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

From: [email-masked]
Date: Tue, 12 Oct 2004 23:16:51 +0300

Hi,

Paul Kyzivat wrote:
> 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.
>

I completely agree with this. I think the ability for a PUA to explicitly override something as compared to just providing it to the composition black box is important. What is needed for this is a way to explicitly address a "raw" published tuple (raw meaning that it has not gone through the composition logic yet). Doing this through a unique contact address is fine, but this is not always possible. Can't there simply be some sort of identifier within the tuple that could be used for the same? If a tuple is published with the same identifier as an existing tuple, it is considered to be an override. This is exactly the same logic as is proposed to be based on contact for tuples and device-id for devices. I don't understand why we couldn't allow this for the reason that unique contact is sometimes hard to get. Also I don't think this has anything to do with identifying services which some people don't like. This would just be meta-data related to the tuple, not something that watchers would use.   
 
> I don't know if this can be resolved without first tackling 
> the problem 
> of composition policy. But I think that will be a long time in coming.
> 
> 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 think we should solve this part of the problem now.

Markus

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

---

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Wed, 13 Oct 2004 09:24:47 -0400

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: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Jonathan Rosenberg
> Sent: Wednesday, October 13, 2004 6:26 AM
> To: Henning Schulzrinne
> Cc: Paul Kyzivat; [email-masked]; Dag Ekengren;
> [email-masked]
> 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
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

---

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Wed, 13 Oct 2004 10:14:35 -0400

Johnathan, Henning, Paul,

Henning wrote -
can also be used as a voice only end point?

Johnathan wrote -

I am missing something here, wouldn't the most recent one always
over write the older one?

Dave

---

From: [email-masked]
Date: Wed, 13 Oct 2004 17:23:36 +0300

Hi,

See at the end.

> From: Khartabil Hisham (Nokia-TP-MSW/Helsinki) 
> Sent: 13 October, 2004 16:49
> To: 'ext Jonathan Rosenberg'; Henning Schulzrinne
> Cc: Paul Kyzivat; [email-masked]; Dag Ekengren; Isomaki Markus
> (Nokia-TP/Espoo)
> Subject: RE: [Simple] Re: Presence Data Model: Overriding services
> (tuples)
> 
> 
> 
> 
> > Of ext Jonathan Rosenberg
> > Sent: 13.October.2004 13:26
> > To: Henning Schulzrinne
> > Cc: Paul Kyzivat; [email-masked]; Dag Ekengren; Isomaki Markus
> > (Nokia-TP/Espoo)
> This is a point that needs emphasising. I think people 
> misunderstood it as no PUA can publish a service with the 
> same service URI as another PUA.
> 

So how about a device that has separate applications (say, push-to-talk, IM, one-way video) and does not support GRUU. It can collect all of this under one tuple, in which case the watcher might think that he can do push-to-talk and video at the same time, which is not true. On the other hand all those apps can run a separate PUA and just publish their individual services with AoR as the contact. In that case anything is possible: just one of the tuples (any one) is sent to the watchers, or the compositor decides to merge. I guess you just have to try to know. 

I'm not sure what should happen if the tuples initially have different classes and they are merged. Will they have just one class or all of the classes. This might make auth decisions based on class rather tricky.

> Regards,
> Hisham

Markus