From nobody Tue Dec 9 11:35:08 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D981A037B for ; Tue, 9 Dec 2014 11:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RFcqIT0pwHY for ; Tue, 9 Dec 2014 11:35:06 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074031A0075 for ; Tue, 9 Dec 2014 11:35:06 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so1130344lbv.11 for ; Tue, 09 Dec 2014 11:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=smm9lDEq0pfUSmimPasnD2I/NwdL1h0kYX4otKlpVsI=; b=0kN8Y8WEFM6Y325PAvoqt8FOBLYd/6dEQkaVTeolUUtp4/8+xQ5Iidaok0sLGluH+h ZenvXqzqRRytBi2DqqJez4EwCWkJU8lsaPK0okJg5uEQL/hgNsgildWIJGzsiP5jwi9o jrvX+GiyixaVAiYDuO+Un4jY+l2jbJ3lOlfAc9ZYprBmMOB1zkVSmAkT3omakFZzeUsx Fg6k2j+sSNj4bEFN0an/d8L+AFPgnHubuepWV97fB0SS53FPjOucCyEvfbPbtCfHEh/B WMT3LbLsG5zun8NnxcYToBqEZf1MrFgGMsIZJZAjrZi2gxj+lDtUT1qpVu+H4CBZKodt iKLg== MIME-Version: 1.0 X-Received: by 10.112.12.65 with SMTP id w1mr107923lbb.68.1418153704543; Tue, 09 Dec 2014 11:35:04 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 9 Dec 2014 11:35:04 -0800 (PST) Date: Tue, 9 Dec 2014 14:35:04 -0500 X-Google-Sender-Auth: vrZOXL1uZ7MI3tsqxzEwli7Lurk Message-ID: From: Barry Leiba To: Melinda Shore , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/saz5WtpoTufQJcmunawjITL1qHo Subject: [urn] Change in urnbis chairs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 19:35:07 -0000 Alfred H=F6nes has not had the time necessary to act as urnbis chair for some while now. I very much appreciate the work he did for the working group in the past. Thank you, Alfred, for your service. Melinda Shore has agreed to take the chair reins[1] and to work with Andy to see the working group through to completion. Effective immediately, Melinda is Andy's co-chair. Please welcome her and work with her and Andy to finish the work that's really very close to being done. Barry, Applications AD [1] In Melinda's case, dog-sled reins, I guess. From nobody Tue Dec 9 17:54:54 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8851A6FF7 for ; Tue, 9 Dec 2014 17:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsHBx7FRm8oy for ; Tue, 9 Dec 2014 17:54:50 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43051A0092 for ; Tue, 9 Dec 2014 17:54:45 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fb1so1762412pad.13 for ; Tue, 09 Dec 2014 17:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lLK2pJ+gUnvuAh1QTAXVOlwh7p3+ge1K/S+u41g6YiA=; b=CIeZp4OaiY+gbjOtzvFiOy+e6MHAL40xiwffyZFoVgzEA5YDHhwNhuWE/yLdZ3ViAo RmouxDle4n3NVNwtjiCjA/9x/obRosiXQAlMCBH4hyk3qeCYn9XXkIoyy4uezFp0/e98 TPtjVm3VPjS/RAGoTrswO12cRdIBfCTFtXLN6LAoFhbxpsK3pbqwZMgOowO7wUsUHUL7 uiRj/O3ZtfgRD1p0i4E7UmzlyDpi9a3y1rmTiwzLbbtMHkKIohRLpd91TBicRlI6AkuG WhL0uosd8Sb7ov+Z0jp1kb72TfIQ8AI4a97CSO5c5KUt0A2JBDdv6FjOebWwYOFO+6G3 olSQ== X-Received: by 10.66.189.100 with SMTP id gh4mr2156516pac.131.1418176485191; Tue, 09 Dec 2014 17:54:45 -0800 (PST) Received: from spandex.local (216-67-120-90.dynamic.cdma.acsalaska.net. [216.67.120.90]) by mx.google.com with ESMTPSA id nx1sm83802pdb.85.2014.12.09.17.54.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 17:54:43 -0800 (PST) Message-ID: <5487A7E1.10003@gmail.com> Date: Tue, 09 Dec 2014 16:54:41 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Barry Leiba , =?ISO-8859-1?Q?Alfred_H=F6ne?= =?ISO-8859-1?Q?s?= , "urn@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/chbDr4YOEvklawRoQUaax1V6FEg Subject: Re: [urn] Change in urnbis chairs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 01:54:51 -0000 Hi, all - pleased to be here. I've been working primarily on security-related problems, but have a library degree and did some work on names and naming in a previous professional life. I'm looking forward to working with the group on getting the documents wrapped up and moved towards publication. Melinda From nobody Fri Dec 12 12:14:48 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751521A870D for ; Fri, 12 Dec 2014 12:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3yxe54kJ5N5 for ; Fri, 12 Dec 2014 12:14:41 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB4C1A6EF3 for ; Fri, 12 Dec 2014 12:14:24 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XzWb9-000BkL-HS; Fri, 12 Dec 2014 15:13:59 -0500 Date: Fri, 12 Dec 2014 15:13:54 -0500 From: John C Klensin To: Juha Hakala , =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , urn@ietf.org Message-ID: <7CE00C2F4CE2885B1DDE77D3@JcK-HP8200.jck.com> In-Reply-To: <546C807D.4030007@helsinki.fi> References: <546AE45B.1040901@helsinki.fi> <546B1118.4070404@it.aoyama.ac.jp> <546B2A2F.8090809@helsinki.fi> <546C709B.8090503@it.aoyama.ac.jp> <546C807D.4030007@helsinki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tMukkZVNbOgV5ZpbiLRplkwfRVk Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:14:44 -0000 Sorry I've been largely tuned out for the last month. Too many other things going on that had very short deadlines and that necessarily got in front of URNs in the queue. I will try to be fully caught up --and get a new version of the "syntax only" document posted-- within the next week (it would be sooner, but I have to spend half of it traveling). I'm glad to see that others seem to be making progress and want to welcome Melinda on board. Where I have something to say, I'm going to try to respond to threads and where they seemed to end up or break off, not individual messages. =20 Now, as to equivalence... >From my perspective, there are two important things to remember. They could lead to conflicting conclusions but I hope we can figure out a balance (and, fwiw, think that the current version of 2141bis may express that). First, the situation we have gotten ourselves into with URNs is that a lot of namespaces are going to be invented elsewhere and may be just URN instantiations of naming or identification systems invented and controlled elsewhere, many of them very widely well entrenched. If we establish anything resembling a URN-wide set of canonicalization rules (e.g., "remove hyphens") or strong syntax restrictions about anything that appears in the string once one gets past the NID (i.e., the NSS and anything that follows it, for which see elsewhere), we are going to end up, in big trouble or worse. Phrases like shooting ourselves in the foot apply. However, if carried to its logical conclusion, everything after the scheme name has to be treated as an opaque blob, modulo maybe case-insensitivity in the NID. None of the other URI syntax rules apply and, in particular, no special character, even "%", has special meaning that can be interpreted, or even parsed as an introducer of something specific, by a processor that doesn't know the details of the particular namespace. We considered that although not quite in those terms. It has a certain appeal and the "URNs are not URIs" approach can be seen as a less-extreme version of that thinking. The WG decided not to go that way, so fine. The other issue is that URNs are supposed to be about _names_. If one examines one of the parts of the RFC 3996 URI spec that led us to reach the "syntax only" conclusion, one finds a collection of equivalence tests with different degrees of stringency with schemes and/or processor able to choose among them (some readers think they constitute an ordered list with choices made about how far down the list to go, others think they are just a menu, but we don't need to deal with that further for URNs). However, the assumption is that, for most purposes, the ultimate equivalency test is to go retrieve the object to which the URI points: if two URIs point to the same object, then they are equivalent. URNs are, by definition, names. Equivalence tests have to be made on the names because there is no guarantee there is any object to be retrieved. Indeed, different applications of a given name may yield different objects (or information about objects, etc., etc.). In a more perfect world, we might have a typology of equivalence operators over the set of URIs. Then we could ban the standalone term "equivalent" and talk about foo-equivalence, bar-equivalence, and so on. For those who are fond of arguments about "persistent", we could probably do the same job for "change" (perhaps defined as "what cool URIs don't do"): alpha-change, beta-change,... Probably too late for that now and not this WG's job, at least if we want to accomplish anything before the end of the century. If we take the two issues above together and don't like the "opaque after the scheme name" approach, then we can state the current rule without using terms like "equivalent". The equivalence question can be restated as "for two URNs to be equal, the names must be identical except for case-independence in the scheme and NID identifiers. Then the question is what makes up the "name". I (and, at least at the moment, 2141bis) answer that question by saying that the "name" is the scheme id, the NID, and the NSS (either including or plus the p-component if it is present). f-components and q-components, if present, are supplemental, qualifying, or directive information that supplement the name but are not part of it. Whether p-, f-, or q-components are allowed is a per-NID issue. If a parser accepts one for an NID that can't make use of it, that is not a seriously bad thing although we probably should have some guidance about whether an NID-specific (or NID-knowledgeable) processor encounters one it doesn't understand should ignore it or take some other action. Of course, particular namespaces might impose somewhat different rules on the whole string, but that would be about URN-string-equivalence, not URN-equivalence. Now, in that context... =20 --On Wednesday, November 19, 2014 13:35 +0200 Juha Hakala wrote: >... > On 19.11.2014 12:27, "Martin J. D=C3=BCrst" wrote: >... >> But if we take ISBNs just as an example for a future >> registration, then I think it's a very valid idea to e.g. >> say that ISBNs can contain hyphens, but these are removed >> when constructing an urn:isbn: URN. It may not always be the >> best solution, but it would be strange to reject such as >> solution from the get-go. Actually, maybe not so strange. As a superficial example, I note that "D=C3=BCrst" and "Duerst" are equivalent. You have a strong and reasonable preference for the first but the observation that most people treat them as equivalent doesn't make them "the same". And mechanical rules about what to remove or transform don't work unless one wants to end up confusing the not-so-famous poet G=C3=B6the with the more famous Goethe. > IMO this is something which should be considered whenever a > URN namespace is registered. The ISBN community could afford > to be liberal since all applications which deal with ISBNs > know that hyphens are to be ignored when ISBNs are processed. > But some other communities may have valid reasons for > providing additional guidelines for how to express their > identifiers as URNs (that is, something that goes beyond the > simple percent encoding). Sure. For example, if we refuse to allow "/" in URNs (as the introducer for nominal p-components) we would give the portion of the DOI community that wants to embed their identifiers in URNs three choices: (1) Write the "/" character as %2F. (2) Declare a pox on our house and use "/" anyway (3) Return to denouncing URNs as an ill-conceived system developed by people who had an incomplete model and no clue. >From a certain amount of experience, I think the first is unlikely, as would following any suggestions we might make about an alternate character to be used for their namespace only. I'm not sure which of the other two is worse. When 2141 was written, it was possible to ignore DOI issues. Anyone who thinks we should be doing so today should be talking with the RFC Editor, the IAB, and the Nomcom. >>> and that can be done by creating namespace >>> specific rules for lexical equivalence which says that >>> hyphens must be ignored. >>=20 >> Yes, it can. But we should write our document so that the >> other choice (eliminating gratuitous equivalences by >> restricting the permitted syntax) is at least also >> permitted, if not preferred. Well, I think one can write a rule that is very similar to one we have used elsewhere. It is more or less that a given string has a preferred/canonical form, that the form looks like so-and-so for this particular namespace, and that using other forms is likely to cause bad behavior including some things not matching that probably should. But for us to go to, e.g., another standards body and say "despite the fact that your Standard allows these flexibilities in the identifiers it specifies, were are not going to allow them when those identifiers are embedded in URNs" strikes me as inviting one of those "and who do you think you are?" situations as well as a hunt for the protocol policeperson and the supporting army. >... > Valid and invalid / canceled ISBNs are tagged differently in > MARC 21 records. In this example > It is important to provide canceled ISBN since that ISBN is > often the one printed in the book. >... >> *020* *##**$z*0835200028 :*$c*$10.00 >> *020* *##**$a*0835200019*$q*pbk.*$c*$2.95/ >> / >... >>> It is important to show that they are equivalent (identify >>> the same resource) since both versions of the URN:ISBN may >>> be actionable in the Web. For instance, the publisher may >>> prefer to use the invalid identifier and libraries the >>> correct one. Again, let's distinguish between "equivalent using a certain criterion" (in this case, only one resource is associated with the two names) and "names are equal", which those strings clearly are not. Note also that I don't think p-components, much less f- or q-components, have anything to do with that. >... > In your example there is nothing wrong, according to the > catalogue of Der Deutschen Nationalbibliothek. The book just > happens to have both ISBN-10 and ISBN-13, which have different > check sum calculation algorithms. In the record retrieved by >=20 > = https://portal.dnb.de/opac.htm?method=3DsimpleSearch&query=3D978-= 1 > -449-32188-9 >=20 > neither ISBN has been tagged as invalid: they are in separate > tag 020 $a occurrences in the metadata record. And according > to the rules of the ISBN community, it is OK to give a book > both ISBN-13 and ISBN-10 (or generate automatically one from > the another). This is necessary during a transitory period > since some organizations may still have outdated systems which > cannot deal with ISBN-13. >...=20 > ISBN and other semantic identifiers make it easy for humans to > spot certain kinds of errors (for instance, it is easy to see > if there is a typo in the publisher code). Machines are rarely > capable of this kind of analysis because they do not dig deep > enough (for instance, they never compare the publisher name > and the publisher code in ISBN). Well, they could even if it is not the practice to do so. But I can't see any reason to try to turn that into a URN problem rather than a per-namespace one that is relevant only to processors for/using that namespace. best, john From nobody Fri Dec 12 13:11:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF031A7028 for ; Fri, 12 Dec 2014 13:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5u96iS0EiD8 for ; Fri, 12 Dec 2014 13:11:25 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23081A1B0D for ; Fri, 12 Dec 2014 13:11:24 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XzXUU-000BuE-9S; Fri, 12 Dec 2014 16:11:10 -0500 Date: Fri, 12 Dec 2014 16:11:05 -0500 From: John C Klensin To: "Henry S. Thompson" , Julian Reschke Message-ID: <7913B138FBE36A801B08B467@JcK-HP8200.jck.com> In-Reply-To: References: <546AF38B.40306@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MAvLNQV-cDHjx3XBKhivqXz_Bh0 Cc: urn@ietf.org Subject: Re: [urn] 2141bis Section 5 Conformance consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 21:11:31 -0000 --On Thursday, November 20, 2014 14:33 +0000 "Henry S. Thompson" wrote: > Julian Reschke writes: > >>> 5. URI Conformance >>> >>> >>> Because a URN is, syntactically, a URI under the "urn" >>> scheme, in theory a URN can be placed in any protocol >>> slot that allows for a URI (e.g., an XML namespace name >>> [XML-NAMES]). However, this does not imply that, >>> semantically, it makes sense in practice to place a URN >> >> maybe s/makes sense/always makes sense/ > > Yes, this is very important. >... >> It's not clear to me why it would be wrong to use a URN in >> a/@href. > > In fact, it's clear to me that it will often make sense to use > URNs in a/@href and even image/@src, and it will become > increasingly common to do so, if implementation of > registerProtocolHandler [1] becomes widespread. I note that > 'urn' is already specified as a whitelisted (i.e. open to have > a handler registered). >... Henry, Without having a strong position on the specifics of the a/@href question, we come back to the comment I made earlier. URNs may be just names, with no notion of an associated object. Even a URN namespace that is typically associated with objects, like the ISBN one, isn't obviously clear about that -- to go back to a discussion the WG had parts of a long time ago, sometimes an ISBN may be a reference to a book. It is still not a locator for a book. Through an indirection process, it might be used to find a copy of the book, but that indirection ("resolution") process is not inherently bound to the URN because the URN could also be used to find pictures of the binding of the book, a discussion of typestyles used in the book, and any number of other things. Now 3986 and the associated documents could have included the notion of either some recursion operations or two different kinds of URI, one of which (sometimes?) gets mapped into one of the others. elements could be expanded to include, not only a URI but instructions as to what to do with it (as far as I know, they have been -- I haven't been following that work). Or one could take a more strict "locator" point of view for a/@href and adopt the sort of slightly bizarre http://example.com/...?urn="..." model I discussed on-list and in Appendix B.3 of draft-ietf-urnbis-semantics-clarif-00. I'm ok with changing the statements to use "not always" and "may not be appropriate", but I'm opposed to this WG getting into an argument about what is or is not appropriate to include in a particular HTML element. Let the folks who are trying to produce and document new versions of HTML sort that out, specify whatever semantics make sense to them, and, if they can figure out in a sufficient generic way what they want to do with URNs, more power to them. best, john From nobody Fri Dec 12 15:34:57 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986DC1A0025 for ; Fri, 12 Dec 2014 15:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2mJvQTVaFYC for ; Fri, 12 Dec 2014 15:34:54 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0691A1A000D for ; Fri, 12 Dec 2014 15:34:54 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XzZjY-000CJj-O4; Fri, 12 Dec 2014 18:34:52 -0500 Date: Fri, 12 Dec 2014 18:34:47 -0500 From: John C Klensin To: Andrew Newton , urn@ietf.org Message-ID: <1989450B7C37B1678167F6D5@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/7kmQVC9qJD7hTuSQ03ziC7k_g7o Subject: Re: [urn] 2141bis Section 7.1 question X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 23:34:55 -0000 --On Monday, November 17, 2014 09:13 -1000 Andrew Newton wrote: > In 2141bis Section 7.1, the fourth bullet reads like this: > > 4. The scope of the namespace (public vs. private, global > vs. local to a particular organization, nation, or > industry). For example, a namespace claiming to deal > in "national identification numbers" ought to have a > global scope and address all identity number > structures, whereas a URN scheme for a particular national > identification number system would need to handle only the > structure for that nation's identity numbers. > > The example is driving me crazy at it seems to be using the > same situation but suggesting two different outcomes. Am I > just not reading that correctly? Yes, you are not reading it correctly. The first example would presumably have the country and/or identity scheme identification somewhere in the NSS or supplemental supporting information, and hence might be something like (exaggerating for clarity): urn:GlobalNationalIDNumberSystem:<3166Alpha2CountryCode>/ or, if one established a typology of such codes _and_ they didn't overlao within a type, urn:GlobalNationalIDNumberSystem:/ and, it they might overlap, urn:GlobalNationalIDNumberSystem:/<3166CountryCode>/ Note that I have chosen to use a p-component above. One could imagine other systems, but, IIR, some national code systems use the ":" character. Whether we could successful tell/get people to not do that is something I addressed in an earlier message today. Now A particular nations's identity number system (making up an example involving the US because we don't have one) might look more like urn:USANationalIdentifierNumber:NNNNNNNNNNNNN Suggestions for how to make the text more clear are, of course, welcome. john From eb2mmrt@gmail.com Wed Dec 17 14:59:49 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1A1A0024 for ; Wed, 17 Dec 2014 14:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZA-Y1cIj0WZ for ; Wed, 17 Dec 2014 14:59:48 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3351A000A for ; Wed, 17 Dec 2014 14:59:48 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so39610lab.20 for ; Wed, 17 Dec 2014 14:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=QE39jsgBdhr2PLELJG47mw5nDF1TW0QyJLQEybcTKlk=; b=ZIdvhr9rex7jB0nV58ePGitXYTsH/nXQ1XuvARSwJ5KokVNZAhEH6+fUzeAAVrWrxS 0e9It2Z9urJPx5xK5Y1XxRssD4Zr50P0ULg3bQERUACN+oARN0qAeip+ymHoifwXXlhT PMHls+ifkwMFUfMPMeQkfFYJhaao8hhpw80vpTmb91bdXSuoGQWok5+HezyzNHBYc39g 5gjKTVsR8T2ES9wm0XzUCshWuxPcqZ/1mnHVof1++jLPLdMMv48Ob+ps29NYf8XDIapZ Equyv0OmRxdsOynohUYr83U0Qg2dw/fvzMvObitjIwpZ43PdALJVrt367sMThuVAB5ES KXmA== MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr44210709lbb.6.1418857186725; Wed, 17 Dec 2014 14:59:46 -0800 (PST) Sender: eb2mmrt@gmail.com Received: by 10.25.154.144 with HTTP; Wed, 17 Dec 2014 14:59:46 -0800 (PST) Date: Thu, 18 Dec 2014 07:59:46 +0900 X-Google-Sender-Auth: mKwBbPrbWoS43PiEKDH_SP29zpc Message-ID: From: MURATA Makoto To: urn@ietf.org Content-Type: multipart/alternative; boundary=001a11c341c89a1794050a716e3a Archived-At: http://mailarchive.ietf.org/arch/msg/urn/kz-wQ1DL6ZfFybYjQ4Y1wuOsenk Subject: [urn] p-component, q-component, and f-component for UUID URNs? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:08:19 -0000 --001a11c341c89a1794050a716e3a Content-Type: text/plain; charset=UTF-8 Dear colleagues, I am wondering if it is ok to use the p-component, q-component, and f-component for UUID URNs. 3.3 of draft-ietf-urnbis-rfc2141bis-urn-08 disallows them unless they are explicitly allowed. Unless specifically defined for a particular namespace, use of these components is disallowed .... RFC 4122 (A Universally Unique IDentifier (UUID) URN Namespace) does not say anything about paths, queries, or fragment identifiers. Thus, they are disallowed. However, suppose that an UUID URN references a resource whose media type allows fragment identifiers. Then, use of fragment identifiers is obviously useful. I can imagine that the p-component and q-component may be useful for some UUIDs such as those referencing to server-side programs. I am sorry if I have missed something. Regards, Makoto --001a11c341c89a1794050a716e3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear colleagues,

I am wonder= ing if it is ok to use the p-component, q-component, and
f-compon= ent for UUID URNs. =C2=A03.3 of draft-ietf-urnbis-rfc2141bis-urn-08
disallows them unless they are explicitly allowed.

<= div>=C2=A0 =C2=A0Unless specifically defined for a particular namespace, us= e of these
=C2=A0 =C2=A0components is disallowed ....
<= br>
RFC 4122 (A Universally Unique IDentifier (UUID) URN Namespac= e) does
not say anything about paths, queries, or fragment identi= fiers.=C2=A0 Thus,
they are disallowed.

= However, suppose that an UUID URN references a resource whose media
type allows fragment identifiers.=C2=A0 Then, use of fragment identifier= s
is obviously useful.=C2=A0 I can imagine that the p-component a= nd
q-component may be useful for some UUIDs such as those referen= cing to
server-side programs.

I am sorry= if I have missed something.

Regards,
Ma= koto

--001a11c341c89a1794050a716e3a-- From nobody Wed Dec 17 18:22:28 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9101F1A00B2 for ; Wed, 17 Dec 2014 18:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrBnflhHxNEI for ; Wed, 17 Dec 2014 18:22:22 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA41C1A00BB for ; Wed, 17 Dec 2014 18:22:21 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so95057igb.4 for ; Wed, 17 Dec 2014 18:22:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wtvjFhNFdQ8bBnLWcj8AbW9PC1E+mnQ55dBo5Zv1nBw=; b=DT2MsKuSpZF2ACMSO67okGODcW9hi1LX2G8ru6WfbUY9MIEnc9KYSOROIiBjUA3Kzx 8EAh6UycS+TweJWt7IbUm/UC5yME4xqcBI1QAhb/+7XIOHepivops7lnB5ymeHP9qQ4p akXg3gPButzaxlJYYW2mDMSPF0BwiMcn7Xz1aQVe3iqO6irkjvNornQdZGrttLI2Rv4e 6cNYpFgTn2ziIo8zlh14SPdPkt8BA4OXtfx37XKWVENAHD+2OADfpGYtW7qaJAVnJIP7 RTrJKx1Gy676zKqwZ6lUi6ToGMz8EZUyRUmFfABhwxIFWgI8LJO74I5bQAHwtolR6TeA jsjQ== X-Gm-Message-State: ALoCoQnwu3N9TEA5jtZfFPXvOV4M6P4FLf7wQEAGiUmSrxZWNUMQtsZ3tCWiSS+b2mBqwaIPey05 X-Received: by 10.107.11.195 with SMTP id 64mr42938789iol.51.1418869341422; Wed, 17 Dec 2014 18:22:21 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ci9sm3146540igc.1.2014.12.17.18.22.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 18:22:20 -0800 (PST) Message-ID: <54923A5C.6030308@andyet.net> Date: Wed, 17 Dec 2014 19:22:20 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: MURATA Makoto , urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/4XJCJqFUu48uHZkuBpwx0ddw_wg Subject: Re: [urn] p-component, q-component, and f-component for UUID URNs? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 02:22:25 -0000 On 12/17/14, 3:59 PM, MURATA Makoto wrote: > Dear colleagues, > > I am wondering if it is ok to use the p-component, q-component, and > f-component for UUID URNs. 3.3 of draft-ietf-urnbis-rfc2141bis-urn-08 > disallows them unless they are explicitly allowed. > > Unless specifically defined for a particular namespace, use of these > components is disallowed .... > > RFC 4122 (A Universally Unique IDentifier (UUID) URN Namespace) does > not say anything about paths, queries, or fragment identifiers. Thus, > they are disallowed. > > However, suppose that an UUID URN references a resource whose media > type allows fragment identifiers. Then, use of fragment identifiers > is obviously useful. I can imagine that the p-component and > q-component may be useful for some UUIDs such as those referencing to > server-side programs. > > I am sorry if I have missed something. Someone would need to update RFC 4122 in order for those components to be allowed. Peter From nobody Tue Dec 23 09:12:42 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5D1AD005 for ; Tue, 23 Dec 2014 09:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3tZCIemdmzW for ; Tue, 23 Dec 2014 09:12:38 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2171ACFFF for ; Tue, 23 Dec 2014 09:12:38 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y3T0f-0004pW-LO for urn@ietf.org; Tue, 23 Dec 2014 12:12:37 -0500 Date: Tue, 23 Dec 2014 12:12:32 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/QQeyXjotr7bLfP5CIE-L-iLzq0I Subject: [urn] 2141bis questions - (1) Section 3.2 Namespace specific string syntax X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:12:40 -0000 Hi. Since almost no one else seems to be doing so, I've made a careful pass through 2141bis-08 looking for things it doesn't seem to address that have been discussed on this list or elsewhere in the WG in the past. Some of what I've found appears to be just editorial. I'll summarize those to the list before Peter and I start making changes to see if anyone disagrees and thinks they are substantive. But there are some substantive things that, IMO, deserve discussion and review. This note is the first of a series that will address those, one at a time and in separate threads. This group of comments are entirely based on draft-ietf-urnbis-rfc2141bis-urn-08. Section 3.2 Namespace specific string syntax, doesn't seem completely clear when p-, q-, or f-components are possible, nor is it clear about any syntax issues within those components. Anyone have opinions about what should be said, or do Peter and I need to take a guess at this? If you do have opinions, text would be ideal along with explanation/ justification. john From nobody Tue Dec 23 09:13:52 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95E51ACFEF for ; Tue, 23 Dec 2014 09:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKC0xX2hmH0w for ; Tue, 23 Dec 2014 09:13:50 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C0D1ACFDC for ; Tue, 23 Dec 2014 09:13:50 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y3T1p-0004pp-R2 for urn@ietf.org; Tue, 23 Dec 2014 12:13:49 -0500 Date: Tue, 23 Dec 2014 12:13:44 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oKz4DISOK4nRQtrnHM7wGqeJEN8 Subject: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:13:51 -0000 In section 3.3.2 on q-component, it seems reasonable to add a bit of explanation, thereby providing some protection from people who might assume they know what 3986 says without checking it (especially given the ABNF issues with that document). I propose something like: "Note that "?" is not a special character after its first instance introduces a q-component (assuming one is allowed by the namespace). "?" appearing later in a q-component or in an f-component does not require %-escaping except as required on a per-namespace basis." Is that roughly correct? What we want? There is also another issue with that paragraph. Given the "syntax only" principle, it is not clear that unquoted "?" must be prohibited from appearing in the NSS and/or p-component (if we think that is distinct). The argument for prohibiting it is potential confusion. The argument for allowing it is that it might be needed for externally-defined name spaces for which %-encoding would either be clutter or actually problematic. What is the WG's pleasure? john From nobody Tue Dec 23 09:32:05 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15E1A1B35 for ; Tue, 23 Dec 2014 09:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuHhPBODCejx for ; Tue, 23 Dec 2014 09:32:02 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB621A1A8F for ; Tue, 23 Dec 2014 09:32:02 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y3TJR-0004tq-2b for urn@ietf.org; Tue, 23 Dec 2014 12:32:01 -0500 Date: Tue, 23 Dec 2014 12:31:56 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/uGeL91p7xO1B6y4o3OXTPy52jiI Subject: [urn] 2141bis questions - (3) Section 4.1 "normalization" comment X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:32:03 -0000 Hi. Section 4.1 ("Procedure"), third paragraph, talks about "applying case normalization". There is no such thing in Unicode even though 3986 has a section of that title . It would be an editorial issue and easily fixed if I was sure what the WG intended, but I'm not. It isn't clear whether Section 6.2.2.1 of RFC 3986 is included or excluded by a "syntax only" policy. Even if it is included, it generically applies to the two characters that follow "%" in percent-encoding, the scheme name, and the host (the latter being irrelevant for URNs). Other components are specified on a per-scheme basis. Independent of the terminology it uses, the text in 3986 specifies that the characters that follow "%" in percent-encoding must be converted to upper case and that scheme names (and the host component) must be converted to lower case. The text in the current version of 2141bis says (construct 4) that the p-component is to have "case normalization" applied, but doesn't specify upper case, lower case, or case folding. We either need to get p-components out of that list, making them case-sensitive, or need to choose one of the three. Note that, because of situations like "what happens with accent marks when converting to upper case" (and its opposite of an accent-free upper case character potentially mapping to two or more lower case characters), arguments that position-dependent characters in Arabic or other scripts should really be treated as case variations, etc., this is not a trivial decision. If we care about consistency with the reasoning of IDNA and probably PRECIS, we should probably (but only probably) preserve case-sensitivity as much as possible. john From nobody Tue Dec 23 09:44:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5A1A1A96 for ; Tue, 23 Dec 2014 09:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMeLv4R6ILe1 for ; Tue, 23 Dec 2014 09:44:45 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378C11A1A75 for ; Tue, 23 Dec 2014 09:44:45 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y3TVk-0004v4-9O for urn@ietf.org; Tue, 23 Dec 2014 12:44:44 -0500 Date: Tue, 23 Dec 2014 12:44:39 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/zh-_5NfmitCOrkcfanBc3x2SYpg Subject: [urn] 2141bis questions - (4) Section 5 on URI Conformance X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:44:46 -0000 We've had some on-list discussion about the wording of parts of Section 5 of 2141bis. I think we've reached general agreement about some of the language in the first paragraph or two and Peter or I will post draft text sometime soon to see if it is actually what the WG intends. However, a careful reading of the rest of that section turns up several related issues. Before trying to write and circulate draft text, I want to verify that it is the view of the URN WG that precise rules (and constraints and restrictions) for the use of URNs embedded in various contexts is the job of the definitions for those contexts, not 2141bis or other generic URN documents. On particular, while 2141bis can (and probably should) offer general guidance for issues a context/usage designer should think about, decisions about what can, or cannot, appear with href in elements are a matter for HTML, not this specification. Is the WG in enough agreement about that to allow us to draft text? john From nobody Tue Dec 23 09:49:24 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E791A1A75 for ; Tue, 23 Dec 2014 09:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7zuwiJryrI1 for ; Tue, 23 Dec 2014 09:49:22 -0800 (PST) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065DF1A03A8 for ; Tue, 23 Dec 2014 09:49:22 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id fp1so8224286pdb.19 for ; Tue, 23 Dec 2014 09:49:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NRlbJqyBkxQFFyM7d6wBB9KJtP6IBG3GMp1orGbvhH4=; b=Nyi8CKwEKn+tRJVyG+CG4TjfciIidl/j21HTnTbMeTHaUeypa3/YJFMrXYG/e3Hdkc ncXAyG4uHuQUIMyidTfNapJJ4XP5GM6TF0b7Nwvg5GWTgyNDNULT7q/NC6Pz1p4SEpRv i2LegBHrFYihYIq1c9kA/RHfgu+S+nR9aGG2vBOFRBOH+rhB2zZ+IXyT8OBkqRn0BCZO av9UDEfd35FxAjHe9u1ZwqZzW3QzG4UjCDeD8AR4Z0d2zYEOQgg2/KFuT2xSZ4F2jrT7 kRncBj5tC6Mf8vxefHDPHOr27ewXKy3JzMYNExAQHAgUjaHbefwWa52TdyN0X6orgTTS jKww== X-Gm-Message-State: ALoCoQmSfdMxvAG2ajXbHhS2m+2CDZ3ZB1x8ec/W/dq1nvjIgrTpxYHCfGXBZFW0VZ9XvpBGTH8n MIME-Version: 1.0 X-Received: by 10.69.3.194 with SMTP id by2mr46168605pbd.130.1419356961620; Tue, 23 Dec 2014 09:49:21 -0800 (PST) Received: by 10.66.135.164 with HTTP; Tue, 23 Dec 2014 09:49:21 -0800 (PST) X-Originating-IP: [2001:500:4:15:94f3:97f:2ca0:c457] In-Reply-To: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> Date: Tue, 23 Dec 2014 12:49:21 -0500 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: multipart/alternative; boundary=047d7b5db42081df32050ae5cb21 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/XnpZqpbSNd0XgJBgjjnlkqHml-c Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:49:23 -0000 --047d7b5db42081df32050ae5cb21 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 23, 2014 at 12:13 PM, John C Klensin wrote: > "Note that "?" is not a special character after its > first instance introduces a q-component (assuming one is > allowed by the namespace). "?" appearing later in a > q-component or in an f-component does not require > %-escaping except as required on a per-namespace basis." > > Is that roughly correct? What we want? > Using my possibly faulty recollection of 3986, I thought "?" was a general delimiter and those needed to be escaped no matter what when not being used as a delimiter. From an implementation standpoint, certainly escaping "?" everywhere is easier than only escaping it in certain portions of the UR*. -andy --047d7b5db42081df32050ae5cb21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 23, 2014 at 12:13 PM, John C Klensin <john-ietf@jck.com>= ; wrote:
=C2=A0 =C2=A0 =C2=A0 "Note that "= ;?" is not a special character after its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 first instance introduces a q-component (assumi= ng one is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 allowed by the namespace).=C2=A0 =C2=A0"?&= quot; appearing later in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 q-component or in an f-component does not requi= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 %-escaping except as required on a per-namespac= e basis."

Is that roughly correct?=C2=A0 What we want?

&l= t;chair hat=3D"off"/>

Using my possibly faulty recollection of 3986,= I thought "?" was a general delimiter and those needed to be esc= aped no matter what when not being used as a delimiter. From an implementat= ion standpoint, certainly escaping "?" everywhere is easier than = only escaping it in certain portions of the UR*.

-andy
--047d7b5db42081df32050ae5cb21-- From nobody Tue Dec 23 09:55:00 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5480F1A1A75 for ; Tue, 23 Dec 2014 09:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yDJBTBlhyw8 for ; Tue, 23 Dec 2014 09:54:58 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D501B1A1A66 for ; Tue, 23 Dec 2014 09:54:57 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y3Tfc-0004y0-PZ for urn@ietf.org; Tue, 23 Dec 2014 12:54:56 -0500 Date: Tue, 23 Dec 2014 12:54:51 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/LP0En012xuyyV77Psn5bf6BXMLo Subject: [urn] 2141bis questions - (5) Section 6 and valid and invalid URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:54:59 -0000 Section 6 ("URN Namespaces") of 2141bis talks about valid and invalid, formal and informal URNs. The combinations are a little confusing, especially since the current text makes a string that generally follows the URN syntax but that uses an unregistered NID invalid. I think some clarification is in order and want to make sure the WG agrees. Hence: Question 1: It is our intent to keep URN-like objects based on unregistered namespace invalid, right? Question 2: The last paragraph of the Section 6 introduction (before Section 6.1 starts) disposes of "experimental" namespaces. I believe it should be made clear that continued use of such namespaces with URN-like syntax does not make them valid URNs (because they are unregistered). If anyone disagrees, please speak up not. john p.s. Probably more coming soon to help people celebrate the season, i.e., "Bah. Humbug". From nobody Tue Dec 23 10:32:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A001D1A1AA6 for ; Tue, 23 Dec 2014 10:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2FFkNT4Bqmc for ; Tue, 23 Dec 2014 10:32:03 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4F31A1A98 for ; Tue, 23 Dec 2014 10:32:03 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so6414268iec.36 for ; Tue, 23 Dec 2014 10:32:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KqTJ+Qw7Mglb70etivrnKh/7wTESJZ3q2oIYRoDnntk=; b=T+71eWhWpN4yU410BxcH/faWMWsC8V0EzL4sfNymz+DVfXat3AeBEMUR0bxP4wo0PY 6gpfn682WMMzrmCZIkqiksDBZLoLKrdWIpiEk+ZNVQzPMk3dm74d3jQoCIjzhK+jwMW2 +tXXR4VY6gyORspb8nfBNH0oZS88RwxApd1RepqlYQfJwVlxh09YmeD1rHMkxckbcbxI BW+2ZV3vm8+gRrRcP1v4MPZXS2rFMMuYrBdcVrC+UBSu1je8qEFQCWv3NVsb8ovW9fbL CWlDFi7sqqfKcTUYmoxUV+iRS4FWuyZgQtdM3+ijVrONhfsji7P/4mPS6FxfOQcTVg8F 4+XA== X-Gm-Message-State: ALoCoQl50s35GknAAKIujaqSQmBXPc8B5gOWrJduvfkmdoEvKuOcAm7LCInUyK1Sgqbcnak1iP9+ X-Received: by 10.107.26.8 with SMTP id a8mr26604205ioa.58.1419359522533; Tue, 23 Dec 2014 10:32:02 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o185sm10216257ioe.40.2014.12.23.10.32.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 10:32:01 -0800 (PST) Message-ID: <5499B521.80407@andyet.net> Date: Tue, 23 Dec 2014 11:32:01 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/8Ep-SCuwI-X-Y6sciyKtlIo5FYY Subject: Re: [urn] 2141bis questions - (1) Section 3.2 Namespace specific string syntax X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:32:05 -0000 On 12/23/14, 10:12 AM, John C Klensin wrote: > Hi. > > Since almost no one else seems to be doing so, I've made a > careful pass through 2141bis-08 looking for things it doesn't > seem to address that have been discussed on this list or > elsewhere in the WG in the past. Some of what I've found > appears to be just editorial. I'll summarize those to the list > before Peter and I start making changes to see if anyone > disagrees and thinks they are substantive. But there are some > substantive things that, IMO, deserve discussion and review. > This note is the first of a series that will address those, one > at a time and in separate threads. John, thanks for initiating these threads. > This group of comments are entirely based on > draft-ietf-urnbis-rfc2141bis-urn-08. > > Section 3.2 Namespace specific string syntax, doesn't seem > completely clear when p-, q-, or f-components are possible, As I understand it, the NSS is part of the assigned-name, so those components don't occur within the NSS. Perhaps did you mean to reference Section 3.3 for this note? Or by referencing Section 3.2 did you mean to imply that 2141bis needs to be more clear about rules or guidelines for when those components are allowed ("possible") in the context of a given namespace? > nor > is it clear about any syntax issues within those components. To date, we have simply pointed to RFC 3986 regarding the *syntax* of those components. Here again, we might provide some guidelines about how a given namespace would best handle syntax within those components. Or we could leave it completely up to the namespace definition, as long as the syntax is consistent with the RFC 3986 definitions. I would prefer the latter. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 23 10:41:08 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FB61A1AA6 for ; Tue, 23 Dec 2014 10:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-I7UZtt0vch for ; Tue, 23 Dec 2014 10:41:04 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6721A1AAD for ; Tue, 23 Dec 2014 10:41:02 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so5920012igi.6 for ; Tue, 23 Dec 2014 10:41:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZnLt79Ji8p64N3hmbkgfkYVX3xCof929eKk3GO6eC1g=; b=edKmusrDQ5kHD9IgGYypHUsCpCFewhIHePqVJGIoBX9+dNtznJOsfRGCRwVIy/D0sY impv42px4BcrLlEJkx/mGWjK1fXl9O0EXg8gw54v5k3rbNkJ7J9119nS9DUAXrC1055P Ezl8nQL2nWbh2z+cC9KEPl/rGYzdey4kPnKA0MT89BV0gPJcDQj/ExywB515WyhnYk6M zplW346AlNUy1f7zMkDq91fLFsVcTtOASG5TZFGRvam1PX8mIsRmTfg1F9m51MvEUwzA 8ksgDnofPOgoy1/5vHQA1kANEN/2VMWmaVRVMWQnz2lCKXV1JbceM1r/85Hh61v8rWXT nanw== X-Gm-Message-State: ALoCoQl2WKy7mqNECRLFxr0XIqu67KzpaLGeyWC9lP0PgW8oHPM8LkzRbZ2AqtqfoXuNMmMgDCre X-Received: by 10.42.103.7 with SMTP id k7mr23065916ico.33.1419360061765; Tue, 23 Dec 2014 10:41:01 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o72sm10232126ioo.14.2014.12.23.10.41.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 10:41:01 -0800 (PST) Message-ID: <5499B73C.3070506@andyet.net> Date: Tue, 23 Dec 2014 11:41:00 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> In-Reply-To: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/TV-EGTjRcsDIY6jLDamWbL-AsNc Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:41:06 -0000 On 12/23/14, 10:13 AM, John C Klensin wrote: > In section 3.3.2 on q-component, it seems reasonable to add a > bit of explanation, thereby providing some protection from > people who might assume they know what 3986 says without > checking it (especially given the ABNF issues with that > document). I propose something like: > > "Note that "?" is not a special character after its > first instance introduces a q-component (assuming one is > allowed by the namespace). "?" appearing later in a > q-component or in an f-component does not require > %-escaping except as required on a per-namespace basis." > > Is that roughly correct? What we want? As I read RFC 3986, what you propose is indeed roughly correct as an informational note. > There is also another issue with that paragraph. Given the > "syntax only" principle, it is not clear that unquoted "?" must > be prohibited from appearing in the NSS and/or p-component I think it must be prohibited, given the ABNF definitions in RFC 3986 that we borrow here. NSS = 1*(pchar) p-component = "/" path-absolute path-absolute = "/" [ segment-nz *( "/" segment ) ] segment = *pchar pchar = unreserved / pct-encoded / sub-delims / ":" / "@" (no gen-delims allowed there) > (if > we think that is distinct). I think the p-component is not part of the NSS. namestring = assigned-name [ p-component ] [ q-component ] [ f-component ] assigned-name = "urn" ":" NID ":" NSS > The argument for prohibiting it is > potential confusion. The argument for allowing it is that it > might be needed for externally-defined name spaces for which > %-encoding would either be clutter or actually problematic. I would favor prohibiting it. -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 23 10:48:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF61A1AB9 for ; Tue, 23 Dec 2014 10:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1LtpARrUzCs for ; Tue, 23 Dec 2014 10:48:07 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACA61A1AB3 for ; Tue, 23 Dec 2014 10:48:07 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so6346195iga.14 for ; Tue, 23 Dec 2014 10:48:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A4JAppnCSxddSrcYSIDrYQOqQF8DGVYB6JjDnAMY5aE=; b=lY/sPm5VT7eBHodBVv45v7UDvsorS9lpsHB95EnLodrBG3AuRdbYx4Rs4qf0LjZhMH 8pcbk/+wG/tpO8Ljp3KCz3I23PNXXkQ8L8OiZ+Yh2AiCzqc6SORcgxsRvo70nwZvdAqu EuB/PcJsRqRBAYta079ZXaVcfg6QCrg6Wa+YSqetnQUl+zzvt/X4oQTpr/1RDP6pdda5 HlMnEw2ugkkO/A9F7YKfEZFPXmrrqAgDZTRUYbcJXLSVdNpfT2u3dZoMiXjNljQz9did P8a4RbUkiw07t82kH0pHOgakfS2+5uYuqQ7+NDpgCKI4/8Q72CtZ2q/XcdEamKlYEoVd ADQg== X-Gm-Message-State: ALoCoQkiYgUpCBOg7QRulRF1PqSG6zh3CeSG1avKCfVDmXRGSC01yR+NiyiU7xhEiUCLYf/F7rp4 X-Received: by 10.50.138.107 with SMTP id qp11mr13385863igb.46.1419360486494; Tue, 23 Dec 2014 10:48:06 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o185sm10234071ioe.40.2014.12.23.10.48.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 10:48:05 -0800 (PST) Message-ID: <5499B8E5.7080909@andyet.net> Date: Tue, 23 Dec 2014 11:48:05 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/0IP2SEkVyQm_QqVcV_okKg-hQfg Subject: Re: [urn] 2141bis questions - (3) Section 4.1 "normalization" comment X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:48:08 -0000 On 12/23/14, 10:31 AM, John C Klensin wrote: > Hi. > > Section 4.1 ("Procedure"), third paragraph, talks about > "applying case normalization". There is no such thing in > Unicode even though 3986 has a section of that title . But we are supporting only the ASCII range of Unicode. We need to get our terminology right, but that does simplify matters significantly. > It > would be an editorial issue and easily fixed if I was sure what > the WG intended, but I'm not. It isn't clear whether Section > 6.2.2.1 of RFC 3986 is included or excluded by a "syntax only" > policy. Even if it is included, it generically applies to the > two characters that follow "%" in percent-encoding, the scheme > name, and the host (the latter being irrelevant for URNs). > Other components are specified on a per-scheme basis. That is my understanding as well. > Independent of the terminology it uses, the text in 3986 > specifies that the characters that follow "%" in > percent-encoding must be converted to upper case and that scheme > names (and the host component) must be converted to lower case. > The text in the current version of 2141bis says (construct 4) > that the p-component is to have "case normalization" applied, > but doesn't specify upper case, lower case, or case folding. > We either need to get p-components out of that list, making them > case-sensitive, or need to choose one of the three. I lean toward removing it from the list, but I'd like to think about it more. > Note that, > because of situations like "what happens with accent marks when > converting to upper case" (and its opposite of an accent-free > upper case character potentially mapping to two or more lower > case characters), arguments that position-dependent characters > in Arabic or other scripts should really be treated as case > variations, etc., this is not a trivial decision. ASCII only mitigates that concern. We are using the syntax from RFC 3986, not RFC 3987. > If we care > about consistency with the reasoning of IDNA and probably > PRECIS, we should probably (but only probably) preserve > case-sensitivity as much as possible. For p, q, and f components, I think that makes the most sense. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 23 10:49:37 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826941A1AB9 for ; Tue, 23 Dec 2014 10:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mORowMiF5JNV for ; Tue, 23 Dec 2014 10:49:35 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178351A1AB3 for ; Tue, 23 Dec 2014 10:49:35 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rp18so6230150iec.24 for ; Tue, 23 Dec 2014 10:49:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q0yoLcAZUx6t/iYHveQAYTBaCacN793lM+qpe6NpJuQ=; b=KYmenzMHvIrLgreW264TzVxKjdVKsA29b8uwlZAWACMtS9HrEUIJycGzJhmcak4RMq aFY3J+pihdMFi/Au/1mAVKafaM2NssQdNrvPq41x7Lf+A8vPEmL4k6tzzsbyydi/MKhy l/to8aJT4tEFEgSLObk8uGA58NksmHf/6VywRxrEUOGoYp1SzKvih8hQ8/ufKKUIqJBn oyxqr2bhLLUzxBlObiS+3YoPfC0QYYu2LbUwSiFW3HswEDxs7J7MnAH69vWTOD0CnCiW gcNOfTHwQlckfSqXdNP5TUThFw2RBoywTnItXNmCv8sQVnicWLK0PhkwiWAlqwDJuUF0 zLsQ== X-Gm-Message-State: ALoCoQkP9DvcyTPKrFRAn8LQ2LbWOLvigtZSwwk/rrPKfzbmVBrieWXj0t9rDxoPtYxYSISWrBrE X-Received: by 10.107.135.163 with SMTP id r35mr26898133ioi.25.1419360574582; Tue, 23 Dec 2014 10:49:34 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id i19sm6668867igh.6.2014.12.23.10.49.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 10:49:34 -0800 (PST) Message-ID: <5499B93D.5050209@andyet.net> Date: Tue, 23 Dec 2014 11:49:33 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> In-Reply-To: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/coeqdeTdgBSJQu743ZOUCTp60bo Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:49:36 -0000 On 12/23/14, 10:44 AM, John C Klensin wrote: > We've had some on-list discussion about the wording of parts of > Section 5 of 2141bis. I think we've reached general agreement > about some of the language in the first paragraph or two and > Peter or I will post draft text sometime soon to see if it is > actually what the WG intends. > > However, a careful reading of the rest of that section turns up > several related issues. Before trying to write and circulate > draft text, I want to verify that it is the view of the URN WG > that precise rules (and constraints and restrictions) for the > use of URNs embedded in various contexts is the job of the > definitions for those contexts, not 2141bis or other generic URN > documents. I would think so. > On particular, while 2141bis can (and probably should) offer > general guidance for issues a context/usage designer should > think about, decisions about what can, or cannot, appear with > href in elements are a matter for HTML, not this > specification. Very much +1. > Is the WG in enough agreement about that to allow us to draft > text? Yes, please. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 23 10:52:23 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118F91A1AB9 for ; Tue, 23 Dec 2014 10:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H52nZQs804p5 for ; Tue, 23 Dec 2014 10:52:21 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646361A1AB3 for ; Tue, 23 Dec 2014 10:52:21 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so6356206iga.2 for ; Tue, 23 Dec 2014 10:52:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Vm8UaMHvO59DsbvHbAGcz2AyiTJjHuXxXauEU5BqohA=; b=iWlLY/Cw11NGWszIuCPu1sm/eOTIrR+fb/JNcS1A6QjF+madPipnwVfgugCposSkZr m8lj4ymq9fKgNl+AAdgzLo1qRL3TrbJJfKx3ShYM9hqtsIuQDOMjKDMj2AnC2T/dubh5 WmYWFfek+DfchJtHOuN/UJOC29RkRDP3zrzq19P66PHICgsjyLQas6JCXezB7i0156Ju wv8UoTGz9ExR50dJ29UzgF1ge7zWGdScxnvEWiKHbSMFqRUiP58fqaqc8hPNZNFVcQTt 8YEJfsu+f+B8VR7++xEoM6GcSMmv6HC9OQrAQuspgddPy761wG8Yhlwt6AGYrFsmafUj vBIg== X-Gm-Message-State: ALoCoQmxnfty7PudVcPqTnaVZXL28aX/BwqU/aIQt+qpYgiK8IebMV79wdwh3a5iT15n64JYEmxD X-Received: by 10.50.9.33 with SMTP id w1mr9354021iga.41.1419360740882; Tue, 23 Dec 2014 10:52:20 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id cl9sm6677263igb.0.2014.12.23.10.52.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 10:52:20 -0800 (PST) Message-ID: <5499B9E4.8010609@andyet.net> Date: Tue, 23 Dec 2014 11:52:20 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/RLIHPBfhxqkRTk4Y0dOV0uAX4eI Subject: Re: [urn] 2141bis questions - (5) Section 6 and valid and invalid URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:52:23 -0000 On 12/23/14, 10:54 AM, John C Klensin wrote: > Section 6 ("URN Namespaces") of 2141bis talks about valid and > invalid, formal and informal URNs. The combinations are a > little confusing, especially since the current text makes a > string that generally follows the URN syntax but that uses an > unregistered NID invalid. I think some clarification is in > order and want to make sure the WG agrees. Hence: > > Question 1: It is our intent to keep URN-like objects based on > unregistered namespace invalid, right? I think so. URNs are a managed process. If someone starts creating URNs under urn:klensin:* and no one ever registered "klensin" as a NID, then they're out of bounds. > Question 2: The last paragraph of the Section 6 introduction > (before Section 6.1 starts) disposes of "experimental" > namespaces. I believe it should be made clear that continued > use of such namespaces with URN-like syntax does not make them > valid URNs (because they are unregistered). If anyone > disagrees, please speak up not. Agreed. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 23 10:54:04 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D491A1AB9 for ; Tue, 23 Dec 2014 10:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mJdgwZyLUmo for ; Tue, 23 Dec 2014 10:54:02 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB811A1ABC for ; Tue, 23 Dec 2014 10:54:02 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id z20so5889948igj.10 for ; Tue, 23 Dec 2014 10:54:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=E5Y95ovknuvKrC0Fp+BHejXnSCARnPWxV+NNKjL1kZQ=; b=GzMnPzJhy9CqVxo7dULLSIcRC/XmoWWTmemegIwTHKBd6Bc0XkGwJLRS3jWapgryO3 AtBo+bSnkaA/gZjejrTm1ocNmXbAHLUvi2hFMcjdTYdnkK9X6VdTx5YFwKQ8wQMniWeg kthv6NW4FDjg5hXGtG29Fbq/OgmYl9biAaK1Au7IIhajF/Bzul7vEoatCY6v7DccqWRd JWRYYvQLVsm0kDeNFMsbN16rDOZJQf6OG7kGB6C7kjMnkKP9l2dQh5Km2Th0kfYx3wqo 5JghqjG5X3Z6ISsn2U+n+xm7ky76QDY1FbnnbW321Yyay4PND90AiIb19o3fONO0zP5k IHKw== X-Gm-Message-State: ALoCoQnfJnfkL89ni3oVq8Scla/K2CAGW2wRHs/Aig7Yp+zJpeavjSNuaPnMZv2SwMim99gaQ/2f X-Received: by 10.107.8.97 with SMTP id 94mr26764930ioi.91.1419360841484; Tue, 23 Dec 2014 10:54:01 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id pn2sm6661714igb.21.2014.12.23.10.54.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 10:54:01 -0800 (PST) Message-ID: <5499BA48.5060807@andyet.net> Date: Tue, 23 Dec 2014 11:54:00 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/jpA-ZeUCvvktwC4z5h78iEplp6w Subject: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:54:03 -0000 RFC 3406 specified use of the urn-nid@ietf.org list for discussion about namespace registrations, and 2141bis has not yet changed that. In the interest of economy, I would suggest using the urn@ietf.org list for all future discussions and deprecating the urn-nid@ietf.org list. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 23 11:16:50 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12F61AC39A; Tue, 23 Dec 2014 11:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPltu0QkbOMm; Tue, 23 Dec 2014 11:16:45 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3816C1A1ACE; Tue, 23 Dec 2014 11:13:32 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1724B22E260; Tue, 23 Dec 2014 14:13:30 -0500 (EST) Message-ID: <5499BED1.104@seantek.com> Date: Tue, 23 Dec 2014 11:13:21 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <5499BA48.5060807@andyet.net> In-Reply-To: <5499BA48.5060807@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/PRkWaZZg1Rz_iub_39I_fUVMHd8 Cc: urn-nid@ietf.org Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 19:16:47 -0000 Maybe. But there are two distinct controversies: 1) whether a proposed NID follows the URN rules sufficiently to permit registration, and 2) what the URN rules should be. It is very difficult for people who are trying to get work done under 1), to get sucked into debates about 2). My latest proposal for xmlns and rdf URN NIDs (draft-seantek-xmlns-rdf-urns-00.txt) is an example of that. For those who want to resolve the f-component stuff with a practical example, please take a look. Thanks! Sean On 12/23/2014 10:54 AM, Peter Saint-Andre - &yet wrote: > RFC 3406 specified use of the urn-nid@ietf.org list for discussion > about namespace registrations, and 2141bis has not yet changed that. > In the interest of economy, I would suggest using the urn@ietf.org > list for all future discussions and deprecating the urn-nid@ietf.org > list. > > Peter > From nobody Tue Dec 23 11:27:06 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4F1A1BEC for ; Tue, 23 Dec 2014 11:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nBEDiwwlxPq for ; Tue, 23 Dec 2014 11:27:04 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7C31A1BF6 for ; Tue, 23 Dec 2014 11:19:42 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so6193188iec.8 for ; Tue, 23 Dec 2014 11:19:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NVzkGRg3K4nB2txJMeCrVFpRtPR/voBlYGu+1K3Lt8U=; b=EuBGj9we0KapXBeRuBo54Lfb1vah/gXNkRtCjc6u+7aFu12+CSiW1TKmEuc8p69vVG V0gHy3Iqr5nKIPGbTK3YenJe5+kQiwG0dJj0ccg0YcEthBkQlCIKqTh333Cy0Vcd6qyF Nyw4Dpt5EO720evUF2up8VU6lq45McwfXUqDzPlQJE+2LJUym13MMXcbSOscKyKx1Jec bO0asXm7HYzQMnJ3RuL9wIEw8WF7yAesHafBwobV/OjNaeGmrP7FYgchbQ7HZDk2wiq4 xk2WghsmJdmqEbxNog6TVWmKDvwuw1tKaq7aJ3C+lIi3/wWJFxUS980ImMtoFRyYeQCY 71/w== X-Gm-Message-State: ALoCoQmg+Zki4BXpsjaot1SGMXUNMV/2Tj71B2pe4x3Uz++JaH9SUeq86ADcIyi69ChuPEjb9KYd X-Received: by 10.107.134.39 with SMTP id i39mr26968928iod.53.1419362380968; Tue, 23 Dec 2014 11:19:40 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id mv6sm6699974igb.10.2014.12.23.11.19.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 11:19:40 -0800 (PST) Message-ID: <5499C04C.6040605@andyet.net> Date: Tue, 23 Dec 2014 12:19:40 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> In-Reply-To: <5499BED1.104@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/wP5hcXs_A2ARtN19I5vPrlFL7QI Cc: urn-nid@ietf.org Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 19:27:05 -0000 On 12/23/14, 12:13 PM, Sean Leonard wrote: > Maybe. > > But there are two distinct controversies: 1) whether a proposed NID > follows the URN rules sufficiently to permit registration, and 2) what > the URN rules should be. It is very difficult for people who are trying > to get work done under 1), to get sucked into debates about 2). Ah, I am thinking of the post-URNBIS context. Once we finish 2141bis, the debates will be done. Or so I hope. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 23 22:11:40 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC951ACD07; Tue, 23 Dec 2014 22:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j3C0-6mFaxC; Tue, 23 Dec 2014 22:11:31 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 94E4D1ACD15; Tue, 23 Dec 2014 22:11:30 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4DF1432E53F; Wed, 24 Dec 2014 15:10:44 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 15b9_5ed0_515d8f66_92a2_4211_8887_889c493da596; Wed, 24 Dec 2014 15:10:43 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9A635BF4DF; Wed, 24 Dec 2014 15:10:43 +0900 (JST) Message-ID: <549A58E4.30206@it.aoyama.ac.jp> Date: Wed, 24 Dec 2014 15:10:44 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Sean Leonard , urn@ietf.org References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> In-Reply-To: <5499C04C.6040605@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vFQ3s0CkmD2E5UZZ8iUyonDoez0 Cc: urn-nid@ietf.org Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 06:11:34 -0000 On 2014/12/24 04:19, Peter Saint-Andre - &yet wrote: > On 12/23/14, 12:13 PM, Sean Leonard wrote: >> Maybe. >> >> But there are two distinct controversies: 1) whether a proposed NID >> follows the URN rules sufficiently to permit registration, and 2) what >> the URN rules should be. It is very difficult for people who are trying >> to get work done under 1), to get sucked into debates about 2). > > Ah, I am thinking of the post-URNBIS context. Once we finish 2141bis, > the debates will be done. Or so I hope. :-) I agree. Even now, the traffic isn't terribly high when averaged over a month or so, and while Sean definitely has a point, it's good that people who discuss the overall framework get exposed to actual examples and vice versa. So I think we should put "urn@ietf.org" into the draft as the address for review/discussions of namespace proposals, with the understanding that this will attain force when the draft is published as an RFC. Regards, Martin. From nobody Wed Dec 24 22:09:56 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50161A8720 for ; Wed, 24 Dec 2014 22:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3eEzEi4kyag for ; Wed, 24 Dec 2014 22:09:51 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2B31A007E for ; Wed, 24 Dec 2014 22:09:51 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y41cM-000EMX-Hd for urn@ietf.org; Thu, 25 Dec 2014 01:09:50 -0500 Date: Thu, 25 Dec 2014 01:09:45 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <4AEA9634620DA149DF74EDBC@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/NNczOMlfOvsk_7e8i_AkrsDAx90 Subject: [urn] 2141bis questions - (6) NID syntax for informal namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 06:09:54 -0000 Section 6.2 specifies the syntax of NIDs for Informal Namespaces, but it lacks specificity in one area, which is whether numbers with leading zeros are permitted and, if they are, whether NIDs with leading zeros are considered equivalent to those with the same numeric values with the leading zeros removed. I suggest we pick one of two options and document it more or less as described below. By the way, the syntax of an NID for an informal namespace is not the syntax of the namespace. Equally important, the syntax snippet isn't ABNF, ABNF is not referenced, and there is no production for "". Those are editorial issues that will have to be fixed in any event. Option 1: Leading zeros forbidden. Remove the present format snippet and replace Old: Thus the syntax of an informal namespace is: "urn-" New: The syntax for the NID of an informal namespace is: InformalNamespaceNID = "urn-" Digit19 [ *Digit09] Digit19 = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" Digit09 = "0" / Digit19 Option 2: Leading zeros forbidden but equivalent to the NID if they are stripped. Add, after the sentence starting "The only restrictions..." (and after fixing "syntax of an informal namespace" and ""), something like: While IANA may choose to assign NIDs with leading zeros following "urn-", a URN containing, for example, an NID of "urn-007" would not be equivalent under the matching rules of this specification and RFC 3986 to one containing and NID of "urn-7" so IANA should use care to avoid creating confusion. I think Option 1 is probably easier and simpler. A hypothetic third option in which an NID with leading zeros in the number is equivalent to one with them stripped leads, I think, to madness despite its numerical obviousness. john From nobody Wed Dec 24 22:28:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245F31A8720 for ; Wed, 24 Dec 2014 22:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoVdOQV4WnYC for ; Wed, 24 Dec 2014 22:28:30 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C8A1A004C for ; Wed, 24 Dec 2014 22:28:30 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y41uP-000ESa-BL for urn@ietf.org; Thu, 25 Dec 2014 01:28:29 -0500 Date: Thu, 25 Dec 2014 01:28:24 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GV3yjNN3U3MqOtK-lU6phl0dWjc Subject: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 06:28:31 -0000 The first part of Section 7, "Defining a URN Namespace", outlines broad requirements. Under item (2), it seems worthwhile to clarify that the status of *-components be specified here (it is explained in more detail in Section 7.2, as promised). Suggestion: Old: 2. The syntax of URNs assigned within the namespace. New: 2. The syntax of URNs assigned within the namespace, including whether p-, q-, and/or f-components are allowed. From nobody Wed Dec 24 22:32:06 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280981A8720 for ; Wed, 24 Dec 2014 22:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS5fEebmit9V for ; Wed, 24 Dec 2014 22:32:04 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC7C1A004C for ; Wed, 24 Dec 2014 22:32:04 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y41xr-000EUx-8s for urn@ietf.org; Thu, 25 Dec 2014 01:32:03 -0500 Date: Thu, 25 Dec 2014 01:31:58 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/xH4fBFCjShlQA89ZIUjkEjFK5rs Subject: [urn] 2141bis questions - (8) Equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 06:32:05 -0000 In Section 7.2, item 3, there is a sentence that reads: If it is appropriate and helpful, reference can be made to the equivalence rules defined in the URI specification [RFC3986]. Given all of the controversy we have had about those rules and what is required, suggested, ordered or unordered, etc., I suggest the above is looking for trouble. How would people feel about "... reference can be made to specific equivalence rules defined..." as a way to get around that without making a big deal of it? john From nobody Wed Dec 24 22:55:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97E1A8732 for ; Wed, 24 Dec 2014 22:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-FubDLO0UFc for ; Wed, 24 Dec 2014 22:55:38 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130781A872E for ; Wed, 24 Dec 2014 22:55:38 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y42Ke-000EaH-S2 for urn@ietf.org; Thu, 25 Dec 2014 01:55:36 -0500 Date: Thu, 25 Dec 2014 01:55:31 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/RQNxsQAq24JH9YFzgQM0Ji6MwiU Subject: [urn] 2141bis questions - (9) Expert review X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 06:55:39 -0000 Section 8 of the document, on registration of namespaces, specifies Expert Review and points to RFC 5226. The expert review provisions there are fairly specific. draft-leiba-cotton-iana-5226bis-11 is better, but still doesn't align with the discussion I think we had many months ago about creating a committee (not just a set of rotating individuals to spread the load) and about being very specific that the "expert" role was one of advising and trying to convince people to produce better-quality registration specs, not accepting or rejecting registrations. If my memory of that is correct, this section will need some work and text suggestions would be welcome. Is my memory correct or do we need to discuss those issues further? john From nobody Wed Dec 24 23:02:04 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768B61A8735 for ; Wed, 24 Dec 2014 23:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZaW0lLAFGnB for ; Wed, 24 Dec 2014 23:02:00 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5121A8733 for ; Wed, 24 Dec 2014 23:02:00 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y42Qp-000Edi-39 for urn@ietf.org; Thu, 25 Dec 2014 02:01:59 -0500 Date: Thu, 25 Dec 2014 02:01:54 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/IHx0hTFsOkbg62LXHTYMTsvjpMU Subject: [urn] 2141bis questions - (10) Backward compatibility X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 07:02:01 -0000 The registration procedures for formal and informal namespaces (Sections 8.1 and 8.2) both provide for revisions of the registration by updating the template. Especially given some discussions in the WG, I think we should impose an explicit requirement for a description of differences from prior versions and/or backward compatibility in updated registrations. Do others agree? john From nobody Wed Dec 24 23:06:42 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38B1A873C for ; Wed, 24 Dec 2014 23:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2wpwX8ff5XG for ; Wed, 24 Dec 2014 23:06:36 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036701A8739 for ; Wed, 24 Dec 2014 23:06:35 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y42VH-000Ee1-0j for urn@ietf.org; Thu, 25 Dec 2014 02:06:35 -0500 Date: Thu, 25 Dec 2014 02:06:29 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <7AA292AD3338AE2BC429F266@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/imcjlZUbFrnqyeVvszICpreRfMc Subject: Re: [urn] 2141bis questions - (9) Expert review (addendum) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 07:06:38 -0000 Sorry... didn't read my notes carefully enough. I should have added that Section 9 does discuss some of the issue and should be pointed to in, or merged with, the first paragraph of Section 8.1 (an editorial matter), but Section 9 still somewhat contradicts the language of RFC 2226. john From nobody Wed Dec 24 23:20:45 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5C1A8745 for ; Wed, 24 Dec 2014 23:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GgfhSnD_FyX for ; Wed, 24 Dec 2014 23:20:38 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C041A8743 for ; Wed, 24 Dec 2014 23:20:38 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y42ir-000EgH-0p for urn@ietf.org; Thu, 25 Dec 2014 02:20:37 -0500 Date: Thu, 25 Dec 2014 02:20:31 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <5765CD04A2095D995D241104@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/qyCYG2sD0HuTK2HUxTvJciMZt6Q Subject: Re: [urn] 2141bis questions - (11) IANA considerations and Interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 07:20:43 -0000 Under IANA Considerations - URI Scheme, Section 10.1, the text says "Interoperability Considerations: There are no known interoperability concerns related to use of the 'urn' URI scheme." IMO, this is not strictly true because the whole discussion of whether URNs can be (or should be, or are meaningful in) various contexts and/or in relative URI form is ultimately about interoperability considerations. One could argue that almost everything else that RFC 3986 considers a per-scheme issue and that we have made per-NID for URNs falls into the same category. Should more be said in that line item and, if so, what? john p.s. That is the end of my current questions/issues list for probably-substantive and/or controversial changes to 2141bis. I'll be posting a list of proposed editorial modifications within the next few days. From nobody Thu Dec 25 09:22:02 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7D1A8843; Thu, 25 Dec 2014 09:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOzYi1Nyud-j; Thu, 25 Dec 2014 09:21:54 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857F11A8842; Thu, 25 Dec 2014 09:21:54 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y4C6e-000GVV-Nk; Thu, 25 Dec 2014 12:21:48 -0500 Date: Thu, 25 Dec 2014 12:21:43 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Peter Saint-Andre - &yet , Sean Leonard , urn@ietf.org, Barry Leiba Message-ID: <844A0581B9447C7703322432@JcK-HP8200.jck.com> In-Reply-To: <549A58E4.30206@it.aoyama.ac.jp> References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YBABi4ynojbhpNtwShapwAQE4d8 Cc: urn-nid@ietf.org Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 17:21:59 -0000 (Barry and IESG explicitly copied) --On Wednesday, December 24, 2014 15:10 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > On 2014/12/24 04:19, Peter Saint-Andre - &yet wrote: >> On 12/23/14, 12:13 PM, Sean Leonard wrote: >>> Maybe. >>>=20 >>> But there are two distinct controversies: 1) whether a >>> proposed NID follows the URN rules sufficiently to permit >>> registration, and 2) what the URN rules should be. It is >>> very difficult for people who are trying to get work done >>> under 1), to get sucked into debates about 2). >>=20 >> Ah, I am thinking of the post-URNBIS context. Once we finish >> 2141bis, the debates will be done. Or so I hope. :-) >=20 > I agree. Even now, the traffic isn't terribly high when > averaged over a month or so, and while Sean definitely has a > point, it's good that people who discuss the overall framework > get exposed to actual examples and vice versa. >=20 > So I think we should put "urn@ietf.org" into the draft as the > address for review/discussions of namespace proposals, with > the understanding that this will attain force when the draft > is published as an RFC. Actually, I think we should go a step further. I think we should celebrate the new year and expected rapid progress in the WG by blocking all pending and future URN namespace registrations by referring them to the WG for formal review until 2141bis is approved and becomes the new procedure. The problem is that, as we debate details of what should be permitted in URN strings, it is at least theoretically possible to slip registrations through a small mailing list and and indifferent and noisy IETF LC process that would then give us additional legacy compatibility problems. I note that RFC 3406 not only requires IETF Consensus for new URN namespaces but explicitly quotes the portion of RFC 2434 pointing to referral to relevant WGs, so it has probably been an error to approve new URN namespaces since this "bis" WG came into being without formally asking the WG for it consensus opinion. What is done is done and I think it would be ill-advised to reopen the reviews on any namespace already approved and either registered or in some phase of the post-approval publication process, but I believe that the IETF Last Call on draft-higgs-hbbtv-urn should not be closed out and an IESG vote taken until this WG has formally reviewed it for conformance to our plans going forward and that authors or proponents of=20 draft-atarius-dispatch-meid-urn draft-atarius-dispatch-meid-urn-as-instanceid draft-benjemaa-vbs-urn draft-seantek-certspec-04 draft-seantek-rdf-urn-00 draft-seantek-xmlns-urn-00 draft-snell-social-urn-01 draft-spinosa-urn-lex-09 should be notified that their drafts [1] are going to be referred to the WG for formal review when IETF Consensus approval is formally requested. Their alternative, of course, is to encourage this WG to finish its work, after which a more streamlined procedure will be in place. If any of those authors or would-be registrants believe their requests are urgent, let them convince the WG, noting that a WG-approved request should go through the IETF approval process more quickly and might even qualify for a two-week Last Call.=20 In addition, while I would hope to not delay it, someone should send a note to this list requesting a quick review of draft-murdock-nato-nid-03 when it appears. I hope we can accomplish this change by an administrative decision rather than by document-by-document appeals based on the language of RFC 3406, the fact that there is a relevant WG, and that the referrals have not been made. john [1] List produced by a quick pass through the I-D Datatracker; may not be complete. From nobody Mon Dec 29 12:37:22 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B83A1A8F3B; Mon, 29 Dec 2014 12:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV_nTrFNVvVm; Mon, 29 Dec 2014 12:37:17 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74D51A8F38; Mon, 29 Dec 2014 12:37:16 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so11286577lbv.39; Mon, 29 Dec 2014 12:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=o3FP6csxJE6CwV8ellxVYwDYGr8aHRVj4C3qOAIEyYQ=; b=pNotcjwTAcoTY+Kw0AuVmyp3qRGmKrf2jzgyINIH047VQVMuY+1acfFuf0TezF8O48 aAGpFLu2GZGAaDXTH6lDzKYCG+SOfqRrYAs5aeASBqg9zW3gXnp1q8YzhH0ZE7QQdv3+ Sz9zMhun5UNPzcb9eZe+Xej1EVsxiuy5gqwTp1/NUhpUpnEBo4wpO4zxb82U/CX7GH86 e/ZDk5EF1zF/+ybiaXfh8v/ehqLDqGPMCwaTL+G3R9xn6YnpgaHEznmusm3HgKfuDJZQ QVzmsbodSA8246fNHCmuuv2+zL5+6u9fMccouPP8WY3I76y1Jp7ZcaVUFY/Au/BvdPOw 067Q== MIME-Version: 1.0 X-Received: by 10.152.87.142 with SMTP id ay14mr58834398lab.45.1419885435210; Mon, 29 Dec 2014 12:37:15 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Mon, 29 Dec 2014 12:37:15 -0800 (PST) In-Reply-To: <844A0581B9447C7703322432@JcK-HP8200.jck.com> References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> Date: Mon, 29 Dec 2014 15:37:15 -0500 X-Google-Sender-Auth: GltaEqan8JBQVOSfiWhJFkywcYU Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/I2YvSkMVhBAH_QJDv0-ZfCVKvn0 Cc: "urn-nid@ietf.org" , "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 20:37:18 -0000 >> So I think we should put "urn@ietf.org" into the draft as the >> address for review/discussions of namespace proposals, with >> the understanding that this will attain force when the draft >> is published as an RFC. > > Actually, I think we should go a step further. I think we > should celebrate the new year and expected rapid progress in the > WG One can hope, and I do. > by blocking all pending and future URN namespace > registrations by referring them to the WG for formal review > until 2141bis is approved and becomes the new procedure. I strongly disagree with blocking pending ones. There is only one, and there's no reason to stop it now. If you see something wrong with it, say so specifically. If not, let it be approved, and we'll deal only with the future now. The urn-nid list is not a secret, and anyone here who thinks they need to scrutinize NID requests now more strongly than earlier... need only go there and do so. It would be sillier to have those requesting NIDs post to and follow this list, which goes far beyond what they know or care to know. > I note that RFC 3406 not only requires IETF Consensus for new > URN namespaces but explicitly quotes the portion of RFC 2434 > pointing to referral to relevant WGs, so it has probably been an > error to approve new URN namespaces since this "bis" WG came > into being without formally asking the WG for it consensus > opinion. Hm. I don't see it that way. What I say above has always applied, and the existing documents shunted the work over to urn-nid for good reason. It's been quite a good thing, really, through most of the life of this working group, that it hasn't directly been on the hook for reviewing and approving NID requests. Participants here can be presumed to know well that urn-nid is where those go, and to know well how to go there too. > What is done is done and I think it would be ill-advised to > reopen the reviews on any namespace already approved and either > registered or in some phase of the post-approval publication > process Thank you for being sensible about that. > but I believe that the IETF Last Call on > draft-higgs-hbbtv-urn should not be closed out and an IESG vote > taken until this WG has formally reviewed it for conformance to > our plans going forward Please, let's not do that. Let's just include that in the above "what's done is done" category, and let it finish. Unless you see specific harm, of course, which you absolutely should comment on. > and that authors or proponents of > > draft-atarius-dispatch-meid-urn > draft-atarius-dispatch-meid-urn-as-instanceid > draft-benjemaa-vbs-urn > draft-seantek-certspec-04 > draft-seantek-rdf-urn-00 > draft-seantek-xmlns-urn-00 > draft-snell-social-urn-01 > draft-spinosa-urn-lex-09 > > should be notified that their drafts [1] are going to be > referred to the WG for formal review when IETF Consensus > approval is formally requested. I am mostly happy to hold the future requests up, and I think it's not unreasonable to do that, provided that we do put a time limit on it. The possible exception is "lex", which has been held up very long already. It is, on the other hand, one that I find problematic for a number of reasons, and when the authors have responded to my last comments to them I'm inclined to ask you, John, to be its document shepherd... which may, in itself, throw it into the "delayed" pile (if you share my concerns, at least some of them, and/or have your own). Barry, Applications AD From nobody Tue Dec 30 01:45:54 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4731ACEEE; Tue, 30 Dec 2014 01:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-IbQwBeBhkT; Tue, 30 Dec 2014 01:45:49 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F377C1A0041; Tue, 30 Dec 2014 01:45:48 -0800 (PST) Received: from [192.168.123.151] (unknown [23.241.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 887DC22E25F; Tue, 30 Dec 2014 04:45:45 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <844A0581B9447C7703322432@JcK-HP8200.jck.com> Date: Tue, 30 Dec 2014 01:45:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> To: urn@ietf.org, urn-nid@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SVTUatf50kCr6NefSMr22qbSkzs Cc: Barry Leiba , Peter Saint-Andre - &yet Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 09:45:52 -0000 On Dec 25, 2014, at 9:21 AM, John C Klensin wrote: > draft-seantek-certspec-04 > draft-seantek-rdf-urn-00 > draft-seantek-xmlns-urn-00 Without commenting on the merits of any of the rest of that message=85 Please note that draft-seantek-xmlns-urn-00 and draft-seantek-rdf-urn-00 = have been replaced with draft-seantek-xmlns-rdf-urns-00, which = incorporates prior feedback. Due to ongoing uncertainty, draft-seantek-certspec-04 is being abandoned = in favor of a much more straightforward set of approaches using URIs. Sean= From nobody Tue Dec 30 06:28:59 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262331A00CF; Tue, 30 Dec 2014 06:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvB6ytvc6nw5; Tue, 30 Dec 2014 06:28:50 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92BF21A00CD; Tue, 30 Dec 2014 06:28:50 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y5xmt-000BRs-3Q; Tue, 30 Dec 2014 09:28:43 -0500 Date: Tue, 30 Dec 2014 09:28:38 -0500 From: John C Klensin To: Barry Leiba Message-ID: <1D6DD11066A060EED966B640@JcK-HP8200.jck.com> In-Reply-To: References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/2zDMQcVmidNo8A2HKvZPr9feku0 Cc: urn-nid@ietf.org, urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 14:28:55 -0000 --On Monday, December 29, 2014 15:37 -0500 Barry Leiba wrote: >>> So I think we should put "urn@ietf.org" into the draft as the >>> address for review/discussions of namespace proposals, with >>> the understanding that this will attain force when the draft >>> is published as an RFC. >> >> Actually, I think we should go a step further. I think we >> should celebrate the new year and expected rapid progress in >> the WG > > One can hope, and I do. > >> by blocking all pending and future URN namespace >> registrations by referring them to the WG for formal review >> until 2141bis is approved and becomes the new procedure. > > I strongly disagree with blocking pending ones. There is only > one, and there's no reason to stop it now. If you see > something wrong with it, say so specifically. If not, let it > be approved, and we'll deal only with the future now. Some observations below, but I'm going to defer to you on this because I just don't have time or energy to both have a long discussion and to make progress on the URNBIS WG documents. > The urn-nid list is not a secret, and anyone here who thinks > they need to scrutinize NID requests now more strongly than > earlier... need only go there and do so. It would be sillier > to have those requesting NIDs post to and follow this list, > which goes far beyond what they know or care to know. I was actually thinking about the issue the other way around. It has long been my experience that anyone who is active in the IETF, knows where to find things or who to ask, and have lots of time on their hands can find or follow just about anything that amuses them. There have historically been exceptions, but they are few and becoming fewer. However, one of several issues with URNBIS is that people are coming into the discussions with the perspective of one particular set of needs and advocating for them on the implicit assumption that, if those needs are accommodated, everything else will be taken care of [1]. The result is that we aren't getting a sufficient number of perspectives and that increases the risks that we will get something seriously wrong by omitting consideration of an important case. So my thinking was to create a situation in which someone proposing a new URN namespace and NID was more or less forced, as a condition for getting that NID, to follow and participate in the WG, primarily wrt two questions: (i) Would any of the changes being proposed either hurt or help setting up their namespace, and any others similar to it that they can think about, be defined in a way that is clear, reasonable, and natural? (ii) Are there additional changes that should or should not be made that would be significant from their perspective? Now, one could figure out other ways to ask those questions than having them emerge in a dialog with the WG, and try to assure that we got answers, then forcing applicants onto the on the URN mailing list and holding the applications until the WG signed off. But, right now, it appears to me that we are not, and have not been, getting those answers from the perspective of any recent applicants other than Sean, and he hasn't been involved for very long. >> I note that RFC 3406 not only requires IETF Consensus for new >> URN namespaces but explicitly quotes the portion of RFC 2434 >> pointing to referral to relevant WGs, so it has probably been >> an error to approve new URN namespaces since this "bis" WG >> came into being without formally asking the WG for it >> consensus opinion. > > Hm. > I don't see it that way. What I say above has always applied, > and the existing documents shunted the work over to urn-nid > for good reason. It's been quite a good thing, really, through > most of the life of this working group, that it hasn't > directly been on the hook for reviewing and approving NID > requests. Participants here can be presumed to know well that > urn-nid is where those go, and to know well how to go there > too. See above. >... >> but I believe that the IETF Last Call on >> draft-higgs-hbbtv-urn should not be closed out and an IESG >> vote taken until this WG has formally reviewed it for >> conformance to our plans going forward > > Please, let's not do that. Let's just include that in the > above "what's done is done" category, and let it finish. > Unless you see specific harm, of course, which you absolutely > should comment on. I actually commented, at some length, on the GSMA/IMEI namespace(s) (now RFC 7254 and 7255). Those comments went nowhere, including no useful responses from the authors or GSMA. I considered making a fuss during the last round of IETF Last Call (and, if necessary, on appeal) and concluded that (i) I'm reluctant to tell another standards body what they need, even though I'd be a lot happier if there was some sort of roadmap rather than "this request now and maybe there will be others later"; (ii) I don't see a particular example, in its own namespace and with its own NID, as being especially harmful -- especially since nothing says "you get to use this as a precedent" -- even if there were serious problems with it; (iii) URNBIS wasn't nearly far enough along for us to have a serious discussion about one GSMA namespace and qualifiers of various sorts (?-components ?) that would identify different uses of that namespace. I do note that, AFAIK, the situation with GSMA is rather different from that with ISO/TC 46. In the latter case, there are separate registration authorities and oversight arrangements for, e.g., ISSN and ISBN. If the registrations arrived, de novo, under the procedures outlined in 2141bis (and the former 3406bis), they would almost certainly arrive from different applicants. GSMA, again AFAIK, is a little more monolithic, so it would be reasonable to press for "one organization, one broad set of topics, one namespace" or at least for an explanation of why that was not appropriate; (iv) I just don't have time to both fight individual URN namespace battles (unless they are obviously critical-path), try to drag i18n work along, and pay attention to anything else IETF-related. >... > I am mostly happy to hold the future requests up, and I think > it's not unreasonable to do that, provided that we do put a > time limit on it. Again, see the discussion of motivation above. > The possible exception is "lex", which has been held up very > long already. It is, on the other hand, one that I find > problematic for a number of reasons, and when the authors have > responded to my last comments to them I'm inclined to ask you, > John, to be its document shepherd... which may, in itself, > throw it into the "delayed" pile (if you share my concerns, at > least some of them, and/or have your own). In the interest of future discussion and to keep this note from getting longer, I'll reply separately on that subject. Again, I'll defer to your decision about not combining the two lists now, but note that, IMO, the continued separation is weakening the work of this WG and increasing the risk of bad results. best, john [1] There are more negative versions of that story, including "as long as my needs are met, I don't care about anything else", but such hypotheses are unnecessary to my point. From nobody Tue Dec 30 07:31:49 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66E11A01CB; Tue, 30 Dec 2014 07:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gAX7ZuW2Fjj; Tue, 30 Dec 2014 07:31:43 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCC71A019B; Tue, 30 Dec 2014 07:31:43 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y5ylk-000BWr-RZ; Tue, 30 Dec 2014 10:31:36 -0500 Date: Tue, 30 Dec 2014 10:31:31 -0500 From: John C Klensin To: Barry Leiba Message-ID: <1BCA16D96EC2C307E29BFABC@JcK-HP8200.jck.com> In-Reply-To: References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/q9z4onGW-YlFpAigWxpJhJxTZLA Cc: urn-nid@ietf.org, urn@ietf.org, Peter Saint-Andre - &yet Subject: [urn] A few quick thoughts on "lex" (was" Re: continued use of urn-nid@ietf.org list) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 15:31:46 -0000 --On Monday, December 29, 2014 15:37 -0500 Barry Leiba wrote: > The possible exception is "lex", which has been held up very > long already. It is, on the other hand, one that I find > problematic for a number of reasons, and when the authors have > responded to my last comments to them I'm inclined to ask you, > John, to be its document shepherd... which may, in itself, > throw it into the "delayed" pile (if you share my concerns, at > least some of them, and/or have your own). Against my better judgment, I looked through this (that is "looked through", not "read carefully"). I see multiple problems which start with the observation that I know of at least a few international legal document referencing systems that would not fit this mold without considerable distortion (I'm not an expert; if I were, I'd probably know of more); the document commits Punycode abuse and, at the risk of appealing to 3986, there is no obvious reason to avoid use of %-encoding for the non-ASCII cases they cite; they claim to be international, but all of their thinking and examples seem to be tied to sometimes-extended Latin script (in particular, Section 3.5 could create a huge mess and, for Section 3.9, someone should explain to them what an "Arabic numeral" looks like); and so on. As a slightly more complex example, Section 2.4 contains text starting "In case of country code re-assignement...". Perhaps more study would help, but I'm not sure what it actually means in practice but believe that it might violate the fundamental principle of stability in URNs. I also note that, while the introductory material (first paragraph of 1.1) claims this is about legal materials and sources of law and not, e.g., about legal doctrine, they identify at least one example of a legitimate registrant who is a source of law only in the wildest imagination of its more doctrinaire adherents. That particular example calls both the consistency and the competence of the submission in this particular area into question. The naming authority model is also a bit muddy. The registration root should really be under control of an international consensus body/authority, not a research organization in one country (we've had more than enough proofs of where the latter leads). My skimming did not identify any evidence that national legal/judicial authorities are willing to sign up for the roles this document seems to give them, and so on. I spotted several other issues that might be more important but that would require a lot more explanation. One of them is whether we should be using .urn.arpa for subtrees that have neither network protocol implications or broad international use and acceptance. If there were the criterion, I don't know if this would qualify. Otherwise, and unless the i18n issues are really sorted out, I'd think that consideration should be given to whether something like .urn.eu would be appropriate. I draw two conclusions for the above. FIrst, there are a lot of issues, some related to legal documents, some to URN (or URI) niceties, and some to authority, that the document just does not have sorted out yet. Second, the IETF may be appropriate as a place to sort out the best syntax model for registering an established name space as a URN-embedded namespace, but we should not be in the business of recognizing or ratifying naming authorities, especially in areas we know almost nothing about (either technically or in terms of socio-political relationships). Except where Internet protocols are concerned, we should probably refer issues about defining namespace fundamentals for particular fields to established and competent bodies in those fields, let them establish their own standards, and then work with them on URN embedding as needed. That is something we haven't written into 2141bis and, especially with the elimination of experimental RFCs, we probably should figure out how to say explicitly. For the case of this particular document, if the International Federation of Library Associations and Institutions (IFLA) has really been consulted, it would be reasonable to approach them, ideally in consultation with ISO/TC 46, and define an appropriate international standard that parallels the ISSN and ISBN, or even DOI, work. If not, I think we should suggest to the authors that they try publishing a detailed description of the underlying system in scholarly legal community journals of appropriate scope and coverage (including an internationally-broad editorial board and wide international readership), see what feedback they get, and then strip this document down to normative references about the theory and organization of the namespace. If they can't get such feedback, or can't find a reputable and appropriate place to publish, then no one relevant cares and the IETF should not be in the middle. As an alternative, if they can get formal EU backing for this, they might try registering a namespace that assigned codes and jurisdictions for EU, IT, Brazil if they really want to play, and any other EU countries they can get to sign up, reserve all other codes for future expansion, designate the second-level authorities (presumably ones who have formally agreed) in the document, and come back to us with a revision plan when they can show more international interest. Given the above and time constraints, I'm not willing to play shepherd for this document unless at least those issues are sorted out and clear endorsements and commitments are established. THe comments above may give you enough of a review to get the draft out of "AD contemplation" state. Melinda and Andy, these two notes seemed important, but sucked up almost all of my URNBIS time for the week. Schedule slipping accordingly. john