Subject: [Sip] updated GRUU spec

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Feb 2005 00:12:03 -0500

Folks,

I posted an updated version of the GRUU spec, which just popped out:

http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-03.txt

In the end, I did NOT change the fundamental mechanism per our 
discussions on the list; its still based on getting the gruu in the 
register response. There were lots of other text changes to improve 
clarity and make it simpler. The biggest changes were that the server 
will now overwrite the registration from a particular instance when a 
new one arrives. I've also punted on the issue we've been debating the 
last two meetings, on whether multiple contacts from a single instance 
can be registered.

Here are the detailed changes:

* instance parameter has to be a URN

* equality rules for instance ID are now equal to the function rules
for that URN scheme, else lexical URN rules if the scheme is
unknown. Mentioned that this is unliekly to be a problem, and that
clients should just use the same instance ID in all registrations

* rewrote introduction to do a much better job at motivating why you
should care about this draft

* added back the GRUU property of long-livedness, but comment that
this property cannot be guaranteed

* clarified that gruus are resolved using normal rfc3263 procedures

* substantial rewrite of the normative behaviors in order to simplify
the explanation, including an updated simpler UML model.

* previously, behavior was not specified when a contact expired. That
is now specified - its binding to both the AOR and GRUU are removed

* previously, if a Contact with an instance ID arrived and there
already was a contact with that instance ID registered, an error
response is returned. Now, the new contact replaces the previous
one. The 425 response code is therefore no longer needed, and has been
removed.

* SIP/SIPS handling is now specified - both a SIP and SIPS version of
a GRUU have to exist. The scheme used for the GRUU in the register
response is equal to that of the To in the REGISTER request. Little
else is said about sips processing; it should work equally to a sips
AOR (which is admittedly underspecified in RFC3261, but its not GRUU's
problem to fix that)

* clarified proxy processing by showing exactly how the processes of
section 16 in rfc3261 are affected - its just a different abstract
locatoin service

* note that Path (rfc3327) processing applies to GRUU as well

* sustantial text added to discuss the interactions with
record-routing and how to avoid the spiral that can ensue if you are
not careful

* clarify that if the contact in a register had a grid for some reason
(not a good idea), it would be overwritten with the grid value in a
gruu that is translated to that contact

* during discussions in the last few meetings, it was proposed that
multiple contacts of the same instance be allowed to register for a
gruu. This is useful only for supporting high availability in
clients. However, the requirements do not include such a
capability. As such, I went with the simpler approach as currently
documented, with a single contact for each instance. The high
availability work will require us to rethink the registration data
model more seriously, and should be relegated to a different spec that
can modify gruu processing if needed. draft-jennings-sipping-outbound
seems the right forum for that

* updated example based on new rules for conflict resolutions

* removed IANA registration for response code

* the conflict resoltuion algorithm provides a neat way to remove any
contact with a specific instance ID; the equivalent of * but targeted
to a specific instance ID, and this is documented

* tried to clean up terminology, since "contact" and its variants are
used all over the place with different meaning

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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