Subject: [sipcore] Bug in RFC 4474

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Oct 2013 08:48:18 -0600

Bret has pointed out a bug in 4474. It has to do with the P-Asserted-Identity header field value URI encoding when the URI has a , ? or ;. There are basically two ways we go to resolve this 

1) say URI with , ? or ; were not allowed 

2) say that URI has to be inside <> brackets 

There seem to be some evidence that #2 would cause problem for 3GPP implementations but I don't really know.  I'm not sure any reason that a URI in a PAI should ever have , ? or ; and like to hear uses cases.

Thoughts on what we should do ?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 11:15:28 -0400

Cullen,

I believe you mean 3325, not 4474.

The situation with 4474 is a little different, because it didn't include 
addr-spec in its abnf. So its not buggy, just confusing. We got into 
trouble with a proposed "fix" to this in 4474bis, because the fix wasn't 
backward compatible.

	Thanks,
	Paul

On 10/9/13 10:48 AM, Cullen Jennings wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Oct 2013 09:54:30 -0600

Ahhg - so sorry. You are right Paul. Bug in 4474 just seems embedded in my brain :-)

On Oct 9, 2013, at 9:15 AM, Paul Kyzivat <[email-masked]> wrote:

> The situation with 4474 is a little different, because it didn't include addr-spec in its abnf. So its not buggy, just confusing. We got into trouble with a proposed "fix" to this in 4474bis, because the fix wasn't backward compatible.
> 
> 	Thanks,
> 	Paul
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Oct 2013 10:55:22 -0500

On 10/9/13 09:48, Cullen Jennings wrote:
> There seem to be some evidence that #2 would cause problem for 3GPP implementations but I don't really know.

That doesn't make sense. The text under discussion (as Paul points out, 
we're talking about RFC 3325) is:

   "A P-Asserted-Identity header field value MUST consist of exactly one 
name-addr or addr-spec."

And name-addr is defined thus:

   name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT

Note, in particular, that display-name is optional, meaning any 
addr-spec can be trivially wrapped in angle brackets and become a 
name-addr. So your option #2 above effectively says "of these two forms 
that are mandatory to parse, any URI containing three specific 
characters needs to be in the second format."

Now, if there are implementations out there that ignore the syntax 
defined in RFC 3325, I'm pretty comfortable asserting that they will 
continue to ignore corrections we issue to RFC 3325. What we say here 
has no impact on them.

Incidentally, I don't think there's actually an ambiguity here, since 
",", "?", and ";" don't have any defined meaning when used in 
P-Asserted-Identity. It does make the parsing of that header field 
somewhat of a pain, since you can't just throw a normal "multi-value 
name-addr/addr-spec header field" parser at it, but SIP header parsing 
is nothing if not a pile of exceptions on top of some loosely implied 
rules. This is just one more exception on the pile.

/a

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 9 Oct 2013 13:43:50 -0400 (EDT)

> From: Cullen Jennings <[email-masked]>
> 
> Bret has pointed out a bug in 4474. It has to do with the
> P-Asserted-Identity header field value URI encoding when the URI has
> a , ? or ;. There are basically two ways we go to resolve this 

I think you mean RFC 3325 here.  And as far as I can see, only "," is
problematic, since the syntax does not provide for "header
parameters":

      PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
                      *(COMMA PAssertedID-value)
      PAssertedID-value = name-addr / addr-spec

> There seem to be some evidence that #2 would cause problem for 3GPP
> implementations but I don't really know.  I'm not sure any reason
> that a URI in a PAI should ever have , ? or ; and like to hear uses
> cases.

Unfortunately, "," is allowed in generic URIs, and in a number of
places in SIP URIs.

I expect that current practice is to not use P-Asserted-Identity URIs
that contain commas by creating "users" that contain comma.

But if a sender wanted to use such a URI, it could add <...>, making
the PAssertedID-value into a name-addr.  And the receiver is already
required to be able to parse that value.

Actually, isn't this one of the many places where the rule of RFC 3261
section 20 is implicitly applied?

   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.

In the context of implicit application of this rule whenever a syntax
rule uses the construction "name-addr / addr-spec", what is the
problem?  Is it that some implementations do not accept the name-addr
alternative, or do not consider it to be equivalent to the addr-spec
alternatives when the contained URI is the same?

And P-Asserted-Identity looks like it has the same problem:

      PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
                      *(COMMA PAssertedID-value)
      PAssertedID-value = name-addr / addr-spec

Dale

---

From: Brett Tate <[email-masked]>
Date: Wed, 9 Oct 2013 17:46:25 +0000

Hi,

The main issue is that RFC 3261 section 20 has the following bracket rule.

"The Contact, From, and To header fields contain a URI.  If the URI
 not URI parameters."

NOTICE: It does not define a generic rule to indicate that all SIP headers defined to include (name-addr / addr-spec) will follow the same RFC 3261 section 20 bracket rule.  However some RFCs (including RFC 3261 defined Reply-To) do not reiterate the same statement for the headers that are also defined to include (name-addr / addr-spec).  The implementer does not know if it was an oversight or intentional.

Why didn't RFC 3261 apply the same rule to Reply-To?  Anybody know why?

A common response on sip-implementors concerning the (name-addr / addr-spec) ambiguity is to always use the RFC 3261 section 20 bracket rule (even when no RFC indicates to do it).

However, RFC 3325 introduces a dilemma from a decode perspective for P-Asserted-Identity and P-Preferred-Identity since these headers do not contain parameters.  If the header was received without using brackets, does the presence of a parameter decode as 1) uri parameter, 2) malformed, or 3) assume someone expanded the ABNF to include header-parameters.

If you just look at RFC 3325, option 1 is appropriate.

If you apply the RFC 3261 section 20 bracket rule, option 2 or 3 is appropriate.

As reflected within the following thread, I can be easily convince either way. :)

https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-October/029421.html

> Incidentally, I don't think there's actually an ambiguity here, 
> since ",", "?", and ";" don't have any defined meaning when used 
> in P-Asserted-Identity. 

A semicolon has the same meaning within a P-Asserted-Identity's sip-uri as it does within From sip-uri.  It can separate parameters.  However ignoring RFC 3261 section 20 bracket rule, I agree that it does not cause ambiguity concerning P-Asserted-Identity and P-Preferred-Identity since the ABNF does not allow the headers to contain parameters.

A comma has the same meaning within P-Asserted-Identity as it does within a Contact.  It can separate entries.

The question mark has the same meaning within P-Asserted-Identity as it does within a Contact sip-uri.  It can seperate the headers from other part of the sip-uri.

Thus the RFC 3325 ambiguity; no text was added to indicate if the RFC 3261 section 20 bracket rule fully applies, partially applies, or does not apply.  Anyone know why RFC 3261 section 20 bracket rule was defined for To, From, and Contact but not Reply-To, P-Asserted-Identity and P-Preferred-Identity (I assume that there are others)?

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 14:39:27 -0400

I think I'm in agreement with Adam, but am not certain about his position.

IMO there is *no bug* in 3325 in this regard. Its inconsistent with the 
"normal" processing of headers that have name-addr/addr-spec, but that's 
just ugly, not a bug.

The reason for the special rules in 3261 is because without them the 
syntax is ambiguous. E.g., in:

	To: sip:foo@bar,baz

the comma could introduce a sip uri parameter, or it could end the sip 
uri and introduce a To header field parameter.

But P-Asserted-Identity has no syntax for header field parameters, or 
anything else, after the name-addr/addr-spec, so there is no ambiguity. 
The comma unambiguously introduces a sip URI parameter.

As Adam notes, this is unpleasant for implementers. Sorry.

	Thanks,
	Paul

On 10/9/13 11:55 AM, Adam Roach wrote:
>> P-Asserted-Identity header field value URI encoding when the URI has a
>> , ? or ;. There are basically two ways we go to resolve this
>>
>> implementations but I don't really know.
>

---

From: Brett Tate <[email-masked]>
Date: Wed, 9 Oct 2013 19:13:51 +0000

You can ignore my mentioning of Reply-To.  The rule is within RFC 3261 section 20.31.

"Even if the "display-name" is empty, the "name-addr" form MUST be
 used if the "addr-spec" contains a comma, question mark, or
 semicolon."

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brett Tate
> Sent: Wednesday, October 09, 2013 1:46 PM
> To: SIPCORE (Session Initiation Protocol Core) WG
> Subject: Re: [sipcore] Bug in RFC 3325
> 
> Hi,
> 
> NOTICE: It does not define a generic rule to indicate that all SIP
> headers defined to include (name-addr / addr-spec) will follow the same
> RFC 3261 section 20 bracket rule.  However some RFCs (including RFC
> 3261 defined Reply-To) do not reiterate the same statement for the
> headers that are also defined to include (name-addr / addr-spec).  The
> implementer does not know if it was an oversight or intentional.
> 
> A common response on sip-implementors concerning the (name-addr / addr-
> spec) ambiguity is to always use the RFC 3261 section 20 bracket rule
> (even when no RFC indicates to do it).
> 
> However, RFC 3325 introduces a dilemma from a decode perspective for P-
> Asserted-Identity and P-Preferred-Identity since these headers do not
> contain parameters.  If the header was received without using brackets,
> does the presence of a parameter decode as 1) uri parameter, 2)
> malformed, or 3) assume someone expanded the ABNF to include header-
> parameters.
> 
> A semicolon has the same meaning within a P-Asserted-Identity's sip-uri
> as it does within From sip-uri.  It can separate parameters.  However
> ignoring RFC 3261 section 20 bracket rule, I agree that it does not
> cause ambiguity concerning P-Asserted-Identity and P-Preferred-Identity
> since the ABNF does not allow the headers to contain parameters.
> 
> A comma has the same meaning within P-Asserted-Identity as it does
> within a Contact.  It can separate entries.
> 
> The question mark has the same meaning within P-Asserted-Identity as it
> does within a Contact sip-uri.  It can seperate the headers from other
> part of the sip-uri.
> 
> Thus the RFC 3325 ambiguity; no text was added to indicate if the RFC
> 3261 section 20 bracket rule fully applies, partially applies, or does
> not apply.  Anyone know why RFC 3261 section 20 bracket rule was
> defined for To, From, and Contact but not Reply-To, P-Asserted-Identity
> and P-Preferred-Identity (I assume that there are others)?
> 
> Thanks,
> Brett
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 15:13:20 -0400

Oops! Obviously my earlier reply was wrong, because I suggested that 
PAID didn't allow anything after the name-addr/addr-spec. Since it 
allows comma it does have an ambiguity that needs some clarification to 
resolve.

I suppose *in principle* (using arbitary amounts of look ahead) it would 
be possible to resolve the ambiguity. But that is unreasonable.

So I take it all back and agree there is a bug.

	Sorry,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 9 Oct 2013 19:49:27 +0000

> In the context of implicit application of this rule 
> whenever a syntax rule uses the construction 
> "name-addr / addr-spec", what is the problem?  

RFC 3325 introduces a dilemma from a decode perspective for P-Asserted-Identity and P-Preferred-Identity since these headers do not contain parameters.  If the header was received without using brackets, does the presence of a parameter decode as 1) uri parameter, 2) malformed, or 3) assume someone expanded the ABNF to include header-parameters.

> Is it that some implementations do not accept the 
> name-addr alternative, or do not consider it to be 
> equivalent to the addr-spec alternatives when the 
> contained URI is the same?

It is the applicability of the bracket rule from a decode perspective when headers such as P-Asserted-Identity and P-Preferred-Identity contain semi-colon (or comma or question mark) when there are no brackets.

>From RFC perspective, the RFC 3261 section 20 bracket rule explicitly applies to To, From, and Contact.  There is nothing to indicate that it fully applies, partially applies, or does not apply to P-Asserted-Identity and P-Preferred-Identity.

Thanks,
Brett

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 10 Oct 2013 11:21:02 -0400 (EDT)

> From: Brett Tate <[email-masked]>

> However, RFC 3325 introduces a dilemma from a decode perspective for
> P-Asserted-Identity and P-Preferred-Identity since these headers do
> not contain parameters.  If the header was received without using
> brackets, does the presence of a parameter decode as 1) uri
> parameter, 2) malformed, or 3) assume someone expanded the ABNF to
> include header-parameters.
> 

Yuck.

Given the possibility that someone has added header-parameters, then
the grammar as specified (without assuming section 20) is ambiguous.
So "the answer" depends on actual practice.  Fortunately, 3GPP is a
fairly small community.

Can we lobby everybody to start applying section 20 when they send
requests?

Dale

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Oct 2013 10:28:20 -0500

> Can we lobby everybody to start applying section 20 when they send

That's the proposal made by the erratum on the table, and (I think) the 
cleanest way to deal with the situation.

/a