Subject: RE: [SIP] SIP Registration interval

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 14 Mar 2001 11:41:28 -0600

Interval - Sounds good, Jonathan. (i.e. let the server decide on the wanted
interval, without limiting it in any direction. Have the client take it from
the server as is)

number of Contacts - Basically agree with what you say. have a question
though... Would it be silly/redundant/possible of a client to use the
OPTIONS request to find out if there is an upper bound limitation on number
of contacts it can use with given server? (I think it may be beneficial for
a client that serve many users (e.g. multi user host) and have many hits
with the same registrar) (I know it may sound like an implementation
question..)

===========================================
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
===========================================

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 10:01 AM
> To: 'Henning Schulzrinne'; Baniel Uri-CUB001
> Cc: 'Iliff, Tina'; 'Sean Olson (EUS)'; [email-masked]'
> Subject: RE: [SIP] SIP Registration interval
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Thursday, March 08, 2001 10:55 AM
> > To: Baniel Uri-CUB001
> > Cc: 'Iliff, Tina'; 'Sean Olson (EUS)'; [email-masked]'
> > Subject: Re: [SIP] SIP Registration interval
> > 
> > 
> > I suspect many clients already simply take the refresh 
> > interval from the
> > server, rather than doing a min(client,server) operation. Maybe it
> > wouldn't hurt to put that into the spec, as it doesn't seem 
> > to cause any
> > backwards-compatibility problems. (At worst, clients refresh more
> > frequently than they have to.) I'm against imposing any 
> > arbitrary fixed
> > lower value, for the same reasons that I outlined with 
> regards to the
> > number of Contact entries.
> 
> I agree with Henning. I believe we should change the wording 
> such that the
> client should use the refresh interval as specified in the 
> 2XX registration
> response, whatever the value. We would then strike the rule that the
> registrars SHOULD NOT increase the value. I don't even recall 
> why we put
> this directionality constraint in there (can only decrease, 
> not increase).
> Henning, do you recall?
> 
> As per number of Contacts, I also agree that the spec should 
> remain silent
> on this. In general, a server may decide not to service a 
> request for many
> reasons. It may not want to support multiple contacts, or it 
> may allow users
> to register only specific contacts. Rather than define 
> specific headers for
> each of these cases (which, in many cases, there is nothing 
> the client can
> do anyway), the server can simply respond with a 500 class 
> response, and
> include something textual in the reason phrase. 
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 14 Mar 2001 13:56:25 -0500

Baniel Uri-CUB001 wrote:

> with the same registrar) (I know it may sound like an implementation

This is another direction I don't think we want to go to. As stated, in
almost all reasonable cases, clients should never, ever have to worry
about these things. Otherwise, instead of implementing OPTIONS to say
"sorry, I only support 7 Contact headers", developer effort is much
better spent increasing that limit to effectively infinity (which, in
practice, you have to work hard it not to be). This is a deep rat-hole,
as the policy restrictions on registrations are endless. Do you want to
construct a language that says "Sorry, being MSN, I don't accept yahoo
mail addresses, and by the way, email addresses can only be 25
characters long and I don't like the letter "Z" since Sesame Street
hasn't gotten around to that one yet; please also avoid registering tel:
URLs on Fridays, and certainly don't register any 10288 tel: URL since
I'm paid by AT&T; also, don't register http://www.whitehouse.com as your
URL, since it's a porn site."?

In short: for parameters that have to have reasonable limits and where
policy comes into play, this is a network management issue. For
everything else, the old maxim "Computer Science only knows three
numbers, zero, one and infinity" is a good one.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs