Re: Comments on draft-resnick-2822upd-02.txt

[email protected] wrote:
>> Moreover, does it make sense to distinguish between obs constructs that
>> were theoretically permitted by RFC822 but in practice never seen in the
>> wild, as opposed to those which actually saw significant usage at one
>> time? IOW what possibilities exist for the eventual removal of at least
>> some of the weirder obs constructs?
> 
> The grammar is always quite complex and confusing. Adding another splitting
> point would make it even more complex and confusing. Additionally, I really
> don't think we need yet another round of interminable arguing over whether or
> not some system that hasn't been seen or heard of in several decades did such
> and such or so and so.

Discussing whether "it makes sense to distinguish" seems like a discussion 
that is appropriate for an initial development effort.  And of course that did 
take place during the writing of what became rfc2822.

To question the decision at this stage of the standards process would seem to 
me to require demonstrating that the current form of rfc2822 has caused 
problems that outweigh the benefits, with respect to this issue.  I'm not 
aware of any such claims.

In other words, I thought that later stages in the standards process were for 
fixing known errors, rather than opening up the entire set of design and 
specification decisions.


> So, while I get your point and see some benefit to tracking the implementation
> status of obsolete features (and non-obsolete ones as well), I don't believe
> the benefits of doing so exceed the costs. If this is to be done it should be
> done in some other document or perhaps just a web page. 

Indeed.  Tracking adoption and use is nice, but not the job of a protocol 
spec.  For that matter, I do not have the sense that it has been done all that 
much in the IETF, other than what is required to go to Draft.


>> Can we de-emphasise that SHOULD, and make it clear that this is a matter
>> of good practice (in the sense of BCP) rather than a normative feature?
> 
> That would be a significant change in normative language from RFC 2822 and
> could easily be seen as requiring a reset to proposed  Moreover, if memory
> serves, this language went into RFC 2822 not because the WG wanted it but
> rather because the IESG insisted on it.

Again, this line of challenge to the current spec seems to be attempting a 
review of previously-resolved issues, rather than claiming that there are 
known problems with the resolution and documenting the need for change.

That ain't what this stage of standardization is for, right?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net