Instant Messaging and Presence Protocol WG (impp) Wednesday, August 08 at 1300 - 1500 ==================================== CHAIRS: Leslie Daigle Mark Day AGENDA: 1. Agenda bashing (2 min) 2. Overview of schedule & documents (3 min) 3. Open issues [see summary below](90 min) a. SRV format ("The DNS thing") b. FETCH with 0 time c. CPIM accurate on success vs. refused vs. failure d. IM use of message/cpim e. Status of draft-sugano-cpim-pidf-00.txt f. Role of XMLDSIG and relationship to sugano-cpim-pidf 4. Gatewaying walkthrough report (10 min) 5. Next steps for WG (15 min) Remaining issues to resolve =========================== July 16, 2001. [Issue1] SRV format for identifier resolution ---------------------------------------------- See Christian Huitema's note, in http://www.imppwg.org/ml-archive/IMPP-WG/200105/msg00016.html As I understand it, there are 3 ways to go from here: . provide specific requirements to the DNS (dnsops? dnsext?) WG, and see waht they have to suggest (see Christian's note for a suggested list of requirements) . stop at asking for "where is the service for ", instead of "where is the IM service for for each of the protocols it supports". Requires "guessing" and "poking" to determine what services are supported. . focus on simply getting the info on the "preferred" IM service for a particular domain Which way do we want to go? Require action: [Issue2] What about FETCH? -------------------------- [No discussion since this was posted May 7] In Minneapolis, the room resolved that subscribe with 0 time does not unsubscribe. But, see Harald Alvestrand/Hiroyasu Sugano discussion of April 6, 9: http://www.imppwg.org/ml-archive/IMPP-WG/200104/msg00008.html "> So, among the two possible resolutions: > > - Zero duration SUBSCRIBE means fetch > - New operation FETCH, same arguments as SUBSCRIBE except duration > > we now have an argument in favour of FETCH. > > Query: If FETCH is separate, should the response/NOTIFY be carried in the > FETCH answer, or do we want to preserve the separate NOTIFY message? My preference is that presence info will be carried in the FETCH response because I expect that a FETCH request is to acquire the current presence info. I know there is a different opinion, though. > Query(2): If FETCH is separate, should SUBSRIBE(duration=0) mean UNSUBSCRIBE? As CPIM already has UNSUBSCRIBE operation, the duration value could be restricted to more than zero. In this case, I think zero duration SUBSCRIBE should be handled as an error. Or, we could discard UNSUBSCRIBE... ." Should we, then: . create FETCH with status in reply? . make 0-duration SUBSCRIBE an error? Resolution: Required action: [Issue3] Presence Subscription & privacy ----------------------------------------- As I understand the conclusion: SUBSCRIBE returns . success, or . operational failure (e.g., congestion) But "success" means that you have successfully subscribed to a PRESENTITY, not that you are guaranteed to get presence information (whether you do or not depends on the authXXX policies implemented by the server on behalf of the PRESENTITY). Resolution: "Yes" -- see 5.1.5 in RFC2779. And we need a "refused" message that may (or may not -- polite blocking) be used by servers. Required action: ensure this is clear in [CPIM] [Issue4] Where to define IM use of message/cpim? ------------------------------------------------ Proposal: Graham is the only respondant on this -- and suggests it belongs in CPIM. Resolution: [CPIM] Required action: update [CPIM] to reflect it. [Issue5] Presence XML DTD -------------------------- We have a proposed XML DTD for presence information, from Theodore Havinis: http://www.imppwg.org/ml-archive/IMPP-WG/200104/msg00011.html and we have (more recently) draft-sugano-cpim-pidf-00.txt which extends MSGFMT to encompass an XML presence object. Is the latter . acceptable . enough . ready to be incorporated (by value or by reference) in CPIM? (Since it seems to include the aspects of how to apply MSGFMT to the particular application of presence)? Resolution: Required action: [Issue6] How to carry Presence XML document ------------------------------------------- If draft-sugano-cpim-pidf-00.txt is acceptable, or at least people agree it is on the right path, this issue is answered & closed. Discussion: There has been some discussion on the list re. the signability of this, as XML is not a bitwise-static (binary) representation. What's wrong with XMLDSIG, or have I completely missed the point? Resolution: Required action: [Issue7] Gatewaying walkthrough -------------------------------- This isn't really an issue; we're waiting for our volunteers to report back: Jonathan Rosenberg, Vasilis Polychronidis, Sathya Narayanan. Any report? Resolution: Required action: Documents -- remaining work =========================== [CPIM] draft-ietf-impp-cpim ---------------------------- 1. Update text to reflect MSGFMT, security requirements for instant messaging: "2.3 Format of Instant Messages An INSTANT MESSAGE comprises a MIME Multipart/Related, Type=message/RFC822+XML object, as defined in XML/MIME[5]. Representation of non-ASCII character sets in MIME is a standard feature of MIME. Note that the IETF provides numerous technologies that allow end- users to exchange authenticated and private messages formatted as MIME objects, c.f., PGP-MIME[4] and S/MIME[6]." Format should be message/cpim, requirement for messaging security is: reception of multipart/signed for messaging, no requirement to send signed. 2. Loop detection Per resolution in Minneapolis, in 2.4.1, include hopcount as part of abstract parameters for messaging. 3. Identifier resolution, SRVs Update SRV record section. Waiting on: [Issue1] -- final resolution of SRV record format and address resolution. Additional note: example could illustrate that the targets may be outside the original domain (e.g., pointing to a gateway) 4. Clarification >From the mailing list: "Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)." What does it mean? Does it mean there is no "200 OK" to be expected? 5. To FETCH or not to FETCH Waiting on: [Issue2] 6. SUBSCRIBE SUCCESS clarification Waiting on: [Issue3] 7. Define particulars of IMPP's use of message/cpim for instant messaging Waiting on: [Issue4] 8. Define particular os IMPP's use of message/cpim for presence (if applicable) Waiting on: [Issue5], [Issue6] [DATETIME] draft-ietf-impp-datetime ------------------------------------ Done (in WG last call) [MSGFMT] draft-ietf-impp-msgfmt -------------------------------- 1. Administration Need to define the mechanism for defining new applications. It's probably as simple as: write an RFC that answers the questions in section 6. 2. Other todo Other todo's include those noted by editors ("[[[" "]]]" encased), including: "7. IANA CONSIDERATIONS [[[Registration template for message/cpim content type]]] [[[Registration of namespace URN for CPIM headers]]]" The latter is subject to status of IANA URN namespace.