Subject: [Sipping] Binding published data to services

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Apr 2002 14:46:21 -0500

In Minneapolis, we talked (yet again) about how to publish service data to
SIP network elements (such as presence documents, CPL, etc.). We decided to
look first into the question of how we would bind such publications to the
SIP services in question. I volunteered to try to spearhead the solution
effort in that area. So here goes:

First, the problem itself seems rather nebulous. It would be useful to more
clearly define the problem. It seems to me that it is really an issue of
name binding--that is, how do we map the name of a SIP based service to the
name of a data element.

Of course, before we can generically map service names to data names, we
must understand how to refer to SIP services in the first place. This issue
keeps coming up, and it is always controversial--so I am not sure if it
makes sense to go futher here than say we use a URI to refer to a service.
(Even that can be problematic, as a service may be distinguished by more
than just the URI. For example, a presence subscription is distinguished by
URI, method, and event. Of course you can still create a URI for that, but
it wouldn't be one you would enjoy typing.

So, does a generic binding of data to services even make sense? We have so
far been unable to agree on a way to generically refer to services. Is there
a way to narrow this problem to avoid that particular rat hole?

Thoughts?

Thanks!

Ben Campbell.

_______________________________________________
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: Fri, 12 Apr 2002 16:11:46 -0400

A useful and easibly describable sub-problem is the binding of a non-SIP
URI to a SIP URI, so that properties of the SIP URI can be described.
This is sufficient, for example, to describe CPL and other configuration
information, two of the motivating examples for this discussion. It may
also be sufficient for some subset of the presence issue, as long as all
events are handled by the same entity and thus event discrimination can
be handled by the entity receiving the published data. Given practical
realities, that doesn't seem unrealistic.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Apr 2002 15:33:12 -0500

Are you thinking of an algorithmic binding, or some discovery mechanism?

An algorithmic binding would be nice, but I am afraid it may imply some
limitations on architecture that we might not should make. For example,
would an algoritmic binding force the publication point to have the same
domain name as the SIP service element?

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 3:12 PM
> To: Ben Campbell
> Cc: Sipping
> Subject: Re: [Sipping] Binding published data to services
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Apr 2002 18:41:41 -0400

> domain name as the SIP service element?

Not sure I understand algorithmic vs. discovery.

No, I certainly wouldn't want to restrict the publication point in any
way, by domain or otherwise.

As a crude thought-experiment, imagine that the REGISTER response for
[email-masked] would return something like

SIP/2.0 200 OK
From: [email-masked]
...
Publish: <http://www.yahoo.com/campbell> ;use=cpl ,
 <http://www.att.com> ;use=config

This would tie the publish information to your SIP URI, but not in any
way restrict the publishing URL.

You could presumably configure this information via REGISTER, too.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Apr 2002 19:46:46 -0500

That is what I meant by discovery--the service tells you where to publish,
as opposed to being able to perform some transformation on a SIP URI to get
an http: (or foo: for that matter) URI.

> Sent: Friday, April 12, 2002 5:42 PM
> To: Ben Campbell
> Cc: Sipping

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Apr 2002 20:53:54 -0400

The only way I could see something like an algorithmic transformation
working would be to use NAPTR records, using the regexp transformations.
However, I'm not convinced that DNS is the right location for this, as
it would pretty much mean that everybody in the same domain has to use
the same transformation. This may still be useful as a default
mechanism, however, subject to some discovery override.

---

From: Sean Olson <[email-masked]>
Date: Fri, 12 Apr 2002 18:02:56 -0700 (PDT)

A few comments on this topic:

1) We should consider both SIP-based mechanisms
   for discovery (like the example shown) as well
   as other mechanisms: DHCP, DDDS, etc.

2) We should support both client-supplied bindings
   as well as server-supplied bindings. A 
   client supplied binding might be publishing a
   CPL script. A server supplied binding might be
   an administrator creating a binding between an
   LDAP URL and a SIP URL.

3) We should allow (as one option) an automated
   way for binding one URL scheme to another.
   An example might be an automated way to 
   bind a pres: URL to a sip: URL. You don't
   necessarily want to have to provision these
   bindings.

4) It might be nice to be able to identify the
   party which created the binding.

5) It would be nice to support an ephemeral 
   binding.

6) It would be nice to support bindings 
   in some situations that are not easily 
   guessable.

/sean

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Apr 2002 21:12:36 -0500

My concern about algorithmic tranformations (DNS or otherwise) is that it
would imply fairly static bindings. I can imagine an application that would
allocate a publication URI on the fly, and not necesarrily give the same
result for multiple queries against a given SIP URI.

> Sent: Friday, April 12, 2002 7:54 PM
> To: Ben Campbell
> Cc: Sipping

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Apr 2002 21:19:53 -0500

It sounds like we are starting to generate requirements--I guess that is
progress. More comments inline.

> From: Sean Olson [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 8:03 PM
> To: Ben Campbell; Henning Schulzrinne
> Cc: Sipping
> Subject: RE: [Sipping] Binding published data to services
>
>

Can you elaborate further on what you mean by client-side bindings?

>    necessarily want to have to provision these

By automated, I assume you mean a way for a client to infer the publication
URI from a SIP URI without asking the SIP service? Henning suggested a NAPTR
approach as a possible last-resort alternative. Is this the sort of thing
you had in mind? It does seem like this might conflict with your items 4 and
6.

>    party which created the binding.

Agreed.

> 5) It would be nice to support an ephemeral

Agreed, which points more to a discovery mechanism.

>    in some situations that are not easily

Agreed. I suspect 5 and 6 are aspects of the same thing.

I would also  propose 7) It would be nice to control who can discover a
binding, and 8) who can use the bound URI it is discovered.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Apr 2002 21:23:59 -0500

(replies to self)

Actually, let me retract my number 8 item--authentication/authorization for
the use bound URI after discovery is probably an aspect of the associated
publication protocol itself, not the binding mechanism.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ben Campbell
> Sent: Friday, April 12, 2002 9:20 PM
> To: Sean Olson; Henning Schulzrinne
> Cc: Sipping

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Apr 2002 22:58:07 -0400

> result for multiple queries against a given SIP URI.

As long as such static bindings can be overridden, they may have a
useful role to play, particularly for provisioned bindings.

---

From: "Sean Olson" <[email-masked]>
Date: Fri, 12 Apr 2002 23:45:45 -0700

Sean> The distinction I am trying to make is who owns/defines the
binding, assuming that the binding is dynamic and not simple
string manipulation. A client-side binding, would be made by a
UserAgent/user-centric device. A server-side binding would be
made by a registrar/proxy/network-centric device. This may be a
bit blurry, but I wanted to ensure that the mechanism worked 
"both ways".

>    necessarily want to have to provision these

By automated, I assume you mean a way for a client to infer the
publication URI from a SIP URI without asking the SIP service? Henning
suggested a NAPTR approach as a possible last-resort alternative. Is
this the sort of thing you had in mind? It does seem like this might
conflict with your items 4 and 6.

Sean> I had two possibilities in mind:
      1) Use something like NAPTR/DDDS
      2) Use something even simpler like a well-known regex.
         This would be much more static and useful in only a 
         handful of cases. Nonetheless, I think it will serve
         a purpose. An example that comes to mind is the 
         construction of a UUID binding from a SIP URL.
 
      It conflicts with items 4,6 in the sense that you would
      likely not apply such an obvious static binding in the case where
      you want an ephemeral or private binding. Both types of 
      bindings are useful under different circumstances.

/sean