Re: draft-resnick-2822upd-02 and Netnews

I want to start out by saying that in answering this, I'm trying to 
take RFC 2119, section 6 *very* seriously:
6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

Insofar as I interpret this:

MUST means, "You must do this or seriously bad things will happen, 
either with regard to interoperation with other implementers of this 
specification or known harm will come to this or other parts of the 
Internet." SHOULD means, "You probably want to do this, and not doing 
so may cause some interoperability problems, but you can do this if 
you fully understand the ramifications and you have a good reason to 
do so."
If below I ask why something should be a MUST or a SHOULD, I'm 
looking for an answer in light of the above.
Also, Charles alone does not rough consensus make. If there are 
others who strongly feel that these changes should be made (and 
strongly would be good; we're trying to push this along through the 
standards track, and changes at this point would be less than 
desirable), please speak up and indicate why the current 
specification does "the wrong thing".
Preliminaries out of the way:

On 7/26/07 at 9:44 PM +0000, Charles Lindsey wrote:

> ...a <quoted-pair> is still allowed within a <no-fold-literal>. 
> True, there is a mention that "other specifications" will limit it, 
> but no such specifications are mentioned.  Pointers to 
> draft-ietf-usefor-usefor-12 and to RFC2821-bis would be in order 
> here (cf such a mention in 3.4.1).
I'll do something similar to 3.4.1.

> However, I cannot conceive that any future IP-address format or 
> other domain literal would ever contain a <quoted-pair> or any 
> whitespace (that, together with '>', is the other thing Netnews 
> cannot tolerate at this point) - there are just too many existing 
> protocols that would promptly
> fall over. So why not fix the problem once and for all now? And fix 
> it for <domain-literal> at the same time - that and 
> <no-fold-literal> and the only places where <dtext> and <dcontent> 
> are used, so it is easily done, and the obs-syntax would remain, of 
> course.
My main issue here is that we already have examples where limiting 
the syntax in "obvious" ways in 2822 screwed up 2821 (e.g., 
"Received:" syntax) and I'd prefer not to shoot myself in the foot 
again. Do we know of implementations (especially non-netnews 
implementations) which can't deal with quoted-pair in domain literals 
or message ids, or won't strip whitespace out of domain literals? 
Should this really come out?
> And finally, a couple of nits I have spotted:
>
> In 3.2.2, in the Note:, "no-fold-quote" no longer exists, and 
> "no-fold-literal" need not be mentioned because the mention of 
> "dcontent" covers it.
Fixed.

> In 3.6.4, near the bottom of page 27, you need to add quoted-strings 
> to the list of things now not allowed in msg-ids.
Fixed.

> 2. SP after the ':' in headers
> ------------------------------
>
> That is REQUIRED in draft-ietf-usefor-usefor-12, and it is REQUIRED 
> in the new NNTP standard RFC 3977. Since every known MUA already 
> generates headers that way
Please some support for this, including a review of the DRUMS 
archive. If we're going to make this change, you do the research. I 
seem to remember a discussion of this during DRUMS, and having the 
space optional was where we ended up. Can we check?
> There is one slight consequence that you should then forbid header 
> lines with only whitespace after the header-name (because trailing 
> whitespace has a habit of getting lost).
And this gets us into a "changes with potential side-effects" problem 
that worries me.
> 3. CFWS between msg-ids in References
> -------------------------------------
>
> It is currently [CFWS], but usage in Netnews has always placed 
> whitespace there (and References has always been more of a News 
> featrure than an Email feature). Would it hurt to REQUIRE it?
See top of this message. Would it hurt to *not* have it as a MUST?

> And also, please can we promote its use in Replies from SHOULD to 
> MUST? It was SHOULD in RFC2822, but many MUAs have not taken the 
> "hint" and, as a result, threading in mailing lists often gets 
> broken, which is a confounded nuisance. It is invariably done 
> properly within News.
This is absolutely a violation of the 2119 definition in section 6. 
You must provide a better reason to make it a MUST.
> 4. Allowed positions for <comment>s
> -----------------------------------
>
> Allowing <comment>s in Message-ID header fields will break Netnews, 
> and therefore the Usefor draft disallows them. Would it hurt to 
> bring Email into line? For sure nobody ever uses them there.
Again, potentially breaking some netnews implementations is not by 
itself a reason to remove this IMO. Are there known non-netnews 
implementations that break because of this? (And why are netnews 
implementations so non-robust in the first place, unable to parse 
comments and quoted-pairs?)
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102