> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.