RE: Status of RFC 1738 -- 'ftp' URI scheme

I have been watching this discussion about retiring RFC 1738.  It seems
there are some hurdles preventing that action, such as the absence of an
RFC for the "file" scheme and whether or not other dependent
technologies are still in use.  In my view all these blocking conditions
are most easily dismissed if the RFC is not retired, but is instead
obsolete by a replacing document in the standards track.

If I am wrong so far please stop reading the remainder of this reply and
please let me know.

Something I have been wanting to do for little more than year after
reflecting upon a 7 month old conversation I had with Dr. Dürst in this
very list is to create a URI scheme for referencing data in SMTP.  The
objective of such a task to provide an addressable means of referencing
documents, document fragments, or document collections resident in
repositories reserved for transfer or receipt via SMTP distribution
using a request means of transfer opposed to a push transfer like SMTP.

I believe a document that supports the completion of such a scheme could
adequately represent a subset of URI, RFC3896/3897, and achieve the
objectives of RFC 1738 if written broadly as a functional syntax opposed
to a scheme specific vocabulary.  More specifically, provide a document
that defines a syntax for universal addressing, as in the spirit of
URI/IRI, and confine its functional approach to referencing documents
using a pull type application protocol.  The constraints are necessary,
because such a task is not meant to parallel or replace URI.  I believe
this task has merit because there is no scheme available for addressing
documents in an email repository and RFC 1738 does not provide a means
to accomplish such a scheme even though the RFC 3896/3897 documents
provide a sufficient syntax and are sufficiently scheme agnostic.

>From a technology perspective the prior described task would differ from
URL in how a hierarchy of data fragments can be referenced from a single
instance of addressing.  RFC 3986 provides a syntax to achieve the
desired complexity, but does not supply definitions on how to use those
conventions to achieve such an objective where the usage of the
constraints is uniform and standard to achieve the necessary complexity
without conflict to compatibility and reuse.

In summary I think the discussion at hand makes for a community
awareness of URL as an aging technology.  The relationship between URL
and URI is not replacement and is something more comparable to
inheritance.  URL is intended to reference a resource, while URI is
intended to provide a syntax for addressing without regard
for function.  I would like to see RFC 1738 obsolete by a newer document
that accounts for this relationship and achieves new objectives not
previously considered when RFC 1738.

If these conclusion are in error please let me know.  If writing a new
standards track document for resolving resources using a pull type
protocol is a bad idea please let me know.


Austin Cheney, Travelocity User Experience

Received on Tuesday, 11 January 2011 20:51:59 UTC