Re: request for assignment of informal urn

<yoshiki.sameshima.vf@hitachi-solutions.com> Wed, 18 February 2015 10:08 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 55C5A1A8728 for <urn-nid@ietfa.amsl.com>; Wed, 18 Feb 2015 02:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.508
X-Spam-Level: *
X-Spam-Status: No, score=1.508 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, 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 QA6ltYZ8M-27 for <urn-nid@ietfa.amsl.com>; Wed, 18 Feb 2015 02:08:37 -0800 (PST)
Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC031A039F for <urn-nid@apps.ietf.org>; Wed, 18 Feb 2015 02:08:37 -0800 (PST)
Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id D6B3D37AC2; Wed, 18 Feb 2015 19:08:36 +0900 (JST)
Received: from mfilter04.hitachi.co.jp by mlsv3.hitachi.co.jp (8.13.1/8.13.1) id t1IA8aQ0028673; Wed, 18 Feb 2015 19:08:36 +0900
Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t1IA8Z6G014796; Wed, 18 Feb 2015 19:08:36 +0900
Received: from gxml13a.ad.clb.hitachi.co.jp (unknown [158.213.157.129]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 72702140046; Wed, 18 Feb 2015 19:08:35 +0900 (JST)
Received: from [127.0.0.1] by gxml13a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 71IA08ZQ8000013B0; Wed, 18 Feb 2015 19:08:35 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <XNM2$7$1$6$$4$8$2$A$5000124U54e4649d@hitachi-solutions.com>
Content-Type: text/plain; charset=us-ascii
To: <worley@ariadne.com>
From: <yoshiki.sameshima.vf@hitachi-solutions.com>
Date: Wed, 18 Feb 2015 19:08:29 +0900
References: <XNM2$7$1$6$$4$8$2$A$5000104U54d87c3b@hitachi-solutions.com> <87a90dqk0t.fsf@hobgoblin.ariadne.com>
Priority: normal
Importance: normal
Subject: =?ISO-2022-JP?B?UmU6IHJlcXVlc3QgZm9yIGFzc2lnbm1l?= =?ISO-2022-JP?B?bnQgb2YgaW5mb3JtYWwgdXJu?=
X400-Content-Identifier: X54E4649D00000M
X400-MTS-Identifier: [/C=JP/ADMD=GMGROUP/PRMD=GMGROUP/;mta1415021819082948U]
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/Lh2mzAaRSnhgRKsSaN0-_MnqWQ4>
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 10:08:39 -0000

Dale,

Thank you for your comments.

> > CoNETS-EPUB-UUID = "conets-epub-uuid:" UUID *( "/" FILE ) [ "#" EPUBCFI ]
> In the namespace, all URNs have the format
> urn-NNN:conets-epub-SOMETHING:SOMETHING.  It seems to me that
> "conets-epub-" is redundant and only functions to make the URN longer,
> and it might be desirable to remove that from the specification.

We have removed the redundant part.


> > UUID = 1*(HEXDIGIT) 0*( "-" 1*(HEXDIGIT))
> > FILE = PCHAR *PCHAR
> Why not say "FILE = 1*PCHAR"?

You are correct.

> But I can anticipate problems with "[ "#" EPUBCFI ]".  That can't be
> part of the URN itself, as we haven't defined "fragment identifiers" for
> use with URNs.  I think people would be happier if you omitted that from
> the syntax of your URN, and then in section 5, you noted that some uses
> of these URNs use them with fragment identifiers, and in that case,
> fragment identifiers must have the syntax and semantics of EPUBCFI as
> defined in [document].

We have removed the fragment from the syntax, and added a description
that the urn may have a specific type of fragment.

I attach the revised specification.

Best regards,
Yoshiki Sameshima

---------------- URN Namespace Definition ----------------

I. Namespace ID

To be assigned.


2. Registration Information

Version 1
Date: 2015-02-17


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-UUID / CoNETS-ISBN )

; There are two types of the new scheme.


;;;
;;; First type: CoNETS UUID
;;;

CoNETS-UUID = "uuid:" UUID *( "/" FILE )
UUID = 1*(HEXDIGIT) 0*( "-" 1*(HEXDIGIT))
FILE = 1*PCHAR

; The first type is a combination of UUID and optionally file name.
; 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.
; PCHAR is the same as RFC 3986 or its successors.


;;;
;;; Second type: CoNETS ISBN
;;;

CoNETS-ISBN = "isbn:" ISBN *( "/" FILE )
ISBN = 1*(DIGIT / ALPHA) 0*("-" 1*(DIGIT / ALPHA))

; The second type is as the same as CoNETS-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

The URN represents an epub publication and may include an EPUBCFI fragment
optionally. The 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

The next is an example of UUID-type URN with EPUBCFI fragment:

  urn:urn-XX:uuid:1234a560-b78c-9d1e-f123-4567890abd00/book.epub#epubcfi(/6/2!/4/0)


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.


9. Process for identifier resolution

The resolution of the URN is processed locally. Firstly the epub publication which
is identified by the UUID/ISBN and FILE is searched in local repository, and then
the rest EPUBCFI part is identified as specified in the EPUBCFI specification.
Future versions of this specification may specify a global resolution process.


10. Rules for Lexical Equivalence

No special considerations.


11. Conformance with URN Syntax

No special considerations.


12. Validation mechanism

None specified.


13. Scope

The scope is global.