On 10/4/13 9:39 AM, Balint Menyhart wrote:
> 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?

Probably not.

The real reason that the <> are needed has to do with the syntax of what 
follows the name-addr/addr-spec. If additional syntax would allow a 
character that would then be ambiguous then there is a problem. If the 
additional syntax doesn't introduce an inconsistency, then there is no 
problem.

        Thanks,
        Paul

> 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
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to