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
Andrew Allen wrote:
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 protected] [mailto:[email protected]] On Behalf Of
Florian Zumbiehl
Sent: Sunday, April 12, 2009 10:55 PM
To: [email protected]
Subject: [Sip] bug in draft-ietf-sip-gruu-15 grammar
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 protected]>;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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] 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.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
