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

[Yehoshua Gev <[e-mail]>]

On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley <[e-mail]> wrote:

> Yehoshua Gev <[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".

Thanks,
Yehoshua