Re: [urn] Finalizing items from IETF 83

Jonathan A Rees <> Fri, 29 June 2012 14:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 431EF21F86B1 for <>; Fri, 29 Jun 2012 07:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hk2bWY6g2yN3 for <>; Fri, 29 Jun 2012 07:00:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6FCB821F86C2 for <>; Fri, 29 Jun 2012 07:00:46 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so4750881pbc.31 for <>; Fri, 29 Jun 2012 07:00:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5L4lYXoz4YhYmTzY6tC29xTL/XEvcwCEbmJaGPnLh5U=; b=N0PR3zT93fK1YI+q/soH0hZF6lyYSfG2IaVqUzb6jhgUc+I/ZL+ccV69pn4RraLU5m t/WUOuC1Fk3S2Yg5DYAD9Zk3KVki+i6Dxq2umLYZpGBep/+zRQPy68U+HcdR6QKmA0DA BhUuCyYfx1sjABb60MKg0djv+/HMLfabOLG0S+OO9Foloi0EqytEmZbjxyGCF3cJoVvN nYm2R228DS0VjS8p+SqD1o/5cjlewWZZf4z+rPekjIAllumeBURPwAowPDjLWk6TJRcj dd4jvbuBUK7k7CK7luK1rrIR0xC0xWJPRhiQe8MJsZRWle52MRJErEjLishWEH0Ttt/Y Bz9g==
MIME-Version: 1.0
Received: by with SMTP id sm2mr7469409pbc.57.1340978445963; Fri, 29 Jun 2012 07:00:45 -0700 (PDT)
Received: by with HTTP; Fri, 29 Jun 2012 07:00:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <> <> <>
Date: Fri, 29 Jun 2012 10:00:45 -0400
X-Google-Sender-Auth: E1LuMsZHLuyjN-V1pO3pFCbvn_4
Message-ID: <>
From: Jonathan A Rees <>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Julian Reschke <>, "" <>
Subject: Re: [urn] Finalizing items from IETF 83
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jun 2012 14:00:47 -0000

I think the goal is for URIs of the form urn:x#fragid to also have
URN-like properties, just as urn:x does., i.e. name-like and
persistent. RIght? And this appears to be in conflict with the fact
that the semantics of such URIs is determined by 3986, not by the URI
scheme registration.

I offer (again) the following compromise for your consideration; I
have no dog in this race:

If those registering namespaces want to constrain the semantics of
urn: URIs with fragment identifiers, it would be possible to do so
indirectly, by constraining the possible representations yielded by
URN resolver infrastructure.  E.g. if urn:x#part1 was supposed to name
part 1 of <urn:x>, then the registration could say (or imply) that a
resolver MUST only yield representations in which #part1 names part 1.

Or perhaps it would be OK to yield some representations in which
#part1 did not name anything at all. Then you would say: A resolver
MUST NOT yield a representation in which the semantics of #part1 is
inconsistent with  urn:x#part1 being a name for (whatever). Whether
this would work in one of the many unclear aspects of fragment
identifier semantics (see ).

That is, per 3986, fragment id semantics depends on media types, so if
a spec wants to constrain fragment id semantics, its only option is to
do so indirectly, by constraining the representations to which the URN

A weakness of this approach would be differentiating between
persistent fragment identifiers and ephemeral ones. If someone gets a
representation, and discovers a fragment identifier definition inside
it, they will have no way of knowing the persistence commitment of
that fragment identifier.


On Fri, Jun 29, 2012 at 6:17 AM, "Martin J. Dürst"
<> wrote:
> On 2012/06/28 20:52, Juha Hakala wrote:
>> On 28.6.2012 13:01, Julian Reschke wrote:
>>> Namespace specifications define the namespace-specific part; nothing
>>> else. Fragment syntax and semantics are defined by RFC 3986.
>>> A spec *can* point out that the URN does not identify something from
>>> which a payload + media type can be retrieved, in which fragment
>>> identifiers are not applicable. But that's different from disallowing
>>> them.
>> OK. It should be possible to adjust the text in rfc2141bis to say that
>> there are namespaces in which fragment usage is not applicable since the
>> resources which can be identified within than namespace - say, textual
>> works as abstract entities in URN:ISTC - will not have fragments in the
>> RFC 3986 sense of the word.
> Strictly speaking, that's not true. It's perfectly possible to imagine (and
> even to set up, although that will require quite a bit of coordination) to
> have an identifier for "Much Ado about Nothing" and have fragment
> identifiers e.g. for Act I, II, III, IV, and V. These may not work with all
> resolution systems, or all representations, but that's not a problem. If a
> fragment identifier cannot be resolved, we just get the whole work. The only
> problem is when a fragment identifier leads to obviously different pieces in
> different representations (e.g. Act I in an XML representation and Act V in
> a mobi representation,...).
> All this isn't new for URNs, it's exactly the same as for content-negotiated
> HTTP resources (different languages, HTML vs. XML vs. SVG vs. JSON vs. RDF,
> just to name a few).
>> As far as I am concerned, it does no harm if the namespace registration
>> request confirms that it is possible to use fragment to augment the
>> functionality of the URNs from that particular namespace. For instance,
>> I asked a permission from the ISBN Registration Authority to use
>> fragments in the URN:ISBN namespace. Since this point will be made in
>> the namespace registration request the national ISBN agencies and other
>> ISBN users do not need to ask if fragments are allowed.
> Nobody should have to ask. If it works, you can use it. If you can't make it
> work, it's a bad idea.
>> And while some
>> examples could be given in the namespace registration request it is
>> definitely up to the URI Generic Syntax and other relevant technical
>> documents to provide the necessary details for each document format.
> Yes indeed.
> Regards,    Martin.
> _______________________________________________
> urn mailing list