RE: [Sipping] Binding published data to services

["Ben Campbell" <bcampbell@dynamicsoft.com>]

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:hgs@cs.columbia.edu]
> Sent: Friday, April 12, 2002 3:12 PM
> To: Ben Campbell
> Cc: Sipping
> Subject: Re: [Sipping] Binding published data to services
>
>
> 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.
>
> Ben Campbell wrote:
> >
> > 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 sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP