In <46C89306(_dot_)8050303(_at_)dcrocker(_dot_)net> Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> writes:
ned+ietf-822(_at_)mrochek(_dot_)com wrote:
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.
IMHO it is also for spotting cases where you have made the rules too
strict, and maybe some backing off might make life simpler for future
implementors. It is your last chance to do such a thing.
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.
This is exactly such an example. Implementors seems to have taken that
SHOULD as an excuse to "improve" messages during transit (not allowed if
you read the spec correctly) or to avoid enabling display of these things
robustly when they do arrive (also not allowed by the spec).
--
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