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

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Aug 2006 16:00:41 -0500

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?

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.

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.

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).

RjS

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Aug 2006 17:43:39 -0400

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.
> 
> 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.
> 

My interpretation of this is:
- there are ways to implement gruu that do not require the
   keeping of state. A registrar may use such a technique
   if it wishes.

- there are other ways of implementing gruu that would require
   the keeping of state. A registrar may use such a technique
   if it wishes. If so, then there are some requirements and
   some recommendations about when, how, and for how long that
   state should be kept. In general it must be kept as long
   as a registration remains valid, and it should be kept longer,
   preferably as long as the AOR remains valid.

> 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, I think so too.

> circumstance above - 

I agree.

> if I'm wrong, then we need text that reinforces 
> viability of an AoR that might be derivable from that GRUU. Same with 410.
> 
> So if the intent is not to require infinite state storage, can we tune 
> that language out?

As above, I think it is there for the case of a registrar that doesn't 
want to embed everything in the gruu. There could be reasons for that, 
so I think it is fair to allow it and to spell out the implications of 
doing so. But maybe this could be made clearer.

I spent some time trying to figure out how to do anonymous gruus. After 
banging my head for awhile I decided to put it off till later. But I 
expect that being stateful may be part of the solution to that. It may 
be ok in that case, because it seems that it doesn't make a lot of sense 
for anonymous gruus to last a long time.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 21 Aug 2006 21:24:57 -0500

On Aug 21, 2006, at 4:00 PM, Robert Sparks wrote:

>
> 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.
>

This is where I think GRUU is wrapped around the axle.

In my world view, a GRUU is just a synthetic or aliased Contact. If  
we could have a "route vector" instead of a Contact, we wouldn't need  
GRUU (except for the anonymization part, which is IMHO bogus).

What happens when you send an request through a proxy to a Contact  
that no longer exists? Why would this say anything about the AOR,  
other than that the contact is stale?

Why should it be different for a GRUU?

--
Dean

---

From: [email-masked]
Date: Fri, 25 Aug 2006 10:30:35 -0400

From: Robert Sparks <[email-masked]>

I think the idea is to allow registrars a lot of latitude in how they
create and handle GRUUs, as long as they produce effects that are
generally what is desired.

OTOH, the draft is careful to compel UAs to behave in ways that
don't restrict how registrars can implement GRUUs.  (E.g., being
prepared for the GRUU to change, despite that the GRUU should never
change.)

   I think it is.

I've started looking at when to use which "address not found" error
(404, 410, 480), and it's not clear to me that distinguishing between
them can be done usefully:

1. Existing implementations are rather sloppy about which response
code to return in various circumstances.

2. I've asked, and implementors do not have a strong and unified
opinion about how the response codes are to be used.

3. The response code is generated in regard to the request-URI that
the ultimate UAS sees, and in the context of the SIP domains that it
is authoritative for (which will often be only its IP address).  Thus,
even if the UAS is exact in which response code it uses, it is in
general impossible for the UAC to know what request-URI that response
code describes.

I think there is some value in restricting 480 to mean that the
request arrived at a UAS that believes that it should handle the call,
but due to some indication from the *user*, the user should not be
notified at this time.  This would be analogous to a 486.  But this
concept works because it takes 480 away from being a routing error,
and turns it into a status indication for the UAS/user.

Of course, this idea means that we need to change the error in the I-D
mentioned by Robert above to something other than 480, one that
specifically means "the AOR is valid but at this time we have no place
to forward it to".  I don't think that there is any code with that
specific meaning now.

OTOH, the assignment of response codes for error conditions has been
sloppy in SIP from the very beginning, so there's no reason to start
being careful now.

Dale