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

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

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.

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 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.

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.

-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).

--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen at dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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