RE: [Uri-review] Request for review

[Andrey Shur <[e-mail]>]

Hi Martin,

thank you for the feedback. You have raised the number of points, but before going through them let me describe how relative references in a part's content are resolved according to the Open Packaging Conventions (OPC) technology (which "pack:" Uri scheme is a part of).

Let's take the package http://www.mysite.com/my.package. The package holds a number of parts; the part named /bar.xml holds relative references "../../foo.ext" and "/path/foo.ext".

OPC defines the base Uri of the part named /bar.xml as pack://http%3c,,www.mysite.com,my.package/bar.xml. Note that OPC only defines the base Uri of a part, the resolution of relative references follows the algorithm defined in RFC 3986 section 5.

If content of the part /bar.xml does not hold explicit instructions defining another base Uri (e.g. xml:base attribute), relative references are resolved against the base Uri of the part.

In our example:

Relative reference ../../foo.ext resolved against the base Uri = pack://http%3c,,www.mysite.com,my.package/bar.xml gives us pack://http%3c,,www.mysite.com,my.package/foo.ext. The obtained Uri identifies part named /foo.ext within the given package.

Relative reference /path/foo.ext resolved against the base Uri = pack://http%3c,,www.mysite.com,my.package/bar.xml gives us pack://http%3c,,www.mysite.com,my.package/path/foo.ext. The obtained Uri identifies part named /path/foo.ext within the given package.

We can see from these two examples that any relative reference (let's put network-path aside) being resolved against the base Uri of the part gives us the "pack:" Uri that identifies a part within the same package.

Regards,
Andrey Shur

-----Original Message-----
From: Martin Duerst [mailto:[e-mail]]
Sent: Monday, May 22, 2006 8:04 PM
To: Andrey Shur; Mark Baker
Cc: John Calhoon (LCA); [e-mail]; Ted Hardie; [e-mail]; Jerry Dunietz; Gregg Brown
Subject: RE: [Uri-review] Request for review

Hello Andrey,

At 11:08 06/05/23, Andrey Shur wrote:
>Mark,
>
>Thank you for the question. I can see two parts of it that should be answered:
>
>First, why do we consider "any relative reference"? Actually we expect
>users of the packaging technology to store manifold content in the package parts.

Of course.

>Certain kinds of the content may hold relative references.

Yes of course. But you don't have any guarantee that the
content referenced will be part of the package. So if a
user wants to create a 'self-contained' (meaning no
external relative references) package, either the user
(manually, or with dedicated scripts,...) or the packaging
software has to check all the references anyway.
Such a check is only marginally simplified by the
fact that there is a way to rewrite these relative
references so that any in-package relative reference
can start with a single slash, and out-of package
relative refences cannot be converted.


>We don't want to limit our customers to a particular form of relative
>references.

If you want to make use of the specific properties of your
scheme, you have to rewrite relative references anyhow, in
which case it doesn't make much of a difference.

Let's say the user uses something like ../../foo.ext.
If this is in-package, you can leave it as that. If it
is out-of-package, and you want to restrict such links,
you have to raise an error (or do something else according
to user preferences).

Let's say the user uses something like /path/foo.ext.
Again, this could be in-package or out of package. You have
to check, and if necessary rewrite it.


>Second, why do we have a goal to "keep relative references within the
>package"? This is all about security. An application performing regular
>(default) resolution of relative references should not access resources
>outside of the package.

But the syntax you came up with doesn't guarantee this, as you
showed with the ../../../foo.ext example.

Trying to get security with the syntax, when you actually don't have
that security and therefore need to check things anyway on the
receiving end and/or on the production end doesn't make much sense
to me.

Also, the additional potential security threads created by
an additional escaping layer should be considered.


>If an application needs to access external resources, it must be
>explicitly defined in the content by specifying an appropriate base Uri

So basically all the security precautions can be circumvented
by using a base URI? Again, security has to be checked on
resolution. Trying to build it into the syntax doesn't work.


>or by using network-path form of the relative reference.

Using a network-path reference means to use the same scheme as
used previously, which means the pack: scheme. As said in
RFC 3986, network-path references are rare anyway.
You don't mention absolute URIs. Are they allowed or not?

Regards,    Martin.




#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]


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