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

[Brett Tate <[e-mail]>]

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