Re: Review of new HTTPbis text for 303 See Other

On Jul 14, 2009, at 2:46 PM, Larry Masinter wrote:

> 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.)

Sorry if it gave offense, all the above was meant ad dicto, not ad  
hominem. And Im a Brit, so "bloody" is a friendly form of emphasis.

>
> 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.

Well, let me react to that. (This is an aside from the main topic, but  
it helps explain motivation and attitude.) True, Richard may have  
accidentally become the spokesperson here for an entire culture, which  
I regret if true, and apologize to him for having to bear the brunt of  
my frustration.) But I do feel that there seems to be what I can only  
describe as a somewhat arrogant double standard throughout the W3C  
regarding these issues of technical usage. The W3C documents use a  
number of words in VERY peculiar ways, ways which (1) do not  
correspond even remotely to their normal usage and (2) do not conform  
to the historical usage of these words even in the 'technical'  
literature out of which the W3C usages have grown, and yet every  
attempt to ask for clarification of these usages is rebuffed,  
sometimes angrily or impolitely; and there is nothing even remotely  
like a glossary available. (Contrast, say, the ISO's almost anal  
approach to giving definitions of every usage.)  My favorite example  
is "resource", of course (which was first used in this context by  
Engelbart, who meant it in close to its normal English sense), but  
"representation" is another, and "identity" (fortunately no longer in  
wide use) yet another. Seems to me that when your own technical  
audience has to use your words prefixed with 'awww:' in order to  
distinguish these deviant meanings from those used in the rest of the  
world, that there may be a slight issue here.

>
> 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.

I strongly disagree. It may be good practice to be deliberately  
agnostic about technical details, but it is never good practice to be  
deliberately obscure about the meanings of the words one is using. And  
you cannot reasonably hold two positions, along the lines of "I am  
deliberately not going to say what I mean because it does not matter"  
and "Your interpretation is wrong because that isn't what I meant".  
Which is exactly what Richard did in this email thread.

>
> 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.

Of course, but this IS in its scope. That is the whole point.

> 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.

I am not asking it to answer that question. That question is already  
answered: a URI *can* identify a person. Absolutely no doubt about  
that. What I am asking for is that the spec RECOGNIZE this and DEAL  
WITH IT. Richard told me that HTTP "does not care" what the URI  
identifies, or what counts as a representation of it. I took him at  
his word and gave him an immediate example of a resource and a  
representation of that resource, which according to what he had said,  
I was entirely able to do within the confines of the spec, since it  
DID NOT CARE about that stuff, and he rejected the example without  
comment on the grounds that it wasnt to do with computer architecture.  
Which was exactly my point. If HTTP does not care what a resource is,  
or what a representation of a resource is, then it should apply to  
examples like mine. Obviously, it does not: ergo, it DOES CARE what a  
URI identifies and what a representation is. Then the spec should say  
this, and say it clearly.

Its not enough to hide behind the defense that this is (obviously)  
just a technical spec in a technical area, and philosophy has nothing  
to do with that technical topic. That would be fine if URIs could not  
identify people and books, but they can. It might be OK if http codes  
didn't imply anything about what URIs denote, but (according to http- 
range-14) they do. I know y'all don't want to be in this semantic/ 
philosophical stew, you just want to be technologists. But the fact  
is, you are in it whether you like it or not. HTTPrange14 put you in  
it. I didn't make this stew, but I am going to go on yelling as long  
as y'all refuse to recognize that this stew exists and it is your job  
to handle it properly, or at least not poison it.  The reason why we  
can't just all assume , in a kind of collegial technophile way, that  
we are all just talking about networks, is that these very technical  
usages of words on which you yourself rely to explain the spec have  
*already* been extended to a wider usage which makes no sense when we  
are only talking about networks. URIs *can* "identify" people, and  
other "resources"  that cannot possibly have a (n awww:)  
"representation".

>
> 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.

For the purpose of the entire Web. It isn't something that can be  
closeted inside a '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.

Sure. Im not asking you or anyone else to solve age-old problems. But  
I am asking you to recognize, and say, that HTTP now has some  
interaction with semantics. Its not a very deep or complex  
interaction. IMO, it can be entirely contained in the observation that  
a 200-coded response indicates that the URI denotes (refers to) the  
resource that it identifies, and a 303 doesn't indicate that. That's  
all you need to say[[**see below for less**]]:  questions of what  
exactly is the nature of that identified resource, etc., are outside  
the scope, of course. But you are already assuming that 'the resource  
identified by the URI' makes sense, right? Because if that is  
problematic, then the whole of HTTP is problematic.

>
> 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.

Well, it does it that thing that matters has been tied to a technical  
device - a 303 code- that is specified in this 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.

I have never said that it did. I have always consistently said that  
http-range-14 is about URIs, not about resources.

> 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.

I understand about the red flag. But URI issues aren't really just  
about the semantic web. They are about the whole Web, which is slowly  
becoming semanticized. URIs convey meanings in all sorts of ways, they  
aren't purely a transfer protocol addressing mechanism any more.

[[**]]If you recall, my interaction on this thread arose from wanting  
the HTTP spec to simply say that a 303 response can be thrown  
basically on the server's whim: it needs no "I have no appropriate 200  
response to send" justification for the 303. Put another way, the  
server is not *obliged* to return a 200 response even when it does  
have a representation available that it *could* respond with. This is  
purely within the HTTP 'layer', but it is necessary to allow servers  
to respond with 303s *for semantic reasons* which may (should?) have  
absolutely nothing to do with the existence of awww:representations.  
And that is all: I would shut up immediately if that wording were to  
be used. BUt right now, the wording does have this must-send-200-if- 
possible constraint in it, which is potentially operationally  
incompatible with the http-range-14 recommendation. Ironically, it is  
so precisely because of the orthogonality you want to preserve: the  
semantics of the URI need have nothing to do with the presence or  
absence of an awww:representation. It can be determined by other,  
loftier, matters to do with denotation, whatever that is. I think it  
would be helpful if the spec could just remark that the reason for  
this responding-code freedom is because 303 codes have these semantic  
uses, or that it is generally understood (informative ref httprange14)  
that 200 codes have semantic implications which might want to be  
avoided in some cases, or the like, but I also understand your  
reluctance to include anything in a spec that might come back to bite  
you.

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

I don't want it to be about what the resource is, but it does need to  
at least recognize that the resource might not have ANY possible  
connection with any computer ever made. It needs to at least show that  
it understands that not ALL resources are just on the other side of an  
http interface, even when they are identified by an http URI.

> 	
>
> 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.

Point taken.

Pat

>
> Regards,
>
> Larry
> -- 
> http://larry.masinter.net
>
>
>
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 15 July 2009 15:34:20 UTC