W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Review of new HTTPbis text for 303 See Other

From: Richard Cyganiak <richard@cyganiak.de>
Date: Wed, 15 Jul 2009 03:11:54 +0200
Cc: "'Pat Hayes'" <phayes@ihmc.us>, "'Roy T. Fielding'" <fielding@gbiv.com>, "'Jonathan Rees'" <jar@creativecommons.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'HTTP Working Group'" <ietf-http-wg@w3.org>, <www-tag@w3.org>
Message-Id: <AF50EF2A-9193-47FC-92C9-70B6B7F42B04@cyganiak.de>
To: Larry Masinter <LMM@acm.org>
Thanks Larry. I wish I could talk with such clarity.

I want to take the discussion with Pat a bit further, but will do so  
off-list. (Tomorrow, Pat -- I need to mull it over a bit.)

I initially joined the thread to say this: The HTTP spec, with Roy's  
proposed new 303 text, accommodates all Semantic Web use cases I can  
think of. Including using HTTP URIs to denote people. It's good to see  
httpRange-14 slowly "trickle down" into the specs.

Cheers,
Richard


On 14 Jul 2009, at 21:46, 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.)
>
> 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 Wednesday, 15 July 2009 01:12:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:07 GMT