Minutes, SIMPLE Working Group, IETF 59
recorded by Dean Willis
Monday, 1 March, 2004 1930 GMT+9
Meeting called to order by Robert Sparks. "Note Well" slide presented.
Agenda accepted as presented.
Topic: Status by Chairs
Slides presented reviewing current status.
------------------------------------------------------------------------
Topic: RPIDs, Henning Schulzrinne
Slides presented review status and open issues.
Issue: Extension namespace model. PIDF calls for one namespace
("status") for all extensions as top-level elements. Do we define
extenions from RPID as top-level elements in this namespace, or extend
from other namespaces? namespace model discussed at some length . . .
This MAY be an error in the PIDF documents, and Jon Peterson will
examine them and see if something is needed there.
Issue: CIPID e vs . Allowing both accepted.
Issue: CIPID by value or by reference. Question: Can we assume
multipart MIME in CIPID systems? Answer (Peterson) is No. Proposed
that we ignore for now.
Issue: future-status implies past-status. Should we go back and call
it time-status? No objections.
Conclusion: Ready for WGLC after next revision.
------------------------------------------------------------------------
Topic: MSRP and Relays, Ben Campbell
Slides presented.
Issue: SIMS and MSRP. Proposed to take ideas from SIMS and apply those
as an MSRP Relays extension draft.
Issue: Session identifier. Proposed to use URL tuple, no objections.
Issue: Shared connections. Proposed to bring this back into scope. No
objections.
Issue: Message Framing. Change to boundary based framing instead of
content-length: No objections.
Issue: Message Chunking. Allow RFC2616 message/byteranges. No objections.
Issue: return-receipt. Proposed r-r request used optionally. Open
issue as to whether this is per-message or per-session. Consensus on
per-session. Since this is not needed for peer-to-peer, do UAs always
know at SDP-creation time whether the session will be peer-to-peer?
This needs further work.
Issue: Direction atttribute from co-media. Directionality not needed
when at least one relay is used. We may need something with co-media
expressiveness without directionality. Further thought is required.
Issue: co-media. Do we need co-media at all? Needs more thinking. If
we do something here, it will need to be reviewed in the Transport
area, preferably in MMUSIC, or by someone from Transport assisting
Apps. Our usage here works because we have a demuxing property at the
application layer, which must other usages of co-media would not. Is
MMUSIC willing to accept this restriction? Discussion contnued on the
bogdown of co-media in MMUSIC. Discussion of use case where one
endpoint is behind a nat or FW and the other is not. Do we need to
solve this without a relay? We know that if both parties are behind
nat/fw, we will need a relay. Poll: Consensus that it is OK to require
a relay in this case. TO DO: AD asked document editor to include this
discussion of rationale in the draft revision. Discussion continued
along lines of ICE and requirements for routing optimality.
Issue: Proposed Relay Draft. Discussion on message chunking raised
possible requirement for operating without transaction response. It
was argued that nack-on-index-failure requires less processing than
ack-on-index. This is analagous to the window-ack model in
TCP. Concluded that we continue with positive ackowledgement while
interested parties conclude the analysis of the alternative. TO DO:
Orit Levin will document and publish an analysis of the alternatives.
Issue: Relay requirements deadlock. Conflicting requirements
documented in slides. Current apporach requires hop-by-hop
buffering. Proposed that we just live with it somewhat controversial,
but no sustained objections.
Issue: Wrapped Type mechanism may be too complicated. Proposed that we
just leave it as-is, no objections.
------------------------------------------------------------------------
Topic: XCAP, Jonathan Rosenberg
Slides presented.
Changes since last rev reviewed. No objections raised.
Issue: Fragment MIME type. Options application/xml-frag+xml or
application/xml-frag. Discussion ensued. To Do: change to
application/xcap-frag+xml.
Issue: ETAG scope. Singular etag scope for presence document breaks
multiple editor model. Proposal that etag scoping be left to the server
accepted, no objections.
Issue: Schema extensibility. Currently, each document lists required
namespaces. Proposed that we use a negotiation technique using a
"supported-namespaces" element in the user tree and an event package
for change distribution. To Do: Implement proposed change.
Issue: Insertion Point. Current spec does not specify insertion points
when multiples are possible. This breaks position specs. Proposed that
we mandate insertion at the end. Concerned that this may still be
non-deterministic resolved by discussion of etag usage.
Issue: Other selectors. We could use additional selectors to manage
ordering issues. Proposed that we do not address at this time. No
objections raised.
Issue: Multiple insertions. We may need to insert multiple elements
with a single operation. Proposed to use xpath "union" operator.
Concern raised that this functionality might delay XCAP. Conclusion:
Discuss further. To Do: Jonathan will send out more text for review.
Issue: Directories. No objections raied to approach proposed in slides.
Issue: Authorization changes. No objections raised to current appoacch.
Issue: Semantic vs. syntactic. Current policy model is syntactic,
which allows semantically incorrect policies to be
constructed. Proposed to take a semantic approach forward. To do:
Jonathan to document semantic approach. Suggested that there is a
requirement that proprietary policy extensions in clients not require
matching server authorization extensions.
------------------------------------------------------------------------
Topic: Advanced IM Requirements, Jonathan Rosenberg
Slides presented as part of preceding deck.
No proposals to discard any specific requirements.
------------------------------------------------------------------------
Topic: Partial Notification, Mikko Lonnfors
Slides presented.
Open Issues: Repetition of text from presence event package. Chair
requests review comments.
------------------------------------------------------------------------
Topic: Presence Capabilities, Mikko Lonnfors
Slides presented.
Open issue: Separate . Proposal: Add element outside
<[media]> elements. Possibility of sub-types raised. Alternatives
discussed inlcude media-specific sub tags. Argued that this conflicts
with "negotiation" phase of SIP. This diverged into a discussion of
REGISTER vs PUBLISH, and did not resolve into a conclusion.
Open Issue: Extension tags. Do we need existing tags? Do we need more?
Is this a schema change? General consensus seems to be "just use
XML". Discussion deferred to list.
------------------------------------------------------------------------
Topic: Interdomain Requirements, Orit Levin
Slides presented.
Issue: TCP HOLB avoidance on TCP links. This seems to be a
controversial requirement.
Issue: Server-mediated model. Suggested that we should also include
proxy-server-less nodes in model.
Issue: Proposed that we include co-located servers in different
domains.
Issue: Presence Info Optimizations, New Functionalities
Conclusions: Further discussion to list. Noted by AD that mechanisms
in this draft lack adequate security considerations.
------------------------------------------------------------------------
Topic: XCAP Complexity
Poll: How many people think they know enough about XCAP to be able to
help bootsrap others? Four hands were raised.
(Chair note: A second session was scheduled to address this. The minutes
from that session appear below)
========================================================================
SIMPLE XCAP Tutorial
Led by Jonathan Rosenberg
Notes by Dean Willis
March 4, 2004 1300 GMT +9
Gardenia Room, Lotte Hotel, Seoul, ROK
The purpose of these notes is NOT to document the tutorial, but to
record any working-group related decisions that might arise during
this meeting.
Slides are at:
http://www.jdrosen.net/papers/xcap-tutorial.ppt
ToDo list:
1) We need to make sure that the preservation of client-provided
namespace prefixes is declared as a MUST level in the XCAP
specification.
2) Check up selecting attribute in xcap when value is escaped -- does
the return value contain the literal?
3) Clarify XCAP spec on selection behavior when there is partial
repetition on the attributes -- for example, when the query
specifies attr="2" and there are two difeerent records having this
attribute but varying in other attributes.
4) There appears to be an unhandled case where the application
validating the xcap document finds that the document is
invalid. The XCAP server already returned a 200OK to the client,
but the application has decided to reject the new document. How
does the client know?
5) Investigate the possibility of returning a 306 redirect from HTTP
requests so that you can be redirected into a quota-controlled
space. If possibly, needs to be clearly said in XCAP.
6) Clarify discussion of filename extensions question.
7) Talk about escaping in document (see #1).
8) Document If-None-Match * etag matching to make sure that attempts to
overwrite an existing document don't create a new resource. Also
document return codes for differentiating the two cases
ex-post-facto.
9) Clarify that ordering of schema and existence both impact insertion
placement.
10) Clarify use of positional parameters to add repetitive elements
and interaction of repetitive elements on selection.
11) Look at WebDAV 409 generic error body return and see if we can
reuse it.