Session One: 0900-1130
Session Two: 1300-1500
Chairs:
Robert Sparks
Jon Peterson
Summary of major consensus points and action items: (All consensus points are subject to confirmation on list.)
(Thanks to Dean Willis and Vijay Gurbani for acting as notetakers)
Session One:
Notes by Dean Willis
Topic: Agenda Bash
No changes proposed
Topic: MSRP Open Issues, Ben Campbell
Slides presented.
Status reviewed.
Issue: Shutdown of Relay. Does spec need discussion of clients reconnecting?
Issue: Send Failures. If a SEND request times out on a tcp connection, is a resend likely to succeed? Consensus seems to be that this sort of failure indicates a dead connection, which should be closed and reconnected.
Issue: Should there be a protocol failure message sent before closing the socket? Debate around whether it is possible for a slow-link transmission delay from a relay to produce a timeout on a SEND. Should a resend use the same TR-ID? Consensus: yes.
Issue: In the cross-session (new INVITE) retransmission case, we have a question on the requirement for duplicate suppression, which would require globally unique TR-IDs, and require endpoints to remember TR-IDs across sessions. Do we need a mechanism to suppress these duplicates? No consensus, question deferred to list.
Possible Major Issue: It is not uncommon for a TCP connection to get whacked by a NAT-binding reclamation. Currently, if this happens, we have to re-invite. This is probably not a reasonable design constraint and requires list discussion. The current BIND/VISIT semantics are problematic, as they clean up state in relays. One possibility would be to make the BIND protocol "stateless" and carry the entire connection info in it.
Issue: Session Purpose. Current guidelines suggest a dedicated session for things like large content transfer. What keeps the other end from sending IMs on this session? Is a "one way" indicator (send only) adequate, or do we need a more semantic indicator? Seem to have consensus on send-only, with a small amount of clarification in the text.
Issue: Session Teardown at Visting Relay. This needs to factor in the TCP-reconnect stuff, so connection is deferred.
Issue: SEND for Keep-Alives. Currently, empty SEND messages are used to refresh the activity timer. Do we need another method instead of SEND? Suggestion made that a relay reset the timer whenever it sees ANY traffic, so any message, including a proposed "bodiless send with a new name" should reset the timer, effecting a keepalive. Question: Is bidirectional traffic required for keepalives? This raises the question of what happens in large-message conditions. Question deferred to list.
Issue: Multiple Digest Algorithms. HTTP digest requires a seperate challenge per algorithm. Do we need to do anything other than this? Suggested that unless there is a very compelling reason to annoy the security people that we just continue to follow the HTTP model. Consensus to continue forward.
Issue: Security considerations. We have several suggestions for improvements. Cullen is to send text on TLS usage. Question on whether we expect self-signed certs to work between relays (consensus, probably not). Also a suggestion that more attack scenarios are needed.
Issue: MIME Usage. Action item: incorporate "normal" usage of MIME include Content-Disposotion.
Issue: More Examples. Do these need to be in core MSRP spec or in a seperate example document. Suggested that we follow the SIP documentation model, but that more clarification of some of the existing text would help.
Issue: Congestion. We have multiple TCP connections between relays. Is this a slayer of the commons? (Editor's note: The question is will having multiple connections cause traffic on other TCP streams to be treated unfairly). Does this need more discussion? (discussion followed). A "Large provider of IMs" reports that they have seen a requirement for connection reuse. Question: Is this related to congestion, policy enforcement, or TCP fan-out? Comment that we don't need an either-or solution. We have considered adding muxing later -- have we done anything to preclude it? Proposed that we split out relayance, or muxing, or relay muxing as seperate docs. Hum requested: Do people feel that relays without muxing are useful. Consensus yes. Poll on who will implement MSRP? About a dozen. Poll: Who will implement MSRP without relays. About six. Who would do relays with nat but no mux? About two. Who would do relays with nat and mux? About a dozen. Conclusion: Of the people who are willing to do relays at this stage, they seem to want muxing and chunking. Poll: should we rip out relays now, and do a seperate document for relays and muxing later? About a dozen. Should we continue as is? About 2. Proposal that we split up into core and relay docs, and set a hard date for deciding whether to include muxing in relayance. Noted that 3GPP seems to be using MSRP. Consensus: We rip out relays. Comment: This breaks TLS. Author thinks this is doable by the end of the year. Chair directs author to put a list of issues on the list ASAP, and to work with the relay-complainers on getting a list of relay requirements. Rohan volunteered to incorporate relay requirements into a draft.
Topic: Presence Document Usage, Robert Sparks
Slides presented.
Issue: Can you associate a service with a tuple? Analysis by use case proposed, working from characterizing services by characteristics. Room indicated general support for current document and little interest in discussing it here at this time. Several people volunteered to send additional use cases. Proposed that we divide the problem into two 1)How to use PIDF, and 2) Representing specific servcies in SIP URIs. It may be that the "service" respresented by a SIP URL is not as clearly defined as the "service" represented by a Mailto. Proposed that this be resolved in the tuple referencing the service. Question: Will we include teletype use case? Ans. If you have a use case, send it in. Question: Will this be published as an RFC? This is currently an exercise in requirements and feasibility analysis. It might get published eventually by transformation into a call-flows document.
Topic: Partial Notification, Mikko Lonnfors
Slides presented.
Changes since last version reviewed.
Noted that no comments received on list recently. Consensus: Move to WGLC.
Topic: Presence Capabilities, Mikko Lonnfors
Slides presented.
Changes since last version reviewed included harmonization with callee-caps and new XML schema.
Issue: "<contact uri>" with prescaps -- what should be used? A contact? A GRUU? an AoR? This relates to the capability-merging model of callee-caps, but different. Consensus: AoR, representing union of capabilities.
Issue: What capabilities? Conclusion: Publish as much as you can subject to privacy constraints.
Issue: Contacting particular UA. Conclusion: Construct Accept-contact using prescaps.
Issue: Syntax for negated featurs in lists. Options, !-notation, and "negated" parameter on feature element. Conclusion: use "negated" parameter. Discussion of content vs. attribute debate raised. Conclusion: ask an XML expert.
Issue: Extension tags. Current mechanism requires a new namespace for extension tags. Typed extension parameter syntax proposed. Discussion taken to list.
Poll: Adopt this work as a WG effort? Consensus to adopt noted.
Topic: 3GPP Requirements, Aki Niemi
Slides presented include must-have dates.
No conclusions.
Topic: XCAP Patching, Lisa Dusseault
Slides presented discuss HTTP PATCH request which may be applicable to XCAP.
Noted that either etags or locks must be used to prevent conflicts. This relates to the etags discussion around PUBLISH.
Topic: Event Filtering Requirements, Hisham Khartabil
Slides presented.
Noted that reviewers who volunteered at last meeting failed to deliver.
Topic: Event Filtering Format, Hisham Khartabil
Issue: XPath Usage. Replaced in current draft with own BNF which is similar to a subset of XPath.
Issue: Filtering by namespace. Added based on suggestions from last meeting.
Issue: Applyling filters to domain. Unresolved. Needed for xcap-auth.
Issue: Filtering scope is too large. Discussion: we could establish scope based on use cases. If we don't know of a tuple requiring a proposed filtering feature, we can descope it. Poll on adopting as a WG item? Generally favorable, consensus determined by chair.
Topic: Filter Functional Description, Hisham Khartabil
Issue: Full vs. Partial State. There seems to be confusion between the full and partial flags in the notification XML and the concept of filtering. These two things are independent -- the full/partial flag refers to the current view, and the current view is defined by the filter. Consequently, filtering does not mean that all notifications are partial.
Poll: Who has read? Very small number. Debate on adopting as a WG document ensued. A hum indicated consensus to adopt.
Session Two: Notes by Vijay Gurbani
XCAP Jonathan Rosenberg
Changes in main spec:
Tried to get aligned with HTTP usage (a list
of changes in the slide). Previous open issue: return content in
error response to indicate what is wrong. Don't need it anymore and
removed it. No questions from the floor.
Open issues from the list:
Filename:
Does the xcap URI have a filename extension in it?
Proposal: with filename extension. (No comments on floor).
Mimetypes:
What MIME type is indicated in PUT request and
GET responses? Proposal: app/xml when it is an XML doc and
text/plain for attributes.
Adam: did you pick one or any reason not to use MIME type of
the body.
Jonathan: I don't think it matters too much.
Adam: Reference the ad-hoc stuff we've been talking about on
the wg list. Maybe we need a special MIME type app/xml-snippet.
Jonathan: I am a little leery about this...
Chris Neuman: You need to register an xml fragment. It's a
fragment of an XML doc, so label it as such.
Event package:
What is the fate of this? Did not rev the doc
much less discussion on wg list. Big question: integrate
with SIP config framework? SyncML?
Proposal: Move forward with important pieces of work (xcap, xcap-
auth, xcap-list) and work on this later. People OK with this?
(Some discussion between Rohan and Jonathan, but does not
appear to be any objection).
Etag scope:
Current spec associates a separate etag with each XML component
creating a dependency heirarchy. Problem: how does the client
know what those other etags are? Proposal 2: Don't do it, maintain
one etag. Proposal 2 is simpler ad list discussion indicated
Proposal 1 had serious compliance problem to the spec. Recommendation:
use Proposal 2. (No one objected and no other proposals).
Query v. Path:
Query appraoch is better for servers; path approach
works better with existing implementation and hides implementation
details. Proposals: path approach.
Lisa D: If you have a URL with path elements inside a conceptual
doc which is not compatible with webdav, I don't know what you
would do with http when someone tries to present these URIs. It
is incompatible with existing implementations.
Ted: This should be permissible and implementable (disagree
with Lisa).
Error reporting:
Current revision has no error reporting; however,
there could be recoverable errors and how to indicate this?
Question: can we put XML body in a 409 HTTP response?
Lisa: Yes. You have to be careful, but extensions to HTTP do
that.
Ted: Will anything break if you include it? Probably not.
But you should define in this extensions what the content
disposition should be -- display it to the user, or treat it
as garbage.
Hisham: Is there an HTTP header like Reason or Warning that
we can use?
Lisa: No.
XCAP list:
Changes in this rev: is it an http extension or something else
altogether? No consensus yet.
Chris: Scheme name represents the app to me; http means hyper-
text app. XCAP to me is a different scheme and should have
a different port. Treat this as a different service. This
is not accessing docs stored there, but modifying data. More
sophisticated service than simple http.
Ted: BCP 56 says you should not use http as a substrate for
other apps. Generically we do not want http to be used for
layered app, but you've been careful to construct this as an
original application for http -- gets and puts. XCAP should
be a usage of http.
Lisa: It's a grayscale and a matter of judgement when it
stops being http.
Chris: I may be a little more conservative. I don't see
this as something that a browser would render. If what you
are looking for is code reuse, you can conceivably use
the same http libraries but have them go to a different port.
???: Subdocument URIs are not what standard http server
implements or client understands, regardless of it being
on an http port.
Aki: what is important is to keep the functionality 2616 and
not invent new headers or whatever.
Ted: Do you see the development of this long term not being
backward compatible with http as a whole?
Jonathan: Need to work more on wg mailing list.
XCAP auth:
Axed this document seriously for simplification.
Open issues: alignment with geopriv and lying/polite blocking.
Geopriv is working on the same problem: geolocation and
presence are intimately related. We use PIDF doc to carry
geoloc info right now. In RPID there is a PLACETYPE element
which can be used as a start. Industry looking for geoloc
and presence as a service.
Rohan: Also enhances the IMPP value proposition.
Are folks interested in actively aligning geopriv and simple
wgs in how they represent data? What do people think?
Adam: I see the value but from a practical viewpoint I see
a hard time putting together a solution that does not include
exceptions.
Ted: I see a great value; folks who want this would prefer them
to use the same system. Presence is one of the most
critical use of geoloc resources. So, yes, I would like them
to align.
???: In favor of this approach. Need to deal with some technical
and document issues.
???: In 3GPP device, geopriv is somewhat of an unknown and simple
is more prevelant. If we get this aligment done in IETF would
that result in any gains outside?
Robert: Group is interested in learning what alignment would
mean. Let's move on now.
Issues: exceptions need to be treated carefully. Can't use
them for a pure blacklist. Exceptions don't deny a user
permissions - they allow a conveinence for enumerating a long list
of people to whom a rule applies.
Ted: geopriv wants exceptions to work. Problem is a timing one.
If geopriv does not get its work done by the close of this
year, it'll be a lame duck. geopriv has a slightly different
problem: group membership has to be resolved.
(Long discussion ensued on exceptions. Issues include
federated service providers, users in an enterprise, issues of
accessability of lists from providers, revocations, white
lists and black lists, etc. Chair interrupted since the
discussion went out of time.)
Conclusions: can't draw any right now. Jonathan to post the
slides and continue thrashing out the issues on the SIMPLE
mailing list.
Robert: This is a hi-priority discussion that we need to
close in 9 days max!
Aki Niemi, Watcher info history
Background: 3gpp mentions winfo-history and some commercial
systems have similar functionality.
Jonathan: What is the use for this? I have authorized you
to watch me anyway. Why would I want to know that you
were watching me for 2 hours. Massive amount of data
generated.
Jon: We would like to see the motivation before accepting
anything as a requirement.
Orit Levin, Ad-hoc resource lists using subscribe
Motivation: solves an acute problem of batched notifications by introducing the RLMI schema. Cannot be deployed in an interoperable manner wihout standard creations of 'soft' or 'hard' lists.
The ad-hoc list dynamically created and modified by a watcher. The list creates a soft state in the RLS and exists only for the life-time of a SUBS dialog. NOTs are being sent in any agreed format (PIDF, ...) The proposed solution: new option tag: adhoclist and new Media type name: application/addrl+xml *Went through a call flow; see slides, slide number 5-9)
The solution relates to draft-camarillo-sipping-exploders-solution-00.txt. However, this I-D is classified as being in a B2BUA. It is an excellent case study: longtime identified reqs, technically straightforward and no new security risks.
Proposed next steps: define as a WG working item in SIMPLE, if accepted start polishing the spec details on the list, and the standardization timing is crucial.
Robert: Related proposals to this that arrived from many
different directions. Group is ready to start exploring
this space. But we are not ready to adopt one document
as a wg item right now. Let's have list discussions first.
It's getting list attention and let it continue for a
couple of weeks and revisit this again.
Adam: In many places in your presentation, you
mentioned a series of requirements that are not met
by the existing solutions, such as XCAP.
Is there a specific requirements document you had in
mind? I propose that we need to figure out what requirements
are not met by existing proposals before we continue down
this path.
???: Can we work this in the SIPPING WG where we are
pursing a more general solution?
Hisham: problem not specific for subscribe.
(Further discussion directed to list)
XCAP Usage for publishing presence info, Markus Isomaki
Motivation: Every device publishes its state independent of other devices. Each devices cannot access the publication state published by others. There is need to be able to publish PUA/device indepedent data about the presentity. It must be possible to fetch and update this data from any device. Examples of this data: presentity's home page.
Why XCAP? allows manipulation of data on a server. SIMPLE presence apps already use XCAP to manipulate lists.
What the I-D specifies: define a new AUID: presence-publish. PIDF XML schema and its extensions (RPID, CIPID, Prescaps, ...) No computed data or additional constraints.
Open issues: how to publish content which is external to PIDF? (images, logos?)
Proposal: use CID URIs, upload external content via HTTP, insert http URIs to PIDF doc, ...
Ben: This is an open issue that applies to publish and notification in general.
Next steps: adopt this as a wg draft?
Ben: change name of I-D.
(Hum taken to establish this as a WG doc; hum indicated support).
14:50 Meeting adjourned.