Notes,
SIMPLE session two, IETF 61
Reported
by Ben Campbell
------------------Partial
PIDF format 02 (Jari Urpalainen)
--"patch"
model for pidf docs.
add,
remove, replace, but no creation.
failure
falls back to unchanged pidf doc.
question:
similar to xcap operations--how close is the
relationship?
answer:
very close--same operations that any xml database uses.
issue:
this is a compression scheme on xml docs, based on diff. We
should
have one way for all xml docs, not one for each. similar to
xcap
Further
discussion about competing with xcap, and which is more
simple
and/or
compact.
Issue:
Is this just xcap with different attribute names?
Jonathan
agrees to look at possible improvements to xcap.
Chair:
Both this and xcap took divergent evolutionary paths to a
similar
place--no competition intended. Need to talk to other
groups working
on
xml diff formats.
--------------Partial
Presence (Aki)
*-partial-publish-01
*-partial-notify-03
Radical
simplification
No
longer tuple specific.
Issues:
What if updated version is garbage?
Issue:
Do we need guidlines to avoid sending partial pidf that is
bigger
than whole doc. Don't want to do a large number of small
changes.
Resolution:
We think it is already addressed in draft. (Maybe just
notification,
but needs to be in publish.)
---------------------------XCAP
Needed diffs (Jonathan)
Issue:
xcap equates get(put(x))==x as idempotency. This is
sufficient
but
not necessary. ( if-match requests are all idempotent)
Options:
Clarify, but keep normative text; allow other idempotent
ops.
Proposal:Keep
normative text.
discussion:
does get(put(x))==x also check for concurrent changes?
Resolution:
accept proposal.
Issue:
xcap list usage talks about unioning liest elements. But
operation
is more complex--ns prefix can get lost. (see slide for
accuracy)
Proposal:
when <service> element copied into global doc, add
a
namespace
prefix def for all in-scope ns. If default differes from
global def,
add
a new default.
Resolution:
accept proposal.
chair:
draft already last called, need to post changes on list.
----------------------------Presence
Data Model Open Issues
(Jonathan)
Topic:
One element vs many. Currently only one person element.
Only one
definition
for any one device or service.
question:
do we allow multiples? Represents unresolvable
conflicting
info
at compositor.
Jonathan
and Henning present arguments for each side.
Comment:
Need ability to be lossless.
Comment:
Both models may be needed.
Comment:
No _practical_ one best composition policy.
Comment:
Need something deterministic to publisher and watcher.
Comment:
Even an endpoint can publish conflicting information.
Comment:
Can we have a way to show a "preferred" view of
data for dumb
consumers,
but also show raw or conflicting data for smart
consumers?
This
requires some form of metadata.
comment:
want to do something today that allows complex solutions
in
the
future, but not necessarily solve all the hard problems now.
Resolution:
Need the ability to avoid loss and express conflicting
data.
This will come with some complexities. Will not try to
specify all
complexity
up front, but want to specify some method of specifying
a
"preferred"
instance out of a conflicting set.
Topic:
Spheres- for variables that serve as rule selectors (e.g.
sphere)
into privacy policy, need to determine which is used.
Composition
output
and rule selection are logically distinct.
Proposal:
Allow separate algorithms for rule selection and
composition.
Selection
algorithm could be local policy, or a standardized
algorithm.
comment:
composition could include conflicting spheres.
Comment:
we need to discuss atomicity of conflicting info.
comment:
determining sphere priority is policy decision.
comment:
May need to select included in composed document.
Resolution:
1)
Composition and selection algorithms are separate.
2)
Selection algorithm is application defined for now, but we may
need
to
define a default in the future.
Topic:
Multiple services with same URI
Do
we need different identifier, but with same contact ID. What if
pua
publishes
multiple serices with Contact containing AoR?
How
do you identify conflicting services vs just different
services?
How
about different services at same device with same URI? Example
of
one
softphone doing voice and IM, currently available for IM but
not
voice.
Discussion
about whether this is a capabilities problem or
something
else.
We
appear to have very different views of what service means,
before we
can
determine encoding.
Call
attention to henning point: Differentiating tuples based on
URI
equiv.
Do compositors group things into multiples based on URIs.
But can
compositors
cannot canonically compare all URIs.
Attempt
to call question:
1)
What is interpretation of two tuples with same contact URI
2)
Should we force a composer to remove and compose multiple
tuples
with
the same URI if it can tell?
Resolution:
None--take it to the list.