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/ >>
- Re: request for assignment of informal urn yoshiki.sameshima.vf
- request for assignment of informal urn yoshiki.sameshima.vf
- Re: request for assignment of informal urn Dale R. Worley
- Re: request for assignment of informal urn Peter Saint-Andre - &yet
- Re: request for assignment of informal urn yoshiki.sameshima.vf
- Re: request for assignment of informal urn yoshiki.sameshima.vf
- Re: request for assignment of informal urn Peter Saint-Andre - &yet
- Re: request for assignment of informal urn Dale R. Worley
- Re: request for assignment of informal urn Peter Saint-Andre - &yet
- Re: Re: request for assignment of informal urn Dale R. Worley
- Re: request for assignment of informal urn Dale R. Worley