Re: [Uri-review] Request for review

["Mark Baker" <[e-mail]>]

Jerry,

On 6/16/06, Jerry Dunietz <[e-mail]> wrote:
> 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!)

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

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

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

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

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

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.

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

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

Cheers,

Mark.

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