Subject: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments

From: Yehoshua Gev <[email-masked]>
Date: Mon, 10 Oct 2016 10:12:04 +0300

Hi,

Regarding the following paragraph in section 1:

   It is important to note that a message formed without honoring the
   constraint will still be syntactically valid, but would be
   interpreted differently.  The characters after the comma, question
   mark, or semicolon would be interpreted as header field parameters or
   additional header field values as discussed in section 7.3.1 of
   [RFC3261].

How about the following often-seen form:

  Refer-To: sip:123@host?Replaces=1111%3Bto-tag%3Dtag1%3Bfrom-tag%3Dtag2

I don't see how it fits with the paragraph above.
It does not honor the constraint, but according to the suggested
interpretation
(as header field parameters) it will not be syntactically valid.

Can it be clarified whether this form is syntactically invalid, and perhaps
write
the way to interpret it in a normative manner?

Thanks,
Yehoshua

---

From: Robert Sparks <[email-masked]>
Date: Tue, 11 Oct 2016 08:52:20 -0500

Inlin

On 10/10/16 2:12 AM, Yehoshua Gev wrote:
> It does not honor the constraint,
It _does_ fit the constraint, and is syntactically valid.
The presence of %3D during parsing is not the same as the presence of a 
semi-colon - that's the point of having the escaped form.
Section 19.1 of RFC3261 covers this.
> but according to the suggested interpretation
> Can it be clarified whether this form is syntactically invalid, and 
> perhaps write
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 12 Oct 2016 14:15:05 -0400

> It _does_ fit the constraint, and is syntactically valid.

As far as I can see, the above header is syntactically correct (per the
ABNF in section 25.1), and its value can only be interpreted as a single
addr-spec, that is, a SIP URI.  The URI does contain a "headers"
component.

Since the URI contains a qustion mark, the constraint requires it to be
written:

   Refer-To: <sip:123@host?Replaces=1111%3Bto-tag%3Dtag1%3Bfrom-tag%3Dtag2>

But it can't be mis-interpreted if the angle brackets are omitted.

It *seems* to me that the original constraint in section 20 needn't have
mentioned question-mark as a problematic character.

(Am I overlooking something?  I don't have a header parser handy to
check this.)

Dale

---

From: Yehoshua Gev <[email-masked]>
Date: Thu, 13 Oct 2016 10:32:46 +0300

Thank you Robert and Dale for your detailed replies.

Let me explain again my understanding of the paragraph I quoted, especially
the sentence "The characters after the comma, question mark, or semicolon
would be interpreted as header field parameters or additional header field
values...".

>From my understanding, the following header:

   (1a) Refer-To: sip:123@host;user=phone

should be interpreted the same as:

   (1b) Refer-To: sip:<123@host>;user=phone

Having the characters after the semicolon ("user=phone") interpreted as header
field parameters.

Using the same logic:

   (2a) Refer-To: sip:123@host;user=phone?Replaces=1111

will be equivalent to:

   (2b) Refer-To: <sip:123@host>;user=phone?Replaces=1111

And:

   (3a) Refer-To: sip:123@host?Replaces=1111

equivalent to

   (3b) Refer-To: <sip:123@host>?Replaces=1111

The last two interpretations are not syntactically correct, as the Refer-To
header does not allow a question mark after the name-addr/addr-spec.

For my point of view, the decision of the interpretation should be simple.
The above indeed propose a simple rule (although not worded as a normative
one) to decide where is the end of an addr-spec - when encountering a comma,
a question mark, or a semicolon.
However, this interpretation _does_ render some forms invalid.

Am I misreading the paragraph?

Thanks,
Yehoshua

---

From: Brett Tate <[email-masked]>
Date: Fri, 14 Oct 2016 09:59:09 -0400

Hi,

> It *seems* to me that the original constraint in
> section 20 needn't have mentioned question-mark
> as a problematic character.

If anyone can locate the old 1998 emails, it looks like the question mark
became part of the rule when creating draft-ietf-mmusic-sip-10.

Based upon the following link, it looks like that was during the last call
for comments.

http://www.cs.columbia.edu/sip/history.html

---

From: Robert Sparks <[email-masked]>
Date: Fri, 14 Oct 2016 09:51:06 -0500

> became part of the rule when creating draft-ietf-mmusic-sip-10.
I'm not sure what you're hoping to find by spelunking that history, but 
this will pull it up:
https://mailarchive.ietf.org/arch/search/?qdr=c&start_date=1998-9-1&end_date=1998-12-01&email_list=mmusic&q=&as=1&subject=SIP

The only thing related I see in there is in one of Anders' comments, but 
it doesn't directly explain the set of characters that were chosen.

On a quick scan of the BNF I see that ? can appear in lots of surprising 
places unescaped (like in header names) - look at all the productions 
that include "unreserved" in their name and a literal '?' in their 
expansion and where those productions are used.

But other than historical interest, where are we really going to go with 
this?

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 14 Oct 2016 11:48:00 -0400

> Am I misreading the paragraph?

Yes, it looks to me like you are right, in a case like (3a) the rule
makes it invalid.  I suspect the correct response is "This rule has been
in use since RFC 3261, so we're not going to change it now."  We could
use a different rule for Refer-To than we do for Contact, From, and To,
but that would lead to madness...

Dale

---

From: Robert Sparks <[email-masked]>
Date: Fri, 14 Oct 2016 10:52:29 -0500

Poking a little further down this path - '?' appears in a couple of 
places in absoluteURI (one the the alternatives for addr-spec).

Now I'm getting deja-vu.

RjS

On 10/14/16 9:51 AM, Robert Sparks wrote:
> I'm not sure what you're hoping to find by spelunking that history, 
> but this will pull it up:
> The only thing related I see in there is in one of Anders' comments, 
> but it doesn't directly explain the set of characters that were chosen.
>
> On a quick scan of the BNF I see that ? can appear in lots of 
> surprising places unescaped (like in header names) - look at all the 
> productions that include "unreserved" in their name and a literal '?' 
> in their expansion and where those productions are used.
>
> But other than historical interest, where are we really going to go 
> with this?
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2016 12:16:41 -0400

> places in absoluteURI (one the the alternatives for addr-spec).

I have begun to think that the "proper" way to address this is to 
rewrite the syntax to remove the ambiguity. The change is bigger, but 
should be clearer. However that would make it harder to retrofit to lots 
of old rfcs.

But the big problem is indeed with absoluteURI. ISTM that the best way 
to handle that is to always require <> around absoluteURI, at least 
anywhere that follows it with *anything*. Would that break anything 
currently legal?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2016 12:19:33 -0400

> but that would lead to madness...

There is *nothing* special about Refer-To that justifies treating it 
differently from other header fields.

	Thanks,
	Paul