ietf-822
[Top] [All Lists]

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

2007-07-30 18:20:09


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

I am in complete agreement with your assessment here.

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

I won't object strongly if these changes are made, however my personal position
is that none of them have been sufficiently justified to be done at this stage
of the game.

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?

Our implementation has handled quoted-pairs in domain literals since it was
first written. However, while we allow whitspace in domain literals, we don't
drop whitespace embedded inside domain literal content as we should when
interpreting the value. But I'd rather fix our implementation (in fact I've
already done so) than change the specification to deal with this - I don't
think we have any way to be sure that such a change wouldn't have some adverse
impact somewhere. Frankly, I think dropping the ability to quote stuff would
actually be a bit safer than mucking around with whitespace rules that impact
where folding can occur.

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

The problem is we're not just talking about full fledged MUAs. A simple message
submission agent can be written in 50 or so lines of code in most languages and
on most platforms. As a result there are a bagillion such agents out there
hardcoded into all sorts of applications and even hardware. And since a
significant fraction of MTAs fix up stuff like this, especially when dealing
with submission rather than relay, there's a lot of marginal code in use that
could be pushed over the edge by such a change. And yes, while I've yet to see
a full-fledged MUA that doesn't put in the space, I've seen several of these
bits of code that do not. (I usually fix them when I come across them, which is
why I know people write them this way.)

This issue has abated somewhat now that people code more and more in higher
level languages with built in mail sending capabilities or "mail classes" ready
to hand or whatever, but I think we're still a long way from this being a
completely safe change to make.

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

Me too.

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

Agreed.

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

I've only seen commetns show up in an id field a couple of times, and each time
it apparently was because of some very broken logic attempting to generate an
id based in part on what was in the From: field. I have no problem breaking
stuff that's already deeply broken, but OTOH are we really sure nobody does
this? We said something similar about MIME-Version:, only to find an
implementation almost immediately that put comments in every time.

                                Ned