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

From: Adam Roach <[email-masked]>
Date: Mon, 6 Mar 2017 17:30:35 -0600

[as chair]

We've spoken to the author of draft-ietf-sipcore-name-addr-guidance 
about its current state, and he indicated that he believes the document 
to be complete, with no open issues. Given its relative simplicity and 
the fact that it is addressing a real-world problem being encountered in 
the field, we would like to get the publication ball rolling.

Today, we start a two-week working group last call for the document, 
ending Monday, March 20th. Please direct comments to the SIPCORE WG 
mailing list.

Thanks!

/a

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 07 Mar 2017 23:02:53 -0500

Of course, I favor approval of draft-ietf-sipcore-name-addr-guidance.

I do think there are some nits that need to be resolved.  Though since I
haven't been following this draft closely, these points may already have
been discussed.

Dale
----------------------------------------------------------------------
Abstract

   It
   also updates those extension SIP header fields that use the
   alternative to clarify that the constraint applies (RFCs 3325, 3515,
   3892, 4508, 5002, 5318, 5360, and 5502).

This isn't parallel to the 1st sentence of the paragraph, where the
object of "updates" is "RFC3261".

Perhaps

   It also updates the RFCs (3325, 3515, 3892, 4508, 5002, 5318,
   5360, and 5502) that define the extension SIP header fields that
   use the alternative to clarify that the constraint applies.

1.  Introduction

   It is important to note that a message formed without honoring the
   constraint will still be syntactically valid, but would be
   interpreted differently.

This is a subtle point...  If the <...> is omitted, the header will
necessarily still be syntactically valid according to the BNF, reading
the original URI as an addr-spec -- the BNF is ambiguous in that way.
What *might* happen is that the header becomes parsable according to
the BNF in a different way also, one that parses the URI as multiple
elements.  E.g.,

    From: sip:10.0.0.1,sip:[email-masked]

can be either parsed as one URI with user "10.0.0.1,sip" and password
"x", or two URIs, one "sip"10.0.0.1" and one "sip:[email-masked].

OTOH,

    From: sip:10.0.0.1,@10.0.0.0

can only be parsed with the BNF as a single URI, because "@10.0.0.0"
doesn't parse as a URI.

So it's more accurate to say

   It is important to note that a header formed without honoring the
   constraint will still be syntactically valid, but might be
   syntactically ambiguous and interpreted differently than it was
   formed.

4.  IANA Considerations

   This memo has no considerations for IANA.

Shouldn't the new RFC be listed in the IANA table of SIP header fields
(http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2)
as a reference for these header fields:

     P-Asserted-Identity
     P-Preferred-Identity
     P-Profile-Key
     P-Refused-URI-List
     P-Served-User
     Permission-Missing
     Refer-To
     Referred-By
     Reply-To

And while we're at it, shouldn't RFC 4508 be a reference for Refer-To?

(Perhaps I'm not understanding how the "Reference" column of that table
is to be used.)

5.  Security Considerations

   One pre-existing consideration is worth reiterating:
   messages produced without honoring the constraint will be mis-
   interpreted by the receiving element.

This should say "may be mis-interpreted", as discussed in the item for
section 1.

[END]

---

From: Robert Sparks <[email-masked]>
Date: Wed, 15 Mar 2017 13:55:55 -0500

> haven't been following this draft closely, these points may already have
I'll use a variation of that.
>     syntactically ambiguous and interpreted differently than it was
s/formed/intended/?

But I don't think changing will to might is correct.

Can you construct a case where the refined guidance says you have to use 
the <>, and if  leave them out you get the same interpretation?

> And while we're at it, shouldn't RFC 4508 be a reference for Refer-To?
Good question, but not this document's problem, and I don't remember if 
using Updates for this doc was discussed at the time (it should have 
been at least discussed).  In any case, I propose the answer is no, for 
the reasons below.
> (Perhaps I'm not understanding how the "Reference" column of that table
So this is hard.

My opinion is that it would be a mistake to try to mark updates in the 
iana registry as you suggest.
Rather, the registry should point to the main defining document, and 
only the main defining document.
Readers can follow the Updates links from the RFC pages.
(Note that we _have_ changed that registry to reflect Obsoletes, which 
is consistent with the above.)

My rational for that opinion is that we already have the Updates 
metadata in two databases (the RFC Editor and the datatracker). We have 
had, an expect will continue to have, conversations about moving to one 
authoritative database for that. If we were to try to also track this in 
the IANA registries, that unification gets even harder.

I also note that if we _were_ to update the IANA registry column as you 
suggest, it's unusually easy
to figure out which ones to modify for this particular draft's case. It 
becomes much murkier for the
general case. Why, for example, would you not list 6141 along with every 
row that says 3261 (at least
for any header field involved in reINVITE and target-refresh request 
handling). That could lead, in the
extreme to a lot of noise, with most of the rows in that table saying:
[RFC3261][RFC6665][RFC4320][RFC3265][RFC5954][RFC5630][RFC5393][RFC7463][RFC5626][RFC6878][RFC3853][RFC7462][RFC6026][RFC5621][RFC5922][RFC4916][RFC6141]

I really think the right way to approach this is to keep the table as it 
is now.

> This should say "may be mis-interpreted", as discussed in the item for
Again, I don't think the change from will to may is correct.
>
> [END]
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 Mar 2017 15:46:38 -0400

>>     syntactically ambiguous and interpreted differently than it was

You could phrase it that way.

> the <>, and if  leave them out you get the same interpretation?

Let me see if I made a mistake here...

If you form the header and violate the guidance by not using <>, the
header will necessarily be parsable *by the BNF alone* in the way it was
constructed.  It might also be parsable by the BNF alone in another
way.  What the guidance does is resolve the parsing ambiguity by
favoring the interpretation of comma, etc. as separators in the header
rather than as characters in the URI.

So if you want a From header containing "sip:10.0.0.1,sip:[email-masked]",
which has user "10.0.0.1,sip" and password "x", you should write:

      From: <sip:10.0.0.1,sip:[email-masked]>

and if you write

it's interpreted as two URIs, "sip:10.0.0.1" and "sip:[email-masked]", which
is syntactically correct but not what was intended.  (It's also
semantically incorrect.)

If you want a From header containing "sip:10.0.0.1,@10.0.0.0", which has
user "10.0.0.1,", you should write

      From: <sip:10.0.0.1,@10.0.0.0>

but if you do it wrong and write

there's only one way to parse it with the BNF, and that is as you
intended it.

There's sort of an open issue as to what to do with that last header.
Since the guidance forbids its use, there's no requirement for
implementations to successfully parse it.  But since there's only one
way to parse it with the BNF, it's likely that a considerable number of
implementations parse it as it was intended.

At this point, I think the discussion is getting into the weeds
regarding exactly how you describe the bad things that might happen if
one violates the guidance, and I'll leave it to you!

> the IANA registries, that unification gets even harder.

And putting the updates information in the registry would be an
additional duplication, which is undesirable in general.  The loss is
that in following the "RFC X updates RFC Y" links, RFC X may not update
RFC Y in regard to a particular registry item, and there's no recording
of that.

I'm OK with this as a policy.

Dale

---

From: Yehoshua Gev <[email-masked]>
Date: Mon, 27 Mar 2017 18:08:39 +0300

> rather than as characters in the URI.

This is something that I raised some time ago, in this thread
https://mailarchive.ietf.org/arch/msg/sipcore/8DQXMoMSXfvldRYgRu-YcwhfKFo ,
and I'm sorry that I've left it open then.

I still think that the current wording of the draft might be misleading.

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.

This draft is a great place to state how exactly those type of examples
are parsed.
Also, it might be good to show an example like:
   Refer-To: sip:123@host;user=phone
which is valid, but interpreted with an header parameter although it might
have been intended to have a URI parameter (there is a reference to
section 7.3.1 of [RFC3261], but is it not stated there explicitly regarding
URI).

Thanks,
Yehoshua Gev

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 28 Mar 2017 20:57:48 -0400

> After the discussion there, I think (IIUC) they agreed that those are not

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.

On the other hand, you could say that "syntactically valid" means that
it passes every validity check that can be implemented without reference
to external information sources.  In that case, the two examples are
"syntactically invalid", because they violate the non-BNF restriction,
and determining that doesn't require knowing anything about the domain
"host".

That ambiguity is why I used the term "parsable *by the BNF alone*", as
that is not bedeviled by the exact definition of "syntactically".

Of course, the questions you raise about what examples should be
discussed in the draft are still valid.

Dale

---

From: Yehoshua Gev <[email-masked]>
Date: Wed, 29 Mar 2017 12:05:25 +0300

> 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

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 29 Mar 2017 17:04:04 -0400

> 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 "<...>".)

> Given so, IMHO the disambiguation rule should be stated as a normative text.

Well, in section 2 of draft-ietf-sipcore-name-addr-guidance-00, it says:

   This text from the introduction to section 20 of [RFC3261]:
     ...
   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.
     ...

So, yes, the new disambiguation rule is stated as a normative text.

Dale

---

From: Yehoshua Gev <[email-masked]>
Date: Thu, 30 Mar 2017 13:57:14 +0300

> 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.

> 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