Subject: request for assignment of informal urn

From: <[email-masked]>
Date: Mon, 9 Feb 2015 18:22:03 +0900

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.

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.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 16 Feb 2015 22:44:34 -0500

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

> UUID = 1*(HEXDIGIT) 0*( "-" 1*(HEXDIGIT))

Why not say "FILE = 1*PCHAR"?

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].  It think that would have exactly the same
implications in practice, without trying to declare the fragment
identifier as *part* of the URN.

Dale

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 09:03:19 -0700

> Agency. As for the other part of the identifier, FILE and EPUBCFI, the assignment

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/

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 18:59:17 +0900

Peter,

>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

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 19:08:29 +0900

Dale,

Thank you for your comments.

> and it might be desirable to remove that from the specification.

We have removed the redundant part.

> Why not say "FILE = 1*PCHAR"?

You are correct.

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

Version 1
Date: 2015-02-17

Name:		Yoshiki SAMESHIMA
		Takanobu HOSOE
		Tomohiro MISAWA

NEW-URN	= "urn:" ASSIGNED-SCHEME ":" ( CoNETS-UUID / CoNETS-ISBN )

;;;
;;; 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.'

The URN represents an epub publication and may include an EPUBCFI fragment
optionally. The definition of EPUBCFI can be found in:

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)

12. Validation mechanism

None specified.

13. Scope

The scope is global.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 20 Feb 2015 20:14:27 -0700

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

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

> 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

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 22 Feb 2015 22:58:30 -0500

IMHO, the correct way to handle fragment identifiers is to ignore the
fact that the URN syntax doesn't permit them.  The two main reasons for
that are (1) work is underway to allow specifying fragment identifiers
with URNs, and (2) by analogy with all other URIs, everyone knows how
they'll work syntactically.  A more subtle reason is (3) the fragment
identifier can be semantically separated from the "base" URN, in that
the definition of the URN namespace tells how to map the URN into a
"resource", and the resource itself determines how the fragment
identifier is to be interpreted.

Within that framework, the politics of the situation is much improved if
the namespace doesn't explicitly define fragment identifiers as part of
the syntax, and the practice is implicitly what everybody expects
already.

But it's not clear why a new namespace is needed -- instead of defining
one namespace which is semantically the disjoint union of ISBNs and
UUIDs, instead have the set of admissible URNs be the (intrinsically
disjoint) union of ISBN and UUID URNs.

The only reason I can see for a new namespace is if the process by which
a fragment identifier is applied to a resource is determined not by the
resource itself but by the namespace definition.  That is,
"urn:isbn:0-345-33971-1#epubcfi(/6/4[chap01ref]!/4[body01]/16[svgimg])"
might mean something different than
"urn-NNN:isbn:0-345-33971-1#epubcfi(/6/4[chap01ref]!/4[body01]/16[svgimg])"
even though they both intrinsically refer to fragments within the "book"
that has the ISBN 0-345-33971-1.

Dale