From owner-urn-ietf@LISTS.NETSOL.COM Tue Oct 3 09:20:50 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09981 for ; Tue, 3 Oct 2000 09:20:49 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA07886; Tue, 3 Oct 2000 09:19:51 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8617185 for URN-IETF@LISTS.NETSOL.COM; Tue, 3 Oct 2000 09:17:35 -0400 Received: from citrix-hq.citrix.com ([12.8.192.30]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id JAA07879 for ; Tue, 3 Oct 2000 09:17:33 -0400 (EDT) Received: from [10.9.1.142] by citrix-hq.citrix.com via smtpd (for lists.netsol.com [216.168.224.214]) with SMTP; 3 Oct 2000 13:11:16 UT Received: from 10.9.1.111 by hqvwall01.citrix.com (InterScan E-Mail VirusWall NT); Tue, 03 Oct 2000 09:11:11 -0400 (Eastern Daylight Time) Received: by hqexchcon01.citrix.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 09:11:10 -0400 Received: from delivery.cam.eu.citrix.com ([10.70.128.47]) by hwexch01.ctxuk.citrix.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SZAK6887; Tue, 3 Oct 2000 14:11:08 +0100 References: <4.2.0.58.J.20000927120546.031dc2b0@sh.w3.mag.keio.ac.jp> Lines: 29 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 X-Face: wqk-$Z5Z Message-ID: <87k8bqrrx0.fsf@delivery.cam.eu.citrix.com> Date: Tue, 3 Oct 2000 14:11:07 +0100 Reply-To: Toby Speight From: Toby Speight Organization: Citrix Systems Subject: Re: Idea: URL-based URN space To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: "Martin J. Duerst"'s message of "Wed, 27 Sep 2000 12:14:06 +0900" 0> In article , 0> Larry Masinter ("Larry") wrote: Larry> I propose a URN namespace based on URLs, but made persistent by Larry> the addition of a date. Larry> Larry> I would propose calling this namespace 'dated-url' (possibly Larry> 'durl' or 'url'). These URNs would take the form Larry> Larry> urn:dated-url:: Larry> Larry> where was a string representing the date with arbitrary Larry> precision (following RFC 2550). The largest granularity of a Larry> date is a year. Larry> Larry> One is empowered to assign a dated-url URN with a date of Larry> and a URL only if one had administrative control Larry> of the resource located by that URL at that given date/time. 0> In article <4.2.0.58.J.20000927120546.031dc2b0@sh.w3.mag.keio.ac.jp>, 0> Martin J. Duerst ("Martin") wrote: Martin> Shouldn't that say something like 'during that given time'? Martin> E.g. for the 1999 example below, it would mean during all of Martin> 1999. Larry referred to RFC2550, which defines only instants, not periods. The example refers to the *first moment* of 1999, not the whole year. From owner-urn-ietf@LISTS.NETSOL.COM Tue Oct 3 23:20:37 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28294 for ; Tue, 3 Oct 2000 23:20:37 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id XAA14445; Tue, 3 Oct 2000 23:19:59 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8617954 for URN-IETF@LISTS.NETSOL.COM; Tue, 3 Oct 2000 23:19:37 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA13826 for ; Tue, 3 Oct 2000 22:39:24 -0400 (EDT) Received: from enoshima (dhcp-100-207.mag.keio.ac.jp [133.27.195.207]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id LAA06534; Wed, 4 Oct 2000 11:32:39 +0900 (JST) X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J References: <"Martin J. Duerst"'s message of "Wed, 27 Sep 2000 12:14:06 +0900"> <4.2.0.58.J.20000927120546.031dc2b0@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20001004110308.009d3a90@sh.w3.mag.keio.ac.jp> Date: Wed, 4 Oct 2000 11:03:58 +0900 Reply-To: "Martin J. Duerst" From: "Martin J. Duerst" Subject: Re: Idea: URL-based URN space To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <87k8bqrrx0.fsf@delivery.cam.eu.citrix.com> At 00/10/03 14:11 +0100, Toby Speight wrote: >Martin> Shouldn't that say something like 'during that given time'? >Martin> E.g. for the 1999 example below, it would mean during all of >Martin> 1999. > >Larry referred to RFC2550, which defines only instants, not periods. >The example refers to the *first moment* of 1999, not the whole year. Well, yes, but I think that will be misunderstood by many people, so it may be better to fix it. Regards, Martin. From owner-urn-ietf@LISTS.NETSOL.COM Fri Oct 6 15:15:19 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11050 for ; Fri, 6 Oct 2000 15:15:18 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA12545; Fri, 6 Oct 2000 15:14:18 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8621965 for URN-IETF@LISTS.NETSOL.COM; Fri, 6 Oct 2000 15:13:39 -0400 Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA12538 for ; Fri, 6 Oct 2000 15:13:36 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA08846; Fri, 6 Oct 2000 15:06:55 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Approved-By: Keith Moore Message-ID: <200010061906.PAA08846@astro.cs.utk.edu> Date: Fri, 6 Oct 2000 15:06:55 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: proposed revision to RFC2611 To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Message from Leslie Daigle of "Fri, 22 Sep 2000 18:50:19 EDT." <39CBE22B.6A68CE2B@thinkingcat.com> > ---- Proposed replacement text for RFC2611 ---- > > III. Formal: A "Formal" namespace may be requested, and IETF > review sought, in cases where the publication of the NID proposal > and the underlying namespace will provide benefit to an open and broad > base of the Internet community. That is, as in any open standards > outcome, publication of the NID proposal would allow persons > not immediately associated with the proposer to create new software, > or services, or otherwise better carry out their own activities > than if the NID publication had not been made. Benefits are expected > to be in the form of open accessibility, interoperability, etc. Mumble. Clearly if the community will benefit from having details of the namespace published as an RFC, then IETF should encourage such publication. But I don't necessarily see that as sufficient qualification for a Formal namespace. In general, URNs are not intended to have exposed structure beyond the NID. This is because the structure by which URNs under a particular NID are assigned, or resolved (the two are different) may change over time. We do not want to encourage implementors to depend on details of the structure within a particular NID, because that would tend to either constrain the future use of that NID. On the other hand, if the structure of assignment or resolution for a particular NID were to change, it could limit the applicability of software designed with assumptions about the old structure, and could therefore lessen the effective persistence of the bindings between previously assigned URNs and their resources. The principal exception would be for a NID that grandfathers an existing, well-established namespace (such as ISBN), for which there is significant utility in exposing the relationship between that existing namespace and URN-space, and/or in utilizing the structure of that existing namespace. I don't necessarily want to discourage publication of the structural details of URN namespaces (especially since the exchange of ideas might help promote sound namespace design and management). But I don't think we should think of this as promoting interoperability. URN interoperability should not depend on applications knowing the internal structure of NIDs. I continue to be strongly of the opinion that namespaces with human-meaningful NIDs are themselves damaging to persistence, and we should only assign human-meaningful NIDs when the utility of doing so (say for grandfathering purposes) has an overwhelming benefit. Thus, use of ISDN as an NID can be justified because ISDNs are already quite well-established, but use of WXYZ as an NID cannot easily be justified if WXYZ identifiers are not already well-known. To the extent that it is useful to encourage people to publish details about the structure of their NIDs, I would prefer that we use a different mechanism than assigning human-readable NIDs to those namespaces. We should separate the concepts of Formal NIDs and Human-Meaningful NIDs. Also, Formal but non-Human-Meaningful NIDs should not be penalized by making them longer and harder to transcribe than Human-Meaningful NIDs. A concrete proposal would be to allow Formal but Non-Human-Meaningful NIDs to be represented with a short string of digits to be assigned by ICANN. non-Formal NIDs would still need some prefix. (aside: it would be interesting to investigate the possibility of allowing DOI prefixes as NIDs, since they already have many of the right properties for persistence....and this might minimize the competition between the two groups. but this would require that the DOI folks and IETF agree on rules for future assignment of such prefixes.) > The RFC must include a "Namespace Considerations" section, which > outlines the perceived need for a new namespace (i.e., where existing > namespaces fall short of the proposer's requirements). > Considerations might include: > > - URN assignment procedures > - URN resolution/delegation > - type of resources to be identified > - type of services to be supported We should be careful here about 'types of services'. To some degree the types of services to be supported are inherently related to the types of resources which may be identified. But we should not encourage implementors to make assumptions about which services (or for that matter, which resources) are available with which NIDs. > The RFC must also include a "Community Considerations" > section, which indicates the dimensions upon which the proposer > expects the Internet community to be able to benefit by publication > of this namespace. Potential considerations include: > > - open assignment and use of identifiers within the namespace > - open operation of resolution servers for the namespace (server) > - creation of software that can meaningfully resolve and > access services for the namespace (client) Again, the creation of software aspect seems dubious. > It is expected that Formal NIDs may be applied to namespaces > where some aspects are not fully open. For example, > a namespace may make use of an externally managed (proprietary) > registry (as, e.g., ISBN does), for assignment of URNs in the namespace, > but it may still provide broad community benefit if the services > associated have openly-published APIs. I think that Formal-ness (meaning publication of the structure) of the NID should have little or nothing to do with open-ness of the NID. However, we should be wary about assignment of a human-meaningful NID to a closed and non-pre-existing namespace - because the resulting competition for favorable names, and the potential for disputes over ownership of an NID, damages persistence of the URNs under that NID. NIDs are not intended for marketing purposes. IMO, the fundamental requirements for assignment of a Formal NID should be based on the following principles: - the organization maintaining the NID should demonstrate stability and ability to maintain the NID space for a long time - it should demonstrate ability and competency at name assignment in order to facilitate persistence (e.g. to minimize the likelihood of conflicts) - it should commit to not re-assigning existing names and allowing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers of that organization. (this does not mean that they must provide resolution of such names, but it does mean that they must not resolve the name to false or stale information, and it means that they must not reassign the name) Keith From owner-urn-ietf@LISTS.NETSOL.COM Tue Oct 24 22:30:07 2000 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19849 for ; Tue, 24 Oct 2000 22:30:05 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA07161; Tue, 24 Oct 2000 22:28:34 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8615711 for URN-IETF@LISTS.NETSOL.COM; Tue, 24 Oct 2000 22:27:54 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA07141 for ; Tue, 24 Oct 2000 22:27:52 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id WAA05639 for urn-ietf@lists.netsol.com; Tue, 24 Oct 2000 22:11:38 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20001024221138.C5490@bailey.dscga.com> Date: Tue, 24 Oct 2000 22:11:38 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: final revisions of all DDDS documents.... To: URN-IETF@LISTS.NETSOL.COM Hi all, I've taken all of the last call comments and incorporated them into the final versions of all of the DDDS documents. I have them up on a web page so that you can check them out before I send 'em to the repository: http://usrlocalsrc.org/URN/ddds/ Unless I hear something otherwise I'm going to send 'em on Thursday. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com