Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Jan 2002 14:25:06 -0500

Ok - a couple of slightly more specific examples:

Web based registration - I goto a conference room and add
the conference room phone to the set of places I can be reached.
This is valid for the planned duration of this meeting only.
Calls to me had best not interrupt my CEO who has the next
reservation on the room.

Any application that uses presence of an unexpired registered
contact in its processing logic. I'm travelling - my softclient
registers a contact with my home service (i'm in the airport using
a commercial 802.11 service). I tell my home service that I'm good
until slightly after I take off to Austrailia. I get called to the
gate and end up turning my laptop off (no clean "unregister").
Applications running 6 hours later (while I'm way out over the
Pacific and unreachable) had best not be basing their processing
on that contact. This would really toast the way some people want
to build presence services for example.

Let me try stating my objection another way.

What does the expiration of a contact header value mean?
I think it means "this URI is only valid for this long" - an expired
header value should not be used. Where does knowledge of the validity
of the contact live? The most authoritative source of that knowledge
is the thing that provides that contact. I say to a server "this URI
is only good for 20 minutes". I know its good for only 20 minutes, 
because I've implemented "explode my phone" and I've set the timer.
Its not OK for the server to turn around and tell someone else
"here's this URI for Robert and it'll be good next Tuesday." That's a
flat-out lie.
Its fine for the server to turn around and tell me "well, I'm glad you have
a URI that's valid
for 20 minutes, but I'm only going to keep it around and tell people its
valid for 10". When it hands that URI off to someone else (which may be its
own routing logic), its handing off a URI that I, as the authority, have
claimed will be valid during that time.

RjS

> >>The real question is how much does it hurt to have
> >>that (soft)state in the network? How critical
> >>is it to your service that the registrar purge
> >>the state at that time?
> >>
> > 
> > Potentially alot. (yes, I know the removal time
> > will be fuzzy, but if I ask for an hour,
> > having stuff stay around for a week will
> > break things).
> 
> 
> I don't feel all that strongly here, as I see points on
> both sides. I think much of the issue depends on whether
> or not registration times are really used to drive services
> or not.
> 
> Robert, I would ask that more specific
> examples be provided to assist in resolving the issue.
> Also, I'd welcome thoughts on some of the other points
> Brett raised, specifically, the fact that there is a backwards
> compatibility issue with sending an error response if the interval
> is too short.
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.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: Sean Olson <[email-masked]>
Date: Mon, 14 Jan 2002 12:45:49 -0800 (PST)

> Calls to me had best not interrupt my CEO who has

In this example, an explicit de-registration is
really needed to avoid interrupting the next party.
And in this specific example, there should be no
reason a de-registration could not be performed.

> to build presence services for example.

This makes sense. What you are talking about is
having an order of magnitude difference between
the requested registration expiration and the 
actual registration expiration. I don't expect this
will happen in practice -- at least not in this
end of the spectrum. I believe it is more likely
that a server would change "1 minute" into "1 hour"
than "1 hour" into "8 hours". But I could be wrong.

> claimed will be valid during that time.

A reasonable argument. The point of extending the
URI lifetime was not to do this kind of thing. It
is meant as a defensive mechanism for the server
to say basically that it's timer resolution is greater
than what you are attempting. I think that is a
reasonable thing to say. If you want to accomplish
this through a 4xx response, that is actually fine
with me. I would like an explicit response code
and header (akin to Retry-After) that would allow
the server to reject the registration and suggest
a more suitable resolution.
 
> RjS
/sean

=====
--
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/