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

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

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

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.

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.


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

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.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net