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

[Yehoshua Gev <[e-mail]>]

Hi Robert,

Yes, this is exactly what I was looking for.
I think that in my previous mail I tried to propose a text with similar
meaning, but your suggestion is much more strightforward.
One bit (actually not a new problem) - The term "header-parameters" is
never really defined. In other places "XXX header parameter" is used, but
only when referencing specific header. IMHO this term clear enough, but
nevertheless I raise this point.

Thanks,
Yehoshua

On Tue, May 2, 2017 at 1:57 AM, Paul Kyzivat <[e-mail]>
wrote:

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