W3C home > Mailing lists > Public > public-openannotation@w3.org > May 2014

non-derefencable http URIs and oa:SpecificResource quibble

From: Bob Morris <morris.bob@gmail.com>
Date: Wed, 21 May 2014 17:13:22 -0400
Message-ID: <CADUi7O5v6kArTZdYjBQ0ODMyKeBemhDzygRMqFyiDbWm03fRbw@mail.gmail.com>
To: public-openannotation <public-openannotation@w3.org>
The IETF draft [1] seems to attempt to disambiguate (at last!)  http
URI resolution and dereferencing from the http protocol by being
explicit [2] about how dereferencing must work.  What I do not read
there is that the draft asserts that an http URI  MUST be
dereferencable.  It's my understanding that nothing presently accepted
by IETF, nor anything in this draft, requires that an http URI must be
dereferencable. In our project we frequently generate
nondereferencable http URIs whose uniqueness is guaranteed by part of
it being a UUID (not a UUID urn).

If I am wrong, I'd like to know why. By this I mean "Where in a
specification document do I find the text that contradicts me?"

If I'm right, I would hope to see the OA section on SpecificResources
have the sentence
"If the Specific Resource has an HTTP URI, then the exact segment of
the Source resource that it identifies ..."
be changed to
"If the Specific Resource has a dereferencable HTTP URI, then the
exact segment .... "

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26
[2] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-2.7


Thanks
Bob
-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390


Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob@gmail.com
web: http://efg.cs.umb.edu/
web: http://wiki.filteredpush.org
http://www.cs.umb.edu/~ram
===
The content of this communication is made entirely on my
own behalf and in no way should be deemed to express
official positions of The University of Massachusetts at Boston or
Harvard University.
Received on Wednesday, 21 May 2014 21:13:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:06 UTC