Subject: Diffs from USEFOR-06 as of 1/4/06

From: Ken Murchison <[email-masked]>
Date: Wed, 04 Jan 2006 15:03:27 -0500

Attached are my current diffs based on discussion on the list.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University
--- draft-ietf-usefor-usefor-06.unpg	2005-12-16 14:44:25.000000000 -0500
+++ draft-ietf-usefor-usefor-07.unpg	2006-01-04 14:25:47.000000000 -0500
@@ -1,25 +1,25 @@

 
 Usenet Format Working Group                            K. Murchison, Ed.
 Internet-Draft                                Carnegie Mellon University
 Obsoletes: 1036 (if approved)                                 C. Lindsey
-Expires: June 19, 2006                          University of Manchester
+Expires: July 8, 2006                           University of Manchester
                                                                  D. Kohn
                                                         Skymoon Ventures
-                                                       December 16, 2005
+                                                         January 4, 2006

                          Netnews Article Format
-                      draft-ietf-usefor-usefor-06
+                      draft-ietf-usefor-usefor-07
 
 Status of this Memo
 
    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
@@ -30,40 +30,54 @@
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on June 19, 2006.
+   This Internet-Draft will expire on July 8, 2006.
 
 Copyright Notice
 
-   Copyright (C) The Internet Society (2005).
+   Copyright (C) The Internet Society (2006).
 
 Abstract
 
    This document specifies the syntax of network news (Netnews) articles
    in the context of the "Internet Message Format" (RFC 2822) and
    "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045).  This
    document supersedes RFC 1036, updating it to reflect current practice
    and incorporating incremental changes specified in other documents.
 
-Note to the RFC Editor
+Changes since draft-ietf-usefor-usefor-06
+
+   o  Addressed ticket #1155 (ABNF imports).
+
+   o  Addressed ticket #1156 (IANA registration for header fields per
+      RFC 3864).
+
+   o  Addressed ticket #1157 (new ABNF for Control:).
+
+   o  Addressed ticket #1158 (better ABNF for host-value).
+
+   o  Using RFC 4234 as a reference instead of RFC 2234.
+
+   o  Removed reference to RFC 0977 -- using only
+      draft-ietf-nntpext-base.
+
+   o  Added note about Expires being defined by RFC 2156.
+
+   o  Miscellaneous editorial changes.
 
-   The normative reference to RFC 2234 and the informative reference to
-   RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and
-   draft-ietf-nntpext-base respectively should one or both of those of
-   those documents reach RFC status before this one.
 
 Changes since draft-ietf-usefor-usefor-05
 
    o  Resolved ticket #1003 (msg-id).
 
    o  Resolved ticket #1021 (Newsgroups description and exceptions).
 
    o  Resolved ticket #1028 (fixed ABNF for orig-date).
 
    o  Began adding text for ticket #1032 (diff from RFC 1036).
@@ -80,21 +94,21 @@
    o  Resolved ticket #1079 (header fields which don't permit CFWS).
 
    o  Applied text from ticket #1080 (Injection-Info MIME params).
 
    o  Resolved ticket #1082 (Approved header field semantics).
 
    o  Resolved ticket #1088 (Injection-Date mandatory/optional).
 
    o  Resolved ticket #1102 (Definition of "agents", etc).
 
-   o  Removed RFC 0821 as a normative reference.
+   o  Removed RFC 2821 as a normative reference.
 
    o  Miscellaneous editorial changes.

 Changes since draft-ietf-usefor-usefor-04
 
    o  Resolved ticket #1002 (updated references).
 
    o  Applied text from ticket #1003 (ABNF cleanup for msg-id).
 
@@ -203,28 +217,21 @@
 
    o  More exact ABNF for Archive and Injection-Info parameters.
 
    o  Complaints-To header is now an Injection-Info parameter.

 Issues to be addressed
 
    o  Ticket #1047: Path header field delimiters and components.
 
-   o  IANA considerations (the Klyne message header registry is now
-      official as RFC 3864)?.
-
-   o  Collected Syntax?
-
-   o  Merge more security issues?
-
-   o  Merge acknowledgments?
+   o  Ticket #1159: Advice on sender vs. posting account.

 Table of Contents
 
    1.  Introduction
      1.1.  Basic Concepts
      1.2.  Scope
      1.3.  Requirements Notation
      1.4.  Syntax Notation
      1.5.  Definitions
@@ -253,23 +260,24 @@
        3.2.9.  Approved
        3.2.10. Organization
        3.2.11. Xref
        3.2.12. Archive
        3.2.13. User-Agent
        3.2.14. Injection-Info
      3.3.  Obsolete Header Fields
        3.3.1.  Lines
    4.  Internationalization Considerations
    5.  Security Considerations
-   6.  References
-     6.1.  Normative References
-     6.2.  Informative References
+   6.  IANA Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
    Appendix A.  Acknowledgements
    Appendix B.  Differences from RFC 1036 and its derivatives
    Appendix C.  Differences from RFC 2822
    Authors' Addresses
    Intellectual Property and Copyright Statements

 1.  Introduction
 
 1.1.  Basic Concepts
@@ -313,30 +321,52 @@
 
    This document uses terms that appear in capital letters.  The key
    words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
    "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
    are to be interpreted as described in [RFC2119].
 
 1.4.  Syntax Notation
 
    Header fields defined in this specification use the Augmented Backus-
    Naur Form (ABNF) notation (including the Core Rules) specified in
-   [RFC2234] and many constructs defined in [RFC2822] and [RFC2045].
-   Section 3.1.3 updates the [RFC2822] definition of <msg-id>.
+   [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as
+   amended by [RFC2231], and [RFC3986], specifically:
+
+   token         = <see RFC2045 Section 5.1>
+   dot-atom-text = <see RFC2045 Section 5.1>
 
-   The following constructs referenced by this document are defined in
-   [RFC2822]: <mailbox-list>, <mailbox>, <date-time>, <phrase>,
-   <address-list>, <utext>, <dot-atom-text>, <dot-atom>, <FWS>, <CFWS>
-   and <CRLF>.
+   parameter     = <see RFC2231 Section 7>
+   attribute     = <see RFC2231 Section 7>
 
-   The following constructs referenced by this document are defined in
-   [RFC2045] (as amended by [RFC2231]): <token>, <parameter>, <value>.
+   FWS           = <see RFC2822 Section 3.2.3>
+   CFWS          = <see RFC2822 Section 3.2.3>
+   atext         = <see RFC2822 Section 3.2.4>
+   dot-atom-text = <see RFC2822 Section 3.2.4>
+   phrase        = <see RFC2822 Section 3.2.6>
+   utext         = <see RFC2822 Section 3.2.6>
+   date-time     = <see RFC2822 Section 3.3>
+   mailbox       = <see RFC2822 Section 3.4>
+   mailbox-list  = <see RFC2822 Section 3.4>
+   address-list  = <see RFC2822 Section 3.4>
+   fields        = <see RFC2822 Section 3.6>
+
+   IPv6address   = <see RFC3986 Section 3.2.2>
+   IPv4address   = <see RFC3986 Section 3.2.2>
+
+   ALPHA         = <see RFC4234 Appendix B.1>
+   CRLF          = <see RFC4234 Appendix B.1>
+   DIGIT         = <see RFC4234 Appendix B.1>
+   DQUOTE        = <see RFC4234 Appendix B.1>
+   SP            = <see RFC4234 Appendix B.1>
+
+   Additionally, Section 3.1.3 updates the [RFC2822] definition of
+   <msg-id>.
 
 1.5.  Definitions
 
    An "article" is the unit of news, synonymous with an [RFC2822]
    "message".  A "proto-article" is one that has not yet been injected
    into the news system.  In constrast to an "article", a "proto-
    article" may lack some mandatory header fields.
 
    A "message identifier" (Section 3.1.3) is a unique identifier for an
    article, usually supplied by the "user agent" which posted it or,
@@ -397,30 +427,30 @@
    Section 2 defines the format of news articles.  Section 3 details the
    header fields necessary to make an article suitable for the Netnews
    environment.

 2.  Format
 
 2.1.  Base
 
    An article is said to be conformant to this specification if it
-   conforms to the format specified in [RFC2822] section 3 and to the
+   conforms to the format specified in [RFC2822] Section 3 and to the
    additional requirements of this specification.
 
-   An article that uses the obsolete syntax specified in section 4 of
+   An article that uses the obsolete syntax specified in Section 4 of
    [RFC2822], except for the two exceptions mentioned below, is NOT
    conformant to this specification.
 
    Articles are conformant if they use the <obs-phrase> construct (use
    of a phrase like "John Q. Public" without the use of quotes, see
-   [RFC2822] section 4.1) but agents MUST NOT generate productions of
+   [RFC2822] Section 4.1) but agents MUST NOT generate productions of
    such syntax.
 
    Articles are conformant if they use the "GMT" <zone>, as specified in
    Section 3.1.2.
 
    This document, and specifications that build upon it, specifies how
    to handle conformant articles.  Handling of non-conformant articles
    is outside the scope of this specification.
 
    Agents conforming to this specification MUST generate only conformant
@@ -428,27 +458,27 @@
 
    The text below uses ABNF to specify restrictions on the syntax
    specified in [RFC2822]; this grammar is intended to be more
    restrictive than the [RFC2822] grammar.  Articles must conform to the
    ABNF specified in [RFC2822].
 
    Articles must also conform to the restrictions specified here, both
    those that are expressed as text and those that are expressed as
    ABNF.
 
-      NOTE: Older Netnews specifications used the term "header" as a
-      synonym for what [RFC2822] calls "header field".  This document
-      follows the terminology in Section 2 of [RFC2822] in using the
-      terms "line", "header field", "header field name", "header field
-      body", and "folding", based on a belief that consistent
-      terminology among specifications that depend on each other makes
-      the specifications easier to use in the long run.
+      NOTE: Other specifications use the term "header" as a synonym for
+      what [RFC2822] calls "header field".  This document follows the
+      terminology in Section 2 of [RFC2822] in using the terms "line",
+      "header field", "header field name", "header field body", and
+      "folding", based on a belief that consistent terminology among
+      specifications that depend on each other makes the specifications
+      easier to use in the long run.
 
 2.2.  Header Fields
 
    All header fields in a news article are compliant with [RFC2822],
    however this specification is less permissive in what can be
    generated and accepted by news agents.  The syntax allowed for news
    articles is a strict subset of the "Internet Message Format", making
    all messages compliant with this specification inherently compliant
    with [RFC2822].  Note however that the converse is not guaranteed to
    be true in all cases.
@@ -509,59 +539,60 @@
    encodings within any <unstructured> header field, or within any
    <comment> or <phrase> permittted within any structured header field.
 
    User agents MAY accept and generate other MIME extension header
    fields, and in particular SHOULD accept Content-Disposition [RFC2183]
    and Content-Language [RFC3282].

 3.  News Header Fields
 
-   The following news header fields extend those defined in section 3.6
+   The following news header fields extend those defined in Section 3.6
    of [RFC2822]:
 
    fields          =/ *( newsgroups /
                          path /
                          injection-date /
                          followup-to /
                          expires /
                          control /
                          supersedes /
                          distribution /
                          summary /
                          approved /
                          organization /
                          xref /
                          archive /
                          user-agent /
-                         injection-info )
+                         injection-info /
+                         lines )
 
    Each of these header fields may occur at most once in a news article.
 
    The following header fields defined in this document do not allow
    comments (CFWS):
 
    Newsgroups
    Path
    Followup-to
    Control
    Supersedes
    Distribution
    Xref
    Lines
 
    This also applies to the following header field defined in [RFC2822]:
 
    Message-ID
 
-   Several of these headers are mainly of interest to servers, and
-   servers often need to process these fields very rapidly.
+   Several of these headers are mainly of interest to news servers, and
+   news servers often need to process these fields very rapidly.
 
 3.1.  Mandatory Header Fields
 
    Each news article conformant with this specification MUST have
    exactly one of each of the following header fields: From, Date,
    Message-ID, Subject, Newsgroups, Path.
 
 3.1.1.  From
 
    The From header field is the same as that specified in Section 3.6.2
@@ -579,32 +610,32 @@
    "GMT" zone.
 
    orig-date       =  "Date:" SP date-time CRLF
 
       NOTE: This specification does not change [RFC2822], which says
       that agents MUST NOT generate <date-time> constructs which include
       any zone names defined by <obs-zone>.
 
    Software that accepts dates with unknown timezones SHOULD treat such
    timezones as equivalent to "-0000" when comparing dates, as specified
-   in [RFC2822] section 4.3.
+   in [RFC2822] Section 4.3.
 
    Also note that these requirements apply wherever <date-time> is used,
    including Injection-Date and Expires in Section 3.2.1 and
    Section 3.2.4 respectively.
 
 3.1.3.  Message-ID
 
    The Message-ID header field contains a single unique message
    identifier.  Netnews is more dependent on message identifier
    uniqueness and fast comparison than Email is, and some news software
-   and standards [RFC0977] might have trouble with the full range of
+   and standards [NNTP] might have trouble with the full range of
    possible <msg-id>s permitted by [RFC2822]; this section therefore
    restricts the syntax of <msg-id> as compared to Section 3.6.4 of
    [RFC2822].  The global uniqueness requirement for <msg-id> in
    [RFC2822] is to be understood as applying across all protocols using
    such message identifiers, and across both Email and Netnews in
    particular.
 
    message-id      =  "Message-ID:" SP [FWS] msg-id [FWS] CRLF
 
    msg-id          =  "<" id-left "@" id-right ">"
@@ -745,53 +776,53 @@
    private prior agreement to do so.  However, such names MUST be
    accepted by news servers.
 
    The following <newsgroup-name>s are reserved, and MUST NOT be used as
    the name of a newsgroup:
 
    o  Groups whose first (or only) component is "example"
 
    o  The group "poster"
 
-   The following <newsgroup-name&gts have been used for specific
-   purposes in various implementations and protocols, and therefore MUST
-   NOT be used for the names of normal newsgroups.  They MAY be used for
-   their specific purpose, or by local agreement.
+   The following <newsgroup-name>s have been used for specific purposes
+   in various implementations and protocols, and therefore MUST NOT be
+   used for the names of normal newsgroups.  They MAY be used for their
+   specific purpose, or by local agreement.
 
-      Groups whose first (or only) component is "to"
+   o  Groups whose first (or only) component is "to"
 
-      Groups whose first (or only) component is "control"
+   o  Groups whose first (or only) component is "control"
 
-      Groups which contain (or consist only of) the component "all"
+   o  Groups which contain (or consist only of) the component "all"
 
-      Groups which contain (or consist only of) the component "ctl"
+   o  Groups which contain (or consist only of) the component "ctl"
 
-      The group "junk"
+   o  The group "junk"
 
       NOTE: "example.*" is reserved for examples in this and other
       standards; "poster" has a special meaning in the Followup-To
       header field; "to.*" is reserved for certain point-to-point
       communications in conjunction with the "ihave" control message
       [USEPRO]; "control.*" and "junk" have special meanings in some
       news-servers; "all" is used as a wildcard in some implementations;
       and "ctl" was formerly used to indicate a <control-command> within
       the Subject header field.
 
 3.1.6.  Path
 
    The Path header field indicates the route taken by an article since
    its injection into the Netnews system.  Each agent that processes an
    article is required to prepend one (or more) identities to this
    header field body.  This is primarily to enable news servers to avoid
    sending articles to sites already known to have them, in particular
    the site they came from, and additionally to permit tracing the route
-   articles take in moving over the network, and for gathering Usenet
+   articles take in moving over the network, and for gathering
    statistics.
 
    path            =  "Path:" SP path-list CRLF
 
    path-list       =  [FWS]
                       *( ( path-identity / path-keyword /
                            path-diagnostic ) [FWS]
                          path-delimiter [FWS] )
                       tail-entry [FWS]
 
@@ -808,25 +839,30 @@
    path-delimiter  =  "!" / "!!"
 
    A <path-identity> is a name identifying a site.  It takes the form of
    a domain name having one or more components separated by dots.
 
    Each <path-identity> in the <path-list> (excluding the one in the
    <tail-entry>) indicates, from right to left, the successive agents
    through which the article has passed.  The <path-keyword> "POSTED"
    indicates that the agent to its left injected the article.  The use
    of the <path-delimiter> "!!" indicates that the agent to its left
-   claims that the agent to its right was the verified source of the
+   verified the identity of the agent to its right before accepting the
    article (whereas the <path-delimiter> "!" implies no such claim).
    The <path-keyword> "MISMATCH" indicates that the agent to its right
    failed to be so verified.
 
+      NOTE: Historically, the <tail-entry> indicated the name of the
+      sender.  If not used for this purpose, the string "not-for-mail"
+      is often used instead (since at one time the whole path could be
+      used as a mail address for the sender).
+
       NOTE: Although case-insensitive, it is intended that the <path-
       keyword>s "POSTED" and "MISMATCH" should be in upper case, to
       distinguish them from the <path-identity>s which are traditionally
       in lower case.
 
    A <path-diagnostic> is an item inserted into the Path header for
    purposes other than to indicate the name of a site.  One commonly
    observed usage is to insert an IP address.  The colon (":") is
    permitted in order to allow IPv6 addresses to be inserted; note that
    this will cause interoperability problems at older sites that regard
@@ -870,22 +906,22 @@
    already expired by the time they arrive at some news server.
 
    This header field MUST be inserted whenever an article is injected.
    However, software that predates this standard does not use this
    header, and therefore agents MUST accept articles without the
    Injection-Date header field.
 
    injection-date  =  "Injection-Date:" SP date-time CRLF

-   See the remarks under Section 3.1.2 regarding the syntax of <date-
-   time> and the requirements and recommendations to which it is
+   See the remarks under Section 3.1.2 regarding the syntax of
+   <date-time> and the requirements and recommendations to which it is
    subject.
 
       NOTE: The <date-time> in this header field would normally be
       expected to be later than the <date-time> in the Date header
       field, but differences between the clocks on the various agents
       and other special circumstances might vitiate that; no provision
       is made for any such discrepancy to be corrected - better that the
       news server should just insert the correct time as it sees it.
 
    This header field is intended to replace the currently-used but
@@ -932,63 +968,66 @@
    insensitive forms such as "Poster".
 
 3.2.4.  Expires
 
    The Expires header field specifies a date and time when the article
    is deemed to be no longer relevant and could usefully be removed
    ("expired").
 
    expires         =  "Expires:" SP date-time CRLF
 
-   See the remarks under Section 3.1.2 regarding the syntax of <date-
-   time> and the requirements and recommendations to which it is
+   See the remarks under Section 3.1.2 regarding the syntax of
+   <date-time> and the requirements and recommendations to which it is
    subject.
 
+      NOTE: The Expires header field is also sometimes used in Email
+      with a similar meaning [RFC2156].
+
 3.2.5.  Control
 
    The Control header field marks the article as a control message, and
    specifies the desired actions (additional to the usual ones of
    storing and/or relaying the article).
 
    control         =  "Control:" SP [FWS] control-command [FWS] CRLF
 
-   control-command =  verb *( [FWS] argument )
+   control-command =  verb *( 1*WSP argument )
 
    verb            =  token
 
-   argument        =  value
+   argument        =  1*( %x21-7E )
 
    The verb indicates what action should be taken, and the argument(s)
    (if any) supply details.  In some cases, the body of the article may
    also contain details.  The legal verbs and respective arguments are
    discussed in the companion document, [USEPRO].
 
    An article with a Control header field MUST NOT also have a
    Supersedes header field.
 
 3.2.6.  Supersedes
 
    The Supersedes header field contains a message identifier specifying
    an article to be superseded upon the arrival of this one.  An article
    containing a Supersedes header field is equivalent to a "cancel"
    [USEPRO] control message for the specified article, followed
    immediately by the new article without the Supersedes header field.
 
    supersedes      =  "Supersedes:" SP [FWS] msg-id [FWS] CRLF
 
-   NOTE: There is no "c" in Supersedes.
+      NOTE: There is no "c" in Supersedes.
 
-   NOTE: The Supersedes header field defined here has no connection with
-   the Supersedes header field that sometimes appears in Email messages
-   converted from X.400 according to [RFC2156]; in particular, the
-   syntax here permits only one <msg-id> in contrast to the multiple
-   <msg-id>s in that Email version.
+      NOTE: The Supersedes header field defined here has no connection
+      with the Supersedes header field that sometimes appears in Email
+      messages converted from X.400 according to [RFC2156]; in
+      particular, the syntax here permits only one <msg-id> in contrast
+      to the multiple <msg-id>s in that Email version.
 
 3.2.7.  Distribution
 
    The Distribution header field specifies geographic or organizational
    limits on an article's propagation.
 
    distribution    =  "Distribution:" SP dist-list CRLF
 
    dist-list       =  [FWS] dist-name
                       *( [FWS] "," [FWS] dist-name ) [FWS]
@@ -1117,51 +1156,53 @@
 
 3.2.14.  Injection-Info
 
    The Injection-Info header field contains information provided by the
    injecting news server as to how an article entered the Netnews system
    and to assist in tracing its true origin.  It can also specify one or
    more addresses where complaints concerning the poster of the article
    may be sent.
 
    injection-info  =  "Injection-Info:" SP [CFWS] path-identity
-                      [CFWS] *(';' parameter) CRLF
+                      [CFWS] *( ";" parameter ) CRLF
 
       NOTE: The syntax of <parameter> ([RFC2045] as amended by
       [RFC2231]), taken in conjunction with the folding rules of
       [RFC0822], effectively allows [CFWS] to occur both before and
       after the <parameter>, and also on either side of its "=".
 
    The following table gives the <attribute> and the format of the
    <value> for each <parameter> defined for use with this header field.
    At most one occurrence of each such <parameter> is allowed.
 
    <attribute>              format of <value>
    --------------------     -----------------
    "posting-host"           a <host-value>
    "posting-account"        any <value>
    "sender"                 a <sender-value>
    "logging-data"           any <value>
    "mail-complaints-to"     an <address-list>
 
    where
 
-   host-value      =  dot-atom-text / [ dot-atom-text ":" ]
-                      ( IPv4address / IPv6address ) ;  see [RFC 3986]
+   host-value      =  dot-atom-text / IPv4address / IPv6address /
+                      (dot-atom-text ":" ( IPv4address / IPv6address ))
 
    sender-value    =  mailbox / "verified"
 
       NOTE: Since any such <host-value>>, <sender-value> or <address-
       list> has also to be a syntactically correct <value>, it will
-      usually be necessary to encapsulate is as a <quoted-string>, for
+      usually be necessary to encapsulate it as a <quoted-string>, for
       example:
 
+   posting-host = "an.example.de:::ad:be:ef"
+
    sender = "\"Joe Q. Public\" <[email-masked]>"
 
    Additionally, any other <parameter> whose <attribute> starts with
    "x-" MAY be used where the defined ones appear to be unsuitable, but
    other unlisted <parameter>s SHOULD NOT be used unless defined in
    extensions to this standard.
 
    Although comments and folding of white space are permitted throughout
    the Injection-Info header field, it is RECOMMENDED that folding is
    not used within any <parameter> (but only before or after the ";"
@@ -1173,31 +1214,31 @@
       X-Complaints-To, and others.  Once a news server uses Injection-
       Info, it should have no need to send these non-standard header
       fields.
 
    The "posting-host" <parameter> specifies the FQDN and/or IP address
    (IPv4address or IPv6address) of the host from which the news server
    received the article.
 
       NOTE: If the "posting-host" <parameter> identifies a dial-up
       point-of-presence, the "posting-account" or the "logging-data"
-      <parameter> may provide additional information about true origin
-      of the article.
+      <parameter> may provide additional information about the true
+      origin of the article.
 
    The "posting-account" <parameter> identifies the source from which
-   that news server received the article.  For security reasons, it
-   SHOULD be in a cryptic notation understandable only by the
-   administrator of the news server.
+   that news server received the article.  For security reasons and
+   other reasons, it SHOULD be in a cryptic notation understandable only
+   by the administrator of the news server.
 
    The "sender" <parameter> identifies the mailbox of the verified
    sender of the article (alternatively, it uses the token "verified" to
-   indicate that at least any addr-spec in the Sender header field of
+   indicate that at least any <addr-spec> in the Sender header field of
    the article, or in the From header field if the Sender header field
    is absent, is correct).  If a news server can verify the sender of an
    article, it SHOULD use this <parameter> in favor of the "posting-
    account" <parameter>.
 
    The "logging-data" <parameter> contains information (typically a
    session number or other non-persistent means of identifying a posting
    account) which will enable the true origin of the article to be
    determined by reference to logging information kept by the news
    server.
@@ -1214,20 +1255,23 @@
    Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
    Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
    Date-Received: Friday, 19-Nov-82 16:59:30 EST
 
    Relay-Version contained version information about the news server
    that last processed the article.  Posting-Version contained version
    information about the user agent that posted the article.  Date-
    Received contained the date when the last news server to process the
    article first saw it (in a slightly nonstandard format).
 
+   These header fields are mentioned for historical purposes only.
+   Agents SHOULD NOT generate articles containing these header fields.
+
    In addition, this present standard obsoletes certain header fields
    defined in [Son-of-1036]:
 
    Also-Control: cancel <[email-masked]>
    See-Also: <[email-masked]> <[email-masked]>
    Article-Names: comp.foo:charter
    Article-Updates: <[email-masked]>
 
    Also-Control indicated a control message that was also intended to be
    filed as a normal article.  See-Also listed related articles, but
@@ -1240,42 +1284,42 @@
    The header fields listed above are documented for historical purposes
    only.  Articles containing these header fields MUST NOT be generated.
    Persons writing new agents SHOULD ignore any former meanings of these
    header fields.
 
 3.3.1.  Lines
 
    The Lines header field indicates the number of lines in the body of
    the article.
 
-   lines           =  "Lines" ":" SP [FWS] 1*DIGIT [FWS] CRLF
+   lines           =  "Lines:" SP [FWS] 1*DIGIT [FWS] CRLF
 
    The line count includes all body lines, including the signature if
    any, including empty lines (if any) at the beginning or end of the
    body, and including the whole of all MIME message and multipart parts
    contained in the body (the single empty separator line between the
    header fields and the body is not part of the body).  The "body" here
    is the body as found in the posted article as transmitted by the user
    agent.
 
-   Historically, this header field was used by the [NNTP] overview
-   extension, but its use for this purpose is now deprecated.  As a
+   Historically, this header field was used by the [NNTP] Overview
+   facility, but its use for this purpose is now deprecated.  As a
    result, this header field is to be regarded as obsolescent, and it is
    likely to be removed entirely in a future version of this standard.
    Servers and clients SHOULD ignore it, and SHOULD NOT generate it.

 4.  Internationalization Considerations
 
    Internationalization of news article header fields and bodies is
    provided using MIME mechanisms discussed in Section 2.3.  Note that
-   the generation of internationalized <newsgroup name>s for use in
+   the generation of internationalized <newsgroup-name>s for use in
    header fields is not addressed in this document.

 5.  Security Considerations
 
    The news article format specified in this document does not provide
    any security services, such as confidentiality, authentication of
    sender, or non-repudiation.  Instead, such services need to be
    layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME
    [RFC3156], or below, using secure versions of news transport
@@ -1294,28 +1338,220 @@
 
    MIME security considerations are discussed in [RFC2046].  Note that
    the full range of encodings allowed for parameters in [RFC2046] and
    [RFC2231] permits constructs that simple parsers may fail to parse
    correctly; examples of hard-to-parse constructs are:
 
    Content-Type: multipart/mixed
    (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
 
    Content-Type: multipart/digest;
-   boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
+    boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
 
    Such differences in parsing may be used as part of an attack.

-6.  References
+6.  IANA Considerations
+
+   IANA is requested to register the following header fields in the
+   Permanent Message Header Field Repository, in accordance with the
+   procedures set out in [RFC3864].
+
+      Header field name: Also-Control
+      Applicable protocol: netnews
+      Status: historic
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): [Son-of-1036] (Section 6.15)
+
+      Header field name: Approved
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.9)
+
+      Header field name: Archive
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.12)
+
+      Header field name: Article-Names
+      Applicable protocol: netnews
+      Status: historic
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): [Son-of-1036] (Section 6.17)
+
+      Header field name: Article-Updates
+      Applicable protocol: netnews
+      Status: historic
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): [Son-of-1036] (Section 6.18)
+
+      Header field name: Comments
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2),
+      [RFC2822] (Section 3.6.5)
+
+      Header field name: Control
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.5)
+
+      Header field name: Date
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.1.2),
+      [RFC2822] (Section 3.6.1)
+
+      Header field name: Distribution
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.7)
+
+      Header field name: Expires
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.4),
+      [RFC2156] (Section 5.3.4)
+
+      Header field name: Followup-To
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.3)
+
+      Header field name: From
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.1.1),
+      [RFC2822] (Section 3.6.2)
+
+      Header field name: Injection-Date
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.1)
+
+      Header field name: Injection-Info
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.14)
+
+      Header field name: Keywords
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2),
+      [RFC2822] (Section 3.6.5)
+
+      Header field name: Lines
+      Applicable protocol: netnews
+      Status: obsoleted
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.3.1)
+      Related information: [NNTP] (Section 8.1)
+
+      Header field name: Message-ID
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.1.3),
+      [RFC2822] (Section 3.6.4)
+
+      Header field name: Newsgroups
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.1.5)
+
+      Header field name: Organization
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.10)
+
+      Header field name: Path
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.1.6)
+
+      Header field name: References
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.2),
+      [RFC2822] (Section 3.6.4)
+
+      Header field name: Reply-To
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2),
+      [RFC2822] (Section 3.6.2)
+
+      Header field name: See-Also
+      Applicable protocol: netnews
+      Status: historic
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): [Son-of-1036] (Section 6.16)
+
+      Header field name: Sender
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2),
+      [RFC2822] (Section 3.6.2)
+
+      Header field name: Subject
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.1.4),
+      [RFC2822] (Section 3.6.5)
+
+      Header field name: Summary
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.8)
+
+      Header field name: Supersedes
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.6)
+
+      Header field name: User-Agent
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.13)
+
+      Header field name: Xref
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF ([email-masked])
+      Specification document(s): This document (Section 3.2.11)
+
 
-6.1.  Normative References
+7.  References
+
+7.1.  Normative References
 
    [Errata]   "RFC Editor Errata".
 
    [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part One: Format of Internet Message
               Bodies", RFC 2045, November 1996.
 
    [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part Two: Media Types", RFC 2046,
               November 1996.
@@ -1332,157 +1568,158 @@
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
               Presentation Information in Internet Messages: The
               Content-Disposition Header Field", RFC 2183, August 1997.
 
    [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
               Word Extensions: Character Sets, Languages, and
               Continuations", RFC 2231, November 1997.
 
-   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", RFC 2234, November 1997.
-
    [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
               April 2001.
 
    [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
               May 2002.
 
-6.2.  Informative References
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+7.2.  Informative References
 
    [ISO.3166.1988]
               International Organization for Standardization, "Codes for
               the representation of names of countries, 3rd edition",
               ISO Standard 3166, August 1988.
 
    [NNTP]     Feather, C., "Network News Transfer Protocol",
               draft-ietf-nntpext-base-*.txt.
 
    [PGPVERIFY]
               Lawrence, D., "PGPverify", June 1999.
 
    [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
               text messages", STD 11, RFC 822, August 1982.
 
-   [RFC0977]  Kantor, B. and P. Lapsley, "Network News Transfer
-              Protocol", RFC 977, February 1986.
-
    [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
               USENET messages", RFC 1036, December 1987.
 
    [RFC2156]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
               Mapping between X.400 and RFC 822/MIME", RFC 2156,
               January 1998.
 
    [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
               Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
               Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 
    [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
               "MIME Security with OpenPGP", RFC 3156, August 2001.
 
    [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
               Extensions (S/MIME) Version 3.1 Message Specification",
               RFC 3851, July 2004.
 
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              September 2004.
+
    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", STD 66,
               RFC 3986, January 2005.
 
    [Son-of-1036]
               Spencer, H., "News Article Format and Transmission",
               June 1994.
 
    [USEAGE]   Lindsey, C., "Usenet Best Practice",
               draft-ietf-usefor-useage-*.txt.
 
    [USEPRO]   Lindsey, C., "News Article Architecture and Protocols",
               draft-ietf-usefor-usepro-*.txt.

 Appendix A.  Acknowledgements
 
-   Comments and/or text were provided by Mark Crispin, Claus Faerber,
-   Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson,
-   Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey
-   Melnikov.
+   As this document is the result of an eight year effort, the number of
+   people that have contributed to its content are too numerous to
+   mention individually.  Many thanks go out to all past and present
+   members of the USEFOR Working Group of the Internet Engineering Task
+   Force (IETF) and the accompanying mailing list.

 Appendix B.  Differences from RFC 1036 and its derivatives
 
    This appendix contains a list of changes that have been made in the
    Netnews Article Format from earlier standards, specifically
    [RFC1036].
 
-      The [RFC2822] conventions for parenthesis-enclosed <comment>s in
+   o  The [RFC2822] conventions for parenthesis-enclosed <comment>s in
       header fields are supported in all newly defined header fields and
       in header fields inherited from [RFC2822].  They are, however,
       still disallowed for performance and/or compatibility reasons in
       the Message-ID, Newsgroups, Path, Followup-To, Control,
       Supersedes, Distribution, Xref and Lines header fields.
 
-      Whitespace is permitted in Newsgroups header fields.
+   o  Whitespace is permitted in Newsgroups header fields.
 
-      An enhanced syntax for the Path header field enables the injection
+   o  An enhanced syntax for the Path header field enables the injection
       point of, and the route taken by an article to be determined with
       more precision.
 
-      MIME is recognized as an integral part of Netnews.
+   o  MIME is recognized as an integral part of Netnews.
 
-      There is a new Injection-Date header to make the rejection of
+   o  There is a new Injection-Date header to make the rejection of
       stale articles more precise and to minimize spurious rejections.
 
-      There are several new optional header fields defined, notably
+   o  There are several new optional header fields defined, notably
       Archive, Injection-Info and User-Agent, leading to increased
       functionality.
 
-      Certain header fields, notably Lines, have been made obsolete
+   o  Certain header fields, notably Lines, have been made obsolete
       (Section 3.3).
 
-      There are numerous other small changes, clarifications and
+   o  There are numerous other small changes, clarifications and
       enhancements.

 Appendix C.  Differences from RFC 2822
 
    This appendix lists the differences between the syntax allowed by the
    Netnews Article Format (this document) as compared to the Internet
    Message Format, as specified in [RFC2822].
 
    The Netnews article format is a strict subset of the Internet Message
    Format; all Netnews articles conform to the syntax of [RFC2822].
 
    The following restrictions are important:
 
-      A SP (space) is REQUIRED after the colon (':') following header
+   o  A SP (space) is REQUIRED after the colon (':') following header
       field name.
 
-      A more restricted syntax of <msg-id> (to be used by the
+   o  A more restricted syntax of <msg-id> (to be used by the
       Message-ID, References, and Supersedes header fields) is defined.
 
-      The length of a msg-id MUST NOT exceed 250 octets.
+   o  The length of a <msg-id> MUST NOT exceed 250 octets.
 
-      Comments are not allowed in the Message-ID header field.
+   o  Comments are not allowed in the Message-ID header field.
 
-      The CFWS between <msg-id>s in the References header field is not
+   o  The CFWS between <msg-id>s in the References header field is not
       optional.
 
-      It is legal for a parser to not accept obsolete syntax, except
-      that:
+   o  It is legal for a parser to reject obsolete syntax, except that:
 
-         The <obs-phrase> construct MUST be accepted.
+      *  The <obs-phrase> construct MUST be accepted.
 
-         The obsolete <zone> "GMT" MUST be accepted within a <date-
+      *  The obsolete <zone> "GMT" MUST be accepted within a <date-
          time>.
 
-      Every line of a header field body (including the first and any
+   o  Every line of a header field body (including the first and any
       that are subsequently folded) MUST contain at least one non-
       whitespace character.  This means that an empty header field body
       is illegal.

 Authors' Addresses
 
    Kenneth Murchison (editor)
    Carnegie Mellon University
    5000 Forbes Avenue
@@ -1547,21 +1784,21 @@
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 Copyright Statement
 
-   Copyright (C) The Internet Society (2005).  This document is subject
+   Copyright (C) The Internet Society (2006).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

 Acknowledgment
 
    Funding for the RFC Editor function is currently provided by the
    Internet Society.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 05 Jan 2006 03:19:27 +0100

Ken Murchison wrote:

> my current diffs based on discussion on the list.

Great stuff, thanks.

> +   Additionally, Section 3.1.3 updates the [RFC2822] definition of

Standing out like a beacon, I like it.

>     and Content-Language [RFC3282].

Out of context I wonder why that SHOULD is no MUST, and why we talk about
it at all.  If a news server rejects articles with these header fields it
is broken, or what could be a justification to do this ?

>     This also applies to the following header field defined in [RFC2822]:

After the beacon in 1.4 another alert is unnecessary, I'd kill the lines:
-
-     This also applies to the following header field defined in [RFC2822]:
-

> +   news servers often need to process these fields very rapidly.

Is 7 out of 9 "Several" or better "Most" ?  Nit:  s/headers/header fields/

>                        *( [FWS] "," [FWS] dist-name ) [FWS]

Are the two internal [FWS] here approved by Russ ?  The whole distribution
concept is rather old, does it really work anywhere, except from "local" ?

>     sender = "\"Joe Q. Public\" <[email-masked]>"

LOL, full disclosure, nobody can claim that we didn't tell them, nice.
Unfortunately the owner of example.de doesn't like jokes with his FQDN,
(got too much bogus mails), maybe we should pick a better example.

>     article, it SHOULD use this <parameter> in favor of the "posting-

Yes, ticket #1159 is noted as new point in the "Issues to be addressed".

> +   Agents SHOULD NOT generate articles containing these header fields.

Actually I thought that we better get rid of pre-1036 history with those
three header fields:  S-o-1036 would cover this.  We reference it anyway,
as RFC or as you have it now.  The SHOULD NOT is dubious, s-o-1036 says:

"for archaeological purposes only.  Do not generate articles using them"

Some lines later you already have a MUST NOT for the complete 3.3 zoo,
adding a SHOULD NOT for the oldest and obscurest header fields wasn't
the idea.  Just delete everything from "Early" up to "In addition,"

>     defined in [Son-of-1036]:

In other words start section 3.3 with "This present standard" etc.

> +    boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy

Yes, but we want the proper folding in both examples.

> +      Author/change controller: IETF ([email-masked])

IMNSHO we can do without an address for IETF.  When SPF went from
"experimental" to "standards track" (before it was pushed back) I
checked that, and IIRC "change controller: IETF" is good enough.

> +      Specification document(s): This document (Section 3.2.9)

xml2rfc has a trick for RFCxxxx instead of "this document", IANA
can't say "this document" in their registry.  Nothing to worry
about, the RFC-editor and IANA will get the idea.

> +      [RFC2822] (Section 3.6.1)

Are you sure that they want and need the section ?  Even if you're
sure they should already know where to find it for 2822, they have
this in RFC 4021.

> +      Applicable protocol: netnews

Better say "deprecated" or "obsolescent" as stated in 3.3.1, we need
"obsoleted" for the NNTP-Posting-*.

> +      [RFC2822] (Section 3.6.4)

No, our Mesaage-ID isn't specified in 2822.  There are overloaded
names for similar 2822-productions unfortunately, but otherwise it
is quite different, as stated in 1.4 (see above).  RFC 4021 uses...

         Related information: ...

...for such cases, e.g. many specification: 2822, related info: 822.

> +      Header field name: Organization

Here I miss NNTP-Posting-* with status "obsoleted".  Maybe you can
say "Specification: n/a" (or "trad.") with "related info: RFCxxxx
section 3.2.1 Injection-Date" for NNTP-Posting-Date.  Dito "3.2.14
Injection-Info" for NNTP-Posting-Host.

All this "standard business" is about getting the idea somehow to
as many readers as possible, hoping that it's implemented a.s.a.p.

>                ISO Standard 3166, August 1988.

For LTRU (3066bis) we used the freshest version:

   [ISO3166-1]
              International Organization for Standardization, "ISO 3166-
              1:1997. Codes for the representation of names of countries
              and their subdivisions -- Part 1: Country codes", 1997.

xml2rfc-template available in
http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.xml

BTW, I think that 3166-1 qualifies as "normative", maybe also NNTP.

>                Lawrence, D., "PGPverify", June 1999.

Is that the best we can do, no URL, only author + title ?

>                draft-ietf-usefor-usepro-*.txt.

Only informative, sure ?

> +   the number of people that have contributed to its content are too
> +   numerous to mention individually.

True, but I kind of like the huge 2822 "IETF who is who", and if you
mention Henry, Ned, and Russ it will be noted in the Usenet community
as no nonsense.  Otherwise they might decide to ditch it as irrelevant.
USENET is seriously mad, worse than the IETF.  Maybe "special thanks"
to Henry, Ned, and Russ.  After the huge IANA templates "keep it short
and sweet" is anyway lost in space... :-(

> +   o  Certain header fields, notably Lines, have been made obsolete

Notably Lines is only "deprecated" / "obsolescent" in 3.3.1.  Based on
1036 (appendix B is about 1036) we obsoleted not a single header field.
The stuff we removed is in s-o-1036, and the two NNTP-Hosting-*.  And
appendix B is NOT about s-o-1036, let alone any pre-1036 "archaeology".

> +   o  A SP (space) is REQUIRED after the colon (':') following header

Nit: s/header/the header/ or s/header/a header/ or similar.

I miss "removed Subject: cmsg" (#1032) and I think we should mention
that we seriously try to support IPv6 everywhere (in addition to 1036).

> +      *  The obsolete <zone> "GMT" MUST be accepted within a <date-

s/date-time/date&nbhy;time/ in the XML source.  Okay, essentially only
#1047 and some minor stuff pending.
                                   Tnx & bye, Frank

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 05 Jan 2006 07:56:31 -0500

> and sweet" is anyway lost in space... :-(

The hoped for effect of implied endorsement through name dropping is
not going to make a difference.

It is notably dishonest to try to pass these documents off as products of Henry, 
Russ, et al, without mentioning the cooks who spoiled the broth.

If these documents had been left to Henry, Ned, and Russ, I'm sure they
would have turned out much differently, and be relevant.

I've stopped reading and participating, (as have many others if the
list traffic is accurate indication.)  But this one just seemed too
sly and manipulative to leave without comment.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 05 Jan 2006 09:17:38 -0500

> sly and manipulative to leave without comment.

Hopefully those people that have stopped participating on the list will 
at least look over the document during WG/IETF last call.  If we produce 
a specification that the community will ignore (again?), then we have 
wasted everyone's time.

-- 
Kenneth Murchison
Systems Programmer

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 5 Jan 2006 14:24:50 GMT

>+   control-command =  verb *( 1*WSP argument )

Yes, but we haven't agreed that WSP yet.

>+   argument        =  1*( %x21-7E )

That seems OK

>+   posting-host = "an.example.de:::ad:be:ef"

Well if we are to have an example of a quoted-string in a posting-host,
then we don't need a confusing one like that (people will be looking for
all sorts of hidden subtleties that are not there, not realising that it
is that first ':' which necessitates the quoting). We need something like

     posing-host = "[email-masked]:123.456.123.456"
(but choose an IP address guaranteed not to exist, of course)

>+      Specification document(s): [Son-of-1036] (Section 6.15)

I think I slightly prefer "obsolete" (or is it "obsoleted") to "historic"
for these.

Also, you need to say something about NNTP-Posting-Host and
NNTP-Posting-Date which definitely need to be recorded in the IANA
Registry as something that is no longer supposed to be used (whichever
of obsolete/historic you choose to use). The fact that they have no
Specification Document make it even more important to clarify their status
here (you would say "Specification document(s): None", of course).

>+      [RFC2156] (Section 5.3.4)

No, I don't think that is right. I would expect some other template
registered with "Applicable protocol: email" to mention RFC2156. but it
should not be mentioned here. The situation with regard to Supersedes and
User-Agent is similar, but you made (quite rightly) no additional
references there.

Note that the cases where you mention RFC2822 as well as "This Document"
are fine, because in those cases our definition relies (to varying
extents) on what is said in 2822.

>+      Related information: [NNTP] (Section 8.1)

s/obsoleted/obsolescent/ (it is only "SHOULD NOT generate")

or s/obsoleted/deprecated/ if you prefer.

>+   Force (IETF) and the accompanying mailing list.

Yes, I agree (though you might decide to list the various chairmen who
have watched over us). I have adopted that same text for USEPRO.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 05 Jan 2006 23:44:26 +0100

Forrest J. Cavalier III wrote:

> The hoped for effect of implied endorsement through name
> dropping is not going to make a difference.

For me it did in some cases, looking at the credits I can
see if anybody I've heard of contributed.  E.g. something
about MIME or mail without JohnK, Keith, or Ned is highly
suspicious.  The sieve vacation draft can't be completely
wrong, it mentions 3834, and Ned is a co-author.

Or 3066bis:  It mentions almost everybody I've ever heard
of in conjunction with I18N, anything I18N without Martin,
JohnK, or Harald would be suspicious.

> It is notably dishonest to try to pass these documents
> off as products of Henry, Russ, et al, without mentioning
> the cooks who spoiled the broth.

If they don't like it they'd say NO, and that would be that.

I didn't propose Bruce (who fixed numerous ABNF issues) or
Ralph (who "terminated" the old -07 WG last call), because
I guess that they'd be indeed not happy with the result as
it is.  In the case of Ralph I hope that he likes it a bit
better than the old -07.

All controversial points are compromises between "common
message format first" and "common practice first", and I've
always supported the latter as stated in s-o-1036   If you
would prefer the former with CFWS and NO-WS-CTL everywhere
it's okay, but that would be very different from...

> If these documents had been left to Henry, Ned, and Russ,
> I'm sure they would have turned out much differently, and
> be relevant.

...I've always supported Henry and Russ whereever they agreed,
or only one of them offered an opinion.  IIRC the complaints-
URL (instead of an address) was the only exception.

It's excessively rude to say that this was "dishonest, sly,
manipulative, and spoiling the broth".  Actually I think that
the "broth" is rather good.  If the "Injection-Info" is a bit
"gibbous" then that's a necessary side-effect of 2231.  There
just was no complete better proposal, "Bruce and Frank tried"
doesn't count, and if anybody else tried I missed it, because
it was before tho old -07.

No idea who the cooks were before this time, but from my POV
they didn't get the Message-ID right, and that's fixed now -
compatible with NNTP, 2822, 1738, 1036 - as far as possible.

> this one just seemed too sly and manipulative to leave
> without comment.