Subject: RE: [Sipping] Binding published data to services

From: "James Undery" <[email-masked]>
Date: Thu, 25 Apr 2002 17:20:55 +0100

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]

> > The problem is how to tie the other URIs to their function 
> i.e How do I
> > REGISTER to say push my CPL scripts to
> > http://www.example.com/scripts/james.cpl. I am concerned 
> any REGISTER
> > based solution will be a hack, REGISTER like semantics would make me
> > happier.
> 
> Similar to Content-Disposition and Call-Info, i.e., with a registered
> tag identifying the function of the URI.

This okay we pick a tag compatible with sip, http and various others,
this means we are at risk of interfering with scheme foo.

> It's hard to discuss "hack quotients". Could you be more specific in
> your objections?

It also interfers with "Contact: *, Expires: 0" as we don't want those
function mapped URIs to be removed just the standard ones. If we don't
have this we're back to the configuration problem we were trying to
avoid. (Or thinking about it we could fetch and then restore the
function mapped URIs but I'd definately describe that as hackish and
highly non backwardly compatible.)

James

> > James

_______________________________________________
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, 25 Apr 2002 12:35:42 -0400

> this means we are at risk of interfering with scheme foo.

I suspect that we may have a different notion of how this would work.
I'm proposing something like

Service-Info: <http://i-am-here.com> ;service=presence,
<http://filter.com> ;service=cpl

being *returned* in the REGISTER response.

> highly non backwardly compatible.)

I'm assuming that these URLs are part of the service. The whole point is
not to have the client register anything, as the client only knows its
IP address (if it's lucky) and AOR.

---

From: Sean Olson <[email-masked]>
Date: Thu, 25 Apr 2002 10:20:52 -0700 (PDT)

I think there are two different models for how
this would work. One is the model where
a server (in your example, the registrar) 
creates the binding and pushes this to the client.

The other model would be where the client creates
a binding and informs the server of the binding.

I think both models are valid. Implicit in both
is that a binding is "created" and must be 
"published" to interested parties. In other words,
we are not talking about an algorithmic approach
for associating one URL with another.

The second model
could be seen as an application of the content
indirection concept (if SIP is used to push the
binding). 

The first model is 
essentially provisioning and the sticky point is
what protocol you use to do this. If SIP, how? 
If not SIP, where does this work go?

A related issue
is the time validity of this information. 
(Does it change per registration, per session, 
per device, never, etc.?)

/sean

--- Henning Schulzrinne <[email-masked]> wrote:
> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

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

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Apr 2002 13:30:33 -0400

Agreed. For the "client informs AOR" (since this has to be the common
reference point), the question is also what happens with this. There are
at least two cases:

- Effectively, just "cookies": the client stores and retrieves this
information, so that multiple instances affiliated with the AOR get the
same information. The server doesn't do anything except store it (and
possibly expire it).

- The information has meaning to the registrar (or the server affiliated
with it), e.g., to retrieve CPL information or to use this to retrieve
presence information.

For the "client informs server", I agree with earlier remarks that
REGISTER may not be the right thing, as it causes multiple failure modes
and you have to deal with multiple different expiration times. I think
the latter is less of an issue, as we already have multiple expiration
times for Contact headers and since REGISTER is incremental (i.e.,
things that don't get removed explicitly stay around until their time is
up, even if not refreshed each time.) Thus, there would be no problem
just refreshing a service binding or just refreshing a Contact.

Pretty clearly, this has nothing to do with Contact and should be
treated separately. However, it may well make sense to make the
semantics similar, to avoid having too many different concepts.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Apr 2002 14:09:15 -0400

The problem I have is that you have to bootstrap somehow from the only
thing that the SIP entity knows, its AOR. "Somehow" just doesn't cut it
for me. I think the REGISTER response has the right semantics, since
it's tied to the AOR. It might be helpful to enumerate the alternatives
and see what the trade-offs are. (Manual configuration is always one,
but it better not be the only one.)

> Ah. To me, this is "configuration". I would certainly not propose that a
> user type in anything. Rather, this is one of many parameters that need
> to be read into the phone when it starts up. What I was arguing for is
> exactly the approach you are talking about here, although I am not
> entirely sure that the information is returned in a register response,
> as opposed to through some other configuration bootstrap approach.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 13:57:09 -0400

-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