Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07

From: Alexey Melnikov <[email-masked]>
Date: Wed, 31 May 2006 10:08:40 +0100

Dan Kohn wrote:

> Here are some slightly more substantive proposed changes.  Any of  
> these that are controversial may require a ticket.

This message just summarizes what went into -08 based on input from 
Harald, Charles and myself.

>>    Additionally, Section 3.1.3 updates the [RFC2822] definition of
>>    <msg-id>.
>
> [This is wrong, as this document is not updating RFC 2822.  Here's  
> replacement text:]
>
>    Additionally, Section 3.1.3 specifies a stricter definition of
>    <msg-id> than the syntax used in [RFC2822] Section 3.6.4.

Accepted.

>>    A "newsgroup" is a single news forum, a logical bulletin board,
>>    having a name and nominally intended for articles on a specific
>>    topic.  An article is "posted to" a single newsgroup or several
>>    newsgroups.  When an article is posted to more than one  
>> newsgroup, it
>>    is said to be "crossposted"; note that this differs from posting  the
>>    same text as part of each of several articles, one per newsgroup.
>
> ["logical bulletin board" doesn't mean anything, and so is not a  
> clarifying phrase.  Nominally is not the right word here, as it means  
> "In a nominal manner; by name; in name only; not in reality."   
> Newsgroups are intended to be on a topic in more than name only.   
> Here's a word-smithed version:]
>
>    A "newsgroup" is a single forum having a name and intended for  
> articles on a specific
>    topic.  An article is "posted" to a single newsgroup or  
> "crossposted" to several
>    newsgroups.  Crossposting uses a single article; it is different  
> from posting the
>    same text in different articles to different newsgroups.

Accepted the first sentence.
No changes to definition of "crossposting".

>>    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 can be made much more clear as an ordered list:]
>
>    An article that uses the obsolete syntax specified in Section 4 of
>    [RFC2822] is NOT conformant to this specification, except for these
>    two cases:
>
>       1) 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.
>
>       2) Articles are conformant if they use the "GMT" <zone>, as  
> specified in
>       Section 3.1.2.

Accepted.

>>    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.
>
> [I would remove these three sentences, as their meaning is implicit,  
> and yet goes unstated, in every IETF standard.  "handling of non- 
> conformant articles" must by definition be outside the scope of a  
> document that only specifies what a conformant article is.]

Rejected as per comments from Charles/Harald.

>>    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.
>
> [I believe these two paragraphs should be deleted, as they are  
> confusing and don't add any new information.  Specifically, they seem  
> redundant to the opening sentence of this section:  "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."]

Rejected as per comments from Charles/Harald.

>>          NOTE: This means that no header field body defined by or
>>          referenced by this document can be empty.  As a result, this
>>          document updates the <unstructured> construct from Section
>>          3.2.6 of [RFC2822] as follows:
>
>
> ["updates" means that RFC 2822 is being updated, but that is not case  
> here.]
>
>         NOTE: This means that no header field body defined by or
>         referenced by this document can be empty.   As a result,
>         rather than using the <unstructured> syntax from Section 3.2.6
>         of [RFC2822], this document uses a stricter definition:

Accepted.

>>    o  Compliant software MUST NOT generate (but MAY accept) header
>>       fields of more than 998 octets.  This is the only limit on the
>>       length of a header field prescribed by this standard.  However,
>>       specific rules to the contrary may apply in particular cases  (for
>>       example, according to [RFC2047] lines of a header field  
>> containing
>>       encoded-words are limited to 76 octets).  [I-D.ietf-usefor- 
>> useage]
>>       includes suggested limits for convenience of display by user
>>       agents.
>
> [ I think this paragraph should be removed.
>
> The first sentence is redundant with RFC2822, Section 2.1.1, which  
> specified line lengths at 998 but says that implementations "would do  
> well to handle an arbitrarily large number of characters".   The  
> second sentence seems to override the "SHOULD be no more than 78  
> characters", however that's contradictory with the opening paragraph  
> of this section about this standard being "less permissive".  The  
> last two sentences are only necessary because the paragraph is sort  
> of departing from RFC 2822, but not really.
>
> If the purpose is just to remove the 78 character line limit, I would  
> say:]
>
>    Section 2.1.1 of [RFC2822] says:
>
>       "Each line of characters MUST be no more than 998 characters,
>       and SHOULD be no more than 78 characters, excluding the CRLF."
>
>    For news articles, this restriction is loosened as follows:
>
>       "Each line of characters MUST be no more than 998 characters,
>       and MAY be line wrapped at 78 characters, excluding the CRLF."
>
> [But I don't think changing a SHOULD to a MAY is worthwhile, so I  
> would just kill the paragraph.]

No change. The error spotted during subsequent discussion still needs to 
be fixed.

>>          NOTE: There is NO restriction on the number of lines into  
>> which
>>          a header field may be split, and hence there is NO  restriction
>>          on the total length of a header field (in particular it  
>> may, by
>>          suitable folding, be made to exceed the 998 octets  restriction
>>          pertaining to a single header line).
>
> This note should also be removed, as it's implicit in the RFC 2822  
> definition of header folding.

No change as per comment from Harald.

>>    o  The character set for header fields is US-ASCII.  Where the  
>> use of
>>       non-ASCII characters is required, they MUST be encoded using the
>>       MIME mechanisms defined in [RFC2047] and [RFC2231].
>
> This paragraph does not belong here, as these rules are the same as  
> RFC 2822 et al, rather than being an exception to them.  Further, it  
> is redundant with the subsequent section, and so can either be  
> deleted, or added there for emphasis.  (I would recommend deletion.)

No change as per comment from Harald.

> Thus, the only restrictions beyond RFC 2822 in this section 2.2 are  
> requiring a colon space and no whitespace-only headers.  This matters  
> because all of the header definitions below reference back to this  
> section.
>
>>    Most of these headers are mainly of interest to news servers, and
>>    news servers often need to process these fields very rapidly.
>
> I would remove this whole sentence, or at least the second half, as  
> it's superfluous to the specification.

Additional explanation added to the quoted sentence as per discussion 
that followed.

>>    The MIME header fields MIME-Version, Content-Type, Content- Transfer-
>>    Encoding, Content-Disposition, and Content-Language are used in  news
>>    articles in the same circumstances and with the same meanings as
>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with the  
>> added
>>    restrictions detailed in Section 2.2.
>
> It's inconsistent that the ABNF for RFC 2822 headers has been  
> repeated throughout the spec (with the addition of : SP), but not  
> these headers.  My first choice would be to remove all ABNF from the  
> spec that only differ in showing the ": SP" (although they might  
> still be included in an appendix).  Alternatively, these headers  
> should be specified.

No change, as per subsequent discussion.

>>       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.
>
> [Rewritten:]
>
> NOTE:  Since clocks on various agents may not be in sync, the <date- 
> time> in this header field may not be later than the Date header  
> field, as would be expected.  Agents SHOULD use the <date-time> they  
> believe is correct when adding Inject-Info but SHOULD NOT alter the  
> pre-existing Date field.

Accepted.

>>    The syntax is the same as that of the Newsgroups header field
>>    (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, user agents MAY choose to recognize  
>> case-
>>    insensitive forms such as "Poster".
>
> [This is wordy with mismatched parentheses.  How about:]
>
>    The syntax is the same as that of the Newsgroups header field
>    (Section 3.1.5), with the exception that the keyword "poster"
>    requests that followups should be mailed to the article's reply
>    address rather than posted.  Agents MUST generate the
>    keyword "poster" in lower-case, but MAY choose to recognize
>    case-insensitive forms such as "Poster".

Accepted.

>>    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.
>
> Rewritten:
>
>    Other <attribute>s SHOULD NOT be used unless defined in extensions
>    to this standard.  If non-standards-based <attribute>s are used,  they
>    MUST begin with an "x-".

Accepted.

>>    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 <parameter>s), and that comments are only used
>>    following the last <parameter>.
>
>
> [Rewritten:]
>
>    Although comments and folding of white space are permitted  throughout
>    the Injection-Info header field, folding SHOULD NOT be
>    used within any <parameter>.  Folding SHOULD only occur before or  
> after
>    the ";" separating <parameter>s, and comments SHOULD only be used
>    following the last <parameter>.

Accepted.

>>    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.
>
>    The header fields listed above are documented for historical  purposes
>    only.  These header fields MUST NOT be generated and SHOULD be  
> ignored.

Accepted.