Subject: [Simple] Updated RPID

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Oct 2004 16:03:57 -0400

I will shortly submit

http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-04.html

Please let me know if I failed to incorporate conclusions of the recent 
discussion. The major changes are the removal of tuple-type element, the 
re-naming and more precise syntax of the <idle> element (now, 
<user-input>) and the addition of a <timezone> element. The data model 
draft is cited.

Henning

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

---

From: [email-masked]
Date: Tue, 12 Oct 2004 10:10:34 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 11.October.2004 23:11
> To: Henning Schulzrinne
> Cc: [email-masked]; Dag Ekengren
> Subject: Re: [Simple] Updated RPID
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > My concern is that losing source information is not desirable, as it
> >  makes it rather difficult for any downstream entity to decide which
> >  information might be more credible.
> 
> We discussed this extensively on the design team.
> 
> It was concluded that we could support the reporting of conflicting
> information downstream, in later extensions, by inclusion of multipel
> values for a particular element along with its source. That meant that
> the baseline mode of operation was kept simple. Given the confusion
> we've had all along about interpretation of data in multiple 
> places, the
> tradeoff seemed appropriate.
> 
> I, for one, strongly support this decision. I think, prior to 
> the model,
> we were on a path to failure. We clearly had a lack of agreement or
> understanding on what these attributes meant and what they 
> were saying.
> No small part of that was that any data could appear anywhere. I am
> reluctant to return to that. I think that consistent and coherent
> information should be the baseline mode of operation, with conflicting
> data and source information being an extension, something we 
> can do later.
> 
> To be concise, Dan wrote:
> > So in the presence model draft, the cell phone service would report
> > that you are driving using the <person> tuple, and the PDA would
> > report that you are in a meeting also using the <person> tuple.
> > 
> > This would be the case because the information applies to 
> the person 
> > (although it is reported by various services). It is then up to the 
> > composition policy to decide which information should be displayed.
> > It could merge the information so that potentially conflicting
> > information is displayed to the watcher if that is the composition
> > policy in use.
> 
> Correct up to the last sentence - as above, we are not supporting, in
> this current version, the ability to indicate conflicting data.

I agree. There is no logical way of determining which presence info overrides the other. What if I am actually in a meeting but it just happened that I forgot my mobile phone in the car.

We cannot avoid those conflicts. Conflict avoidance, at this point in time, can be left as an exercise to the user of the presence service.

Indeed if a vendor chooses to implement such conflict resolution in its product, it can, but its gonna have to be a proprietory solution as there is no way we can standardise such conflict resolution now in the timeframe that we have.

Thanks,
Hisham

---

From: [email-masked]
Date: Wed, 13 Oct 2004 14:20:41 +0300

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

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?

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

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

> If you are finding text in the document that suggests 
> that the 
> composition policy always picks a winner when there are conflicting 
> information about a service or device, let me know and I will 
> correct it.
> 
> 
> -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
>

Markus

---

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

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

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

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

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

---

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

> From: Isomaki Markus (Nokia-TP/Espoo) 
> Sent: 13.October.2004 16:59
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); 
> [email-masked]'
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]'
> 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:
> 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.

This is not an interoperability problem in my book. This is problem in the compositor implementation that gives your specific user an undesirable result. The behaviour is deterministic, but on a compositor by compositor bases. When you purchase a compositor, you will read the specs for it. If the PUA can communicate with the compositor, and the compositor can communicate with the watcher, then this is enough interoperability.

I think what you want is that the compositor behaves differently in different situations for different users, but you want it to be done in a standardised way. I agree with this, but lets do this work as a second step.

Regards,
Hisham

---

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

inline after snipping --
> >>> As for the person tuple, I think a simple policy like "the latest
> >>> timestamp wins" will get you very far at least for information
> >>> explicitly published by the user. If the user explicitly publishes
> >>> information, he probably wants that information to be visible to
> >>> watchers.
> 
> I don't know what "explicitly published by the user" means. I need to 
> use applications as intermediaries in order to publish.
> 
> I am expecting that the presence client on my PC may have a dropdown 
> list box where I can pick "in meeting". Then I would expect it to 
> publish my activity as in-meeting.
> 
> I also expect that my phone, when I go off-hook, may also 
> publish that 
> my activity is "on-the-phone".
> 
> So, perhaps my activity had been in-meeting, and then was 
> overridden to 
> on-the-phone. What happens when I get off the phone? My phone 
> republishes, but doesn't report my activity at all, since it 
> no longer 
> knows what it is. Does my activity revert to in-meeting, even 
> though it 
> hasn't been republished? What if it is republished?
> 
> Suppose I then go home and use a different PC to publish a 
> new activity 
> status with the intent to override what my office PC is saying?
> 
> I think there are a lot of limitations to "latest timestamp".
> 

The user might be able to set a "global" presence state, e.g. 
his person status,  via his IM client, or through a
personal web portal, which allows the user to 
administer his presence state.  He might want to set his  status
to "unavailable for all communications".  In this case it wouldn't
matter what the phone reports (on-the-phone, or off-the-phone)
after the user sets his person level status.

dave