RE: [Uri-review] Request for review

["Jerry Dunietz" <[e-mail]>]

Forgive me for being late to join this conversation.  Thanks for all of 
the constructive discussion!  I'm going to chime in with some long mail,

picking up on some comments made by both Martin Duerst and Mark Baker.  

I'm covering three topics here:

I.   Relative references and leading slash
II.  Martin Duerst's scenarios involving a "directory of files"
III. Refining the goals for the "pack:" scheme

I. Relative references and leading slash

Just to confirm, I hope that it is now clear that there is no
requirement 
for the relative references within a package to begin with a leading
slash.  
Assume that we take some hierarchically-"close" resources on the web,
and 
we copy their representations (unmodified) into a package.  If the
package 
preserves enough of the "close" naming hierarchy surrounding the
resources, 
then the original relative-references will now resolve to the 
representation-copies within the package.  Achieving this behavior is
one 
of the goals we had in specifying the "pack:" scheme.

II.  Martin Duerst's scenarios involving a "directory of files"

Martin Duerst wrote:

> But what I was talking about (sorry I wasn't explicit
> enough) was conversion from e.g. a directory full of files and 
> directories and so on to a package and again backwards.

I want to take the time to expound on this topic at some length, just to

make sure that we clearly understand one another.  (I think that I
understand 
the concerns, and I believe that the implications are acceptable.)

It is true that if one of our resource-representations contained a
relative 
reference which pointed outside of the "close" naming hierarchy that has

been preserved in the package, then such a relative reference will no
longer 
resolve within the package in a manner that is consistent with the way
in 
which it was resolved against the original HTTP server.  Most likely,
the 
relative-reference will fail to resolve.  However, it is conceivable
that 
the relative reference will now be interpreted as pointing to some other

resource-representation within the package.  So, for example, if I have 
on a web-server:

http://example.com/foo.xml
http://example.com/a/foo.xml
http://example.com/a/b/foo.xml
http://example.com/a/b/bar.xml

Let us assume that http://example.com/a/b/bar.xml contains within it 
three relative references, with the following forms:

"foo.xml"
"../foo.xml"
"/foo.xml"

Against the HTTP server, the these three reference will resolve to 
*different* resources.

Now, suppose we choose to gather everything under
"http://example.com/a/b" 
into a package.

There are three different naming choices I might make in putting
together 
my package.

1)

/foo.xml
/bar.xml

2)

/b/foo.xml
/b/bar.xml

3)

/a/b/foo.xml
/a/b/bar.xml

If I take the first naming approach, the relative references of the 
form "../foo.xml" and "/foo.xml" behave very differently then they did 
against the HTTP server.  They both successfully resolve, but produce 
very different results than they originally did.  The behavior of 
"../foo.xml" is a direct result of the requirements of RFC 3986 -- 
the excess leading ".." segments (in the context of the package
authority) 
effectively disappear.  All three references now resolve to the same 
resource, whereas they resolved to three different resources originally.

If I take the second or third naming approach, the references of the 
form "../foo.xml" and "/foo.xml" will not be resolvable, but at least 
they will not resolve to totally different resources (or copies of 
a resource-representations) then they did in the original environment.  
However, if I take the second approach, there are other relative 
references which will (successfully) resolve differently then they 
would have originally.

By taking the third approach, I guarantee, without processing the 
contents of every copied resource-representation, that no formerly-
functioning relative reference will *successfully* resolve differently 
then it did in the original environment.

If I take instead the stronger goal of assuring that no formerly-
functioning relative-reference is broken, then I must either propagate 
every resource from the original web-server (authority) into the
package, 
or I must filter all of the references within all of the resources 
being propagated into the package.

So far, I've only addressed what happens when I propagate a bunch 
of resources into a package.  I haven't discussed what happens if 
I take a copy of the package, and then "explode" its contents to point 
deep within the naming hierarchy of my own private filesystem or web-
server.  If any reference contained excess leading ".." segments on 
the original HTTP server, then it is true such a reference might have 
successfully resolved in the original environment and also within the 
package environment, but it might (successfully) resolve differently 
in the new environment.

Having taken the time to write all of the above down, I don't actually 
consider the behavior I've described above to be problematic enough 
to outweigh the advantages of what we've designed.  I recognize that 
others might disagree.  But I do want to make sure that I fully 
understand the behavior that might be seen as problematic.  Have 
I captured your concerns (perhaps in too great detail)?  Hopefully, 
we can agree on all matters of fact, but we might have disagreements 
on matters of judgment.

III. Refining the goals for the "pack:" scheme

Let me list a few goals here, some of which were not clearly called out 
in the original submission.  I believe that this set of goals leads us 
to the design we've proposed here.  I think it important that we clearly

distinguish between discussions questioning the goals below from 
discussion questioning the means for achieving these goals.  (Both are 
interesting discussions, but let's me clear about when we are discussing

each.)

1)  Relative references within a package should "work" correctly.

2)  Given a package on an HTTP server somewhere, we should be able to 
construct an absolute reference to a particular part nested in the 
package, made from outside of the package.

3)  We would like the absolute reference described in #2 to function 
without requiring the deployment of any new code on the HTTP server 
holding the package.  (Mark Baker's suggestion of 
"http://www.mysite.com/my.package/a/b/foo.xaml" does not satisfy 
this goal.)

4)  We would like to deliver behavior above without changing existing 
code that relies upon off-the-shelf client-side libraries for dealing 
with URIs.  (That is, we assume that client-side library or installed
code would be updated to support the "pack:" scheme, but the 
code that calls the library requires no change.)

So -- are concerns being expressed with respect to the desirability of 
the new set of goals I describe here, or are they with the means for 
achieving those goals?  (I do think that it would be reasonable for us 
to flesh out the goals stated in the original submission.)

-- Jerry Dunietz
   

_______________________________________________
Uri-review mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/uri-review