W3C home > Mailing lists > Public > www-tag@w3.org > October 2004

comments on NM mods: sec 2.4.1

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 18 Oct 2004 13:01:55 -0700
Message-Id: <8F6F27B4-2140-11D9-8A83-000393753936@gbiv.com>
Cc: www-tag@w3.org
To: noah_mendelsohn@us.ibm.com

[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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:43 UTC