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

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 <rjsparks@nostrum.com>
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 <worley@ariadne.com>
> wrote:
>
>> Yehoshua Gev <yoshigev@gmail.com> 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 listsipcore@ietf.orghttps://www.ietf.org/mailman/listinfo/sipcore
>
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>
>