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

[Paul Kyzivat <[e-mail]>]

Robert,

Please see inline.

On 5/1/17 3:22 PM, Robert Sparks wrote:
> 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".

What you are trying to do seems very good. But there is still trouble 
with the wording. The use of "these brackets" has no referent. How about 
this:

    When a URI appears in such a header field, any URI parameters are
    contained within angle brackets (< and >).  If the URI is not
    enclosed in angle brackets, any semicolon-delimited parameters are
    header-parameters, not URI parameters.

(Or the first "are" above might be replaced by "MUST be".)

	Thanks,
	Paul

> 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>
>>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>