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

From: Andrey Shur <[email-masked]>
Date: Mon, 3 Jul 2006 14:38:39 -0700

Martin,

On 6/29/06, Martin Duerst <> wrote:
>>  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.

>My solution also meets those goals, AFAICT.

Could you please explain how your solution works for the package residing on non-HTTP (e.g. FTP) server?

Regards,

- Andrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Thursday, June 29, 2006 7:41 AM
To: Jerry Dunietz
Cc: Martin Duerst; Andrey Shur; John Calhoon (LCA); [email-masked]; TedHardie; [email-masked]; Gregg Brown
Subject: Re: [Uri-review] Request for review

Jerry,

On 6/23/06, Jerry Dunietz <[email-masked]> wrote:
> > 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.

Ok, thanks.  I agree that is valuable.

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

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

My solution also meets those goals, AFAICT.

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

Good.

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

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

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

Can you provide some more specifics about this software?

Cheers,

Mark.

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

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 3 Jul 2006 20:33:58 -0400

> Martin,

Mark.  Now we're even 8-)

> Could you please explain how your solution works for the package residing on non-HTTP (e.g. FTP) server?

If I had a package at;

  ftp://example.org/foo/my.package/

then I could identify parts like so;

  ftp://example.org/foo/my.package/part1

Mark.

---

From: Andrey Shur <[email-masked]>
Date: Mon, 3 Jul 2006 22:08:15 -0700

>> Could you please explain how your solution works for the package residing >on non-HTTP (e.g. FTP) server?

>Mark.

Ok. I see your point.
To complete the picture - how your solution works for the packages residing in a database on a server? For instance a package at: http://www.example.org/foo/packages.asp?name=my.package

Regards
- Andrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Monday, July 03, 2006 5:34 PM
To: Andrey Shur
Cc: Jerry Dunietz; Martin Duerst; John Calhoon (LCA); [email-masked]; TedHardie; [email-masked]; Gregg Brown
Subject: Re: [Uri-review] Request for review

Mark.  Now we're even 8-)

If I had a package at;

Mark.

---

From: Andrey Shur <[email-masked]>
Date: Mon, 3 Jul 2006 22:18:50 -0700

Mark,

I apologize for confusing the ownership of your mail. Sorry about that.

Regards
- Andrey Shur

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Monday, July 03, 2006 5:34 PM
To: Andrey Shur
Cc: Jerry Dunietz; Martin Duerst; John Calhoon (LCA); [email-masked]; TedHardie; [email-masked]; Gregg Brown
Subject: Re: [Uri-review] Request for review

Mark.  Now we're even 8-)

If I had a package at;

Mark.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 04 Jul 2006 12:14:49 +0900

>  ftp://example.org/foo/my.package/part1

Would that mean that the server would do the expansion? Or the
client? If the client, then that would essentially mean an
update to the ftp: scheme, or not? The ftp client would have
to go through the hierarchy down to the point where it
expects a directory but finds a package file, then download
the package file and apply the rest of the URI path to find
the actual file. No current ftp client does that.

(Not that I like the pack: scheme, it's really ugly in many ways.)

Regards,   Martin.

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

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 4 Jul 2006 07:38:30 -0400

Andrey,

> To complete the picture - how your solution works for the packages residing in a database on a server? For instance a package at: http://www.example.org/foo/packages.asp?name=my.package

I'd suggest you publish a purely hierarchical URI like the ones I've
suggested, and then use URI rewriting to map it to URIs like that one
above (if that's what your database requires).  Obviously my solution
does rely on hierarchy.

Cheers,

Mark.

---

From: Andrey Shur <[email-masked]>
Date: Tue, 4 Jul 2006 18:35:30 -0700

Mark,

>> To complete the picture - how your solution works for the packages >>residing in a database on a server? For instance a package at: >>http://www.example.org/foo/packages.asp?name=my.package

>above (if that's what your database requires).  Obviously my solution

I'm not sure I understand your suggestion. Could you please provide an example on <URI rewriting>, you've mentioned?

Regards,
- Andrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Tuesday, July 04, 2006 4:39 AM
To: Andrey Shur
Cc: Jerry Dunietz; Martin Duerst; John Calhoon (LCA); TedHardie; [email-masked]; Gregg Brown
Subject: Re: [Uri-review] Request for review

Andrey,

Cheers,

Mark.

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 4 Jul 2006 22:38:33 -0400

> I'm not sure I understand your suggestion. Could you please provide an example on <URI rewriting>, you've mentioned?

Sure.

I use rewriting for all my CGI apps, which are by default (with
Apache) kept in /cgi-bin.  So, for example, I map requests for the URL
"http://www.markbaker.ca/2002/09/Blog/" to
"http://www.markbaker.ca/cgi-bin/blosxom".  This is done transparently
from the client's POV; no redirects required.

I understand that there are third party plugins which do basically the
same thing for IIS.

Mark.

---

From: Andrey Shur <[email-masked]>
Date: Tue, 4 Jul 2006 21:51:25 -0700

On 7/4/2006, Mark Baker <[email-masked]> wrote:

>> I'm not sure I understand your suggestion. Could you please provide an >>example on <URI rewriting>, you've mentioned?

Mark,

I should have been more specific in my previous question. I was asking for explanations on how Uri rewriting may work for the particular case we are discussing - a package residing in a database on a server. I still don't get it.

Could you please provide more specific example?

Regards
- Andrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Tuesday, July 04, 2006 7:39 PM
To: Andrey Shur
Cc: Jerry Dunietz; Martin Duerst; John Calhoon (LCA); TedHardie; [email-masked]; Gregg Brown
Subject: Re: [Uri-review] Request for review

Sure.

Mark.

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 5 Jul 2006 07:51:19 -0400

> Could you please provide more specific example?

Well, the same mechanism I described could be used to a expose the URI
you asked about;

http://www.example.org/foo/packages.asp?name=my.package

As, say, this;

http://www.example.org/foo/packages/my.package

The intent would be that the latter URI would be published to the
world instead of the former.

Mark.

---

From: Andrey Shur <[email-masked]>
Date: Wed, 5 Jul 2006 15:04:59 -0700

On 7/5/06, Mark Baker <[email-masked]> wrote:

>> I should have been more specific in my previous question. I was asking >for explanations on how Uri rewriting may work for the particular case we >are discussing - a package residing in a database on a server. I still >don't get it.
>>

Mark,

If for the case the Uri like http://www.example.org/foo/packages/my.package/my.part
would be published to the world, how then the information on the my.package actual location (residing in the database at http://www.example.org/foo/packages.asp?name=my.package)
is obtained by a client?

In other words how the published Uri is different from the Uri indicating /my.part part in the package located at regular HTTP address:  http://www.example.org/foo/packages/my.package ?

Regards
- Andrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Wednesday, July 05, 2006 4:51 AM
To: Andrey Shur
Cc: Jerry Dunietz; Martin Duerst; John Calhoon (LCA); TedHardie; [email-masked]; Gregg Brown
Subject: Re: [Uri-review] Request for review

As, say, this;

Mark.

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 5 Jul 2006 20:28:12 -0400

> In other words how the published Uri is different from the Uri indicating /my.part part in the package located at regular HTTP address:  http://www.example.org/foo/packages/my.package ?

The client never sees the URI with the query term, only the hierarchical one.

Mark.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 5 Jul 2006 17:52:46 -0700

[repost under correct address]

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

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.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Andrey Shur <[email-masked]>
Date: Wed, 5 Jul 2006 17:57:23 -0700

On 7/5/06, Mark Baker < [email-masked]> wrote:
>> Mark,
>>
>> If for the case the Uri like >http://www.example.org/foo/packages/my.package/my.part
>> would be published to the world, how then the information on the >my.package actual location (residing in the database at >http://www.example.org/foo/packages.asp?name=my.package)
>> is obtained by a client?
>>
>> In other words how the published Uri is different from the Uri indicating >/my.part part in the package located at regular HTTP address:  >http://www.example.org/foo/packages/my.package ?

>The client never sees the URI with the query term, only the hierarchical >one.

Mark,

let's assume that client sees the following hierarchical Uri:
http://www.example.org/foo/packages/my.package/my.part

What should be the algorithm for resolving it to /my.part part assuming that package can reside at http://www.example.org/foo/packages/my.package or it can reside in database at http://www.example.org/foo/packages.asp?name=my.package.

Where the client obtains the information on particular package location? Clearly this information is not decoded in the hierarchical Uri.

Regards
- Andrey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: Wednesday, July 05, 2006 5:28 PM
To: Andrey Shur
Cc: Jerry Dunietz; Martin Duerst; John Calhoon (LCA); TedHardie; [email-masked]; Gregg Brown
Subject: Re: [Uri-review] Request for review

Mark.

---

From: Martin Duerst <[email-masked]>
Date: Thu, 06 Jul 2006 10:33:25 +0900

At 07:04 06/07/06, Andrey Shur wrote:

>Mark,
>
>If for the case the Uri like 
>would be published to the world, how then the information on the my.package 
>actual location (residing in the database at 
>http://www.example.org/foo/packages.asp?name=my.package)
>is obtained by a client?
>
>In other words how the published Uri is different from the Uri indicating 
>/my.part part in the package located at regular HTTP address:  
>http://www.example.org/foo/packages/my.package ?

It's a very basic principle that URIs look like they refer
to directory names and file names, but they don't have to.
A server can do anything it wants behind the scenes.

A typical example is to use a CGI script, but that CGI
script wouldn't be
http://www.example.org/foo/packages/my.package/my.part,
but for example
http://www.example.org/foo/packages.
With the CGI interface, the rest of the path gets put
into the ENV variable PATH_INFO, so the script then
can make sure it serves the right part from the right
package.

There are numerous other techniques that produce similar
results.

Regards,   Martin.

---

From: Andrey Shur <[email-masked]>
Date: Thu, 6 Jul 2006 10:43:35 -0700

>>would be published to the world, how then the information on the >my.package

>Regards,   Martin.

Martin,
I thought previously we agreed that not touching server code and relying solely on the client code is a reasonable goal?

Regards
- Andrey