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,
Well, that may be your opinion, but I'm afraid the rules say otherwise: A
document moving to draft can remove features and functionality but cannot add
any. Removing a restriction is a form of adding functionality and is therefore
not allowed.
and maybe some backing off might make life simpler for future
implementors.
Or it can make it far more difficult. This part's a judgement call, and I'll
again repeat that you're a long way from having made a case for such a change.
It is your last chance to do such a thing.
You keep saying this like repetion will make it true. This entire execise of
revising 821/822 would not have been possible if this were true. And even if
this time around is indeed the last time we'll ever be able to revise these
base specifications, writing short specifications that update some small thing
or other is possible at any point.
In other words, if at some future point things change so it becomes clear that
advising implemenentations to limit line lengths ts 78 characters is a bad
idea, this can be changed quite simply by pushing a one page revision through
the process.
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).
And I'll once again point out that these implementors have quite simply read
something into the specification that just isn't there. You cannot
cure such misreadings by removing compliance language - if you do that
they will simply say "there's nothing in the specification that says I cannot
or should not do this".
If this really is worth addressing (and I'm 99.99% convinced it is not), the
way to do it is to tighten down the rules, not loosen them. For example, you
could say something like "the 78 character limit SHOULD be observed when
initially constructing messages but exceeding 78 characters SHOULD NOT be taken
as justification for modifying messages in transit".
Ned