From juha.hakala@helsinki.fi Mon Jan 9 22:23:19 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9476D21F881A for ; Mon, 9 Jan 2012 22:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.136 X-Spam-Level: X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkS+q1jMYSz3 for ; Mon, 9 Jan 2012 22:23:18 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23521F8812 for ; Mon, 9 Jan 2012 22:22:43 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q0A6MbOT024786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Jan 2012 08:22:39 +0200 Message-ID: <4F0BD92D.8070108@helsinki.fi> Date: Tue, 10 Jan 2012 08:22:37 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> <4EF821A9.3050404@it.aoyama.ac.jp> In-Reply-To: <4EF821A9.3050404@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 06:23:19 -0000 Hello Martin, I agree with you in many respects, but there are some differences of opinion as well. See below... Martin J. Dürst wrote: > Hello Juha, > This means that there is a strong question as to how, and to what > degree, the classical library-based name-location distinction is still > relevant and useful. With that I don't want to say that it's useless, I > just want to say that however many years of "practical experience" you > can claim, that experience may or may not transfer to a world with > essentially different "physical" rules. From a library point of view, for instance the following features of networked resources seem to be in favour of separating identification from location: 1. There may be multiple copies of a single resource in different locations. However a resource should have one and only one identifier. 2. Over time, there may be different resources available from a single location. 3. A single resource may be moved from one location to the next. 4. A digital resource may disappear (leaving only e.g. a printed surrogate). 5. A single file can incorporate multiple resources that should be identified separately; a single resource can span over multiple files. There has also been discussions about persistence (or the lack of it) of domain names, and the need of identifying abstract entities such as works (which may or may not have manifestations in the Web). > Also, at least as far as content is digital text, search engines add > another dimension to this picture. If things move, search engines just > catch up. Especially for specialized content, we are definitely not yet > there yet, but for more general content, the fact that something gets a > different URI isn't the end of the world these days. Search engines do catch up if the resource is not in a non-accessible silo. There seems to be an alarming trend that instead of making resources available in the (semantic) Web, some importand players are preferring to hide their data from the open Web. For resources in silos, it remains to be seen if persistent identifiers will be able to provide access. Moreover, any library has a significant amount of non-textual resources which for the time being are not well catered for by search engines. There are interesting (pilot) services for searching music or still images, but this is not yet mature technology. > So up to the middle ages, we mostly had the situation that one would > hear by chance that a certain library had a certain work, and would > travel to that library and read the work inside that library (though > indeed not on the shelf) if one had that much leisure time. It is a little bit ironic that for the Web content, most national libraries that harvest the Web must rely on similar practice. According to the existing legal deposit & copyright acts the harvested documents cannot be made freely available; the users must come to the national library or other legal deposit libraries in the country, and use the material on dedicated workstations, which are a modern equivalent of the chain that attached the mediaeval books to the shelf so as to protect them against thieves. > > In the "library age", one would go to the nearest public library, ask > e.g. "I want to read Tom Sawyer", got back a question whether one meant > Tom Sawyer by Mark Twain, and then got a "name" (or number) to write on > the order slip, or got directed to the relevant bookshelf (location). > And one would take the book home, and the library would record the > location of the copy in question as "with lender Foo". As an aside, while there is a well functioning business model for scientific periodicals (which, once purchased can be freely used) there is as of yet not a fixed model for e-books. There could be a limited number of electronic items (allowing for instance two users to read an electronic item at the same time), or each lending operation may have a fixed cost, so that one really popular book might take the entire acquisitions budget in a short time. > > In the digital age, we can type something into a search box, get the > content in no time, and never have to "give it back". At the same time, > several copies will have been created. Lots of > names/locations/identifiers (from metadata down to track numbers on a > hard disk) may be involved, but the overall thing may not easily fit an > old-style library name/location dichotomy anymore. The process you describe above applies freely available materials and e.g. commercial scientific periodicals. But for other kind of resources such as e-books things may become more complex, legally and otherwise. As regards the content, an e-book in EPUB 3 format becomes a ZIP container that can and will hold many things (each one of which must be identified separately) in addition to the text of the book, and even the text should adapt itself to different viewers. For the libraries' traditional cataloguing principles these resources will pose interesting challenges. > > > Regards, Martin. > -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From julian.reschke@gmx.de Tue Jan 10 01:30:23 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7325821F84D5 for ; Tue, 10 Jan 2012 01:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.657 X-Spam-Level: X-Spam-Status: No, score=-103.657 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxhzLJRm9ntN for ; Tue, 10 Jan 2012 01:30:22 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 13FC421F84D4 for ; Tue, 10 Jan 2012 01:30:21 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2012 09:30:19 -0000 Received: from p5DCC311D.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.49.29] by mail.gmx.net (mp066) with SMTP; 10 Jan 2012 10:30:19 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19OcDg/RmNOZIRZOsC2cFO46DMyjt1FhyRijjoxHC 1fXdXlK9+Bxj9L Message-ID: <4F0C0524.6050007@gmx.de> Date: Tue, 10 Jan 2012 10:30:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Juha Hakala References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> <4EF821A9.3050404@it.aoyama.ac.jp> <4F0BD92D.8070108@helsinki.fi> In-Reply-To: <4F0BD92D.8070108@helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 09:30:23 -0000 On 2012-01-10 07:22, Juha Hakala wrote: > Hello Martin, > > I agree with you in many respects, but there are some differences of > opinion as well. See below... > > Martin J. Dürst wrote: >> Hello Juha, > >> This means that there is a strong question as to how, and to what >> degree, the classical library-based name-location distinction is still >> relevant and useful. With that I don't want to say that it's useless, >> I just want to say that however many years of "practical experience" >> you can claim, that experience may or may not transfer to a world with >> essentially different "physical" rules. > > From a library point of view, for instance the following features of > networked resources seem to be in favour of separating identification > from location: > > 1. There may be multiple copies of a single resource in different > locations. However a resource should have one and only one identifier. CDNs show that HTTP URIs can be used to identify a single resource that can have multiple copies in different locations. > 2. Over time, there may be different resources available from a single > location. > > 3. A single resource may be moved from one location to the next. > > 4. A digital resource may disappear (leaving only e.g. a printed > surrogate). > > 5. A single file can incorporate multiple resources that should be > identified separately; a single resource can span over multiple files. > ... I still don't see what this has to do with "location" vs "naming". You can start with a locator and overload it as a name, or you can start with a name and overload it as locator. The former has been done a lot with HTTP URIs, the latter is what you seem to try to do with URN resolution. In the end, where's the difference? > There has also been discussions about persistence (or the lack of it) of > domain names, and the need of identifying abstract entities such as If you don't use domain names, you'll need an alternate system to delegate responsibilities. Who's going to run it? Who's going to guarantee persistence of *that* system`? > works (which may or may not have manifestations in the Web). "A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such that the follow-on representation might be useful to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s)." -- > ... Best regards, Julian From jonathan.rees@gmail.com Tue Jan 10 06:15:44 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26E921F8737 for ; Tue, 10 Jan 2012 06:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L13LXtnbW1wx for ; Tue, 10 Jan 2012 06:15:43 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 695EB21F8476 for ; Tue, 10 Jan 2012 06:15:43 -0800 (PST) Received: by ggnr5 with SMTP id r5so274293ggn.31 for ; Tue, 10 Jan 2012 06:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KKGne6ywgS8TCD1uF9ewgFuYl6z0KsKxP9EboQhNuoI=; b=KmNBBsGlHHGH2talij3QGI82fpm9DDzTGxD/5rbPpVsS2246jNLhbwt5eDFpCvRn/h SuKd7mVhXy4hKHnNDKH0kTy4HEtXXJtwPeF1yoQnYzFkY+avMLYCjCmZ0oLmrcmyDI+W /hjywBPFe3hvF53kXhfo7aPyKK7VxvIL73sWM= MIME-Version: 1.0 Received: by 10.50.194.168 with SMTP id hx8mr2532560igc.3.1326204942746; Tue, 10 Jan 2012 06:15:42 -0800 (PST) Sender: jonathan.rees@gmail.com Received: by 10.50.13.40 with HTTP; Tue, 10 Jan 2012 06:15:42 -0800 (PST) In-Reply-To: <4F0C0524.6050007@gmx.de> References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> <4EF821A9.3050404@it.aoyama.ac.jp> <4F0BD92D.8070108@helsinki.fi> <4F0C0524.6050007@gmx.de> Date: Tue, 10 Jan 2012 09:15:42 -0500 X-Google-Sender-Auth: leKN9dd-1aOBAmnVk_uIxe30NuM Message-ID: From: Jonathan A Rees To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:19:01 -0000 On Tue, Jan 10, 2012 at 4:30 AM, Julian Reschke wrote: > On 2012-01-10 07:22, Juha Hakala wrote: > I still don't see what this has to do with "location" vs "naming". You can > start with a locator and overload it as a name, or you can start with a name > and overload it as locator. > > The former has been done a lot with HTTP URIs, the latter is what you seem > to try to do with URN resolution. > > In the end, where's the difference? As I see it the significant difference between urn: and http: is that the NID registry is administered by IETF through the RFC process, and establishes NIDs permanently, while the domain name registries (other than .arpa, .example, and .invalid) are administered by ICANN (with delegation to TLDs and so on), and seem to always involve the threats of expiration and steward corruption. If the NID namespace were embedded in .arpa we could have a full equivalence: urn:nid:path == http://nid.urn.arpa/path The latter could even be resolvable in the usual HTTP way, if someone were to set up a network of servers that did URN resolution via DNS and HTTP. (Obviously just best effort, as some legitimate URNs are going to be unresolvable.) > >> There has also been discussions about persistence (or the lack of it) of >> domain names, and the need of identifying abstract entities such as > > If you don't use domain names, you'll need an alternate system to delegate > responsibilities. Who's going to run it? Who's going to guarantee > persistence of *that* system`? I think persistence and resolvability can and should be decoupled, and treated as separate responsibilities. Persistence is relative and to some extent subjective. I would say that the RFC series is a pretty good bet for persistence, as are the non-DNS registries such as media type, link relation, message header, etc. So that is where I would set the bar - are the bindings of the URIs in question (whether URN or HTTP) as persistent as the binding of (say) media type name to media type? To answer the question of responsibility for persistence, URN persistence devolves to IETF, with the help of IANA, and with delegation to the NID authorities. Persistence of the NID registrations is enhanced by the existence of mirrors of the IETF RFC series. If you trust the NID authorities and their technical infrastructure and succession plans then URNs are as persistent as the RFC series. Whether you do trust them or not is sort of up to you. We don't have a persistence story like this for http: since domain name registration (outside of .arpa) seems to always be vulnerable to loss. No matter how much you trust an organization's ability to maintain the registration over decades, there will always be a nagging doubt, which is very annoying. I too find the "naming" vs. "location" dichotomy not very compelling, but I do find the renewal requirement vs. permanent NID registration to be hard to gloss over. For me, expiration and corruption risks are the real hole in the "Cool URIs" story. Resolvability via DNS is a different story from persistence, and indeed the business model for the party that would be responsible for resolution is not clear to me. IETF and IANA absorb the cost for other registries, but might balk at being asked to provide DNS support for something like .urn.arpa. This for me is the hole in the "resolvable persistent URI" idea. But I am not convinced yet that this is insurmountable. We do have other persistent registries, so the difficulty has to be one of scale, not of kind. >> works (which may or may not have manifestations in the Web). > > > "A 303 response to a GET request indicates that the requested resource does > not have a representation of its own that can be transferred by the server > over HTTP. The Location URI indicates a resource that is descriptive of the > target resource, such that the follow-on representation might be useful to > recipients without implying that it adequately represents the target > resource. Note that answers to the questions of what can be represented, > what representations are adequate, and what might be a useful description > are outside the scope of HTTP and thus entirely determined by the URI > owner(s)." -- > +1 Best Jonathan >> ... > > > Best regards, Julian > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From stpeter@stpeter.im Wed Jan 11 14:48:24 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA44921F8764 for ; Wed, 11 Jan 2012 14:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwIXinZXEadH for ; Wed, 11 Jan 2012 14:48:24 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 246AC21F875D for ; Wed, 11 Jan 2012 14:48:24 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A223E40058; Wed, 11 Jan 2012 15:57:25 -0700 (MST) Message-ID: <4F0E11B6.5080805@stpeter.im> Date: Wed, 11 Jan 2012 15:48:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jonathan A Rees References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> <4EF821A9.3050404@it.aoyama.ac.jp> <4F0BD92D.8070108@helsinki.fi> <4F0C0524.6050007@gmx.de> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , urn@ietf.org Subject: [urn] OT: urn:iana (was:Re: I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:48:24 -0000 This is off-topic. My apologies for the tangent... On 1/10/12 7:15 AM, Jonathan A Rees wrote: > I think persistence and resolvability can and should be decoupled, and > treated as separate responsibilities. > > Persistence is relative and to some extent subjective. I would say > that the RFC series is a pretty good bet for persistence, as are the > non-DNS registries such as media type, link relation, message header, > etc. So that is where I would set the bar - are the bindings of the > URIs in question (whether URN or HTTP) as persistent as the binding of > (say) media type name to media type? I wonder whether it would be useful to define a URN namespace for IANA, so that applications could persistently name individual entries in IANA registries. As examples: urn:iana:managesieve:capabilities:SASL urn:iana:media-types:application:atom+xml urn:iana:sdp-security-descriptions:crypto-suites:SEED_128_GCM_96 Last summer I wrote an Internet-Draft on this topic, but I never submitted it. If you think this might have value, please ping me off-list. Peter -- Peter Saint-Andre http://stpeter.im/ From stpeter@stpeter.im Wed Jan 11 14:52:12 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EE421F8593 for ; Wed, 11 Jan 2012 14:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjP0X04RiPBC for ; Wed, 11 Jan 2012 14:52:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BC7ED21F8592 for ; Wed, 11 Jan 2012 14:52:11 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3A3DA4005B; Wed, 11 Jan 2012 16:01:13 -0700 (MST) Message-ID: <4F0E129A.7030701@stpeter.im> Date: Wed, 11 Jan 2012 15:52:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Julian Reschke References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> In-Reply-To: <4EF44091.3070608@gmx.de> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:52:12 -0000 On 12/23/11 1:49 AM, Julian Reschke wrote: > On 2011-12-23 09:14, Juha Hakala wrote: >> ... >> Is there a way to estimate how widely the UUID community is using >> urn:uuids, and for what purposes? >> ... > > I think it's safe to say that it's used a lot if you need a globally > unique URI that doesn't need to be resolvable. > > And no, I don't think there's something like an "UUID community"... Agreed. >>> Do you want to force identifiers like these into different URI >>> schemes? Why? >> >> To be honest, I would rather not see another URN namespace like uuid, >> since most users of persistent identifier systems have service >> expectations based on resolvability. And URN:UUIDs a priori will not >> fulfill any of these expectations. But based on what Peter said earlier, >> I suppose URN:UUID is and will be different from (all/most) other URN >> namespaces in this respect. > > We should keep that the important point in UR*N* * *naming*. > > URNs *can* be (made) resolvable, and URLs *can* be (stable) names. > > If this WG believes that urn:uuid is something that is kind of wrong > then I think we have a problem :-) We had a discussion about that last year, in which folks set me straight regarding the UUID NID: http://www.ietf.org/mail-archive/web/urn/current/msg01616.html >>> Also, once you start to focus too much on resolution then you'll >>> inevitably get people asking why you don't start with a scheme that >>> already is resolvable in the first place. In the end, stability of >>> URIs depends mainly on those who mint them, not on the actual notation. >> >> Yes, there is a broad agreement among the people who deal with long term >> preservation of digital content that preservation is primarily an >> organizational issue. >> >> The reason why resolution is important is that URN and other persistent >> identifiers will only become popular if they can provide added value; >> services which cool URIs etc. cannot support at all, or could only >> support with difficulty. These services are often based on resolution. > > I don't follow. Any kind of organization that can make name-based > identifiers stable and resolvable *could* do that with HTTP URIs as > well. It's not a technical problem but only one of organization. > >> There are good reasons for keeping services and identification apart >> (for instance, services are technology driven and will change over >> time), which is why the URN community has tried to avoid conflicts here, >> both in the existing URN RFCs and in the documents currently under >> development. > > Is this the "HTTP" may go way argument? Even if it does, you will still > be able to write resolvers, just like what you're trying to do right now > with URNs. True. In any case, what is the practical output of this discussion in terms of specification text? Peter -- Peter Saint-Andre http://stpeter.im/ From stpeter@stpeter.im Wed Jan 11 15:29:07 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85411E808E for ; Wed, 11 Jan 2012 15:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12YLvpfhYTce for ; Wed, 11 Jan 2012 15:29:06 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9291B11E8074 for ; Wed, 11 Jan 2012 15:29:06 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 266AD40058; Wed, 11 Jan 2012 16:38:08 -0700 (MST) Message-ID: <4F0E1B3F.3000703@stpeter.im> Date: Wed, 11 Jan 2012 16:29:03 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juha Hakala References: <201110312002.VAA11600@TR-Sys.de> <4EC25AC6.9060404@helsinki.fi> <4EEBB2B6.5090801@stpeter.im> <4EF303AF.3030807@helsinki.fi> In-Reply-To: <4EF303AF.3030807@helsinki.fi> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: [urn] naming and the necessity of resolution X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 23:29:07 -0000 On 12/22/11 3:17 AM, Juha Hakala wrote: > URNs and resolution services are parts of the URN system. Without > services URN assignment would not make sense. This is the core of my worry: you assume that URNs are worthless if they cannot be resolved. Yet the text you proposed includes these sentences: Resources identified with URNs may be abstract (e.g. works such as Shakespeare's Hamlet) or embodied in some physical form (PDF/A version of the Finnish translation of Hamlet). An abstract entity may have 0-n digital manifestations in the Internet (and other kind of manifestations in the physical world). To my mind, an abstract resource with zero manifestations is not the kind of thing that needs to be resolved. Examples might include: * the UUID C1A95067-9ECF-4983-9675-2B9CAA70BB11, which has a name of urn:uuid:C1A95067-9ECF-4983-9675-2B9CAA70BB11 * the SIEVE extension for a personal addressbook, which has a name of urn:ietf:params:sieve:addrbook:personal * the XML namespace used to advertise support for ZRTP by XMPP clients, which has a name of urn:xmpp:jingle:apps:rtp:zrtp:1 As far as I can see, these URNs do not need to be resolved, yet they are perfectly useful in the relevant applications. Indeed, I ask you to look at the IANA registry for formal URN namespaces at http://www.iana.org/assignments/urn-namespaces/ to see that many of these NIDs are used to assign URNs that name abstract resources with zero manifestations. Those URNs are just as valid and useful as URNs that name abstract resources with 1+ manifestations. I realize that resolution is important for the applications you care about, but those are not the only applications of interest to people who have minted URNs. Peter -- Peter Saint-Andre http://stpeter.im/ From stpeter@stpeter.im Wed Jan 11 15:35:17 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47E21F853B for ; Wed, 11 Jan 2012 15:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-37vxEUXy59 for ; Wed, 11 Jan 2012 15:35:16 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 60DCA21F8539 for ; Wed, 11 Jan 2012 15:35:16 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DCD5D40058; Wed, 11 Jan 2012 16:44:17 -0700 (MST) Message-ID: <4F0E1CB3.8090703@stpeter.im> Date: Wed, 11 Jan 2012 16:35:15 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juha Hakala References: <201110312002.VAA11600@TR-Sys.de> <4EC25AC6.9060404@helsinki.fi> <4EEBB2B6.5090801@stpeter.im> <4EF303AF.3030807@helsinki.fi> In-Reply-To: <4EF303AF.3030807@helsinki.fi> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 23:35:17 -0000 On 12/22/11 3:17 AM, Juha Hakala wrote: > Peter Saint-Andre wrote: >> Juha Hakala wrote: >>> In chapter 2 is discussed in the bottom of page 9 & top of the >>> page 10. We should refer here to RFC2483 (which specifies the resolution >>> services) and use an example which is based on an existing service. The >>> current example is a bit puzzling; for the time being it is not possible >>> to specify the type of metadata wanted because no such service exists. >> >> Could you clarify whether your statement refers to that particular >> example or to resolution services as such? > > I refer to the example in 2141bis. But my comment also makes the point > that we should revise the URN services in such a way that the user can > specify the type of metadata desired (the point made above in parenthesis). >> >>> A note should be added, saying that the services nailed down in RFC2483 >>> are not sufficient. For instance, it is not possible to specify what >>> type of metadata is needed (descriptive / administrative / structural) >>> and in which format (there are plenty of formats for descriptive >>> metadata, such as MARC21 or Dublin Core). RFC2483 refers to URC (Uniform >>> Resource Characteristics) which was never implemented in practice. (As >>> an aside, there are plenty of other reasons for updating that RFC.) >> >> Isn't that a matter for RFC 2483 (or 2483bis), not the core URN spec? >> There is no necessary connection between URNs and resolution, I think. > > There is no need to add the note if revision of RFC 2483 is added to the > charter of the URNBIS WG ;-). As long as I'm the Area Director (which is only through IETF 83), this WG will not add any new items to its charter because it is already behind schedule on delivering the work for which it was chartered. Peter -- Peter Saint-Andre http://stpeter.im/ From juha.hakala@helsinki.fi Wed Jan 11 23:08:37 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25921F866E for ; Wed, 11 Jan 2012 23:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a8ZRSVkjYuf for ; Wed, 11 Jan 2012 23:08:36 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id D1F5A21F8670 for ; Wed, 11 Jan 2012 23:08:34 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q0C78R4a025241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jan 2012 09:08:28 +0200 Message-ID: <4F0E86EB.8030206@helsinki.fi> Date: Thu, 12 Jan 2012 09:08:27 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <201110312002.VAA11600@TR-Sys.de> <4EC25AC6.9060404@helsinki.fi> <4EEBB2B6.5090801@stpeter.im> <4EF303AF.3030807@helsinki.fi> <4F0E1B3F.3000703@stpeter.im> In-Reply-To: <4F0E1B3F.3000703@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] naming and the necessity of resolution X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 07:08:37 -0000 Hello Peter; all, Peter Saint-Andre wrote: > > > On 12/22/11 3:17 AM, Juha Hakala wrote: > >> URNs and resolution services are parts of the URN system. Without >> services URN assignment would not make sense. > > This is the core of my worry: you assume that URNs are worthless if they > cannot be resolved. Yet the text you proposed includes these sentences: > > Resources identified with URNs may be abstract (e.g. works such as > Shakespeare's Hamlet) or embodied in some physical form (PDF/A > version of the Finnish translation of Hamlet). An abstract entity > may have 0-n digital manifestations in the Internet (and other kind > of manifestations in the physical world). In the library community, if there are no (digital) manifestations of the work, URNs should still be actionable. A user will not get the resource itself, but a surrogate such as descriptive metadata, which may include location of a physical copy. > > To my mind, an abstract resource with zero manifestations is not the > kind of thing that needs to be resolved. Examples might include: > > * the UUID C1A95067-9ECF-4983-9675-2B9CAA70BB11, which has a name of > urn:uuid:C1A95067-9ECF-4983-9675-2B9CAA70BB11 > > * the SIEVE extension for a personal addressbook, which has a name of > urn:ietf:params:sieve:addrbook:personal > > * the XML namespace used to advertise support for ZRTP by XMPP clients, > which has a name of urn:xmpp:jingle:apps:rtp:zrtp:1 > > As far as I can see, these URNs do not need to be resolved, yet they are > perfectly useful in the relevant applications. If non-resolvable URNs indeed do have meaningful functions, fine. But the IETF community should know or be able to find out what these functions are. Otherwise people may conclude that the URN system is not functioning properly. In order to make sure that the users do not have wrong expectations, the namespace registration should be informative as regards these functions. Anyway, based on this discussion, I'll change RFC2483bis draft. It currently requires that at least one resolution service is supported. The new version will say that some URN namespaces may not support any of the formally registered resolution services (the service registration mechanism is specified in RFC 2483bis). Instead they may provide some internal resolution services (outlined in the namespace registration), or none at all. RFC2483bis will also state that if zero resolution services are supported, the purpose of expressing the identifiers in question as URNs should be specified in sufficient detail in the namespace registration. Then the reviewers can decide if the proposed additional functionality is suitable from the URN system point of view. Such review should consider both the usefulness of the suggested functionality and the persistence of it. > Indeed, I ask you to look at the IANA registry for formal URN namespaces > at http://www.iana.org/assignments/urn-namespaces/ to see that many of > these NIDs are used to assign URNs that name abstract resources with > zero manifestations. Those URNs are just as valid and useful as URNs > that name abstract resources with 1+ manifestations. I have looked at them, albeit only briefly. The number of manifestations is not a critical issue from the resolution point of view, since a surrogate such as metadata record describing the resource can be supplied. If there are zero surrogates there should be a specific application context which renders the URN meaningful. What does bother me is that I am not familiar with these contexts and there is no way to find out about them from the current documentation. As a result it is impossible to know how some namespaces are expected to serve the Internet users. Any URN namespace may be valid and useful, but I am afraid that in the long run some will be more valid and useful than others. > I realize that resolution is important for the applications you care > about, but those are not the only applications of interest to people who > have minted URNs. I agree, but in order to know the overall role of URNs in the Internet we should perhaps know more about out what kind of applications and functions people have had in mind. That may have an impact on 3406bis. Best regards, Juha > > Peter -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From L.Svensson@dnb.de Thu Jan 12 10:30:10 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F3D21F8498 for ; Thu, 12 Jan 2012 10:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s-J3Xjlr4Hk for ; Thu, 12 Jan 2012 10:30:09 -0800 (PST) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id CD18621F8483 for ; Thu, 12 Jan 2012 10:30:08 -0800 (PST) Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 23AACD5C83 for ; Thu, 12 Jan 2012 19:30:07 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([10.69.63.245]) by dbf-ex.AD.DDB.DE with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jan 2012 19:30:06 +0100 Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.01.0355.002; Thu, 12 Jan 2012 19:30:06 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Re: [urn] naming and the necessity of resolution Thread-Index: AQHM0LjXEmaSc4jHJkiUbpbLeqpiE5YIP8CAgAC8ruA= Date: Thu, 12 Jan 2012 18:30:06 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFF0CA@dnbf-ex1.AD.DDB.DE> References: <201110312002.VAA11600@TR-Sys.de> <4EC25AC6.9060404@helsinki.fi> <4EEBB2B6.5090801@stpeter.im> <4EF303AF.3030807@helsinki.fi> <4F0E1B3F.3000703@stpeter.im> <4F0E86EB.8030206@helsinki.fi> In-Reply-To: <4F0E86EB.8030206@helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 18:30:06.0918 (UTC) FILETIME=[3557DE60:01CCD158] Subject: Re: [urn] naming and the necessity of resolution X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:30:10 -0000 Juha, Peter, all, Juha wrote >=20 > Peter Saint-Andre wrote: > > > > > > On 12/22/11 3:17 AM, Juha Hakala wrote: > > > >> URNs and resolution services are parts of the URN system. Without > >> services URN assignment would not make sense. > > > > This is the core of my worry: you assume that URNs are worthless if > they > > cannot be resolved. Yet the text you proposed includes these > sentences: > > > > Resources identified with URNs may be abstract (e.g. works such as > > Shakespeare's Hamlet) or embodied in some physical form (PDF/A > > version of the Finnish translation of Hamlet). An abstract entity > > may have 0-n digital manifestations in the Internet (and other > kind > > of manifestations in the physical world). >=20 > In the library community, if there are no (digital) manifestations of > the work, URNs should still be actionable. A user will not get the > resource itself, but a surrogate such as descriptive metadata, which > may > include location of a physical copy. > > > > To my mind, an abstract resource with zero manifestations is not the > > kind of thing that needs to be resolved. Examples might include: > > > > * the UUID C1A95067-9ECF-4983-9675-2B9CAA70BB11, which has a name of > > urn:uuid:C1A95067-9ECF-4983-9675-2B9CAA70BB11 > > > > * the SIEVE extension for a personal addressbook, which has a name of > > urn:ietf:params:sieve:addrbook:personal > > > > * the XML namespace used to advertise support for ZRTP by XMPP > clients, > > which has a name of urn:xmpp:jingle:apps:rtp:zrtp:1 > > > > As far as I can see, these URNs do not need to be resolved, yet they > are > > perfectly useful in the relevant applications. >=20 > If non-resolvable URNs indeed do have meaningful functions, fine. But > the IETF community should know or be able to find out what these > functions are. Otherwise people may conclude that the URN system is not > functioning properly. In order to make sure that the users do not have > wrong expectations, the namespace registration should be informative as > regards these functions. >=20 > Anyway, based on this discussion, I'll change RFC2483bis draft. It > currently requires that at least one resolution service is supported. > The new version will say that some URN namespaces may not support any > of > the formally registered resolution services (the service registration > mechanism is specified in RFC 2483bis). Instead they may provide some > internal resolution services (outlined in the namespace registration), > or none at all. +1 > RFC2483bis will also state that if zero resolution services are > supported, the purpose of expressing the identifiers in question as > URNs > should be specified in sufficient detail in the namespace registration. > Then the reviewers can decide if the proposed additional functionality > is suitable from the URN system point of view. Such review should > consider both the usefulness of the suggested functionality and the > persistence of it. -1=20 The requirement that a namespace registrant explicitly need to defend, why = the proposed namespace doesn't need a resolution service seems a bit unfair= to me. If we do that, we would also need a section where a registrant who = wants to have resolvable (or "actionable") URNs need to explain, why http-U= RIs don't work for him (the keyword being "persistence"). Since we're looking at the complete family of URN RFCs, I suggest the follo= wing: RFC 2141bis simply states what URNs are for and what they look like (syntax= ). It possibly mentions that URNs can be resolvable, but that they don't ha= ve to. RFC 3406bis states that when you register a namespace you must decide if it= needs resolution services or not. If it needs resolution services, there i= s a mandatory section where you describe if you will provide services accor= ding to rfc2483bis or other services (which). If there is agreement on this, I shall supply some text suggestions next we= ek (or possibly the week after). I also volunteer to supply some text to 2483bis (outside of the WG), since = we need something to refer to in 3406bis. > > Indeed, I ask you to look at the IANA registry for formal URN > namespaces > > at http://www.iana.org/assignments/urn-namespaces/ to see that many > of > > these NIDs are used to assign URNs that name abstract resources with > > zero manifestations. Those URNs are just as valid and useful as URNs > > that name abstract resources with 1+ manifestations. >=20 > I have looked at them, albeit only briefly. The number of > manifestations > is not a critical issue from the resolution point of view, since a > surrogate such as metadata record describing the resource can be > supplied. If there are zero surrogates there should be a specific > application context which renders the URN meaningful. What does bother > me is that I am not familiar with these contexts and there is no way to > find out about them from the current documentation. As a result it is > impossible to know how some namespaces are expected to serve the > Internet users. Any URN namespace may be valid and useful, but I am > afraid that in the long run some will be more valid and useful than > others. I fear that it is inevitable that some things turn out to be more valid and= useful than others. A phlogiston made much sense in the 17th century but i= t doesn't any more (except to people interested in the history of philosoph= y, but to them it might still be very important). What I'm trying to say is= that it is terribly hard to predict what will make sense in the future and= thus we should be very careful not to exclude namespaces just because we d= on't believe they will be useful in the future. We definitely need some cri= teria (who will maintain the namespace/resolution service; do they have a p= lan what will happen, when the organization goes out of business), but also= must be able to measure each criterion objectively. > > I realize that resolution is important for the applications you care > > about, but those are not the only applications of interest to people > who > > have minted URNs. >=20 > I agree, but in order to know the overall role of URNs in the Internet > we should perhaps know more about out what kind of applications and > functions people have had in mind. That may have an impact on 3406bis. To me it seems that some people really only think of naming (like info-URIs= , RFC4452), whereas others think of naming _and_ services. We need to cater= for both, and that's why it makes sense (to me) to differ between generic = syntax and services. The two aspects come together when someone registers a= namespace needing a resolution service. If it doesn't they shouldn't need = to care about 3406bis. All the best, Lars **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. **** **** Please note my new internet- and email-address. **** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de From L.Svensson@dnb.de Thu Jan 12 10:35:55 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A482A21F8606 for ; Thu, 12 Jan 2012 10:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8yuq-Q3PbO4 for ; Thu, 12 Jan 2012 10:35:54 -0800 (PST) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id F229821F8513 for ; Thu, 12 Jan 2012 10:35:53 -0800 (PST) Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 23B42D5C41 for ; Thu, 12 Jan 2012 19:35:53 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([10.69.63.245]) by dbf-ex.AD.DDB.DE with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jan 2012 19:35:52 +0100 Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.01.0355.002; Thu, 12 Jan 2012 19:35:52 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt Thread-Index: AQHMz6LQgCegjXXSQU2O4Ltn33aGlJYJEcwQ Date: Thu, 12 Jan 2012 18:35:52 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFF115@dnbf-ex1.AD.DDB.DE> References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> <4EF821A9.3050404@it.aoyama.ac.jp> <4F0BD92D.8070108@helsinki.fi> <4F0C0524.6050007@gmx.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 18:35:52.0914 (UTC) FILETIME=[0392AB20:01CCD159] Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:35:55 -0000 Jonathan wrote: >=20 > On Tue, Jan 10, 2012 at 4:30 AM, Julian Reschke > wrote: >=20 > > On 2012-01-10 07:22, Juha Hakala wrote: > > I still don't see what this has to do with "location" vs "naming". > You can > > start with a locator and overload it as a name, or you can start with > a name > > and overload it as locator. > > > > The former has been done a lot with HTTP URIs, the latter is what you > seem > > to try to do with URN resolution. > > > > In the end, where's the difference? >=20 > As I see it the significant difference between urn: and http: is that > the NID registry is administered by IETF through the RFC process, and > establishes NIDs permanently, while the domain name registries (other > than .arpa, .example, and .invalid) are administered by ICANN (with > delegation to TLDs and so on), and seem to always involve the threats > of expiration and steward corruption. [...] > I think persistence and resolvability can and should be decoupled, and > treated as separate responsibilities. +1 > Persistence is relative and to some extent subjective. I would say > that the RFC series is a pretty good bet for persistence, as are the > non-DNS registries such as media type, link relation, message header, > etc. So that is where I would set the bar - are the bindings of the > URIs in question (whether URN or HTTP) as persistent as the binding of > (say) media type name to media type? +1 Thanks, Jonathan. Excellent points! All the best, Lars **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. **** **** Please note my new internet- and email-address. **** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de From juha.hakala@helsinki.fi Fri Jan 13 00:33:37 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6946F21F8592 for ; Fri, 13 Jan 2012 00:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.658 X-Spam-Level: X-Spam-Status: No, score=-5.658 tagged_above=-999 required=5 tests=[AWL=0.941, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BalYf0pXwM4L for ; Fri, 13 Jan 2012 00:33:36 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 89C8121F858A for ; Fri, 13 Jan 2012 00:33:34 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q0D8XTV3028890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jan 2012 10:33:30 +0200 Message-ID: <4F0FEC59.7020702@helsinki.fi> Date: Fri, 13 Jan 2012 10:33:29 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Svensson, Lars" References: <201110312002.VAA11600@TR-Sys.de> <4EC25AC6.9060404@helsinki.fi> <4EEBB2B6.5090801@stpeter.im> <4EF303AF.3030807@helsinki.fi> <4F0E1B3F.3000703@stpeter.im> <4F0E86EB.8030206@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFF0CA@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFF0CA@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] naming and the necessity of resolution X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 08:33:37 -0000 Hello Lars; all, Svensson, Lars wrote: > Since we're looking at the complete family of URN RFCs, I suggest the following: > > RFC 2141bis simply states what URNs are for and what they look like (syntax). It possibly mentions that URNs can be resolvable, but that they don't have to. OK. > RFC 3406bis states that when you register a namespace you must decide if it needs resolution services or not. If it needs resolution services, there is a mandatory section where you describe if you will provide services according to rfc2483bis or other services (which). OK. Please note that RFC2483bis does not try to list all possible services (since that is not possible). Instead there should be an IANA registry for formal and informal services, and a possibility to create experimental resolution services as well. > > If there is agreement on this, I shall supply some text suggestions next week (or possibly the week after). Great! > > I also volunteer to supply some text to 2483bis (outside of the WG), since we need something to refer to in 3406bis. Not only do we need something to refer to in 3406bis; 3406bis and 2483bis must be in synch. You are most welcome to revise the 2483bis (which will then become a joint venture between you, Alfred and me). I'll send the latest version of the document to you separately later today. > I fear that it is inevitable that some things turn out to be more valid and useful than others. A phlogiston made much sense in the 17th century but it doesn't any more (except to people interested in the history of philosophy, but to them it might still be very important). What I'm trying to say is that it is terribly hard to predict what will make sense in the future and thus we should be very careful not to exclude namespaces just because we don't believe they will be useful in the future. We definitely need some criteria (who will maintain the namespace/resolution service; do they have a plan what will happen, when the organization goes out of business), but also must be able to measure each criterion objectively. Come to think of it, there is probably nothing much to be afraid of. What we need is a flexible system where we have formal, informal & experimental namespaces and, independently, formal, informal and experimental services. Any combination of a namespace & related services is valid, and since it is possible to register the services as needed the registrants can indicate precisely what their intentions are. The only thing that may be harmful to the URN system as a whole is a namespace registration request which fails to provide complete / correct information about the namespace. Best regards, Juha -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From stpeter@stpeter.im Tue Jan 17 09:14:52 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F60111E8072 for ; Tue, 17 Jan 2012 09:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQYpSpYX8BxY for ; Tue, 17 Jan 2012 09:14:51 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2C1F0C49 for ; Tue, 17 Jan 2012 09:14:44 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5FBEC40058 for ; Tue, 17 Jan 2012 10:24:04 -0700 (MST) Message-ID: <4F15AC89.9070307@stpeter.im> Date: Tue, 17 Jan 2012 10:14:49 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "urn@ietf.org" X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [urn] meeting in Paris X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:14:52 -0000 I assume that the URNBIS WG will meet at IETF 83 in Paris (if the WG does not plan to meet then my concerns would become even more grave). Please note that WG sessions need to be scheduled less than 2 weeks from now: http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 Peter -- Peter Saint-Andre http://stpeter.im/ From L.Svensson@dnb.de Thu Jan 19 04:10:52 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7C21F8647 for ; Thu, 19 Jan 2012 04:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZyci+88KEMk for ; Thu, 19 Jan 2012 04:10:51 -0800 (PST) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id EEB3021F8645 for ; Thu, 19 Jan 2012 04:10:45 -0800 (PST) Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id AFA31D5C94 for ; Thu, 19 Jan 2012 13:10:36 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([10.69.63.245]) by dbf-ex.AD.DDB.DE with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jan 2012 13:10:36 +0100 Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.01.0355.002; Thu, 19 Jan 2012 13:10:36 +0100 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-01.txt Thread-Index: AcyYCCd8qAQbHPemSRu4edV13MaYRg+mSiIA Date: Thu, 19 Jan 2012 12:10:35 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF012326@dnbf-ex1.AD.DDB.DE> References: <201110312002.VAA11600@TR-Sys.de> In-Reply-To: <201110312002.VAA11600@TR-Sys.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.241] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 12:10:36.0552 (UTC) FILETIME=[5A0A0080:01CCD6A3] Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 12:10:52 -0000 Alfred, thanks for moving this forward. I have added some inline comments, below. Alfred wrote on October 31, 2011 > So, in order to bring forward the discussion on the draft, please > currently focus on the other open issues tagged in (editorial) Notes > inside the draft, which have not received much comments so far. > In particular, we should hopefully be able to close the NID syntax > issues discussed in section 2.1 soon, with your help! Sec 2.1 says: [[ Note for discussion: The above definition is taken from RFC 2141 and changed to reflect requirements from RFC 3406[bis]. RFC 3406[bis] contains further syntax restrictions on NID strings. Should this be further restricted, e.g., to avoid possible confusion caused by multiple adjacent hyphens and NIDs looking like a numerical value or a numerical range? Does the WG opt to move the more restrictive NID syntax details from the rfc3406bis draft to this section? Such restrictions would be fully backward compatible because no NIDs have been defined so far that would violate these restrictions. Hyphens have been used only in the naming pattern for "Informal Namespace IDs" per RFC 3406[bis]. Namespace Identifiers are case-insensitive, so that for instance "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the URI Scheme name "urn", the NID "urn" is permanently reserved by this RFC and MUST NOT be used or registered. Note for discussion: This reservation is carried over unchanged from RFC 2141, for historical reasons. Further possible reservations and/or details are out of scope for this document, but within the scope of the rfc3406bis draft! ]] If we say that 2141bis reserves the NID 'urn' but that all other reserved N= IDs are specified by 3406bis, 3406bis should be the master document for all= restrictions/requirements on NID syntax. That way we'd have all in one pla= ce which makes it easier for implementers (they only need to look at 3406bi= s when registering a namespace). Some further comments: The document does not give a complete ABNF for the URN syntax. If we supply= that, it would be fairly straightforward to implement a URN validation ser= vice and possibly a service to check for lexical equivalence. Regarding NSS Syntax: Is it possible to give an ABNF rule that makes it cle= ar that some characters MUST be percent-encoded? I'm not that deep into ABN= F, but I guess that there are experts on this list. And a final thought about Lexical Equivalence (out of scope for 2141bis, bu= t relevant to 3406bis): If I have a namspace that allows characters which I must percent-encode in = a URN (like '=C5=C4=D6=E5=E4=F6'), how can I specify that the NSS '=C5=C4= =D6' is lexically equivalent to '=E5=E4=F6'? > I plan to submit another revision of this draft during the IETF 82 > week, once draft submission is open again. I could not find a newer revision than 01, so my comments refer to that one= . If there is a new revision, please accept my apologies and point me to th= e newest one and I will have a look ASAP. All the best, Lars **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. **** **** Please note my new internet- and email-address. **** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de From A.Hoenes@TR-Sys.de Thu Jan 19 09:02:48 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24B721F86A5 for ; Thu, 19 Jan 2012 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.299 X-Spam-Level: X-Spam-Status: No, score=-96.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz6-In8gU+EO for ; Thu, 19 Jan 2012 09:02:46 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE121F84F7 for ; Thu, 19 Jan 2012 09:02:44 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA163372514; Thu, 19 Jan 2012 18:01:54 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA02623; Thu, 19 Jan 2012 18:01:48 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201201191701.SAA02623@TR-Sys.de> To: L.Svensson@dnb.de Date: Thu, 19 Jan 2012 18:01:48 +0100 (MEZ) In-Reply-To: <24637769D123E644A105A0AF0E1F92EF012326@dnbf-ex1.AD.DDB.DE> from "Svensson, Lars" at Jan "19, " 2012 "12:10:35" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:02:48 -0000 [[ speaking as the draft author ]] On 2012-01-19, Lars Svenson wrote: > Alfred, > > thanks for moving this forward. I have added some inline comments, > below. Lars, Thanks for taking the time to review the draft. I have been eagerly waiting for comments. > Alfred wrote on October 31, 2011 > >> So, in order to bring forward the discussion on the draft, please >> currently focus on the other open issues tagged in (editorial) Notes >> inside the draft, which have not received much comments so far. >> In particular, we should hopefully be able to close the NID syntax >> issues discussed in section 2.1 soon, with your help! > > Sec 2.1 says: > > [[ > Note for discussion: > The above definition is taken from RFC 2141 and changed to reflect > requirements from RFC 3406[bis]. RFC 3406[bis] contains further > syntax restrictions on NID strings. > Should this be further restricted, e.g., to avoid possible > confusion caused by multiple adjacent hyphens and NIDs looking > like a numerical value or a numerical range? > Does the WG opt to move the more restrictive NID syntax details > from the rfc3406bis draft to this section? > Such restrictions would be fully backward compatible because no > NIDs have been defined so far that would violate these > restrictions. Hyphens have been used only in the naming pattern > for "Informal Namespace IDs" per RFC 3406[bis]. > > Namespace Identifiers are case-insensitive, so that for instance > "ISBN" and "isbn" refer to the same namespace. > > To avoid confusion with the URI Scheme name "urn", the NID "urn" is > permanently reserved by this RFC and MUST NOT be used or registered. > > Note for discussion: > This reservation is carried over unchanged from RFC 2141, for > historical reasons. Further possible reservations and/or details > are out of scope for this document, but within the scope of the > rfc3406bis draft! > ]] > > If we say that 2141bis reserves the NID 'urn' but that all other > reserved NIDs are specified by 3406bis, 3406bis should be the master > document for all restrictions/requirements on NID syntax. That way > we'd have all in one place which makes it easier for implementers > (they only need to look at 3406bis when registering a namespace). The main reason for the current placement in the drafts of the reservation for the NID string 'urn' is that -- as already pointed out in the 2nd 'Note for discussion' quoted above -- it was in RFC 2141 (last paragraph of section 2.1, at the bottom of page 2 of RFC 2141). IMO, this placement is justified because it seems to be an essential detail to disambiguate the leading part of a URN string (whether it is written as the full URN or as the -- not recommended -- colloquial abbreviated form comprised of only the NID and subsequent components). The other exclusions under consideration are more like for convenience of human users, and need only be respected during the process of registration of a URN namespace; hence, the placement in rfc3406bis seems appropriate to me. Nevertheless, for clarity, the banning of 'urn' as an NSS string is repeated in rfc3406bis (as a quote from rfc2141bis), in the same way it has been in RFC 3406 vs. RFC 2141. However, that implementers on *generic* URN parsers need to follow rfc2141bis; since this is the document entitled "URN syntax". Implementations that want/need to go the NID-specifics can (and should) always derive the current set of registered NISs from the IANA registry -- i.e. the result of the application of RFC 3406 / rfc3406bis, not these documents themselves -- and obtain the NID-specific additional syntax rules from the registration documents proper. IMO, generic tools do not need to be aware of NID-specific syntax details, only URN resolver systems need to do that -- to the extent of the NIDs they specifically support. So, in a nutshell, the exclusion specified in rfc2141bis is intended to provide disambiguation in the general case, ensuring that a single (leading) instance of "urn" will always be the URI scheme and never be an NID. Following other voices, I conclude that the WG does _not_ desire further formal restrictions in the NID syntax in rfc2141bis, because the common sense of prospective registrants (likely seeking for short, expressive, mnemonical, NID strings) and of the janitors of the IANA registry (a.k.a. IETF experts, and in the case of dispute, the IESG) will prevent the registration of confusing/dangerous/abusive NIDs. If you don't share this conclusion, please state your opinion and arguments NOW, on the urn list; thanks! > Some further comments: > > The document does not give a complete ABNF for the URN syntax. > If we supply that, it would be fairly straightforward to implement > a URN validation service and possibly a service to check for lexical > equivalence. It's important, but a bit tricky to avoid overspecification (with the impending danger of inconsistencies). Therefore, the rfc2141bis draft follows the IETF tradition of including other ABNF rules by reference; this seems to be proper in this case because RFC 5234 (ABNF) and RFC 3986 (URI Syntax) are the only sources of ABNF rules referred to, and knowledge of these documents seems to be essential for all implementers of rfc2141bis. Further, the *informative* Appendix B of the current rfc2141bis draft contains the fully expanded version of all the ABNF rules that are referred to in the normative part of the draft, so that -- assuming that Appendix B is precisely quoting RFCs 3986 and 5234 -- readers of rfc2141bis can have the full picture of all ABNF syntax details. > Regarding NSS Syntax: Is it possible to give an ABNF rule that > makes it clear that some characters MUST be percent-encoded? > I'm not that deep into ABNF, but I guess that there are experts > on this list. Answer to the question: Essentially, NO ! (At least it would be huge, onerous, unreadable, and confusing.) The deeper reason likely is that what you would like to have relates to the _semantics_ of , which cannot be given in ABNF. Note that the ABNF standard (RFC 5234) points out that textual explanations can place additional restrictions on ABNF rules that cannot be formulated in ABNF proper, and that such explanations are at the same normative level as the formal, directly machine- parseable, ABNF rules. > And a final thought about Lexical Equivalence (out of scope for > 2141bis, but relevant to 3406bis): > If I have a namspace that allows characters which I must percent- > encode in a URN (like 'ÐØÚÔÌÎ'), how can I specify that the NSS > 'ÐØÚ' is lexically equivalent to 'ÔÌÎ'? A namespace that needs/wants to incorporate non-ASCII characters (which will be first UTF-8 encoded and then percent-encoded for inclusion in URNs) needs to determine its appropriate rules. In case of roman characters with accents, the case mapping properties and normalization rules/forms specified by the Unicode Standard might be good candidates to draw from. In general and ultimately, any equivalence not easily expressible in syntax rules will need to be instantiated by the registration / resolution systems for a specific namespace, and the methods for implementation are strictly a "local" matter for the maintainers of the registration system(s). A similar problem is well-known for domain names, where it is well-known that, in particular for non-roman scripts, "human-friendly" equivalence for identifiers is impossible to be specified on an "absolute base" and achieved in a distributed manner because human-perceived equivalence is frequently culture and context dependent; hence, in the context of the DNS, only the name registration system and the authoritative servers for a domain can implement and enforce the non-ASCII equivalence rules intended for that particular domain. So, in your example above, the respective namespace document could specify a "normal form" of the NSS for that namespace and the rules to achieve it (e.g., Unicode NFxx normalization and case mapping to lower-case), or it could simply state that any appropriate equivalence will be deliverd by the resolution system. Therefore, and in fact, for some namespaces, _lexical_ equivalence of URNs (i.e., what a client system can determine) might become less important than _semantical_ equivalence (implemented in the registration / resolution services). >> I plan to submit another revision of this draft during the IETF 82 >> week, once draft submission is open again. > > I could not find a newer revision than 01, so my comments refer > to that one. If there is a new revision, please accept my apologies > and point me to the newest one and I will have a look ASAP. Indeed, -01 is still current; I've been waiting for more review comments (like your message!) to address before preparing the next draft version, but there haven't been much so far. > All the best, > > Lars > > ... > > -- > Dr. Lars G. Svensson > Deutsche Nationalbibliothek / Informationstechnik > http://www.dnb.de/ > l.svensson@dnb.de Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From internet-drafts@ietf.org Thu Jan 19 13:41:43 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB4F21F8491; Thu, 19 Jan 2012 13:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDlsZT+OZfBF; Thu, 19 Jan 2012 13:41:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2940421F847B; Thu, 19 Jan 2012 13:41:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120119214143.9028.60947.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2012 13:41:43 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 21:41:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Worki= ng 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-02.txt Pages : 20 Date : 2012-01-19 National Bibliography Numbers, NBNs, are widely used by the national libraries and other organizations in order to identify various resources such as digitized monographs. Generally, NBNs may be applied to all kinds of 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 national libraries in several European countries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) is included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3188bis-nbn-urn-02= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3188bis-nbn-urn-02.= txt From A.Hoenes@TR-Sys.de Thu Jan 19 14:22:42 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0099C21F857A for ; Thu, 19 Jan 2012 14:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.224 X-Spam-Level: X-Spam-Status: No, score=-97.224 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG1NvWuMZ3Im for ; Thu, 19 Jan 2012 14:22:40 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9A88A21F8573 for ; Thu, 19 Jan 2012 14:22:39 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA164851709; Thu, 19 Jan 2012 23:21:49 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA04217; Thu, 19 Jan 2012 23:21:44 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201201192221.XAA04217@TR-Sys.de> To: urn@ietf.org Date: Thu, 19 Jan 2012 23:21:44 +0100 (MEZ) In-Reply-To: <20120119214143.9028.60947.idtracker@ietfa.amsl.com> from "internet-drafts@ietf.org" at Jan "19, " 2012 "01:41:43" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3188bis-nbn-urn-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:22:42 -0000 [[ speaking as a co-author ]] URN folks, A new version of the URN:NBN draft is available (cf. below). The most significant change from the -01 version is the removal of an unused feature from RFC 3188 -- non-ISO 3166 based NBN prefixes, in accordance with one of the basic principles of the IETF Standards Track: Don't standardize features that aren't used. This removal has been done based on feadback from the bibliographic community as collected by Juha; it has lead to some simplifications in the syntax and quite a bit of related text, and it will allow the unused registry for such NBN prefixes (maintained per RFC 3188 at the Library of Congress) to be abandoned eventually. One argument that has been pointed out was that the ISO 3166 MA has started to assign "pseudo country codes" to supranational bodies (in particular, EU), and such bodies could be envisioned as future candidates to host agencies with similar duties as national libraries, and hence candidates for future, a bit generalizied, use of NBNs. Further, significant effort has been put into a cleanup of terminology and textual clarifications, and many editorial details have been fixed according to the most recent style guide recommendations. At 19 Jan 2012 13:41:43 -0800, internet-drafts wrote: > 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-02.txt > Pages : 20 > Date : 2012-01-19 > > National Bibliography Numbers, NBNs, are widely used by the national > libraries and other organizations in order to identify various > resources such as digitized monographs. Generally, NBNs may be > applied to all kinds of 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 national libraries in several > European countries have implemented URN:NBN-based systems. > > This document replaces RFC 3188 and defines how NBNs can be supported > within the updated URN framework. A revised namespace registration > (version 4) is included. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt A HTMLized version of the draft and htmldiff's from the previous draft version are available from the IETF Tools site: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3188bis-nbn-urn-02 http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt Please review this draft thoroughly and send your comments to the urn list! Kind regards, Alfred. From prvs=03703817f0=bengt.neiss@kb.se Tue Jan 24 02:42:46 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2009E21F8517 for ; Tue, 24 Jan 2012 02:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ihaTihYBJYE for ; Tue, 24 Jan 2012 02:42:45 -0800 (PST) Received: from mspkb002.kb.se (mspkb002.kb.se [193.10.72.137]) by ietfa.amsl.com (Postfix) with ESMTP id ABDAC21F8514 for ; Tue, 24 Jan 2012 02:42:44 -0800 (PST) Authentication-Results: mspkb002.kb.se header.from=bengt.neiss@kb.se; domainkeys=neutral (no sig) From: Bengt Neiss To: "urn@ietf.org" Thread-Topic: Some initial thoughts on draft-ietf-urnbis-rfc3188bis-nbn-urn-02 Thread-Index: AczahKs/+ZCmcE2iQ7q+NjATeeTCaA== Date: Tue, 24 Jan 2012 10:42:40 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF06SRVVM305kblocal_" MIME-Version: 1.0 Received-SPF: none Subject: [urn] Some initial thoughts on draft-ietf-urnbis-rfc3188bis-nbn-urn-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 10:42:46 -0000 --_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF06SRVVM305kblocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all.. Just some initial thoughts on the new text... 1. In chapter 4.2. "Encoding Considerations...." the expressions "pri= mary prefix" as well as "secondary prefix" are introduced. I think we need = to rephrase this since "prefix" is the expression used otherwise in text. A= s it is written now there is a sentence that states that the NSS consists o= f three parts and then there is a list with four "parts"... (might be bette= r as "primary part of prefix", " secondary part of prefix" which occurs in = occurs in other places text). I think it should be similar to the text in "= Declaration of syntactic structure..." on page 12 - 13. 2. The sentence "Future NBN implementations SHOULD make the NBN strin= g case insensitive as well". Is this a relevant statement? Since it seems to be that the nbn_string may be case-sensitive depending on= syntax applied locally (ie. already implemented) and URN:s are persistent = the case-sensitivity of the nbn_string must always be taken into considerat= ion... 3. I think there is a need to work further on defining restrictions o= r evaluate the consequences of the current text. Will make a new post on so= me issues later.. Regards //Bengt --------------------------------------------------------- Bengt Neiss Kungl. Biblioteket / National Library of Sweden Phone: +46 (0)10 709 35 41 --_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF06SRVVM305kblocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all..

 

Just some initial thoughts on t= he new text…

 

1. &nbs= p;     In chapter 4.2. “= Encoding Considerations….” the expressions “primary prefi= x” as well as “secondary prefix” are introduced. I think = we need to rephrase this since “prefix” is the expression used = otherwise in text. As it is written now there is a sentence that states that the NSS co= nsists of three parts and then there is a list with four “parts”= ;… (might be better as “primary part of prefix”, “ = secondary part of prefix” which occurs in occurs in other places text= ). I think it should be similar to the text in “Declaration of syntacti= c structure…” on page 12 – 13. 

 

2. &nbs= p;     The sentence “Fut= ure NBN implementations SHOULD make the NBN string case insensitive as well= ”. Is this a relevant statement?
Since it seems to be that the nbn_string may be case-sensitive depending on= syntax applied locally (ie. already implemented) and URN:s are persistent = the case-sensitivity of the nbn_string must always be taken into considerat= ion…

 =

3. &nbs= p;     I think there is a need= to work further on defining restrictions or evaluate the consequences of t= he current text. Will make a new post on some issues  later..

 =

 

Regards

 

//Bengt

 

 

 

---------------------------------------------------------

Bengt Neiss

Kungl. Biblioteket / National Library of Sweden

Phone: +46 (0)10 709 35 41

 

--_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF06SRVVM305kblocal_-- From prvs=03703817f0=bengt.neiss@kb.se Tue Jan 24 02:43:13 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C063821F8550 for ; Tue, 24 Jan 2012 02:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMJrDTlDQsOl for ; Tue, 24 Jan 2012 02:43:13 -0800 (PST) Received: from mspkb001.kb.se (mspkb001.kb.se [193.10.249.137]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD7421F8530 for ; Tue, 24 Jan 2012 02:43:13 -0800 (PST) Authentication-Results: mspkb001.kb.se header.from=bengt.neiss@kb.se; domainkeys=neutral (no sig) From: Bengt Neiss To: "urn@ietf.org" Thread-Topic: A 'newbie' question on the terminology used in RFC:s Thread-Index: AczaeH1kN0Rz75QXQv2GNq0/S83Tjg== Date: Tue, 24 Jan 2012 10:43:10 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF1CSRVVM305kblocal_" MIME-Version: 1.0 Received-SPF: none Subject: [urn] A 'newbie' question on the terminology used in RFC:s X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 10:43:13 -0000 --_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF1CSRVVM305kblocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since I am new to IETF standardization and after reading draft-ietf-urnbis-= rfc3188bis-nbn-urn-02.txt there is a question I would like to ask.... In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'. Is t= his intentional and are there a difference in understanding lower-case vers= us upper-case words (ie. upper-case is interpreted as stated in RFC 2119 an= d lower-case is a less strict use of the word) or should the use of lower-c= ase words (in this case) be considered a 'typo' that should be corrected to= upper-case (and as such be interpreted according to RFC 2119)? Regards //Bengt --------------------------------------------------------- Bengt Neiss Kungl. Biblioteket / National Library of Sweden Phone: +46 (0)10 709 35 41 --_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF1CSRVVM305kblocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since I am new to IETF standard= ization and after reading draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there= is a question I would like to ask....

 

In the text 'SHOULD' and 'shoul= d' are used as well as 'MAY' and 'may'. Is this intentional and are there a= difference in understanding lower-case versus upper-case words (ie. upper-= case is interpreted as stated in RFC 2119 and lower-case is a less strict use of the word) or should the use of= lower-case words (in this case) be considered a 'typo' that should be corr= ected to upper-case (and as such be interpreted according to RFC 2119)?

 

 

 

Regards

 

//Bengt

 

---------------------------------------------------------

Bengt Neiss

Kungl. Biblioteket / National Library of Sweden

Phone: +46 (0)10 709 35 41

 

--_000_F52230A186DA59469E8E21CF80FE6D4D0F23DF1CSRVVM305kblocal_-- From julian.reschke@gmx.de Tue Jan 24 02:52:08 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8B321F8470 for ; Tue, 24 Jan 2012 02:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tymoCoy4CsjZ for ; Tue, 24 Jan 2012 02:52:08 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BCEDB21F8464 for ; Tue, 24 Jan 2012 02:52:07 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2012 10:52:05 -0000 Received: from p5DCC3EBD.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.189] by mail.gmx.net (mp018) with SMTP; 24 Jan 2012 11:52:05 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/pzQg9+IDpiUtexA9WElH2RATMLqaTnLDASdmkvH p0o4PGMhenfgEu Message-ID: <4F1E8D53.8040006@gmx.de> Date: Tue, 24 Jan 2012 11:52:03 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bengt Neiss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" Subject: Re: [urn] A 'newbie' question on the terminology used in RFC:s X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 10:52:08 -0000 On 2012-01-24 11:43, Bengt Neiss wrote: > Since I am new to IETF standardization and after reading > draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there is a question I would > like to ask.... > > In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'. > Is this intentional and are there a difference in understanding > lower-case versus upper-case words (ie. upper-case is interpreted as > stated in RFC 2119 and lower-case is a less strict use of the word) or > should the use of lower-case words (in this case) be considered a 'typo' > that should be corrected to upper-case (and as such be interpreted > according to RFC 2119)? The latter. It's best to avoid these lowercase variants. If you don't want to invoke RFC 2119, use "might", "can", "ought to", "advised"... From A.Hoenes@TR-Sys.de Tue Jan 24 06:22:23 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FA821F84F7 for ; Tue, 24 Jan 2012 06:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.387 X-Spam-Level: X-Spam-Status: No, score=-97.387 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7FnqIRcw4pD for ; Tue, 24 Jan 2012 06:22:22 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB0A21F84E7 for ; Tue, 24 Jan 2012 06:22:21 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA189444889; Tue, 24 Jan 2012 15:21:29 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA01865; Tue, 24 Jan 2012 15:21:27 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201201241421.PAA01865@TR-Sys.de> To: julian.reschke@gmx.de Date: Tue, 24 Jan 2012 15:21:27 +0100 (MEZ) In-Reply-To: <4F1E8D53.8040006@gmx.de> from Julian Reschke at Jan "24, " 2012 "11:52:03" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] A 'newbie' question on the terminology used in RFCs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:22:23 -0000 [[ speaking as author and document editor ]] Julian and Bengt, please see my inline comments below. On 2012-01-24, Julian Reschke wrote > On 2012-01-24 11:43, Bengt Neiss wrote: >> Since I am new to IETF standardization and after reading >> draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there is a question I would >> like to ask.... >> >> In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'. >> Is this intentional and are there a difference in understanding >> lower-case versus upper-case words (ie. upper-case is interpreted as >> stated in RFC 2119 and lower-case is a less strict use of the word) or >> should the use of lower-case words (in this case) be considered a 'typo' >> that should be corrected to upper-case (and as such be interpreted >> according to RFC 2119)? > > The latter. No. That is deliberate. 'should' and 'may' are perfect, plain english words. Only the fully capitalized versions carry the RFC 2119 semantics: --- start of quotes from RFC 2119 ---- 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ... 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) --- end of quotes from RFC 2119 ---- > It's best to avoid these lowercase variants. I do not share this opinion, in general. Avoiding the normal forms and semantics of everyday auxiliary verbs seems to be some kind of silly self-enforced "political correctness". In cases where text talks about very formal procedures however, I try to avoid the lowercase forms, just to avoid iterated discussions whether the capitalized form should be used, besides in one important case of circumstances: When the spirit of current normative text (from inside or outside the IETF) is referred to (yet not quoted literally, e.g. for reasons of potential copyright issues, or to allow future evolution of those documents), but the I-D/RFC text does not aim at overriding that 'foreign' normative text, I have been advised several times to keep the lowercase form. For instance, when reporting on requirements within the rfc3187bis and rfc3188bis drafts that are laid down in external standards (ISO 2108 for ISBN, National Library standards for NBNs) but carry on to fulfill generic URN requirements for the URN:ISBN and URN:NBN documents, the latter use the lowercase forms in order to avoid perceived attempts to override the applicable normative documents. > > If you don't want to invoke RFC 2119, use "might", "can", "ought to", > "advised"... There are lots of differences in the semantics that might [ no pun intended :-) ] make these choices less appropriate than "may", "should", or "must", in specific cases. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Tue Jan 24 06:38:02 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7021F8551 for ; Tue, 24 Jan 2012 06:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.141 X-Spam-Level: X-Spam-Status: No, score=-97.141 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWbSMZdeJdMV for ; Tue, 24 Jan 2012 06:38:01 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id BD74F21F8550 for ; Tue, 24 Jan 2012 06:38:00 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA189585829; Tue, 24 Jan 2012 15:37:09 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA01961; Tue, 24 Jan 2012 15:37:08 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201201241437.PAA01961@TR-Sys.de> To: bengt.neiss@kb.se Date: Tue, 24 Jan 2012 15:37:08 +0100 (MEZ) In-Reply-To: from Bengt Neiss at Jan "24, " 2012 "10:42:40" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Some initial thoughts on draft-ietf-urnbis-rfc3188bis-nbn-urn-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:38:02 -0000 [[ speaking as co-author and document editor of the rfc3188bis I-D ]] At 2012-01-24, Bengt Neiss wrote: > Hello all.. > > Just some initial thoughts on the new text... > > > 1. In chapter 4.2. "Encoding Considerations...." the > expressions "primary prefix" as well as "secondary prefix" are > introduced. I think we need to rephrase this since "prefix" is > the expression used otherwise in text. As it is written now there > is a sentence that states that the NSS consists of three parts and > then there is a list with four "parts"... (might be better as > "primary part of prefix", "secondary part of prefix" which occurs > in occurs in other places text). I think it should be similar to > the text in "Declaration of syntactic structure..." on page 12 - 13. We will look into this and straighten up the text in the next draft version. (The related text has undergone a lot of changes due to the dropping of the non-ISO 3166 prefixes, and admittedly the changes for this effort and the effort to better align the text in the registration template with the expanded prose have collided a bit.) > 2. The sentence "Future NBN implementations SHOULD make the NBN > string case insensitive as well". Is this a relevant statement? > Since it seems to be that the nbn_string may be case-sensitive > depending on syntax applied locally (ie. already implemented) and > URN:s are persistent the case-sensitivity of the nbn_string must > always be taken into consideration... The intent here was to refer to new usages of URN:NBNs, i.e. national libraries and institutions that newly establish and/or formalize NBNs and build national support services for URN:NBN for their ISO 3166 URN:NBN prefix. So there should not be backwards compatibility issues at the URN level, but of course legacy NBN usage within the scope of the future adoptors needs to be addressed, which might lead to a legitimate exemption of the "SHOULD" quoted above. Question to the list: Would you prefer to drop the quoted "SHOULD" recommendation ? > 3. I think there is a need to work further on defining > restrictions or evaluate the consequences of the current text. > Will make a new post on some issues later.. We are waiting for all kind of thoughts and text proposals! > Regards > > //Bengt > > --------------------------------------------------------- > Bengt Neiss > Kungl. Biblioteket / National Library of Sweden > Phone: +46 (0)10 709 35 41 Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From julian.reschke@gmx.de Tue Jan 24 07:03:23 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC59421F84D1 for ; Tue, 24 Jan 2012 07:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY5rt5BrkNcq for ; Tue, 24 Jan 2012 07:03:23 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9D88721F84D4 for ; Tue, 24 Jan 2012 07:03:15 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2012 15:03:13 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 24 Jan 2012 16:03:13 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+4rgMAhK64cufalSuoLQJ0s3GveNJfuJZ9Z07Oga W4YWf30xNVRN2r Message-ID: <4F1EC82F.1050406@gmx.de> Date: Tue, 24 Jan 2012 16:03:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201201241421.PAA01865@TR-Sys.de> In-Reply-To: <201201241421.PAA01865@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] A 'newbie' question on the terminology used in RFCs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:03:24 -0000 On 2012-01-24 15:21, Alfred � wrote: > [[ speaking as author and document editor ]] > > Julian and Bengt, > please see my inline comments below. > > On 2012-01-24, Julian Reschke wrote >> On 2012-01-24 11:43, Bengt Neiss wrote: >>> Since I am new to IETF standardization and after reading >>> draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there is a question I would >>> like to ask.... >>> >>> In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'. >>> Is this intentional and are there a difference in understanding >>> lower-case versus upper-case words (ie. upper-case is interpreted as >>> stated in RFC 2119 and lower-case is a less strict use of the word) or >>> should the use of lower-case words (in this case) be considered a 'typo' >>> that should be corrected to upper-case (and as such be interpreted >>> according to RFC 2119)? >> >> The latter. > > No. That is deliberate. > 'should' and 'may' are perfect, plain english words. > Only the fully capitalized versions carry the RFC 2119 semantics: > > --- start of quotes from RFC 2119 ---- > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > ... > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > --- end of quotes from RFC 2119 ---- > ... In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: (note the 2nd sentence) But yes, reasonable people disagree on this. The way of least resistance is not to use them. Best regards, Julian From juha.hakala@helsinki.fi Tue Jan 24 22:02:44 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B5921F85FB for ; Tue, 24 Jan 2012 22:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.762 X-Spam-Level: X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS3uR8CrevKk for ; Tue, 24 Jan 2012 22:02:43 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3636621F85F9 for ; Tue, 24 Jan 2012 22:02:40 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q0P62amW010401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jan 2012 08:02:37 +0200 Message-ID: <4F1F9AFC.5010805@helsinki.fi> Date: Wed, 25 Jan 2012 08:02:36 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alfred Hoenes References: <201201241437.PAA01961@TR-Sys.de> In-Reply-To: <201201241437.PAA01961@TR-Sys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Some initial thoughts on draft-ietf-urnbis-rfc3188bis-nbn-urn-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 06:02:44 -0000 Hello Bengt, Alfred & all, >> 3. I think there is a need to work further on defining >> restrictions or evaluate the consequences of the current text. Definitely! > We are waiting for all kind of thoughts and text proposals! I agree that there is a need to evaluate the present draft and carefully consider the impact it will have on NBN assignment and use. The same applies to the ISBN namespace registration, but that document is less challenging to write since the ISBN system is specified in great detail in the ISO standard 2108:2005 and related guidelines. On the level of the URN system as a whole, there shall not be many restrictions, since at the top level we must allow anything that any namespace might justifiably require in the future. We have spent some time on the list to find the limits of acceptability. URNs certainly do not need to be resolvable, and I have understood that there will be no absolute requirement for persistence either because, among other things, URNs can be assigned to things which are not persistent per se. Whether the identifier must be more persistent than the identified object itself is of course an interesting question which we do not need to solve (I hope). But URN namespaces can (and many will) specify more detailed rules. The identifier system itself may be the basis for this; for instance, bibliographic identifiers tend to be persistent and there is a good chance that they will remain actionable for quite some time. NBN will pose a challenge in this respect since it is not a single identifier system but a set of them, assigned primarily by the national libraries and their peers. Requirements specified in the namespace registration may, in the worst case, become counterproductive if we do not foresee correctly the ways in which NBNs will be used in the future. In the end of the day, feedback from the current and potential future users of NBNs is the best guarantee that the NBN namespace registration will make sense even five years from now. So, I look forward to text proposals from Bengt and other current and potential user of NBNs. The more people contribute to the content, the better. Best regards, Juha > > >> Regards >> >> //Bengt >> >> --------------------------------------------------------- >> Bengt Neiss >> Kungl. Biblioteket / National Library of Sweden >> Phone: +46 (0)10 709 35 41 > > > Kind regards, > Alfred. > -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From juha.hakala@helsinki.fi Wed Jan 25 04:33:27 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDCD21F8629 for ; Wed, 25 Jan 2012 04:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.246 X-Spam-Level: X-Spam-Status: No, score=-5.246 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deZEPahsrPSt for ; Wed, 25 Jan 2012 04:33:27 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id D303C21F861B for ; Wed, 25 Jan 2012 04:33:26 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q0PCXMgH006786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jan 2012 14:33:22 +0200 Message-ID: <4F1FF692.4090700@helsinki.fi> Date: Wed, 25 Jan 2012 14:33:22 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alfred Hoenes References: <201201241421.PAA01865@TR-Sys.de> In-Reply-To: <201201241421.PAA01865@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: julian.reschke@gmx.de, urn@ietf.org Subject: Re: [urn] A 'newbie' question on the terminology used in RFCs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 12:33:28 -0000 Hello, RFC 2119, which is the sole authority as regards this issue, uses (certainly intentionally) both upper-case and lower-case versions of these words, and these terms do have different semantics: > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation... I have followed the policy Alfred outlines below which is identical to the spirit of RFC 2119. In the I-Ds I have drafted must and MUST do not mean the same thing. IMHO it would be less clear to the reader what the relation between MUST and terms like have to, ought to, etc. would be. And there would be no place to check this. My conclusion from the discussion is that there is no need to change the current, RFC 2119 -based policy. I fail to see how any changes could make semantics more clear but there are definitely many ways to create a muddle by using terms which are not within the scope of RFC 2119. And IMHO we ought to (;-)) avoid such a situation. Alas, not all standards organizations follow an identical policy as IETF. For instance, if an RFC is published as an ISO standard, some subtle changes will be necessary. I have been asked to change a quote (!) from an RFC since the terminology in the quote did not match the ISO rules. Juha Alfred � wrote: > [[ speaking as author and document editor ]] > > Julian and Bengt, > please see my inline comments below. > > On 2012-01-24, Julian Reschke wrote >> On 2012-01-24 11:43, Bengt Neiss wrote: >>> Since I am new to IETF standardization and after reading >>> draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there is a question I would >>> like to ask.... >>> >>> In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'. >>> Is this intentional and are there a difference in understanding >>> lower-case versus upper-case words (ie. upper-case is interpreted as >>> stated in RFC 2119 and lower-case is a less strict use of the word) or >>> should the use of lower-case words (in this case) be considered a 'typo' >>> that should be corrected to upper-case (and as such be interpreted >>> according to RFC 2119)? >> The latter. > > No. That is deliberate. > 'should' and 'may' are perfect, plain english words. > Only the fully capitalized versions carry the RFC 2119 semantics: > > --- start of quotes from RFC 2119 ---- > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > ... > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > --- end of quotes from RFC 2119 ---- > > >> It's best to avoid these lowercase variants. > > I do not share this opinion, in general. > Avoiding the normal forms and semantics of everyday auxiliary verbs > seems to be some kind of silly self-enforced "political correctness". > In cases where text talks about very formal procedures however, > I try to avoid the lowercase forms, just to avoid iterated discussions > whether the capitalized form should be used, besides in one important > case of circumstances: > When the spirit of current normative text (from inside or outside the > IETF) is referred to (yet not quoted literally, e.g. for reasons of > potential copyright issues, or to allow future evolution of those > documents), but the I-D/RFC text does not aim at overriding that > 'foreign' normative text, I have been advised several times to keep > the lowercase form. For instance, when reporting on requirements > within the rfc3187bis and rfc3188bis drafts that are laid down in > external standards (ISO 2108 for ISBN, National Library standards > for NBNs) but carry on to fulfill generic URN requirements for the > URN:ISBN and URN:NBN documents, the latter use the lowercase forms > in order to avoid perceived attempts to override the applicable > normative documents. > > >> If you don't want to invoke RFC 2119, use "might", "can", "ought to", >> "advised"... > > There are lots of differences in the semantics that might [ no pun > intended :-) ] make these choices less appropriate than "may", > "should", or "must", in specific cases. > > > Kind regards, > Alfred. > -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From julian.reschke@gmx.de Wed Jan 25 04:47:41 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8021F8621 for ; Wed, 25 Jan 2012 04:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlmy9eiJG9ed for ; Wed, 25 Jan 2012 04:47:41 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BAFA821F8599 for ; Wed, 25 Jan 2012 04:47:40 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2012 12:47:38 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp066) with SMTP; 25 Jan 2012 13:47:38 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19pk+k7UbJpG8rFYezy5p2ePyRkgde+N9GJ/Hefgk eS/GEPrqmvvSSU Message-ID: <4F1FF9E2.7020800@gmx.de> Date: Wed, 25 Jan 2012 13:47:30 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Juha Hakala References: <201201241421.PAA01865@TR-Sys.de> <4F1FF692.4090700@helsinki.fi> In-Reply-To: <4F1FF692.4090700@helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] A 'newbie' question on the terminology used in RFCs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 12:47:41 -0000 On 2012-01-25 13:33, Juha Hakala wrote: > Hello, > > RFC 2119, which is the sole authority as regards this issue, uses > (certainly intentionally) both upper-case and lower-case versions of > these words, and these terms do have different semantics: > ... Again, reasonable people disagree on this, and you will questions about this again and again. The easiest fix is to avoid the issue by simply not using the lowercase variants. Best regards, Julian From juha.hakala@helsinki.fi Wed Jan 25 22:29:28 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57211E80CD for ; Wed, 25 Jan 2012 22:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZdlYt59RZyb for ; Wed, 25 Jan 2012 22:29:27 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id E834211E80BB for ; Wed, 25 Jan 2012 22:29:25 -0800 (PST) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q0Q6TLOi024607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jan 2012 08:29:21 +0200 Message-ID: <4F20F2C1.3010804@helsinki.fi> Date: Thu, 26 Jan 2012 08:29:21 +0200 From: Juha Hakala User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Julian Reschke References: <201201241421.PAA01865@TR-Sys.de> <4F1FF692.4090700@helsinki.fi> <4F1FF9E2.7020800@gmx.de> In-Reply-To: <4F1FF9E2.7020800@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] A 'newbie' question on the terminology used in RFCs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 06:29:28 -0000 Hello, Reasonable people such as Alfred prefer using lowercase variants, and do not believe that avoiding them would fix anything. Since there is no approach that everybody would accept (as this discussion has already shown) I think it is better to stick to the policy implicit in RFC 2119. It is unfortunate that standards are often written so that people, even after having actually red them, do not understand them in the same way. Revision of RFC 2119 is (fortunately) not on the charter of URNbis. But it seems to me that there is a need to clarify the RFC key word policy so as to make an end to this kind of semantic uncertainty which makes writing and understanding RFCs more difficult than it should be. Other standards communities I have been involved with do not have this kind of systemic terminological issues, although now and then some individual concepts have been difficult to nail down. For instance in the Dublin Core community we had hard times trying to agree on what a document like object is, and finally gave up and started using the term resource instead. IETF may not be able to agree on the ideal approach (even reasonable people can be stubborn and stick to their own views), but that will not be a problem of the URNbis. Within this WG the editors only need to make sure that all the documents produced follow the same key word policy. Juha Julian Reschke wrote: > On 2012-01-25 13:33, Juha Hakala wrote: >> Hello, >> >> RFC 2119, which is the sole authority as regards this issue, uses >> (certainly intentionally) both upper-case and lower-case versions of >> these words, and these terms do have different semantics: >> ... > > Again, reasonable people disagree on this, and you will questions about > this again and again. The easiest fix is to avoid the issue by simply > not using the lowercase variants. > > Best regards, Julian -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678