Subject: [Sipping] Re: [Sip] Originating Line Information

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Sep 2002 14:49:32 -0400

Moving to sipping.

Another option is caller preferences. We could register parameters for 
these various things, which would allow you to do things like:

INVITE
Contact: <sip:1.2.3.4>;prison="TRUE";methods="INVITE,BYE,BLOWUPMYPHONE"

and so on.

This leads to a question we haven't really discussed in too much depth 
yet - when does descriptive information belong as a tel/SIP URI 
parameter, and when does it belong as a caller prefs contact parameter?

My general take on this is that things which describe characteristics of 
a URI - such as the MIME type of the document being referenced, or the 
color of the phone it desribes, are not part of the URI, but belong in 
the realm of things like caller prefs which desribe URIs. The URI, IMHO, 
should contain the minimal amount of stuff.

-Jonathan R.

Peterson, Jon wrote:
> This is more a SIPPING issue than a SIP issue... but yes, I was hoping that
> my proposal for a calling party's category tel URL parameter cover this (it
> speaks to the fact that in North American networks, the OLI is often the
> repository for information that appears in the CPC elsewhere). The draft
> happens to be expired at the moment, though I will be resubmitting it fairly
> soon.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
>>-----Original Message-----
>>From: Romel Khan [mailto:[email-masked]]
>>Sent: Wednesday, September 11, 2002 2:47 PM
>>To: [email-masked]'
>>Subject: [Sip] Originating Line Information
>>
>>
>>Is there any existing internet draft that talks about how to pass
>>Originating Line Information (e.g. hotel, motel, prison) in SIP?
>>_______________________________________________
>>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
>>
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Sep 2002 15:01:36 -0400

In general, I think the basic rule should be "if the URI is different, 
the resource is a different resource". This doesn't have to be true all 
the time, but the URI is after all an *identifier*, not a description. 
The URI should also be somewhat permanent and publishable.

At least for the prison or motel phone, these are hopefully temporary 
conditions, unless the URI identifies the jack-in-the-wall rather than 
the person answering.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Sep 2002 15:07:02 -0400

Henning Schulzrinne wrote:
 > In general, I think the basic rule should be "if the URI is
 > different, the resource is a different resource". This doesn't have
 > to be true all the time, but the URI is after all an *identifier*,
 > not a description. The URI should also be somewhat permanent and
 > publishable.
 >
 >  conditions, unless the URI identifies the jack-in-the-wall rather
 > than the person answering.

Agreed.

This also seems to be in line with a general trend towards "late 
binding" for URIs, whereby as much information as possible is obtained 
through lookups or external information. This includes things like ports 
even, which can be obtained from the SRV records, or inclosed in the 
URI. My perception from the URI community (and I could be wrong) is that 
its better to NOT include them in the URI, and get them from DNS 
wherever possible.

-Jonathan R.