Re: URI schemes and media types (was Re: Review of Oct. 27 webarch

Hi Noah,

On Thu, Nov 06, 2003 at 07:00:30PM -0500, wrote:
> Mark Baker proposes:
> > What about this as a replacement?
> > 
> > "If an agent encounters an unknown URI scheme, it is
> > unable to dereference the URI to retrieve a
> > representation.  Media types, even unrecognized ones,
> > are encountered *after* a representation has been
> > retrieved.  This provides the agent the opportunity to
> > save the representation to disk, to ask the user (if
> > any) to choose an application to process the
> > representation, or in general, simply to use
> > information available in the representation to make
> > forward progress."
> > 
> > Mark
> Do you see this as consistent with [1]:
> "Although many URI schemes are named after protocols, this does not imply 
> that use of such a URI will result in access to the resource via the named 
> protocol. Even when an agent uses a URI to retrieve a representation, that 
> access might be through gateways, proxies, caches, and name resolution 
> services that are independent of the protocol associated with the scheme 
> name, and the resolution of some URIs may require the use of more than one 
> protocol (e.g., both DNS and HTTP are typically used to access an "http" 
> URI's origin server when a representation isn't found in a local cache)."?

Slightly inconsistent, yes.  My paragraph doesn't accomodate the
possibility that the agent can delegate dereferencing.  If it did, I
think that would address the inconsistency that I believe you're
referring to; the agent itself may not support FTP/ftp:, but it could
ask a trusted HTTP proxy to provide that service, e.g.

  GET HTTP/1.1

> FWIW, I find the paragraph quoted immediately above a bit vague.  Is it or 
> is it not OK per WebArch for me to implement the http: scheme using the 
> FTP transport protocol?  The above seems to imply:  sort of yes, insofar 
> as you could imagine your FTP store as some sort of repository for 
> representations of resources that happened to be named with the http 
> scheme, but sort of no insofar as there is a specific non-FTP "protocol 
> associated with the [http] scheme name".   So, I think the arch document 
> might benefit from a little clarification in this area. 

I agree, but I expect we'd quickly hit the httpRange-14 impass.

I also agree that your other questions should be answered in the
document as well.  I have my own views on all of them; I'll save them
for later.

Mark Baker.   Ottawa, Ontario, CANADA.

Received on Thursday, 6 November 2003 23:00:43 UTC