DISPATCH WG Agenda IETF 100 — Singapore November 13, 2017 09:30 (9:30-11:00 am) Minute Takers: - Thank you to Magnus for Minutes. Jabber Scribe: Pete Resnick Summaries: ========== - Zstd Compression (Murray Kucherawy). Conclusion: Alexey agreed to AD sponsor. - IM with S/Mime (Ben Campbell). There was general support/interest in the WG. Either AD sponsored or mini-WG to be considered for progression. Actions: Authors to post a problem statement, scope, etc for consideration by the WG. - IDNA-Related Issues (John Klensin) There was a lot of discussion with no clear conclusion. However, it was proposed that the 3 documents should be further discussed on that ART area list. The ADs are to consider the best way forward. Discussion: ============= == Notes from Magnus Westerlund == Noting the Note Well. Providing the deadlines for next meeting (IETF #101) Dispatch Meeting Zstd Compression ------------------------ Murray Kuckerawy presenting the intention with draft-kucherawy-dispatch-zstd. Marting Thomson: Content-Type don't know if there is a strong motivation for this. Harald Alvestrand: What is it useful for? The same thing that gzip and roth. Zstd used with Linux kernel. Better performance than GZIP What is the IPR situation? In compliance with BCP 79. Alexey: Content-Transfer encoding registration. It is very hard to add these unless very special cases. Martin Thomson: Don't worry about transfer-encoding. They will not deploy. Alexey: Considering to AD sponsor this document. ART AD Report -------------- ART Directorate has been tried out, but there are not yet that many on it. Have been useful. Asking for volunteers. New WG: DNS over HTTP (DOH) and  EXTRA IM with S/MIME ---------------------- Ben Campbell presenting. Mary: Noting that we done mini WGs also for fairly small issues, and a WG would attract more attention from the security people. Sean Leonard: In general this should move forward. In the context of IETF messaging it should specify which version of S/MIME it uses, probably 4. Martin Thomson: Is this for point to point. Or is multi-party also? Ben do you mean multiparty with exploder. Martin group keying is a challenging if you want to prevent the exploder from reading the message. Jon Peterson, why using S/MIME. There has been multiple previous attempts. Why implement S/MIME in SIP messaging Ben: There are already S/MIME in a lot of related context. Thus, code exist and S/MIME likely require less new code in clients. Christer Holmberg: In CPIM, the headers can't be encrypted as they are used in Store and Forward cases. Can the solution be used peer to peer? Ben: There are no technical reasons. But likely practically reasons with key-management. The draft doesn't tackle this problem at all. Andrew Allen: Two years ago there where hardly no support for S/MIME at SIPIT. Ben: There are enough interested parties that it worth doing, even if there are solutions for other groups. Martin Dolly: The US wireless community is requesting this. Chairs: Who thinks it is a problem worth solving? A number of hands (approximate ?) Martin: When you ask that question you asking who wants a unicorn. The right question are there enough push behind this to get this done? Stephen Farrell: What implementation does exist in this context? Ben there are email implementations. If they are suitable doesn't know. Jon Peterson: Not that interested if this is only S/MIME. If we are doing work on secure messaging, that would be more interesting as S/MIME may not be the right solution. Jim Fenton: The problem of getting secure message to the users do exist. However, If we are doing secure messaging we should take a step back to figure out the best way. One problem is the lack of confirmation of reception. Jon Peterson: If the Cert management does come in again. That would be more interesting and I likely engage. Christer Holmberg: It is very useful to clarify the protocol. As S/MIME is an allowed in the SIP messaging RFC if there a question it should Sean Leonard: ? Chairs: Who are willing to work with Ben on S/MIME: 4 persons. More interest in the general topic of secure messaging. Looking at Internationalization .. Again ---------------------------------------------- John Klensin presenting. Pete Resnick: Leaving the problem to some else. Has normally not worked. Is there a possibility to do joint work with Unicode Consortium so that both comes to consensus. IETF has to little expertise to be really productivity and no forcing function. Leslie Daigle: Don't see a way of getting Unicode consortium to do things.  Still need John there are two different territory, and we would be crazy to take on theirs. However, there has been some Barry Leiba: We need guidance for protocol developers what they need to think about on internationalization. Yoshiro Yoneya: Encourage to work with other SDOs on this. Andrew Sullivan: Discussion hasn't gone into the buckets in John's slides. Don't know if trying harder on collaborating will work. The problem, is that this is user interface problem. We usually don't think we have those problem. User interface people would laugh if we asked for a general cook book for these problems. Ted Hardie: IRIs was the presentation format, that had a mapping to URIs (Identifier). That didn't work. Part of the problem is that Unicode Consortium, assumes that you have a local context, that you know the script and local language. This we don't normally have that context. If we are going tackle this problem space, we really need to think about what we are going to change to make this work. Pete Resnick: Not suggesting that try to work hard on getting together. The problem, is that we try to do this very formally, with something like liaison statement. But there are personalities involved. We need to engage more directly, and work in the both sides organization according to each rules. Leslie: We are not ready. We don't yet know what we want to do. We should remove Unicode Consortium from the table and take a step back what we really need to do on architecture. What do we need to change to accommodate the needs that exist. Joe Hildebrand: We have lets constraints block some some possibilities such as backwards compatibility. ...  There is one way that would be horrible in the near term, but may be better in 20 years. John Klensin: A special review team is for dealing with the patching issues, not working on grand architecture. In response to Joe there are backwards compatibilities that have to be handled somehow as this is part what caused the problems. Joe Hildebrand: That we don't necessarily constrain the solution space, based on historical issues with personalities. Pete Resnick: A concern that if we start go down the path without Unicode Consortium people involvement. We need to figure out how to Chairs: Where do we take this discussion? Barry: The drafts should be discussed in ART list. The long term discussion is likely not suitable on ART list. WG is also likely to contain quite some overhead. Adam (as AD): Drafts on ART list is reasonable. For the long term things, we ADs like to think more about next step. Leslie: An IAB workshop would be a possibility. ===================================== Notes by John Levine (from ether pad) ===================================== IETF 100 DISPATCH rough notes 09:30-09:35 Administrivia (chairs) Deadlines for IETF 101 DISPATCH
 09:35-09:40 Zstd Compression (Murray Kucherawy) Murray presented the draft M Thompson: why does this need a media type? Harald: what is it useful for, what IPR? used in linux kernel, text compression, better than gzip Alexey: is this a content transfer encoding? they're harder to add than media types MT: nobody will implement a new CTE Harald: I'll take it ARTAREA 09:40-09:45 Update from Area Directors (ADs) Alexey, Adam presented 09:45-09:50 BoFs and New Working Groups This Week (open) four BOFs 09:50-10:05 SIP and MSRP with S/Mime (Ben Campbell) Ben: presented slides Sean Leonard: seems OK MT: use case? mostly point to point, could be multiparty MT: secure sending to many people is hard. Ben: yes what about cert management? Ben: we're waving hands Jon Peterson: S/MIME hasn't been very successful, STIR seems more successful Ben: many clients can handle S/MIME already Christer Holmberg: does this include direct peer-perr comms? Ben: technically it could work, cert management is hard Andrew Allen: Why S/MIME Ben M Dolly: US wireless carriers want this Chairs: Is this a problem worth solving? yes MT: does this have enough momentum to be worth doing? maybe Stephen Farrell: is "this" S/MIME or the whole thing? Implemented? Ben: implemented in mail at least JP: might as well, not clear it's the right approach Ben: I think this is S/MIME in MSRP, not general secure messaging Jim Fenton: using mail is a bad solution but widely used, we should look more broadly e.g., might want to know that a message was delivered JP: cert management is interesting CH: people want to use this, clarify what it's good for SL: leaving out cert management is correct here. Chairs: four people willing to work on this draft Ben: agree that problem statement could be better 10:05-10:35 IDNA-Related Issues (John Klensin) JK presented slides Pete Resnick: can we figure out how to do joint work with Unicode consortium, require consensus on both sides? We don't have time and expertise. Leslie Daigle: Unicode has different priorities than we do, e.g., don't change the tables. Makes joint work improbable. We need something high enough profile that the whole IETF pays attention. JK: important area of non-overlap between IETF and Unicode, e.g. they can code characters, we can do protocols. Barry Leiba: Unicode's goal is to reproduce documnets, ours is stable labels, IDNA2008 hasn't worked well. Non-experts still don't understand issues, e.g. "it's UTF-8" isn't enough. Yoshiro Yoneya: mixed user feedback Andrew Sullivan: need to understand what Unicode is doing, not just documents really a user interface problem, which we're not good at. Ted Hardie: we tried to do IRRs with presentation format and transform to/from URIs, didn't work, IRIs were used directly has talked to Unicode, they understand some problems, they assume context we don't have, e.g., what language. They think we should add the context, we have places where it's impractical, e.g. DNS root. What are we willing to change? PR: not suggesting that we join harder with Unicode, interactions have been formal, often not well received from one side to the other. Need Unicode people here and v/v. LD: We're not ready for that. We don't yet know what we want. Joe Hildebrand: haven't listened to Unicode's feedback. JK: agree we context issues, some Unicode people have been in these discussions in the past. Don't try boiling the ocean before addressing concrete problems. We have symmetrical problems re assumptions. JH: don't constrain technical design space by historical personality issues. JK: we've listened, sometimes helped sometimes not PR: it we work on problsm space with Unicode participation it won't work, both sides need to understand at least what issues are JK: we have people depending on drsfts BL and other ADs: can deal with drafts here, ART not so good for broader issues, too many people who don't understand issues, but powwow of experts looks closed. Adam: scratching our heads, will let you know LD: IAB workshop? It is architecture MT: IAB is looking at ways to find a piece we can constructively work on BL: just was an IAB naming workshop 10:35-11:00 Open Microphone/AOB (open)