[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Updated RPID
Jonathan Rosenberg wrote:
>
> Markus.Isomaki at nokia.com 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
> jdrosen at dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
Markus
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple