RE: [Uri-review] Request for review

[Andrey Shur <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Mark Baker
Sent: Thursday, June 29, 2006 7:41 AM
To: Jerry Dunietz
Cc: Martin Duerst; Andrey Shur; John Calhoon (LCA); [e-mail]; TedHardie; [e-mail]; Gregg Brown
Subject: Re: [Uri-review] Request for review

Jerry,

On 6/23/06, Jerry Dunietz <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/uri-review