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

[Yehoshua Gev <[e-mail]>]

On Wed, Mar 29, 2017 at 3:57 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
> > will all be syntactically invalid using the interpretation proposed by
> the
> > draft.
> > I think this is ok and corresponds to my current understanding of RFC
> 3261.
> >
> > However, in the above thread, it seemed to me that on first sight, both
> Dale
> > and Robert thought that those examples are valid.
> > After the discussion there, I think (IIUC) they agreed that those are not
> > valid.
>
> You have to be careful about the terminology.  Within the context of
> draft-ietf-sipcore-name-addr-guidance, there is the BNF, and then there
> is an extra-BNF constraint.  So what does the term "syntactically valid"
> mean?  In the context of parsing as it is used in computer programming
> languages, "syntactic" is usually used only in regard to what is
> expressed in BNF.  So from that point of view, you could say that the
> two examples are "syntactically valid" but that they are invalid
> relative to the non-BNF restriction.
>

I believe that the examples above are not valid according to the BNF -
that of RFC 3515, not of 3261:
      Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *
      (SEMI generic-param)
This BNF does not allow for a question mark after the name-addr.
So, the interpreting the string "sip:123@host" as the addr-spec alone,
renders the
header non-parsable by the BNF of 3515.

Also, RFC 3261 section 20:
    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.
only has normative text regarding Contact, From, and To header fields.
I didn't see similar normative text for other headers, so the text int the
draft: "The characters after the comma, question mark, or semicolon would
be interpreted..." is a new disambiguation rule (for other headers).
Given so, IMHO the disambiguation rule should be stated as a normative text.

Thanks,
Yehoshua Gev