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

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Jan 2002 16:09:47 -0500

> --- Robert Sparks <[email-masked]> wrote:
> > 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.
> 
> 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.

Other than I forgot to do so?

With the exception of having to accept a small margin
of error I disagree that explicit de-registration is
called for. Why would you require me to go in and say
"I'm not here anymore" when you allow me to say "I'm
here for 20 minutes". If you _don't_ allow me to say
"I'm here for 20 minutes" (which is the effect of allowing
a server to extend the time), then why are you pretending
to carry around expirations? From a user's perspective,
everything becomes hard state, with all the fail-cases
hard state brings.

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

Eventually, someone will find something where changing
1 minute to 1 hour would be just as damaging.

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

This is a better direction to go.

>  
> > RjS
> /sean
> 
> 
> =====
> --
> Sean Olson <[email-masked]>
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
> 

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Tue, 15 Jan 2002 23:24:07 -0500

> Eventually, someone will find something 
> where changing 1 minute to 1 hour would 
> be just as damaging.

That is a two way street.  A registrar with
100,000 subscribers might not desire to 
accommodate its users extending contact
expirations through registrations every 30 
seconds.  However I guess this gets into
an issue of billing for capacity-usage.

> This is a better direction to go.

The problem with returning a new error response 
is that non-bis compliant UAC's would reduce the
response to 400.  Thus it might actually produce
more registrations and restrict the user from 
receiving calls until customer support 
communicates what the timer should be.

The 403 with Expires or a new header could 
potentially be used to avoid such a situation.
The UAC could automatically adjust the expiration
or at least communicate the minimum to the user.
The advantage is that older UACs SHOULD NOT 
retry the REGISTER without modifying something 
(excluding authorization) associated with the 
REGISTER request; changing the expiration value 
should produce another registration try.

Taking it one step further, we could add a new
parameter to Contact which could indicate that
the UAC currently does not intend to refresh 
the contact beyond the indicated expires value.  
This should calm nervous registrars to start 
allowing short expiration values under the 
pre-text that a 403 would be honored if such 
a contact gets refreshed too often.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 19:18:01 -0500

I would really like to resolve this one finally.

 From what I can tell, people seem to agree that,
generally speaking, the registrar shouldn't
increase it, and if the interval is too low,
it can reject it.

Brett's concern is backwards compatibility. However,
I think I have an easier answer for that.

I suspect there are zero existing UA's that ever include
an expires less than one hour. So, as long as we mandate
that a proxy support registrations of at least one
hour (i.e., it not reject registrations greater than one hour
because they are too short), we'll be backwards compatible in practice.

So, to summarize:

1. registrars can't increase the interval
2. registrars must not reject registrartions less than
one hour
3. registrars may reject registrations less that one
  hour, with some TBD response code

May I please hear a yea/nea from the people in this thread??

-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

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 17 Jan 2002 22:08:50 -0500

> I suspect there are zero existing UA's that 
> ever include an expires less than one hour.

I am aware of some that allow configuration
values of less than one minute (even without
clear indication that the units are in
seconds).

> 2. registrars must not reject registrartions 
> less than one hour

I assume you meant 'more' instead of 'less' in 
the above sentence?

> 3. registrars may reject registrations less 
> that one hour, with some TBD response code

Registrars choosing to return this, would
break Robert's example of using the REGISTER's
expiration for indicating temporarily 
reach me on conference room phone.  
However I guess that would be the registrar's 
decision to bar such an example or expose
itself to incorrect/malicious provisioning
of a device.
 
> May I please hear a yea/nea from the people 

Sounds fine to me.

Can the bis please suggest what should happen 
when a 400 response is received for a REGISTER?
This maybe would give a little encouragement
to vendors to quit retrying or back off to 
retrying no more than once every 30 minutes 
after getting a few 400's (or unknown 4xx's).  
I mention it in case item 3 turns a new response 
code instead of a 403.

-- Warning the following is completely unrelated 
-- to the thread but is similar to the above
-- suggestion; so if you respond to it, 
-- please start a new thread since I'm
-- not intending to sidetrack this one.

Can the bis please suggest what should happen 
when a 401 response is received for a REGISTER
when the UAC can't generate an Authorization
header for the challenge?
This maybe would give a little encouragement
to vendors to quit retrying or back off to no 
more frequent than once every 30 minutes.  
Some like to ping-pong the REGISTER (without 
Authorization header) and 401 until the 
registrar returns a 403, 404, 405, or 501.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jan 2002 11:13:58 -0500

Inline.

> clear indication that the units are in

Sure, but in actual usage I believe most are using 3600s.

> I assume you meant 'more' instead of 'less' in 

Yes, sorry.

> itself to incorrect/malicious provisioning

Right. I suspect that the threshold for most devices will be less than 
3599 anyway ;) All we need is a discussion in bis to make sure people 
are aware that expiring registrations is needed for specific services, 
and that the duration may not be arbitrary.

>>May I please hear a yea/nea from the people 

Great!

> I mention it in case item 3 turns a new response 

Such text is already in bis. In 23.4, it says:

4xx responses are definite failure responses from a particular server. 
The client SHOULD NOT retry the 4257
same request without modification (e.g., adding appropriate 
authorization). However, the same request to a 4258
different server might be successful. 4259

i.e., if you get any 4xx, you have to change the request before 
resubmitting it. That covers your 401 case as well.

Robert Sparks wrote:

> It would be good to specifically capture that registrars mustn't reject
> the request only because they wanted the expiration to be longer
> (we still want to be able to return 401s, 503s, etc).

Right.

> 
> I would ask to make this a SHOULD and not a MUST. In no version
> of the spec to date has there been a requirement that I, as a registrar,
> MUST accept a registration of a given duration - I've always had
> the option to refuse it if it violated some policy of mine.
> A MUST here also builds another good candidate for future-failure
> (those places where we have pain fixing problems in the future because
> of backwards compatibility). Do you really want to close off the
> functionality of the TBD response below to long expirations forever?
> Or would it be better to recommend the hour threshold and have
> implementors anticipating change?

I think SHOULD is OK.

> 
> That said, don't hold up closing it based on these comments.

I think we are done with this one. Text for it will appear in bis-06. It 
will require the usage of a new response code (423), and a new header in 
that error response to indicate the minimum desired interval (probably 
Min-Expires).

-Jonathan R.