ned+ietf-822(_at_)mrochek(_dot_)com 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