> In <[email protected]> Dave Crocker <[email protected]> writes:
> >[email protected] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.