Hi, While we are here... RFC 3261's section 20 has obviously not been written in a forward-compatible way. Is there any hint in any subsequent standard document that requires the quoted paragraph to be applied to other similar-looking headers? Or is it just an assumption based on "we like things that look consistent"?
Or to put it in a different way, if we see an implementation not adding the angle brackets in a name-addr / addr-spec extension header containing, say, a question mark, and the extension RFC does not verbatim include or refer to 2361's section 20, do we have any ground (subsequent RFC, best practice document, erratum, or something), other than our sense of aesthetics or consistency, to tell them off? Thanks in advance, Balint On 03/10/2013 19:21, Brett Tate wrote: > Hi, > > Concerning RFC 3325's P-Asserted-Identity and P-Preferred-Identity, should > the typical bracket rule apply concerning parameters? > > Since these headers do not contain parameters, I assume that the following > RFC 3261 section 20 snippet does not apply. > > Thanks, > Brett > > ----- > > RFC 3261 section 20: > > The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters. > > RFC 3325 section 9.1: > > PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value > *(COMMA PAssertedID-value) > PAssertedID-value = name-addr / addr-spec > > RFC 3325 section 9.2: > > PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value > *(COMMA PPreferredID-value) > PPreferredID-value = name-addr / addr-spec > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If you > are not the intended recipient and have received this email in error, please > notify BroadSoft, Inc. immediately by replying to this message, and destroy > all copies of this message, along with any attachment, prior to reading, > distributing or copying it. > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
