ietf-822
[Top] [All Lists]

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

2007-08-28 09:52:58

In <46D17ED0(_dot_)9050706(_at_)dcrocker(_dot_)net> Dave Crocker 
<dhc(_at_)dcrocker(_dot_)net> writes:

I believe what follows is largely or completely compatible with Pete's and 
Ned's comments:


Pete Resnick wrote:
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.......

This really underscores the difference between making changes that "fix" 
RFC2822, versus adding the (new) the goal of compatibility with other 
messaging standards.

The former is required for the current exercise.  But why is the latter?

I mean, do we really want to go through the exercise of testing every single 
RFC2822 parser, to make sure that we will not be breaking it (unnecessarily)?

An RFC2822 parser that will not accept SP after the ':' will already be
non-compliant, and will still be non-compliant even if absence of that SP
is relegated to the obs-syntax. Moreover, since 99.999% of emails
currently sent already include that SP, such a parser would be totally
useless in the current email environment - so I think we can safely assume
that no such parser exists.

An existing RFC2822 agent that currently _generates_ headers without that
SP (I am not aware of any) would then become non-compliant, but the
messages it generated would still be accepted by all current and future
2822-bis-compliant agents.

There is no technical reason for requiring any white space here, since the 
colon provides the necessary syntactic marker.  So requiring a space is either 
a compatibility requirement for "interoperating" with other messaging 
standards or it is a human factors usability requirement.  As much as the 
latter might be appealing, I suspect we don't want to go down that path.

Exactly. The ONLY reason for REQUIRING that SP is for interoperability
with other messaging standards.

This is the sort of specification detail that would have made quite a lot of 
sense when we began writing messaging specs, but does not warrant the risk of 
side-effects (to quote Pete) at the present stage of deployment.

What side effects? I have just demonstrated that no such side effect can
occur within any 2822- or 2822-bis-compliant agent.

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.

Yes, I am not suggesting you go so far as to make that change (though a
SHOULD NOT do it might help). That still leaves a slight interoperability
problem, but one that would only show up only in very rare and improbable
circumstances.

Indeed. Absent a clear and substantial demonstrating of operational problems, 
we should not be making any changes to the specification.  Doing things that 
appear to clean up the spec or otherwise make it better, absence a compelling 
demonstration of need, is inviting problems.  Let's not do that.

The clear and substantial interoperability problem with Netnews has
already been demonstrated. It WOULD cause emails without that SP that were
gatewayed or cross-posted to Netnews (both of which are common practice)
to get lost/garbled/whatever. The only reason this does not pose a problem
at present is that emails (99.9999% of them) already insert that SP.

So all I am asking for is for that loophole to be closed. And the cost of
closing it within the email environment appears to be zero (and nobody has
demonstrated otherwise).

-- 
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: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      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