Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange
Wenbo Zhu <wenboz@google.com> Fri, 13 August 2010 00:12 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECE03A69E0 for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Thu, 12 Aug 2010 17:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.976
X-Spam-Level:
X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 DaFSbkJK0p-M for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Thu, 12 Aug 2010 17:12:50 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 624803A63EC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 12 Aug 2010 17:12:50 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ojhsh-0007rd-PA for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Aug 2010 00:12:19 +0000
Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <wenboz@google.com>) id 1OjhsQ-0007q9-Az for ietf-http-wg@listhub.w3.org; Fri, 13 Aug 2010 00:12:02 +0000
Received: from smtp-out.google.com ([216.239.44.51]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from <wenboz@google.com>) id 1OjhsN-0005dH-TL for ietf-http-wg@w3.org; Fri, 13 Aug 2010 00:12:02 +0000
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o7D0BXMT024364 for <ietf-http-wg@w3.org>; Thu, 12 Aug 2010 17:11:33 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281658293; bh=ZsF8NT8ActhJhkUiY8dtJrl2acA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=vBe4nW/7hZqJo+OOrySdlzyYH5dxv1RiIIatyL89HU/Fu/22fH+6XwUSyGC5nvgSL EKDfw6mGE2fTEwoJobtiQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=tx2kOl3UCM6HipgdreBBfSelbPWrBLt13AcAGp5WEQuEeseaDSo2XXlkrLrxbvoZS ecaQjGtCHR3/ESahgg4ew==
Received: from qwe4 (qwe4.prod.google.com [10.241.194.4]) by wpaz21.hot.corp.google.com with ESMTP id o7D0BWlY003166 for <ietf-http-wg@w3.org>; Thu, 12 Aug 2010 17:11:32 -0700
Received: by qwe4 with SMTP id 4so1983706qwe.22 for <ietf-http-wg@w3.org>; Thu, 12 Aug 2010 17:11:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.171.198 with SMTP id i6mr511448vcz.248.1281658291418; Thu, 12 Aug 2010 17:11:31 -0700 (PDT)
Received: by 10.220.188.203 with HTTP; Thu, 12 Aug 2010 17:11:31 -0700 (PDT)
In-Reply-To: <4C63C650.1090301@gmx.de>
References: <4C63C650.1090301@gmx.de>
Date: Thu, 12 Aug 2010 17:11:31 -0700
Message-ID: <AANLkTi=GCUezZOeZ+vCW0G8SwTUqkWZiiS3Pb57CpgRX@mail.gmail.com>
From: Wenbo Zhu <wenboz@google.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0016e64136042efc0d048da95332"
X-System-Of-Record: true
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: bart.w3.org 1OjhsN-0005dH-TL 3aeb15ba19d2943e79cb3403c45b90f3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange
Archived-At: <http://www.w3.org/mid/AANLkTi=GCUezZOeZ+vCW0G8SwTUqkWZiiS3Pb57CpgRX@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/9072
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1Ojhsh-0007rd-PA@frink.w3.org>
Resent-Date: Fri, 13 Aug 2010 00:12:19 +0000
Very plausible .. and comments inline. - Wenbo On Thu, Aug 12, 2010 at 3:00 AM, Julian Reschke <julian.reschke@gmx.de>wrote: > 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 -- see < > http://lists.w3.org/Archives/Public/w3c-dist-auth/>). > > 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@gmx.de> > To: WebDAV <w3c-dist-auth@w3.org> > > 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> > > >