Subject: Re: [Uri-review] Request for review

From: "Mark Baker" <[email-masked]>
Date: Fri, 9 Jun 2006 05:44:29 +0100

Hi Jerry,

Sorry for the delay.

On 5/26/06, Jerry Dunietz <[email-masked]> wrote:
> 1)  Relative references within a package should "work" correctly.

We seem to disagree on what "work correctly" means, so perhaps you
should mention your requirement(s) for having it work the way you
desire.  IIRC, that seemed to be security related.

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

Right.  My http URI meets that requirement.

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

By "function" you mean what exactly?  Because the identifier I minted
works perfectly as an identifier.  It's only when you want to
dereference it to obtain the part, that new software is required.  And
it will be required in both cases AFAICT, no?

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

Reusing the http scheme would mean no new client side code was
required *at all*.  Would that not be advantageous?

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

It seems it's a bit of both.

Cheers,

Mark.

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

---

From: "Jerry Dunietz" <[email-masked]>
Date: Fri, 16 Jun 2006 17:17:16 -0700

Thanks for your reply, and apologies for further delay in
continuing this discussion.

(My mailer isn't currently configured to automatically generate
replies matching your formatting conventions.  I hope my attempts
to do so by hand are satisfactory.)

> desire.  IIRC, that seemed to be security related.

I was deliberately keeping the security topic out of my last posting.
I'm happy to return to that topic, because I really do believe
that the proposed scheme does have some advantageous security
characteristics.  But I believe that the proposed URI Scheme is fully
motivated without bringing the security issue into the discussion.
So I'd like to set that issue aside for the moment.

When I wrote "work correctly", I did not mean to imply anything about
leading ".." segments that would appear to attempt to cross the
package boundary.  By "work correctly", I meant that ordinary
(no superfluous ".." segments) relative-references between parts in
a package should behave the same as identical relative-references
between resources on a server.  I don't think that anyone has
suggested anything on this list that would violate this particular
goal, but this goal needed to be stated, if only to answer the
potential question of "why didn't you use fragment-identifiers to
identify parts within a package?"

> Right.  My http URI meets that requirement.

Couldn't agree more!

> it will be required in both cases AFAICT, no?

By "function", I did exactly mean to suggest "be capable of being
dereferenced," as you inferred.  And yes, new software will have to
be deployed somewhere in order to support dereferencing URIs that
point to parts within packages.  The question, of course, is where
that code will have to be deployed.

Typically, deferenceable schemes supporting a GET-like operation
require code to be deployed on both the client and the server.
You describe an approach to packaging that requires code-deployment
on the server, but no particular code on the client.  (Not surprising,
given that you actively trying to avoid minting a new scheme!)  But
if the client ever has the desire to copy the entire package
down to the client, the client needs some out-of-band knowledge that
"http://www.mysite.com/my.package" will get him a complete package
in a particular format containing all of the lower-level resources.
And more importantly, after the package has been copied to the
client, the client obviously would require some client-side code
to access the parts within the package.

Our goal was to deploy a solution which would allow packages to reside
on servers with no awareness of the physical format of a package,
accepting the need to deploy client-side code (in this specification,
in the form of a scheme implementation).  Note that because no server-
side code is required, the client will interoperate with packages
retrievable via any otherwise-supported scheme.  Thus, for example,
the package might be stored on an FTP server and addressed with
an "ftp:" URI.

Identical code can be used for working with packages on an HTTP
server as for working with packages on a local filesystem.  In the
former case, the code works with a "pack:"-scheme URI in which the
token "http" occurs in the authority component.  In the latter case,
the URI-based code works with a URI with the token "file" occurring
in the authority component.

> required *at all*.  Would that not be advantageous?

Interesting and advantageous, but a set of goals different
than we were pursuing.  (I actually like the idea of potentially
deploying both sets of solutions simultaneously.  They don't
conflict with each other.)

> It seems it's a bit of both.

I think primarily it's been about clarifying goals.  Both sets
of goals have solid benefits.  The set upon which Andrey and I are
focusing led to the design of a new scheme, one requiring only client-
side support.  The set towards which I think you've been driving this
discussion doesn't require a new scheme,  but does require server-side
support.  Nothing about either suggestion (new client-side URI scheme on
the one hand, package-aware server-side code on the other) prevents the
other from being implemented.  I don't think that the implementability
of your suggestion reduces the value of ours.  (Nor vice-versa.)

-- Jerry Dunietz

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 19 Jun 2006 01:02:34 -0400

Jerry,

On 6/16/06, Jerry Dunietz <[email-masked]> wrote:
> given that you actively trying to avoid minting a new scheme!)

Yep!  I should just mention too, that the new URI registration
requirements require (with SHOULD strength) that permanent
registrations demonstrate that existing URI schemes are insufficient,
which is what motivates the questions I've been asking;

  "New URI schemes SHOULD have clear utility to the broad Internet community,
   beyond that available with already registered URI schemes"
  -- RFC 4395 sec 2.1

>  But

Yes, certainly, code to process the media type of the archive format
is required in both cases.  But I assume that the media type name
would suffice for your "out-of-band knowledge" above, no?  More below
...

> the package might be stored on an FTP server and addressed with

Right.  Or an HTTP server with a http URI? 8-)

> in the authority component.

I'm not sure I'm following you.  What do you mean by "the code works with"?

As I see it, if the package were downloaded to the client, be it with
HTTP, FTP, or a pack-specific PACK-TP, it should ideally be
transferred using a media type which declares the format; say,
application/vnd.ms.pack.  And that media type should be used in
locating an application which can process the package.  I don't see
why the URI should be used in that process, because a) URIs are names
and don't typically carry that kind of info (the data scheme
notwithstanding), and b) that sounds just like what a media type is
for.

> support.

It doesn't require any more server-side support than the new URI scheme, AFAICT.

Cheers,

Mark.

---

From: "Jerry Dunietz" <[email-masked]>
Date: Fri, 23 Jun 2006 17:53:58 -0700

>    beyond that available with already registered URI schemes"

Thanks for clarifying the context of our discussion.

> would suffice for your "out-of-band knowledge" above, no?  More below

If one is willing to relax other goals, then yes, it would be
sufficient to know the media type name or names, and to explicitly
include or reference code whose implementation matches the details
of the package format.  But I will return below to the goals that
make this approach unsatisfactory.

> I'm not sure I'm following you.  What do you mean by "the code works
with"?

Let me elaborate.  There exist programming frameworks in both
the Java and .NET worlds that includes classes for dealing with and
dereferencing URIs and/or URLs.  (The exact class names used varies.)

My point was that any code which written to use such a general
URI-dereferencing class need not be modified to deal with the
introduction of the "pack:" scheme; the only modification would be
the one required to incorporate "pack:" support into the URI-
dereferencing class.  If a component's source code deals with, for
example, the SVG media type, then it need not be modified to
support SVG embedded within a package.

Furthermore, as I stated before, our goal is to allow for dereference-
able external URIs pointing to individual part-resources within a
package.  If we were to model the package only with a media type (or
set of media types), then we would have to invent a fragment-identifier
mechanism to allow for the referencing of individual parts within the
package.  And if we were to use fragment-identifiers for this purpose,
we would raise the problematic question of what base URI should be
used when dereferencing relative-URIs embedded within an individual
part. If we used a fragment-identifier to address the individual
part, then by ordinary conventions, the base URI for resolving
relative references embedded in the individual part would be the
(fragment-identifier-free) URI of the package as a whole.

The combination of our three goals lead us to our specification:

1.  External absolute references to individual parts.
2.  An individual part's URI can serve as a base URI.
3.  Package can reside on any server implementing any protocol
supporting a GET-like operation, without requiring new code to be
deployed on the server.

> notwithstanding), and b) that sounds just like what a media type is

We do have a number of media types for domain- or application-
specific data formats that are defined in terms of the package-format
spec.  We are considering the possibility, as you suggest, of a
domain-independent media-type for a generic package, applicable
independently of what the package holds.

> It doesn't require any more server-side support than the new URI
scheme, AFAICT.

We believe that the URI scheme we propose requires *no* server-side
support.  What server-side support are you suggesting?  The only
thing I can think of would be convincing the server to return the
correct mime type for each package, but I don't think of that as a
code change.

Finally, I would now like to re-introduce the "security" argument
that I set aside earlier in this thread.  I said before that I didn't
believe that the "security" topic was necessary to motivate our
specification.  But we observe that some existing software makes
security decisions based on determining whether or not two URIs
reference resources within the same "site" or "zone".  We regard it
to be a feature of our proposal that any such pre-existing software
will consider any package-boundary to be a "site" boundary.  Any
protections for cross-site references will apply to references
that cross a package boundary.

-- Jerry

P.S.  Unfortunately, I will not be able to contribute to this
interesting exchange for the next three weeks.  During that period,
my colleague Andrey Shur will be continue to participate and respond
as appropriate.

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 29 Jun 2006 10:40:38 -0400

Jerry,

> support SVG embedded within a package.

Ok, thanks.  I agree that is valuable.

> package.

No, you wouldn't AFAICT.  You could use what I proposed before, about
using references relative to the URI of the package.

>  And if we were to use fragment-identifiers for this purpose,

My solution also meets those goals, AFAICT.

> independently of what the package holds.

Good.

> We believe that the URI scheme we propose requires *no* server-side

Right.  But you seemed to suggest that my alternate proposal does
require it.  I don't believe either approach does, at least for this
case of "download the package to the client".

> that cross a package boundary.

Can you provide some more specifics about this software?

Cheers,

Mark.