Subject: [Simple] modeling dispatchers in the data model: a proposal for moving forward

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Dec 2004 15:12:29 -0500

We've gotten ourselves stuck lately in a few places in the presence data 
model. In particular, folks have come forward with requirements for 
having multiple services with the same URI. The use cases that have been 
brought forward include:

1. I have a softphone on my PC that is one integrated application, 
available at one AOR with one contact/gruu. I'd like to be able to say 
that I'm available for IM but not available for voice.

2. I have a cell phone that has a common SIP stack by which other 
applications can "register". The sip stack dispatches incoming SIP 
requests to different applications depending on characteristics of the 
request. For example, based on method, codec, media types, SIP 
extensions, URI parameters, etc.

The data model does not, as currently defined, readily handle these 
cases. In my view, the issue of "can we have the same URI for two 
services or not" is a detail around a more general modeling question 
that we have not addressed properly. I think that more general modeling 
question is how we think about dispatchers. Dispatchers are software 
agents which receive service reuqests, but don't directly process them. 
Rather, they dispatch them to another service for processing. By this 
definition, a SIP proxy is a dispatcher. The SIP stack in example 2 
above is also a dispatcher. You could *model* the integrated application 
in example 1 as a dispatcher fronting different services that all happen 
to run in the same process.

A dispatcher is associated with a URI, just like a service as currently 
defined in the model. However, in the model today, there is no way to 
explicitly tell the watcher - "hey, if you invoke this URI, you'll get 
dispatched to 1 of these services depending on some policy". All we can 
do today is have the compositor attempt to compose the component 
services being dispatched to, and thus hide the existence of the 
underlying component services. Where we appear to be running into 
trouble is when we want to expose these component services to the 
watcher, but still convey the fact that there is a dispatcher there - 
usually by trying to publish them all with the same URI.

Since the goal of the data model is to be extremely explicit about what 
presence is, I think the approach we should take here is to be very 
explicit about how we represent dispatchers. As such, I would propose 
the following:

1. Dispatchers be added to the model as a type of service. Like other 
services, they have a <contact> which is the URI you would use to access 
the dispatcher service. They can have characteristics and status. The 
most important characteristic of the dispatcher service is the set of 
services to which the dispatcher will dispatch. This would be enumerated 
explicitly as part of the characteristics of the dispatcher. These 
component services could be specified by URI or by some other identifier 
that serves only to link the component service to the dispatcher.

2. Since dispatchers are services, they can publish their status too. 
This means that, for example, a proxy could PUBLISH (at least 
conceptually) a tuple to a compositor that defines the dispatch 
operation it provides when it receives a request for a particular AOR. 
The current data model is kind of vague about how a compositor would 
know to combine certain services together. The answer is provided by 
this dispatcher. The dispatcher tuple explicitly tells the compositor 
what the "input" URI is, and what the "output" URIs would be.

I'll note tha the reg-event package provides similar information, but 
dispatching is more general than registration.

3. If you have a "dumb" compositor which simply unions together the 
information it gets, when that information contains the component 
services in addition to the dispatcher service, it allows the watcher to 
compose together the component services.

4. A service in the model is most usefully thought of as a "software 
agent". It is a software process running somewhere on the network. Its 
<contact> URI necessarily indicates the address to which a request has 
to be sent in order to be received by that software agent. When an agent 
publishes its own status, it knows its own URI since that is the address 
it is listening at for requests. There needs to be truth in advertising 
for this to work; a software agent representing a service should never 
publish a <contact> that its not actually receiving requests for.

Here are a few examples to make this more concrete.

Example 1: Proxy

Two SIP UAs, on two different PCs, each registering under the same AOR. 
Each UA is a software agent, and provides a service. Each one 
self-publishes (that is, the software agent providing the service is the 
same one generating the PUBLISH request). The pidf document published by 
one of the UA might look something like this:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:[email-masked]">
      <tuple id="ub93s3">
        <status>
          <basic>open</basic>
        </status>
        <contact>sip:1.2.3.4</contact>
      </tuple>
    </presence>

Lets say the other UA publishes a similar document, but with a contact 
of 5.6.7.8 and a status of closed.

Lets say the compositor knows about the registrations of those UA. The 
proxy that does the location processing can be modeled as a dispatcher 
service. As a result, the compositor can construct the following 
document which models the proxy:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:[email-masked]">
      <tuple id="ub93s9">
        <dispatch-to>
           <uri>sip:1.2.3.4</uri>
           <uri>sip:5.6.7.8</uri>
        </dispatch-to>
        <contact>sip:[email-masked]</contact>
      </tuple>
    </presence>

This says that there is a service at [email-masked] which is a 
dispatcher, dispatching to the two contacts. Using the three documents 
it now has, the compositor can produce several results. One is the 
"transparent" document, which merely combines all of the data:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:[email-masked]">
      <tuple id="ub93s9">
        <dispatch-to>
           <uri>sip:1.2.3.4</uri>
           <uri>sip:5.6.7.8</uri>
        </dispatch-to>
        <contact>sip:[email-masked]</contact>
      </tuple>
      <tuple id="ub93s3">
        <status>
          <basic>open</basic>
        </status>
        <contact>sip:1.2.3.4</contact>
      </tuple>
      <tuple id="ub93s4">
        <status>
          <basic>closed</basic>
        </status>
        <contact>sip:5.6.7.8</contact>
      </tuple>
    </presence>

This is a basic "union" operation. Note that the document provides 
sufficient context for a watcher to know how to combine the two 
component services; it knows that they are both reachable through a 
dispatcher. Indeed, in this case, they may ONLY be reachable through the 
dispatcher since the <contact> URIs of the two component services may 
not be directly routable.

Or, instead of being transparent, the compositor can combine the three 
tuples and advertise a single tuple. This single tuple routes to the 
dispatcher, but doesn't make it explicit to the watcher that there is a 
dispatcher; the component services are hidden and the dispatcher is made 
to look like a regular service:

<?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        xmlns:local="urn:example-com:pidf-status-type"
        entity="sip:[email-masked]">
      <tuple id="ub93s3">
        <status>
          <basic>open</basic>
        </status>
        <contact>sip:[email-masked]</contact>
      </tuple>
    </presence>

What does this mean in terms of the URIs that get put within the 
<contact> elements of each tuple? I think the following can be said:

   a. since each tuple represents a unique service, and since a service 
is associated with a software agent that provides it, there has to, by 
definition, be a unique URI per service.

   b. If two tuples in a document have the same service URI, it means 
that there have been conflicting tuples generated for the same service.

   c. some services may only be reachable through the dispatcher, in 
which case their URIs may not be particularly relevant. They would only 
serve the purposes of correlating the component service to its 
dispatcher. Thus, a gruu would not be needed per se - a contact URI 
would suffice.

   d. If an agent is self-publishing (that is, publishing a tuple about 
itself), the <contact> URI should route to it as far as it knows 
definitively. This would mean that the contact URI of its registration 
or the gruu would do, but not the AOR.

   e. If an agent is third-party publishing, things are more flexible. 
If a UA knows that there are no other UA registered against a particular 
AOR, and if it knows that the proxy itself is not publishing its 
dispatch service, the UA can perform the composition of the two agents 
in the picture (the proxy and the UA), and publish a tuple representing 
the service provided by the *proxy*. In this case, the tuple could have 
the AOR as the <contact>. However, this can be brittle, since the 
ability of the UA to do this is based on it knowing a lot about what 
else is being published. The safest bet is self-publication, since it is 
the approach with the highest likelihood of correctness.

Comments welcome,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Dec 2004 16:27:09 -0500

Jonathan,

I think perhaps you have found a way out of the dilemma.

I see a couple of issues, perhaps not so big:

- when both the dispatcher and the dispatched services
   are included in the presence document, you depend on
   the contact addresses as the correlating info.

   There is at least a possibility that the contact
   addresses are not all unique. Of course all those
   bound to a single dispatcher must be, but if there
   are two dispatchers and four services, then in
   theory there could be two services with the same
   address (but different network) that are disambiguated
   by the two dispatchers. So the dispatchers have no
   trouble dispatching, but a watcher can't do the
   proper correlation. This may be too far fetched to
   worry about.

   When GRUUs are used, there is some ambiguity about
   whether to publish the gruu or the target of the gruu.
   This can be solved by careful specification.

   You also alude to the need for a correlator other
   than contact, for the case when there really is
   only one contact and dispatch is via private
   mechanisms. That might also be a solution for the
   above problem. Or maybe we never want to use contact
   as the correlator.

- This solution still leaves an OR-OF-ANDs case.
   That is the case when there is indeed just one
   service, but where not all combinations of its
   capabilities are valid. But perhaps this just
   needs to be left to another day. Or maybe this
   can be modeled as a dispatcher to two services
   even though that isn't quite what it is.

Otherwise I think this works for me.

	Paul

Jonathan Rosenberg wrote:
>   e. If an agent is third-party publishing, things are more flexible. If 
> a UA knows that there are no other UA registered against a particular

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 07 Dec 2004 23:10:54 -0500

I think this does provide more explicit description of interesting, 
SIP-oriented subcases of the problem, albeit at the cost of increased 
complexity.

With this approach, I see no need to use URIs as tuple identification, 
i.e., forcing the merging of tuples that have different tuple id's (your 
ub93s*), but the same contact URI. The contact URI are needed only as 
correlators that allow the watcher to tell that a particular dispatcher 
and a set of service tuples are related.

To avoid the need for inventing non-reachable URIs (which seem like a 
bad idea), one could reverse this and simply have the individual 
services indicate their "master" URI. (I'm avoiding the AOR term to be 
less SIP-specific.), as in

  <tuple id="ub93s3">
    <i-belong-to>sip:[email-masked]</i-belong-to>
        <status>
          <basic>open</basic>
        </status>
        <contact></contact>
      </tuple>

Here, the contact can be empty or not, depending on whether the contact 
URI is meaningful or not.

If there is no way to contact that service (SIP or non-SIP) except by 
describing the service to the dispatcher, there's no need to include the 
contact-URIs or the <contact> element.

The dispatched services will always know their master by his voice/URI.

My concern continues to be that any rule has to work with all kinds of 
URIs, including schemes the composer knows nothing about and schemes 
where non-URI components are needed to describe the service. (As 
discussed, these qualifiers would be labeled as mandatory-to-understand 
elements, as described in Section 4.3.3 of the PIDF draft.)

I believe with this modification, a purely additive composer will do no 
harm, but watchers will know exactly what's going on. (I believe this 
will also solve the or-of-and problem, in that it is simply a special 
catch of the dispatch problem.)

Henning

---

From: Aki Niemi <[email-masked]>
Date: Fri, 17 Dec 2004 10:31:57 +0200

Hi Jonathan,

First of all, thanks for pushing the resolution of this issue forward by
making a concrete proposal.

I don't think making the dispatcher visible to the composer/watcher 
actually solves the real problem; it does however reaffirm the statement 
made in the data model that unique contacts URIs are required in service 
tuples. The primary motivation for this requirement seems to be that it 
enables overriding service elements.

I think we are working with the wrong publication model to begin with, 
which makes override of service elements problematic. The publication 
model is that of a presentity employing a set of PUAs with equal rights 
-- no one PUA is more authoritative than another. They are all 
publishing their own full view of the presentity's service statuses.

This is much like a set of users running processes in an OS. Let's say 
that user 'apniemi' sees that a process run by 'calendar' has gone awry 
and is not responding. Using the current data model, fixing, or 
overriding this process would entail user 'apniemi' creating a new 
process, with matching properties (such as the pid), but a different 
binary, resulting in overriding the 'calendar' user's process. Normally, 
of course 'apniemi' probably wouldn't be able to do that, but instead, 
would need to become 'root' and 'kill' the process.

So I think ultimately, we need a new interface to the composer, call it 
root account, that gives us a way to "kill" publications that are 
publishing stale event state. Perhaps such an interface could be 
provided as part of the composer policy or authorization policy, but I 
don't think it necessarily requires uniqueness of service URIs.

If we reverse the assumption made in the data model that requires 
uniqueness of service URIs, will watchers generally be confused if they 
encounter service tuples with the same contact? I don't think so, as 
long as the watcher does the following:

1) takes note of the meta-information of each service (timestamp, 
q-value) giving preference to a fresher service, or one with higher q-value.

2) takes note of the characteristics of each service (prescaps for 
example) along with the contact URI, applying its own known 
characteristics and service URIs to determine what service the tuple is 
describing

3) takes note of the status, meaning that a basic status of OPEN is a 
better choice than one with CLOSED, for example

4) all of the above being equal, folds all identical services together 
(after all they are identical in all ways that have relevance to the 
watcher)

These steps should guarantee that the watcher can always make a proper 
selection of which service to invoke. Invoking the service then involves 
more than a simple "clicking the contact", since in the case of SIP the 
watcher generally will e.g. construct an SDP offer that matches the 
service that the watcher thinks the tuple is describing. I believe the 
invoking of a service MUST work using an AoR. If an INVITE offering 
voice ends up served by a chess application, I think the system is 
utterly broken, and needs to be fixed. One fix could be using GRUUs as 
contacts, but that is not the only fix, and may not even be the best 
one, IMHO.

All and all, I still don't buy the requirement for unique service URIs. 
Also, I think that the default composer policy of union (i.e., collect 
all service tuples together intact) will take care of the 95% need, 
leaving out more sophisticated things like override and 
merging/splitting for future study. These more sophisticated needs can 
be tackled later, when more real-world experience has been accumulated 
about them. I don't think we currently are able to see exactly what the 
needs of this 5% are, so the best way forward is to take the 95%, make 
it as flexible as possible to accommodate this future work and run with it.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Dec 2004 22:20:18 -0500

> publishing their own full view of the presentity's service statuses.

Actually, there does seem to be a hierarchy, namely that "latest is 
best", or "most frequent publisher wins".

> don't think it necessarily requires uniqueness of service URIs.

I wouldn't think it requires uniqueness. If you can explicitly yank a 
tuple, you can much more easily, without worrying about URL matching, 
yank it by its tuple id handle.

I like the 'root' analogy, although I see this more like a filter: An 
entity representing the presentity (logically similar to the one that 
publishes rules, for example) would add a filtering policy. Indeed, in 
many ways it would probably look similar to the current rules, except 
without reference to a specific receiver. This could be as simple as two 
sets of XPath expressions that stipulate the tuples to include and those 
to remove. For those purposes, you probably want a source identifier or 
a tuple identifier, not something that is subject to change with every 
reboot of the PUA, like a GRUU.

We already assume that we have a central rulemaker that issues 
non-contradictory privacy rules. This same logical entity would then 
provide the the composition policy rules. (The data model hints at that, 
but doesn't say much about the identity of the rulemaker.)

> (after all they are identical in all ways that have relevance to the 

Agreed; this is just applying the standard pivoting and merging rules at 
the watcher, with the advantage that only the watcher knows what 
information is meaningful and differentiating to it.