[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Re: Presence Data Model: Overriding services (tuples)
Johnathan, Henning,
Trying to catch up with this thread.
[Stealing from Paul -]What would an example be when two tuples with the same contact could represent two services available simultaneously at the
same URI?
Henning wrote -
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).
What is a service example of this? A video conferencing application
can be used as a voice only end point?
Johnathan wrote -
if you have two descriptions of the same service, you
should pick the most recent one.
I am missing something here, wouldn't the most recent one always
over right the older one?
Dave
> -----Original Message-----
> From: simple-bounces at ietf.org
> [mailto:simple-bounces at ietf.org]On Behalf
> Of Jonathan Rosenberg
> Sent: Wednesday, October 13, 2004 6:26 AM
> To: Henning Schulzrinne
> Cc: Paul Kyzivat; simple at ietf.org; Dag Ekengren;
> Markus.Isomaki at nokia.com
> Subject: 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
>
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple