RE: Review of new HTTPbis text for 303 See Other

This conversation is filling my mailbox. Some general
observations:

(Pat, your arguments are laced with ad hominem, which makes reading
the dialog unpleasant. I don't think Richard is being
silly, intellectually dishonest, bloody arrogant, or any of the
other terms you've used, please refrain.)

It's the nature of standards discussions that people speak
their point of view; doing so isn't arrogant.

It is the nature of technical specifications that it is frequently
necessary to take normal English words in particular technical
way; it is not intellectually dishonest to do so.

It is good practice for technical specifications in standards
groups to say as little as possible in order to meet the
needs of interoperability and the purpose for which the
specification is being written. 

It is not necessary or even possible for a technical specification
to answer questions that may be fundamental for applications
that are outside of its scope. It is common, reasonable,
and traditional for standards specifications to "not answer"
questions because answering the question isn't necessary
for the purpose for which the standard was written. 

It isn't necessary for the proper functioning of the web and
to accomplish interoperability of web clients and servers
to agree on how to use HTTP URIs and the HTTP protocol --
for that purpose, it isn't necessary to answer the question 
of whether a HTTP URI can identify a person.

It may be necessary to answer the question in a technical
specification for the semantic web and in the RDF
specification  -- but the answer more likely
belong in those specifications and not in the
IETF HTTP specification. 

It may be necessary for the IETF HTTP specification
be edited in a way that made it clear that it didn't
contain the answer to this question, but I'm not
sure where to draw the line of describing things
it doesn't answer.

It's easy to imagine a system in which a URI is used 
to identify a person for the purpose of that system.
But I can't see how IETF, W3C, or continued discussion
on any of our mailing lists are going to converge
any time soon on answers to the philosophical questions
that have been with us for millennia. What is it
that "Pat Hayes" identifies, anyway? Can I use
mailto:phayes@ihmc.us as a URI to identify you?
Well, that's a question outside of the "mailto:"
URI spec, I think.

Perhaps  there needs to be a better way of distinguishing
the statements "this specification does not limit the scope
of applicability" and "this specification applies in all
circumstances".

If you had some better way of phrasing it so that it would
be clear the former was meant rather than the latter, I 
think that would be helpful.

The fact that something "does matter" -- to you, to the
RDF community, to the W3C, to the world at large --
does not mean that it is appropriate to "matter" in
the context of the HTTP spec.

It is an important design principle for developing
specifications to keep specifications orthogonal: for the purposes
of the HTTP protocol, it does not matter what resources
are exactly. For the purpose of resource identification, it should
not matter what the protocol is; tying semantic web
interpretation to a particular error code in the HTTP 
protocol seems like bad design to me.

The idea that the HTTP working group should care about the
semantic web and change its specification to meet some
semantic web requirement for use of HTTP URIs in semantic
web applications  -- well, that raises several red flags
for me, that we're building specifications that are not
sufficiently orthogonal that things that *shouldn't* matter
are taken as important questions that *must* be answered.

The HTTP specification is *not* about what a "resource" is.
It *is* about how to use and implement the HTTP protocol.	

There continues to be some confusion in the discussion between
"URI" and "HTTP URI" that I find disturbing and confusing, because
I think sometimes statements about one are attributed to the
other. Not all URIs are HTTP URIs. Please try to be more careful.  

Regards,

Larry
-- 
http://larry.masinter.net

Received on Tuesday, 14 July 2009 19:47:13 UTC