- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 2 Feb 2004 18:48:19 -0800
- To: www-tag@w3.org
The new draft is much better, though I still see many areas for improvement of the rationale and wording. Here are my suggested changes in patch form. ....Roy Index: mime-respect.xml =================================================================== RCS file: /w3ccvs/WWW/2001/tag/doc/mime-respect.xml,v retrieving revision 1.40 diff -u -r1.40 mime-respect.xml --- mime-respect.xml 27 Jan 2004 19:58:49 -0000 1.40 +++ mime-respect.xml 3 Feb 2004 02:41:09 -0000 @@ -12,7 +12,7 @@ <spec w3c-doctype='other'> <?CVS $Id: mime-respect.xml,v 1.40 2004/01/27 19:58:49 ijacobs Exp $?> <header> -<title>Client Handling of Authoritative Metadata</title> +<title>Authoritative Metadata</title> <w3c-designation>&http-ident;-&iso6.doc.date;</w3c-designation> <w3c-doctype>DRAFT TAG Finding</w3c-doctype> <pubdate><day>&draft.day;</day> @@ -55,20 +55,21 @@ <abstract> -<p>The architecture of the Web depends on applications having a shared +<p>Web architecture depends on applications having a shared understanding of the messages exchanged between agents (for example, clients, servers, and intermediaries) and a shared expectation of how the -payload of the message -- a representation -- will be interpreted by -the recipient. The Web architecture uses representation metadata to -indicate the sender's intentions to the recipient whenever the -protocols used for communication allow such metadata to be -communicated. In particular, dispatching and security-related +payload of a message -- a representation -- will be interpreted by +the recipient. The Web architecture uses representation metadata, when +supported by the commuinication protocol, to indicate the sender's +intentions to the recipient. +In particular, dispatching and security-related decisions regarding the processing of a message are often based on values provided in representation metadata fields, such as the "Content-Type" field of HTTP and MIME. In this finding, we review the architectural design choice that metadata provided by a sender -be authoritative. We also examine why client behavior that -misrepresents the user or representation provider is harmful. +be authoritative. We also examine why recipient behavior that +misrepresents information provided by the sender can be harmful +if it is done without consent from the user. Finally, we consider how specification authors should incorporate these points into their work.</p> </abstract> @@ -136,20 +137,26 @@ <olist> -<item>A representation provider is the authoritative source of -representation metadata, including the Internet media type.</item> +<item>Representation metadata, when provided by the sender of a +representation, is authoritative in defining the nature of the +representation being sent.</item> <item>It is an error for an agent to ignore or override authoritative metadata without the consent of the party the agent represents.</item> <item>Inconsistency between representation data and metadata is an -error.</item> +error that should be discovered and corrected rather than silently +ignored.</item> -<li>Format specifications SHOULD NOT include -requirements for clients to override server metadata without user -consent.</li> +<item>Format specifications SHOULD NOT work against the architecture +by requiring or suggesting that a recipient override sender-provided +metadata without user consent.</item> </olist> +<p>In all cases, user consent may be achieved in the form of pre-selected +configuration options, modes, or selectable user inteface toggles, +with appropriate reporting to the user when an exception is made.</p> + <p><loc href="#scenarios">Section 2</loc> presents scenarios where these principles/points have been ignored and poses the question of what has been ignored and by whom. <loc href="#auth-metadata">Section @@ -215,15 +222,14 @@ </div1> <div1 id="auth-metadata"> -<head>Why the representation provider is the +<head>Why the sender is the authoritative source of representation metadata</head> <p>Successful communication between two parties using a piece of information relies on shared understanding. In the Web architecture, agents identify resources with URIs and they communicate resource -state information by exchanging representations. A representation of -resource state is an octet sequence that consists logically of two -parts:</p> +state information by exchanging representations. A representation +consists of two parts:</p> <olist> <item>Representation data: @@ -235,31 +241,31 @@ </item> </olist> -<p>Arbitrary numbers of independent parties can use a URI identify and +<p>Independent parties can use a URI to identify and communicate about a Web resource. To make it possible for these parties to interpret representations of the same resource in a consistent manner (according to a common set of specifications), the -design choice for the Web is that the representation provider is the +design choice for the Web is that the sender is the authoritative source of representation metadata. Thus, if the -representation provider asserts (through protocols) that "the +sender asserts (through protocols) that "the following representation data has the Internet media type text/html", -that assertion is authoritative. In the HTTP/1.1 protocol, the -"Content-Type" header field is used to communicate an Internet Media type.</p> +that assertion is authoritative.</p> <p>Separating representation metadata from data to guide processing -provides a number of benefits, including improved efficiency. For -instance, when a representation provider sends XML data and proper -metadata, a recipient can determine the media type after rapid -inspection of a short string. It is considerably more expensive in -processing time to start up an XML parser to guess the media type.</p> +provides a number of benefits, including improved efficiency. It is far +easier to dispatch behavior on the basis of inspecting a short string +than it is to invoke a generic document parser and try to divine its +purpose by inspecting the data itself, even if such a thing were possible +given that single data format (e.g., plain text) can support a +multitude of media types.</p> <div2 id="data-interpretation"> <head>Interpretation of Representation Data</head> -<p>An Internet media type asserts "this representation data is X" +<p>An Internet media type asserts "this data is in a format defined by X" where X is a short string such as "text/html" or "image/png". The <loc href="http://www.iana.org/assignments/media-types/index.html">IANA -media type registry</loc>) maps these short strings to data format +media type registry</loc> maps these short strings to data format specifications (e.g., XHTML, CSS, PNG, XLink, RDF/XML, etc.) via intermediate media type registrations. For instance, in the IANA registry, the content type "text/html" is associated with <bibref @@ -269,24 +275,19 @@ The text/html media type is now defined by W3C Recommendations; the latest published version is [HTML401].</div> -<p>Once an agent knows how the representation provider has identified -the representation data, the agent may process it in a number of ways. -For instance, if the representation provider identifies representation -data as having Internet media type "text/html", a recipient might, -depending on application context:</p> - -<ulist> -<item>Render the HTML content in a graphical user agent.</item> -<item>Check the validity of the markup.</item> -<item>Check for broken links.</item> -<item>Spell check the document</item> -<item>Render the HTML as synthesized speech.</item> -<item>Transform the HTML into some other data format.</item> -</ulist> - -<p>Note that some of these applications may rely on the fact that the -representation data really is HTML, while others (e.g., a spell -checker) may not.</p> +<p>Representation metadata often defines the default behavior for a +receiving agent processing the representation data, establishing an +expectation between the sender and the recipient that is key to +correctly interpreting the communication. For example, a recipient +may be expected to render the same representation data as a graphic +image when labelled as "image/svg+xml" that it would otherwise render +as a pretty-printed XML element tree when labelled as "application/xml". +It is impossible to recognize such a distinction by inspecting the +data itself. Precisely how the recipient will process the data is +not defined by the metadata; instead, the metadata indicates the +sender's intentions and allows the designer (or user configuration) +of the receiving agent to correctly interpret those intentions +according to the desires of its own user.</p> </div2> @@ -374,8 +375,19 @@ <p>Recipients SHOULD detect inconsistencies between representation data and metadata but MUST NOT resolve them without the consent of the -user (e.g., by securing permission or at least providing -notification).</p> +user. Consent does not necessarily imply that the user is interrupted +and must select from one choice or another. User consent may be achieved +in the form of pre-selected configuration options, modes, or selectable +user inteface toggles, with appropriate reporting to the user when an +exception is made. For example, a small "bug" icon might be used on a +graphical browser UI to indicate that an error has been overridden, +and further act as a button through which a curious user might inspect +the error or reverse the override. Naturally, such interfaces are unique +to each type of receiving agent and it is beyond the scope of this +finding to anticipate the ways in which interface designers might +obtain user feedback.</p> + +</p> <div2 id="self-describing"> <head>Self-describing data and Risk of Inconsistency</head> @@ -432,7 +444,7 @@ <ulist> <item>Remain silent when forced to guess, or</item> <item>Inform the user that a guess has been made, or</item> -<item>Allow the user to direct the client's processing of the +<item>Allow the user to direct the agent's processing of the representation data (e.g., by invoking a particular handler or saving to disk).</item> </ulist>
Received on Monday, 2 February 2004 21:48:01 UTC