Push back on the resource/representation introduction in HTTPbis?

On several occasions the TAG has discussed our concerns about the way
in which the the HTTP specs (both 2616 and now HTTPbis) introduce the
basic semantics of URIs and URI usage in HTTP, see most recently our
recent f2f minutes [1].  We have also discussed revising the way in
which we use that language ourselves in AWWW, and I floated a trial
balloon in that regard late last spring [2].

Now that it's nearly too late (HTTPbis in in WG Last Call at the
IETF), I've finally taken a stab at framing a possible TAG request
about this in a positive form.  What do people think about the prose
below as a replacement for Section 2 and the start of Section 3 in
httpbis-p2-semantics [3]?

What I'm trying to do (with some welcome help from Jonathan Rees) in
this rewrite is to avoid the problems we have noted with some aspects
of the existing language, while keeping the goal of providing a
helpful, but not overly complicated, introduction to the motivating
background for the HTTP protocol, while never-the-less providing the
necessary technically precise definitions of key terms used throughout
the specs.

I'm at least as interested in strategic feedback at this point as
editorial:  the pressing issue for the TAG right now is whether to
feed _something_ like this into the IETF HTTP WG, or to accept that
we've missed our chance this time around.

ht

[1] http://www.w3.org/2001/tag/2013/09/30-minutes.html#item02 [at the end]
[2] http://lists.w3.org/Archives/Public/www-tag/2013Jun/0023.html
[3] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-2
-----------------
2. Targets

Origin servers make content and services available to clients via
Uniform Resource Identifiers (URIs---see section 2.7 of [Part1]).
Clients use appropriate URIs in requests in order to access (or
update) a server's content or interact with its services.

We use the word "resource" in these specifications to refer to the
whole range of content and services which a server may provide.

In the case of a given request, we call the resource that is accessed
the "target resource" of the request (or "target" for short), and the
URI as contained in the request the "target URI".  How those
responsible for configuring an origin server determine what URIs can
be used to give access to what resources, or how clients might learn
or check this independently of HTTP requests, is out of scope for
these specifications.

We call the relationship between a request and the actions to be
performed and/or the response to be generated when processing it the
"request semantics", the primary determinants of which are the request
method, the target resource and the state of the server at the time
the request is handled.  Sections 4 through 7 below specify the
details of this relationship.

The utility of individual servers and the resources they give access
to, to say nothing of the value of the HTTP-mediated Web as a whole,
depend in large part on the consistency of the relationship between
URIs, request methods and their joint semantics, both across
similar-but-different URIs available from the same server, and over
time for the same URI.  Such matters are, however, out of scope for
this specification.

 [Does this para. really belong at this introductory level????]

  When a client constructs an HTTP/1.1 request message, it sends the
  target URI in one of various forms, as defined in (Section 5.3 of
  [Part1]).  When a request is received, the server reconstructs an
  effective request URI for the target resource (Section 5.5 of
  [Part1]).

One design goal of HTTP is to separate resource access from request
semantics, which is made possible by vesting the request semantics in
the request method (Section 4) and a few request- modifying header
fields (Section 5).  Resource owners SHOULD NOT include request
semantics within the URI that accesses it, such as by specifying an
action to invoke within the path or query components of the effective
request URI, unless those semantics are disabled when they are
inconsistent with the request method.

3. Representations

HTTP allows an origin server to give access to a broad range of types
of resources.  It does so via a uniform interface which supports
interaction with resources only through the exchange of messages.

In the exchange of request and response involved in accessing a
given resource, the relationship between message contents and the
accessed resource can be simple, as for example in the case of the
response message to a GET request whose target resource is a piece
of static clip art, or it may be very complex, as in the case of a
POST request to a ticket booking service.  In what follows below we
will use the word "representation" to generalize over all these
cases: a "representation" is the encoding within a message of
information intended to reflect the current state or output of a
resource, and/or (at least in part) affect its future state or
actions.  We further articulate message contents into a set of
"representation metadata" and a potentially unbounded stream of
"representation data".

Thus in the simple and common case of a GET request whose target URI
gives access to web content such as a picture, video or web page, a
cooperative server will ensure that the response message, using a
format that can be readily communicated via the protocol, enables
the presentation to the user of that content, whereas in the case of
a booking service a POST request will contain the information
necessary to enable a ticket to be issued.

-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Tuesday, 5 November 2013 15:41:53 UTC