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

[Paul Kyzivat <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Florian Zumbiehl
> Sent: Sunday, April 12, 2009 10:55 PM
> To: [e-mail]
> 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:x@10.0.0.1>;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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
>