IETF 90 -- Toronto, Canada Minutes of the APPSAWG Meeting July 21, 2014 -- 09:00, Ontario room Called to order at 09:00. Blue sheets were circulated. Minute taker and Jabber scribe volunteers selected. APPSAWG MEETING =============== Administrivia Salvatore Loreto will be relinquishing his co-chair hat after this meeting. Alexey Melnikov returns to the co-chair role. Barry Leiba (Applications Area Director) points out to the audience that we are keen to give less experienced IETF attendees a shot at positions such as these, so if anyone is interested exploring such opportunities, please contact him. Murray Kucherawy (co-chair) presented a summary of work accomplished since IETF 89, which includes four published RFCs, one in the RFC Editor queue, three in AD/IESG evaluation, three documents in progress, and three that are potentially going to be adopted by the working group. == draft-ietf-appsawg-uri-scheme-reg Dave Thaler gave a current status update on draft-ietf-appsawg-uri-scheme-reg, and discussed open issues. There have been a couple of versions posted since last meeting. There are a few open issues, including one waiting for W3C feedback. Open questions: 1) What to do when a domain name changes hands? Suggest: Do nothing; collisions are possible between old domain owner and new owner, which provides some incentive to do provisional registrations; trust that people have good will and will do the right thing. 2) RFC 4395 discrepancies regarding how to handle provisional scheme name registrations that have the same name; one says IANA always rejects, the other says the IESG has to decide. a) How do we resolve this? b) Does this only apply to provisional requests, or also to permanent and historic? c) Does the existing entry also have to be provisional? d) Who is the approver? Suggest: IANA sends to IESG before rejecting. Dave Crocker is interested in having less work for the IESG. Tony Hansen suggest delegating this to a designated expert; that's what they're for. Barry points out that few members of the IESG have much to say on such things when they come to the IESG. John Klensin suggests that it be pointed out that the IESG could appoint an alternative Designated Expert when things like a conflict of interest are a concern. Murray asks Barry if alternative Designated Experts are common. Barry points out that IANA likes this practice. Tony says RFC5226bis has text about a Designated Expert recusing herself when doing so is appropriate. Eric Burger asks if we need all these permutations written down, since the IESG can always jump in. 3) A returning question, which needs W3C feedback: a) What to do when defining a set of schemes that are of the form "prefix+suffix" (e.g., coap+sms). If we have a set of permanent schemes in the IETF and someone else wants to register a name inside that scheme, should there be a conflict approval process? Do we need a registry of prefixes, or a special token that triggers such a process? Are we OK with the current consensus? Suggest: Keep consensus (i.e., not concerned with such conflicts). b) Private use scheme names. How do I track down the owner? Suggest: If you're not using your domain name in the scheme name, you should register at least one so that encountering a similar one leaves a starting place for finding the owner. Eric Burger was going to write a draft for application/deep-links; didn't make the cutoff. Is there interest in him pursuing this? The idea is a single app-launch type scheme with thousands of apps instead of thousands of proprietary schemes. Dave Thaler suspects people would be interested in that, but not for some time (a few years). Joe Hildebrand asks: How come these weren't ms-xbl://guid-whatever instead? Dave Thaler says the systems interested in these things only deal with schemes right now. You could also register a media type and launch via media type, but that's just what these systems do right now. == draft-seantek-text-markdown-media-type Sean Leonard introduced this draft as a potential working group item. Markdown is a very lightweight markup language, somewhere between plain text and fully specified markup languages (e.g., HTML), commonly used by people in applications such as Wikimedia. The intent is to register a new media type that refers to content in this format. There is a basic syntax set, but an inconsistent set of extensions. This format is not governed by any standards body. Some examples were presented. We have some syntax variations or clarifications to discuss that have been brought up on apps-discuss and in the markdown community. There's also discussion about the idea of creating registries with designated experts for the variants of markdown. The intent is to have the normative specification of the syntax be what's on a web page. There's some question about whether this can be referenced from an RFC. Dave Crocker suggests that this needs to go through a standards process, though it's unclear what the right venue is. Joe Hildebrand supports processing it through APPSAWG, especially if some of the nuances are removed. Paul Hoffman concurs, and points out that there's no indication that the markdown community wants us tinkering with their format. Sean also concurs. The co-chairs will send a Call For Adoption to the list. == draft-nottingham-safe-hint Mark Nottingham presented this draft, which proposes a simple flag that allows an HTTP client to request whatever the server considers to be the "safe" version of its content. The advantage is that it obviates the need for one to visit numerous sites and request "safe" mode from each of them individually, relying on cookies. The definition of "safe" is deliberately unspecified, and intentionally Boolean. Some popular browsers already include support for this proposal. There was some discussion on the list already regarding proposed enhancements and serious reservations to taking on this work in APPSAWG (or at all). Doug Leonard supports the simplicity of the proposal. John Levine says it's refreshingly quaint to standardize something simple and already in use, and server have an interest in honoring it. Sean Leonard says this is not the first time we've had a proposal like this and past work has seen no server side adoption. Mark described differences, which mainly had to do with content labeling needing a very rich vocabulary, which in turn didn't scale. Joe Hall is concerned that this might label a client as "Hey, I'm a kid!" Mark countered that this needs to be explicitly defined in a way that makes it clear that's not the intent; connecting this flag to COPPA would be a bad thing. This is a good argument for keeping it as a single bit. The co-chairs will send a Call For Adoption to the list. == draft-nottingham-http-problem Mark Nottingham presented this draft, which is a description for reporting problem details in HTTP machine-to-machine interactions. The status code is often not sufficient to diagnose the problem. Most APIs roll their own error format and have to deal with many trials in doing so. This proposal standardizes the way of doing so using JSON. There is one implementation in Javascript, and several other expressions of interest. Of note: There is a standards tree media type registration involved. The co-chairs will send a Call For Adoption to the list. == draft-nottingham-json-home Mark Nottingham presented this draft, which covers "home" documents for HTTP APIs and encourages effective use of linking. The data model used is JSON. Can also be used as a role-based access control mechanism. The draft has been around long enough that it's probably time to advance it. Currently in use at Rackspace. Martin Thomson says this and the previous document are extremely useful, though specifying a format in each case may be problematic. He would prefer to see such things presented as "Here's a good way to do it", not "Here's the only way to do it." Mark agrees. Mike Jones points out that WebFinger ended not long ago. It's always puzzled him why, rather than having a new format, this couldn't be cast as resource definitions that could be discovered with WebFinger. Mark replied that the two have some overlap; this could be revisited. No current action for APPSAWG, but it's related to the previous topic and so was presented for information only at this time. == JSON Patch Redux Mark Nottingham points out that JSON patch and JSON pointer have received a lot of feedback about things that are missing. Mark is collecting suggestions for a revision to JSON patch in the not-too-distant future. No current action for APPSAWG. == draft-hansen-mdn-3798bis Alexey presented this draft, which is a revision to Message Disposition Notifications. The existing document needs some fixing and has some open ABNF and whitespace insertion issues that need to be resolved. Feedback from implementers would be very welcome for this work, specifically about strictness of generators. The co-chairs will send a Call For Adoption to the list. Applications Area General Meeting ================================= Each of the applications area working groups presented a brief summary of what it works on and current status. Four new working groups were formed since the London meeting, and were briefly introduced: - ACE (Authentication and Authorization for Constrained Environments) - DART (DiffServ Applied to Real-time Transports) - TAPS (Transport Services) - TCPINC (TCP Increased Security) Six Birds of a Feather sessions are being held this meeting: - DTNWG (Delay Tolerant Networking Working Group) - ACTN (Abstraction and Control of Transport Networks) - IANAPLAN (IANA Plan) - VNFPOOL (Virtual Network Function Pool) - UCAN (Use Cases for Autonomic Networking) - RFCFORM (RFC Format) == Transport Protocol Evolution Joe Hildebrand discussed the evolution of application transport protocols beyond TCP, for applications that need only some of the services provided by TCP. The work of the TAPS and HOMENET WGs are relevant here, as is the ability to provide hints about content between the application and network layers. Mostly, people just fall back to port 443. Can we do better? If there's anyone in the APPS community that's interested in this, an IAB program called "IP Stack Evolution" is being started, and is looking for interested participants. Contact Joe or Brian Trammell. == Privacy in Email Dave Crocker gave a presentation on the evolution of email in this new era of high privacy sensitivity and the enormous amount of current activity. TLS by itself doesn't solve the problem, because it solves only one hop and email uses multiple hops. We need to focus on end-to-end object security. The stuff we have doesn't to do so seem to be working. What, if anything, should the IETF be doing now or in the future? This session will be repeated in SAAG with a focus on gap analysis. == TPA Labels [audio for this presentation was not included in the archive] Doug Otis gave a proposal for a way to express policy via the DNS to describe domain-level relationships with respect to email authentication. Meeting adjourned at 11:30.