- 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