Re: request for assignment of informal urn

Peter Saint-Andre - &yet <peter@andyet.net> Sat, 21 February 2015 03:14 UTC

Return-Path: <peter@andyet.net>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA821A1A60 for <urn-nid@ietfa.amsl.com>; Fri, 20 Feb 2015 19:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 6RmMttsBhNbc for <urn-nid@ietfa.amsl.com>; Fri, 20 Feb 2015 19:14:30 -0800 (PST)
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3091A1A31 for <urn-nid@apps.ietf.org>; Fri, 20 Feb 2015 19:14:29 -0800 (PST)
Received: by mail-ig0-f175.google.com with SMTP id hn18so7539236igb.2 for <urn-nid@apps.ietf.org>; Fri, 20 Feb 2015 19:14:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Rf9zObA5rrQVcL7itklirPf1obgzPClxC7XdPJ3D1zY=; b=I27iNsB8D0P2JojXwCy8JiCGiX44uJsEpK9h7VlcwrnC/iIgsnpQuksS3pCckTG+vB NbaChzO5peb8IUmlCLAMI+TimigthPfU4X/I7PxndxYH21hn3uMN6vEfX/kZ8Y/1W6Kq txma4e/MJPmqQCJr2fZg29VyrwLAL5LAO/QYO5fhhSmGLl/eHelQ75uIk+JBDpyTAr1b rbxw6SN2YclrOWQt7VhUNtMTvCBY0H+YJjnTl96k9KUKe4O/Igphhw4Fvp+8CntUuEIw Ce+NdmJ4Wk+i0VjSDgpyHLv4X124o3JCPLMcMZQ0P1rlTuREjQyVZXx70ml0gpwMXkbg Zytg==
X-Gm-Message-State: ALoCoQmEeShxaqVgrgh8q9EL351WeE8EuaXfmxO9jcpVdcLXxH4i2p9T4ejGdL8NG/Fi0Joj2eJT
X-Received: by 10.42.71.194 with SMTP id l2mr1061542icj.71.1424488469287; Fri, 20 Feb 2015 19:14:29 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id b6sm2131522igb.15.2015.02.20.19.14.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 19:14:28 -0800 (PST)
Message-ID: <54E7F813.8010201@andyet.net>
Date: Fri, 20 Feb 2015 20:14:27 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: yoshiki.sameshima.vf@hitachi-solutions.com
Subject: Re: request for assignment of informal urn
References: <XNM2$7$1$6$$4$8$2$A$5000104U54d87c3b@hitachi-solutions.com> <54E36647.4060506@andyet.net> <XNM2$7$1$6$$4$8$2$A$5000123U54e46275@hitachi-solutions.com>
In-Reply-To: <XNM2$7$1$6$$4$8$2$A$5000123U54e46275@hitachi-solutions.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/JoY7hD_bh-NPu0pxMSWFr1UxTyw>
Cc: tomohiro.misawa.rf@hitachi-solutions.com, urn-nid@apps.ietf.org, takanobu.hosoe.ju@hitachi-solutions.com
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2015 03:14:33 -0000

On 2/18/15 2:59 AM, yoshiki.sameshima.vf@hitachi-solutions.com wrote:
> Peter,
>
>> I'm confused. Why do we need a new URN namespace, given that we already
>> have a URN namespace for UUIDs and a URN namespace for ISBNs?
>
> URN is a kind of URI, and it can contain a fragment syntactically.

Are you aware that we are updating the core definition of URNs to allow 
this in a more official way? See here:

https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

(RFC 2141 does not really allow this.)

> But the rfc of urn:uuid (RFC 4122) does not describe the semantics of a fragment.
> The same is true in the rfc of urn:isbn (RFC 3187).

I think the right approach is to update those specifications.

> We also want to include an epub file name as well as an EPUBCFI fragment.

Can you show us some examples of this usage?

> This is the reason why we submit the request of our informal urn specification
> describing semantics and syntax of epub file name and EPUBCFI fragment.

Trying to squeeze new definitions of urn:uuid and urn:isbn into an 
informal namespace feels like the wrong way to do things.

Peter

>
> Best regards,
> Yoshiki Sameshima
>
>
>> On 2/9/15 2:22 AM, yoshiki.sameshima.vf@hitachi-solutions.com wrote:
>>> Dear URN NID members,
>>>
>>> This is a request for assignment of informal urn.
>>>
>>> The following is a URN Namespace Definition according to the template
>>> described in RFC 3406.
>>>
>>> Please send comments to addresses in the cc field.
>>>
>>> Best regards,
>>>
>>> Yoshiki Sameshima, Hitachi Solutions
>>>
>>>
>>> ---------------- URN Namespace Definition ----------------
>>>
>>> I. Namespace ID
>>>
>>> To be assigned.
>>>
>>>
>>> 2. Registration Information
>>>
>>> Version 1
>>> Date: 2015-02-09
>>>
>>>
>>> 3. Declared registrant of the namespace
>>>
>>> Name:		Yoshiki SAMESHIMA
>>> 		Takanobu HOSOE
>>> 		Tomohiro MISAWA
>>> Affiliation:	Hitachi Solutions, Ltd.
>>> Address:	4-12-7 Higashi-Shinagawa Shinagawa-ku, Tokyo 140-0002 Japan
>>> Contact:	Yoshiki Sameshima
>>> 		yoshiki (dot) sameshima (dot) vf (at) hitachi-solutions (dot) com
>>>
>>>
>>> 4. Declaration of structure
>>>
>>> The identifier structure is as follows:
>>>
>>> NEW-URN	= "urn:" ASSIGNED-SCHEME ":" ( CoNETS-EPUB-UUID / CoNETS-EPUB-ISBN )
>>>
>>> ; There are two types of the new scheme.
>>>
>>>
>>> ;;;
>>> ;;; First type: CoNETS EPUB UUID
>>> ;;;
>>>
>>> CoNETS-EPUB-UUID = "conets-epub-uuid:" UUID *( "/" FILE ) [ "#" EPUBCFI ]
>>> UUID = 1*(HEXDIGIT) 0*( "-" 1*(HEXDIGIT))
>>> FILE = PCHAR *PCHAR
>>>
>>> ; The first type is a combination of UUID, optionally file name and EPUBCFI.
>>> ; A bulky book or a series of books may have a single UUID, but it may consist
>>> ; of multiple epub publication files. In this case the epub file name is
>>> ; included in the URN.
>>> ; A piece of content or any location in an epub publication file is identified
>>> ; with EPUBCFI, which is a fragment identifier for epub publication, such as
>>> ; chapter, image, page, etc. EPUBCFI is specified in EPUB Canonical Fragment
>>> ; Identifier Specification. See Sec. 5.
>>> ; PCHAR is the same as RFC 3986 or its successors.
>>>
>>>
>>> ;;;
>>> ;;; Second type: CoNETS EPUB ISBN
>>> ;;;
>>>
>>> CoNETS-EPUB-ISBN = "conets-epub-isbn:" ISBN *( "/" FILE ) [ "#" EPUBCFI ]
>>> ISBN = 1*(DIGIT / ALPHA) 0*("-" 1*(DIGIT / ALPHA))
>>>
>>> ; The second type is as the same as CoNETS-EPUB-UUID except that ISBN is used
>>> ; instead of UUID. ISBN in URN can be found in RFC 3187
>>> ; 'Using International Standard Book Numbers as Uniform Resource Names.'
>>>
>>>
>>> 5. Relevant ancillary documentation
>>>
>>> Definition of EPUBCFI can be found in:
>>>       International Digital Publishing Forum,
>>>       EPUB Canonical Fragment Identifier (epubcfi) Specification
>>>       http://www.idpf.org/epub/linking/cfi/epub-cfi.html
>>>
>>>
>>> 6. Identifier uniqueness considerations
>>>
>>> The URN consists of epub publication identifier (UUID or ISBN), optionally an epub
>>> publication file and a fragment that identifies content or location in the epub
>>> file. That is, the URN points some part in the epub publication, and reassignment
>>> of the URN cannot happen.
>>>
>>>
>>> 7. Identifier persistence considerations
>>>
>>> Each time the publication is revised, the UUID/ISBN is changed, and a URN will
>>> persist in identifying a particular publication even after its lifetime.
>>>
>>> As for usability of the identifier, identifier resolution is processed locally
>>> in this version as described in Section 9, and the usability is assured as long as
>>> the publication is stored locally. Future versions of this specification may
>>> specify global repository and persistence of usability of the URN identifier.
>>>
>>>
>>> 8. Process of identifier assignment
>>>
>>> UUID is 128 bits long, and requires no central registration process. The generation
>>> process described in RFC 4122 will give a unique identifier from all other UUIDs
>>> that have been or will be assigned. ISBN is assigned from the International ISBN
>>> Agency. As for the other part of the identifier, FILE and EPUBCFI, the assignment
>>> is open.
>>
>> I'm confused. Why do we need a new URN namespace, given that we already
>> have a URN namespace for UUIDs and a URN namespace for ISBNs?
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://andyet.com/
>>