--On 17. mai 2007 15:32 -0400 Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>
wrote:
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.
Actually we defined a concept (LWSP) in a way that turned out to be much
more
troublesome in several contexts than we thought it would be (because it
allowed
two different versions of "blank" lines to have different semantics).
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 don't agree with the meaning I get from this statement. The problem is
that the construct that ABNF calls "LWSP" causes problems in protocols that
use it.
This problem is independent of the name of the construct; the problem is in
defining a grammar where the sequence <CRLF><CRLF> has a different meaning
than <CRLF><SPACE><CRLF>.
Some protocols have addressed this problem by defining their own construct,
and have used the term "LWSP" to refer to it - something that is legal by
ABNF rules, but can cause people who read multiple specs to become confused.
There seems to be some reason to think that it's useful to warn people that
there's reasons not to use the construct that is defined as "LWSP" in the
ABNF spec. The revised version of the ABNF spec is one possible place to
put that warning.
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 agree with the last statement.
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.
Fully agree with this statement too, but since I don't agree with your
interpretation (as given above) of what the problem is, I can't be sure
that my agreement with this statement means anything....
Harald
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf