[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] Re: Presence Data Model: Overriding services (tuples)
Henning Schulzrinne wrote:
At the moment the answer is that Jonathan's data model document says
they must be unique.
Hmm; I thought the discussions in the design team allowed them to be
non-unique. I don't see how this can realistically be enforced.
The enforcement is only within a document. The entity that creates the
document, be it the compositor or the publishers, just doesn't put
multiple services with the same URI. I dont understand why this is hard.
My basic concern is that, as of right now, the only composition policy
we have specified (implicitly) is concatenation. I'm really worried if
we built systems that break badly for this 'null' composition policy.
I don't understand here. There is a whole section in the data model that
talks about the things one can do for composition policy, including the
pivot concepts that you yourself introduced. This is far from just
concatenation.
I also don't see how anything breaks here by having unique URI. Indeed,
there is clear breakage when they are not. As Paul pointed out:
OTOH, I agree that there are benefits to having the addresses be unique. Specifically, its hard to imagine how a composition policy could work if two tuples with the same contact could represent *either* an override or two services available simultaneously at the same address.
The problem is much worse than just composition policy. Its any
recipient of a presence document. If we can't differentiate between
"there is one service with an or-of-and capabilities" and "these two
services are alternates", watchers of any sort, be they network
applications or PC clients, and compositors, won't be able to sort out
the difference, and each will reach differing conclusions about what the
document means. That is the very problem that the data model is seeking
to avoid!
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).
I am torn about this. I fully agree with this example, and repeating
the contact address in two tuples seems the most straightforward way
to represent it.
OTOH, I agree that there are benefits to having the addresses be
unique. Specifically, its hard to imagine how a composition policy
could work if two tuples with the same contact could represent
*either* an override or two services available simultaneously at the
same address.
That would have to be marked up explicitly in any event. For example,
you may want to say "if my sip URI is available, don't show my tel URI
tuple". I don't see how this is affected by having duplicate URIs.
The point Paul is saying is that once you have multiple ones, you cannot
determine why you have multiple ones in a document. Does it mean these
are alternates which represent conflicting views of the same service
(which you have proposed in a separate thread for <person>), or does it
mean that this is one larger service which multiple simultaneous
capability sets?
I guess my inclination is to *allow* duplicates for now, and leave it
as a later exercise to possibly restrict them as part of a composition
policy. I don't think the presence of duplicates should be a problem
for watchers.
I agree.
No, I disagre, for the same reason I've been repeating in my other
mails. Choice of interpetation is our enemy. You cannot just allow it
and then define what it means later on.
-Jonathan R.
--
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