Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance

[Robert Sparks <[e-mail]>]

Hi Yehoshua -

It was that last paragraph of the introduction to section 20 that I was 
pointing to. The change made by this document doesn't take those 
sentences away.

I still don't agree that new normative text is the necessary (I actually 
feel it's dangerous - it adds yet another opportunity for 
misinterpretation).

But I re-read the end of the introduction to section 20 with the changes 
this document specifies applied to it, and I think I see an improvement 
that might ease the discomfort you're feeling with it.

Section 2 currently says this:

> 2. Updates to RFC3261
>
>     This text from the introduction to section 20 of [RFC3261]:
>
>       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 >).
>
>     is replaced with:
>
>       When constructing the value of any SIP header field whose grammar
>       allows choosing between name-addr and addr-spec, such as those
>       that use the form '(name-addr / addr-spec)', the "addr-spec" form
>       MUST NOT be used if its value would contain a comma, semicolon,
>       or question mark.
>
>       The header fields defined in this specification that allow this
>       choice are "To", "From", "Contact",  and "Reply-To".
We could change it to say this (being more explicit with what happens to 
the rest of the paragraph being operated on).

> 2. Updates to RFC3261
>
>     This text from the introduction to section 20 of [RFC3261]:
>
>       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.
>
>
>     is replaced with:
>
>       When constructing the value of any SIP header field whose grammar
>       allows choosing between name-addr and addr-spec, such as those
>       that use the form '(name-addr / addr-spec)', the "addr-spec" form
>       MUST NOT be used if its value would contain a comma, semicolon,
>       or question mark.
>       When a URI appears in such a header field, 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.
>       The header fields defined in this specification that allow this
>       choice are "To", "From", "Contact",  and "Reply-To".

Does that ease your concern?

RjS

On 4/18/17 2:42 AM, Yehoshua Gev wrote:
> Hi Robert,
> Can you point me to the text on 3261 that has the disambiguation rule?
> I could only find it in the last paragraph of section 20, which only 
> speaks about "Contact, From, and To".
> I believe the intention of this draft is to expand this paragraph to 
> cover all other "problematic" headers,
> so it should also expand the disambiguation rule to the other headers.
> Thanks,
> Yehoshua
> On Fri, Apr 14, 2017 at 12:43 AM, Robert Sparks <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Yehoshua -
>
>     On 3/30/17 5:57 AM, Yehoshua Gev wrote:
>>     On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         Yehoshua Gev <[e-mail] <mailto:[e-mail]>>
>>         writes: >> > The examples of: >> >    Refer-To:
>>         sip:123@host?Replaces=1111 >> >    Refer-To:
>>         sip:123@host;user=phone?Replaces=1111 > So, the interpreting
>>         the string "sip:123@host" as the addr-spec alone, > renders
>>         the > header non-parsable by the BNF of 3515. Yes... but if
>>         you're only considering the BNF, "sip:123@host?Replaces=1111"
>>         can be parsed as an addr-spec, so the header is valid (by the
>>         BNF alone).  (Actually, even "sip:123@host" can't be parsed
>>         as a name-addr, because it doesn't have "<...>".)
>>
>>     Ok. I see your point. So when parsing header like  "Refer-To:
>>     sip:123@host;user=phone", the BNF parser will give two possible
>>     interpretation, and the non-BNF restriction will rule out one of
>>     them. And for "Refer-To: sip:123@host?Replaces=1111", the BNF
>>     parser will give one possible interpretation, which will be ruled
>>     out by the restriction. I believe my first understanding was that
>>     the restriction is applied to addr-spec, disallowing it from
>>     having uri-parameters/headers. And if the restriction if applied
>>     after parsing the add-spec, prior to parsing the rest of the
>>     Refer-To header, it will make the header syntactically invalid.
>>     But I guess it's a philosophical question.
>>
>>         > Given so, IMHO the disambiguation rule should be stated as
>>         a normative text. ... So, yes, the new disambiguation rule is
>>         stated as a normative text. 
>>
>>     The normative text in the draft only considers the "construction"
>>     of the header,
>>     it doesn't handle parsing/interpretation of a "constructed" header.
>>     Specifically, a sentence like "If the URI is not enclosed in
>>     angle brackets,
>>     any semicolon-delimited parameters are header-parameters, not URI
>>     parameters" (from RFC 3261 section 20) is missing.
>>     I suggest adding a text like:
>>     "If the URI in such headers is not enclosed in angle brackets,
>>     any characters
>>     after a comma, a question mark, or a semicolon SHOULD NOT be
>>     parsed as
>>     part of the URI".
>>     Alternatively:
>>     "When a URI is part of addr-spec which is not part of name-addr,
>>     the addr-spec
>>     SHOULD NOT be parsed to include a comma, a question mark, or a
>>     semicolon".
>     3261 does already say this. and there's no ambiguity to clear up -
>     we'd be restating it here, and restating things that are required
>     by a base specification is something we avoid.
>>     Thanks,
>>     Yehoshua
>>
>>     _______________________________________________
>>     sipcore mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/sipcore
>>     <https://www.ietf.org/mailman/listinfo/sipcore>
>     _______________________________________________ sipcore mailing
>     list [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sipcore
>     <https://www.ietf.org/mailman/listinfo/sipcore> 
>