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

[Fwd: Re: Comments on draft "baseline" httprange-14 replacement]

From: David Booth <david@dbooth.org>
Date: Tue, 28 Feb 2012 10:04:00 -0500
To: www-tag <www-tag@w3.org>
Cc: Jonathan A Rees <rees@mumble.net>
Message-ID: <1330441440.10438.45794.camel@dbooth-laptop>
[These comments were originally sent on 21-Feb-2012 but for some reason
the message did not appear in the archives, perhaps due to the
attachments.  Hence I am resending this message, but with the
attachments posted here: 
http://dbooth.org/2012/awwsw/uddp-2012-02-21.doc (with changes incorporated)
http://dbooth.org/2012/awwsw/uddp-2012-02-21-changes.doc (showing all changes)
I also re-generated the version that shows all changes, by comparing
against the original version, because the "track changes" feature
apparently did not work entirely correctly.]

-------- Forwarded Message --------
From: David Booth <david@dbooth.org>
To: Jonathan A Rees <rees@mumble.net>
Cc: www-tag <www-tag@w3.org>
Subject: Re: Comments on draft "baseline" httprange-14 replacement
Date: Tue, 21 Feb 2012 03:24:43 -0500

Hi Jonathan,

Attached are two versions of the "baseline" document
containing my suggested changes.  They are in MS Word format (produced
by OpenOffice).  One has "track changes" turned on, and shows
(hopefully) all the changes.  The other simply shows the document as a
whole with the changes incorporated.  (The formatting is a little screwy
in this latter version because of "holes" left by deleted portions.)

The changes that I am suggesting are of two kinds: (1) substantive
changes to better align this "baseline" document with the intent
of the existing httpRange-14 resolution and background specifications;
and (2) editorial changes to improve the readability and clarity 
of the document.  

I included them both at once: (a) because it was easier for me to
make a single pass through the document, improving everything
that I thought I could improve; and (b) because I thought it would
be more helpful to others to see how the document as a whole
would read with these changes.

However, if you felt more comfortable doing so, you could just 
incorporate the substantive changes now and leave the 
editorial changes for me to make as a change proposal,
in an additional step.

Some further explanations that were too long
to embed in the attached documents:

1. This document is partially written as though it is applicable
to URIs in general, but it really only gets into the necessary
detail to cover http: (and https:) URIs.  I think it would
be better to only attempt to cover http: (and https:) URIs,
since those are the ones that the httpRange-14 issue bears on.

2. The title, "Understanding URI Hosting Practice as Support
for Documentation Discovery" is too vague.  It sounds like it
would apply to *any* kind of documentation whatsoever, when
really it is only about URI definitions.  

3. The current draft seems to be unnecessarily obsessed with
differentiating statements conveyed under this protocol with
truth in real life, as though such statements would otherwise
be taken as truth.  This shows up in a number of places,
such as: (a) in its concern about the term "authoritative"
(as though "authoritative" imparts any authority beyond this
specification); (b) in its use of the term "URI documentation"
instead of "URI definition" (as though "definition" would imply
too much); (c) in its use of the qualifying word "nominal",
as in "nominal URI documentation carrier" (as though there is a
need to distinguish the URI definition conveyed by this protocol
from the *real* URI definition); and (d) in its mention that
"URI documentation may not be correct".

4. The abstract includes the disclaimer: 'There is no
intention that the set of specified circumstances should be
either "authoritative" or exclusive of other sources of URI
documentation.'  I think this is unhelpful, counterproductive,
and should be deleted, for these reasons:

 - A protocol specification can and *should* state
what bits are to be considered authoritative
_under_that_protocol_.  The fact that something is authoritative
_under_a_particular_protocol_ does not automatically make it
"authoritative" in any legal or other sense.  Defining something
as "authoritative" under a particular protocol is simply a means
of describing an algorithm for choosing between potentially
conflicting pieces of information.  If it is useful for a
protocol to describe an algorithm in terms of authoritative
versus non-authoritative information, then that is fine to do.
For example, the HTTP 1.1 specification defines "authoritative"
entity headers.  Nobody confuses that as conveying any sort
of legal or other authority beyond the scope of that protocol

 - If a protocol specification gains such uptake in the
community that conformance eventually becomes a legally binding
social expectation, then that is a social and legal matter that
falls entirely outside the scope of the specification itself.
The specification itself should not attempt to make claims
one way or the other about such matters.

 - It sounds disparaging to the specification itself, to
include such a disclaimer.  By comparison, the HTTP 1.1
specification does not say that "There is no intention that
this protocol be "authoritative" or exclusive of other transport

 - The point of recommending a particular protocol is that we
*want* the community to rally around one particular protocol
(which may itself involve a wide range of options), rather
than having the chaos of multiple conflicting protocols.
The disclaimer undermines this purpose.

 - This "baseline" draft is supposed to convey the intent of the
current httpRange-14 decision, but the httpRange-14 decision
has nothing like this disclaimer.  It appears to originate
from personal opinion.

BTW, I am near MIT, if you'd like to get together to work on this in


David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Tuesday, 28 February 2012 15:04:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:13 UTC