Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange

[Wenbo Zhu <[e-mail]>]

[re-repost]

Very plausible .. and comments inline. - Wenbo


> -------- Original Message --------
>
> Subject: Proposal for work on an efficient, browser-friendly, HTTP-based
> communication protocol for fine-grained information exchange
> Date: Thu, 12 Aug 2010 10:36:59 +0200
> From: Julian Reschke <[e-mail]>
> To: WebDAV <[e-mail]>
>
> 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.
>
> I have seen many debates around representation formats when the underlying
meta-model is often ignored ... and the meta-model should cover, in addition
to hierarchy, relations. And naming should allow for different
representations too, e.g. with the URI template[] being one of them.


> 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).
>

Resource-based concurrency-control and sync (revision logs) specs may be
developed on top of these deliverables as well.


>
> 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>
>
>
>