Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-lease-00.txt

From: [email-masked]
Date: Thu, 13 Feb 2003 11:15:14 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: URI Leasing in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-rosenberg-sipping-lease-00.txt
	Pages		: 23
	Date		: 2003-2-12
	
Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI which can be used
by anyone on the Internet to route a call to that specific UA
instance.  An example of such an application is call transfer, based
on the REFER method.  To date, a variety of techniques have been
proposed for the contruction of such URI.  All of them have fatal
drawbacks.  This document proposes that the problem is actually one
of URI leasing - a feature whereby a UA can dynamically request the
creation of an address-of-record (AOR) within a domain.  Requirements
for a URI leasing mechanism are outlined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-lease-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rosenberg-sipping-lease-00.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-rosenberg-sipping-lease-00.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.

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 17 Feb 2003 11:00:37 -0500

> 	Filename	: draft-rosenberg-sipping-lease-00.txt
In general I like the direction this is going. I have a query. Did you 
consider making the creation and communication of the GRUU simply a 
side-effect of a REGISTER operation as opposed to a separate method? In 
other words, the REGISTER would optionally request the construction of a 
(range of/template for) GRUUs for the UA, and the response would contain 
the constructed values. This would seem to meet all of the requirements, 
including, at least provisionally, the requirement for not substantially 
increasing the domain-level state stored by proxies.

One small point bears upon the above. In the text you say that a lease 
should not extend beyond the registration expiration of a registered UA. 
However, the requirement is weaker; it only says that the domain has final 
say over the lease duration. Was this intentional? If so I would think this 
complicates the life of a registrar somewhat, compared with managing GRUUs 
just like registrations, or state directly bound to registrations. I can 
see a rather straightforward implementation if leases are simply extra 
stuff associated with a registration. I have a harder time seeing a simple 
implementation if a new method or some completely separate mechanism is 
used.

Dave.

Dave.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Wed, 19 Feb 2003 19:44:54 -0600

>increasing the domain-level state stored by proxies.

I like this approach.  It also solves the problem of how a UA finds out if 
it needs to lease a URI or not and whether the registrar supports 
it.  Otherwise, it must either send an OPTIONS to the registrar or find out 
with a 501 that the registrar does not support a LEASE method.  I also 
don't think a UA can tell if it's Contact is routeable, but the registrar 
can (or should).    As a result UA might lease a URI that it in fact 
doesn't need if its Contact is already globally routeable which would 
needless increase stored state.

If the leased URI is returned in a new header or Contact parameter, the 
registrar would only do so if the UA needs it - if the Contact URI in the 
REGISTER is already globally routeable (no screening proxies, 
firewalls/NATs, etc.) then the registrar would not return any value.  UAs 
that didn't support the extension would simply ignore.  A UA supporting the 
extension would use the returned leased URI instead of the one that it 
registered with.

>say over the lease duration. Was this intentional? If so I would think 
>this complicates the life of a registrar somewhat, compared with managing 
>GRUUs just like registrations, or state directly bound to registrations. I 
>can see a rather straightforward implementation if leases are simply extra 
>implementation if a new method or some completely separate mechanism is used.

And the separation can cause problems - a UA that wishes to watch the state 
of its registration and lease would have to watch both because if either 
one fails, then requests will fail.  Seems better to combine the two for 
the reasons Dave mentions.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]