Subject: RE: [Simple] Updated RPID

From: [email-masked]
Date: Wed, 13 Oct 2004 16:59:00 +0300

Hisham,

There will be no interoperability problem on _syntactic_ level. As you say, a tuple saying I'm in a car is syntactically as correct as a tuple saying I'm in a meeting. 

What is meant in this context with an interoperability problem is something that actually manifests itself on the user and user interface level. Let's take your example:

Hisham wrote:
> PUA1 publishes that the person is in a meeting
> PUA2 publishes that the person is in a car
> compositor1 composes in a way picking the former, in a meeting
> compositor2 composes in a way picking the latter, in a car

>From user and PUA point of view this is undeterministic behavior which is not very good. As a vendor of mobile phone software I would like to give my users a UI whereby they can explicitly set their status to be "in a car", even if some other source tells they are "in a meeting". If there is no way instructing the compositor whether PUA1 or PUA2 input should be taken, the user really has no clue as to what his OWN presence will be, unless he subscribes to it. And even after that he does not know how to change it.

Now of course all this will be solved when we define compositor rules that can be managed by e.g. XCAP - but before that I can't implement what I want for the users of my phones.

> > Do you think that the eventual composition policy would be 
> > harder to make if we include this type of information already 
> > within the published state?
> 
> Probably not, but it will challenge the model that we have 
> been working with so far. We are at a point were we cannot 
> afford to re-design the model.

Fine. So, let's just leave it to the compositor policy. But even if we follow a model where publication only contains a state that has nothing to do with any other state, you still need handles to reference to such state. For instace you can't define rules for person elements unless you can uniquely identify them.

> There is basic default policy already in the presence data 
> model. What do you see is missing the is critical?

No there isn't, as I've learned. There are just example policies that are reasonable. For instance regarding your example above, it is also a completely valid policy to report that a person is having a meeting in a car. There is NO way for a source to tell whether it wants to override or complement the state set by another source. Of course not, since the sources are not supposed to know anything about each other, and any composition is ok as long as it generates syntactically valid presence documents.

Markus
 
> -----Original Message-----
> From: Khartabil Hisham (Nokia-TP-MSW/Helsinki) 
> Sent: 13 October, 2004 16:28
> To: Isomaki Markus (Nokia-TP/Espoo); [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Simple] Updated RPID
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf
> > Of ext [email-masked]
> > Sent: 13.October.2004 14:21
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: [Simple] Updated RPID
> > 
> > 
> > 
> > Jonathan Rosenberg wrote:
> > > 
> > > [email-masked] wrote:
> > > > 
> > > > 
> > > > If composition policy is completely proprietary, it is 
> > very hard to
> > > > build the PUAs in a reasonable way so that the user would 
> > > really know
> > > > what is going on. For this reason I think we need at 
> minimum, even
> > > > for person, a way of saying either a) override your 
> > previous person
> > > > info with identifier X with this information, or b) merge 
> > > this person
> > > > info with the rest of the person information you have.
> > > 
> > > This is what composition policy defines. Its proprietary 
> now in the 
> > > sense that we have not written standards which allow its 
> > > control. That 
> > > doesnt mean we won't, it means we haven't yet. TO date, we 
> > > haven't even 
> > > had a firm grasp on what presence really meant in our 
> > > systems, let alone 
> > > how to override it.
> > > 
> > > So, I am not objecting to the requirement. I am saying, 
> we have an 
> > > approach in the data model which defines a default behavior 
> > > in absence 
> > > of explicit policy directing otherwise. That default behavior 
> > > covers the 
> > > cases that appear to be most pressing - changing my status 
> > from "in a 
> > > meeting" to "available" when I get home and my work PC is 
> > > publishing old 
> > > information. It does not cover more complex cases where I 
> > > need to accept 
> > > partial information from some sources, and completely 
> override from 
> > > others. That is fine to solve, but it IS composition 
> policy and we 
> > > should not try to define it now.
> > > 
> > > Keep in mind also that a presence document is not a 
> > "command" - it's 
> > > state. 
> > 
> > I can basically agree to everything so far, and things would 
> > be fine if we already had the standardized composition policy 
> > ruleset. I think we would still want to do interoperable PUA 
> > & PS implementations before that, so having something more 
> > already before tackling the composition policy problem 
> > properly is necessary. Otherwise I'm afraind we will have to 
> > wait yet another year before declaring that we have a 
> > reasonably interoperating presence system implementable based 
> > on SIMPLE specs.
> 
> Can you explain how a compositor applying proprietory 
> composition policy results in an interoperable system? The 
> PUAs publish state, the PS composes then and sends the 
> results to watchers. As long as the watcher receives a 
> correctly formulated XML document, then the system is 
> interoperable. Limitations and algorithms of a composition 
> policy is not an interoperability issue. A simple example follows:
> 
> PUA1 publishes that the person is in a meeting
> PUA2 publishes that the person is in a car
> compositor1 composes in a way picking the former, in a meeting
> compositor2 composes in a way picking the latter, in a car
> 
> While the presentity cannot be sure how the his compositor 
> will compose, the Watcher will still receive a valid presence 
> document. I don't understand why the interoperability problem is here.
> 
> >  
> > > It makes no sense to include an identifier in a 
> > > presence document 
> > > whose meaning is "override existing state with this". What 
> > > would happen 
> > > if someone else published a document saying the same thing? 
> > Who wins? 
> > > The most recent? Well, having the most recent override is 
> > > exactly what 
> > > is in there today, and has the same effect.
> > > 
> > 
> > The reason I propose the identifier is this: I want to let 
> > the compositor know whether I am just publishing my view of 
> > person/device/service and leave it up to the compositor to 
> > merge that with other information about the same 
> > person/device/service, OR I am aware of the existing 
> > published state and want to explicitly enforce that state to 
> > be overriden with the state I'm publishing. I think your idea 
> > is that I would modify composition rules with e.g. XCAP to 
> > the same effect. Given that such rules won't exist for a 
> > while, I would like to include enough information in the 
> > published document itself. I wouldn't still call this a 
> > command, although I agree that the proposal is very close to that.
> 
> I don't like this command-like business. As Jonathan said, a 
> presence document carries presence state and not command-like 
> information.
> 
> > 
> > Do you think that the eventual composition policy would be 
> > harder to make if we include this type of information already 
> > within the published state?
> 
> Probably not, but it will challenge the model that we have 
> been working with so far. We are at a point were we cannot 
> afford to re-design the model.
> 
> > 
> > > > 
> > > > To me this is solvable so that we just define an 
> identifier, whose
> > > > semantics are as follows: "If two or more person elements are
> > > > published with an identical identifier, the composer MUST 
> > take only
> > > > the most recent of them to be part of the composition 
> process. The
> > > > composer MUST merge the information in person elements having
> > > > different identifiers into a single person element using any
> > > > heuristics it has at its disposal. The most natural way 
> > is to union
> > > > them together".
> > > 
> > > We have a disconnect here in the model of how this works.
> > > 
> > > In the model described in the document, each source publishes 
> > > the state 
> > > of the universe as it knows it, period. 
> > 
> > And I think this is not always sufficient. If the source has 
> > knowledge of the existing state set by other sources, it 
> > could indicate that to the compositor. This it can prove by 
> > including the same id as was used in the existing state. 
> > Based on this the work of the compositor would become easiear.
> 
> Why don't we leave the compositor problem to the compositor. 
> The PUAs must be able to work with and without compositors 
> and need not know if they are dealing with a compositor or 
> not. A PUA publishes its view of the presence and that's it.
> 
> > 
> > > The published 
> > > documents do not 
> > > themselves contain tidbits of composition policy. 
> > 
> > At least they should contain enough information so that any 
> > meaningful policy could be even specified. If you have N 
> > sources publishing one person element each, how do you 
> > instruct which one to take? There has to be some instance 
> identifier.
> > 
> > > Composition 
> > > policy is 
> > > something specified totally separately, and it makes 
> > > decisions based on 
> > > information in the documents. What you are suggesting is 
> > that you can 
> > > effectively insert directives to control composition in the 
> > presence 
> > > document itself - special identifiers that have significance 
> > > ONLY in the 
> > > context of composition. 
> > 
> > > This is contrary to the model; 
> > 
> > Yes, this is what I am suggesting. Even if we had a rule 
> > language to set explicit composition rules, we would need 
> > identifiers etc. handles within the published elements to be 
> > able to address such elements in the rules. The model should 
> > allow that.
> > 
> > > the 
> > > document has 
> > > meaning in absence of any other part of the system, and its 
> > > one and only 
> > > goal is to describe the presentity.
> > > 
> > > 
> > > 
> > > > 
> > > > 2. User has a cell phone which updates its 
> > characteristics in device
> > > > element. However, some information related to the device 
> > also comes
> > > > from the network, such as its location. So here we have 
> > two sources
> > > > publishing information about a device which are not 
> exclusive but
> > > > complementary.
> > > > 
> > > > The data model draft does not support this properly, since two
> > > > sources publishing with a same device id are considered to be
> > > > conflicting. 
> > > 
> > > Yes. However, the model does not say that you have to pick 
> > > one winner. 
> > > It talks about merging of information, and allows all kinds 
> > > of things to 
> > > happen. 
> > 
> > I think we should have a more clearly defined default policy 
> > that is supported with providing enough information within 
> > the publications. 
> > 
> 
> There is basic default policy already in the presence data 
> model. What do you see is missing the is critical?
> 
> Regards,
> Hisham
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Oct 2004 11:07:11 -0400

Jumping into this thread at a more or less arbitrary point...

I think what Markus is proposing is similar to what Henning was talking 
about in a related thread yesterday (I think), where he used a DB model.

We get into trouble when we decide on insertion or replacement based on 
a key that has semantics of its own. (E.g. the service URI.)

If the "default" composition algorithm instead makes this decision based 
on attributes that are present simply to act as keys and nothing else, 
then the PUAs have more lattitude to influence the outcome of the policy.

If the default composition policy was to take the most recent of tuples 
with the same tuple-id, and retain all tuples with different tuple-ids 
(even if they have identical contact URIs) then that problem would be 
solved for tuples.

To do the same for <person>, we would have to introduce a person-id 
attribute. Then, a PUA that wanted to override the data of another PUA 
would need to first find the person=id of the data to be overridden. 
Then it would publish an overriding <person> with the same person-id.

<person>s from different sources would normally have differing 
person-ids, so by default they would all be included.

	Paul