Peter Saint-Andre wrote: > Eric Allman wrote: >> I don't see any reason why a new proposed standard should allow >> obsolete syntax (specifically, obs-FWS in section 2). > Another reviewer pointed that out as well. As a result, in my > working copy I have changed that to: > "Jabber-ID:" [FWS] pathxmpp [FWS] CRLF We discussed this elsewhere a year ago: http://permalink.gmane.org/gmane.ietf.message-headers/8 You can't have any ... [FWS] CRLF in a header field, what you really want is ... *WSP CRLF. That 2822 issue is already fixed in http://tools.ietf.org/html/draft-resnick-2822upd-02#section-3.2.6 [new] | unstructured = (*([FWS] utext) *WSP) / obs-unstruct [old] | unstructured = *([FWS] utext) [FWS] If you intend to rule out the obsolete syntax you don't need the obs-FWS case covering what 2822upd-02 has as obs-unstruct. While you're at it it could make sense to define the Jabber-ID in a way also working for Netnews. If you do that you'd arrive at... | "Jabber-ID:" SP *WSP pathxmpp *WSP CRLF ...with the "magic SP" for Netnews (see a recent thread ont the 822 list about this oddity). If you don't care about Netnews for the moment you get: | "Jabber-ID:" [FWS] pathxmpp *WSP CRLF The reasoning behind this is that mail doesn't allow "apparently empty lines" ... CRLF 1*WSP CRLF within the header. And Netnews is even stricter and doesn't allow an "apparently empty" header field body line. Or in other words the RFC 2822 message syntax is designed so that losing trailing white space can't cause havoc (in the form of a premature end-of header CRLF CRLF condition). The obsolete RFC 822 syntax like the RFC 4234 LWSP construct still demand that CRLF 1*WSP CRLF is very different from CRLF CRLF, and won't survive conditions where significant trailing white space is lost or ignored. Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf