Subject: [Sip] bug in draft-ietf-sip-gruu-15 grammar

From: Florian Zumbiehl <[email-masked]>
Date: Mon, 13 Apr 2009 04:54:31 +0200

Hi,

draft-ietf-sip-gruu-15 contains (amongst others) these ABNF rules:

| contact-params  =/ temp-gruu / pub-gruu
| temp-gruu       =  "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair )
|                    RDQUOT
| pub-gruu        =  "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair )
|                    RDQUOT

which, when adding them to the grammar from RFC 3261, would produce
from <Contact> a language that's a superset of the language that would
be produced by <Contact> from RFC 3261-only.

In particular, the language produced by <foo> is a subset of the
"GRUU extended" language, but not of the RFC 3261-only one:

| foo = "m: <sip:[email-masked]>;temp-gruu=" DQUOTE "x" DQUOTE SP CRLF

To put it in more practical terms: the <RDQUOT> in both <temp-gruu> and
<pub-gruu> allow for trailing <LWS>, which <contact-extension> does
not, so an implementation conforming to draft-ietf-sip-gruu-15 could
produce a Contact header that potentially could not be parsable
(except as an <extension-header>) by an implementation conforming
to RFC 3261.

Thus, I would suggest to replace the rules quoted above by:

| contact-params  =/ temp-gruu / pub-gruu
| temp-gruu       =  "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair )
|                    DQUOTE
| pub-gruu        =  "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair )
|                    DQUOTE

This produces the same language, maybe it's a better replacement:

| contact-params  =/ temp-gruu / pub-gruu
| temp-gruu       =  "temp-gruu" EQUAL quoted-string
| pub-gruu        =  "pub-gruu" EQUAL quoted-string

Florian

---

From: "Andrew Allen" <[email-masked]>
Date: Mon, 13 Apr 2009 10:20:37 -0400

If a revision of GRUU 15 is needed then I have one more issue that I
recently identified to be considered in any update.

In 5.1 Processing of a GRUU 

The text seems to indicate that the registrar allocates GRUUs for every
Contact that includes the "+sip.instance" header field parameter.
However "+sip.instance" can be used by UAs that support only outbound
and not GRUU so first the registrar should check that "gruu" option tag
is included by the UA in a Require or Supported header before checking
for "+sip.instance" header field parameters in the Contacts and
allocating GRUUs. There doesn't seem any point in the Registrar
allocating GRUUs if the UA doesn't support them.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Florian Zumbiehl
Sent: Sunday, April 12, 2009 10:55 PM
To: [email-masked]
Subject: [Sip] bug in draft-ietf-sip-gruu-15 grammar

Hi,

Florian
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Apr 2009 10:49:44 -0400

Andrew,

Its been quite awhile and my memory may be getting a little fuzzy on 
this, but...

As I recall there are some very subtle points about this. There are 
cases where someone other than the UA doing the registering may need the 
gruu. So the UA that registers its contact may not support GRUU, the 
gruu need be allocated so others can use it. For instance, if some other 
UA registers the same AOR, and does support gruu, it will get back all 
the contacts, and should get back gruus for all of them. Similarly, any 
who subscribe to the reg event package.

As I recall, the "hello world" example (in the gruu reg event package?) 
would depend on this.

Of course the registrar need not actually assign the gruu until 
something happens that will result in it being observed.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 13 Apr 2009 17:06:02 -0400

> who subscribe to the reg event package.

You're correct.  It was explicitly designed that the registrar would
create a GRUU even if the UA registering did not support GRUU.  In
particular, this GRUU would be visible in reg events for the AoR in
question, which allows *other* UAs that want to know the GRUU of the
registering UA to find it.

(E.g., the sipX open-source PBX takes advantage of this.)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Apr 2009 19:27:32 -0400

Hey, you mean that is actually *used*!

Its nice to learn that what started out as a weird corner case or only 
theoretical interest actually turns up in practice!

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 14 Apr 2009 15:45:07 -0400

> theoretical interest actually turns up in practice!

It turns out to be useful if you are trying to accumulate "busy" status
information for an AoR.  In theory, you can just send a dialog event
SUBSCRIBE to the AoR, but that tends to get forked to the voicemail
server, etc.  What you really want to do is subscribe to reg events for
the AoR, and then do individual dialog event subscriptions to every
contact for the AoR.  That way, you're talking directly to each
line-appearance of the AoR.  And if you can get a GRUU for a contact,
you subscribe using the GRUU rather than the stated contact URI, because
that is more likely to avoid NAT problems, etc.

Dale