--On 10. september 2002 13:18 +0700 Robert Elz
<kre(_at_)munnari(_dot_)OZ(_dot_)AU> wrote:
That is, the IETF (according to this) cannot specify a new P-header
unless it meets the requirements in that doc (or if they do, implementors
are still not free to use it, even if it is documented in an RFC and
registered by IANA. That is, they can't if they want to remain
conformant, of course, and often, they do.
It is extortion aimed at the IETF community that I am worried about,
and what's more, I have seen this work. Some WG (perhaps the same one
that published an earlier doc, perhaps a different one) looks at an RFC
which says what can or cannot be done, and without further thought,
rejects a proposal, because it does not conform with some rule laid down
by some earlier doc (which most likely hadn't even considered the
situation now being proposed).
Robert,
thanks for clarifying - I did misunderstand your first message.
I think you have the reason why documents specify such "forward-looking
prohibitions" described exactly, and your words also point out the right
way to handle it.
The sipchange draft is the result of a good deal of thinking and discussing
about the dangers of extensibility in the particular case of SIP.
There will certainly be cases in the future when someone proposes some
action that does not fit in with that rule.
And in some cases, that action is the Right Thing to do.
But I think it is right and proper that once one encounters such a
situation, one should take responsibility for not only steamrollering the
nonconformant proposal through the IETF (and we have done that, too...) but
also to read and understand the rule laid down in the past, and undertake
the effort to *change* that rule, because it no longer fits the real world.
Blithely ignoring a conclusion because it was drawn a year ago is as
harmful (IMHO) as blithely ignoring new ideas because they don't conform to
the "received wisdom".
In my opinion, which is neither particularly new nor received wisdom.
Harald