[Simple] Draft minutes - SIMPLE - IETF61

[Robert Sparks <[e-mail]>]

Please review - send any corrections to the list by this Thursday 12/9.

Thanks,
RjS
-----------------------------------

Minutes - IETF61 - SIMPLE WG meeting - Washington, D.C.
(SIP for Instant Messaging and Presence Leveraging Extensions)

Summary:

MSRP:
   Several changes were made in response to Sam Hartman's
   security review. The group is comfortable with those changes.
   The number of open issues is rapidly decreasing - we expect
   these drafts to be last-called after thier next revision.
   The chairs will obtain appropriate review of the drafts use
   of SDP.

Presence Rules:
   The group extensively discussed what it means to allow rules
   based on anonymous or unauthenticated identities. No specific
   decisions were made during this discussion.

Partial PIDF:
   The group noted the similarity between the differencing
   mechanisms in this draft and the mechanisms in XCAP. There
   was consensus to work towards a common mechanism.

Partial publish/notify:
   Draft will be clarified with guidelines on when to use the
   partial mechanisms.

XCAP:
   The group rejected a proposal to allow idempotency tests
   other than GET(PUT(X))==X. Jonathan will make minor revision
   to the core draft which will then be ready to submit for
   publication.

Presence Data Model:
   The group reached consensus that the model must provide a
   way to pass potentially conflicting information through a
   compositor without losing data.
   The group concluded that the  algorithms for applying
   composition and selecting policy rules will be different.
   There was extensive but inconclusive discussion around
   differentiating services (tuples) based on URI equivalency.

Raw notes from each session follow:

-----------------------------------------------------------

Notes, SIMPLE First Session, IETF61
Reported by Dean Willis

Agenda bashed.

Status of various drafts presented on slides. Noted that "is
composing" is in RFCED queue, not IESG queue.

Topic: MSRP
------------------------------------------------------------
Discussion lead by Ben Campbell
Slides presented.

Changes since last pub and dependencies reviewed.

Changes from security review:

Added applicability statement around usage with rendezvous/negotiation
protocols.

Mapping of "im:" URIs. This needs to be in  a separate
document. Dicussion ensued as to whether MSRP blocks on this
document. The general consensus is that it does not, as MSRP never
sees an "im:" URL (this would be a rendezvous dependency).

Security review suggested reintegrating core and relay
drafts. Consensus seems to be to resist that suggestion. Suggested
that the full security story needs to be in one of the two drafts.

Previous deaft missed RFC 3682 Application Considerations on usage of
CPIM headers. This has been clarified.

Open issues:

"?" Parameter Syntax: Proposed that this be added to the next
rev. Discussion: Cullen has a concern that this may break the security
model and will review offline with author to ascertain.

Overlapping Chunks: Concluded to recommend that most recently received
chunk wins unless the application domain dictates otherwise.  No
arguments raised against proposal.

Report handling: Consensus among authors that current draft is
underspecified. Proposed that negative reports be "per chunk" and new
incremental values for Report-Success (as well as per-message) be
permitted. No argument raised against proposal. Further: Relaible
delivery requires positive Report-Success or incremental,
Report-Failure allows rapid failure detection (along with normal
failure timeouts). This would require requesting both success and
failure reports at session setup. No argument against
proposal. Further: Proposed that spurious reports be silently
dropped. No arguments araised against proposal.

Discussion: Does Section 8 (O/A, SDP Ext.) need to be reviewed
elsewhere? This includes some a-line attributes and fmt, and that
sdp-new requires a more detailed registration process. We may also
need to register TCP as a transport. Task: Chairs will work it out
with other chairs and ADs. Note: TCP has been registered as part of
comedia.

Discussion: Have there been any implementations? One report of
preliminary implementation experience, on which the developers had
"serious heartburn", primarily around the abnf that was supposedly
fixed in this release. One other concern was raised around handling
the closing -- given the structure, one can't detect flow end strictly
by ABNF, and list consensus was to stay with this.

Discussion: Is the flow control built into MSRP justifiable? If so,
then we need a relay push-back capability to handle
buffer-overflows. This interacts with "many-flows onto one-TCP"
plexing, and providing reordering of chunks. Argued that reordering is
required anyhow, so this is no added complexity. Conclusion is that
the current text seems consistent with our understanding of
requirements.

Discussion: Similar SDP-ish stuff is being described in BFSCP. Should
we unify? Concluded that the authors will get together and discuss.

Further discussion on implementation: Implementors seem to be
deferring deployment until the RFC is published. This view is
supported from experience reported in 3GPP about their attempt to use
MSRP.


Topic: MSRP Relay
--------------------------------------------------
Discussion led by Cullen Jennings
Slides Presented

Noted that we need one example in text. Other than that, there have
been no comments on-list.

Poll: Who is planning to implement MSRP base? (Many, app. 40). Who is
planning to implement MSRP relay (much smaller, app. 9).

Poll: Who plans to read and comment during last call (very many, 1/3
of room).



Topc: Presence Rules
---------------------------------------------------
Discussion led by Jonathan Rosenberg
Slides presented.

Slides review changes from previous version.

Discussion of anoymous: Seems to be a desire to differentiate an
"unknown user" from a "user authenticated to the network who prefers
not to disclose". Is a non-authenticated "From" identity not the same
as anonymous? How does this relate to Caller IDs "Anonymous" vs
"Unavailable"? Is there a need to present anything relative to the
strength of authentication used? Proposed: no plan to add an
"authenticated" condition. Unauthenticated identities will be
considered comparable to "unknown". Local policy will determine
whether any specific authentication technique counts as
"authenticated", and techniques below this threshold would be counted
as "unknown".

Proposed that we may need a way to match "any" identity in a rule.

More discussion.

New proposal: Delete special treatment "for authenticated but
anonymous" and consider all non-revealing identities "unknown".

More discussion.

Point: Unauthenticated should NEVER receive more information than
"authenticated but anonymous".

Editor: Why does nobody seem to understand that this is a two-axis
system?  Axis 1 is "Authenticated vs. Unauthenticated", and axis 2 is
"Presenting vs Not Presenting Identity", and that decisions need to be
made for at least three of the four resulting tuples?

No conclusion noted.

Changes since last rev reviewed.

Several issues drew brief discussion with some suggestions of
discussing offline.

Discsussion returned to identity, the uncertain, and the unknown. The
result was unclear.

-----------------------------------------------------------------------
(Note that we were fortunate enough to have two notetakers for
  the second session. Both sets of notes appear here)
-----------------------------------------------------------------------

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.

-----------------------------------------------------------------------
(Note that we were fortunate enough to have two notetakers for
  the second session. Both sets of notes appear here)
-----------------------------------------------------------------------

Notes, SIMPLE Second Session, IETF 61
Reported by Dean Willis


Topic: PIDF Partials
----------------------------------------------------
Discussion led by  by Jari Urpalainen
Slides presented

Comment: There would be a benefit to having some sort of XML
compression and partial scheme that would work across
applications. Discussion followed on this approach vs xcap
diff. Author maintains this approach is shorter and should replace
xcap diff. Suggested that there should be comparisons made with real
messages.

Comment: It appears that the net effect is that we have different XML
element names.

The previous proposal worked on the element level, whereas this
approach is doing more of a syntactic patch.

Consensus: We should settle on one technique -- this or XCAP diff, or
whatever. Noted that XCAP diff is already a WG document, so we should
study this approach and see what, if any, makes it better, then add
that to xcap diff.

Chair commentary: This is the result of convergent evolution, and we
should take this to the list for convergence. We do still have a need
for partial notification. We should also check with people outside
SIMPLE who are doing XML diffs.


Topic: Partial Presence
------------------------------------------------------
Discussion led by Aki Niemi
Slides presented.

Goal: A small change in presence should produce a small NOTIFY.

Noted that this technique should work for any event package using XML
bodies.

Observed that sometimes, for a very small document, a partial update
might be larger than a full update due to the extra syntax. It was
discussed as to whether the draft has adequate guidance on "when" to
use the partial format.


Topic: XCAP Needed Diffs
-------------------------------------------------------
Discussion led by Jonathan Rosenberg
Slides presented.

Issue: Noted that draft needs to clarify usage of term "idempotency".
Discussion of this term and usage followed.

Issue: Namespace prefix definitions. Fix proposed in
slides. Discussion: Could this lead to a collision? Ans. No, the
prefix definition is at the service element itself.

Conclusion: Author will submit a revised draft.


Presence Data Model Open Issues
--------------------------------------------------------
Discussion led by Jonathan Rosenberg and Henning Schulzrinne
Slides presented.

Issue: One element vs. many. Current system does not allow conflicting
data. It has been proposed tha twe allow multiple service elements,
representing conflicting input to the compositor, allowing the watcher
to decide.

Proposal: Stay with existing system (argued by JDR). This generates
issues for automata as consumers of services. This may also lead to
multiple ways of interpreting conflicting data vs. simultaneous
capabilities, and could be problemactic. This also requires adding a
tuple/element identifier, and may need lots of additional metadata to
make the interpretation feasible. Alternate approach would be to add a
"<conflict>" wrapper later.

Proposal: Add support for many elements (Argued by HGS). Most existing
presence systems have only once source of presence data. They don't
need to do multiple elements. However, we are now building multisource
systems, and need multiple elements to meet additional requirements
listed in slides.

Noted that one could add a "<view>" or "<conflict>" wrapper now, to
accomplish something similar, but that if it is added "in the future",
we will have a major backward compatibility problem.

Disussion follows . . .

Observed that conflicting data will occur -- the Question is how to 
deal with
this. Is there really a correct composition of this data, or is there
a consumer decision that is needed? We probably have a need to support
delivery of both "vest guess" composition AND full data to consumers.

Observed that we may not know how to do the "best" composition in all
cases, and therefore probably need to be able to expose uncertainty to
the watchers.

Observed that it may be important that the publisher understand what
the compositor is going to do with its data. This may lead to a need
for source-expressable composition preferences, which is hopefully a
"future" topic.

Proposed that we need to support both models.

Proposed that HGS' model would benefit watcher-specific composition.

Noted by chair: This means that an "original source" could publish
conflicting information.

Proposed that the presence document should be able to indicate the
"preferred" view among conflicting views, and that this would be
usable by "dumb" clients. Also noted that "outgoing" policy might
dictate which view is shown to any given watcher.

Proposed that there is no "one true answer" for composition.

Proposed that a timestamp is not enough to indicate the "preferred"
element out of a compositor.

Chair summary: Not acceptable for us to produce a lossy model. We want
the ability to pass through additional information. We understand that
this increases complexity. We will not explain everything, but will
provide a hint as to to which one of the conflicting elements is
recommended.


Issue: Sphere

If we have multiple elements, we may have conflicting sphere
information. This breaks the current model of using the default
composition policy to select which authorization policy applies.

Proposal: Allow separate algorithm (not same as default composition
policy) for determination of which conflicting variable is used for
authorization policy.

Much discussion followed.

Proposed that perhaps authorization policy should be driven by the
view that would be seen by the presentity as a watcher.



Issue: Mutiple Services with Same URI

Much discussion followed.

Noted that there are deployments that don't support GRUU and that some
are hestitant to make the solution GRUU dependent.

Noted that "Open" and "Closed" at a top-level are inadequate as soon
as there are multiple capabilities per device.

Discussion devolved into an apparent divide between model views.

Chair point: We keep talking about differentiating tuples based on
URI equivalency, and whether compositors group according to these same
comparisons. This necessitates that compositors be able to
ascertain the equivalency of two URIs, which might be difficult. We
appear to have no consensus on this at thsi time.

Summary: This is going to make a long list discussion, and we may not
have even stated the problem clearly.


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