Minutes IETF100: dispatch
minutes-100-dispatch-02

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)