Subject: [Sip] updated GRUU spec

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Sep 2005 04:38:03 -0400

I've just submitted an update to the GRUU spec. Until it appears in the 
archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-sip-gruu-05.txt

Changes are based on things we agreed on in Paris, along with some 
additional private comments I received since then. There are no open 
issues with the spec that I am aware of.

Here are the changes:

* To header field in SUBSCRIBE examples now contains the gruu too

* clarified that a UAS can't tell whether a grid-less request was sent to a
gruu or AOR by inspection of r-uri; To header field might work, but even
then not in forwarding cases

* construction of gruu now associated with inclusion of an instance ID
in registration, not with inclusion of Supported: gruu in register
request. Supported now just indicates that gruu is included in
response.

* added some intro text explaining what the "opaque" URI parameter is,
and added more text in the section that defines it. Gave examples of other
usages besides gruu, and clarified that any element that receives a URI
with the opaque parameter can strip it to get the original URI.

* added some words on service treatment for Replaces and Join
requests:

The service treatment property merits further discussion. Typically,
the services a proxy executes upon receipt of a request sent to a GRUU
will be a subset of those executed when a request is sent to the
AOR. For requests that are outside of a dialog, it is RECOMMENDED to
apply screening types of functions, both automated (such as black and
white list screening) and interactive (such as interactive voice
response (IVR) applications which confer with the user to determine
whether to accept a call). In many cases, the new request is related
to an existing dialog, and may be an attempt to join it (using the
Join header field <xref target="RFCJOIN"/>) or replace it (using the
Replaces header field <xref target="RFCREPLACES"/>). In such cases,
the UA will typically make its own authorization decisions, allowing
the reuqest if the sender can prove it knows the dialog identifiers
<xref target="I-D.ietf-sip-target-dialog"/>. In such cases, it might
make sense to bypass screening services, but network designers need to
carefully consider this, as it depends on the specific type of
screening service.

* clarified what the domain of the GRUU is

* there can actually be more than one GRUU for an instance ID/AOR pair
(think aliases or multiple public ID in IMS terms), and this is now
pointed out. However, the gruu spec doesnt provide a way to ask for or
get more than one.

* the draft had claimed that the AOR and GRUU properties are mutually
exclusive. They usually are, but one can construct use cases where it
is not true. So, this restriction is no longer discussed.

* fixed some conflicting text on usage of UUID URN as the instance ID
(it is at SHOULD strength)

* clarified that lack of direct UA-to-UA signaling doesnt apply to
administratively constructed gruu

* wordsmithing to align with sip-outbound rules

* clarified that Path is not required for gruu

* when a register contains a instance ID, the instance ID must
identify the endpoint doing the registration.

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 28 Sep 2005 13:02:34 +0200

Jonathan,

Not sure if this has been discussed already, but currently the draft states 
that in order to determine if the remote target is a GRUU, the UA must look 
for a 'Supported: gruu' header.

Wouldn't it make sense to make this property explicit in the URI itself, 
e.g. by requiring that a GRUU MUST contain a 'gruu' parameter flag?
This would address the requirement that "A server in the domain can 
determine that the URI is a GRUU" (section 6), in fact it would allow any 
entity to determine that the URI is a GRUU.

This would help a UA in all use cases  (4.1 (REFER) for the Refer-To URI, 
4.2 for the conference URI, and 4.3 for the Contact information in PIDF) to 
determine that the URI is in fact a GRUU. I think putting it as a URI 
parameter may also have benefits in authentication scenario's (it would be 
included in the digest calculation).

Putting it as a question: is REQ 8 broad enough to cover all use cases? 
Wouldn't "to know that the URI represents a GRUU" also be required outside 
of a dialog, e.g. when obtaining the URI from a PIDF document?

Regards,

Jeroen van Bemmel