http://blog.gmane.org/gmane.ietf.urn hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.urn/529 <pre>Hi there, looking at &lt;http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml&gt;: 1) It has a "value" column (and it is sorted by "value"). What is this good for? 2) It mixes lowercase and uppercase NIS notations, where the NIS is supposed to be case-insensitive, right? Should I notify IANA? Best regards, Julian </pre> Julian Reschke 2013-05-22T15:52:21 http://comments.gmane.org/gmane.ietf.urn/527 <pre>Hi, I was looking for discussion about draft-saintandre-urn-example-03 (which is in status "publication requested"), but almost everything I could find on the mailing list were unrelated discussions (about what type of resources URNs should be used for). If anybody is disagreeing to the introduction of the "example" namespace, please speak up. Best regards, Julian </pre> Julian Reschke 2013-03-08T11:45:30 http://comments.gmane.org/gmane.ietf.urn/526 <pre> The following revised draft was submitted a few weeks ago. http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-13.txt the abstract is as follows: This specification defines a Uniform Resource Name namespace for the GSMA (GSM Association)and a sub-namespace for the IMEI (International Mobile station Equipment Identity), and associated parameter for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and both are encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile communications(GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, the Universal Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term Evolution). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within t</pre> Andrew Allen 2013-03-08T11:44:38 http://comments.gmane.org/gmane.ietf.urn/508 <pre>Hello Peter; all, Concerning this: It took a while before the bibliographic community got a sufficient grasp of how fragment can best be used in the URN context. Initially we thought that fragment should be part of the URN namespace specific string, but we realized soon that that would complicate things a lot. Since many (most, probably) standard namespaces do not allow add-ons to identifier strings, this: Ex. 1http://urn.fi/URN:ISBN:978-952-10-7670-1 would have been possible, but not this (NOTE: this is only an example) Ex. 2http://urn.fi/URN:ISBN:978-952-10-7670-1#chapter2 Moreover, adding a fragment to an existing URN would in this case have been an act of identifier assignment, which in some namespaces is a managed process, so too few people would have been allowed to use fragments with URNs. Eventually Alfred Hoenes, myself and others concluded that the best solution is to separate identification &amp; URN assignment from fragment assignment, that is, not to include fragment in the NSS. Which means </pre> Juha Hakala 2013-02-21T11:36:28 http://comments.gmane.org/gmane.ietf.urn/505 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the interest of moving forward with rfc2141bis and with my document editor hat on, I've been reviewing list discussions and earlier document versions so that we can be clear about open issues. Because the fragment identifier issue is quite large and has received a lot of discussion, I've decided to focus first on the issue of query components in URNs. Juha Hakala mentioned the topic in late 2010: https://www.ietf.org/mail-archive/web/urn/current/msg01485.html "From the PersID point of view, both &lt;query&gt; and &lt;fragment&gt; are vitally important. We support the idea of reserving &lt;query&gt; for the transfer of service parameters as a part of the resolution process." In March 2011, Juha again mentioned query components: https://www.ietf.org/mail-archive/web/urn/current/msg01507.html "As regards the URN syntax, the key issue - at least from my point of view - that should be discussed more widely is the usage of &lt;fragment&gt; and &lt;query&gt; in the way suggested in RFC214</pre> Peter Saint-Andre 2013-02-21T04:49:14 http://comments.gmane.org/gmane.ietf.urn/480 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Name (URN) Namespace Definitions Author(s) : Peter Saint-Andre Leslie Daigle Renato Iannella Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04.txt Pages : 16 Date : 2012-11-27 Abstract: This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04 A diff from the previous version is available at</pre> internet-drafts< at >ietf.org 2012-11-28T03:48:33 http://comments.gmane.org/gmane.ietf.urn/477 <pre>All, With respect to moving to a new, smaller document encompassing our 2141bis goal I see that there is consensus within this working group for making this transition. Peter Saint-Andre has also submitted a 3406bis document consistent with the same style as his 2141bis document. For consistency, this new document will be used as a basis for this working group's 3406bis goal going forward. It should be noted that these new documents are not the final output of this working group but are simply a new basis for the development of the milestones we must achieve, and they will be based on consensus within this working group and the IETF in accordance with IETF practices. With regards to the historical context and motivations described in the current set of documents, we will seek the addition of new milestones for Informational track RFCs in which to capture this information. -andy, URNBIS co-chair _______________________________________________ urn mailing list urn&lt; at &gt;ietf.org https://www.ietf.org/mailman/list</pre> Andrew Newton 2012-11-27T20:37:33 http://comments.gmane.org/gmane.ietf.urn/460 <pre>All, We have received a request for this working group to consider an alternative to its adopted 2141bis document (draft-ietf-urnbis-rfc2141bis-urn-03). That alternative is draft-saintandre-urnbis-2141bis-00 (http://datatracker.ietf.org/doc/draft-saintandre-urnbis-2141bis/). Additionally, some reviewers of our adopted document have expressed concern regarding its unnecessary wordiness, especially in comparison with the alternative. Can participants of this working group please review both documents and express opinions and provide comments as to the direction desired for this working group in regards to a 2141bis RFC? The two documents can be found here: http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ http://datatracker.ietf.org/doc/draft-saintandre-urnbis-2141bis/ We will use the IETF standard of rough consensus to determine the way forward. Finally, should the working group desire an alternative approach, we intend to preserve and publish the historical and non-normative information </pre> Andrew Newton 2012-10-25T18:34:59 http://comments.gmane.org/gmane.ietf.urn/455 <pre>There's no URN working group meeting scheduled for the Atlanta, but I'd like to talk about urns going forward.... Those who will be there, can we try to meet up informally? Thursday lunch? 1-3 would work for me, other suggestions? Larry </pre> Larry Masinter 2012-10-24T21:02:59 http://comments.gmane.org/gmane.ietf.urn/452 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Using National Bibliography Numbers as Uniform Resource Names Author(s) : Juha Hakala Alfred Hoenes Filename : draft-ietf-urnbis-rfc3188bis-nbn-urn-04.txt Pages : 20 Date : 2012-10-22 Abstract: National Bibliography Numbers, NBNs, are used by the national libraries and other organizations in order to identify various resources such as digitized monographs. Generally, NBNs are applied to resources that do not have an established (standard) identifier system of their own. A URN (Uniform Resource Names) namespace for NBNs was established in 2001 in RFC 3188. Since then, several European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the</pre> internet-drafts< at >ietf.org 2012-10-22T11:23:42 http://comments.gmane.org/gmane.ietf.urn/414 <pre>URN folks, thanks to all for reviving the discussion on the rfx2141bis and rfc3406bis I-Ds. As the editor of both drafts, I try to sum up below and provide a perspective for a way forward; I'll respond individually in more detail ASAP (see endnote). ** general ** Unfortunately, stakeholders of URN Namespaces for various reasons seem to feel discouraged to participate in the on-list discussion, which now has been majorized by few long-time "IETF professional" contributors. Part of the frustration I observe also seems to be based on the lack of constructive proposals on the list so far, as replacement solutions for the options being voted against. We should not forget that the prime target audience of these URN core documents is the rather divers family of (present and) prospective stakeholders of URN Namespaces, which frequently have not been in contact with the IETF, but possibly with other persistent ID schemes, _or_ which are working within the IETF, but with a focus on a particular technology and m</pre> Alfred Hönes 2012-07-05T09:26:08 http://comments.gmane.org/gmane.ietf.urn/405 <pre>I have mentioned this in the past, and I'll mention it again: I think the new bis specs need to include the authors of the original documents, with the new authors shown as editors. So, for instance, draft-ietf-urnbis-2141bis would have the following in the header: A. Hoenes, Ed. R. Moats Simply ripping the old authors out of the specs is disrespectful. Peter </pre> Peter Saint-Andre 2012-07-03T19:43:29 http://comments.gmane.org/gmane.ietf.urn/414 <pre>URN folks, thanks to all for reviving the discussion on the rfx2141bis and rfc3406bis I-Ds. As the editor of both drafts, I try to sum up below and provide a perspective for a way forward; I'll respond individually in more detail ASAP (see endnote). ** general ** Unfortunately, stakeholders of URN Namespaces for various reasons seem to feel discouraged to participate in the on-list discussion, which now has been majorized by few long-time "IETF professional" contributors. Part of the frustration I observe also seems to be based on the lack of constructive proposals on the list so far, as replacement solutions for the options being voted against. We should not forget that the prime target audience of these URN core documents is the rather divers family of (present and) prospective stakeholders of URN Namespaces, which frequently have not been in contact with the IETF, but possibly with other persistent ID schemes, _or_ which are working within the IETF, but with a focus on a particular technology and m</pre> Alfred Hönes 2012-07-05T09:26:08 http://comments.gmane.org/gmane.ietf.urn/405 <pre>I have mentioned this in the past, and I'll mention it again: I think the new bis specs need to include the authors of the original documents, with the new authors shown as editors. So, for instance, draft-ietf-urnbis-2141bis would have the following in the header: A. Hoenes, Ed. R. Moats Simply ripping the old authors out of the specs is disrespectful. Peter </pre> Peter Saint-Andre 2012-07-03T19:43:29 http://comments.gmane.org/gmane.ietf.urn/393 <pre>Hi, These comments are on draft-ietf-urnbis-rfc2141bis-urn-02. The comments may sound abrupt. It is not intentional. In the Abstract Section: "The requirements and procedures for URN Namespace registration documents are set forth in BCP 66, for which RFC 3406bis is the companion revised specification document replacing RFC 3406." The above paragraph isn't relevant to the document contents. In the Introduction Section: "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces (that share the properties of URNs) into URI-space." RFC 3986 mentions that 'the term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name'. The above text d</pre> SM 2012-06-27T23:17:43 http://comments.gmane.org/gmane.ietf.urn/392 <pre>Hi, This comments are on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02. The Abstract Section is too long. The draft is about procedures to register a URN namespace. In the Introduction Section: "URNs are part of the larger Uniform Resource Identifier (URI) family (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF STD 66, RFC 3986 [RFC3986]) with the specific goal of providing persistent naming of resources." The first line is useful; the rest is unnecessary information. "To actually leverage the potential synergetic advantage of this unification" This is not a document about pharmaceuticals. :-) 'The purpose of this document is to outline a mechanism and provide a template for explicit URN Namespace definition, as well as provide the mechanism for associating an identifier (called a "Namespace ID", or NID), which is registered with the Internet Assigned Numbers Authority (IANA) [IANA] in the URN Namespaces registry maintained at [IANA-URN</pre> SM 2012-06-27T23:17:56 http://comments.gmane.org/gmane.ietf.urn/391 <pre>All, There are two items that surfaced during the URNBIS working group meeting in Paris (IETF 83) which I should have explicitly noted on this mailing list but neglected to do so. That is my fault. The first item was brought forward in the presentations on 2141bis and 3406bis. The editors of these drafts have noted, in these documents, issues they feel are closed. At IETF 83 I asked for a review of these issues by working group participants and for any notes of dissent or inquiries to be sent to this mailing list by April 16. Given this request was never explicitly stated here, I would like to re-invite working group participants to review the 2141bis and 3406bis issues. If possible, I would ask that concerns raised from these reviews be given on this mailing list before July 13. Second, at IETF 83 Leslie Daigle proposed removing the fragment language from 2141bis and placing it in a separate draft to be moved forward as an Experimental RFC. If you have objections to this approach, please let us know (aga</pre> Andy Newton 2012-06-26T16:10:28 http://comments.gmane.org/gmane.ietf.urn/388 <pre>Hi there, is there a recommended NIS for URN examples? RFC 3406 doesn't seem to cover this... Best regards, Julian </pre> Julian Reschke 2012-06-24T12:41:41 http://comments.gmane.org/gmane.ietf.urn/382 <pre>&lt;speaking both as an individual and as a co-chair&gt; With URN Namespace registration documents, we have the recurring issue of choosing the appropriate normative language to indicate requirements imposed by the document itself and those imposed by external standards/documents for the underlying namespace, and to distinguish these from the common form of the plain verbs as used in natural language. With the approval of the IESG, RFC 6329 (published in April 2012) has introduced a new convention (see Section 3 of that RFC), and I suggest that we liberally adopt this method for our WG documents: - RFC 2119 terms (in all capital letters) denote normative document requirements according to RFC 2119, which MUST be at a protocol or meta-protocol level and conformance to these terms needs to be verifiable from external behavior of the protocol entities. - The lowercase forms with initial capital: "Must", "Must Not", "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" are to be interpret</pre> Alfred Hönes 2012-05-18T08:33:54 http://comments.gmane.org/gmane.ietf.urn/381 <pre>&lt;speaking as a co-chair&gt; It has been somehow missed to bring to your attention: The (draft) Minutes of the URNbis session at the IETF 83 meeting in Paris are available at http://www.ietf.org/proceedings/83/minutes/minutes-83-urnbis.txt Thanks to Bengt Neiss for taking these minutes! For convenience, I have copied the entire text below. Please check and provide feedback to help fill out a few details. Kind regards Alfred. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ URNBIS Working Group Monday, March 26, 2012 1510-1610 Chairs: Andrew (Andy) Newton Applications Area Advisor: Peter Saint-Andre Scribe: Bengt Neiss 1. Agenda Bashing The published agenda was presented. The item "URNS, Registries &amp; W3C" were removed from the agenda due to the absence of Larry Masinter. There were no objections to the modified agenda and the agenda changes were accepted. The new area director, Barry Leiba, was introduced to the group. 2. draft-ietf-urnbis-rfc2141bis-urn-02 Andy Newton led</pre> Alfred Hönes 2012-05-18T08:32:10 http://comments.gmane.org/gmane.ietf.urn/355 <pre>Section 1.2 of draft-ietf-urnbis-rfc2141bis-urn-02 cites RFC 1738 but instead should cite RFC 1737. Peter </pre> Peter Saint-Andre 2012-03-24T14:16:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.urn