IMPP WG Notes 2002-07-18 54th IETF, Yokohama MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Agenda no items added IMPP Status - The datetime draft has gone to auth48 - MSGFormat is in WG last call PIDF update By Hiroyasu Sugano The current draft is 05, and is deemed sufficiently stable. The suggestions made in Minneapolis have been integrated, including the agreed minimalist approach. - Defines new media type for application/cpim-pidf+xml and new XML namespace urn:ietf:params:xml:ns:cpim-pidf. - XML namespace is for both status value extensions and other tag extensions. - XML Schema replaced use of DTD - Recommendations from RFC3023, IETF XML guideline and other sources have been followed. - Only two presence states defined: open (available) and closed (unavailable). Other states like busy or away must be defined by developers or applications using PIDF. Comments at the microphone: Jonathan Rosenberg suggested adding a reference to the actual schema. Graham Klyne pointed out the datetime draft has a couple of edits to handle case sensitivity issues. These edits should be compatible with XML schema as well. Conclusion: PIDF is ready for last call. No objections were raised. CPIM Mark Day Goal of today: CPIM needs a specific list of issues in order to mature CPIM to the same level as PIDF and bring it to last call. Is the proposal adequate? What needs to change? Deadlines must be established. Are there people with substantial concerns about CPIM? No issues were raised at the microphone (beyond the known item next on the agenda, that of authenticated notifications and subscriptions) Jon Peterson volunteered to create the next CPIM draft by next Friday. Authenticated notifications and subscriptions Mark Day The IMPP charter still says that IMPP is supposed to solve all problems in instant messaging and presence. For a while, the chairs have been operating under the de facto charter of delivering message-format, CPIM and PIDF. Should the WG be officially limited to this workload? Should the workload be extended, given that the charter theoretically allows it? Jonathan Rosenberg opposed taking on this work item. The minimalist approach has been working and allowed us to make progress. This is not a trivial work item. Security isn’t unimportant, but it’s very hard to solve without the context of the actual protocol. I don’t think we should define a subscription format, nor do I think we should expand the scope of the existing work. I think that would mostly amount to choosing S-MIME, I don’t know if it’s more than that. Derek Atkins explained that there would need to be a line in the notification that has the name of the presence server which is the author of the notification. This is the only change required. Mark Day asked whether we need a way to identify the server, as well as the presentity. Currently only the presentity can be identified. In hop-by-hop mode, don’t you care about the server before you? Jonathan: We’re all about doing end-to-end, which specifically ignores the hops. Subscriptions are generated by end users, and in many cases end-users will not have public keys. Authenticating them to the destination server across boundaries is a very hard problem. Simple has been grappling with transitive models and other models. I don’t think it’s worthwhile to pursue supporting authenticated subscriptions. It doesn’t make sense to delay completing a group for something that can’t be deployed well. Sean Olsen seconded Jonathan’s statements. Neither subscription nor notification should be tackled at all. These are not problems that can be tackled easily or within a reasonable time-frame. Graham Klyne: Why is the server generating a notification not covered in the signature? Derek: Currently we have the from and the signature is supposed to match. However, it’s not clear *what* the signature is to be matched to. Jon Peterson: This issue is part of the work items that I’ve just taken on, in editing CPIM. I think the work item covers what we need. Sean Olsen: You do mean service, and not server? A signature of a service is very different from a signature of a server. Zmolek said that none of the issues 6, 7 or 8 from http://impp.fujitsulabs.com/ml-archive/IMPP-WG/200206/msg00012.html should be taken on. Jon Peterson: I have no objection to trying to tackle these problems, after we do the work we are currently doing. These are interesting problems but difficult. Graham Klyne: If the scope is to be expanded, I think there needs to be a fairly compelling case to do so. Zmolek: I’d also be supportive of such an effort, but not here and now. Derek I agree getting CPIM out the door is important, but a simple wrapper for presence information to identify the presence service is a one line change. (#7 from above referenced msg) Jon Peterson: What value does that service identifier add, assuming we’re not doing signed subscription requests? Rohan Mahy and Graham Klyne: Let’s get proposed text, and discuss it on the list. Jonathan Rosenberg: What does it mean to have a wrapper? It’s only a XML document. By wrapper for service identification, how is this different from the signature identified in the certificate associated with the notification? Mark Day proposed taking the resolution of this service identification issue to the list. Derek will send mail to John ASAP. If there’s still silence on the matter within a week, we can probably not worry about it at least as far as the next draft revision goes. Derek Atkins asked for new discussion. After we get CPIM out the door, should IMPP as a WG accept the work item of doing signed subscriptions and notifications? Jonathan Rosenberg suggested that the WG answer that question later to see how other things shape up. There might be other things that people want to do, and deployment might contribute unforeseen work items.