Re: [Simple] Re: Presence Data Model: Overriding services (tuples)

[Paul Kyzivat <pkyzivat at cisco.com>]

Jonathan Rosenberg wrote:
> Please, no.
>
> This is right back to where we started. How, then, should a watcher 
> interpret a document where there are two services with the same URI? As 
> soon as the answer is "several plausible scenarios", we have invalidated 
> the idea of the presence model, which is that the document has one and 
> only one meaning.

There have been two meanings suggested for this case:

- "alternative views" - data from different sources, about the same
  resource. The data may either be complementary or conflicting.
  Everybody seems to agree that we can have this arriving at the
  composer in different presence documents that are somehow to be
  composed. Henning is suggesting that it must also be possible for
  this to be the case in a single document - generally as the result
  of naive composing. This leaves the hard composition problem to
  the watcher.

  I think Henning makes a good case that this is needed. We aren't
  going to be able to "solve" the hard composition problems any time
  soon. Naive solutions that simply throw away one or the other of
  the competing views aren't going to yield acceptable results.

- "OR-of-AND" - data from (presumably) a single source that expresses
  a more complex relationship among capabilites than we can otherwise
  represent. More on this one below.

These two uses (if present) require *different* interpretation. Hence 
they need to be distinguishable by a watcher.

> I don't think the spec is explicit that each service in the document has 
> to have a different URI, but that has been the intent.

I guess it was your intent. It wasn't mine, and I don't think it was 
Henning's.

> I do not want to add a feature to the data model which basically allows 
> for OR-of-AND style capability decalarations, which is the motivating 
> use case you are indicating below. We have never had that to date for 
> any of our capability decalration specs, either SDP or callee-caps (RFC 
> 3840). Thus, I see no need to permit its representation in a presence 
> document right now. If we want it, it can be added later in any number 
> of ways that do not require the inclusion of multiple <service> elements 
> with the same URI.

I wanted this is callee-caps. (I looked into ways to revise the rules 
for registration so that contacts could be repeated with different sets 
of capabilities.) But gave up on it, as too hard to get approved.

One of the reasons gave up there was because presence was coming, which 
had the potential for a much richer representation, without the same 
historical constraints.

Later in this thread David Boyer asked for an example of this. One that 
comes to mind is:

- I can do voice and video, or I can do gaming, at this address.
  Both are negotiated using SIP and SDP.

Another:

- This contact can do regular voice, it can do PTT, but not both
  on the same call. (Seems like a poor way to design things, but
  also seems to be a common restriction.)

> The main point though, and this cannot be overstated - is that the 
> problem we've had to date with "what is a tuple" is that we were never 
> willing to be concise and make a decision about what a piece of data 
> really meant in a document. That path led to interoperability problems. 
> The path we are on now is to make concrete statements about what the 
> document means. Choice of interpretation is our enemy here! I am really 
> worried that folks are trying to push this work back down the path to 
> where we were before, and I think its a big mistake. Please don't.

I don't want to do that.

I agree that there is a problem if we permit tuples with the same 
contact to mean both of the above, without any way of distinguishing.

I think the need to represent "alternative views" in one document is 
more pressing. So I propose that we permit this usage, and postpone 
consideration of how to represent "OR-of-ANDs".

As long as there is only this one interpretation I don't think we have 
set back progress at all. In fact, it permits us to move forward to 
useful products without defining how to do composition more 
sophisticated than catenation.

	Paul

> -Jonathan R.
>
>
> Henning Schulzrinne wrote:
>
> > > Out of curiosity, is there anything that says that the contact uri must
> > > be unique within the composed document? With the service tuples being
> > > identified by tuple-id:s, is there anything preventing to such tuples
> > > having the same contact uri:s?
> > There are several plausible scenarios where you could have the same 
> > contact URI appear twice. For example, limitations in the capabilities 
> > description may not allow you to express "this URI can do A1,A2,A3  OR 
> > it can do B1,B2,B3" (but not random combinations of sub-capabilities 
> > such as A1,B1).


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple