Subject: draft-ietf-usefor-usefor-06

From: Ken Murchison <[email-masked]>
Date: Fri, 16 Dec 2005 15:07:55 -0500

I just submitted the -06 draft to the I-D editor.  Attached are the 
diffs between -05 and -06 for those that are interested.

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University
--- /home/ken/Desktop/draft-ietf-usefor-usefor-05.unpg	2005-12-15 14:59:16.000000000 -0500
+++ /home/ken/Desktop/draft-ietf-usefor-usefor-06.unpg	2005-12-16 14:44:25.000000000 -0500
@@ -3,16 +3,16 @@

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

                          Netnews Article Format
-                      draft-ietf-usefor-usefor-05
+                      draft-ietf-usefor-usefor-06
 
 Status of this Memo
 
@@ -37,7 +37,7 @@
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on January 2, 2006.
+   This Internet-Draft will expire on June 19, 2006.
 
 Copyright Notice
 
@@ -53,9 +53,44 @@
 
 Note to the RFC Editor
 
-   The normative reference to RFC 2234 may be replaced by
-   draft-crocker-abnf-rfc2234bis should it reach RFC status before this
-   one.
+   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).
+
+   o  Resolved ticket #1046 (MIME boundary security considerations).
+
+   o  Addressed ticket #1047 (Path header field delimiters and
+      components) using Harald's suggested text -- Still an open issue.
+
+   o  Resolved ticket #1052 (diffs from RFC 2822).
+
+   o  Resolved ticket #1053 (relationship to RFC 2822).
+
+   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  Miscellaneous editorial changes.
+
 
 Changes since draft-ietf-usefor-usefor-04
 
@@ -173,12 +208,7 @@
 
 Issues to be addressed
 
-   o  MIME boundary security considerations.
-
-   o  Path header field delimiters and components.
-
-   o  Complete appendixes for changes from RFC 1036 and differences from
-      RFC 2822.
+   o  Ticket #1047: Path header field delimiters and components.
 
    o  IANA considerations (the Klyne message header registry is now
       official as RFC 3864)?.
@@ -234,7 +264,7 @@
      6.1.  Normative References
      6.2.  Informative References
    Appendix A.  Acknowledgements
-   Appendix B.  Differences from RFC 1036
+   Appendix B.  Differences from RFC 1036 and its derivatives
    Appendix C.  Differences from RFC 2822
    Authors' Addresses
    Intellectual Property and Copyright Statements
@@ -268,9 +298,9 @@
    This document focuses on the syntax and semantics of Netnews
    articles.  [USEPRO] is also a standards-track document, and describes
    the protocol issues of Netnews articles, independent of transport
-   protocols such as [NNTP].  An best common practice document,
-   [USEAGE], describes implementation recommendations to improve
-   interoperability and usability.
+   protocols such as [NNTP].  A best common practice document, [USEAGE],
+   describes implementation recommendations to improve interoperability
+   and usability.
 
    This specification is intended as a definition of what article
    content format is to be passed between systems.  Though some news
@@ -309,11 +339,11 @@
    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 "posting agent" which posted it or,
-   failing that, by the "injecting agent".  It distinguishes the article
+   article, usually supplied by the "user agent" which posted it or,
+   failing that, by the "news server".  It distinguishes the article
    from every other article ever posted anywhere.  Articles with the
    same message identifier are treated as if they are the same article
-   regardless of any differences in the body or header.
+   regardless of any differences in the body or header fields.
 
    A "newsgroup" is a single news forum, a logical bulletin board,
    having a name and nominally intended for articles on a specific
@@ -328,40 +358,32 @@
    implemented partially or entirely in software.
 
    A "poster" is the person or software that composes and submits a
-   possibly compliant article to a "posting agent".  The poster is
+   possibly compliant article to a "user agent".  The poster is
    analogous to [RFC2822]'s author.
 
-   A "posting agent" is the software that assists posters to prepare
-   proto-articles, in compliance with this standard.  The proto-article
-   is then passed on to an "injecting agent" for final checking and
-   injection into the news stream.  If the article is not compliant, or
-   is rejected by the injecting agent, then the posting agent informs
-   the poster with an explanation of the error.
-
    A "reader" is the person or software reading news articles.
 
-   A "reading agent" is software which presents articles to a reader.
-
    A "followup" is an article containing a response to the contents of
    an earlier article, its "precursor".  Every followup includes a
    "References" header field identifying that precursor (but note that
    non-followup articles may also use a References header field).
 
-   A "followup agent" is a combination of reading agent and posting
-   agent that aids in the preparation and posting of a followup.
-
-   Posting, reading and followup agents (which are usually just
-   different services provided by the same piece of software) are known
-   collectively as "user agents".
-
-   An "injecting agent" takes the finished article from the posting
-   agent (often via the [NNTP] "post" command) performs some final
-   checks and passes it on to a relaying agent for general distribution.
-
    A "control message" is an article which is marked as containing
-   control information; a relaying or serving agent receiving such an
-   article may (subject to the policies observed at that site) take
-   actions beyond just filing and passing on the article.
+   control information; a news server receiving such an article may
+   (subject to the policies observed at that site) take actions beyond
+   just filing and passing on the article.
+
+   A "news server" is software that may accept articles from a "user
+   agent", and/or make articles available to user agents, and/or
+   exchange articles with other news servers.
+
+   A "user agent" is software that may help posters submit proto-
+   articles to a news server, and/or fetch articles from a news server
+   and present them to a reader, and/or assist the reader in creating
+   articles and followups.
+
+   The generic term "agent" is used when describing requirements that
+   apply to both user agents and news servers.
 
 1.6.  Structure of This Document
 
@@ -381,14 +403,37 @@
 
 2.1.  Base
 
-   News articles MUST conform to the syntax specified in Section 3 of
-   [RFC2822].  Netnews agents MAY also accept the obsolete syntax
-   specified in Section 4 of [RFC2822], but they MUST NOT generate
-   productions of such syntax.
-
-   Agents MUST accept the obs-phrase construct (use of a phrase like
-   "John Q. Public" without the use of quotes, see [RFC2822] section
-   4.1) but they MUST NOT generate productions of such syntax.
+   An article is said to be conformant to this specification if it
+   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
+   [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
+   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
+   articles.
+
+   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
@@ -415,9 +460,9 @@
 
    o  All agents MUST generate header fields so that at least one space
       immediately follows the ':' separating the header field name and
-      the header field body (for compatibility with deployed software).
-      News agents MAY accept header fields which do not contain the
-      required space.
+      the header field body (for compatibility with deployed software,
+      including [NNTP] servers).  News agents MAY accept header fields
+      which do not contain the required space.
 
    o  Every line of a header field body (including the first and any
       that are subsequently folded) MUST contain at least one non-
@@ -459,7 +504,7 @@
 
    For the purposes of Section 5 of [RFC2047], all header fields defined
    in Section 3 of this standard are to be considered as "extension
-   message header fields" (insofar as they are not already considered
+   message header fields" (insofar as they are not already so considered
    under the existing Email standards), permitting the use of [RFC2047]
    encodings within any <unstructured> header field, or within any
    <comment> or <phrase> permittted within any structured header field.
@@ -492,6 +537,25 @@
 
    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.
+
 3.1.  Mandatory Header Fields
 
    Each news article conformant with this specification MUST have
@@ -514,11 +578,11 @@
    Therefore, agents MUST accept <date-time> constructs which use the
    "GMT" zone.
 
-   from            =  "Date:" SP date-time CRLF
+   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>.
+      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
@@ -533,12 +597,13 @@
    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
-   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.
+   and standards [RFC0977] 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
 
@@ -600,14 +665,14 @@
       case-sensitive (and thus, once created, are not to be altered
       during subsequent transmission or copying)
 
-   This is to simplify processing by relaying and serving agents and to
-   ensure interoperability with existing implementations and compliance
-   with [NNTP].  Thus, whereas under [RFC2822] the following <msg-id>s
-   would be considered semantically equivalent,
-
-   <[email-masked]>
-   <"abcd"@example.com>
-   <"ab\cd"@example.com>
+   This is to simplify processing by news servers and to ensure
+   interoperability with existing implementations and compliance with
+   [NNTP].  Thus, whereas under [RFC2822] the following <msg-id>s would
+   be considered semantically equivalent,
+
+   <[email-masked]>
+   <"ab.cd"@example.com>
+   <"ab.\cd"@example.com>
 
    only the first of them is syntactically permitted by this standard,
    and hence a simple comparison of octets will always suffice to
@@ -622,8 +687,8 @@
    fashion.  Implementations MUST NOT generate two Message-IDs where the
    only difference is the case of characters in the <id-right> part.
 
-   If domain literals are used, the syntax found in Section 4.1.3 of
-   [RFC2821] is RECOMMENDED.
+   When generationg a <msg-id>, implementations SHOULD use a domain name
+   as the <id-right>.
 
       NOTE: Section 3.6.4 of [RFC2822] recommends that the <id-right>
       should be a domain name or a domain literal.  Domain literals are
@@ -655,11 +720,6 @@
 
    component-char  =  ALPHA / DIGIT / "+" / "-" / "_"
 
-      NOTE: Observe that the syntax does not allow comments within the
-      Newsgroups header field; this is to simplify processing by
-      relaying and serving agents which have a requirement to process
-      this header field extremely rapidly.
-
    Folding the Newsgroups header field over several lines has been shown
    to harm propagation significantly.  Folded Newsgroups header fields
    SHOULD NOT be generated, but MUST be accepted.
@@ -671,95 +731,108 @@
       NOTE: All-digit components conflict with one widely used storage
       scheme for articles.  Mixed case groups cause confusion between
       systems with case sensitive matching and systems with case
-      insensitive matching of newsgroup names.
+      insensitive matching of <newsgroup-name>s.
 
-   Components beginning with underline ("_") are reserved for use by
-   future versions of this standard and MUST NOT be generated by posting
+   <component>s beginning with underline ("_") are reserved for use by
+   future versions of this standard and MUST NOT be generated by user
    agents (whether in Newsgroups header fields or in newgroup control
-   messages [USEPRO]).  However, such names MUST be accepted by relaying
-   and serving agents.
+   messages [USEPRO]).  However, such names MUST be accepted by news
+   servers.
 
-   Components beginning with "+" and "-" are reserved for private use
-   and MUST NOT be generated by posting agents (whether in Newsgroups
+   <component>s beginning with "+" and "-" are reserved for private use
+   and MUST NOT be generated by user agents (whether in Newsgroups
    header fields or in newgroup control messages [USEPRO]) without a
    private prior agreement to do so.  However, such names MUST be
-   accepted by relaying and serving agents.
+   accepted by news servers.
 
-   The following newsgroup names are reserved, and MUST NOT be used as
+   The following <newsgroup-name>s are reserved, and MUST NOT be used as
    the name of a newsgroup:
 
-   o  Groups starting with the component "example"
+   o  Groups whose first (or only) component is "example"
 
    o  The group "poster"
 
-   The following newsgroup names have been used for specific purposes in
-   various implementations and protocols, and MUST therefore 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&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.
 
-      Groups starting with the component "to"
+      Groups whose first (or only) component is "to"
 
-      Groups starting with the component "control"
+      Groups whose first (or only) component is "control"
 
-      Groups containing the component "all"
+      Groups which contain (or consist only of) the component "all"
 
-      Groups containing the component "ctl"
+      Groups which contain (or consist only of) the component "ctl"
 
       The group "junk"
 
-      NOTE: The list above includes the groups "to", "control", "all",
-      and "ctl".
+      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 relaying agents 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 statistics.
+   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
+   statistics.
 
    path            =  "Path:" SP path-list CRLF
 
    path-list       =  [FWS]
-                      *( ( path-identity / path-keyword ) [FWS]
-                      path-delimiter [FWS] )
+                      *( ( path-identity / path-keyword /
+                           path-diagnostic ) [FWS]
+                         path-delimiter [FWS] )
                       tail-entry [FWS]

    path-identity   =  ( ALPHA / DIGIT )
-                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
+                      *( ALPHA / DIGIT / "-" / "." / "_" )
+
+   path-keyword    =  "POSTED" / "MISMATCH"
 
-   path-keyword    = "POSTED" / "MISMATCH"
+   path-diagnostic =  1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
 
    tail-entry      =  path-identity
 
    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 <keyword> "POSTED"
+   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
    article (whereas the <path-delimiter> "!" implies no such claim).
-   The <keyword> "MISMATCH" indicates that the agent to its right failed
-   to be so verified.  The full procedure for constructing a Path header
-   field as well as the specific format and use of <path-identity> and
-   <tail-entry> are discussed in [USEPRO].
-
-      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).
+   The <path-keyword> "MISMATCH" indicates that the agent to its right
+   failed to be so verified.
 
       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
+   ":" as a <path-delimiter> and have neighbors whose names have 4 or
+   fewer characters, and where all the characters are valid HEX digits.
+
 3.2.  Optional Header Fields
 
    None of the header fields appearing in this section is required to
@@ -794,21 +867,26 @@
    The Injection-Date header field contains the date and time that the
    article was injected into the network.  Its purpose is to prevent the
    reinjection into the news stream of "stale" articles which have
-   already expired by the time they arrive at some relaying or serving
-   agent.
+   already expired by the time they arrive at some news server.
 
-   injection-date  =  "Injection-Date:" SP date-time CRLF
+   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 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 injecting
-      agent should just insert the correct time as it sees it.
+   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
    undocumented "NNTP-Posting-Date" header field, whose use is now
@@ -850,8 +928,8 @@
    (Section 3.1.5, with the exception that the keyword "poster" (which
    is always lowercase) requests that followups should be mailed to the
    article's reply address rather than posted.  Although the keyword
-   "poster" is case-sensitive, followup agents MAY choose to recognize
-   case-insensitive forms such as "Poster".
+   "poster" is case-sensitive, user agents MAY choose to recognize case-
+   insensitive forms such as "Poster".
 
 3.2.4.  Expires
 
@@ -861,8 +939,9 @@
 
    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 subject.
+   See the remarks under Section 3.1.2 regarding the syntax of <date-
+   time> and the requirements and recommendations to which it is
+   subject.
 
 3.2.5.  Control
 
@@ -937,7 +1016,8 @@
 
    The Approved header field indicates the mailing addresses (and
    possibly the full names) of the persons or entities approving the
-   article for posting.
+   article for posting.  Its principal uses are in moderated articles
+   and in group control messages [USEPRO].
 
    approved        =  "Approved:" SP mailbox-list CRLF
 
@@ -960,9 +1040,9 @@
 3.2.11.  Xref
 
    The Xref header field indicates where an article was filed by the
-   last serving agent to process it.  The article locations are used to
-   keep track of crossposted articles so that reading agents serviced by
-   a particular serving agent can mark such articles as read.
+   last news server to process it.  The article locations are used to
+   keep track of crossposted articles so that user agents serviced by a
+   particular news server can mark such articles as read.
 
    xref            =  "Xref:" SP [FWS] server-name
                       1*( FWS location ) [FWS] CRLF
@@ -976,12 +1056,12 @@
                       ; except '(' and ';'
 
    The <server-name> is included so that software can determine which
-   serving agent generated the header field.  The locations specify what
+   news server generated the header field.  The locations specify what
    newsgroups the article was filed under (which may differ from those
    in the Newsgroups header field) and where it was filed under them.
-   The exact form of an article-locator is implementation-specific.
+   The exact form of an <article-locator> is implementation-specific.
 
-      NOTE: The traditional form of an article-locator (as required by
+      NOTE: The traditional form of an <article-locator> (as required by
       [NNTP]) is a decimal number, with articles in each newsgroup
       numbered consecutively starting from 1.
 
@@ -1020,13 +1100,13 @@
    product-version =  [CFWS] token
 
    This header field MAY contain multiple product-tokens identifying the
-   agent and any subproducts which form a significant part of the
-   posting agent, listed in order of their significance for identifying
-   the application.
+   user agent and any subproducts which form a significant part of it,
+   listed in order of their significance for identifying the
+   application.
 
       NOTE: Some of this information has previously been sent in non-
       standardized header fields such as X-Newsreader, X-Mailer,
-      X-Posting-Agent, X-Http-User-Agent, and others.  Once an agent
+      X-Posting-Agent, X-Http-User-Agent, and others.  Once a user agent
       uses User-Agent, it should have no need to send these non-standard
       header fields.
 
@@ -1037,87 +1117,94 @@
 
 3.2.14.  Injection-Info
 
-   The Injection-Info header field provides information 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.
+   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] ";" [CFWS] inj-info-param )
-                      [CFWS] CRLF
-
-   inj-info-param  =  post-host-param /
-                      post-acct-param /
-                      sender-param /
-                      logging-param /
-                      complainto-param /
-                      ext-param
-                      ;; At most one of "post-host-param",
-                      ;; "post-acct-param", "sender-param",
-                      ;; "logging-param" or "complainto-param"
-                      ;; is allowed.
+                      [CFWS] *(';' parameter) CRLF
 
-   ext-param       = parameter
-   [[Should also allow for x-attributes?]]
+      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>
 
-   post-host-param =  "posting-host" "=" host-value
+   where
 
-   host-value      =  dot-atom / [ dot-atom ":" ]
+   host-value      =  dot-atom-text / [ dot-atom-text ":" ]
                       ( IPv4address / IPv6address ) ;  see [RFC 3986]
 
-   post-acct-param =  "posting-account" "=" value
-
-   sender-param    =  "sender" "=" sender-value
-
    sender-value    =  mailbox / "verified"
 
-   logging-param   =  "logging-data" "=" value
-
-   complainto-param=  "mail-complaints-to" "=" address-list
-
+      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
+      example:
+
+   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 ";"
-   separating those parameters), and that comments are only used
-   following the last parameter.
+   not used within any <parameter> (but only before or after the ";"
+   separating those <parameter>s), and that comments are only used
+   following the last <parameter>.
 
       NOTE: Some of this information has previously been sent in non-
       standardized header fields such as NNTP-Posting-Host, X-trace,
-      X-Complaints-To, and others.  Once an injecting agent 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 injecting
-   agent 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.
+      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.
 
-   The "posting-account" parameter identifies the source from which the
-   injecting agent received the article.  For security reasons, it
+   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 injecting agent.
+   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
+   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
    the article, or in the From header field if the Sender header field
-   is absent, is correct).  If an injecting agent can verify sender of
-   an article, it SHOULD use this parameter in favour of the "posting-
-   account" parameter.
+   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
+   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 injecting
-   agent.
+   determined by reference to logging information kept by the news
+   server.
 
-   The "mail-complaints-to" parameter specifies mailbox(es) for sending
-   complaints concerning the behavior of the poster of the article.
+   The "mail-complaints-to" <parameter> specifies mailbox(es) for
+   sending complaints concerning the behavior of the poster of the
+   article.
 
 3.3.  Obsolete Header Fields
 
@@ -1128,11 +1215,11 @@
    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 relaying agent
+   Relay-Version contained version information about the news server
    that last processed the article.  Posting-Version contained version
-   information about the posting agent that posted the article.  Date-
-   Received contained the date when the last relaying agent to process
-   the article first saw it (in a slightly nonstandard format).
+   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).
 
    In addition, this present standard obsoletes certain header fields
    defined in [Son-of-1036]:
@@ -1167,8 +1254,8 @@
    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
-   posting agent.
+   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
@@ -1181,8 +1268,8 @@
 
    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 names for use in header
-   fields is not addressed in this document.
+   the generation of internationalized <newsgroup name>s for use in
+   header fields is not addressed in this document.

 5.  Security Considerations
@@ -1205,6 +1292,19 @@
    that generate message identifiers for news articles SHOULD ensure
    that they are unpredictable.
 
+   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
+
+   Such differences in parsing may be used as part of an attack.
+
 
 6.  References
 
@@ -1242,9 +1342,6 @@
    [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.
 
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
    [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
               April 2001.
 
@@ -1264,6 +1361,12 @@
    [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.
 
@@ -1305,54 +1408,90 @@
    Melnikov.

-Appendix B.  Differences from RFC 1036
+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
+      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.
+
+      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.
+
+      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
+      Archive, Injection-Info and User-Agent, leading to increased
+      functionality.
+
+      Certain header fields, notably Lines, have been made obsolete
+      (Section 3.3).
+
+      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, specifically [RFC2822].
+   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
       field name.
 
-      A more restricted syntax of msg-id (to be used by the Message-ID,
-      References, and Supersedes header fields).
+      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.
 
       Comments are not allowed in the Message-ID header field.
 
-      The CFWS between msg-ids in the References header field is not
+      The CFWS between <msg-id>s in the References header field is not
       optional.
 
-      An <unstructured> header field body MUST contain at least one non-
-      whitespace character (header fields such as Subject can not be
-      empty).
+      It is legal for a parser to not accept obsolete syntax, except
+      that:
 
-      The <obs-phrase> construct MUST be accepted.
+         The <obs-phrase> construct MUST be accepted.
 
-      The obsolete timezone "GMT" MUST be accepted in the Date header
-      field.
+         The obsolete <zone> "GMT" MUST be accepted within a <date-
+         time>.
 
-      The length of a msg-id MUST NOT exceed 250 octets.
+      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)
-   Oceana Matrix Ltd.
-   21 Princeton Place
-   Orchard Park, NY  14127
+   Carnegie Mellon University
+   5000 Forbes Avenue
+   Cyert Hall 285
+   Pittsburgh, PA  15213
    US
 
-   Phone: +1 716 662 8973
-   Email: [email-masked]
+   Phone: +1 412 268 2638
+   Email: [email-masked]

    Charles H. Lindsey

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 17 Dec 2005 00:02:07 +0100

Thank you, Ken!

--On fredag, desember 16, 2005 15:07:55 -0500 Ken Murchison 
<[email-masked]> wrote:

> I just submitted the -06 draft to the I-D editor.  Attached are the diffs
> between -05 and -06 for those that are interested.
>
> --
> Kenneth Murchison
> Systems Programmer

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Dec 2005 03:17:24 +0100

> +   RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and

No issue, but 4234 is published: s/2234/4234/g

> +   o  Removed RFC 0821 as a normative reference.

JFTR: 2821.

>     o  IANA considerations (the Klyne message header registry is now

Oops, -05 had no IANA considerations at all, that's wrong.

> +   Appendix B.  Differences from RFC 1036 and its derivatives

Apparently Henry dropped his plan to publish s-o-1036 as
"historic", that's sad.

> +   A best common practice document, [USEAGE], describes

Maybe s/, [USEAGE], describes/ will describe/ - I won't bet
that it will be finished, let alone soon or as a BCP, and an
approved USEFOR / USEPRO pair blocked in the RFC editor queue
isn't what "we" (TINW) want.

>        synonym for what [RFC2822] calls "header field". 

Actually it's s/Older Netnews/Other/ (JFTR, no issue)

> +   The following header fields defined in this document do not allow
[...]
> +   This also applies to the following header field defined in [RFC2822]:

Add Message-ID to the "defined in this document" set, and get
rid of the 2822-set:  Our Message-ID is still different from
(2)822, and it's defined here.  You have the full discloure

> +   and standards [RFC0977] might have trouble with the full range of 

BTW, often you say [NNTP], here you have [RFC0977], how about
[NNTP] everywhere ?  That would also eliminate the instructions
for the RFC editor (together with s/2234/4234/ - see above).

> +   The following <newsgroup-name&gts have been used for specific

Missing semicolon in the source....^^^

> +      the Subject header field.

Somehow we managed to mention "cmsg" nowhere - it should at
least show up in appendix B (differences from 1036).

> +                      *( ( path-identity / path-keyword /
[...]

I'll look at the <path-list> etc. ABNF in the complete draft.

> -      used as a mail address for the sender).

What's wrong with that note ?

> +   fewer characters, and where all the characters are valid HEX digits.

Seconded, no amount of MUSTard and weird colon encoding schemes
could obfuscate the fact that this is just ugly whatever we do.

> +   time> and the requirements and recommendations to which it is

With old xml2rfc versions a <vspace /> could enforce a line
break before <date-time>.  Now &lt;date-&wj;time&gt; might do
it, or better use &lt;date&nbhy;time&gt; (non-breaking-hyphen).

> +   time> and the requirements and recommendations to which it is

Dito, replace it globally.

>                       ; except '(' and ';'

Oops, why on earth do we exclude "(" from article-locator ?
That's probably an obsolete CFWS oddity, proposed new ABNF: 

-  article-locator =  1*( %x21-27 / %x29-3A / %x3C-7E )
-                     ; US-ASCII printable characters
-                     ; except '(' and ';'
+  article-locator =  1*( %x21-3A / %x3C-7E )
+                     ; VCHAR excl. colon ":"

>     sender-value    =  mailbox / "verified"

One of the hidden mines, let's see what happens, it deserves a
[Discuss].

> +   extensions to this standard.

Could be also a MUST NOT as far as I'm concerned, if they want
new tricks let them create a IANA registry for their funny
inventions.

> it is RECOMMENDED that folding is
[...]
> +   following the last <parameter>.

The former is also a general rule, should we add a pointer to
2822 2.2.3 ?  It's a 2822-SHOULD, not some red-is-green excuse.

> +      <parameter> may provide additional information about true origin

Missing article or DEnglish on my side.

>     SHOULD be in a cryptic notation understandable only by the
[...]
> +   administrator of the news server.

How about s/For security reaons, it/It/ ?  It could be also for
privacy reasons, and in Germany it could be for legal reasons.

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

After talking with his legal department.  In other words, this
can't be a SHOULD, pleae delete this statement.

> +   sending complaints concerning the behavior of the poster of the

Obvious, doesn't need an explanation.

> +   the generation of internationalized <newsgroup name>s for use in

Missing "-" (or rather &nbhy; ;-)

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

You need a leading space in the second line for the folding.
If it's too long replace xyzzy by something that's shorter.

>                Specifications: ABNF", RFC 2234, November 1997.

4234

> +              Protocol", RFC 977, February 1986.

See above.

> +      There are numerous other small changes, clarifications and

The removal of Subject: cmsg is not a small change, it's among
the few things why we bother to create this future "1036ter".

Otherwise it's ready, isn't it ?  I haven't checked the ABNF
for the path.
                      Tnx & bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Dec 2005 16:29:35 GMT

>Apparently Henry dropped his plan to publish s-o-1036 as

He suddenly vanished from this list (and all his other usual haunts) and
his personal domain (spsystems.net) went dead.

I just Googled for him, and it seems that he posted nothing to Usenet
between July 27th and October 11th, at which point his signature started
to contain

spsystems.net is temporarily off the air; | Henry Spencer 
mail to henry at zoo.utoronto.ca instead.  | [email-masked]

So I shall email him now to see where he is at. I would certainly like to
be able to get rid of those two historical appendices, which are simply
verbatim copies from s-o-1036.

>Actually it's s/Older Netnews/Other/ (JFTR, no issue)

Indeed, because the new [NNTP] also does it.

>(2)822, and it's defined here.  You have the full discloure

I think we have to accept that the Message-ID header comes from RFC 2822,
although we have given it a good mauling.

>> +   and standards [RFC0977] might have trouble with the full range of

I dislike that convention of writing [RFC0977] rather than [RFC977]. Yes,
I know why it is done (getting the References sorted sensibly - but I
would rather fix that by hand by negotiation with the RFC-Editor after
last call).

>for the RFC editor (together with s/2234/4234/ - see above).

Yup. BTW, the new [NNTP] is only waiting for the new SASL standard, so
that the RFC-Editor doesn't have any dangling References. Is Alexey
listening?

>Missing semicolon in the source....^^^

Yup.

>least show up in appendix B (differences from 1036).

No, because is is not a matter of syntax. The whole ctl/cmsg mess is
thoroughly covered in USEPRO, with strong discouragement for its continued
use.

>What's wrong with that note ?

I agree. Please can we have it back?

>That's probably an obsolete CFWS oddity, proposed new ABNF: 

Yes, it was for comments.

OTOH, there may be agents out there that strip comments from all
unstructured headers without looking first to see that they are doing, so
it would probably be safer to leave the restriction in place.

>new tricks let them create a IANA registry for their funny

There would be no interoperability, so I don't think we can justify
"MUST". We never went as far as setting up an IANA Registry for the
<parameter>s in this new header. If you want it done (technically, there is
no reason why not) they please propose it.

>2822 2.2.3 ?  It's a 2822-SHOULD, not some red-is-green excuse.

Actually, it goes further than that rule in RFC 2822, but I have no problem
with adding a pointer.

>Missing article or DEnglish on my side.

Yup.

>privacy reasons, and in Germany it could be for legal reasons.

Or you could say "For security and other reasons,". I have no problem
either way.

>can't be a SHOULD, pleae delete this statement.

No, the WG fought long and hard between those who wanted all relevant
tracing information exposed, so that malefactors could be caught, and
those who wanted to protect the privacy of posters. The upshot was an
agreed paragraph setting out the pros and cons, which eventually got moved
to USEAGE. That is the proper place to discuss this.

>Obvious, doesn't need an explanation.

It is usualy to describe (however briefly) the meaning of all features
introduced by the syntax.

>Missing "-" (or rather &nbhy; ;-)

Yup.

>If it's too long replace xyzzy by something that's shorter.

Yup.

>the few things why we bother to create this future "1036ter".

Ken's 1036-changes text is largely taken from USEPRO. But there are a few
items that will still remain in USEPRO because they relate to the
protocol, or to the syntax of control messages. This is one of them.

-- 
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: Ken Murchison <[email-masked]>
Date: Mon, 19 Dec 2005 13:01:30 -0500

> No issue, but 4234 is published: s/2234/4234/g

Fixed.

>>+   o  Removed RFC 0821 as a normative reference.

Fixed.

> Actually it's s/Older Netnews/Other/ (JFTR, no issue)

Fixed.

> for the RFC editor (together with s/2234/4234/ - see above).

Fixed.

> Missing semicolon in the source....^^^

Fixed.

> What's wrong with that note ?

Editorial mistake.  Its been returned to the document.

> Dito, replace it globally.

Fixed.

> Missing article or DEnglish on my side.

Fixed.

> privacy reasons, and in Germany it could be for legal reasons.

Using Charles' suggested text.

> Missing "-" (or rather &nbhy; ;-)

Fixed.

> If it's too long replace xyzzy by something that's shorter.

Fixed.

>>+              Protocol", RFC 977, February 1986.

Fixed.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 20 Dec 2005 01:40:59 +0100

Charles Lindsey wrote:

> So I shall email him now to see where he is at.

Thanks, I hope he's well.  Of course we can reference s-o-1036
without historic RFC, but I'd prefer the original (2002?) plan.

---
> Indeed, because the new [NNTP] also does it.

Not only [NNTP], I saw "headers" in another RFC, completely
unrelated to NetNews.  If necessary I can dig for it.

---
> I think we have to accept that the Message-ID header comes
> from RFC 2822, although we have given it a good mauling.

Well, I don't accept this, because the 2822 Message-ID doesn't
reflect common practice.  We explain all details in chapter
3.1.3.  The introduction of chapter 3 just enumerates the set
of header fields not allowing [CFWS], and Message-ID belongs
to this set.

That this is different from 2822 is beside the point in this
enumeration, it's explained in 3.1.3 and again in appendix C.

Telling the same story three tiimes doesn't help.  We should
get rid of these three lines:

+

Curious readers will see this, it's obvious with Message-ID as
last (or first) header field in the "no-CFWS" enumeration.

In hardcore nitpicking mode I'd prefer three lines with three
header fields per line - instead of nine lines, or even twelve
lines with this uncalled for "Message-ID is 2822" subsection.

---
> BTW, the new [NNTP] is only waiting for the new SASL
> standard, so that the RFC-Editor doesn't have any dangling
> References. Is Alexey listening?

They're almost ready as far as I can judge it as lurker.  Sam
refuses to sponsor CRAM-MD5 as DS, but that doesn't affect the
core spec.  OT:  I have a working CRAM-MD5 implementation, can
I just submit an "implementation and interoperability report" ?

---

> No, because is is not a matter of syntax. The whole ctl/cmsg
> mess is thoroughly covered in USEPRO, with strong
> discouragement for its continued use.

It is a syntax issue, we removed the concept of a "structured"
Subject header field.  After discussing "Re: the note between
Do and Mi" for *_years_* in *_thousands_* of articles.  We did
not discuss this because it was funny, it's a major difference
from 1036.  The least we can do is to mention it in appendix B.

---

> Yes, it was for comments.

Then let's get rid of it.  I'm perverse, I try to "see" the
raw "idea" or "concept" behind any ABNF oddity, from <toplabel>
over <id-domain> - some say <id-right> because their concept is
in fact slightly different - down to ")" in <article-locator>.

---
> We never went as far as setting up an IANA Registry for the
> <parameter>s in this new header. If you want it done
> (technically, there is no reason why not) they please propose
> it.

No, I want that those who invent new Injection-Info parameters
go to that trouble, "we" (TINW) don't need this at the moment.

---

>> How about s/For security reaons, it/It/ ?  It could be also
>> for privacy reasons, and in Germany it could be for legal
>> reasons.

> Or you could say "For security and other reasons,". I have no
> problem either way.

Same here.

---

>> After talking with his legal department.  In other words,
>> this can't be a SHOULD, pleae delete this statement.

s/pleae/please/

> No, the WG fought long and hard between those who wanted all
> relevant tracing information exposed, so that malefactors
> could be caught, and those who wanted to protect the privacy
> of posters. The upshot was an agreed paragraph setting out
> the pros and cons, which eventually got moved to USEAGE. That
> is the proper place to discuss this.

The SHOULD makes no technical sense, and it might be illegal in
my country without the prior and explicit consent of the sender.

See also BCP 14 at <http://tools.ietf.org/html/2119#section-6>

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Dec 2005 17:45:12 GMT

>diffs between -05 and -06 for those that are interested.

OK, that has tidied up a lot of the issues that we had agreed, leaving
just #1047 as the main outstanding matter.

So all I have at this moment is some nits (Frank also had some, which I
will not repeat here).

I should now be in a position to produce a new USEPRO draft, consistent
with this latest USEFOR, as a basis for our future work.

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

s/to servers/to news servers/ (since that is now the terminology we use)

>    to harm propagation significantly......

Actually, it is worse than that. Even WSP will break existing usage, and
it is more than "significantly". I think you have to make it clear that
this is a newly introduced feature, hence "MUST accept" but "MUST NOT
generate" (yet, for some value of "yet" :-) ).

>    indicate that at least any addr-spec in the Sender header field of
                                ^^^^^^^^^
                               <addr-spec>

>+      Whitespace is permitted in Newsgroups header fields.

        Whitespace (with the possiility of folding) is permitted in
        Newsgroups header fields (but is not to be generated)

[or similar wording, perhaps even mentioning "MUST NOT.]

It should also be noted that further Differences from 1036 are listed in
USEPRO (notably for the syntax of control messages, which are in USEPRO).

>+      The length of a msg-id MUST NOT exceed 250 octets.
                        ^^^^^^
                       <msg-id>

>+      It is legal for a parser to not accept obsolete syntax, except

Split infinitives can lead to long religious wars :-( . It is usually
safer not to include them.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 21 Dec 2005 14:16:38 -0500

> s/to servers/to news servers/ (since that is now the terminology we use)

Applied.

Fixed.

Fixed.

> safer not to include them.

/not accept/reject/

I'll leave the rest of your comments to Harald, since most, if not all, 
of the text added/replaced in -06 was taken verbatim from the tickets.