Subject: [Sip] Re: GRUU-10: Storing state at the binding-agent (GRUU-factory?)

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Sep 2006 09:09:25 -0400

Thanks for the comments Robert. Replies inline.

Robert Sparks wrote:

> gruu-10 has a mixed message about the requirements on the overall  
> system for saving information about the existence of GRUUs.
> 
> It notes on page 13 that
> * "for any particular AOR, there can be a potentially infinite number  
> of GRUUs"
> and goes on to say
> *"it is RECOMMENDED that a GRUU be created at the time a contact with  
> an instance ID is first registered to an AOR (even if that  registration 
> indicates that the registering UA doesn't even support  GRUUs)
> 
> This section implies that new state is created at the thing that  "owns" 
> GRUUs for each new GRUU that gets created, and recognizes that  
> _clients_ can ask that thing to create an infinite number of them.  
> Later in that section it talks about the difficulty of maintaining  this 
> state across reboots and power-failures.
> 
> A little later (page 15) it notes again that a UA MUST be prepared to  
> receive a different GRUU for the same instance-id/AoR pair in  
> subsequent registrations because this owning-thing might lose state.
> 
> But, off in the appendix, in sections describing the creation of  GRUUs 
> it talks about building them such that this owning-thing  doesn't have 
> to create new state.
> 
> Is there a real requirement to keep state here or not?

As others have commented, the spec purposefully allows an implementation 
to go either way and be compliant. Thus there is no requirement for 
statefulness.

> 
> I don't think we meant there to be in the end, and that some of the  
> text is legacy and just needs to be elided or adjusted, but I can't  
> tell for sure, so let me ask the question another way:
> 
> Is it OK for me as a proxy that has the responsibility for  retargeting 
> GRUUs to _always_ return a 480 to a GRUU that I recognize  as feasibly 
> mine (cryptographically perhaps), maps correctly  (whatever that means) 
> to an AoR in good standing, but has no current  registered contact 
> associated with it EVEN IF I have no record of  dealing with that 
> particular instance-id ever before?
> 
> I think it is.

Yes, it is.

Indeed, I think 8.2.1 is quite explicit on this point:

If the Request-URI is within the domain of the proxy,
    contains a "gruu" URI parameter, and the GRUU is known within the
    domain and refers to a valid AOR within the domain, but the instance
    ID is unknown, the proxy SHOULD generate a 480 (Temporarily
    Unavailable).

Perhaps the confusion is around what it means to be 'known'. What I 
meant here, is for stateless registrars, it would mean that the AOR is 
something you recognize and the opaque param is formatted appropriately 
and could belong to your domain. For stateful, it would mean that the 
GRUU is in the database itself.

> 
> Furthermore, I suspect would be an error to return, say, a 404 in the  
> circumstance above - if I'm wrong, then we need text that reinforces  
> that a 404 to a GRUU doesn't say a thing about the existence or  
> viability of an AoR that might be derivable from that GRUU. Same with  410.

You are correct.

> 
> So if the intent is not to require infinite state storage, can we  tune 
> that language out?
> (If it was the intent, then we've got other text discussing those  
> ramifications that needs to go in).

Suggestions?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.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