W3C home > Mailing lists > Public > uri@w3.org > January 2011

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

From: Cheney, Austin <Austin.Cheney@travelocity.com>
Date: Wed, 12 Jan 2011 07:38:35 -0600
To: URI <uri@w3.org>
Message-ID: <9FB4E1C2C67D214BAF184CE12F7DF4DB29139D22E0@SGTULMMP005.Global.ad.sabre.com>
> A *generic* document that describes URLs isn't needed.

I disagree.  I find a functional difference between accessing a resource
and merely addressing a resource to be important.  Consider the
functional differences of addressing between RDF and HTTP I mentioned in
my first email.  If a URI is not treated like a URL in HTTP an error
code is returned.  If a URL is treated like a URI in RDF the entirely
technology breaks.  If this nature were solely confined to HTTP only
your point would be more than valid.

> URLs are URIs. RFC 3986 defines the syntax and various operations
> (like encoding, various types of comparisons, or resolution of
> relative references).

I entirely agree, and have already gone over this.  See my allusion
about XML versus XML Schema instances.

> The only aspect of a *concrete* URL that is not described by RFC 3986
> is the actual syntax and semantics of the given scheme.

No, RFC 3986 is pretty clear about differentiated intention.  Intention
is important to every technology specification and when ignored security
abuses arise.

> That the standards track classification system is to coarse-grained
> when an old RFC does too many things at once is a known issue and
> entirely orthogonal :-).

It is not orthogonal.  It was commonly agreed that my position was
lacking precision and was generally confused about the nature of this
conversation.  Is my position confused and lacking precision or is to
vested in a coarse-grained system too precisely?

Either my position is valid or invalid, but it is not lacking precision
and at the same time too precise.

As long as there exists a mandatory functional requirement that a class
of URI return resources at the specified address the intention of URL,
and thus RFC 1738 remains valid.  If then RFC 1738 remains valid, and
its language and its examples are out dated then the only responsible
course of action is to submit an internet draft with revised language.

There is precedent for this behavior.  Consider the replacement of RFC
2821 with RFC 5321.  Clearly email remains a valid technology and has
not changed how it operates from 2001 to 2008, but when the language
falls out of date it is updated to keep the technology current.

The intention of RFC 1738 is extremely important for operation of
current technologies, such as those examples mentioned in the document.
More important to an updated document is the potential future
compatibility to emerging technologies where returning a resource at the
of an address is no less important than how that scheme of addressing is
specified as a syntax.  If this not true then what is the point of the
current effort to achieve a standard for addressing media fragments?

Thanks,

Austin Cheney, Travelocity User Experience
CISSP TS/SCI
Received on Wednesday, 12 January 2011 14:56:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC