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

From: Dan Kohn <[email-masked]>
Date: Mon, 17 Apr 2006 07:54:36 -0700

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

>    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.

>    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.

>    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.

>    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.]

>    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."]

>          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:

>    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.]

>          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.

>    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.)

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.

>    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.

>       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.

>    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".

>    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-".

>    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>.

>    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.

Finally, I think it would highly useful to add an Appendix A with  
example articles the way RFC 2822 does.  The ABNF for <path>, for  
example, is crying out for examples.

            - dan
-- 
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Apr 2006 20:57:45 +0200

Summary:

I don't see any protocol changes being proposed, but have a different 
opinion about what's clearest in a few of these.

>    <msg-id> than the syntax used in [RFC2822] Section 3.6.4.
Doesn't seem controversial to me.
>>    newsgroups.  When an article is posted to more than one newsgroup, it
>>    is said to be "crossposted"; note that this differs from posting the
Doesn't seem controversial to me, but I think the original second 
sentence is clearer than the proposed replacement.
>>    Articles are conformant if they use the "GMT" <zone>, as specified in
>>    Section 3.1.2.
>
This seems noncontroversial to me.
>>    Agents conforming to this specification MUST generate only conformant
>>    articles.
>
> and yet goes unstated, in every IETF standard.  "handling of 
> non-conformant articles" must by definition be outside the scope of a 
Unfortunately the discussion in the WG has shown that in this context, 
those sentences are not self-evident. I would like to keep them.
>>    restrictive than the [RFC2822] grammar.  Articles must conform to the
I think this is an example of saying the same thing twice, but I'd like 
to keep the text.
>         of [RFC2822], this document uses a stricter definition:
Seems OK with me.
>>       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]
> 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.
>
Actually the paragraph as written ("header fields of more than 998 
octets") specifies an absolute limit on a header field, INCLUDING 
folding, not a limit on header field lines. Which is in conflict with 
the next paragraph you quote.

So I think the text you suggest is an improvement.
>
>>          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
Agreed.
>
>>    o  The character set for header fields is US-ASCII.  Where the use of
It's been used as an argument for why (for instance) comments should not 
be permitted in this field. So I'd keep it.
>
>>    The MIME header fields MIME-Version, Content-Type, Content-Transfer-
>>    Encoding, Content-Disposition, and Content-Language are used in news
>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with the added
> 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.
Are there other headers that differ only with the ": SP"? I'm not sure.
Other opinions?
>>       is made for any such discrepancy to be corrected - better that the
> 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 
This language is clearer.
>>    is always lowercase) requests that followups should be mailed to the
>>    "poster" is case-sensitive, user agents MAY choose to recognize case-
Seems an improvement to me.
>>    "x-" MAY be used where the defined ones appear to be unsuitable, but
>    to this standard.  If non-standards-based <attribute>s are used, they
>    MUST begin with an "x-".
Clearer, in my opinion.
>
>
>>    Although comments and folding of white space are permitted throughout
>    Although comments and folding of white space are permitted throughout
Clearer.
>
>>    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
Or we could add a new document with examples, the way SIP does.... I'd 
like to get this one out the door....

---

From: Dan Kohn <[email-masked]>
Date: Mon, 17 Apr 2006 20:40:36 -0700

>> 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:]
>>
> folding, not a limit on header field lines. Which is in conflict  
> with the next paragraph you quote.
>

Harald, you caught an error I missed, which is that the first  
sentence of the original text meant to say header lines instead of  
header fields.  In any event, I would still propose that the whole  
paragraph be removed, as I don't see any reason to discourage agents  
from wrapping at 78 characters.  Specifically, I don't see why news  
articles are special in terms of line wrapping compared to mail  
messages.

>> 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.)
>>
>> 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.

Harald, you didn't comment on whether you agree with deletion of this  
paragraph or 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.
>

The following header ABNF differ from RFC 2822 only in their use of  
": SP".  I believe all of the following would best be moved to an  
appendix:

    from            =  "From:" SP mailbox-list CRLF
    orig-date       =  "Date:" SP date-time CRLF
    subject         =  "Subject:" SP unstructured CRLF
    sender          =  "Sender:" SP mailbox CRLF
    reply-to        =  "Reply-To:" SP address-list CRLF
    comments        =  "Comments:" SP unstructured CRLF
    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

            - dan

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Apr 2006 08:22:45 +0200

Dan Kohn wrote:

>>> do well to handle an arbitrarily large number of characters".    The 
>>> characters", however that's contradictory with the opening  
>>> permissive".  The last two sentences are only necessary because  the 
>>> paragraph is sort of departing from RFC 2822, but not really.
>>>

There is one specific reason to not wrap I know of, which is that 
wrapping of Path: is not handled well by all sites. Others will have to 
comment on how much of an operational issue this is, and whether 
wrapping near 998 is significantly less of a problem than wrapping near 72.

>>> RFC 2822 et al, rather than being an exception to them.   Further, 
>>> it is redundant with the subsequent section, and so can  either be 
>>> requiring a colon space and no whitespace-only headers.  This  

I think it's another one of those where people have argued so long and 
strenously for an opposite viewpoint (the whole just-send-8 thing) that 
we restate what's obvious to make sure it remains obvious. I don't see 
harm in letting it remain (despite being chair of the EAI WG, which 
proposes to do away with that restriction in that context...).

>    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

Thanks. I don't see that including this ABNF in this document 
contributes much at all - except that it gives the sections a consistent 
look. Other opinions?

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 18 Apr 2006 20:35:21 GMT

>like to get this one out the door....

I agree that some examples would be nice (even if we just copy the rather
simple example that appeared in the old "article" drafts).

But it is fair to point out that USEPRO contains a thorough Path example
(which now needs reworking, of course), and it also contains examples of
control messages.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Tue, 18 Apr 2006 20:29:42 GMT

>these that are controversial may require a ticket.

Again, many of these are improvements, but some of them go too far.

>    same text in different articles to different newsgroups.

s/uses a single article/creates a single article/

(I think I am disagreeing with John and agreeing with Seth).

>document that only specifies what a conformant article is.]

A lot of discussion went into those sentences. Safer to leave them as they
are.

>requirements of this specification."]

Ditto.

>>       includes suggested limits for convenience of display by user

Aaaarrrggggghhhhh! Bug or feature?

That was always meant to say "MUST NOT generate (but MAY accept) header
field lines...". I don't know how that wording crept it. So Dan's
suggested changes are certainly in order (though possibly not needed).

>If the purpose is just to remove the 78 character line limit, I would  

Yes, the intention was most definitely to remove any mention of the 78
character limit (and removing it is still consistent with RFC 2822). In
Email, various intermediate agents use this limit as an excuse to refold
headers and even body lines en route. This is most definitely verboten in
Netnews. USEAGE discusses what are sensible practical limits on line
lengths.

>       and MAY be line wrapped at 78 characters, excluding the CRLF."

We certainly don't want that "MAY" line in there. The line MAY be wrapped
anyway the poster likes (subject to 998). USEAGE is the place to give more
precise advice.

My inclination would be to leave the paragraph as it is, after fixing the
"header field [lines]" bug.

>definition of header folding.

Yes, that NOTE (which has been in our drafts for ages) confirms that is
was a bug rather than a feature. I would prefer to see those words left.

>deleted, or added there for emphasis.  (I would recommend deletion.)

It was there for emphasis. By all means move it.

>it's superfluous to the specification.

It gives the reason why we have made some restrictions. Leave it.

>still be included in an appendix).  Alternatively, these headers  

I agree our treatment is inconsistent, but where do we stop? There are
lots of standards which have introduced extension headers to Email, and
some of them may be appropriate for news. They all need to have the SP
there if they appear. So, inconsistent as it is, I think Ken got it about
right.

>believe is correct when adding Inject-Info but SHOULD NOT alter the  

I think I prefer the original, but no big deal.

>    case-insensitive forms such as "Poster".

That seems just as "wordy"

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Apr 2006 18:55:57 +0100

Harald Alvestrand wrote:

> It's been used as an argument for why (for instance) comments should 
> not be permitted in this field. So I'd keep it.

Unfortunately the quoted sentence doesn't explain why it is in the 
document. I suggest addition of "Thus some headers prohibit comments." 
or similar.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Apr 2006 19:37:32 +0100

Harald Alvestrand wrote:

> contributes much at all - except that it gives the sections a 
> consistent look. Other opinions?

If I remember correctly Charles has suggested to have collected ABNF in 
one place, so that people don't have to track 4 different documents for 
different ABNF pieces.
If I am to choose between ABNF only or existing sections describing 2822 
header fields, I choose ABNF. But I am fine with leaving existing 
sections as is and add ABNF in an appendix.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 24 Apr 2006 23:06:25 +0200

> document. I suggest addition of "Thus some headers prohibit comments." 
That makes sense.
Even more specific:

  Most of these headers are mainly of interest to news servers, and news 
servers often need to
  process these fields very rapidly. Thus the syntax of these headers is 
rather rigid; for instance
  they do not allow comments.

OK?

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 24 Apr 2006 23:21:46 +0200

Alexey Melnikov wrote:

> If I remember correctly Charles has suggested to have collected ABNF 
> in one place, so that people don't have to track 4 different documents 
> for different ABNF pieces.
> If I am to choose between ABNF only or existing sections describing 
> 2822 header fields, I choose ABNF. But I am fine with leaving existing 

A collected ABNF of what? All constructs defined in USEFOR, or all 
constructs from USEFOR and its supporting documents?

I think it would be presumptuous and error-prone to include all of 
2822's grammar in an USEFOR appendix - a collected ABNF for the USEFOR 
constructs might be a Good Thing; I think the ABNF is stable now. Ken, 
do you feel like writing one?

But this doesn't address the basic question on whether the lines Dan 
listed above should continue to be listed in their various sections, 
whether they should be in the collected ABNF, whether they should be 
dropped altogether, or whether more ABNF for other fields mentioned 
(such as the MIME headers) should be added.

I can't bring myself to care much one way or the other; their inclusion 
or non-inclusion doesn't change the protocol that the document 
specifies. Leave them the way they are?

                       Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Apr 2006 14:33:17 GMT

>do you feel like writing one?

I would certainly like to see a collected ABNF at least of what is in our
document.

In the original "article" drafts we went further and included, in an
appendix, all the ABNF that we relied on from in other documents, all
carefully annotated so you could see where each rule came from and whether
it had been changed. But of course it was all non-normative (though AFAIK
it was all transcribed correctly).

So there are the two extremes - doubtless intermediate states are
possible. I think it is really up to Ken, but a study of the old article
draft-13 would show what is possible. OTOH, we really ought to be getting
on with USEPRO now, so any work on Appendices ought to proceed in parallel
with that (such work would introduce no technical changes, though it might
uncover a few bugs).

>(such as the MIME headers) should be added.

Whatever we do is a compromise. My view is that Ken got it about right,
and that we should leave it as it is (just so long as it is clear that the
SP requirement applies to ALL headers appearing in Netnews articles,
wherever their original ABNF is defined).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Apr 2006 09:50:18 +0100

Harald Alvestrand wrote:

>>>>>> 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.
>>>>>
>>>> The following header ABNF differ from RFC 2822 only in their use 
>>>> of  ": SP".  I believe all of the following would best be moved to 
>>>> an  appendix:
>>>>
>> in one place, so that people don't have to track 4 different 
>> documents for different ABNF pieces.
>> 2822 header fields, I choose ABNF. But I am fine with leaving 
>> existing sections as is and add ABNF in an appendix.
>
> 2822's grammar in an USEFOR appendix

I agree.

> - a collected ABNF for the USEFOR constructs might be a Good Thing;

Yes.

> I think the ABNF is stable now. Ken, do you feel like writing one?
>
> I can't bring myself to care much one way or the other; their 
> inclusion or non-inclusion doesn't change the protocol that the 
> document specifies. Leave them the way they are?

I don't see a strong argument to convince myself one way or another. I 
tend to agree with Charles that the balance is about right. So just 
leaving the document the way it is now is fine with me.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Apr 2006 19:51:56 +0200

> leaving the document the way it is now is fine with me.
I think that's a reasonable resolution.
No change.

                 Harald