<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thank you for your comments, Wes.&nbsp; I
      will be reviewing these and other comments over the next few
      weeks.<br>
      <br>
      -Heather Flanagan<br>
      <br>
      On 7/19/13 8:33 PM, George, Wes wrote:<br>
    </div>
    <blockquote
cite="mid:2671C6CDFBB59E47B64C10B3E0BD59230438FD5FA2@PRVPEXVS15.corp.twcable.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"Lucida Console";
        panose-1:2 11 6 9 4 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Lucida Console";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Lucida Console";}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">I&#8217;ve finally
            gotten around to reviewing the latest version of the style
            guide. Most of my comments from reviewing a prior version
            (below) have not been addressed, but it appears that my
            original message may have gotten stuck in the subscription
            problems that I had when I originally subscribed to
            RFC-interest, so I&#8217;m resending to get them on-list for
            discussion.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">I&#8217;ll note that
            the subject of my original comments regarding section 3.2
            and the number of spaces after periods came up in a previous
            thread, but in the context of tools parsing text, rather
            than the external style. </span><a moz-do-not-send="true"
href="http://www.rfc-editor.org/pipermail/rfc-interest/2013-April/005532.html">http://www.rfc-editor.org/pipermail/rfc-interest/2013-April/005532.html</a>
          <span style="color:#1F497D">(and subsequent messages). My
            citations on the standard (</span><a moz-do-not-send="true"
href="http://www.rfc-editor.org/pipermail/rfc-interest/2013-April/005534.html">http://www.rfc-editor.org/pipermail/rfc-interest/2013-April/005534.html</a>)<span
            style="color:#1F497D"> were &#8220;debunked&#8221; by a long post on the
            history (</span><a moz-do-not-send="true"
href="http://www.rfc-editor.org/pipermail/rfc-interest/2013-April/005540.html">http://www.rfc-editor.org/pipermail/rfc-interest/2013-April/005540.html</a>)<span
            style="color:#1F497D">, but I think that sort of misses the
            point I was trying to make &#8211; both are accepted standards,
            and we&#8217;ll have no better luck declaring one &#8220;right&#8221; and the
            other &#8220;wrong&#8221; than were we to do that with British vs
            American English. My original comments (less the parts
            quoted in the threads above) are below.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <p class="MsoNormal"><span
              style="font-size:10.0pt;color:#1F497D">Thanks,<o:p></o:p></span></p>
          <p class="MsoNormal"><span
              style="font-size:10.0pt;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
          <p class="MsoNormal"><span
              style="font-size:10.0pt;color:#1F497D">Wes George<o:p></o:p></span></p>
        </div>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  George, Wes
                  <br>
                  <b>Sent:</b> Friday, November 02, 2012 5:39 PM<br>
                  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:rfc-interest@rfc-editor.org">rfc-interest@rfc-editor.org</a>;
                  '<a class="moz-txt-link-abbreviated" href="mailto:draft-flanagan-style@tools.ietf.org">draft-flanagan-style@tools.ietf.org</a>'<br>
                  <b>Subject:</b> comments on RFC style guide draft<o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">I&#8217;ve reviewed <a moz-do-not-send="true"
              href="http://tools.ietf.org/html/draft-flanagan-style-00">
              draft-flanagan-style-00</a> and I have comments.<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">First a general formatting comment &#8211; some
            additional sections to break up the content in section 4.8
            would be very helpful for readability and citation. The
            bulleted items make up significant subsections, rather than
            a simple bulleted list.<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">4.8 Requirement words (RFC 2119) may want
            to reference draft-hansen-nonkeywords-non2119 assuming that
            draft goes forward, or perhaps even incorporate some of the
            text of that draft directly into the style guide.<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">4.8 should likely also include a specific
            reference/requirement to use RFC5737 and 3849 documentation
            prefixes whenever IP addresses are used in examples unless
            use of a different range is specifically justified/required.<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Regarding section 4.9: Since people often
            change employers, service providers, etc multiple times
            during the life of an archival document&#8217;s relevance,
            sometimes due to circumstances beyond the author&#8217;s control,
            the use of long-lived email addresses is a nice idea at
            best. The RSE needs to consider some alternatives here to
            assist with maintaining contact with document authors
            despite the fact that both physical and email addresses are
            subject to change.
            <o:p></o:p></p>
          <p class="MsoNormal">Alternatives that come to mind: <o:p></o:p></p>
          <p class="MsoNormal">-creating a permanent email alias such as
            <a moz-do-not-send="true"
              href="mailto:RFCnnnn@tools.ietf.org">
              RFCnnnn@tools.ietf.org</a> that allows the authors to
            update the contact email address associated with them if and
            when it changes (this goes towards support of a metadata
            model for RFC format, I suppose).<o:p></o:p></p>
          <p class="MsoNormal">-allowing an erratum to be filed against
            the RFC to update author contact info (this preserves the
            archival nature of the document, while allowing for an
            important update to ensure that the author can be contacted
            for IPR matters, questions/comments, etc).<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Regarding munged addresses &#8211; if you
            assert that this doesn&#8217;t help to reduce spam, and represents
            an unacceptable barrier for human readers, you need a
            citation supporting such. I&#8217;m not saying you&#8217;re wrong, just
            that a citation would help. Also, IETF is inconsistent in
            their use of munged addresses on official web pages that
            list contact info for I* members and WG chairs. If munging
            in fact doesn&#8217;t help and is simply annoying, we need to stop
            doing it everywhere. Also, an official style guide should
            probably eliminate the colloquialism &#8220;munged addresses&#8221;
            since it adequately explains what it means by that phrase
            such that the phrase itself is no longer necessary.<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Finally, the guidance on the use of URLs
            as references in RFCs in section 4.8 subsection &#8220;References&#8221;
            is a little thin right now. Is there any guidance on
            citation of URLs in published materials within MLA/APA or
            other style guides that addresses this need for stability in
            archival documents? If such a thing exists, I&#8217;d rather we
            use that guidance as a baseline and then discuss exceptions
            rather than building our own.<o:p></o:p></p>
          <p class="MsoNormal">As to the current text:<o:p></o:p></p>
          <p class="MsoNormal">The criteria for determining whether a
            page is a &#8220;personal web page&#8221; and therefore unacceptable as
            a citation must be clearly defined, or this restriction
            should be eliminated. The RSE is not equipped to determine
            which personal websites are stable and which are not based
            on a spot evaluation at the time of publishing, outside of
            perhaps identifying a site that is hosted on ISP-provided
            space that will go away if the owner ever cancels service
            with that provider.
            <o:p></o:p></p>
          <p class="MsoNormal">Additionally, this notion of stable URL
            references is a bit of a pipe dream. Even the most stable of
            websites undergo reorganizations, and only the sites that
            take great care not to break their existing link structure
            or ensure that redirection works properly or leave a
            tombstone will have truly stable references. In the cases
            where the URL goes 404, sometimes a simple web search based
            on the bibliographical reference information will net a
            result, other times not. Then there&#8217;s the matter of things
            like Wikis (esp Wikipedia) where the URL may remain constant
            but the content the author intended to have seen by a reader
            following the reference could well have been edited out or
            changed such that it alters the usefulness of the reference
            to the document. &nbsp;I can understand explicitly prohibiting
            the use of url shorteners, since that virtually guarantees a
            broken link within a few months, but beyond that, the only
            thing the RSE can do is make a best effort to ensure that
            the site is functional at publishing time. If you want to
            ensure archival-quality URL stability, it&#8217;s probably going
            to require allowing errata to correct/update dead links, or
            the use of a static web archive for URL references.<o:p></o:p></p>
          <p class="MsoNormal">And to go back to a related argument from
            some months ago, if the RSE&#8217;s policy is to prohibit the use
            of the Internet Archive (Wayback Machine) as a cited
            reference, that needs to be specifically documented and
            justified in the style guide. Since I ran afoul of this
            personally in a draft I was working on, I&#8217;ll reprise a bit
            of the discussion I had with Ms. Flanagan at the time
            because I think it is relevant in this case. &nbsp;I&#8217;m not trying
            to rehash the argument with Ms. Flanagan, but instead to add
            some points to the discussion as this group works towards
            consensus on this issue, assuming that consensus is indeed
            the goal.<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoPlainText">&#8220;&gt; I understand the rationale
            behind trying to avoid ephemeral references
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; in a "permanent" document, but
            that seems to support<o:p></o:p></p>
          <p class="MsoPlainText">&gt; *using* wayback machine URLs
            (e.g. "the most stable reference
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; available"), rather than avoiding
            them, because it's more certain that
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; this version will not have its
            content significantly altered from what
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; the author intended to cite, and
            there is less risk of the site
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; disappearing. The Wayback machine
            crawls and stores websites as
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; date-based snapshots, and it
            never deletes a snapshot.<o:p></o:p></p>
          <p class="MsoPlainText">&gt; It adds additional snapshots if
            the content changes. Currently, "web
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; 2.0" sites are unlikely to fare
            well in the archive process because of
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; the active content, but more
            standard text content is archived quite
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; effectively. In other words, by
            citing a specific date version of a
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; website on the Internet Archive,
            the author is ensuring that there is
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; a snapshot of the site that is
            representative of the version available
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; when the RFC is published, since
            RFCs are generally a snapshot of
            <o:p></o:p></p>
          <p class="MsoPlainText">&gt; consensus and rationale at the
            time of their publishing.<o:p></o:p></p>
          <p class="MsoPlainText">&gt; <o:p></o:p></p>
          <p class="MsoPlainText">&gt; <o:p></o:p></p>
          <p class="MsoPlainText">&gt; The use of web.archive.org for
            informative references in published RFCs is not without
            precedent (RFCs 4329 and 6265, and there are a number of
            other I-Ds, plus the IETF-hosted timezone data) and so I
            feel like there is a bit of a double-standard at work here,
            both for this draft and for the Web Archive site. When the
            RSE validates URLs in an I-D, my guess is that they go to
            the site and make sure that it loads. They don't make any
            judgments about the relevance of the content, whether the
            subtending links on the resulting page all work properly, or
            when the domain expires, etc. Yet that's exactly what you're
            saying is the problem with the web archive [that some parts
            of an archived page might not work].&#8221;<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Thanks,<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Wes George<span style="color:#1F497D"><o:p></o:p></span></p>
          <p class="MsoNormal"><span
              style="font-size:10.0pt;color:#1F497D">Anything below this
              line has been added by my company&#8217;s mail server, I have no
              control over it.<o:p></o:p></span></p>
          <p class="MsoNormal"><span
              style="font-size:10.0pt;color:#1F497D">-----------------</span><span
              style="color:#1F497D"><o:p></o:p></span></p>
        </div>
      </div>
      <br>
      <hr>
      <font color="Gray" face="Arial" size="1">This E-mail and any of
        its attachments may contain Time Warner Cable proprietary
        information, which is privileged, confidential, or subject to
        copyright belonging to Time Warner Cable. This E-mail is
        intended solely for the use of the individual or entity to which
        it is addressed. If you are not the intended recipient of this
        E-mail, you are hereby notified that any dissemination,
        distribution, copying, or action taken in relation to the
        contents of and attachments to this E-mail is strictly
        prohibited and may be unlawful. If you have received this E-mail
        in error, please notify the sender immediately and permanently
        delete the original and any copy of this E-mail and any
        printout.<br>
      </font>
    </blockquote>
    <br>
  </body>
</html>