> > 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. > > That rule needs to apply anywhere the ABNF allows > name-addr / addr-spec > > Otherwise that rule is ambiguous.
Hi Paul, Since header parameters are not allowed, I don't think that it is ambiguous. However, it does make things inconsistent with other headers which do allow parameters. >From a decode perspective, header parameters are not part of the ABNF. Thus >there are only 3 options when receiving addr-spec with parameter (no >brackets): 1) uri parameter, 2) malformed, or 3) assume someone expanded the >ABNF to include header-parameters. As far as I know, option 1 is valid per RFC 3325; however I have no idea what the RFC 3325 author's intended. Thanks for the response, 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
