[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Updated RPID
> -----Original Message-----
> From: simple-bounces at ietf.org
> [mailto:simple-bounces at ietf.org]On Behalf
> Of ext Markus.Isomaki at nokia.com
> Sent: 13.October.2004 14:21
> To: jdrosen at dynamicsoft.com
> Cc: simple at ietf.org; dag.ekengren at hotsip.com; hgs at cs.columbia.edu
> Subject: 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.
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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple