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

Re: 27 Jan 2004 Draft finding "Client handling of authoritative metadata" available

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 2 Feb 2004 18:48:19 -0800
To: www-tag@w3.org
Message-Id: <6CB97C8B-55F3-11D8-85A3-000393753936@gbiv.com>

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.


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 $?>
-<title>Client Handling of Authoritative Metadata</title>
+<title>Authoritative Metadata</title>
  <w3c-doctype>DRAFT TAG Finding</w3c-doctype>
@@ -55,20 +55,21 @@


-<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 
-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 
@@ -136,20 +137,26 @@


-<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 that should be discovered and corrected rather than silently

-<li>Format specifications SHOULD NOT include
-requirements for clients to override server metadata without user
+<item>Format specifications SHOULD NOT work against the architecture
+by requiring or suggesting that a recipient override sender-provided
+metadata without user consent.</item>

+<p>In all cases, user consent may be achieved in the form of 
+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 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
+state information by exchanging representations.  A representation
+consists of two parts:</p>

  <item>Representation data:
@@ -235,31 +241,31 @@

-<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 
+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 
+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 
  where X is a short string such as "text/html" or "image/png". The <loc
-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>
-<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>
-<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 
+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>


@@ -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
+user.  Consent does not necessarily imply that the user is interrupted
+and must select from one choice or another.  User consent may be 
+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 
+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>

  <div2 id="self-describing">
  <head>Self-describing data and Risk of Inconsistency</head>
@@ -432,7 +444,7 @@
  <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>
Received on Monday, 2 February 2004 21:48:01 UTC

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