Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-10.txt

From: [email-masked]
Date: Tue, 01 Aug 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-gruu-10.txt
	Pages		: 40
	Date		: 2006-8-1
	
Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI that can be used
by anyone on the Internet to route a call to that specific UA
instance.  A URI that routes to a specific UA instance is called a
Globally Routable UA URI (GRUU).  This document describes an
extension to SIP for obtaining a GRUU from a server and for
communicating a GRUU to a peer within a dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-gruu-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-gruu-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Thu, 3 Aug 2006 18:02:21 -0500

Hi Jonathan,

I'm having some problem reconciling parts of gruu-10 with RFC 3261.

(This problem is not gruu-specific, it also applies to the sips
guidelines
draft).

In section 7.1.2 of gruu-10:

   A registrar MUST create both the SIP and SIPS versions of the GRUU,
   such that if the GRUU exists, both URI exist.

...and later in 7.1.2.1 of gruu-10:

   If the To
   header field in the REGISTER request contains a SIP URI, the SIP
   version of the GRUU is returned.  If the To header field in the
   REGISTER request contains a SIPS URI, the SIPS version of the GRUU is
   returned.

However, in RFC 3261/19.14:

   Some operations in this specification require determining whether two
   SIP or SIPS URIs are equivalent.  In this specification, registrars
   need to compare bindings in Contact URIs in REGISTER requests (see
   Section 10.3.).  SIP and SIPS URIs are compared for equality
   according to the following rules:

      o  A SIP and SIPS URI are never equivalent.

It's not clear to me what this all means...

Are we saying that when we register, it really doesn't matter if the
AOR,
and Contact (and GRUU) are SIP or SIP because both will end up being 
"created"?

The distinction between the two in registration would therefore be
purely mechanical (i.e., if AOR is SIP, Contact/GRUU is SIP, and if 
AOR is SIPS, Contact/GRUU is SIPs)?

So SIPS and SIP are somehow synchronized bingings, but are "not 
equivalent" (they seem pretty "equivalent" to me...).

This is quite confusing...

Can you clarify what you think it means?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Aug 2006 15:32:02 -0400

inline.

> and Contact (and GRUU) are SIP or SIP because both will end up being 

It is true that SIP and SIPS URI are never equivalent based on URI 
comparison, but they always point to the same resource, and if one of 
them exists in a domain, so too does the other.

> AOR is SIPS, Contact/GRUU is SIPs)?

GRUU is discussing the mechanical aspect. Its trying to skirt the bigger 
issue of what it means to register a SIPS AOR in the To, vs. a SIP AOR. 
It just says what happens with GRUU processing depending on which you 
do. Indeed, we could decide later on to disallow a SIPS URI in a To 
header field of a REGISTER, and the GRUU spec remains valid.

I'm really hoping to not have to figure out the whole sips mess to 
progress GRUU.

-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

---

From: [email-masked]
Date: Sun, 20 Aug 2006 15:08:50 -0400

From: Jonathan Rosenberg <[email-masked]>

   [...]

>From an implementor's point of view, the sip/sips questions seem
entirely orthogonal to the GRUU mechanisms.  It's quite possible that
the official rules for validity of sip and sips are flouted by many
implementations, but for sanity's sake, everyone follows the rule:  If
both the sip and sips version of a URI are valid, (1) they route to
the same resource (or collection of resources), and (2) and
manipulation that affects the validity or the set of resources
targeted by one automatically affects the other in exactly the same
way.

As the GRUU proposal follows the above rule of thumb, I don't see why
we need to settle or take a stand on *any* sips question to progress
this I-D.

Dale