- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 18 Oct 2004 13:01:55 -0700
- To: noah_mendelsohn@us.ibm.com
- Cc: www-tag@w3.org
[woohoo, case resolved before jury selection, now back to work ...]
Sec 2.4.1:
[{NOAH>} The section URI Schemes and Representation Types discusses
the use of media types as an alternative to defining URI schemes.
2.4.1. URI Schemes and Representation Types
As discussed in URI/Resource Relationships, URI Scheme specifications
define the protocols by which scheme-specific URIs are associated
with resources. These protocols in turn determine the form in which
representations are conveyed on the Web. HTTP, for example, provides
for transmission of representations as octet streams typed using
Internet media types [RFC2046].
I don't like these suggested additions. First of all, the paragraph
referred to in section 2.2 (URI/Resource Relationships) is filled with
errors and false assumptions [more on that below]. People often confuse
the term "protocols" to mean, exclusively, network wire protocols. In
fact, any standard method of name assignment is a "protocol" in the
traditional sense of the word. Thus, the statement "These protocols
in turn determine the form ..." is incorrect. In particular, as stated
in the URI spec multiple times, it is false to assume that the scheme
name somehow determines the protocol under which interactions will
be made with resources. "http" is a name allocation mechanism based
on DNS delegation and HTTP over TCP listeners (servers). There is no
implication whatsoever that assignment of the name somehow determines
the transmission of representations. It is usually *one* way in
which such transmission could occur if such is allowed by the server,
but it is by no means the only way.
Just as it is important to reuse existing schemes whenever possible,
there are significant benefits to using media typed octet streams
for representations even in the unusual case where a new scheme and
associated protocol is to be defined. If for some reason the Oaxaca
weather were conveyed to Nadia's browser using a protocol other than
HTTP, then software to render formats such as text/xhmtl+xml and
image/png would still be usable if the new protocol supported
transmission of those types. This is an example of the principle of
orthogonal specifications (¡Z5.1)
Good practice: Reuse representation formats
New protocols created for the web SHOULD transmit representations
as octet streams typed by Internet media types.
I don't see any reason to say this if we remove the stuff about a
sequence of octets in the introduction. In any case, the advice should
be given in a section on future directions in Interaction. This applies
to the transfer protocol, not the URI scheme: some protocols are
capable of transferring representations of many different URI schemes.
When they do so, they apply their own transformation of representations
into their own model of the world, just like HTTP proxies make lots of
non-http resources look like they have HTTP representations.
One motivation behind registering a new URI scheme is to allow a
software agent to launch a particular application when retrieving
a representation. This can often be accomplished at lower expense
by dispatching instead on the type of a representation conveyed by
an existing protocol such as HTTP. Thus, when designing a new data
format, the preferred mechanism to promote its deployment on the Web
is the Internet media type. Media types also provide a means for
building new information space applications (4.6) [section 4.6],
described below.
Most of this is just rephrasing, which is fine, but it loses some of
the emphasis and reference to HTTP here is unnecessary. How about
One bad motivation behind registering a new URI scheme is to allow a
software agent to launch a particular application when retrieving
a representation. The same thing can be accomplished at lower expense
by dispatching instead on the type of the representation, thereby
allowing use of existing transfer protocols and implementations.
When designing a new data format, the preferred mechanism to promote
its deployment on the Web is the Internet media type. Media types
also provide a means for building new information applications,
as described in section 4.6.
Going back to the (unchanged) paragraph in section 2.2:
[URI] is an agreement about how the Internet community allocates
names and associates them with the resources they identify. URIs
are divided into schemes and URI Scheme specifications define the
protocols by which scheme-specific URI are associated with resources
and take on meaning. For example, the HTTP URI scheme (RFC2616) uses
DNS so that names such as http://example.com/somepath#someFrag
take on meaning by way of HTTP GET response messages from the
domain holder (or an agent they delegate to). HTTP GET is not the
only way to obtain information about a resource. A third party,
for example, might publish a document that purports to define the
meaning of a particular URI. These other sources of information
may suggest meanings for such names, but it's a local policy
decision whether those suggestions should be heeded, whereas the
result obtained through HTTP GET is, by Internet-wide agreement,
authoritative.
should be
[URI] is an agreement about how the Internet community allocates
names and associates them with the resources they identify. URIs
are divided into schemes, each defined by a scheme specification,
that define the mechanism by which scheme-specific identifiers
are associated with resources. For example, the "http" URI
scheme (RFC2616) uses DNS and TCP-based HTTP servers for the
purpose of identifier allocation and resolution. As a result,
identifiers such as "http://example.com/somepath#someFrag" often
take on meaning by the community experience of performing an HTTP
GET request on the identifier and, if given a successful response,
interpreting the response as a representation of the identified
resource. Of course, a retrieval action like GET is not the only
way to obtain information about a resource. One might also publish
a document that purports to define the meaning of a particular URI.
These other sources of information may suggest meanings for such
names, but it's a local policy decision whether those suggestions
should be heeded.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Chief Scientist, Day Software <http://www.day.com/>
Received on Monday, 18 October 2004 20:09:18 UTC