Subject: [urn] Fwd: Re: request for assignment of informal urn

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

Of interest from the urn-nid list...

-------- Forwarded Message --------
Subject: Re: request for assignment of informal urn
Date: Fri, 20 Feb 2015 20:14:27 -0700
From: Peter Saint-Andre - &yet <[email-masked]>
To: [email-masked]
CC: [email-masked], 
[email-masked], [email-masked]

On 2/18/15 2:59 AM, [email-masked] 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, [email-masked] 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/
>>

-- 
Peter Saint-Andre
https://andyet.com/

---

From: John C Klensin <[email-masked]>
Date: Sat, 21 Feb 2015 07:31:25 -0500

Peter,

You are too kind.  The proposed registration is simply invalid
until after 2141bis is approved because it contains invalid
syntax.  On the other hand, we should probably try to understand
it better and try to draw the authors into the WG because:

(1) This appears to use a p-component, which I think some people
here are convinced is unnecessary.

(2) It is possible that 2141bis is in need of some language
advising against creating new URNs (even informal ones) that
appear to incorporate namespaces from existing ones without at
least consulting with the managers of those prior namespaces.
This seems particularly relevant because of potential
ambiguities in what the p-component actually means.  I don't
think they should be prevented from doing such a registration,
but being given an opportunity to understand its implications
seems useful. 

(3) Finally, if I correctly understand their ABNF, they would
end up with, e.g.,

  urn:urn-NNNN:conets-epub-isbn:X-XXX-XXXXX-X/FOO/BAR

It would seem to me that their identifying string is either
unneeded or excessive because it would be possible to either
create two informal URNs, each reflecting one of the underlying
identifiers, and get rid of the extra string or to create a
single informal URN for Hitachi-related epubs, and then make the
sub-namespaces (yeech) extensible beyond these two without
having to come back to the URN-NID list or whatever replaces it.

Again, it seems to me that it would be desirable to at least be
sure they understand those alternatives.

And we really need to get on with the work of this WG.  I take
this application as a further sign of the need for it.

   john

--On Friday, 20 February, 2015 20:16 -0700 Peter Saint-Andre -
&yet <[email-masked]> wrote:

>>> 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?
>> 
>> 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).
> 
>> 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.
> 
>>> On 2/9/15 2:22 AM,
>>> [email-masked] wrote:
>>>> Dear URN NID members,
>>>> 
>>>> The following is a URN Namespace Definition according to
>>>> the template described in RFC 3406.
>>>> 
>>>> Address:	4-12-7 Higashi-Shinagawa Shinagawa-ku, Tokyo
>>>> 140-0002 Japan Contact:	Yoshiki Sameshima
>>>> 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
>>>> 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.'
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 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/