John C Klensin wrote: > I would have no problems adding a comment to any construction > (including built-in productions) in ABNF that has proven > dangerous warning people that they should understand it and > its consequences before they use it. That's the intention of the proposed "security considerations". It could be placed elsewhere, or reduced to "there be dragons" if that's appropriate language for an STD (I'd like it), these proposals have the same effect of deprecating LWSP from my POV. > I see those options as very different from deprecating something > that is used successfully and correctly in a number of standards > and incorporated into them by reference. Then our terminology of "deprecating" is different, but neither "there be dragons" nor the longer security blurb used the verb "deprecate" explicitly. > Since it is in use Do you know a single case of a x234-LWSP intentionally allowing "apparently empty lines" ? I'd guess that authors just copied it without considering this effect, or because their protocol doesn't need any "really empty lines" with a different meaning. While I'm at it, the 4234 definition of LWSP doesn't use the grouping notation recommended in 4234: *(WSP / CRLF WSP) is the same as the <q>strongly advised</q> *(WSP / (CRLF WSP)) Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf