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

John,

> RFC 1738 is about 99% obsolete already.  It describes general URL
> syntax

What RFC 1738 does and what it intends to achieve may be entirely two
Separate things.

RFC 1738:
This document describes the syntax and semantics for a compact string
representation for a resource available via the Internet.  These
strings are called "Uniform Resource Locators" (URLs).

RFC 3896:
A Uniform Resource Identifier (URI) provides a simple and extensible
means for identifying a resource.

The distinction there is resolution versus identification.  URL seeks to
resolve a resource and URI identifies a resource.  RDF puts this
distinction into practice.  URI is a required component of RDF and is
not required to resolve anything, nor is it expected to.  In the case of
RDF URI is merely a means of universally unique identification, as such
RDF does not use URL.

If RFC 1738 is not made obsolete by a new document it is still perfectly
viable.  RFC 3986 does not obsolete RFC 1738, but it does obsolete RFC
2396, which updates RFC 1738.  As a result RFC 1738 is still valid.

In the perspective of the WWW the distinction between URI and URL is
functionally important.  If a resource cannot be resolved using HTTP
then an error is returned.  In RDF the URI does not return errors if
nothing exists as the specified address, because resolution is
irrelevant.  In HTTP resolution is absolutely essential.  Therefore a
distinction is certainly present.

It can be said that URL is class of URI.  URI defines a syntax for
addressing resources, and URL consumes that syntax.  This is no
different than languages written with XML Schema.  XML supplies a syntax
and the XML Schema instance supplies a defined vocabulary written in and
conforming to that syntax.  This does not mean XML obsoletes the
instance language even though it can be said the entirety of the
instance language's syntax is certainly defined by XML.

As long as there exists an imperative need to resolve resources
addressed by URI the intention of URL remains necessary, and therefore
valid even if the language and examples expressed in the corresponding
document have exceed their usefulness.  If this condition does
accurately describe the condition of URL then this should provide more
motivation for revision and not less.

Thanks,

Austin Cheney, Travelocity User Experience
CISSP TS/SCI


-----Original Message-----
From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
Sent: Tuesday, January 11, 2011 5:36 PM
To: Cheney, Austin
Cc: URI
Subject: Re: Status of RFC 1738 -- 'ftp' URI scheme

Cheney, Austin scripsit:

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

RFC 1738 is about 99% obsolete already.  It describes general URL syntax
(now RFC 3986) and a variety of file schemes which were in use ehn 1738
came out: http, ftp, file, prospero, gopher, etc.  All of these now have
their own RFCs except file and afs.  Afs is actually obsolete (and may
never have been used), so file is all that remains.

The problem with file, in a nutshell, is that it has been very variously
implemented, and there's no agreement on what should be mentioned, if
anything, beyond the core file:///(path) and file://localhost/(path)
cases.

-- 
John Cowan   cowan@ccil.org   http://ccil.org/~cowan
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940

Received on Wednesday, 12 January 2011 02:29:59 UTC