Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

ht@inf.ed.ac.uk (Henry S. Thompson) Thu, 05 June 2014 12:48 UTC

Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5691A1A00D7 for <urn@ietfa.amsl.com>; Thu, 5 Jun 2014 05:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.953
X-Spam-Level:
X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAUKR6_W97oT for <urn@ietfa.amsl.com>; Thu, 5 Jun 2014 05:48:35 -0700 (PDT)
Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id D3D4D1A00D4 for <urn@ietf.org>; Thu, 5 Jun 2014 05:48:34 -0700 (PDT)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s55Cm6WD011959; Thu, 5 Jun 2014 13:48:12 +0100 (BST)
Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s55Cm4xT027609; Thu, 5 Jun 2014 13:48:04 +0100
Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s55Cm4IQ013404; Thu, 5 Jun 2014 13:48:04 +0100
Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s55Cm4jL013400; Thu, 5 Jun 2014 13:48:04 +0100
X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: John C Klensin <john-ietf@jck.com>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <f5b38fsh3dx.fsf@troutbeck.inf.ed.ac.uk>
From: ht@inf.ed.ac.uk
Date: Thu, 05 Jun 2014 13:48:04 +0100
In-Reply-To: <f5b38fsh3dx.fsf@troutbeck.inf.ed.ac.uk> (Henry S. Thompson's message of "Thu\, 29 May 2014 18\:59\:54 +0100")
Message-ID: <f5br433a5ff.fsf@troutbeck.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/3eQEn3-dlP3AgNq1iGvzE8pFoLQ
Cc: urn@ietf.org
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 12:48:38 -0000

I wrote:

> Let's take the e-book example (I'm using a DOI, because
> I happen to remember where to find the resolver for them, but the
> point would be the same for any URN->http:URI resolver today):  The
> following _both_ identify the main body of an editorial in the journal
> _Nature_ of 28 May 2014:
>
>  doi:10.1038/509534a#article
>  http://dx.doi.org/10.1038/509534a#article

So I was wrong to use the key term of art 'identify' above.  Somewhat
to my surprise, it turns out that in _neither_ case do we know what
the URI identifies, for different but related reasons in the two
cases.

Wrt the first case, as far as I can tell there _are_ no resolvers
available other than ones which translate at source into the second
case.

Furthermore, I can't find anywhere in DOI documentation any discussion
of an intended semantics for fragments.

Wrt this, and the second case, 3986 tells us that the ('secondary')
resource identified by a URI including a hash is

  "defined by the set of representations that might result from a
   retrieval action on the primary resource.  The fragment's format
   and resolution is therefore dependent on the media type [RFC2046]
   of a potentially retrieved representation, even though such a
   retrieval is only performed if the URI is dereferenced."
    http://tools.ietf.org/html/rfc3986#section-3.5

All attempts at retrieval wrt "http://dx.doi.org/10.1038/509534a",
however, result in a 303 response code, which means, _inter alia_,
that the representation retrievable from the supplied redirection is
_not_ a representation of the primary resource.

The relevance of this to the original question ("Does 3986
unacceptably constrain URN use?") remains to be explained.

I think, at least wrt fragments, the answer is "no", but I'll hold off
on trying to explain that until I hear more about what the
_requirements_ on fragments are that are behind the stated belief in
the current discussion that the answer is "yes".

ht

-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]