Re: request for assignment of informal urn

<yoshiki.sameshima.vf@hitachi-solutions.com> Wed, 18 February 2015 09:59 UTC

Return-Path: <yoshiki.sameshima.vf@hitachi-solutions.com>
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 ABC341A870E for <urn-nid@ietfa.amsl.com>; Wed, 18 Feb 2015 01:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.108
X-Spam-Level: **
X-Spam-Status: No, score=2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no
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 C1TNN7YtMugF for <urn-nid@ietfa.amsl.com>; Wed, 18 Feb 2015 01:59:28 -0800 (PST)
Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id D346E1A86F1 for <urn-nid@apps.ietf.org>; Wed, 18 Feb 2015 01:59:27 -0800 (PST)
Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 7F08A37AC2; Wed, 18 Feb 2015 18:59:26 +0900 (JST)
Received: from mfilter06.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id t1I9xQoL025929; Wed, 18 Feb 2015 18:59:26 +0900
Received: from vshuts01.hitachi.co.jp (vshuts01.hitachi.co.jp [10.201.6.83]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t1I9xPhb021820; Wed, 18 Feb 2015 18:59:26 +0900
Received: from gxml13a.ad.clb.hitachi.co.jp (unknown [158.213.157.129]) by vshuts01.hitachi.co.jp (Postfix) with ESMTP id 16E5E2F003E; Wed, 18 Feb 2015 18:59:25 +0900 (JST)
Received: from [127.0.0.1] by gxml13a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 71I92NOLV00002110; Wed, 18 Feb 2015 18:59:25 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <XNM2$7$1$6$$4$8$2$A$5000123U54e46275@hitachi-solutions.com>
Content-Type: text/plain; charset=us-ascii
To: <peter@andyet.net>
From: <yoshiki.sameshima.vf@hitachi-solutions.com>
Date: Wed, 18 Feb 2015 18:59:17 +0900
References: <XNM2$7$1$6$$4$8$2$A$5000104U54d87c3b@hitachi-solutions.com> <54E36647.4060506@andyet.net>
Priority: normal
Importance: normal
Subject: =?ISO-2022-JP?B?UmU6IHJlcXVlc3QgZm9yIGFzc2lnbm1l?= =?ISO-2022-JP?B?bnQgb2YgaW5mb3JtYWwgdXJu?=
X400-Content-Identifier: X54E4627500000M
X400-MTS-Identifier: [/C=JP/ADMD=GMGROUP/PRMD=GMGROUP/;mta1415021818591741E]
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/Q7ZIAdo0fx4Cevo592-pZ40w8hc>
Cc: tomohiro.misawa.rf@hitachi-solutions.com, urn-nid@apps.ietf.org, yoshiki.sameshima.vf@hitachi-solutions.com, 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: Wed, 18 Feb 2015 09:59:30 -0000

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.
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).
We also want to include an epub file name as well as an EPUBCFI fragment.

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.

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/
>