Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange
Julian Reschke <julian.reschke@gmx.de> Thu, 12 August 2010 08:38 UTC
Return-Path: <w3c-dist-auth-request@listhub.w3.org>
X-Original-To: ietfarch-webdav-archive@core3.amsl.com
Delivered-To: ietfarch-webdav-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AF528C0F6 for <ietfarch-webdav-archive@core3.amsl.com>; Thu, 12 Aug 2010 01:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.915
X-Spam-Level:
X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=2.084, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DowJwxaMbAj6 for <ietfarch-webdav-archive@core3.amsl.com>; Thu, 12 Aug 2010 01:38:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 948183A696B for <webdav-archive@lists.ietf.org>; Thu, 12 Aug 2010 01:38:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <w3c-dist-auth-request@listhub.w3.org>) id 1OjTIF-0006tG-O1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 12 Aug 2010 08:37:43 +0000
Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1OjTIE-0006rG-Q1 for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2010 08:37:42 +0000
Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1OjTIC-0001va-NA for w3c-dist-auth@w3.org; Thu, 12 Aug 2010 08:37:42 +0000
Received: (qmail invoked by alias); 12 Aug 2010 08:37:07 -0000
Received: from p508FE608.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.230.8] by mail.gmx.net (mp013) with SMTP; 12 Aug 2010 10:37:07 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18jGnYFbvQjoiMUD9ZxgDC0RIBVoJ8MZlxRMPrltU oZ8hNYp0eDlIFx
Message-ID: <4C63B2AB.6090701@gmx.de>
Date: Thu, 12 Aug 2010 10:36:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: WebDAV <w3c-dist-auth@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001
X-W3C-Scan-Sig: bart.w3.org 1OjTIC-0001va-NA 0d993aaf03ce9de447b2bbcd336bed42
X-Original-To: w3c-dist-auth@w3.org
Subject: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange
Archived-At: <http://www.w3.org/mid/4C63B2AB.6090701@gmx.de>
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/13293
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1OjTIF-0006tG-O1@frink.w3.org>
Resent-Date: Thu, 12 Aug 2010 08:37:43 +0000
Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange HTTP/1.1 (RFC 2616) already contains a set of tools for modifying resources , namely the methods PUT, POST, and DELETE. Many systems have been built on top of this, most of them in an ad-hoc manner (which is ok when client and server are controlled by the same developers). We would like to cover some of the following use cases extending the resource oriented model. (1) An simple javascript based browser application should be able to read fine-grained information (comparable to WebDAV properties) in a simple manner using a defined JSON format to be consumed in an intuitive fashion. (2) A simple HTML Form should be able to write information in a patch oriented manner containing both binary (file) data and fine-grained, typed information using a multipart POST. (3) A simple javascript application should be able to write information in a patch oriented fashion using a defined JSON-diff PATCH content-type to update fine-grained information. There are also several extensions/applications of HTTP in this space, such as: - WebDAV (RFC 4918), which defines (a) a collection model and methods to manipulate collections/namespaces, (b) a metadata (=property) model, and (c) locking. Other RFCs add extensions on top of this, such as Versioning (RFC 3253) and ACLs (RFC 3744). - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler, not necessarily hierarchic collection model (which, depending on the use case, may be a plus), but does not provide many features WebDAV + friends define. Notably, namespace operations are absent. WebDAV and AtomPub have been very successful so far. WebDAV gets used both as a plain remote filesystem protocol (as observed by clients being shipped with all operating systems, and both Apache httpd and IIS supporting it), and for specific applications, such as Versioning (subversion), Calendaring (CalDAV), etc. The same is true for AtomPub, which actually may not be used a lot in practice for the original use case (feed authoring), but for many other things instead. Both of those protocol specifications are not easily consumed by websites and applications running current browsers and require a lot of client-sided scripting to cover simple read and write use cases. There's a proposal for a protocol called "JSOP", which addresses these use cases, which we may want to consider as input for this work: <http://www.slideshare.net/uncled/jsop> So what's wrong with WebDAV? Since the time WebDAV was designed, we have learned a lot how to use the Web and HTTP. Such as: - if you want to expose data for read operations, make it available to GET, and assign URIs, - consider cacheability, atomicity, and performance of sync operations (for instance, syncing large collections), - be careful with new HTTP methods -- avoid them for things that are not of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that certain platforms (HTML forms, Flash...) can't use them, - when defining formats, also define internet media types. Also, in the last few months, new (and not so new) techniques have finally been published as RFCs, such as: - HTTP PATCH method (RFC 5789) - HTTP Link Header and Link Relations Registry (http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in the RFC Editor queue) - Service Discovery through well-known URIs (RFC 5785) Another potential building block are URI templates (work in progress: http://tools.ietf.org/html/draft-gregorio-uritemplate-04) Considering all of these pieces, it's quite obvious that there's a number of specs that would be useful on their own, but could also, combined together, form the basis of an interesting authoring protocol: # Data Model 1) Define a collection model (hierarchy, naming), and a representation format. Can we re-use the WebDAV collection model here? Web application authors probably would prefer a JSON representation, so can we simply define this as an alternate representation of a DAV:multistatus description of a collection? 2) Define namespace operations in terms of manipulating collection representations (also consider a mapping to COPY/MOVE). 3) Define a media type to use with PATCH for modifying these representations. 4) Define a property model (something like the intersection between WebDAV properties and Java Content Repository (JSR-283) properties?) # Authoring through HTML forms and POST Define how POST with multipart/form-data (RFC 2388) can be used for authoring both content and properties. # URIs for collection browsing Assign either hardwired or discoverable URIs for inspecting collections (URI templates?). Or maybe link relations for collection navigation (similar work for versioning: RFC 5829). # Improvements to WebDAV 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this question comes up quite frequently). 2) Define how to use POST on WebDAV collections to add members (done: see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC Editor queue). 3) Define media types (multiple?) for DAV:multistatus. 4) Define a discovery mechanism for GETtable representations of PROPFIND/REPORT results (old proposal: http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html). 5) Define a mapping between link-typed WebDAV properties and generic Link relations (see proposal: http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html). Although some of this will only be partially related to WebDAV, we think that this mailing list might be a good venue for discussion. Expected deliverables from this activity would be: 1) Definition of a very simply data model and a representation format for it (required JSON, optionally XML). 2) A format suitable for manipulating the data format above using PATCH (potentially tunneled through POST). 3) A binding from multipart/form-data/POST to this model. 4) A separate (?) document explaining how these ingredients would be combined in practice. Extensions to WebDAV and mappings from/to WebDAV could be useful, but would not be a core part of this activity. (That is, we can do without if no volunteers speak up). Note that not all of these specs necessarily need to be on the standards track; for instance, there might be candidates for Informational RFCs as well (see <http://tools.ietf.org/html/rfc2026#section-4> for details). Feedback appreciated. Julian Reschke David Nüscheler PS: people not familiar with the IETF may want to have a look at <http://www.ietf.org/tao.html>
- Proposal for work on an efficient, browser-friend… Julian Reschke
- Webdav related extensions, was: Proposal for work… Julian Reschke
- Re: Fwd: Proposal for work on an efficient, brows… Leigh L. Klotz, Jr
- Re: Proposal for work on an efficient, browser-fr… Wenbo Zhu
- Re: Proposal for work on an efficient, browser-fr… Geoffrey M Clemm
- Re: Proposal for work on an efficient, browser-fr… Jukka Zitting
- Re: Proposal for work on an efficient, browser-fr… Wenbo Zhu
- payload formats and methods, was: Proposal for wo… Julian Reschke
- Re: Proposal for work on an efficient, browser-fr… Julian Reschke
- Re: Proposal for work on an efficient, browser-fr… Julian Reschke
- Re: Fwd: Proposal for work on an efficient, brows… Julian Reschke
- Re: Proposal for work on an efficient, browser-fr… Yves Lafon
- Re: Proposal for work on an efficient, browser-fr… Wenbo Zhu
- Re: Proposal for work on an efficient, browser-fr… Julian Reschke
- Re: Proposal for work on an efficient, browser-fr… David Nuescheler
- Re: Proposal for work on an efficient, browser-fr… Michael Wechner
- Data Model Julian Reschke
- Re: Proposal for work on an efficient, browser-fr… David Nuescheler
- Re: Data Model David Nuescheler
- Re: Data Model Julian Reschke
- Re: Data Model David Nuescheler
- Re: Data Model Julian Reschke
- Re: Data Model David Nuescheler
- Re: Data Model Julian Reschke
- Data Model, as seen from WebDAV Julian Reschke
- Re: Data Model Justin Edelson
- Re: Data Model, as seen from WebDAV Julian Reschke
- Re: Data Model, as seen from WebDAV Mike Douglass
- Re: Data Model, as seen from WebDAV Julian Reschke
- Re: Data Model, as seen from WebDAV David Nuescheler