FW: [oic] Interpretation of terminal "/" in URIs and Zip

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

There are a couple of JIRA issues needed in order to close up the holes in the current rules for package files, subdocuments, and Package manifest entries.  

Meanwhile, here is a distillation of my thinking triggered by a conversation on the 2009-02-10 OIC TC Conference Call.

 - Dennis 

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Thursday, February 11, 2010 11:44
To: OIC TC List; Svante.Schubert@Sun.COM
Subject: [oic] Interpretation of terminal "/" in URIs and Zip

Although this is an important discussion for ODF 1.2 Part 3 Package cleanup, it came up on our OIC call Wednesday and I wanted to follow up here first.  I will repost it to the ODF TC list and any discussion should be over there.

Let's see if this helps make sense of things.

Short answer (11, below): 

For me, it follows naturally that one would refer to a subdocument in a URI using a form that resolves to a full-path that matches "prefix/", and for which there is a manifest:full-path="prefix/" file entry.  This is then completely distinct from resolving to a package file that might happen to have the full-path "prefix" (no ending "/"), something which has not, so far, been prohibited in the ODF 1.2 Part 3 specification and which is definitely not prohibited in the URI RFC specifications.

 - Dennis

ANALYSIS

 1. First, it is important to understand how there are three features in the resolution of URIs to resources:

  a. The client or user agent that is processing a supplied URI

  b. The URI a service receives from an user agent or client (not necessarily identical to the one in (a)

  c. The specific response that the URI of (b) elicits from the service, including any indication of how the URI was understood 

 2. Here's a simple exercise:

 a. Open a browser

 b. Give it this *exact* URI as the address to visit: "http://orcmid.com/blog"; making sure there is no "/" on the end.

 c. Go to that location.

 d. Notice the URI that is now shown in the address bar of the browser.  For me, it is "http://orcmid.com/blog/";.  

 3. What happened here?

 4. The web server, when given "http://orcmid.com/blog"; detects that it has no resource at it's domain-resolved location, "blog", but it has a directory at that location.  So the server performs its default behavior for directory "blog/" *and* it effectively returns the corrected URL "http://orcmid.com/blog/"; to indicated how it resolved the request.  As you know, some servers return indexes of their directories when they have requests like that, some refuse to resolve the request, and others return a default page.  In my case, you are seeing the default page "http://orcmid.com/blog/default.asp";.

 5. It is also the case that there might be a resource for "http://orcmid.com/blog"; as well as a directory.  This is entirely permissible although most web servers don't have such functionality.  The same goes for file systems, where there might be a resource or data stream having the same name as a directory, and there might actually be content at the directory level separate from the content *within* the directory.  The rules for URLs tolerate these variations.  The WebDAV folks had to deal with this because in WebDAV you can create and set web resources and also create collections (usually implemented in directories).  They needed ways for users of WebDAV to have the various cases work.

 6. Now we get to the problem with resources (package files) and subdocuments (sets of one or more package files) and the mappings between URI, manifest:full-path, and the actual content names in Zip packages.

 7. First, for URIs (not file-system addresses), the appearance of ".", "..", "./", "../", etc. are generally client-side or user-agent material (as are #fragment IDs, usually).  These are typically not sent to services in http requests for example.  Instead, the relative URI is turned into an absolute one in some way, and the absolute URI is communicated to the service.  The URI RFCs describe the convention for this.

 8. Now look at the full-path rules, such as they are.  It is simple to infer that a subdocument is a set of package files where the manifest:full-path entries for those package files have a common prefix, "prefix/" which is given as the manifest:full-path of the entry that provides the MIME type for the subdocument.  This file entry has no package file (there is nothing in the Zip with that name) and there is no encryption, of course.  
    It is not prohibited by the rules for URI resolution, and it certainly doesn't impact the use of Zip (which is indifferent to "prefix/" as a prefix), for there to also be a package file with manifest:full-path="prefix" (without the terminal "/").  This is not a subdocument and it is a perfectly good name for a package file.

 9. Basically, we could say that contents of a package are all of the package files that have names of the form "prefix/more" and for which there is a manifest:full-path="prefix/" file entry.

 10. There is one exception to (10).  For the document itself, reflected in manifest:full-path="/" (prefix is empty), the document parts are not identified with manifest:full-path="/more" because package files are not permitted to have names that begin with "/".  (That is a requirement of the Zip specification.)

 11. For me, it follows naturally that one would refer to a subdocument in a URI using a form that resolves to a full-path that matches "prefix/", and for which there is a manifest:full-path="prefix/" file entry.  This is then completely distinct from resolving to a package file that might happen to have the full-path "prefix", something which has not, so far, been prohibited in the ODF 1.2 Part 3 specification.


 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php