Re: [urn] Finalizing items from IETF 83

Jonathan A Rees <rees@mumble.net> Fri, 29 June 2012 14:00 UTC

Return-Path: <jonathan.rees@gmail.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431EF21F86B1 for <urn@ietfa.amsl.com>; Fri, 29 Jun 2012 07:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk2bWY6g2yN3 for <urn@ietfa.amsl.com>; Fri, 29 Jun 2012 07:00:46 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB821F86C2 for <urn@ietf.org>; Fri, 29 Jun 2012 07:00:46 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so4750881pbc.31 for <urn@ietf.org>; Fri, 29 Jun 2012 07:00:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.68.229.2 with SMTP id sm2mr7469409pbc.57.1340978445963; Fri, 29 Jun 2012 07:00:45 -0700 (PDT)
Sender: jonathan.rees@gmail.com
Received: by 10.142.134.8 with HTTP; Fri, 29 Jun 2012 07:00:45 -0700 (PDT)
In-Reply-To: <4FED80D0.5000205@it.aoyama.ac.jp>
References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FEC4595.1020609@helsinki.fi> <4FED80D0.5000205@it.aoyama.ac.jp>
Date: Fri, 29 Jun 2012 10:00:45 -0400
X-Google-Sender-Auth: E1LuMsZHLuyjN-V1pO3pFCbvn_4
Message-ID: <CAGnGFM+kXhfxxU5C=xRz=621XJRc4A8f=NkiWd-+kgtv+3-KTA@mail.gmail.com>
From: Jonathan A Rees <rees@mumble.net>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <duerst@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Julian Reschke <julian.reschke@gmx.de>, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Finalizing items from IETF 83
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
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: 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
http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html ).

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

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.

Best
Jonathan

On Fri, Jun 29, 2012 at 6:17 AM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> 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
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn