Re: [Uri-review] Request for review

"Roy T. Fielding" <fielding@gbiv.com> Thu, 06 July 2006 02:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyJsw-0006D8-4v; Wed, 05 Jul 2006 22:46:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyJsv-0006D1-0B for uri-review@ietf.org; Wed, 05 Jul 2006 22:46:33 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyI7v-0003Cn-6p for uri-review@ietf.org; Wed, 05 Jul 2006 20:53:55 -0400
Received: from scorpio.lunarpages.com ([209.200.229.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyHrv-0001WE-Au for uri-review@ietf.org; Wed, 05 Jul 2006 20:37:25 -0400
Received: from wsip-70-183-59-151.oc.oc.cox.net ([70.183.59.151] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpa (Exim 4.52) id 1FyHsi-0004sv-Rw for uri-review@ietf.org; Wed, 05 Jul 2006 17:38:13 -0700
To: Andrey Shur <andreysh@exchange.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Resent-Date: Wed, 05 Jul 2006 17:37:17 -0700
Message-Id: <C393E78D-AC62-4C29-9DF8-9E43D1169C39@gbiv.com>
Content-Transfer-Encoding: 7bit
Resent-To: uri-review@ietf.org
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: [Uri-review] Request for review
Resent-From: "Roy T. Fielding" <fielding@gbiv.com>
Resent-Message-Id: <3EC61E44-442C-488E-9F90-98E96FC53E3A@gbiv.com>
Date: Wed, 05 Jul 2006 14:20:34 -0700
X-Mailer: Apple Mail (2.752.2)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - gbiv.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Mark Baker <distobj@acm.org>, "John Calhoon (LCA)" <John.Calhoon@microsoft.com>, TedHardie <hardie@qualcomm.com>, "uri-review@ietf.org" <uri-review@ietf.org>, Jerry Dunietz <jerryd@windows.microsoft.com>, Gregg Brown <greggb@microsoft.com>
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
Sender: uri-review-bounces@ietf.org
Errors-To: uri-review-bounces@ietf.org
Resent-Date: Wed, 05 Jul 2006 22:46:34 -0400

Mark is talking about URI rewriting on an HTTP server -- I'm not sure  
what
relevance that has to packages not served via HTTP.  In any case, we
certainly do not need a pack URI.

This entire design space was covered by the discussions regarding MHTML
(encapsulating packages of HTML + inline resources via email) almost ten
years ago, and the same techniques apply here.  The packaging format
needs to contain a catalog table of "package part" --> "real URI" and
treat the package itself as a local cache.  All references to those URIs
are resolved by the package manager to the part given in the catalog.
Each part has a defined base URI, usually its original URI at the time
the package was generated.  The individual parts do not need to be
altered in any way (a requirement for digital sigs).  It also defines
a set of new URIs by treating the individual part names as hierarchical
identifiers within the package (i.e., a folder containing those parts).

The above design is implemented in the media type handler for the
package type by inserting a local cache handler and associating each
part with its corresponding base URI.  Any browser supporting the  
package
type (internally or via plug-in) will require special code to do so,
regardless of how references are handled.  The rest of the browser is
generic, and the package can be served from any source.

Creating a "pack" media-type-specific URI that encapsulates all other
URIs is a terrible idea, especially when it merely applies media-type
instructions on how a browser should handle embedded resources.
It would invert the current relation between identifiers and media  
types,
which is a gross violation of web architecture.  I will never implement
such a beast.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>


_______________________________________________
Uri-review mailing list
Uri-review@ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review