RE: [Uri-review] Request for review

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

On 6/18/06, Mark Baker <[e-mail]> wrote:
> 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

Thanks for clarifying the context of our discussion.

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

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.

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

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

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