Re: [Sipping] Binding published data to services

[Henning Schulzrinne <hgs@cs.columbia.edu>]

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