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); jdrosen at dynamicsoft.com
Cc: simple at ietf.org; dag.ekengren at hotsip.com; hgs at cs.columbia.edu
Subject: 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