FYI - a proposal for collaboration on an
authoring protocol that would
be more browser-friendly than WebDAV or AtomPub
-- for now we started
discussion on the IETF WebDAV mailing list
(hosted by the W3C).
Feedback appreciated.
-------- 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
<julian.reschke@xxxxxx>
To: WebDAV <w3c-dist-auth@xxxxxx>
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>