On May 18, 2007, at 6:03 AM, Charles Lindsey wrote:
Well do we know exactly how much Babel there is?
John Leslie published this list on the IETF reflector:
rfc0733 obs-by rfc0822
rfc0822 defs LWSP-char = SPACE / HTAB obs-by rfc2822
rfc0987 refs rfc0822
rfc1138 refs rfc0822
rfc1148 refs rfc0822
rfc1327 refs rfc0822
rfc1486 refs rfc0822
rfc1505 refs rfc0822
rfc1528 refs rfc0822
rfc1848 defs <LWSP-char> ::= SPACE / HTAB
rfc2017 refs rfc0822
rfc2045 refs rfc0822
rfc2046 refs rfc0822
rfc2110 refs rfc0822
rfc2156 refs rfc0822
rfc2184 refs rfc0822
rfc2231 refs rfc0822
rfc2234 defs LWSP = *(WSP / CRLF WSP) obs-by rfc4234
rfc2243 refs rfc0822
rfc2378 defs LWSP-char = SP | TAB
rfc2530 refs rfc2234
rfc2885 defs LWSP = *(WSP / COMMENT / EOL)
rfc3015 defs LWSP = *(WSP / COMMENT / EOL)
rfc3259 defs LWSP = *(WSP / CRLF WSP)
rfc3501 refs rfc2234
rfc3525 defs LWSP = *(WSP / COMMENT / EOL)
rfc3875 defs LWSP = SP | HT | NL
rfc4234 defs LWSP = *(WSP / CRLF WSP)
rfc4646 refs rfc2434
If we deprecate LWSP for future use, then the remaining problem is
the set of existing standards that rely on it (plus a few that have
redefined it/whatever, but those are not strictly relying on it).
Deprecating LWSP would not _remove_ or _redefine_ this macro. The
deprecation note could simply state this construct often is
problematic when addressing security issues or when dealing with
trailing whitespace. Any future use of this construct should be
locally defined with a different mnemonic, and preferably employ a
different construct where possible. Any existing standard would
simply reference a deprecated, existing, and unchanged definition
that has been deprecated by such a note.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html