Re: [sipcore] [Technical Errata Reported] RFC3325 (3744)

[Paul Kyzivat <[e-mail]>]

Brett,

What you bring up is an interesting issue.

We have lots of headers where the same logic applies. But I see no 
obvious straightforward way to address them as a group. Certainly to 
date we have been addressing them one by one. :-(

In the 3325 case we decided to include ";" and "?" even though the 
ambiguity only exists for ",". The reasoning for doing so extends to all 
similar headers, including those that have no ambiguity for any of these 
characters.

If I had it to do over again I would probably change the ABNF, defining 
a new symbol:

    name-addr-spec = name-addr / addr-spec

and use that everywhere that (name-addr / addr-spec) is now used. And 
then I would move the "bracket rule" from section 20, applying it to any 
use of name-addr-spec.

But I don't see a good way to do that without a substantial update to 3261.

	Thanks,
	Paul

On 1/23/14 8:11 AM, Brett Tate wrote:
> Hi,
>
> Concerning the potential extrapolation of the reasoning and resolution to other headers, my current understanding is that an ambiguity must otherwise exist for ',', ';', or '?' (based upon current draft/RFC) to cause the need for draft modification or RFC errata to clarify when name-addr must be used instead of addr-spec.
>
> For instance, the same reasoning and resolution would likely apply to Refer-To and the other headers mentioned within the following email to avoid ambiguity related to decoding comma or semicolon.
>
> http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html
>
> However, P-Charge-Info (draft-york-dispatch-p-charge-info-02) does not have the same ambiguity concerning comma and semicolon (excluding older drafts and potential future BNF modifications).  And nobody has communicated an ambiguity concerning decoding question mark (although I assume someone had a reason for including it within the RFC 3261 section 20 bracket rule).  Thus the draft does not need to include a similar statement to clarify when name-addr must be used instead of addr-spec.  A device sending P-Charge-Info noa based upon draft-york-sipping-p-charge-info-09 without brackets would cause a draft-york-dispatch-p-charge-info-02 compliant device to decode the noa as a URI parameter (instead of header parameter) since the latest BNF does not allow header parameters.
>
> Please reply if my understanding of the current reasoning and resolution is incorrect.
>
> Thanks,
> Brett
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Monday, January 13, 2014 12:56 PM
>> To: Cullen Jennings (fluffy); Brett Tate
>> Cc: Alice Russo; Vintaur Chen; Dean Willis; Adam Roach; Jon Peterson;
>> [e-mail]; Keith (Keith) DRAGE; Richard Barnes;
>> Gonzalo Camarillo; SIPCORE
>> Subject: Re: [Technical Errata Reported] RFC3325 (3744)
>>
>> The chairs have reviewed the discussions regarding this erratum. There
>> is no ambiguity wrt ";" or "?", but there is wrt ",". So *some* sort of
>> erratum is in order. The question is what the erratum ought to say.
>>
>> It would be "sufficient" to say:
>>
>>      A P-Asserted-Identity header field value MUST consist of exactly
>> one
>>      name-addr or addr-spec.  If the URI contains a comma the URI MUST
>> be
>>      enclosed in angle brackets (< and >).
>>
>> The erratum currently takes a stronger position:
>>
>>      A P-Asserted-Identity header field value MUST consist of exactly
>> one
>>      name-addr or addr-spec.  If the URI contains a comma, question mark
>>      or semicolon, the URI MUST be enclosed in angle brackets (< and >).
>>
>> The difference is who is at fault if there is a usage that has ";" or
>> "?" without enclosing <>.
>>
>> The chairs agree with the stronger statement, because it is consistent
>> with the behavior for other similar headers. Without the stronger
>> statement, implementers that parse these need a special case for this
>> header.
>>
>> I propose that we add an additional note to the erratum:
>>
>> 'While the P-Asserted-Identity and P-Preferred-Identity header fields
>> have an ambiguity only for "," (not for ";" and "?"), we propose that
>> usage of ";" and "?" also must be inclosed in angle brackets to
>> preserve
>> consistency with the RFC 3261 section 20 bracket rule.'
>>
>> Anyone who objects to this should speak up now, or we will proceed this
>> way.
>>
>>       Thanks,
>>       Paul, as sipcore co-chair
>>
>>
>> On 1/6/14 12:50 PM, Cullen Jennings (fluffy) wrote:
>>>
>>> Yep, at this point I think we should leave it up the sip core chars
>> to make a consensus call on this and then the ADs can decide what to do
>> and let the RFC Ed know.
>>>
>>>
>>> On Jan 2, 2014, at 12:22 PM, Brett Tate <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I sent a reply to sipcore so that maybe consensus can be reached
>> concerning the topic and errata status adjusted accordingly.
>>>>
>>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05912.html
>>>>
>>>> Thanks,
>>>> Brett
>>>>
>>>> From: Alice Russo [mailto:[e-mail]]
>>>> Sent: Thursday, January 02, 2014 10:36 AM
>>>> To: Cullen Jennings
>>>> Cc: Vintaur Chen; Paul Kyzivat; Brett Tate; Dean Willis; Adam Roach;
>> Jon Peterson; [e-mail]; Keith (Keith) DRAGE; Richard
>> Barnes; Gonzalo Camarillo; RFC Editor
>>>> Subject: Re: [Technical Errata Reported] RFC3325 (3744)
>>>>
>>>> Cullen,
>>>>
>>>> Please see the mail below from Vintaur Chen (who is CC'ed) re:
>> http://www.rfc-editor.org/errata_search.php?rfc=3325&eid=3744
>>>>
>>>> Also, I've directed Vintaur to the "Bug in RFC 3325" thread on the
>> sipcore list (approx. starting with http://www.ietf.org/mail-
>> archive/web/sipcore/current/msg05714.html).
>>>>
>>>> Thank you.
>>>> RFC Editor/ar
>>>>
>>>> On Jan 2, 2014, at 9:04 AM, Vintaur Chen wrote:
>>>>
>>>>
>>>> Hi, RFC Editor
>>>>
>>>> I disagree with Errata ID: 3744 of RFC 3325, for reasons below.
>>>>
>>>> 1.     There is no ambiguity in current RFC definition, so the
>> Errata is unnecessary.
>>>> The RFC 3261 section 20 rule is involved to avoid the ambiguity
>> between URI parameters and header parameters.
>>>> This is not necessary for PAI header, as PAI header has no header
>> parameters at all.
>>>>
>>>> We can make a quick comparing between PAI header and To header here:
>>>> - PAI header has no pai-param here:
>>>>       PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
>> *(COMMA PAssertedID-value)
>>>>       PAssertedID-value = name-addr / addr-spec
>>>> - Compare this to for example the To-header:
>>>>       To = ( "To" / "t" ) HCOLON ( name-addr/ addr-spec ) *( SEMI to-
>> param )
>>>>
>>>>
>>>> 2.     Errata 3744 is not align with current RFC 3325, so the Errata
>> is incorrect:
>>>>
>>>> Consider the PAI header below:
>>>> - P-Asserted-Identity:
>> tel:[phone]@172.17.151.36;cpc=ordinary123
>>>>
>>>> Per current RFC description, the above header is a valid PAI header,
>> with no ambiguity.
>>>> Per Errata 3744, the above header is invalid. And Errata 3744 not
>> descript how to handle such "invalid" header.
>>>>
>>>>
>>>> RFC 3261 section 20 clearly statement that the rule only applicable
>> for URI in Contact/From/To header.
>>>> So, it should not be applicable for any other header unless clearly
>> statement in RFC.
>>>> 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.
>>>>
>>>>
>>>> Regards
>>>> Vintaur Chen
>>>>
>>>>
>>>> On Oct 9, 2013, at 11:48 AM, Cullen Jennings (fluffy) wrote:
>>>>
>>>>
>>>>
>>>> I started a thead on sip core
>>>>
>>>> [...]
>>>>
>>>> On Oct 8, 2013, at 12:49 PM, RFC Errata System <rfc-editor@rfc-
>> editor.org> wrote:
>>>>
>>>>
>>>> The following errata report has been submitted for RFC3325,
>>>> "Private Extensions to the Session Initiation Protocol (SIP) for
>> Asserted Identity within Trusted Networks".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=3325&eid=3744
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Brett Tate <[e-mail]>
>>>>
>>>> Section: 9.1
>>>>
>>>> Original Text
>>>> -------------
>>>> A P-Asserted-Identity header field value MUST consist of exactly one
>>>>
>>>> name-addr or addr-spec.
>>>>
>>>> Corrected Text
>>>> --------------
>>>> A P-Asserted-Identity header field value MUST consist of exactly one
>>>>
>>>> name-addr or addr-spec.  If the URI contains a comma, question mark
>>>>
>>>> or semicolon, the URI MUST be enclosed in angle brackets (< and >).
>>>>
>>>> Notes
>>>> -----
>>>> P-Asserted-Identity ABNF defines PAssertedID-value to be name-addr /
>> addr-spec.  However, no text is added to indicate if the RFC 3261
>> section 20 bracket rule fully applies, partially applies, or does not
>> apply.  Some of the confusion is caused by the ABNF not allowing the
>> header to contain parameters.
>>>>
>>>>
>>>>
>>>> The same bracket rule should be added to section 9.2 for P-
>> Preferred-Identity.
>>>>
>>>> Instructions:
>>>> -------------
>>>> This errata is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>> can log in to change the status and edit the report, if necessary.
>>>>
>>>> --------------------------------------
>>>> RFC3325 (draft-ietf-sip-asserted-identity-01)
>>>> --------------------------------------
>>>> Title               : Private Extensions to the Session Initiation
>> Protocol (SIP) for Asserted Identity within Trusted Networks
>>>> Publication Date    : November 2002
>>>> Author(s)           : C. Jennings, J. Peterson, M. Watson
>>>> Category            : INFORMATIONAL
>>>> Source              : Session Initiation Protocol
>>>> Area                : Real-time Applications and Infrastructure
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>>
>>>>
>>>>
>>>
>>>
>
>