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

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