Re: Last Call: draft-saintandre-jabberid (The Jabber-ID Header Field) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Frank Ellermann wrote:
> 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.

Thanks for the clarification.

> 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

I see no particular reason to define the header field so that it cannot
be used on Netnews...

> ...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.

Thanks again. I'll clean up the ABNF accordingly (i.e., I think it
should be the Netnews-friendly format you describe above).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]