Minutes for APPSAWG at IETF-88
minutes-88-appsawg-1

IETF 88 -- Vancouver, CA
Minutes of the APPSAWG and APPAREA joint meeting
09:00-11:30, Georgia B

Murray Kucherawy and Salvatore Loreto, co-chairs
Mark Nottingham scribing
John Levine taking minutes

- Called To Order -

1) Administrivia

Blue sheets, note well, jabber room, agenda bashing, etc.

- APPSAWG Section -

2) Document status update

Two documents have been published: Webfinger (RFCxxxx) and
Authentication-Results (RFC7001).

Two documents (xml-mediatypes and json-merge-patch) have cleared WGLC, but
received almost no reviews, so they are in limbo until we can get clear
consensus that they're ready to go.

The malformed-mail draft has cleared IETF LC.  There are two directorate
reviews that need to be addressed and then it can go to IESG Evaluation.

Four documents are still in WG development: multipart-form-data,
rrvs-header-field, sieve-duplicate, and uri-get-off-my-lawn.

3) Mini-charters experiment

We have had a few documents where the authors go dormant for protracted
periods.  We have had complaints that we have too many live documents which
makes it hard for participants to follow relevant discussions.  We have also
observed that occasionally discussion of a document can run out of scope, and
sometimes we can't muster enough reviewers to justify sending a document to the
IESG.

We are considering the idea of having a "mini-charter" when work is brought to
the WG.  This is not meant to be as heavyweight as a full chartering process,
but rather to establish an understanding between the chairs and authors about
who will drive the work, who will be doing reviews and providing comments,
limit scope of discussion, appropriate early reviews and liaisons, etc., before
the document becomes a WG item.  This would be recorded in the WG wiki.

Mark Nottingham expressed enthusiastic support.  There was no other recorded
response.  The WG chairs will try this as an experiment.

4) RRVS Header Field draft

The original mechanism for doing the work described in this draft was to add
and check for a header field.  The impetus for using this mechanism is the
reality that in the wild, adding an checking for header fields is far simpler
to deploy than an SMTP extension, even though the latter is the architecturally
superior approach.  At the same time, the MT-Priority extension published
earlier is an SMTP extension with support for a header field to "tunnel" the
request through non-participating servers; Alexey (the author of that work)
concurs that it's easier in things like Outlook to do header fields versus
extensions.  Barry Leiba agrees that it's easier, but it's still to be avoided;
do the extension and, if you hit a server that doesn't participate, you have to
bail.

Dave Crocker asks if that means MIME should be an extension; Barry says MIME is
a format, not a protocol.

Keith Moore says SMTP extensions are to be used for transport, while content
meta-data goes in header fields or MIME structure, because messages have a life
of their own after transport is complete, and transport-specific context should
not be included when the message is forwarded.  Also, email encryption should
be mandatory for all hops, and if we have to negotiate it on a hop-by-hop
basis, it won't get adopted.  We should be moving toward encryption.

John Levine: Theologically, this should be done as an extension.  However,
given the motivation for this work, I don't see much point in inventing an
extension if almost nobody is going to implement it.  I would be interested in
hearing from large mail providers what they are implementing or plan to
implement.  We may just need to codify existing practice, which so far is just
the header field.

Derek Atkins: It would be really nice to be able to do OTR for email.

The authors will figure out where to go from here.

5) multipart/form-data history and status

[Larry Masinter's slides]

Larry requests more participation, and also comments on using github for source
control and change management.

Keith Moore applauds the effort, but has concerns about writing a Standards
Track document to capture reality, rather than say what reality should be. 
Larry agrees in general, but has been sympathetic to some of the choices that
have been made in the document.  Keith says we should really believe the choice
made is the right thing to do before allowing the work to advance.

John Klensin supports Keith, and also has concerns about non-ASCII header field
names.

Mark Nottingham asks if this work has been discussed with any W3C teams or
working groups.  Larry has discussed it with many individuals but doesn't know
what their roles are.  Mark suggests looping in the W3C liaison.

Keith Moore RFC2047 is completely inappropriate for representing strings in
general, and I object to their use in this work.  Larry notes that the document
currently asks receivers to be liberal in what they expect, but does make it
clear what the preference is.  Keith remains concerned with interoperability.

John Klensin reiterates that some of the above issues are the ones he had in
mind with his comment above.

Larry points out (again) that this document isn't done yet.  Keith indicates
that he thinks this is worthwhile work, but these issues require attention. 
Larry solicits the WG for help, or even a co-author.  Mark will provide liaison
services with the W3C in support of this work.  Dave Thaler volunteered to
develop and run test cases.

6) URI structure

[Mark Nottingham's slides]

Ted Hardie thinks this is good work.  Given recent work by Dave Thaler as well
as RFC4395bis, he believes there needs to be a scope expansion here, that
includes scheme registration material and other advice about minting URI
schemes so that people do things that fit the syntax.  This would be a good use
of mini-charters; such a thing would involve taking all of these documents as
input and covers the ground of all three.  Given the scope creep, he volunteers
to work on the result.  Mark is concerned with the added risk; this is already
a tightly scoped piece of work and an easy win.  Also, this draft currently
references the W3C Web Architecture document.  There was discussion between
them about the costs and benefits of Ted's suggestion.

Eliot Lear agrees with Ted in that we don't have a good traffic record on "do
not" documents.  It's much better to have a specific alternative to propose. 
Apart from that it reads pretty well.  The "who this document is for" section
seems too bureaucratic; Eliot will provide text.  Also, the use of
"applications" probably means "application specifications" throughout. 
Finally, the document appears to proscribe the use of future schemas; was that
intentional?  Mark will clarify on all of these points.  Eliot asks if this
advice has been tested for URI schemes other than http.  Back on the point of
including good advice is very hard to get right in a BCP-level document.

Tim Bray observes that if this document had existed already, he'd have been
able to use it regularly over the last five years; it will be equally useful
when it appears.  My instinct is to say "just do it", and if there's further
additional scope to be covered, it can reference this.  We should publish this
as soon as possible.

John Klensin agrees, noting that we understand this very well for HTTP but
possibly not for other schemes is a really bad idea.  Mark thinks this is not a
strong concern since there has been thought given to this issue already, but we
should do due diligence and make sure before proceeding.  John points out that
the URN WG has been stuck sometimes in this problem space.  Possibly an
applicability statement alongside this might be useful indicating which things
have been tested, and which spaces are still reasonably described as unknown.

7) URI scheme registration process

[Dave Thaler's slides]

Keith Moore hopes we can make the process faster and more lightweight, given
the evidence presented here.  Perhaps the process could be more visible, e.g.,
review process state change notices.  He also thinks the URI syntax is
over-constrained as currently documented; it was possibly HTTP-centric when
designed.

Mark Nottingham is glad these questions are being asked.  The HTTP header field
registry and link relations registry have the same problems.  The happiana
group had some of the same ideas, but it lost momentum.  He wonders whether
APPSAWG or some other WG should do some IANA registry cleanup work.  He wonders
if there are other solutions; we have a proliferation of URI schemes that
belong to only a single application.  Perhaps we need a master scheme with
sub-options for "app launch" or something like that.

Alex Mayerhofer suggests that maybe the IETF is too stringent on what we allow,
and people don't always get what they want or expect out of the process.

Larry Masinter points out that these days, with a registered protocol handler
and the idea of modular handlers, the registry may be outdated.  HTML 5.1 has
registered content handlers as well.  This is more a symptom of how
applications get deployed rather than laziness on the part of people that don't
want to register their schemes.

Brian Dickson asked how many different types of structures were found out of
the 75 surveyed?  Dave replied that in some cases this wasn't obvious; probably
a handful.  Brian suggests that a validation front-end for new submissions
would work, where not only the name is checked but also parts of the
submission.  Things that are out-of-the-ordinary could be subjected to full
review, others could be fast-tracked.

Tony Hansen asked if Michelle Cotton [IANA] has been consulted about any of our
options.  Michelle says IANA simply follows the rules put in place in the RFCs.
 Expert review is responsible for the "delay period".  We could make the
registries first-come-first-served with a syntax checker; it merely needs to be
specified.  She is willing to work with happiana again if that would be helpful.

John Klensin doesn't think we should look at this as an opportunity to look at
all registries.  He suggests creative thinking.  We might instead find ways to
contribute to the Wikipedia registry, for example.

Phillip Hallam-Baker advocates for having a single point of registration for
SRV, well-known, and a URI scheme.  It would be nice if all three were in sync
for a single app.  However, existing products may not respond if something is
registered under an existing scheme.  We should also make it possible to use
opaque URIs (e.g., PGP fingerprints); this would allow things like launching
apps that are signed under a particular key.

- APPAREA General Meeting -

1) New WGs

Ralph Droms presented for DNSSD.
Ulrich Herberg presented for 6LO.
Jon Peterson presented for STIR.

2) BoFs

Heather Flanagan presented about RFCFORM.
Sean Turner presented about PERPASS.
Scott Hollenbeck presented about EPPEXT.

3) HOMENET

Pete Resnick asked the meeting for guidance about how to get Applications Area
attention on work earlier.  HOMENET, for example, exists in APP space, but its
first document drew a large number of DISCUSSes.  It's clear that it has no APP
attention so far despite earlier requests for same.

Dave Crocker mentions this is not the first time this issue has come up. 
Previous attempts have involved requests to us from other WGs, and we have been
really incompetent at providing it.  This is entirely our fault.  Pete concurs;
the HOMENET people did a reasonable job given the information they had (which
was none).  Dave says we need a discussion in APP about how to advise lower
layers; as a group, we don't have a clue how to give advice.

John Klensin mostly agrees with Dave, but suggests there's another dynamic
going on here: Sometimes WGs in other layers come along and ask for APPs clue,
and we provide it, but sometimes we're told "We have vendors in the room, we
know what we're doing, please go away."  There's a tension here, and he
believes this part of it is an IESG issue.  Pete says we need to be told when
they come up so the IESG can intervene.

Keith Moore says the people interested in doing APP things are not always the
same as the people who want to review the work of other WGs.  We might do well
to identify which people are in which groups.  Pete points out that this is not
about review, but about consultation.  Keith doesn't think we should not single
out HOMENET; this is a long-standing problem.  We need to change this.

Eliot Lear wonders if Pete applied his proposed consensus criteria to this
particular case.  Pete didn't observe the problem until it was before the IESG.

Sean Turner points out that the Security ADs regularly deploy SECDIR people to
working groups, and they often get ignored.  All they can do is report back. 
When that happens, advise your AD so they can get involved.

Joe Hildebrand says he runs into this when mentoring junior engineers within
his own organization.  When asked to intervene in the dispute, he declines but
rather advises the engineer to learn to be persuasive and helps with that. 
This takes patience with both parties.

Pete suggests empowering APPs people who go to other WGs by being explicitly
supportive of such people, and helping them present their points in persuasive
ways.  We can perhaps use the Applications Area Directorate for this purpose.

4) Applications Area Security

XMPP: [Peter Saint-Andre slides]

Roen Mae[?] regarding multi-tenant environments: One option is extended client
hello, which gives a server an opportunity to decide which certificate to hand
back.  Peter says we have that capability in XMPP, but hosting providers don't
always have (or want to have) the private keys for the domains they host.

Dave Crocker confirmed that there will still be cleartext in the servers.  He
also expressed concern about having a flag day; Peter feels this is less of a
concern for a smaller network like XMPP (versus, say, email) but they want to
do something drastic, and they can pull back if they find they need to.

Phillip Hallam-Baker points out that XMPP doesn't have a way to say "connect
securely, or not at all" and this would be a useful addition.

Matt Miller supports the comment that we have to start somewhere, so a flag day
is our path forward.

Email use of TLS: [John Levine slides]

Email use of crypto: [Alexey Melnikov slides]

Requiring email encryption: [Keith Moore slides]

SIP security status: [Jon Peterson slide]

HTTP security: [Mark Nottingham slides]

Discussion about how to organize the work:

Stephen Farrell says the work should go ahead.  He's not sure if SIP is in the
same state as all the others, but otherwise strongly advises us to get started
and not wait for a BoF in March.  Paul Hoffman concurs.

Keith Moore would like to see all related work to be appropriately clustered
into dedicated working groups.

Dave Crocker can't imagine doing all of this in one WG would do very well.  TLS
does lots of different things, each appropriate for different concerns, and
it's not clear we understand for which problems we want to apply TLS.  We could
deploy it everywhere and not solve the right problems.  What we ought to have
is a common statement of the threats we want to address.

Phillip Hallam-Baker notes that the Government of Brazil is holding meetings to
create an organization to secure the Internet.  He likes Keith's idea of a
draft that sets the bar for a particular protocol.  We should do this for other
major protocols.

Franck Martin agrees with Dave; we have been doing opportunistic TLS for email,
but it's not obvious why.  For things like DKIM, do we need to revisit which
keys and what key sizes are being used?  For Authentication-Results, why can't
we also indicate the results of TLS processing?

Joe Hildebrand believes there are several patterns that applications follow, so
having guidance for new protocols developed in the future based on what we've
seen in these patterns would be very useful.  It doesn't seem necessary to have
a dedicated effort around each protocol given the similarities between some of
them.

Stephen Farrell reiterates that there are lots of people willing to do stuff,
and we should let them do that.

Tony Hansen agrees with the notion that STARTTLS isn't sufficient, and we
should use the TLS port for them instead.  He wonders if STARTTLS was a bad
experiment, and maybe we should recommend the TLS port for all protocols. 
Keith Moore points out that the model has changed in the last 20 years or so. 
Joe Hildebrand points out that we don't have a plain text option in some cases.

- Adjourned -