RE: [Uri-review] Request for review

On 7/5/2006, Roy T. Fielding wrote:

Roy,
Thank you for the feedback. My comments are inline.

Regards
- Andrey

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

This is also the case for the packaging technology Microsoft is coming up with. Saying this I assume that a catalog table does not necessarily needs to be persisted in actual bits within the package. It could be virtual as long as it is well-defined. The "pack:" Uri schema establishes unambiguous rules for "package part" --> "real Uri" table.

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

The substantial feature of the packaging technology is its purpose to be the framework for multiple media types. It is already the foundation for MS Office 2007 files, and Windows .XPS files. Microsoft has solid plans to extend the line of media-types based on this packaging within and outside of the company. Therefore we made a special effort to move the packaging addressing model outside of the particular media type(s) handling. That is why we picked URI schema as a mechanism we can support across the open family of package-based media types.

More information on this can be found in MSDN article at http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/opcadmdl.asp

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

I'm a bit confused by the term "terrible idea" you've used to denote the "pack" Uri. In fact when the "pack" Uri is supported, browser navigates to the part without knowing the mime-type of the package file. Part does not appear as an embedded resource for the browser, but rather as a regular resource identified by a Uri. The mime-type of the part is returned to caller, so browser can run the appropriate media type handler for the part.

Clearly the pattern of the "pack" Uri, implied by its purpose to be the foundation of the addressing model for the family of package-based media types, is to some extent unusual. We have done a lot of usability and security analysis before coming up with the current design. If you have in mind scenarios which make the "pack" Uri experience "terrible", please let us know.

>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