>>>>> "John" == John C Klensin <john-ietf@xxxxxxx> writes:
John> If we are going to standardize a definitional requirement or
John> method -- whether it is ABNF or IPR boilerplate or something
John> -- we need to get it right as a self-contained definition
John> and then live with it. We should certainly revise and
John> replace it if it turns out to be unworkable (as has happened
John> with IPR work) or if the definition turns out to be
John> inadequate to permit an unambiguous interpretation (that
John> issue spills over into my second observation, below). But,
John> once other specifications start to depend on the definitions
John> that are there, and show those definitions to be adequate,
John> we should not be talking about deprecating definitions
John> unless we are prepared to "that was wrong, we need to start
John> over (even though some of the older material may still be
John> useful)". Again, please note the similarity to the IPR
John> work.
Right. Here, I don't think the definition is wrong, I just think the
term being defined is wrong. We proposed a definition for a useful
concept. The word we chose (LWSP) stuck in some places but not in
others. IN fact other people used the same word for a different
although related concept. sufficiently so that the definition we
proposed in ABNF is not the most common definition in our standards.
Clearly we should not invalidate existing uses of that term. Clearly
we do need a definition for the term: it is being used usefully.
I think that in this instance, the value of future clarity justifies
coming up with a new term that will unambiguously mean what LWSP
means in ABNF today. That term will have to start at proposed
standard.
LWSP will need to continue in ABNF.
I see a desire to document our operational experience with the word:
many people took this word and used it to mean something else.
Perhaps to avoid confusion you should consider whether your use of the
word is a good idea. I think there is significant harm in choosing
not to document this operational experience when advancing standards.
After all, we both agree that it is this experience with running code
that gives the IETF value.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf