Minutes SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions Interim Meeting May 29-30, 2003 Ottawa, Ontario, Canada Chairs: Robert Sparks Jon Peterson Attendees: Mary Barnes Brian Stucker Adam Roach Jonathan Rosenberg Ben Campbell Keith Drage Hisham Khartabil Aki Niemi Paul Kyzivat Larry Brunet Gary Kenward Jim McEachern Tom-PT Taylor Joe Zebarth David Gibson Audio Bridge: Aziz Mohammed Avshalom Houri Brian Rosen Rohan Mahy Henning Schulzrinne Agenda: Summary of discussion/actions: ============================================================================== Message Sessions (draft-ietf-simple-message-sessions-00.txt) * Add clarifying text capturing that an endpoint is globally configured to use a visiting relay or not. It is not a per-session decision. * Keep the current goal of zero, one, or two relays. Add architectural discussion for those cases. * The requirement for explicit endpoint knowledge of intermediaries is not completely met (one side has knowledge), but since these intermediaries don't prevent e2e requirements from being met, the requirement may need to be revisited. * Add a usage section discussing using multiple sessions to avoid HoL blocking when sending large messages. * The draft will capture the list discussion on the impact of attempting connection sharing and why we decided to not include it. * The draft will address the formats a container (like message/cpim) can contain using a new SDP attribute associated with the m-line. The draft only need address the top-level formats, and one level of container formats. The draft will not attempt to allow expression of a different set of formats for different containers on the same m-line. * Because of the SDP definitions, this document will need to be reviewed in MMUSIC. * The document abstract will be rewritten. * The draft will continue to use the port in the URI and put a standard dummy value in the m-line of the sdp, maintaining the semantics of a 0 port in the m-line. * The draft will continue to define framing with a length in the start line. The discussion on using a separate session for large messages will describe how to abort a large send. * DNS A Records will be used in the order returns (per RFC1794). * The draft will not pursue use of NAPTR to discover a transport protocol, but it will not preclude future use of SCTP. * VISIT authentication will remain as is (the URI acts as a shared secret. The paranoid should use msrps. * The Tr-ID and S-URI will be added to the digest hash. The hash will use SHA1. Digest challenges are hop-by-hop - challenges are not passed through relays so there is no need to handle multiple challenges in a message. Using a separate header for the transaction identifier for SEND vs other requests was discussed and rejected. Use of SASL instead was discussed and rejected. * A different mechanism for determining connection liveliness was agreed on. Instead of refresh VISITs or BINDs, liveliness will be determined based on SEND activity (time since last byte sent) with a fixed timeout specified in this document. We will perform the appropriate engineering excercise to determine that value. * The draft will replace the current use of CMS with S/MIME. * The chairs will find a security reviewer, particularly seeking input on the use symmetric keys. * The document will register a well-known port for MSRP with IANA. Protocol messages will avoid explicit ports in messages, favoring discovery through SRV. * A mechanism for signalling TLS usage was agreed on. Roughly, the server must look for the TLS helo to determine TLS is being requested. It may fail any request with a response (code tbd) that means "not allowed without TLS". A hosting relay MUST return an MSRPS URL if the BIND request contained MSRPS. It MAY return MSRPS if the bind URL did not contain MSRPS, but occured over TLS. IT MUST NOT return MSRPS if the BIND did not occur over TLS. A visitor MUST use TLS if the session URI is msrps. A host device MUST fail any VISIT with an msrps uri that arrives without TLS. Adam will research the complexity of discovering a tls helo in a stream and subsequently sending that stream to existing tls libraries. * Require the same cipher suites for TLS as SIP does. * Add discussion of the impact of self-signed certs to the usage session * The draft will continue to use the request name BIND * Hosting requirements were discussed, identifying an issue with setup time and with forking. These issues were sent to the list. ============================================================================== Partial Notification/Event Filtering Requirements * The chairs need to assign reviewers for these documents * The requirement to send a notification when a subscription is about to expire should be removed * The requirement to be able to ask for the presence document structure should be removed (Aki will lead list discussion on this topic). * Requirement language will be reviewed to abstract the set of resources the filter applies to beyond a simple user=x concept. ============================================================================== BINPIDF/Filtering mechanism * There was a lot of discussion over the limitations of expressing filters as syntactic transformations of documents. Capturing authorization in filters is particularly difficult. Jonathan will submit a concrete filtering mechanism using some of the ideas in XCAP. Comparing the approaches will drive list discussion. * Discussion of the BINPIDF work mostly indicated that a standalone draft with no actual extensions is not needed. ============================================================================== What is a Tuple * There was lengthy, inconclusive, discussion over what a tuple represents. * There was agreement that any contact information in a presence document has a finite usable life (it expires), and the RPIDS document will be more explicit about not treating it as long lived. * Jon and Henning posited a characterization of tuple as a contract for communication. Presentities advertise availability through this contract. Watchers execute the contract to contact the presentity. Multiple tuples in a presence document signify contracts with different terms and limitations. Initially, the room was comfortable with this definition, but possible issues around atomicity and capability advertisement were raised near the end. * A design team will be formed to finish this discussion and propose a resolution to the list ============================================================================= RPIDS * The draft will be separated into a draft that just extends status values and one that addresses capabilities. The status value extension draft is currently chartered and should proceed rapidly. * The draft will split logically associated sets of features into xml namespaces * RPIDS will expand on the pidf id semantics allowing it to be assigned by the source of the tuple (typically the publisher) and be valid over a longer timespan than a subscription. Requires that the set of publishers must produce ids that are mutually unique. * General consensus was reaffirmed on designing manipulation of presence documents such that operations on tuples is atomic. A compositor may create a new tuple with information from tuples it has been provided. This new tuple is an atomic element that is created, and possible signed, by the compositor. ============================================================================= Publish: * There was detailed but inconclusive discussion on how to solve the dueling-publisher problem. There is still dissention around how to model who is an "authoritative" source of information. The two leading concepts are exemplified by the proposed If-Unmodified-Since/412 mechanism and one where all information comes with a timestamp, or a version to avoid artificial race conditions generated by discretizing clocks, declaring when it became valid - most recent timestamp/version wins. It isn't clear yet what "when it became valid" means. The later concept received the greater discussion. * Consensus was reconfirmed that Publish is not done within the context of a dialog or session. The current REGISTER-like requirements will be removed from the document * Each tuple will be published independently. Adding the mechanics for handling publishing multiple tuples introduces too much complexity. * Non-tuple data (like note) will be manipulated using the data manipulation system instead of publish. * The document will capture that we are explicitly not trying to solve the problem of humans publishing dueling state. * Document needs review to ensure it is applicable to event packages other than presence. Atomicity of publication was identified as a core concept each package must define. For presence, the atoms are whole documents or tuples. * A suggestion to split this document into one defining a generic publishing system, and one detailing Event: presence was considered and rejected. * A tuple to be deleted will be identified by a minimal tuple in the body of a PUBLISH with a value of closed. * A problem with system-configuration was discussed, noting that forwarding all requests to a new URI (such as for call forwarding) can break composers. There was agreement to document this problem, and agreement that this discussion belongs somewhere other than the PUBLISH document. * A problem with state-inconsistency during migration was discussed. Again, it was suggested that the problem be documented, but that the documentation belongs somewhere other than the PUBLISH document. ============================================================================== Data Manipulation - XCAP * The proposal was favorably received. with some discussion leading to agreement that it is necessary to standardize a baseline realization of the protocol semantics as part of the effort instead of only the data formats and abstract semantics. * The chairs will investigate bringing this proposal to wg item status. There may be intersection with the netconf work. * The URI used in requests must have a separator between the document identifer from the query string. More research is needed before defining that separator. * Manipulating multiple components is nontrivial. Several approaches were discussed, including manipulating the least-common-parent element, creating a wrapper document, and introducing locking semantics (perhaps using Webdav). Jonathan will investigate how much of Webdav would have to be implemented. There was general consensus not to pursue a wrapper document. Jonathan will lead a followup discussion on the list. * There was consensus to not pursue representing metadata in a query string * The draft currently says server must understand the application. It may be possible to relax for some situations: no computed data, no data constraints, baseline auth policy. A proposal to address this by defining a "datastore" application usage later and not modifying the core document was generally accepted, but Jonathan noted there may be a couple of issues that have to be mentioned in the core document. * There was agreement on the proposed default authorization model and the requirement on application usages to specify anything more complex. * There was discussion leaning towards always rejecting PUT and using POST for all operations.