From nobody Fri Jun 3 07:45:45 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264B112D1BF for ; Fri, 3 Jun 2016 07:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1QGULPKoaNwr for ; Fri, 3 Jun 2016 07:45:43 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C196C12D194 for ; Fri, 3 Jun 2016 07:45:43 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id f67so10612243ith.1 for ; Fri, 03 Jun 2016 07:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=znBAQSHN8XbCiY6gFpLzbHaRKECAAgN/VvU4btP37b0=; b=k/9Kp6evDOeLy0tg59mvqjLeqAzlTnz9LTGWbKbXUO2djOai45TfdNDfY30XQJAIPF +fGYD6tuzhupm/q3pvuB4wzyJkSSUzWIFIV8PmrR8FyvbADXf1I2toVQB8PjqewjZnns jfi35ptdby09ntg3AYL9btdxPzgS/wtroSEoJhBu+QhJjaipTDGl0rsBBk3PftvQ46PL zNbcWQ7beX77Edr4RcICPj8GGJXrNWOKzg7wXxIa829b1sFs/2IlVI3moSFti2KUsY+0 o0fq1shvl7j4sUuwpeQHrolkw/Zi6j2N0SdE1WysRiLfxvuq7I+A9QBs+VGJ3B1fzUY+ 2toA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=znBAQSHN8XbCiY6gFpLzbHaRKECAAgN/VvU4btP37b0=; b=TLp5Y/TSDj1Ivcmy3xjBKdVjMI7thdhoz3Ivu1wCfG6dHDan+mXlphIE7Yl0gpMwp8 oSG1cn30MqoCy6ACwz7JZMEzp9nXBHQuEx3yuxr2FYpayIBKCSqxaTO8ELqePn2OlsGy XFNYd3c7vGYoqcxY6gRTyX/85h0pZ8P++74F2/GS0XUNa9+IBYXuWOrA+LL2WwVBz+v8 rWy2EiX8fo2QjrnZQJLhLl08hCYAaivUIOcPOGmyINBjRq2O+PkD2OI0wz/re4NxypbO QJKLK6jVYuSEaK7B22CkVzK9kX3tsnysjSzJB5CR1ta8nvpoqm2YEcz/XydxjGdRmrNc SsBg== X-Gm-Message-State: ALyK8tKcrMdCSNBIJsmGOdmlcrzBhgQMeDa0liP8roxXuXMdUL2nJC6lnfHX8J09ntZb/dYSDrcuixw5ZiIGcA== X-Received: by 10.36.120.12 with SMTP id p12mr10859250itc.22.1464965143104; Fri, 03 Jun 2016 07:45:43 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.140.78 with HTTP; Fri, 3 Jun 2016 07:45:42 -0700 (PDT) In-Reply-To: <96CD7976C66DD563194A554B@JcK-HP8200.jck.com> References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <7883335563DB29FFAF9BE5DB@JcK-HP8200.jck.com> <96CD7976C66DD563194A554B@JcK-HP8200.jck.com> From: Barry Leiba Date: Fri, 3 Jun 2016 10:45:42 -0400 X-Google-Sender-Auth: sGQhYum8pLSjtWn3Aw73pCAVz8M Message-ID: To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:45:45 -0000 We have the following text change proposed, with John's asking others if the change is OK. Any (concise, please) answers to that question?: >> Would it work to simply treat this as a kind of in-principle >> example, by reordering the paragraph? That is, along the >> lines of >> >> The URN q-component has the same syntax as the URI query >> component, but is introduced by "?=", not the "?" alone. >> For URNs which may be resolved to a URL, the semantics of >> the q-component are identical to those for queries to the >> resource located via that URL. So URN resolvers returning >> a URL for a URN with a q-component do this by copying the >> q-component from the URN verbatim to the query component of >> the URL. If the URN does not resolve to a URL the >> interpretation of the q-component is undefined by this >> specification. >> >> [I've kept some wording I find awkward to minimise the >> difference with the existing text -- other things being equal >> I'd also prefer >> >> those for queries to the resource located via that URL >> ==> >> those for the query component of that URL >> >> ] > > Wfm, including the latter. Would others please comment, > especially if they have objections, before I change the text? Barry, as chair From nobody Fri Jun 3 08:05:38 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B96012D6A9 for ; Fri, 3 Jun 2016 08:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 i8ZLaIyvP6iZ for ; Fri, 3 Jun 2016 08:05:32 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FA212D69E for ; Fri, 3 Jun 2016 08:05:32 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id o16so82767504ywd.2 for ; Fri, 03 Jun 2016 08:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=ocOABuZS+co2Gw4/oFeYwXN1ka4gv/Ku3OxlHmLmCXM=; b=x6VzDOTDEj/HDF+xTxRs+NU5ee/TloMtMth6Ub2YcwswPNvErEZYZFMZ89/gAbVQ8w 5F0SsivXKci06fYinOms8D064NYPUlM/KPX/ncZwBH+WG1DIihuGBxjj9gX8R6PwcJcu 2Rj2kzI3llvUXLwytT1zjRMNPB02WjcF7N3wHBZmoT04l1KKN0pk8QQa1U3t9kUEB5M2 ELKyY70uyhoniCD6yS4Jui11L4g5Xp1QmKo3CEg1iKjf19zVLCZiFZQAm2CSRDsOcTSe AC4uoV/6W+YC1WbhKk+XZ44jxONCWR+5N6+GPHRr4EZIq3+waHw7tlBlHYoob52evQVr vypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=ocOABuZS+co2Gw4/oFeYwXN1ka4gv/Ku3OxlHmLmCXM=; b=k7gGr1j1NgTzh+hnEk5GaR5LenRkSzXo8T9FDhYpzXey5dAL5FO9Ad0TtckfDFZMZH NO3rUtqU0R+ZmQ6tAPYUMt+rH9UvntsV4UQzMYZu1uPvYeU8m8j36FZCZ8N5fJs9syIx Zy20ohziO3yKVqPq/qNoHM/LJZgTfG3BQshbpQVoVYYUIo5nRg+EyKU8kOaM360MMmYu jPpk2mz95ZnDEbZrRcMeOmzP8Tc2Jrib34yDpcmO1Rehnn0hscosP1qhzvRkfU210+nI CQ0onbUyAWY7t/rIl6M1/2U8aXsoIz3u3+RHjWSbfUJHxMBx5rJk1nZKLm5VGYiMEn9i /6sA== X-Gm-Message-State: ALyK8tKBHaiXoL95S4j7LtZ1CsKPIGHZqKTDq12ttFpA7XqzikHhqlV2K8z5dzdoCPmtThgcQMsfZVb3tPiD3A== X-Received: by 10.37.98.146 with SMTP id w140mr2544025ybb.129.1464966331183; Fri, 03 Jun 2016 08:05:31 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.37.6 with HTTP; Fri, 3 Jun 2016 08:05:30 -0700 (PDT) From: Barry Leiba Date: Fri, 3 Jun 2016 11:05:30 -0400 X-Google-Sender-Auth: DxTI1i1hC7fz7FlJzunrawvTR30 Message-ID: To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:05:34 -0000 As I'm trying to catch up on the many long messages in the various discussions, I'm seeing issues that seem related to how we're talking about some of this stuff, and that appears to be getting in the way of understanding and coming to agreement. So let me babble for a moment: As we're talking about naming things -- URNs are names -- we mix in issues of locating them, finding them, and other such terminology that gets in the way. In reading a conversation between Juha and Julian, I was struck by things of this sort (from that thread): >> urn:isbn:#chapter1 >> urn:isbn:#chapter1para1 >> urn:isbn:#chapter1para1line1 >> urn:isbn:#chapter1para1line1word1 >> urn:isbn:#chapter1para1line1word1letter1 >> >> According to the rfc2141bis, all these URNs are equivalent (they identify >> the same book, and only that), but they indicate different locations within >> the first chapter of the identified book. Anyone could create these URNs >> once the national library has established the base URN. This is not a >> mandate problem since fragments have no role in identification. > > Wow, they are *equivalent*, but indicate *different* locations? That's IMHO > a very very surprising definition of equivalence. It probably would be good > to use a more specific term. Setting aside, for the moment, whether fragments make sense within the ISBN namespace, I think it's important for us to understand what's being named (or identified, if you prefer) by urn:isbn: ...and by urn:isbn:#chapter1 ...and I suggest that (1) they're not identifying the same thing, but (2) what they're identifying is related, and (3) none of this has anything to do with locating the entity that's been named, nor how that might happen. The first is identifying, say, a book. Specifically, a given edition of a book, from a specific publisher. The second is identifying the first chapter of that editing of that book from that publisher. Yes? When Juha says they're "equivalent", he means that they refer to the same book, but he doesn't mean that the URNs are truly equivalent. When Julian says "wow, equivalent?", he questions where the equivalence stops. We're being imprecise, and it's getting in our way. And I think that's happening because we, naturally, keep thinking in terms of going and finding the thing that's named, rather than staying with the idea that these are abstract names. Will it help, maybe, if we're clear that when we talk about URNs, we're talking purely about names for things, and that anything related to how to use that name to actually *find* the things is a separate question? And then try hard to keep our language in terms of the names only? Barry From nobody Fri Jun 3 12:30:53 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771A312D940 for ; Fri, 3 Jun 2016 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 MW256U8XxtGC for ; Fri, 3 Jun 2016 12:30:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2AC12D7D5 for ; Fri, 3 Jun 2016 12:30:50 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5711D50A73 for ; Fri, 3 Jun 2016 15:30:49 -0400 (EDT) To: urn@ietf.org References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <7883335563DB29FFAF9BE5DB@JcK-HP8200.jck.com> <96CD7976C66DD563194A554B@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <224967fe-5961-e989-a9e9-401c99b5335d@seantek.com> Date: Fri, 3 Jun 2016 12:31:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 19:30:51 -0000 On 6/3/2016 7:45 AM, Barry Leiba wrote: > We have the following text change proposed, with John's asking others > if the change is OK. Any (concise, please) answers to that question?: > >>> Would it work to simply treat this as a kind of in-principle >>> example, by reordering the paragraph? That is, along the >>> lines of >>> >>> The URN q-component has the same syntax as the URI query >>> component, but is introduced by "?=", not the "?" alone. >>> For URNs which may be resolved to a URL, the semantics of >>> the q-component are identical to those for queries to the >>> resource located via that URL. So URN resolvers returning >>> a URL for a URN with a q-component do this by copying the >>> q-component from the URN verbatim to the query component of >>> the URL. If the URN does not resolve to a URL the >>> interpretation of the q-component is undefined by this >>> specification. >>> >>> [I've kept some wording I find awkward to minimise the >>> difference with the existing text -- other things being equal >>> I'd also prefer >>> >>> those for queries to the resource located via that URL >>> ==> >>> those for the query component of that URL >>> >>> ] >> Wfm, including the latter. Would others please comment, >> especially if they have objections, before I change the text? As to the specific change: FROM: those for queries to the resource located via that URL TO: ==> those for the query component of that URL I agree and approve. I still disagree strongly with the syntax of that paragraph, namely, using "?=" as an introducer anywhere in the q-component. Sean From nobody Fri Jun 3 12:40:15 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CC512D16F for ; Fri, 3 Jun 2016 12:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 MubWFZLweap2 for ; Fri, 3 Jun 2016 12:40:12 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1C112D0FE for ; Fri, 3 Jun 2016 12:40:12 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A783F50A73; Fri, 3 Jun 2016 15:40:11 -0400 (EDT) To: urn@ietf.org References: From: Sean Leonard Message-ID: Date: Fri, 3 Jun 2016 12:40:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Barry Leiba Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 19:40:14 -0000 On 6/3/2016 8:05 AM, Barry Leiba wrote: > As I'm trying to catch up on the many long messages in the various > discussions, I'm seeing issues that seem related to how we're talking > about some of this stuff, and that appears to be getting in the way of > understanding and coming to agreement. So let me babble for a moment: > > As we're talking about naming things -- URNs are names -- we mix in > issues of locating them, finding them, and other such terminology that > gets in the way. In reading a conversation between Juha and Julian, I > was struck by things of this sort (from that thread): > >>> urn:isbn:#chapter1 >>> urn:isbn:#chapter1para1 >>> urn:isbn:#chapter1para1line1 >>> urn:isbn:#chapter1para1line1word1 >>> urn:isbn:#chapter1para1line1word1letter1 >>> >>> According to the rfc2141bis, all these URNs are equivalent (they identify >>> the same book, and only that), but they indicate different locations within >>> the first chapter of the identified book. Anyone could create these URNs >>> once the national library has established the base URN. This is not a >>> mandate problem since fragments have no role in identification. >> Wow, they are *equivalent*, but indicate *different* locations? That's IMHO >> a very very surprising definition of equivalence. It probably would be good >> to use a more specific term. > Setting aside, for the moment, whether fragments make sense within the > ISBN namespace, I think it's important for us to understand what's > being named (or identified, if you prefer) by > > urn:isbn: > > ...and by > > urn:isbn:#chapter1 > > ...and I suggest that (1) they're not identifying the same thing, but > (2) what they're identifying is related, and (3) none of this has > anything to do with locating the entity that's been named, nor how > that might happen. > > The first is identifying, say, a book. Specifically, a given edition > of a book, from a specific publisher. > > The second is identifying the first chapter of that editing of that > book from that publisher. > > Yes? > > When Juha says they're "equivalent", he means that they refer to the > same book, but he doesn't mean that the URNs are truly equivalent. > When Julian says "wow, equivalent?", he questions where the > equivalence stops. We're being imprecise, and it's getting in our > way. > > And I think that's happening because we, naturally, keep thinking in > terms of going and finding the thing that's named, rather than staying > with the idea that these are abstract names. > > Will it help, maybe, if we're clear that when we talk about URNs, > we're talking purely about names for things, and that anything related > to how to use that name to actually *find* the things is a separate > question? And then try hard to keep our language in terms of the > names only? +1000 We (well, you and I) are in agreement. We can start with agreeing to call "URN equivalence" something more precise. See my posts around 5/3/2016: http://mailarchive.ietf.org/arch/msg/urn/936s5wvwAsXB8ih3fP-EhBjBSKw "Name the Same Thing" Best regards, Sean From nobody Sat Jun 4 07:14:44 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA42F12D16D for ; Sat, 4 Jun 2016 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 37jcwoBvva5Q for ; Sat, 4 Jun 2016 07:14:41 -0700 (PDT) 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 158CB12D150 for ; Sat, 4 Jun 2016 07:14:40 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b9CLT-000IvC-PY; Sat, 04 Jun 2016 10:14:35 -0400 Date: Sat, 04 Jun 2016 10:14:30 -0400 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <224967fe-5961-e989-a9e9-401c99b5335d@seantek.com> References: <2C60969953BC849FDA35733E@JcK-HP8200.jck.com> <53928f62-3de9-567b-e8dc-444a5c66d477@gmx.de> <2F02EA4EFFCD81CD6ADBB789@JcK-HP8200.jck.com> <7883335563DB29FFAF9BE5DB@JcK-HP8200.jck.com> <96CD7976C66DD563194A554B@JcK-HP8200.jck.com> <224967fe-5961-e989-a9e9-401c99b5335d@seantek.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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] q-component copied verbatim X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 14:14:43 -0000 --On Friday, June 03, 2016 12:31 -0700 Sean Leonard wrote: > On 6/3/2016 7:45 AM, Barry Leiba wrote: >> We have the following text change proposed, with John's >> asking others if the change is OK. Any (concise, please) >> answers to that question?: >... >>> Wfm, including the latter. Would others please comment, >>> especially if they have objections, before I change the text? > > As to the specific change: > > FROM: > > those for queries to the resource located via that URL > TO: ==> > those for the query component of that URL > I agree and approve. Done. I've also taken "verbatim" out. Both are still tentative and subject to others objecting -- fwiw, I'm getting very anxious about these decisions being made by three or four people. I've also added some example text as requested earlier. 2141bis-17 should be posted shortly after I get the next version of semantics-clarif up, but that is unlikely to be before early next week. > I still disagree strongly with the syntax of that paragraph, > namely, using "?=" as an introducer anywhere in the > q-component. Remembering that decision was reached after a discussion that went nowhere after an extended period and that Andy finally delegated the decision to Peter and myself, if you have a new suggestion to make, as far as I'm concerned, please make it and see if you can get support. However some of the earlier discussions suggest to me that part of the disagreement derives from preferences for thinking about implementation in terms of regular expression-like pattern matching versus thinking about them in terms of LR(k)-like parsing (or in some other way). I don't think that difference in preference can be resolved; certainly this WG cannot resolve it. I don't remember if Strachey's time at MIT overlapped with DeRemer and Thompson (if not, it was near-miss), but the discussion has certainly been going on for a very long time now. To at least some extend, viewing URIs as strings isolated from the surrounding environment may be suggestive of the regular expression approach; thinking about parsing them as part of parsing a larger text collection (like an XML or HTML document or something in a programming language) may suggest the LR(k) / LALR approach. I suggest that we not spend a lot of time on it on the basis of preferences between the approaches. john john From nobody Wed Jun 8 06:28:35 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584E812D1C1 for ; Wed, 8 Jun 2016 06:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 ePBCQ4WCXBCF for ; Wed, 8 Jun 2016 06:28:32 -0700 (PDT) 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 63F9012B03D for ; Wed, 8 Jun 2016 06:28:32 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bAdX5-0005k8-CY for urn@ietf.org; Wed, 08 Jun 2016 09:28:31 -0400 Date: Wed, 08 Jun 2016 09:28:26 -0400 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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] draft-ietf-urnbis-semantics-clarif-04 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:28:34 -0000 Hi. Well, as I feared, last week disappeared and it has taken me until now to get this ready. Barry knows some of the rest of what has gotten in the way, but it isn't important. The new draft should be posted very soon. This draft is an attempt to explore what the WG really wants. When "URNs are not URIs" was written, and then transformed into this document, my sense of the WG's preference was to keep it short, high-level, and to the point. From that perspective, I probably removed too little material in the transformation rather than two much. Recent comments, especially from Julian and Sean, and with no one speaking in opposition, suggest that it needs to be far more specific and explicit about justification, relationships to 3986 and other documents, and exactly what it does or does not do. I think this version does that. It describes the disagreements about how to read 3986 and this document in terms of bypassing those disagreements rather than resolving them, is a lot more explicit about what "updates 3986" means (although I think that really was covered in Section 4 of -03), and so on. It also mentions the perceived problem that 3986 has a perspective (and maybe some specific requirements) that are inconsistent with 2141/3406, an issue that was discussed at some length a few years ago. In reading the I-D, please note that I've inserted a note to the RFC Editor below the Abstract (after this version, I will turn it into a comment to them in the XML, but the WG should see it now and understand its request to not nit-pick tense). I've also inserted a number of "CREF" comments that are intended to call WG attention to particular issues or choices and solicit input. A few artifacts of "URNs are not URIs" have been removed or rewritten but, in reading this spec, the WG needs to understand that the earlier approach and this "syntax only" one are different approaches to address the same issue (even though the problem itself can be characterized in multiple ways, something I hope the I-D now makes clear). The earlier one is easier to understand and write about, but many people believe it had adverse consequences, particularly for generic URI parsers and processors. The current one tries to made a much more subtle distinction, one that is complicated by there not being a clear dichotomy between syntax and semantics in 3986 (at least a distinction that is apparently not clear to many people). However, I'm fairly unhappy with the result (one reason this wasn't posted Sunday is that I was even more unhappy with what I had then). It feels very tedious to me, spending a lot of words and space repeating the same things in different words. I've left one section and a few paragraphs that were less redundant but it don't seem to be necessary for this draft. I've proposed just dropping some of those and have asked questions about others. It seems to me that the WG now has a choice among (at least): (i) Deciding that this reflects what was want and is approximately good enough, plus or minus editorial work and cleaning out the CREF comments and maybe some sections or paragraphs. (ii) Deciding that this generally reflects what we want but needs extensive and/or substantive additional work. (iii) Deciding that the document has now served its purpose and should be dropped entirely, replaced by inserting a variation on the third and fourth paragraphs of the Introduction and as little of Section 4 as possible into 2141bis. One of the things that is _not_ on the above list is revisiting the "syntax only" decision. I think the WG Chairs have rather clearly closed that question and the purpose of this I-D (or text in 2141bis to replace it under (iii) above) is just to implement that decision. Personal comment: I note that both (ii) and (iii) above are likely to require significant energy and, unless something changes with how the WG works, calendar time to settle on text and reach consensus. I therefore see those options as tradeoffs against "getting done" and the risk of the WG running completely out of steam before we can produce documents for IETF Last Call. I also think that available time (or the WG, its leadership, document authors, etc.) is much better spent getting the technical and editorial details of 2141bis right rather than striving for generally perfection or fussing with a transitional/ explanatory documents like this one and draft-ietf-urnbis-ns-reg-transition. YMMD, but I think it will help if people are explicit about our priorities. Finally, it would be really helpful to making progress, and to me personally, if people would read and comment on this quickly, before everyone (including myself) loses track of what is in it and why or of the list discussions that led to the changes in it. best, john From nobody Wed Jun 8 06:50:25 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9C612D128 for ; Wed, 8 Jun 2016 06:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 wZ8elMRiIJ2H for ; Wed, 8 Jun 2016 06:50:20 -0700 (PDT) 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 AC7D612D0E0 for ; Wed, 8 Jun 2016 06:50:19 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bAdsA-0005m7-G3 for urn@ietf.org; Wed, 08 Jun 2016 09:50:18 -0400 Date: Wed, 08 Jun 2016 09:50:13 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <88B18924B898F35F6C23423F@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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] draft-ietf-urnbis-semantics-clarif-04 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:50:24 -0000 Sorry... one additional note: In several places, the I-D uses phrases like "some members of the community believe that..." in preference to ones closer to "3986 requires that...". That distinction is a little tedious, but the first type of statement is incontrovertibly true while the second has proven to be an invitation for heated arguments that don't go anywhere. If anyone believe that those who hold such beliefs are ignorant, stupid, or wrong-headed, feel free, within the limits of IETF rules for appropriate behavior, and preferably off-list, to tell them that but let's not let it get in the way of making progress. john From nobody Wed Jun 8 07:03:11 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EACB812D971; Wed, 8 Jun 2016 07:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608140303.19971.27568.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 07:03:03 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-04.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:03:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised of the IETF. Title : URN Semantics Clarification Author : John C Klensin Filename : draft-ietf-urnbis-semantics-clarif-04.txt Pages : 14 Date : 2016-06-08 Abstract: Experience has shown that identifiers associated with persistent names have properties and requirements that may be somewhat different from identifiers associated with the locations of objects. This is especially true when such names are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Names (URNs) to evolve to meet the needs of the Library, Museum, Publisher, and Information Science communities and other users, this specification separates URNs from the semantic constraints that many people believe are part of the specification for Uniform Resource Identifiers (URIs) in RFC 3986, updating that document accordingly. The syntax of URNs is still constrained to that of RFC 3986, so generic URI parsers are unaffected by this change. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 8 12:55:15 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A0412D73B for ; Wed, 8 Jun 2016 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 h4j7wwlctmDx for ; Wed, 8 Jun 2016 12:55:12 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8069312D739 for ; Wed, 8 Jun 2016 12:55:12 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id g20so18022376ywb.0 for ; Wed, 08 Jun 2016 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=x5Now0xiCVzm/8yYun/p/uaL8wLh56PCsOqB/DOm7pE=; b=dL5M/z7EnOaiMQSC+wjZpfM/NI75HUlnBKNk3xhP3xn/TooL4wu3KnC8DvujexutD4 49TIwUpm5tQx2J0jaasUjDR1nH/HaKvbqpHGB3dZlPzynsWhGrcKGPtxgKyEBiOWNQ+D 6N17Xih4UpwH02BIx2IvHeCzymZmxiYeZxR4DXhsBmI5zyq52gMBhAv6A0BWrBVjG8I6 W9jXAJYsHh+2fWGn5OGAk1xF5rYKMxRgG4D75OLzvSJ15xMMUrl6kzSsg6QARj1pCpPz Ivm9KQlWRbfM6ubccNCpGiMi626eMsD+oCb1kXmQ0QCH6XVOCQ88AbEzuveDHLBx9KGG dL4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=x5Now0xiCVzm/8yYun/p/uaL8wLh56PCsOqB/DOm7pE=; b=fqbiwuiJJTShYP1CzW41AokBLukNmGT45fsM0rf5yUDtP9D4ifE7Ap1Jdnk/HuNoRr YQHoR9G7rLeLIYUDcgkB0Te1Ruwswk5SyUPscH9trlKh8gsZXZZwsSwxNDc/QrAqeE/m fvpgI9pIK08I1STrFkwN8gSZxiE+RDhGQplfBqO2ivvO/idKxn4Dsa4ClU8tKacrccMj uHaGCFnhhCokkbQDccfxi7hvnYRMaoRZ2a5t5Orm4lYGj3HrqvSs5M2B53TSlzzr8Evj 4Yfxg9OnZuktjnQ8QEURk0zZPZsJhaDA1ai2F9fXC7x35zwsiGqATA9mM/zu2t0WTcr/ dJRA== X-Gm-Message-State: ALyK8tIVOWBykg4CCC0c84Ekv35dcyDf93eXppTZVohUKuyJsmCXVcEMJK6NrdUBz5ZV2Y+rnzgWPzHCSvMX0A== X-Received: by 10.13.246.6 with SMTP id g6mr3955702ywf.202.1465415711777; Wed, 08 Jun 2016 12:55:11 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.37.6 with HTTP; Wed, 8 Jun 2016 12:55:11 -0700 (PDT) From: Barry Leiba Date: Wed, 8 Jun 2016 15:55:11 -0400 X-Google-Sender-Auth: LHdg48XcFKRDIhUV8pbXtGr2oJ8 Message-ID: To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [urn] URNbis conference call ("virtual meeting") X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:55:14 -0000 The chairs and authors have been chatting, and we think a "virtual meeting" very soon will be helpful in getting us moved forward. I propose that we have such a meeting on Wednesday, 29 June -- three weeks from today for two hours, at 12:00 NY time (see below). If we can get those of you who are active in the discussion on a call then, we'll set it up. We don't have a lot of flexibility on the time, so please let us know quickly whether you can free the time to do it, and make any alternative time suggestions right away. We'll need to get the Secretariat to announce this on Monday in order to meet the IESG's requirements for advance notice and not have to worry about glitches... so, quickly, please. Proposed time: Wednesday, 29 June at... 09:00 - 11:00 California 12:00 - 14:00 NY 17:00 - 19:00 Germany 18:00 - 20:00 Finland Barry From nobody Wed Jun 8 13:24:42 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F7A12D0EB for ; Wed, 8 Jun 2016 13:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=bpp7gd3s; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=KO+sSa3z 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 wKrzApRHzI0r for ; Wed, 8 Jun 2016 13:24:39 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BCC12B00C for ; Wed, 8 Jun 2016 13:24:39 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id 09CEE15A00CD; Wed, 8 Jun 2016 22:24:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1465417478; bh=9A4UaGDOL2QBq7kC/evjzeobO8JvO6HbaKk1ZMq5fwE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bpp7gd3swEKK2UKPNppNM7JqAO9va/KdEhMkW+0qQBE5s0lGb8urLhHZnn0mky4ky /+/b0iO7/bmIEIqh01k6lp+obIcVGTeKeKcGnM4fIyuMjjsg2TbPPPgAHtPCWajd9h BHYFoh093U5lTx7/2tI/YwcMGOGBA6aGui/2OgO4= Received: from [192.168.178.20] (unknown [93.217.77.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 7A33415A00CD; Wed, 8 Jun 2016 22:24:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1465417477; bh=9A4UaGDOL2QBq7kC/evjzeobO8JvO6HbaKk1ZMq5fwE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KO+sSa3z4ynuJPF1myN5k/JpFK1+n3pQ3+v+bl1e1Vurq63K70zzLlOi3EjYx+XrO uj4oNVBU9EzZEdAR/ZTkTsIQNM4chEJ9LsWYYA/Kuw61MXg+UfExFWlH1EotNACwQR xGJUy+zl0jgPG4J5g/cPYLgROXwelKgxdkV2BLSc= To: Barry Leiba , "urn@ietf.org" References: From: Julian Reschke Message-ID: <3031a4c6-3fd3-0bb2-4766-551652089732@greenbytes.de> Date: Wed, 8 Jun 2016 22:24:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URNbis conference call ("virtual meeting") X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:24:41 -0000 On 2016-06-08 21:55, Barry Leiba wrote: > The chairs and authors have been chatting, and we think a "virtual > meeting" very soon will be helpful in getting us moved forward. I > propose that we have such a meeting on Wednesday, 29 June -- three > weeks from today for two hours, at 12:00 NY time (see below). If we > can get those of you who are active in the discussion on a call then, > we'll set it up. We don't have a lot of flexibility on the time, so > please let us know quickly whether you can free the time to do it, and > make any alternative time suggestions right away. We'll need to get > the Secretariat to announce this on Monday in order to meet the IESG's > requirements for advance notice and not have to worry about > glitches... so, quickly, please. > > Proposed time: Wednesday, 29 June at... > 09:00 - 11:00 California > 12:00 - 14:00 NY > 17:00 - 19:00 Germany > 18:00 - 20:00 Finland > > Barry Works for me. Best regards, Julian From nobody Wed Jun 8 13:28:57 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63912B063 for ; Wed, 8 Jun 2016 13:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zk65O_cAXWAP for ; Wed, 8 Jun 2016 13:28:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B36F112B00C for ; Wed, 8 Jun 2016 13:28:51 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 34938E825F; Wed, 8 Jun 2016 14:40:53 -0600 (MDT) To: Julian Reschke , Barry Leiba , "urn@ietf.org" References: <3031a4c6-3fd3-0bb2-4766-551652089732@greenbytes.de> From: Peter Saint-Andre Message-ID: <5a8be3c7-b41f-0450-8c37-be3e4494123e@stpeter.im> Date: Wed, 8 Jun 2016 14:28:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <3031a4c6-3fd3-0bb2-4766-551652089732@greenbytes.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URNbis conference call ("virtual meeting") X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:28:56 -0000 On 6/8/16 2:24 PM, Julian Reschke wrote: > On 2016-06-08 21:55, Barry Leiba wrote: >> The chairs and authors have been chatting, and we think a "virtual >> meeting" very soon will be helpful in getting us moved forward. I >> propose that we have such a meeting on Wednesday, 29 June -- three >> weeks from today for two hours, at 12:00 NY time (see below). If we >> can get those of you who are active in the discussion on a call then, >> we'll set it up. We don't have a lot of flexibility on the time, so >> please let us know quickly whether you can free the time to do it, and >> make any alternative time suggestions right away. We'll need to get >> the Secretariat to announce this on Monday in order to meet the IESG's >> requirements for advance notice and not have to worry about >> glitches... so, quickly, please. >> >> Proposed time: Wednesday, 29 June at... >> 09:00 - 11:00 California >> 12:00 - 14:00 NY >> 17:00 - 19:00 Germany >> 18:00 - 20:00 Finland >> >> Barry > > Works for me. Ditto. See you then! Peter From nobody Wed Jun 8 14:46:04 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C069A12D1A5 for ; Wed, 8 Jun 2016 14:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 x-Hzy-EnmhgS for ; Wed, 8 Jun 2016 14:46:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A567612D126 for ; Wed, 8 Jun 2016 14:46:00 -0700 (PDT) Received: from [192.168.123.151] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5C35050A86; Wed, 8 Jun 2016 17:45:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Wed, 8 Jun 2016 14:45:56 -0700 Content-Transfer-Encoding: 7bit Message-Id: <446BFC7C-9478-4A9F-8D0D-6F3B06BBDF36@seantek.com> References: To: Barry Leiba X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URNbis conference call ("virtual meeting") X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 21:46:04 -0000 > On Jun 8, 2016, at 12:55 PM, Barry Leiba wrote: > > The chairs and authors have been chatting, and we think a "virtual > meeting" very soon will be helpful in getting us moved forward. I > propose that we have such a meeting on Wednesday, 29 June -- three > weeks from today for two hours, at 12:00 NY time (see below). If we > can get those of you who are active in the discussion on a call then, > we'll set it up. We don't have a lot of flexibility on the time, so > please let us know quickly whether you can free the time to do it, and > make any alternative time suggestions right away. We'll need to get > the Secretariat to announce this on Monday in order to meet the IESG's > requirements for advance notice and not have to worry about > glitches... so, quickly, please. > > Proposed time: Wednesday, 29 June at... > 09:00 - 11:00 California > 12:00 - 14:00 NY > 17:00 - 19:00 Germany > 18:00 - 20:00 Finland > > Barry Works for me too. Sean From nobody Wed Jun 8 19:18:12 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789A12D0BA for ; Wed, 8 Jun 2016 19:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 W5oAQ-R1dVD7 for ; Wed, 8 Jun 2016 19:18:07 -0700 (PDT) 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 3D87E12D56C for ; Wed, 8 Jun 2016 19:18:07 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bApXm-000AaM-1G; Wed, 08 Jun 2016 22:18:02 -0400 Date: Wed, 08 Jun 2016 22:17:57 -0400 From: John C Klensin To: Barry Leiba , urn@ietf.org Message-ID: <4633EB8F0B99D61B89141897@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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] URNbis conference call ("virtual meeting") X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 02:18:10 -0000 WFM john --On Wednesday, June 08, 2016 15:55 -0400 Barry Leiba wrote: > The chairs and authors have been chatting, and we think a > "virtual meeting" very soon will be helpful in getting us > moved forward. I propose that we have such a meeting on > Wednesday, 29 June -- three weeks from today for two hours, at > 12:00 NY time (see below). If we can get those of you who are > active in the discussion on a call then, we'll set it up. We > don't have a lot of flexibility on the time, so please let us > know quickly whether you can free the time to do it, and make > any alternative time suggestions right away. We'll need to get > the Secretariat to announce this on Monday in order to meet > the IESG's requirements for advance notice and not have to > worry about glitches... so, quickly, please. > > Proposed time: Wednesday, 29 June at... > 09:00 - 11:00 California > 12:00 - 14:00 NY > 17:00 - 19:00 Germany > 18:00 - 20:00 Finland > > Barry > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Jun 8 21:46:07 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48B212B02A for ; Wed, 8 Jun 2016 21:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 LJqOnyTPx6-o for ; Wed, 8 Jun 2016 21:46:01 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0137.outbound.protection.outlook.com [104.47.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B4B12D0C3 for ; Wed, 8 Jun 2016 21:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G4MSQR4bJ5GxcpcsE+9wT3fkcYCe3hlG20DLnDe+9d4=; b=j56w6k8ZqAqn5JKPc33peY9j2fQGM6VGGhnuLV7zg+lXqVj7p+OnBzp+iKlu53BiX+m0dpAWG6STOeVr02ZcKQ8RU+bseKbn73yNkXwSqxaxglrdzxxOdISyDf6KF6+q/1silEoNU4I4wbqE7FOEbijh6Eh6ZRCBoe+EhCVtWz0= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) with Microsoft SMTP Server (TLS) id 15.1.511.8; Thu, 9 Jun 2016 04:45:56 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0511.010; Thu, 9 Jun 2016 04:45:56 +0000 From: "Hakala, Juha E" To: Barry Leiba , "urn@ietf.org" Thread-Topic: [urn] URNbis conference call ("virtual meeting") Thread-Index: AQHRwb+0TPEaUXCobkWAF1/QCG02fJ/gj/3Q Date: Thu, 9 Jun 2016 04:45:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: c70f1276-a6bf-477a-ee6a-08d39020f20d x-microsoft-exchange-diagnostics: 1; VI1PR07MB1727; 5:t9ifUBdCrqhqi09PQPvPTh4kB/EtqbEmfTuBSyBhVYpRCqFvyOOS11nkKqxkCKD8ovDsq8zDeeYki0VqCHkA4SKLoe3gAD7Vms/YHMpqQnkHQZ8TgCyJylxGF7DiGqSibPa8xEQlgPNEvXhAQICglA==; 24:XxauNIjfRRmFKMm1oS2ryif/gzp+37t88lGJAxoupKGuIMHOOGs3lEnyrSGUXKzlfDM3gMmBJHb6S2CKVTcUE+qW0fjEwuo8icSiM8NEEy4=; 7:AIaPW4nbZhNuoWQPqNMFyRsXllvBj99MKI6GfHG68Wf4IgFYX9YtkwsmfTUv4igHSHEwsXAnQQzdFtQiiAIJFSrDres2afiyDc/3xlL88ejQSmMaITTvxc69Ju0z8Qrid4EbY1JZiaQF8SGeQT/lyuvP8D/TfKb+61peA+k1KAofZvB41zmpGhAknMXaYKHWKX/MUkRoyP6xK+e3dM5vVlL70LUXtC1a2kIMmRAsYV4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1727; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1727; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1727; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(30513003)(13464003)(199003)(5004730100002)(2950100001)(107886002)(10400500002)(2900100001)(97736004)(5001770100001)(77096005)(81166006)(66066001)(2906002)(6116002)(15975445007)(5002640100001)(68736007)(3846002)(5003600100002)(8936002)(586003)(19580405001)(9686002)(2501003)(74316001)(122556002)(11100500001)(189998001)(102836003)(92566002)(81156014)(8676002)(76576001)(105586002)(106116001)(74482002)(106356001)(5008740100001)(19580395003)(33656002)(87936001)(3660700001)(3280700002)(54356999)(76176999)(50986999)(86362001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1727; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 04:45:56.0443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1727 Archived-At: Subject: Re: [urn] URNbis conference call ("virtual meeting") X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 04:46:05 -0000 Hello,=20 fine with me as well.=20 Juha > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: 8. kes=E4kuuta 2016 22:55 > To: urn@ietf.org > Subject: [urn] URNbis conference call ("virtual meeting") >=20 > The chairs and authors have been chatting, and we think a "virtual meetin= g" > very soon will be helpful in getting us moved forward. I propose that we > have such a meeting on Wednesday, 29 June -- three weeks from today for > two hours, at 12:00 NY time (see below). If we can get those of you who > are active in the discussion on a call then, we'll set it up. We don't h= ave a > lot of flexibility on the time, so please let us know quickly whether you= can > free the time to do it, and make any alternative time suggestions right > away. We'll need to get the Secretariat to announce this on Monday in > order to meet the IESG's requirements for advance notice and not have to > worry about glitches... so, quickly, please. >=20 > Proposed time: Wednesday, 29 June at... > 09:00 - 11:00 California > 12:00 - 14:00 NY > 17:00 - 19:00 Germany > 18:00 - 20:00 Finland >=20 > Barry >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon Jun 13 11:35:51 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D849812D92C; Mon, 13 Jun 2016 11:35:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613183549.6799.73692.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 11:35:49 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] The URNBIS WG Virtual Interim Meeting: June 29, 2016 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Reply-To: urn@ietf.org List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 18:35:50 -0000 The Uniform Resource Names, Revised (urnbis) working group will have a virtual meeting scheduled for two hours on 29 June at 16:00 UTC. The purpose of the meeting is to discuss the two active documents (draft-ietf-urnbis-rfc2141bis-urn and draft-ietf-urnbis-semantics-clarif), to resolve issues with those documents, and to plan for completion of the work. For convenient reference, the meeting time in the time zones of the active participants are Wednesday, 29 June at... 09:00 - 11:00 California 12:00 - 14:00 NY 17:00 - 19:00 Germany 18:00 - 20:00 Finland Call-in details, along with any other late information, will be posted to the working group's mailing list . The URNbis working group chairs From nobody Wed Jun 22 07:57:58 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F5212B059 for ; Wed, 22 Jun 2016 07:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b7BRz-Uzzy14 for ; Wed, 22 Jun 2016 07:57:54 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB8B12DA54 for ; Wed, 22 Jun 2016 07:48:21 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id i12so43440326ywa.1 for ; Wed, 22 Jun 2016 07:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=Lj5bL91NGTOMFNEhAXpQ0XJ7fWZ+RR+AJY4dtmZgL9A=; b=itiYIBsSGF1jj2kXSjHWh+EhlwOJ+hXKgnS39mRGzP+1He7qKABsAChrqUN5bgunXA ORZY2BQFVo9NDbywkvrWOdubfUPDR7wei/Q+IK8EwxTJjb86eoDb+ddIY/0HokRjbRU3 93WJF7XbVA393rkYxW1VWS9IH5P9bhAtjX2aMHSeDFIXlhFvUvm0CjTD82LEBLIJyP08 NWoqUDdwCz2bQ5eQDKG0oLZ0U7C2t/Sz8n03txv5rkzj1JpfiU+SEfoKEKwKaQ8L2LXW NxOFJ2j0wqjiQCN1nbeWdlO61XBhfhxtVtA9GLWiTGE0N7oCqdrurDZNQDDuu9iSTji2 Xd/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Lj5bL91NGTOMFNEhAXpQ0XJ7fWZ+RR+AJY4dtmZgL9A=; b=dLadizBcvrL5zhYEpQZzBSgIsMEzcCN/X+qctHlqeR215zjt98Jz5zysWyIlaf0j2G Ij3eBQ4wKEp5Ky/76f3tHzsXWodWrRysAzX+K17w9qXiBljJaCub1le339nFSYEHElpg 7RoovQ166/WPPs/aL30OLZsoDjCqOhxkPICZ7YMWpbdE6zddwmLM+PkDs+QUP2tDAU06 tqTYg5d+ahbAvczsAMQbpz1V3x08VG7DZw+DGoDY+mSOXfTuXvmNM1JWBP10EcGqJlWC oKBcNjkM8TPNwyFifNY3dU19Ir+N38HpUkfJAL2WmJymz1I15qS52remXP8vcB3jnw7o 2u4g== X-Gm-Message-State: ALyK8tLOVR4JUSw2GzMaAFkNAqCRB+G1OXMUuQi2685kv/isMQ3RlC51suxho3UuorYHkQTdtB1yO4fmyU9j2Q== X-Received: by 10.37.203.196 with SMTP id b187mr14435592ybg.134.1466606900175; Wed, 22 Jun 2016 07:48:20 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.12.145 with HTTP; Wed, 22 Jun 2016 07:48:18 -0700 (PDT) From: Barry Leiba Date: Wed, 22 Jun 2016 10:48:18 -0400 X-Google-Sender-Auth: FUhJnTg2rIpBdfQ5aQtJHFdW6rU Message-ID: To: "urn@ietf.org" Content-Type: multipart/mixed; boundary=94eb2c05dc6c4f920d0535df070d Archived-At: Subject: [urn] WebEx meeting invitation: URNbis virtual meeting X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 14:57:57 -0000 --94eb2c05dc6c4f920d0535df070d Content-Type: multipart/alternative; boundary=94eb2c05dc6c4f92080535df070b --94eb2c05dc6c4f92080535df070b Content-Type: text/plain; charset=UTF-8 For whatever reason, the WebEx invitations don't seem to be getting to the working group mailing list. So, here's the information for the upcoming virtual meeting next Wednesday, 29 June. The meeting is open to all, and I think the password may only be needed if you're joining from the WebEx app on a mobile device. The IETF WebEx account does not have International dial-in nor call-back access. You can use the WebEx application (web or mobile device) to connect to audio via the built-in VoIP. You can also use a service such as Skype to call the US toll-free number -- Skype makes toll-free calls at no charge. Barry, urnbis chair ---------- Forwarded message ---------- From: URNBIS Working Group Date: Tue, Jun 21, 2016 at 8:01 PM Subject: WebEx meeting invitation: URNbis virtual meeting Hello, URNBIS Working Group invites you to join this WebEx meeting. *URNbis virtual meeting* Wednesday, June 29, 2016 12:00 pm | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs Meeting number (access code): 643 058 876 Meeting password: 1234 Add to Calendar When it's time, join the meeting . *Join by phone* *1-877-668-4493 <1-877-668-4493>* Call-in toll free number (US/Canada) *1-650-479-3208 <1-650-479-3208>* Call-in toll number (US/Canada) Toll-free calling restrictions Can't join the meeting? IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. --94eb2c05dc6c4f92080535df070b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For whatever reason, the WebEx invitations don't = seem to be getting to the working group mailing list.=C2=A0 So, here's = the information for the upcoming virtual meeting next Wednesday, 29 June.

The meeting is open to all, and I think the passwor= d may only be needed if you're joining from the WebEx app on a mobile d= evice.=C2=A0 The IETF WebEx account does not have International dial-in nor= call-back access.=C2=A0 You can use the WebEx application (web or mobile d= evice) to connect to audio via the built-in VoIP.=C2=A0 You can also use a = service such as Skype to call the US toll-free number -- Skype makes toll-f= ree calls at no charge.

Barry, urnbis chair
<= br>
---------- Forwarded message ----------
Fr= om: URNBIS Working Group <messenger@webex.com>
Date: Tue, Jun 21, 2016 at 8:01 PM
Subject: WebEx meeting invita= tion: URNbis virtual meeting
Hello,
URNBIS Working Group invites you to join this WebEx meeting= .
=C2= =A0
URNbis virtual meeting
Wednesday, June 29, 2016
12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0Eastern Daylight Time (New Yor= k, GMT-04:00)=C2=A0=C2=A0|=C2=A0=C2=A02 hrs
Meeting number (access code): 643 058 876
=09
Meeting password: 1234
=09
= =C2=A0
Add to Calendar
When it's time, <= a href=3D"https://ietf.webex.com/ietf/j.php?MTID=3Dm61147f677b162fd9070e821= 1e5012dd2" style=3D"color:#00aff9;text-decoration:none" target=3D"_blank">j= oin the meeting.
= =C2=A0
=09
Join by phone
1-877-668-4493=C2=A0Call-in toll fr= ee number (US/Canada)
1-650-479-3208<= /a>=C2=A0Call-in toll number (US/Canada)
= Toll-free calling restrictions
=C2= =A0
Can't join the meeting?
=C2= =A0
IMPORTANT NOTICE: Please note that this WebEx service allows audio= and other information sent during the session to be recorded, which may be= discoverable in a legal matter. By joining this session, you automatically= consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session.

--94eb2c05dc6c4f92080535df070b-- --94eb2c05dc6c4f920d0535df070d Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Disposition: attachment; filename="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 X-Attachment-Id: 604495151494fb5b_0.1 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86YmFycnlsZWliYUBjb21wdXRlci5vcmcKT1JHQU5J WkVSO0NOPSJVUk5CSVMgV29ya2luZyBHcm91cCI6TUFJTFRPOnVybmJpcy1jaGFpcnNAaWV0Zi5v cmcKRFRTVEFSVDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTYwNjI5VDEyMDAwMApEVEVORDtUWklE PSJFYXN0ZXJuIFRpbWUiOjIwMTYwNjI5VDE0MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDY2NTUzNjcxClVJRDo0ZTNkN2E0 ZC05OTk3LTQ2NzAtYWI0OC1iNGRkZGFkZGRiZjcKRFRTVEFNUDoyMDE2MDYyOVQxNjAwMDBaCkRF U0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTkxMDZkN2M0N2U4YjA0ZTdiNzJmNWUzNDc4ODI5ODVjXG5NZWV0 aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDMgMDU4IDg3NlxuTWVldGluZyBwYXNzd29yZDog MTIzNFxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVl IG51bWJlciAoVVMvQ2FuYWRhKSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIg KFVTL0NhbmFkYSlcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBcbmh0dHBzOi8v d3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qg am9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vaGVscC53ZWJleC5jb20vZG9jcy9ET0MtNTQxMlxu XG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNl IGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBt YXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50 IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29y ZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0 aGUgc2Vzc2lvbi5cbgpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9odG1sOgk8Rk9OVCBTSVpFPSIx IiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj4mbmJzcDs8QlI+PEZPTlQgU0laRT0i NCIgRkFDRT0iQVJJQUwiPgkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTkxMDZkN2M0N2U4YjA0ZTdiNzJmNWUzNDc4ODI5ODVjIj48Rk9OVCBTSVpFPSIz IiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkpvaW4gV2ViRXggbWVldGluZzwvRk9OVD48 L2E+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDMg MDU4IDg3NjwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQkJCQk8dGFibGU+ PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRp bmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPjEyMzQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+CQk8L0ZPTlQ+PEZP TlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxGT05U IFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04NzctNjY4LTQ0OTM8L3N0cm9u Zz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7 IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+ MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5h ZGEpPC9GT05UPiZuYnNwOyA8QlI+PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90 b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIg RkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZu YnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZuYnNwOzxCUj4JPGEgaHJlZj0iaHR0cHM6Ly9oZWxw LndlYmV4LmNvbS9kb2NzL0RPQy01NDEyIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9IkFyaWFsIj5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD48L2E+CSZuYnNwOzxC Uj4mbmJzcDs8QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5J TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwg ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNl c3Npb24uPC9GT05UPjwvRk9OVD4KU1VNTUFSWTpVUk5iaXMgdmlydHVhbCBtZWV0aW5nClBSSU9S SVRZOjUKQ0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDE1TQpBQ1RJT046RElT UExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxF TkRBUgo= --94eb2c05dc6c4f920d0535df070d-- From nobody Wed Jun 22 08:21:55 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2127512DA13; Wed, 22 Jun 2016 08:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DV99h8q2hwGp; Wed, 22 Jun 2016 08:21:51 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6412D54F; Wed, 22 Jun 2016 08:09:31 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id u5MF9ROx023276; Wed, 22 Jun 2016 16:09:27 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id u5MF9SwE013778; Wed, 22 Jun 2016 16:09:28 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u5MF9SsO023965; Wed, 22 Jun 2016 16:09:28 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u5MF9SBI023964; Wed, 22 Jun 2016 16:09:28 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: urn@ietf.org References: <20160613183549.6799.73692.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 22 Jun 2016 16:09:28 +0100 In-Reply-To: <20160613183549.6799.73692.idtracker@ietfa.amsl.com> (IESG Secretary's message of "Mon\, 13 Jun 2016 11\:35\:49 -0700") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: IETF Announcement List Subject: Re: [urn] The URNBIS WG Virtual Interim Meeting: June 29, 2016 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:21:54 -0000 IESG Secretary writes: > The Uniform Resource Names, Revised (urnbis) working group will have > a virtual meeting scheduled for two hours on 29 June at 16:00 UTC. The > purpose of the meeting is to discuss the two active documents > (draft-ietf-urnbis-rfc2141bis-urn and draft-ietf-urnbis-semantics-clarif), > to resolve issues with those documents, and to plan for completion of the work. > > For convenient reference, the meeting time in the time zones of the > active participants are Wednesday, 29 June at... > 09:00 - 11:00 California > 12:00 - 14:00 NY > 17:00 - 19:00 Germany > 18:00 - 20:00 Finland Sorry for delayed response -- yes, I can attend (at 1700 BST. Please note that the times listed for Germany and Finland are inconsistent with those listed for California and New York - I'm assuming the latter are correct). ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed Jun 22 10:31:12 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B2612D9AC; Wed, 22 Jun 2016 10:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CkGNXtmb3qtk; Wed, 22 Jun 2016 10:31:07 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755CC12D9CC; Wed, 22 Jun 2016 10:30:47 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f6so44228373ith.0; Wed, 22 Jun 2016 10:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3/e9L5pcvbimoWN4uqXlXoivfVLVW3I9VFJygl5uRZ8=; b=UqgV5dn9mwsjw2LDAjlz1DqXggd/QxUp2C3OKntWpAraBvVgxf1kN6dcpO5QoFacUC jLez4GF1eERqXkjTyWjUk7UrNabeVHqT+8OFYchrZh5lGQnQFKUepV5GfB6We3YIwAqC GyXL4Xaq/sUv+b5/YDsdqkSA/SPsCsVpRl1nJbbSN48T7qcFv4MOgGtMslmyG1xgH2xK ZZJWbRbFRNxV1gvmdhwlQkORdndly89ZVOdy73vyNx1m74Gxqt5BXXUr0WPuC/J2zlfB UAfLyPYnDoqylYIWnDVvh5AlM8/K881zwtsvE6fXcJIQGTneU76A8R/vHsnQxwoHjgK6 +clw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3/e9L5pcvbimoWN4uqXlXoivfVLVW3I9VFJygl5uRZ8=; b=inGNaczP/+zLZOwoqPhlaQ6CZEUK7c1jW1IoxzbnCEXQ2RpIrLISxgEHMJfTZnimXd cP8IPfEkbzleXPS45yAc9weZ7w54/K0G9DfpM/tTwHH1v/MFABlloD2xL74WegxoyppD GpoTuu17wUIC4eAnqHpI+3YUtmu9ZP7K5vV5AlcnuKXqNEGAN02FQd+2/Yuv9/tX0Aw5 KnSwB4GgfoH9g0TUOqNlN+2bMIWsa13OzVrA91FEe0n8AZrgh2WV8Uotl6E6FULM/atG JfFvRdMSFnfsVpb5+Ntex1o2whKvigDpZ5peGwoFeDLeHjyFe6Z3XA76ox2mnQp81kO4 ivig== X-Gm-Message-State: ALyK8tLvN+UAGhV9hfHFqadw5JEeghGAOKv92/bR1EE8cA/UpJvnXbPWsSmlec+XFvgk8vIehlDhAYy8XhtO6Q== X-Received: by 10.36.19.16 with SMTP id 16mr16414829itz.76.1466616646693; Wed, 22 Jun 2016 10:30:46 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.78 with HTTP; Wed, 22 Jun 2016 10:30:46 -0700 (PDT) In-Reply-To: References: <20160613183549.6799.73692.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 22 Jun 2016 13:30:46 -0400 X-Google-Sender-Auth: ehNqycMZ_-LVURXYmQoLHZeO1A8 Message-ID: To: "Henry S. Thompson" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" , IETF Announcement List Subject: Re: [urn] The URNBIS WG Virtual Interim Meeting: June 29, 2016 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:31:11 -0000 > Sorry for delayed response -- yes, I can attend (at 1700 BST. Please > note that the times listed for Germany and Finland are inconsistent with > those listed for California and New York - I'm assuming the latter are > correct). Ah, I got the time conversions wrong. I'm sorry about that. The time is 12:00 NY time, so the correct times for Europe are 18:00 Germany and 19:00 Finland. It's not too late to shift that if the Americans can do an hour earlier and the Europeans would greatly prefer the hour earlier. Barry On Wed, Jun 22, 2016 at 11:09 AM, Henry S. Thompson wrote: > IESG Secretary writes: > >> The Uniform Resource Names, Revised (urnbis) working group will have >> a virtual meeting scheduled for two hours on 29 June at 16:00 UTC. The >> purpose of the meeting is to discuss the two active documents >> (draft-ietf-urnbis-rfc2141bis-urn and draft-ietf-urnbis-semantics-clarif), >> to resolve issues with those documents, and to plan for completion of the work. >> >> For convenient reference, the meeting time in the time zones of the >> active participants are Wednesday, 29 June at... >> 09:00 - 11:00 California >> 12:00 - 14:00 NY >> 17:00 - 19:00 Germany >> 18:00 - 20:00 Finland > > Sorry for delayed response -- yes, I can attend (at 1700 BST. Please > note that the times listed for Germany and Finland are inconsistent with > those listed for California and New York - I'm assuming the latter are > correct). > > ht > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged spam] > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon Jun 27 20:24:42 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496CE12DAEF for ; Mon, 27 Jun 2016 20:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 0_HzKKcZAgbg for ; Mon, 27 Jun 2016 20:24:39 -0700 (PDT) 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 211C312DAF0 for ; Mon, 27 Jun 2016 20:24:39 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bHjde-000JBu-4I for urn@ietf.org; Mon, 27 Jun 2016 23:24:38 -0400 Date: Mon, 27 Jun 2016 23:24:33 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <9E2C883B9FEFDCA29CCABA6C@JcK-HP8200> 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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] Comments and drafts prior to the virtual meeting X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 03:24:41 -0000 Hi. Just a summary from this editor (and current pen-holder): (1) There have been zero comments on draft-ietf-urnbis-semantics-clarif-04.txt since it was posted on 8 June. That will be the version going into the call. The editor's working hypothesis is that "no comments" is equivalent to "done" but that is in no sense an attempt to claim consensus, only a statement that I have no work queued for that document. (2) I have been holding draft-ietf-urnbis-urn-17 in the hope of more discussion. It has not been forthcoming. I'm fully committed between this evening and the call/meeting (may not even be able to read URNBIS-related email and almost certainly will not be able to respond to comments on the documents between now and then) so am about to post what I have. There are not many changes from -16 -- there have not been many comments that, after limited discussion with the people who brought them up, I'm not confident about what to do with those comments and suggestions. The change log (Appendix F.9) summarizes the changes I thought were significant enough to mention. I've added a few [[CREF ...]] notes to point to areas of the text that comments seem to claim are significant but that I don't know how to proceed about, possibly because they touch on closed issues or appear to contradict earlier comments. Fodder for the call if Barry and Andy think that is a good way to spend time. They obviously come out before any final or LC version. Until Wednesday... best, john p.s. Peter has not seen this version so any new errors are entirely my fault. From nobody Mon Jun 27 20:25:01 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E45E12DAF1; Mon, 27 Jun 2016 20:24:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628032456.5245.22113.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2016 20:24:56 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-17.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 03:24:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-17.txt Pages : 39 Date : 2016-06-27 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 28 01:14:56 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4008812DB4B for ; Tue, 28 Jun 2016 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qvED5wcZFtLh for ; Tue, 28 Jun 2016 01:14:53 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAED12DB45 for ; Tue, 28 Jun 2016 01:14:53 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id s63so10158721ioi.3 for ; Tue, 28 Jun 2016 01:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=WlBTLPJyJEQSlXPy6xox5z4LQqYM6Uv93dF/Qs272js=; b=zvV342iY8M2y3Knfh4NPKAScSKQJNO9SOoGDfrP8wkPTu1wqmgXAX1sYnX9/k0A4wo krWq2jY9YaO4Vm10TNQL8TTY5Q/wt+6diMm0Y3welMyx5/RsYDmOziy+OzY0RxMUj4hs woXoRqLdJ2S49IXO1KMlfGDUC9uJiAQx6iLg3jmxaiLthqgY1A6JT1DVpm6xExTLvW5N 1cd2t7Wawsqj0JXf3syjk0rwmdQfA6QWGc4jy2xS/JnAy/zjziafbasR5x4QuGWBeWuj +NTAU81pHZJSonjcTNPKwTgoAdrTQuAaMQK0DKo6aZVRjScKfPwR9YIwphkzrw3PgLJd pTNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=WlBTLPJyJEQSlXPy6xox5z4LQqYM6Uv93dF/Qs272js=; b=VD91d8tBS9HNd6nh/AGnLywslJA2TSmfDu2g9KguLXnDPW/JH4LHdyyI9fW8SZ044H xdGfZJI/K3QB5Trm3V9cjzM6vkNlBPFwLLe9KJMjq4iAi59wUKO7nlV1RqDi64TsvGTV smRUZ3s3scAZHVxed6NWkLFlkPHG12GOYr0VZgPInzGUPkL+Q7ogB8dKM8BiOq0t4NXk GuGyBI/03g+xKnAos4BUQ4qXIQf05g2xVxxAD2LBogahNPkH9XHa2IlmoRMbSP6X1KlL Kn9KObTMuapGbTILlW5Kn3xNzMFEqPwYD3PmojE/v7ybjh2Rk9Fb9BO04g9AM2vSmg6Y bRdg== X-Gm-Message-State: ALyK8tLP00NEGmLBJdaQUFe0VkfFyBy19FWVMW6nHE3dac28hD5zoe/SRkAOTHzJBRtHD1Wbl0UdcBt/rfwt4Q== X-Received: by 10.107.175.83 with SMTP id y80mr2311950ioe.70.1467101692296; Tue, 28 Jun 2016 01:14:52 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.78 with HTTP; Tue, 28 Jun 2016 01:14:51 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Tue, 28 Jun 2016 04:14:51 -0400 X-Google-Sender-Auth: O8o_dKKTGEMeQ-KJGY102jyXTBQ Message-ID: To: "urn@ietf.org" Content-Type: multipart/alternative; boundary=001a11448a043801aa0536523ba4 Archived-At: Subject: Re: [urn] WebEx meeting invitation: URNbis virtual meeting X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 08:14:55 -0000 --001a11448a043801aa0536523ba4 Content-Type: text/plain; charset=UTF-8 Reminder to all: Wednesday, 29 June, is out virtual meeting. Corrected times (and, again, my apologies for mis-converting the European times before): 09:00 - 11:00 California 12:00 - 14:00 NY 18:00 - 20:00 Germany 19:00 - 21:00 Finland Barry On Wed, Jun 22, 2016 at 10:48 AM, Barry Leiba wrote: > For whatever reason, the WebEx invitations don't seem to be getting to the > working group mailing list. So, here's the information for the upcoming > virtual meeting next Wednesday, 29 June. > > The meeting is open to all, and I think the password may only be needed if > you're joining from the WebEx app on a mobile device. The IETF WebEx > account does not have International dial-in nor call-back access. You can > use the WebEx application (web or mobile device) to connect to audio via > the built-in VoIP. You can also use a service such as Skype to call the US > toll-free number -- Skype makes toll-free calls at no charge. > > Barry, urnbis chair > > ---------- Forwarded message ---------- > From: URNBIS Working Group > Date: Tue, Jun 21, 2016 at 8:01 PM > Subject: WebEx meeting invitation: URNbis virtual meeting > Hello, > URNBIS Working Group invites you to join this WebEx meeting. > > *URNbis virtual meeting* > Wednesday, June 29, 2016 > 12:00 pm | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs > Meeting number (access code): 643 058 876 > Meeting password: 1234 > > Add to Calendar > > When it's time, join the meeting > > . > > *Join by phone* > *1-877-668-4493 <1-877-668-4493>* Call-in toll free number (US/Canada) > *1-650-479-3208 <1-650-479-3208>* Call-in toll number (US/Canada) > Toll-free calling restrictions > > > Can't join the meeting? > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you automatically > consent to such recordings. If you do not consent to being recorded, > discuss your concerns with the host or do not join the session. > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > > --001a11448a043801aa0536523ba4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reminder to all: Wednesday, 29 June, is out virtual meetin= g.=C2=A0 Corrected times (and, again, my apologies for mis-converting the E= uropean times before):
09:00 - 11:00=C2=A0California
12:00 -= 14:00=C2=A0NY
18:00 - 20:00=C2=A0Germany
19:00 - 21:00= =C2=A0Finland

Barry

On Wed, Jun 22, 2016 at 10:48 AM, Barry Leiba <barr= yleiba@computer.org> wrote:
For whatever reason, the WebEx invitations don't seem to be ge= tting to the working group mailing list.=C2=A0 So, here's the informati= on for the upcoming virtual meeting next Wednesday, 29 June.

=
The meeting is open to all, and I think the password may only be= needed if you're joining from the WebEx app on a mobile device.=C2=A0 = The IETF WebEx account does not have International dial-in nor call-back ac= cess.=C2=A0 You can use the WebEx application (web or mobile device) to con= nect to audio via the built-in VoIP.=C2=A0 You can also use a service such = as Skype to call the US toll-free number -- Skype makes toll-free calls at = no charge.

Barry, urnbis chair

---------- Forwarded message ----------
From: URNBIS Working Group <messenger@webex.com&= gt;
Date: Tue, Jun 21, 2016 at 8:01 PM
Subject: WebEx meeting = invitation: URNbis virtual meeting
Hello,
URNBIS Working Group invites you to join this WebEx meeting= .
=C2= =A0
URNbis virtual meeting
Wednesday, June 29, 2016
12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0Eastern Daylight Time (New Yor= k, GMT-04:00)=C2=A0=C2=A0|=C2=A0=C2=A02 hrs
Meeting number (access code): 643 058 876
=09
Meeting password: 1234
=09
= =C2=A0
Add to Calendar
When it's time, <= a href=3D"https://ietf.webex.com/ietf/j.php?MTID=3Dm61147f677b162fd9070e821= 1e5012dd2" style=3D"color:rgb(0,175,249);text-decoration:none" target=3D"_b= lank">join the meeting.
= =C2=A0
=09
Join by phone
1-877-668-4493=C2=A0Call-in toll fr= ee number (US/Canada)
1-650-479-3208<= /a>=C2=A0Call-in toll number (US/Canada)
Toll-free calling restrictions
=C2= =A0
Can't join the meeting?
=C2= =A0
IMPORTANT NOTICE: Please note that this WebEx service allows audio= and other information sent during the session to be recorded, which may be= discoverable in a legal matter. By joining this session, you automatically= consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session.


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn


--001a11448a043801aa0536523ba4-- From nobody Tue Jun 28 16:54:37 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956D812D764 for ; Tue, 28 Jun 2016 16:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DCvAsxdGpFo8 for ; Tue, 28 Jun 2016 16:54:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D38B112D13E for ; Tue, 28 Jun 2016 16:54:33 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B735DE8291; Tue, 28 Jun 2016 18:07:58 -0600 (MDT) To: "Henry S. Thompson" , urn@ietf.org References: From: Peter Saint-Andre Message-ID: Date: Tue, 28 Jun 2016 17:54:31 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-16: 'name' and 'namespace' X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 23:54:35 -0000 On 5/5/16 5:48 AM, Henry S. Thompson wrote: > The words 'namespace' and 'name' are used throughout the spec in ways > that for this reader at least appear to have different meanings at > different points, sometimes to the point of apparent contradiction. Thanks for pointing out these discrepancies. > Consider for example the following from section 2.2: > > "Depending on the rules governing a namespace, strings that are > valid in an NSS associated with that namespace might contain > characters that are not allowed by the "pchar" production > referenced above (e.g., characters outside the ASCII range or, > consistent with the restrictions in RFC 3986, the characters '/', > '?', '#', '[', and ']'). While such a string might be a valid > name, it is not a valid URN until it has been translated into a > conformant NSS." > > Stripping out a lot of detail, this says "[there are] strings that are > valid in an NSS [which render it not] a conformant NSS". > > While some readers will be familiar with the sense of these words > which I think you are relying on, where e.g. 0-205-31342-6 is a name > in the ISBN namespace, others will not be. > > I would strongly recommend that you adhere much more closely to, and > document, something close to the pattern of usage in the following, > from section 1: > > Some URN namespaces create names that exist only as URNs, whereas > others create URNs out of names that already exist in other > identifier systems > > That is, always use > 'URN namespace' when you mean the thing assigned to an NID; > 'identifier systems' when you mean other (usually pre-existing) > kinds of managed collections of names; > 'URN' when you mean a member of a URN namespace; > 'NSS' when you mean the URN-namespace-specific part of a URN; > 'name' _only_ when you mean a member of a non-URN identifier system. All of those make sense to me except the last one. After all, a URN is a uniform resource *name* so it must be a kind of name. I would prefer to use the term 'identifier' to refer to a member of a non-URN identifier system. > And make these definitions explicit in 1.2, and make it explicit that > by 'URN namespace' you mean _only_ the set of URNs allowed by the > rules governing that URN namespace (extension) or those rules > themselves (intension), _not_ the corresponding names or management of > any related non-URN namespace. > > It will be tedious, and occasionally lead to less concise statements, > to make a pass over the document to do this, but the improvement in > clarity will IMO be worth it. Give me the write token for a week, and > I'll do it, if you like. I'll be happy to make these fixes in the next version. Peter From nobody Tue Jun 28 17:14:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B9B12D98F for ; Tue, 28 Jun 2016 17:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DkfhKqb769IB for ; Tue, 28 Jun 2016 17:14:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA7712D992 for ; Tue, 28 Jun 2016 17:14:48 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7094841694; Tue, 28 Jun 2016 18:28:13 -0600 (MDT) To: Sean Leonard , urn@ietf.org References: From: Peter Saint-Andre Message-ID: Date: Tue, 28 Jun 2016 18:14:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Barry Leiba Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 00:14:51 -0000 On 6/3/16 1:40 PM, Sean Leonard wrote: > On 6/3/2016 8:05 AM, Barry Leiba wrote: >> As I'm trying to catch up on the many long messages in the various >> discussions, I'm seeing issues that seem related to how we're talking >> about some of this stuff, and that appears to be getting in the way of >> understanding and coming to agreement. So let me babble for a moment: >> >> As we're talking about naming things -- URNs are names -- we mix in >> issues of locating them, finding them, and other such terminology that >> gets in the way. In reading a conversation between Juha and Julian, I >> was struck by things of this sort (from that thread): >> >>>> urn:isbn:#chapter1 >>>> urn:isbn:#chapter1para1 >>>> urn:isbn:#chapter1para1line1 >>>> urn:isbn:#chapter1para1line1word1 >>>> urn:isbn:#chapter1para1line1word1letter1 >>>> >>>> According to the rfc2141bis, all these URNs are equivalent (they >>>> identify >>>> the same book, and only that), but they indicate different locations >>>> within >>>> the first chapter of the identified book. Anyone could create these >>>> URNs >>>> once the national library has established the base URN. This is not a >>>> mandate problem since fragments have no role in identification. >>> Wow, they are *equivalent*, but indicate *different* locations? >>> That's IMHO >>> a very very surprising definition of equivalence. It probably would >>> be good >>> to use a more specific term. >> Setting aside, for the moment, whether fragments make sense within the >> ISBN namespace, I think it's important for us to understand what's >> being named (or identified, if you prefer) by >> >> urn:isbn: >> >> ...and by >> >> urn:isbn:#chapter1 >> >> ...and I suggest that (1) they're not identifying the same thing, but >> (2) what they're identifying is related, and (3) none of this has >> anything to do with locating the entity that's been named, nor how >> that might happen. >> >> The first is identifying, say, a book. Specifically, a given edition >> of a book, from a specific publisher. >> >> The second is identifying the first chapter of that editing of that >> book from that publisher. >> >> Yes? >> >> When Juha says they're "equivalent", he means that they refer to the >> same book, but he doesn't mean that the URNs are truly equivalent. >> When Julian says "wow, equivalent?", he questions where the >> equivalence stops. We're being imprecise, and it's getting in our >> way. >> >> And I think that's happening because we, naturally, keep thinking in >> terms of going and finding the thing that's named, rather than staying >> with the idea that these are abstract names. >> >> Will it help, maybe, if we're clear that when we talk about URNs, >> we're talking purely about names for things, and that anything related >> to how to use that name to actually *find* the things is a separate >> question? And then try hard to keep our language in terms of the >> names only? > > +1000 > > We (well, you and I) are in agreement. > > We can start with agreeing to call "URN equivalence" something more > precise. See my posts around 5/3/2016: > > http://mailarchive.ietf.org/arch/msg/urn/936s5wvwAsXB8ih3fP-EhBjBSKw > > "Name the Same Thing" Juha has previously mentioned examples of two URNs from different namespaces (ISBNs and ISSNs) that name the same thing, i.e., the same publication. Irrespective of how one would find that publication based on the different namespaces (e.g., separate lookup services for ISBN and ISSN), he believes that the two URNs name the same thing. However, as far as I can see such a concept of naming the same thing cannot be captured in a form that can be processed by a machine; relatedly, it is not at all what we mean by URN equivalence, which is closer to what I think Barry means when he talks about "abstract names". Because I don't see any possible engineering solution to this problem, I would prefer that we not try to solve it. Peter From nobody Tue Jun 28 17:47:19 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E575D12D762 for ; Tue, 28 Jun 2016 17:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 rIJruCk0t4ie for ; Tue, 28 Jun 2016 17:47:15 -0700 (PDT) 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 2A19912D14F for ; Tue, 28 Jun 2016 17:47:15 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bI3eq-000PzX-Cl; Tue, 28 Jun 2016 20:47:12 -0400 Date: Tue, 28 Jun 2016 20:47:07 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <4839DC906BA288B105BFE29F@JcK-HP8200> 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.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, Barry Leiba Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 00:47:17 -0000 --On Tuesday, June 28, 2016 18:14 -0600 Peter Saint-Andre wrote: >... >> "Name the Same Thing" > > Juha has previously mentioned examples of two URNs from > different namespaces (ISBNs and ISSNs) that name the same > thing, i.e., the same publication. Irrespective of how one > would find that publication based on the different namespaces > (e.g., separate lookup services for ISBN and ISSN), he > believes that the two URNs name the same thing. However, as > far as I can see such a concept of naming the same thing > cannot be captured in a form that can be processed by a > machine; relatedly, it is not at all what we mean by URN > equivalence, which is closer to what I think Barry means when > he talks about "abstract names". Because I don't see any > possible engineering solution to this problem, I would prefer > that we not try to solve it. This is a different type of "equivalence", associated with the principle that two identifiers (URI or otherwise) can be considered equivalent if they both result in retrieval (or equivalent) of an object (or "representation") and the objects ("representations") obtained are "the same". Note that the first definition of "equivalence" in RFC 3986 (see the first sentences of Section 6.1, whether it is "of practical use" or not). I hope that the new (and I hope consistent) use of "URN equivalence" in 2141bis gets us around any issues that "same object equivalence" or "3986 equivalence" might cause. best, john From nobody Tue Jun 28 22:40:11 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EB712D1D7 for ; Tue, 28 Jun 2016 22:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 sP_R3B0hXT_g for ; Tue, 28 Jun 2016 22:40:04 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F9A12DA06 for ; Tue, 28 Jun 2016 22:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ypl0aYGQqrz8rgqHwnW60Plo1JkB+QEFcsR2aR+aPc4=; b=KXURzZmUx84QcSbHoV30dxL8hYuTBT4+MbwgxAXbehNEbEs5P0YFNAPNGXy578CB9LNvnRn4yD1TPxo7t8TsqmThwUXgTym2XVcOb7qYguHfgBJQG11YTJi4C0Dai9GKJjYOTu5K1eMOVnuCh1ljrq8KdGzqw09YfC1ooA9xI9Q= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1726.eurprd07.prod.outlook.com (10.166.143.22) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 05:39:45 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 05:39:45 +0000 From: "Hakala, Juha E" To: John C Klensin , Peter Saint-Andre Thread-Topic: [urn] Talking about fragments in URNs Thread-Index: AQHRvalqNaNE0A+SzUWjMkV0DJvCfZ/YJFqAgCeWzwCAAAkJgIAAOgoQ Date: Wed, 29 Jun 2016 05:39:44 +0000 Message-ID: References: <4839DC906BA288B105BFE29F@JcK-HP8200> In-Reply-To: <4839DC906BA288B105BFE29F@JcK-HP8200> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: ba0b9073-8b26-4a3a-58e8-08d39fdfc6d6 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1726; 6:brVD8vCxbAk5UD5R50rUp9QuWmIyOC6eVd9zOd5PDGYB10ubG0rocUuaD0rL8mgUK7mySfgUMGuondrLXTQ2UeVAUAKHMBNUMtR/wU8/mJvHBNeabCl2roifSXjj4EsEwiKNNQC4zrl3CjBRLwf5T9AuPWFQibAZCbUb+FBFi3ey5MxxtvYtrF+dMT5kgFHGqbQqBYBto4tXX9XvicOSkJCfWcTJwR2foWcp+W9Vu2OWMcPBF7VP4fM3KG0VyLSTBv6W73DwYdiLvR0p+8SZNFFuxWN8cvp2EL0yw+xsIy8=; 5:xpBy2tD6aLPFc7lxzGiv+3oJkmRQ0P4a5X9xy6jd39C5Doy/3RsdtAPx3Nivf5et3w/VSOnpfw9XdsAL9Gwh6ejCHaTDOoq4VY400g+9rElj/99g9NCPw3lP6HJKUuql0CVyjIwXLGyZHRbllEo/2A==; 24:W0NjWNx6ic5891GaJ6XPaL9/Xa+TjGaMrkLAkhGclxkIE1RGsvO1Qatnx4cQmKqnMZFBuzx583O75OjhDfQOFJW7FBqSY/R2zgH+VOFIq4A=; 7:mMY7+ND5sQHcgsp6Cdh6uulHsDrKhJGmFCQXkFDDO1B3oeRjKgRiaFXYGD7yYKHtM2is0tLRJomWocduinszjr8NCQ95Dy4DPqE657tikqMoaiqIG41dg4c0nSlR9KcUW8S2Xw+EXr4X8/7Ks6sFR1gGmprAvEryy3wwFZkbooXspIl14EbhWADxKrDdZKFFB9LI2hOKv0xQCo1rqboNFq0BxH/qsarqb4mK5JDYsptXwLuK3zXD6eKLkO9+Zx1n x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1726; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR07MB1726; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1726; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(199003)(13464003)(54356999)(50986999)(76176999)(66066001)(93886004)(106356001)(106116001)(105586002)(86362001)(74316001)(5002640100001)(8936002)(305945005)(11100500001)(92566002)(81166006)(87936001)(33656002)(2950100001)(8676002)(189998001)(7736002)(586003)(7846002)(4326007)(5003600100003)(7696003)(19580405001)(19580395003)(122556002)(101416001)(3660700001)(10400500002)(3846002)(3280700002)(97736004)(6116002)(5001770100001)(2900100001)(9686002)(15975445007)(77096005)(74482002)(76576001)(102836003)(68736007)(2906002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1726; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 05:39:45.0050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1726 Archived-At: Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 05:40:09 -0000 Hello, there are at least four different aspects of equivalence or "naming the sam= e thing".=20 1. The simplest case is the one that can be determined just by parsing two = identifier strings and determine on the basis of equivalence rules if these= identifiers are equivalent. In the case of URN, such equivalence rules may= exist on both the namespace level and on the URN syntax level.=20 For instance, there are two versions of ISBN, ISBN-10 and ISBN-13. ISBN-10s= can be migrated into ISBN-13s. For someone who does not know how that is d= one, the relation between the source and target ISBN:s may not be obvious. = For instance, these ISBNs are equivalent (they identify the same book): ISBN 0-393-04002-X ISBN 978-0-393-04002-9 Note that neither the hyphens nor "ISBN" (which is only required when ISBNs= are expressed in human readable form) are not taken into account when equi= valence is determined. X in ISBN-10 is case insensitive (but should always = be shown as capital X).=20 When we apply URN syntax equivalence rules on this, we can say that for ins= tance these URNs are equivalent.=20 urn:isbn:0-393-04002-X URN:ISBN:978-0-393-04002-9=20 2. Second case is partial of complete semantic equivalence with respect to = what has been identified within a single URN namespace. This depends on the= identifier assignment rules applied in URN namespaces, and the URN system = / syntax cannot change these rules which in some cases have been in product= ion for decades. =20 For instance, ISBN standard says that=20 "Different product forms of a publication where these are made separately a= vailable shall be assigned separate ISBNs." This means that the same work, when published in different forms, shall hav= e different ISBNs. So if we consider intellectual content identified only, = we may say that the ISBNs given to for instance printed and audio versions = of Nick Bostrom's book Superintelligence are semantically equivalent. One m= ight even argue that the German and Chinese translations of the book to som= e extent equivalent to the original as well. However, this is not what the = ISBN community does. =20 ISBN standard also says that: "An ISBN should be assigned to the complete set of volumes where a publicat= ion comprises more than one volume. If individual volumes of the set are also available separately, the= n each volume shall be assigned its own unique ISBN. The title page verso of the individual volume shall state = the ISBN for the respective volume and should also state the ISBN for the set." So there can be partial equivalence between ISBNs in the sense that one ISB= N identifies all parts of a PDF version of The Lord of the Rings, whereas o= ther ISBN applies just to the second part.=20 This kind of equivalence can never be determined just by parsing either the= namespace specific string or the entire URN. But many applications such as= library systems contain resource related metadata with which this kind of = semantic equivalence can be determined. Smart algorithms have been develope= d by libraries to extract work descriptions from existing manifestation met= adata. These algorithms can be said to analyze semantic equivalence between= ISBNs since they bring together all versions (and translations) of works s= uch as the Bostrom's book mentioned above. So there is an engineering solut= ion, but it is not and it will never be based on the identifier only. If we= want to mention this issue in the URN syntax document, we can say that a U= RN namespace may apply namespace specific algorithms and external metadata = to determine whether two URNs from than namespace are semantically equivale= nt and the nature of such equivalence (partial or complete). =20 3. It is possible to have URNs from 2-n namespaces to identify the same res= ource. For instance, a book published in monograph series may have both ISB= N and ISSN. This kind of equivalence may also be determined with the help o= f metadata related to the resource, but the results may be less reliable th= an in the second case since rules applied in different namespaces may be in= compatible.=20 There will be a lot of partial equivalences: for instance, a digitized book= may have an URN:ISBN, but every image in the book may have its own URN:NBN= . =20 4. Fourth case of equivalence may exist between identifiers in different pe= rsistent identifier systems. For instance, we may have both a DOI and an UR= N identifying the same book, and therefore based on the same ISBN. Again, i= t is not obvious to a machine (or to most humans) that e.g. these identifie= rs are identifying the same resource:=20 ISBN 1-2345-9999-X DOI 10.978.12345/99990=20 URN:ISBN:978-1-2345-9999-0 The difference between these identifiers is functional: plain vanilla ISBN-= 10 is not actionable in the Internet; the DOI and URN may be, but at least = initially in a different way. DOI would probably be resolved by the publish= er or other party which has rights to disseminate the book; URN would be re= solved by the national library. After a while, when the copyright has expir= ed (that is, 70 years after the death of the author) there may no longer be= any commercial interests and both persistent identifiers may resolve to a = copy of the resource in the national library's deposit collection.=20 IMO there is no need to discuss the implications of this kind of equivalenc= e in the URN syntax document. We may mention it in passing, though, by sayi= ng for instance that persistent identifier systems are not mutually exclusi= ve; a resource may have 1-n PIDs which may support different resolution ser= vices.=20 Best regards,=20 Juha=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of John C Klensin > Sent: 29. kes=E4kuuta 2016 3:47 > To: Peter Saint-Andre > Cc: urn@ietf.org; Barry Leiba > Subject: Re: [urn] Talking about fragments in URNs >=20 >=20 >=20 > --On Tuesday, June 28, 2016 18:14 -0600 Peter Saint-Andre > wrote: >=20 > >... >=20 > >> "Name the Same Thing" > > > > Juha has previously mentioned examples of two URNs from different > > namespaces (ISBNs and ISSNs) that name the same thing, i.e., the same > > publication. Irrespective of how one would find that publication based > > on the different namespaces (e.g., separate lookup services for ISBN > > and ISSN), he believes that the two URNs name the same thing. However, > > as far as I can see such a concept of naming the same thing cannot be > > captured in a form that can be processed by a machine; relatedly, it > > is not at all what we mean by URN equivalence, which is closer to what > > I think Barry means when he talks about "abstract names". Because I > > don't see any possible engineering solution to this problem, I would > > prefer that we not try to solve it. >=20 > This is a different type of "equivalence", associated with the principle = that > two identifiers (URI or otherwise) can be considered equivalent if they b= oth > result in retrieval (or > equivalent) of an object (or "representation") and the objects > ("representations") obtained are "the same". Note that the first definit= ion > of "equivalence" in RFC 3986 (see the first sentences of Section 6.1, whe= ther > it is "of practical use" or not). >=20 > I hope that the new (and I hope consistent) use of "URN equivalence" in > 2141bis gets us around any issues that "same object equivalence" or "3986 > equivalence" might cause. >=20 >=20 > best, > john >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Tue Jun 28 23:23:18 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB9E12D81F for ; Tue, 28 Jun 2016 23:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 46-HY1txgWc4 for ; Tue, 28 Jun 2016 23:23:04 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B942212DA80 for ; Tue, 28 Jun 2016 23:23:03 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 84EED509B6 for ; Wed, 29 Jun 2016 02:23:02 -0400 (EDT) To: urn@ietf.org References: <20160608140303.19971.27568.idtracker@ietfa.amsl.com> From: Sean Leonard Message-ID: <57be1339-41ca-2a70-de15-6f8cbbfb8e1c@seantek.com> Date: Tue, 28 Jun 2016 23:22:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160608140303.19971.27568.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------B15E9B8B98753E91B8944867" Archived-At: Subject: Re: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-04.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 06:23:06 -0000 This is a multi-part message in MIME format. --------------B15E9B8B98753E91B8944867 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Comments were requested, so: Really only two things. Section 2. Pragmatic Goals uses the term "abstractly correct" instead of "correct in the abstract": 2. Provide a path to avoid getting bogged down in declarative statements about definitions and debates about what is and is not correct in the abstract. *abstractly correct.* I think I know enough US-English by now; I am not sure what "abstractly correct" really means. I think it means "abstractly correct". But nobody says that. Everybody says (and writes) "correct in the abstract". Google agrees: http://www.googlebattle.com/?domain=abstractly+correct&domain2=correct+in+the+abstract&submit=Go%21 A Google search for the exact terms yields "correct in the abstract" has 532,000 results; "abstractly correct" yields 7,580 results. (Don't even get me started on who is known to have used the latter, according to Google!) Stick with "correct in the abstract". The second comment addresses the whole draft. It looks like this draft "really went there" in terms of actually updating 3986. It really doesor, at least, it tries to within this URN scope. Please, don't do that. As much as I have invested into this URN thing, really, nobody cares (commercially) about URN URIs like people care (commercially) about HTTP(S), LDAP, DATA, MAILTO, WEBSOCKET, MAGNET, etc. I thought the chairs/ADs already said that updating 3986 is out-of-scope a long time ago. This strikes me as a poor way to get what we want. Rather than dialing it back, this draft-04 is getting more aggressive. Bend the URN draft(s) in whatever ways you want to make it work with what RFC 3986 says about URIs. Remember that RFC 3986 "resources" that URIs point to are abstract: they can be anything you want, or don't want, or whatever. The whole enterprise (of trying to change 3986 when we all know that ship has sailed and honestly it's just totally not worth it anyway) is making me feel very tired. That is my feedback. Thanks, Sean On 6/8/2016 7:03 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Uniform Resource Names, Revised of the IETF. > > Title : URN Semantics Clarification > Author : John C Klensin > Filename : draft-ietf-urnbis-semantics-clarif-04.txt > Pages : 14 > Date : 2016-06-08 > > Abstract: > Experience has shown that identifiers associated with persistent > names have properties and requirements that may be somewhat different > from identifiers associated with the locations of objects. This is > especially true when such names are expected to be stable for a very > long time or when they identify large and complex entities. In order > to allow Uniform Resource Names (URNs) to evolve to meet the needs of > the Library, Museum, Publisher, and Information Science communities > and other users, this specification separates URNs from the semantic > constraints that many people believe are part of the specification > for Uniform Resource Identifiers (URIs) in RFC 3986, updating that > document accordingly. The syntax of URNs is still constrained to > that of RFC 3986, so generic URI parsers are unaffected by this > change. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn --------------B15E9B8B98753E91B8944867 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Comments were requested, so:

Really only two things.

Section 2. Pragmatic Goals uses the term "abstractly correct" instead of "correct in the abstract":
   2.  Provide a path to avoid getting bogged down in declarative
       statements about definitions and debates about what is and is not
       correct in the abstract.
       abstractly correct.
I think I know enough US-English by now; I am not sure what "abstractly correct" really means. I think it means "abstractly correct". But nobody says that. Everybody says (and writes) "correct in the abstract". Google agrees:

http://www.googlebattle.com/?domain=abstractly+correct&domain2=correct+in+the+abstract&submit=Go%21

A Google search for the exact terms yields "correct in the abstract" has 532,000 results; "abstractly correct" yields 7,580 results. (Don't even get me started on who is known to have used the latter, according to Google!)

Stick with "correct in the abstract".


The second comment addresses the whole draft.

It looks like this draft "really went there" in terms of actually updating 3986. It really doesor, at least, it tries to within this URN scope.

Please, don't do that. As much as I have invested into this URN thing, really, nobody cares (commercially) about URN URIs like people care (commercially) about HTTP(S), LDAP, DATA, MAILTO, WEBSOCKET, MAGNET, etc.

I thought the chairs/ADs already said that updating 3986 is out-of-scope a long time ago. This strikes me as a poor way to get what we want. Rather than dialing it back, this draft-04 is getting more aggressive.

Bend the URN draft(s) in whatever ways you want to make it work with what RFC 3986 says about URIs. Remember that RFC 3986 "resources" that URIs point to are abstract: they can be anything you want, or don't want, or whatever. The whole enterprise (of trying to change 3986 when we all know that ship has sailed and honestly it's just totally not worth it anyway) is making me feel very tired.

That is my feedback. Thanks,

Sean

On 6/8/2016 7:03 AM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names, Revised of the IETF.

        Title           : URN Semantics Clarification
        Author          : John C Klensin
	Filename        : draft-ietf-urnbis-semantics-clarif-04.txt
	Pages           : 14
	Date            : 2016-06-08

Abstract:
   Experience has shown that identifiers associated with persistent
   names have properties and requirements that may be somewhat different
   from identifiers associated with the locations of objects.  This is
   especially true when such names are expected to be stable for a very
   long time or when they identify large and complex entities.  In order
   to allow Uniform Resource Names (URNs) to evolve to meet the needs of
   the Library, Museum, Publisher, and Information Science communities
   and other users, this specification separates URNs from the semantic
   constraints that many people believe are part of the specification
   for Uniform Resource Identifiers (URIs) in RFC 3986, updating that
   document accordingly.  The syntax of URNs is still constrained to
   that of RFC 3986, so generic URI parsers are unaffected by this
   change.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn


--------------B15E9B8B98753E91B8944867-- From nobody Tue Jun 28 23:54:47 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B90512D9E1 for ; Tue, 28 Jun 2016 23:54:46 -0700 (PDT) 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 autolearn_force=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 4GxLI8mFhnjf for ; Tue, 28 Jun 2016 23:54:44 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D150C12D7F0 for ; Tue, 28 Jun 2016 23:54:43 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EB7CB509B8 for ; Wed, 29 Jun 2016 02:54:42 -0400 (EDT) To: urn@ietf.org References: <4839DC906BA288B105BFE29F@JcK-HP8200> From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 23:54:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 06:54:46 -0000 On 6/28/2016 10:39 PM, Hakala, Juha E wrote: > Hello, > > there are at least four different aspects of equivalence or "naming the= same thing". > [...] Thank you, Juha, for that. Upon reading the responses, I revise my proposal of "Name the Same=20 Thing". It appears that "NtST" means or can be implied to mean "semantic = equivalence", which is not what we are going for. I read draft-ietf-urnbis-rfc2141bis-urn-17 and remain staunchly opposed=20 to the term "URN equivalence". The term is confusing and adds little=20 value. Even very intelligent people can't tell if the q-, r-, and=20 f-components are supposed to be included in the comparison or not. Honestly, I don't see why we got away from the term used by Section 5 of = RFC 2141, "lexical equivalence". Folks, that is what we have been=20 talking about all along. Lexical def.: http://www.dictionary.com/browse/lexical?s=3Dt 1. of or relating to the words or vocabulary of a language, especially=20 as distinguished from its grammatical and syntactical aspects. 2. of, relating to, or of the nature of a lexicon. =3D> Lexicon def.: 1. a wordbook or dictionary, especially of Greek, Latin, or Hebrew. [...] 3. inventory or record. *** That is what we are talking about. A namespace is an "inventory" (or=20 "dictionary") of names. Each name is different. But some names can be=20 written in a plurality of ways but still be the same name. Tomatoes and=20 tomatos are the same fruits (tomato is a fruit, in case you were wonderin= g). It appears that the term "lexical" got dropped between draft-05 and=20 draft-06: https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-urnb= is-rfc2141bis-urn-06.txt for reasons unbeknownst to me...but as Peter Saint-Andre and Ryan Moats=20 were the editor/author at the time, I would like to ask (respectfully=20 and politely), "why?" Let's bring back "lexical equivalence", and call it a kind of=20 scheme-specific comparison (Section 6.2 of RFC 3986). Another verbal formulation is "two URNs have the same name" (HtSM). This = formulation is interchangeable with "lexical equivalence", just in a=20 different part of speech. Regards, Sean From nobody Wed Jun 29 00:16:10 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DC012DA8D for ; Wed, 29 Jun 2016 00:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 VbvhXEx6Krzp for ; Wed, 29 Jun 2016 00:15:55 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0109.outbound.protection.outlook.com [104.47.0.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46A312DA96 for ; Wed, 29 Jun 2016 00:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ywLjiIRu3UPQz9yILEUaEfqPV57MNco34/Xqo1DzPU0=; b=BQpMknZyAf5bTMwZPzmtAZTHOScRTKvwPZOu/9CEeoMqlInU7/34zo0PEutM12nQn5tcLdxNdrkKSrc0sKS7IZQ5YqsXhE15qAmRnvySOGz+FgMubIYc0Dr4cjJIiXWQ7sTVHJZZiajuO+EDJy6Zdt+9dMxLbtp42rtyv56rtio= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 07:15:31 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 07:15:31 +0000 From: "Hakala, Juha E" To: Peter Saint-Andre , Sean Leonard , "urn@ietf.org" Thread-Topic: [urn] Talking about fragments in URNs Thread-Index: AQHRvalqNaNE0A+SzUWjMkV0DJvCfZ/YJFqAgCeWzwCAAF+yQA== Date: Wed, 29 Jun 2016 07:15:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 91c17cf2-1b7b-4df2-8aa6-08d39fed27a1 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1727; 6:bae0VpoB+j3cxeYvqF34gIAAU6ITChrLOSkRaXY7Ajsv0fs9JqnnSC2BP742xufqMBjQDEfaWCbY4v6KtDpkPkSBSdUs+X50ablkxShKzssEUKMwzWiV3XpXqO050deNialK9MJxhGzS16QM03TGL1PoEpn3lEc11l68qoBDDiA0xvTVCiZpm32H9IiM7pbiue0AieU8Nkodzc9/jVSnJZEdDdFAQDuOmU9Qzoqt7A3LcEcJexe9xT8FzrpL3sncMuY0DWbeUh9gqzvDid21OX/89003vla2Tc+Z5OfFXGs=; 5:kmt0F1dkKWK6UeHUOe/BVYUY1zSJKedHoyd40yy8E/1cEunkIyaParPsQagN3DkBSNTDlGuWA/dkfibJUcc8UJeincKliWkdA6xbUEdRDHQM1CzQP4jNfwjnBa+b/jl9pnvRMeji9znL34Y7cvqtIQ==; 24:GjuHLtplEDRHaWZ4XUv4nOhnRhQUOInUUQXHAmrsFZfqwDLgRmpQ2T6GptSIhRtJqHw113ai0xhGsAcPZ9HK7eYkjJDWnBcrlVxKAxF4xG0=; 7:+fnTTIteJtHAs9UudPMN1lZoXi5Oz3WtLdHv1VgqdOo/dtqAMdP1bavzguWdsf/Gt2t218xX8Ljgh3hqq0eigpIKyiQ6+5MkGC1ry7rjNeCbBISil5YLXBrNABJ1Dhm0uXpqrXPAz6sBg+/4IRBJ4ShJPrkJtQiYEh/IiNsDAYrjPmNVA4e3Ou2xjekbuSWtGjOmeubcUYc759i+W8TA7GKezdHIJliO1gFctRWJoXDXEkgpYLDWy6Ljf415DbcX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1727; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR07MB1727; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1727; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(51444003)(199003)(106356001)(10400500002)(3660700001)(66066001)(8936002)(189998001)(9686002)(2501003)(2900100001)(19580405001)(2950100001)(106116001)(76576001)(5001770100001)(97736004)(74482002)(105586002)(86362001)(11100500001)(77096005)(15975445007)(81166006)(8676002)(92566002)(5002640100001)(1720100001)(3280700002)(76176999)(54356999)(6116002)(305945005)(102836003)(3846002)(50986999)(31430400001)(5003600100003)(7696003)(7736002)(586003)(81156014)(33656002)(87936001)(7846002)(101416001)(19580395003)(122556002)(4326007)(68736007)(2906002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1727; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 07:15:30.7733 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1727 Archived-At: Cc: Barry Leiba Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 07:16:08 -0000 Hello,=20 some additional comments about equivalence.=20 > -----Original Message----- > >> When Juha says they're "equivalent", he means that they refer to the > >> same book, but he doesn't mean that the URNs are truly equivalent. > >> When Julian says "wow, equivalent?", he questions where the > >> equivalence stops. We're being imprecise, and it's getting in our > >> way. It is natural for the people with IETF background to see equivalence from t= echnical (RFC 3986) point of view. And it would be easy if we could just pa= rse two URN strings and always make a decision based on that. IMO chapter 3= .1 in RFC2142bis provides clear guidelines for doing that.=20 But it is important to keep in mind what the last paragraph in 3.1 says: UR= N namespaces MAY include additional rules for URN equivalence. And it is ac= tually much more complicated than that; it is possible to analyze resource = metadata to determine if two URNs from different namespaces or even two PID= s from different PID systems are equivalent in the sense that they identify= the same thing.=20 We can only be precise if we stick to the procedure in chapter 3.1, illustr= ated with examples in chapter 3.2. Trying to provide anything like an all-e= ncompassing description of equivalence in the URN context is impossible sin= ce each namespace has its own practices which may be difficult to understan= d to the non-initiated. Such practices have an impact on the URN syntax onl= y when dictating something on the URN side would have a negative impact on = existing identifiers. For instance, insisting that fragments do identify so= mething would not go down well in the ISBN community. =20 > >> And I think that's happening because we, naturally, keep thinking in > >> terms of going and finding the thing that's named, rather than > >> staying with the idea that these are abstract names. > >> Will it help, maybe, if we're clear that when we talk about URNs, > >> we're talking purely about names for things, and that anything > >> related to how to use that name to actually *find* the things is a > >> separate question? And then try hard to keep our language in terms > >> of the names only? The community I represent identifies resources like books using principles = which were carved in stone long time ago, and URN is interesting to us prim= arily because it can make the existing identifiers actionable in the Intern= et. We do not need to specify resolution services and their technical imple= mentation in RFC 2141bis, but syntax must allow us to do that later on. R- = and q-components should satisfy that need. =20 > > +1000 > > > > We (well, you and I) are in agreement. > > > > We can start with agreeing to call "URN equivalence" something more > > precise.=20 AFAIK the current version of RFC 2141bis gives good guidelines for checking= if two URN strings are equivalent in the strict sense of the word. This is= all URNbis needs to do (if we also say that namespaces may have their own = rules). Determining whether two URNs from the same/different namespaces are= equivalent in the broader sense that they identify the same thing is far m= ore difficult and requires deep understanding of the namespace used. This i= s and should be beyond the scope of RFC 2141bis, as is any guidelines for c= hecking of whether two different PIDs identify the same resource.=20 Juha =20 See my posts around 5/3/2016: > > > > http://mailarchive.ietf.org/arch/msg/urn/936s5wvwAsXB8ih3fP- > EhBjBSKw > > > > "Name the Same Thing" >=20 > Juha has previously mentioned examples of two URNs from different > namespaces (ISBNs and ISSNs) that name the same thing, i.e., the same > publication. Irrespective of how one would find that publication based on= the > different namespaces (e.g., separate lookup services for ISBN and ISSN), = he > believes that the two URNs name the same thing. However, as far as I can > see such a concept of naming the same thing cannot be captured in a form > that can be processed by a machine; relatedly, it is not at all what we m= ean > by URN equivalence, which is closer to what I think Barry means when he > talks about "abstract names". Because I don't see any possible engineerin= g > solution to this problem, I would prefer that we not try to solve it. >=20 > Peter >=20 >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Jun 29 00:57:03 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8536212D1D7 for ; Wed, 29 Jun 2016 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 QO2PGxIWvrwg for ; Wed, 29 Jun 2016 00:56:53 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0134.outbound.protection.outlook.com [104.47.1.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB4612B078 for ; Wed, 29 Jun 2016 00:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SU9sklLRaPB8GPY1jXzPLvJQmp1FYgvkEXUEu42+gCY=; b=eAwK98iyLfKq2xdKDTLTJ1Nk1KLcvjVaMURL3eIAk5L2Nmso+HOMx1/2j6VIINfnoGCFy0MxVjSqCIYblZ/vRWBYX6377mYGwCA+0M5VOXb9PbfcFUN7uRH1io9t1WrATnxe3GbUrkpOprY3GsBDfIgFLxuN9ABytrwk2lTmjZY= Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1726.eurprd07.prod.outlook.com (10.166.143.22) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 07:56:49 +0000 Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 07:56:49 +0000 From: "Hakala, Juha E" To: Sean Leonard , "urn@ietf.org" Thread-Topic: [urn] Talking about fragments in URNs Thread-Index: AQHRvalqNaNE0A+SzUWjMkV0DJvCfZ/YJFqAgCeWzwCAAAkJgIAAOgoQgAAsloCAAAcXoA== Date: Wed, 29 Jun 2016 07:56:49 +0000 Message-ID: References: <4839DC906BA288B105BFE29F@JcK-HP8200> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 50f19e55-87d2-489e-74e5-08d39ff2ece6 x-microsoft-exchange-diagnostics: 1; VI1PR07MB1726; 6:oAVKUEVhd64gw11CWpjD0Q5cBvv0ps/gL5y0pPzB8oSgacheOtEpQOwbafUxMTTLFbeZFdn3KeEqw/MlhmLtjxaDiR00EvhUmbjhkVRBzqpqhYxFmVX5G1KMJCDroJClaGvrT6SVzGxv020nKI1lhIYnTF8Xc0nZPWAo9AwbMTr5MCZ6ybnfAs4642uILMwT79GdYWE6eFavWc4FeG7pZGa1XY40OFFnRd2XBhA4PD/RCnJC1wYGl+1DTyNeDsSVnTaJdVPf1tPGe3M2sHLXFIvpbBH2tcNY+d+iAzfLtEs=; 5:3tSQf8DlnWA/kQCh3BgG1eYL3flRCTq9xipVKJjU6Zi8w99l7DjMknunAZk6gICc9jgXomwt12JFwtDe4Mz223SCYIistTljI/h12HPMbX0hLW9IUbPL3muSRsuIZQ2gw9snLY6bZ0A4ZhEhgID2zw==; 24:9UqLv6G7Pnf2XjayhWugI88Eyi1C5d8404o+tVFfs4mpm/Rxps0wt/aJUqGMUz9pwRqZdwC+euktybgxw+kln+SpuxRagdDQFJ/14z7ka2I=; 7:U5wj11NwleLRYRbmtPQu4FNANt4gvYg/Mi0G7ujGcJha2F5Zf8iSaQw7x69PorsOzs3TszijyNFP74XntEFq1vdzF0WVuMFYmDE2ht3HtXb9UCwXsw6W9essyP4+sydalQv0v6FFI6D3gwOqvSl0CncjmEufTRNhpVBXQjz3KYb77y6+Ob6glqOZv20trgquE5UmGbEyA17Q6YdmQKEHRiQY0xmrvkLdx713mlQOQJm7E8V3gDvu7oDJ06mBUrVt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1726; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR07MB1726; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1726; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(24454002)(189002)(7696003)(586003)(5003600100003)(19580405001)(19580395003)(7846002)(3660700001)(10400500002)(122556002)(2501003)(101416001)(33656002)(92566002)(81166006)(9686002)(7736002)(8676002)(189998001)(2950100001)(87936001)(102836003)(68736007)(74482002)(76576001)(2900100001)(81156014)(2906002)(31430400001)(6116002)(5001770100001)(3846002)(3280700002)(97736004)(77096005)(15975445007)(106356001)(106116001)(86362001)(105586002)(93886004)(50986999)(66066001)(76176999)(54356999)(107886002)(8936002)(5002640100001)(305945005)(11100500001)(74316001)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1726; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 07:56:49.2117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1726 Archived-At: Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 07:56:58 -0000 Hello Sean; all,=20 some comments below.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard > Sent: 29. kes=E4kuuta 2016 9:54 > To: urn@ietf.org > Subject: Re: [urn] Talking about fragments in URNs >=20 > On 6/28/2016 10:39 PM, Hakala, Juha E wrote: > > Hello, > > > > there are at least four different aspects of equivalence or "naming the > same thing". > > [...] >=20 > Thank you, Juha, for that. >=20 > Upon reading the responses, I revise my proposal of "Name the Same > Thing". It appears that "NtST" means or can be implied to mean "semantic > equivalence", which is not what we are going for. Yes. People who actually create URNs must pay attention to semantic equival= ence and use the namespace specific rules when they do that. But it is beyo= nd the URNBIS scope to try to tell namespaces what they should be doing.=20 >=20 > I read draft-ietf-urnbis-rfc2141bis-urn-17 and remain staunchly opposed t= o > the term "URN equivalence". The term is confusing and adds little value. > Even very intelligent people can't tell if the q-, r-, and f-components a= re > supposed to be included in the comparison or not. They are not, since then many namespaces would not be able to use them. Inc= luding f-component in the comparison would mean for instance an extension t= o the ISBN scope so that it could be used to identify component parts of bo= oks, which is not acceptable to the ISBN community. The problem can be bypa= ssed simply by saying that fragment does not identify anything, which is no= t compliant with what at least some people think RFC 3986 requires. This di= lemma has been solved by making URN palatable to the identifier systems. = =20 > Honestly, I don't see why we got away from the term used by Section 5 of > RFC 2141, "lexical equivalence". Folks, that is what we have been talking > about all along. Lexical equivalence might be a better term than URN equivalence, since URN = equivalence can be understood to be too broad a concept. For instance, some= people may think that URNs based on ISBN-10 and ISBN-13 of the same book a= re equivalent in the RFC2141bis sense of the word since they identify the s= ame resource. However, these URNs are lexically equivalent only if addition= al namespace specific rules are applied to detect the equivalence. RFC 2141= bis guidelines alone would not be sufficient to detect the equivalence. =20 =20 > Lexical def.: > http://www.dictionary.com/browse/lexical?s=3Dt > 1. of or relating to the words or vocabulary of a language, especially as > distinguished from its grammatical and syntactical aspects. > 2. of, relating to, or of the nature of a lexicon. > =3D> Lexicon def.: > 1. a wordbook or dictionary, especially of Greek, Latin, or Hebrew. > [...] > 3. inventory or record. >=20 > *** > That is what we are talking about. A namespace is an "inventory" (or > "dictionary") of names. Each name is different. But some names can be > written in a plurality of ways but still be the same name. Tomatoes and > tomatos are the same fruits (tomato is a fruit, in case you were wonderin= g). OK, but in lexical analysis we would only be interested in one language at = the time. We shall not try to determine anything across languages, for inst= ance to determine if tomato and tomaatti mean the same thing. =20 > It appears that the term "lexical" got dropped between draft-05 and > draft-06: > https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-urnb= is- > rfc2141bis-urn-06.txt >=20 > for reasons unbeknownst to me...but as Peter Saint-Andre and Ryan Moats > were the editor/author at the time, I would like to ask (respectfully and > politely), "why?" >=20 > Let's bring back "lexical equivalence", and call it a kind of scheme-spec= ific > comparison (Section 6.2 of RFC 3986). OK, but in order to avoid misunderstandings we should say that lexical anal= ysis is not namespace (identifier) specific but applies to all namespaces, = and from RFC 3986 point of view it is scheme specific from URN point of vie= w; not from the point of view of identifier schemes.=20 We must also keep the last paragraph of 3.1 which says that namespace defin= itions may include additional rules for URN equivalence. These rules can be= lexical or something else. For instance, ISBN standard says that hyphens m= ust are not part of the ISBN and are only used to improve readability (simp= le lexical rule) but there is also a complex lexical rule concerning genera= tion of ISBN-13 from ISBN-10, and semantic rules concerning identification = of resources.=20 Juha=20 > Another verbal formulation is "two URNs have the same name" (HtSM). > This formulation is interchangeable with "lexical equivalence", just in a > different part of speech. >=20 > Regards, >=20 > Sean >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Jun 29 02:29:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ACD12DAA4 for ; Wed, 29 Jun 2016 02:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 icaLf_xKNgvz for ; Wed, 29 Jun 2016 02:29:47 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0134.outbound.protection.outlook.com [104.47.93.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4F312DADD for ; Wed, 29 Jun 2016 02:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jRzkCxUIlUwiWCWCfs1XbTWfGWyV4U3Pe9NwVlRy+1A=; b=i3nmNauIGRzk747liYnOWWSA+0X8Wu44pA24F2oV1lydPSJ2bHPctp0KsyLg29B5R1rx/3uKdSzL5oCCQl5tUet5qDvGjZmDXVr+MyDkCK03Gcj3VUz1DUO7aqryIn6HSDKDZi6HdvpKIsx58IZzvRWGxuBDKy0zmJUXiLoRpXc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSXPR01MB0920.jpnprd01.prod.outlook.com (10.167.148.150) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 09:29:41 +0000 To: Sean Leonard , References: <20160608140303.19971.27568.idtracker@ietfa.amsl.com> <57be1339-41ca-2a70-de15-6f8cbbfb8e1c@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 29 Jun 2016 18:29:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <57be1339-41ca-2a70-de15-6f8cbbfb8e1c@seantek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0044.jpnprd01.prod.outlook.com (10.164.162.26) To OSXPR01MB0920.jpnprd01.prod.outlook.com (10.167.148.150) X-MS-Office365-Filtering-Correlation-Id: a8ef9a98-4a8d-4dd3-6434-08d39fffe627 X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 2:0h9/aluXPWlNnSo43TjPZU4DV2Or1tBmTJKQ2Qmg+RAO/sYFGvzSWm0BBzWWGczG9jagVE9FkIolAFU77+TXesAZ+0yXQk/8192uN0VaL5jc4Vl1qat/M8Z+WKCTWzRGUPDAhFiF4hVOc7yMKxFQ8iaqakQ9WE0Ve9EqE9IB95kw1NWgqO5TeOQA7AH93Iob; 3:BcgYGG9UQoITSA3jXqx7263eQ55nvVSu42IKOrLKB2kEjedlwyx/RgJVRRQGEowUpyllGs7si07gZPJl7RsiiWm1yG6F22mAQ074lNOA8pho7GTPu34GftN6+FF4hNWq X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0920; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 25:ybecRqPCfZwUfDK7lhFviNpv3mpcG7MXgUPy1yY9RtG+JsDnBRon1eTg6oLs2oo+LxHvVSPgRVcMUL/PtM360jeXrABQjob2gfzK9A2BZwz3/6OcuOq9rUv41Zw5CPlJ4mtmGDlBfMaNEX1dTSPctH65LxArqoDb8A1CmSgym1ewe54D+VrS5gKX2HroWtz+XqTDNvTMzt1Isxg4dWCeAI1mzB+caCrbkX2v9uBb88MWNKNnZ4G1ZLOqy68dp3XaV0PNLcqIaCddnhI71OZwycSu1p8PE0ZUljHu+AHYtdhkrPSXYoi+P4thI+CJWObpW3DEN1eqKd+SuF6Dljfl0DJHci5l1mJGL+zsad5c15Y+FrPlhLPs5N73fu0lXjNf7y8kdKAigsu45t501M/eCol1GkLbyWBOxRfmHdaP9ac1q/CEj4lCvOm4lx/PY78FVBcvB9K5UOlQWwBGmwhBwwnRzS/dZVJmKVzsxzGWgOvb1gH9ctxdMa+nHORy/b00Xe6ufFOlP/ato/DfkoMZ8nHJhhLnC94OPDw45fHIuBrgNyHv8owt98WOhvHcpp0PFBxyAU9RgKZNMnhlgTagj4/bUWHTkDhZE0+lHXxpW746hMgsVkipj82oLJ3NeS3v822ifue9aN2vUZc2c7cMEahO6wvkV7IxuvTYLzIZGtOTBmSR3z+RQC8FN2mhjNQMSoFmxBqWcSio+Z5KaIpMqYr9l1geAItuK5I3z/QISWkXdMHY2dF41de1RY9KeEQLqTYM6laNAgymlDwPmxqQERLOM99XSpnHdGyNGFkpcmebQFiRAGOR+6pNlj+CDkpR X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 31:OxJWv2apIPVsln8R1ZWN0z3ptIjdP8OxMzXDdzOXFOd/oQ410F6tvWjCu/1RSaEL+IzvTbar8/X2r6oCEy9eDvgKOJgthPBxrcEVikq/dOGeBBNdMEYn40nx209SX9sov7+jUbwvSef+ckprZ0NKh/OpVlIIA/J+g5djhCIUNnuM4MWNuBS2U5AjnZoKe/DqDw4Nt0yYbaWyI98yXVoSBA==; 4:2vEnPZoYXwwENAal7AGdhCTXBvtiOjhNq7UHKJc9+cWk/j1zT4PzEIDoEwvg8Ere3zwBTujKyMkgisdMRnpaXWtB1JF10cEFl6SqgMdoEOga9pnyuSuRR4Bqg9qI4XvFHgl/MvdON3L99hTvCa0QA/AejoH9NMqgNXFoYyzt6dY09ux4GFjhMtRzY0kgecJbrVpHRWloWrAcQA3GIzl4LDNIvao8v34sQjKj6nmctpHcso+RXxI7KvBAl0xYdKrE6hEehZ+wT97NAgg5EHYEy3QCsWA7wjKA4eJ1nKtP/gJssld+AJv0BtLEr5oYkD6LvX/sRbBcqUu/4KIpumnNEqyioE86rfnFyV4qVuMD/9ifRbNmAqK2zNs1+iwKEiEQlBs40HZgG81V8Lwj6DtC4Ub8MSXle1e+LG2Wa5nZrEdL9w0sA0Ny8QRc0kqmYB/3rMGNfVSxjvTfZ3h+rd7dbJOr1CsTodZKR7BHtKZb1pk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6042046)(6043046); SRVR:OSXPR01MB0920; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0920; X-Forefront-PRVS: 09888BC01D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(377454003)(24454002)(377424004)(53754006)(199003)(189998001)(50466002)(107886002)(68736007)(81156014)(81166006)(2870700001)(31686004)(64126003)(7846002)(74482002)(19580405001)(66066001)(86362001)(5001770100001)(23676002)(92566002)(8676002)(97736004)(47776003)(65806001)(65956001)(19580395003)(83506001)(7736002)(4001350100001)(305945005)(106356001)(76176999)(54356999)(105586002)(3846002)(586003)(101416001)(6116002)(15975445007)(31696002)(2950100001)(2906002)(50986999)(33646002)(77096005)(42186005)(230783001)(65826006)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR01MB0920; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxTUIwOTIwOzIzOjF6c2p6aHRTWHZMa0hISm5tK0k0akV3YnBy?= =?utf-8?B?ZVRwSVBHSjUxTTRGb2RvU001T3NSc3orUVFUVTRyd2VHQjZhY3NXNXdLMWlF?= =?utf-8?B?L08yeEhDWXY1ZVRUNlBtTFhXNHhYRE5DZytIZytOQmxTTUc1S0QvNHMxQUtY?= =?utf-8?B?Ui9IazNYU2NTbGwvL3E3azRyS21jVElkVFcrQUg5UTJGZ1R2OWxuZFY1YWpM?= =?utf-8?B?UTdqODVLQThDL2lrUG1IejluTUNKdUgxbzN1SzUzVVprKzkxQW03MjBDcHRQ?= =?utf-8?B?dk90MUNvb0pVYXUvYkFLbHZuQXYvOWY5ZVNWWitZNCtJbUJTUUVrSndSMW5x?= =?utf-8?B?MnYrbVRhTkl2Z3V2UHVFQ0FEdEhEMDJCSlFDTnp5RzB4NWQ0VkF4S0R0ZXAx?= =?utf-8?B?bkhEU1hoN3BHT0xwamwvMHhzYllaMHY3aDhaWmZUbW1rMWRFVGlLZFdZVEg3?= =?utf-8?B?ZWZIa2lBcTFuR0I1RzBreG5QVHVkTjZKc1p5dzZxT1U2cG5JTWsvSmh4RCtz?= =?utf-8?B?Z1V2QTNVTTN2bDVnb0daK0haSDJOR2Y3c3JMUkpqU1liNVJxalgyRkxxdlNC?= =?utf-8?B?bzRYaXc5anJNRXFSRU9BdTFwcFpXUHFRWEtDek01WFpUTTlNYUtDUWViY0lq?= =?utf-8?B?OXdiVm40THZER2tTNkg5enEzWDdwcjdxWno3eG16OEZFVmx4Ym9YNENqSnQ2?= =?utf-8?B?dmMvdWJsWGFuKzhnRGp3UE9NUFAxNllhZ1Q3bUo1ZFN1eHlWZ2YzWnlYUTEz?= =?utf-8?B?d0N4WlRPTmdGY2tRY09RT3J4UlRqVnZOYkZsdWd6Rnpia2kyS1g1ZTQvb3RT?= =?utf-8?B?WGp5ME04UjFxQ1IyRitQSzRqMlZxZXJqdUZOeFZzU1JiNklZeFU2MUY1WVBr?= =?utf-8?B?WXppSXRuQzBSVDJCUitEeTkrTVgrZW9ydG9oUnhyR2xYM1pIdlhJeFkzVFRR?= =?utf-8?B?MjlJdGtEZE9MMTNLU1RNQ3NWR2M5Sk5mSFVWNEE3aWkzbVN2QWFvTjJHM1lX?= =?utf-8?B?ZjR4M0VYYUtTcW12a3UrTk90YlVQSjFTZmtnQ1JidVJ2UWk2Tmd4VXdVSHRJ?= =?utf-8?B?YkEyNmF5SlI1MGxQR0VnQVowSUR3UGx3ZFN2VDREOHRtRnF0QVM5TFNIdVpv?= =?utf-8?B?UjdUVUxjVXZZK0xRd2VxbkVHYy95OHdmUi9WYk9rbHMzd3BaSGZnTjFGUjNE?= =?utf-8?B?WHFuVnZibDdKbm45Vk9xTStjTEwrOVg5bXJSOWhBazRzSFpNN2lsQUs2TUFs?= =?utf-8?B?b2FuYmd2VFllQmdhV3pOTzdETG53T2hRamMxUlUxYTZSUmhmN3FQbG96T0NK?= =?utf-8?B?VGtJYUM5cjRBZ293czI4NndGejFxMEFhaTZHRjZLYSs3ZzlGVXpjbGZsNHFS?= =?utf-8?B?Wm1SNnJBM0NxUm5nU2plREVudjIxN2VuaGRTQWZad3RtNjhHaEpJdmlVdXJX?= =?utf-8?B?TDVGbjdlV25yWG5sRHM5OFhvdmx6TXc4ZkV5UThYN2tEZmw2TEMwekptcTdk?= =?utf-8?B?VHNxbCtjSEdvZExsK2owMHRtNUdvbWlqendnSWZNRmFKa09IVmFlYXJVNkRK?= =?utf-8?B?QnFGNHRBNlI3RUpiTTB6Sy93OU4wZ3ZaMU5NMDJoZnpCWGpQMk5VNzVnN3BN?= =?utf-8?B?eEFYNXBwblQzSXVrWVl0RFpZdDA2ZndNNE51Z3d3OHhvalVZTXNUUThjeDY1?= =?utf-8?B?T3RPYmtIc2o1aFJ5WlphZHNrUE4xK2dveXV0NGhvaEFiVm0xSjNQYWk2bGFq?= =?utf-8?B?V0FTUFNtMHhPdkE0TitTZFd0MjY5VjNaT1JUUWJQVnVmTUZhV3Rra0k2US9t?= =?utf-8?B?RmtudlF4eUJycjdkaDRkcHR0bURFZVFjZ3k1SGZrVmhtMk1WakNkbXNzMWFD?= =?utf-8?Q?BUhgwGOBbSdqXzAdJCoXcULg7UFtJ5o5?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 6:C1/EpIGdqDuzE3yM/CVF4AiK7pkpKeg3Tr1HewgxYvyuQ5IB81tosEg/gTviMKg8hvVZ94jIaR351X7jR5dz//V5dZt09K3H3keRm7Z4NkTFo128AT2gjCICcszK4d6GuVM8CZyHbwsCdPx/ZtHXgUWp4WgACh7tIYTP2L4Qa0EQwJWBhTBpBy5ZEofICkIp4m4yRP1wqAy+qkK8EGhLpzD3n9uoRb1hzUQTbOcuiomlHQh4QXHx9wWFYb/1xmAklknKXeA0a20cEJ5ESF5CmrI8hf96I+4BLKEv997/MJJtp2aml43neZbhrWFWCOD+; 5:VBP06KWQ2E+6HQeOcRkCwRGOyaEcneR5CC4s+I8Emc1tDBhbxGFz8sfSXAqkjXR8l08OiF8/HP3Ujvlc75ZALklJpEx86Kb1F+WUZ7/e907U77DTDXj98GPxKs/FrncHUVdFBaG1ggMbfkW3DoAkBA==; 24:Bg6zura+cOMjGhjV5sHVyY4WxHTyeI3fBLGnZteE9OCXGbIj5VL4GyQL/Z7jBynEeLldTSaf1CyO2Y+PWH+ayEp0J3YBfdoet6hwHzk01yA=; 7:6FLz0eijRVoApwExTwhoWm9S3pg2ACTdI6ubVyD4v7S0WUgp8ytfmY4N2d6fGBG3GkvNF2nfMuFiNzn+7kCfC2w2Bhfe3iru8ML03ktWupRMa3SXpuKyaOfztWSCUp9qDV76xdzwUqURwTWRgmfCBNrp8POCfSw2/uQpiXPHl8Tst3kuHdDsr30ZwE3b7I6kq0rLBo6F4HvG10/LJeNbV+p54kF89d1E4iH4YD7lPBP1W6Z5YoZQ+gs6iSLyQO78 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2016 09:29:41.5139 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0920 Archived-At: Subject: Re: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-04.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 09:29:50 -0000 Hello everybody, On 2016/06/29 15:22, Sean Leonard wrote: > Comments were requested, so: > The second comment addresses the whole draft. > > It looks like this draft "really went there" in terms of actually > updating 3986. It really does—or, at least, it tries to within this URN > scope. > > Please, don't do that. As much as I have invested into this URN thing, > really, nobody cares (commercially) about URN URIs like people care > (commercially) about HTTP(S), LDAP, DATA, MAILTO, WEBSOCKET, MAGNET, etc. > > I thought the chairs/ADs already said that updating 3986 is out-of-scope > a long time ago. This strikes me as a poor way to get what we want. > Rather than dialing it back, this draft-04 is getting more aggressive. > > Bend the URN draft(s) in whatever ways you want to make it work with > what RFC 3986 says about URIs. Remember that RFC 3986 "resources" that > URIs point to are abstract: they can be anything you want, or don't > want, or whatever. The whole enterprise (of trying to change 3986 when > we all know that ship has sailed and honestly it's just totally not > worth it anyway) is making me feel very tired. > > That is my feedback. Thanks, > > Sean I agree. I started to read this draft, but I only got up to the following (partial) sentence in the abstract: >> this specification separates URNs from the semantic >> constraints that many people believe are part of the specification >> for Uniform Resource Identifiers (URIs) in RFC 3986 In particular, the word 'believe' stuck out. Since when is the IETF dealing with religion or similar stuff? Believes, one way or another, just don't belong in an IETF document. The 'problem' with RFC 3986 may be that it uses some specific terms. But then, any spec has to use some specific terms. The IP spec probably uses the term 'packet', but there's probably nothing in that spec that says that a packet doesn't have to be a physical 🎁 [packet/present emoji]. In a very similar way, about every IETF spec uses some terms that heretofore or still currently have other meanings in other contexts. RFC 3986 is absolutely no exception here. Maybe somebody has to write an RFC that would explaining something like the following: If you come from another field (that may not only be library science, but maybe biology, or mechanical engineering, or what not, or even just from apps for ops and vice versa), don't assume the terms used in the spec mean exactly what they mean in the field you are coming from. Instead understand (and if necessary, translate for yourself) these terms with the meanings that they are (explicitly or implicitly) given in the document. Understand that lots of meaning in any language or jargon is derived from use in that language or jargon. It's true that RFC 3986 is easier to read for somebody familiar with HTTP than for somebody familiar with URNs, but actually happens to make sense because there are (at least currently) many more HTTP URIs than URNs. But there's nothing in there that precludes identifiers "to be stable for a very long time" or to "identify large and complex entities", quite to the contrary. It's the URN spec that the necessary constraints for this on top of the (extremely low, even for syntax) constraints in RFC 3986. Well, maybe this is just me who has been doing a lot of spec reviews and gotten used to the fact that different specs use different vocabulary, and sometimes the same word with different meanings. But I don't think I'm alone here; this is pretty much common sense for any kind of subject field. Regards, Martin. > On 6/8/2016 7:03 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Uniform Resource Names, Revised of >> the IETF. >> >> Title : URN Semantics Clarification >> Author : John C Klensin >> Filename : draft-ietf-urnbis-semantics-clarif-04.txt >> Pages : 14 >> Date : 2016-06-08 >> >> Abstract: >> Experience has shown that identifiers associated with persistent >> names have properties and requirements that may be somewhat different >> from identifiers associated with the locations of objects. This is >> especially true when such names are expected to be stable for a very >> long time or when they identify large and complex entities. In order >> to allow Uniform Resource Names (URNs) to evolve to meet the needs of >> the Library, Museum, Publisher, and Information Science communities >> and other users, this specification separates URNs from the semantic >> constraints that many people believe are part of the specification >> for Uniform Resource Identifiers (URIs) in RFC 3986, updating that >> document accordingly. The syntax of URNs is still constrained to >> that of RFC 3986, so generic URI parsers are unaffected by this >> change. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Wed Jun 29 08:38:01 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6912D09D for ; Wed, 29 Jun 2016 08:38:00 -0700 (PDT) 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 autolearn_force=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 gFG2botCyRSB for ; Wed, 29 Jun 2016 08:37:58 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231A112D0B7 for ; Wed, 29 Jun 2016 08:37:58 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3F83050A73; Wed, 29 Jun 2016 11:37:56 -0400 (EDT) To: "Hakala, Juha E" , "urn@ietf.org" References: <4839DC906BA288B105BFE29F@JcK-HP8200> From: Sean Leonard Message-ID: <4fc21c1e-f127-8b2f-18a5-f10fffd8f761@seantek.com> Date: Wed, 29 Jun 2016 08:37:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] Talking about fragments in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 15:38:00 -0000 On 6/29/2016 12:56 AM, Hakala, Juha E wrote: > Hello Sean; all, > > some comments below. > >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard >> Sent: 29. kes=E4kuuta 2016 9:54 >> To: urn@ietf.org >> Subject: Re: [urn] Talking about fragments in URNs >> >> On 6/28/2016 10:39 PM, Hakala, Juha E wrote: >>> Hello, >>> >>> there are at least four different aspects of equivalence or "naming t= he >> same thing". >>> [...] >> Thank you, Juha, for that. >> >> Upon reading the responses, I revise my proposal of "Name the Same >> Thing". It appears that "NtST" means or can be implied to mean "semant= ic >> equivalence", which is not what we are going for. > Yes. People who actually create URNs must pay attention to semantic equ= ivalence and use the namespace specific rules when they do that. But it i= s beyond the URNBIS scope to try to tell namespaces what they should be d= oing. >> I read draft-ietf-urnbis-rfc2141bis-urn-17 and remain staunchly oppose= d to >> the term "URN equivalence". The term is confusing and adds little valu= e. >> Even very intelligent people can't tell if the q-, r-, and f-component= s are >> supposed to be included in the comparison or not. > They are not, since then many namespaces would not be able to use them.= Including f-component in the comparison would mean for instance an exten= sion to the ISBN scope so that it could be used to identify component par= ts of books, which is not acceptable to the ISBN community. The problem c= an be bypassed simply by saying that fragment does not identify anything,= which is not compliant with what at least some people think RFC 3986 req= uires. This dilemma has been solved by making URN palatable to the identi= fier systems. > >> Honestly, I don't see why we got away from the term used by Section 5 = of >> RFC 2141, "lexical equivalence". Folks, that is what we have been talk= ing >> about all along. > Lexical equivalence might be a better term than URN equivalence, since = URN equivalence can be understood to be too broad a concept. For instance= , some people may think that URNs based on ISBN-10 and ISBN-13 of the sam= e book are equivalent in the RFC2141bis sense of the word since they iden= tify the same resource. However, these URNs are lexically equivalent only= if additional namespace specific rules are applied to detect the equival= ence. RFC 2141bis guidelines alone would not be sufficient to detect the = equivalence. > =20 >> Lexical def.: >> http://www.dictionary.com/browse/lexical?s=3Dt >> 1. of or relating to the words or vocabulary of a language, especially= as >> distinguished from its grammatical and syntactical aspects. >> 2. of, relating to, or of the nature of a lexicon. >> =3D> Lexicon def.: >> 1. a wordbook or dictionary, especially of Greek, Latin, or Hebrew. >> [...] >> 3. inventory or record. >> >> *** >> That is what we are talking about. A namespace is an "inventory" (or >> "dictionary") of names. Each name is different. But some names can be >> written in a plurality of ways but still be the same name. Tomatoes an= d >> tomatos are the same fruits (tomato is a fruit, in case you were wonde= ring). > OK, but in lexical analysis we would only be interested in one language= at the time. We shall not try to determine anything across languages, fo= r instance to determine if tomato and tomaatti mean the same thing. Yes. Basically the comparison has to be computable offline, via the=20 application of an algorithm specified in the namespace registration. And = you can't try to get around this by registering the entire English and=20 Italian dictionaries as part of your algorithm and expect people to=20 implement it. > >> It appears that the term "lexical" got dropped between draft-05 and >> draft-06: >> https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-u= rnbis- >> rfc2141bis-urn-06.txt >> >> for reasons unbeknownst to me...but as Peter Saint-Andre and Ryan Moat= s >> were the editor/author at the time, I would like to ask (respectfully = and >> politely), "why?" >> >> Let's bring back "lexical equivalence", and call it a kind of scheme-s= pecific >> comparison (Section 6.2 of RFC 3986). > OK, but in order to avoid misunderstandings we should say that lexical = analysis is not namespace (identifier) specific but applies to all namesp= aces, and from RFC 3986 point of view it is scheme specific from URN poin= t of view; not from the point of view of identifier schemes. > > We must also keep the last paragraph of 3.1 which says that namespace d= efinitions may include additional rules for URN equivalence. These rules = can be lexical or something else. For instance, ISBN standard says that h= yphens must are not part of the ISBN and are only used to improve readabi= lity (simple lexical rule) but there is also a complex lexical rule conce= rning generation of ISBN-13 from ISBN-10, and semantic rules concerning i= dentification of resources. Ok. It sounds like we now have two votes/opinions in favor of "lexical=20 equivalence". In view of the computability property, it would be desirable for=20 namespace registrants to provide a string comparison specification that=20 can be compiled directly into a variety of implementations. What are=20 standard notations for string comparison specifications? For example,=20 rather than just saying in prose: "To compare ISBNs for lexical=20 equivalence, you eliminate hyphens and then compare in a case-sensitive=20 manner", you should say {elim: "-", compare: "C"}, and then=20 copy-and-paste this (or compile this) into your implementation. Regular expressions sort of fall in this category, but not really. A=20 regex can test an arbitrary string against itself, but we want to take=20 two strings and compare them in a particular way. This is either called=20 normalization, or something like "comparison operation". You can write=20 regular expression-based patterns to eliminate characters, e.g.,=20 s/-//gi, but that is not a true comparison spec, that is a pattern=20 substitution spec. I am looking for something like LDAP/X.500 Attribute=20 syntax matching rules. A quick Google search did not come up with what I = was looking for. Juha brought up this ISBN-10 -> ISBN-13 thing. If the registrant of the=20 ISBN namespace wants to provide a complex but still purely "lexical"=20 algorithm to generate and compare the two, that is computable, I say it=20 is fair game. That is up to the namespace registrant. Sean From nobody Wed Jun 29 09:00:26 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A476112D534 for ; Wed, 29 Jun 2016 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 op9-r9OFBtDn for ; Wed, 29 Jun 2016 09:00:23 -0700 (PDT) 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 556D612D18D for ; Wed, 29 Jun 2016 09:00:23 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bIHuW-00052F-5a; Wed, 29 Jun 2016 12:00:20 -0400 Date: Wed, 29 Jun 2016 12:00:15 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Message-ID: <9188AAE52738A69C87B84820@JcK-HP8200> In-Reply-To: References: <20160608140303.19971.27568.idtracker@ietfa.amsl.com> <57be1339-41ca-2a70-de15-6f8cbbfb8e1c@seantek.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.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-04.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 16:00:24 -0000 Sean, Martin, One pre-call observation (at this point, I'm not sure I'll manage to make the call)... While we can debate how to fix semantics-clarif at length (including nit-picking about "abstractly correct", which I will happily change just to avoid spending time debating it), semantics-clarif _does not_ change, or try to change, 3986. What it attempts to do is to establish some local context, relationships, and terminology for URNs that conflict with some people's reading of 3986. If that is still not clear to a significant fraction of the WG, it is clear that a new editor is needed because I can't stand looking at it any more. But the bottom line seems to me to be the comment in another note that we should just make 2141bis conform to whatever 3986 says about URIs. I believe that the WG has already concluded that is impossible (at least as many participants in the WG under 3986) and that we need to move past it. If that discussion is going to be reopened, let's do it explicitly, rather than trying to do it by debating the fine points of either of these URNBIS documents. john From nobody Wed Jun 29 09:01:22 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DC412D0B7 for ; Wed, 29 Jun 2016 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 ihOSO2x6OJ7D for ; Wed, 29 Jun 2016 09:01:19 -0700 (PDT) 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 CED0E12D52D for ; Wed, 29 Jun 2016 09:01:03 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bIHvB-00052x-Ip; Wed, 29 Jun 2016 12:01:01 -0400 Date: Wed, 29 Jun 2016 12:00:56 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= 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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-04.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 16:01:21 -0000 (sorry... wrong address) Sean, Martin, One pre-call observation (at this point, I'm not sure I'll manage to make the call)... While we can debate how to fix semantics-clarif at length (including nit-picking about "abstractly correct", which I will happily change just to avoid spending time debating it), semantics-clarif _does not_ change, or try to change, 3986. What it attempts to do is to establish some local context, relationships, and terminology for URNs that conflict with some people's reading of 3986. If that is still not clear to a significant fraction of the WG, it is clear that a new editor is needed because I can't stand looking at it any more. But the bottom line seems to me to be the comment in another note that we should just make 2141bis conform to whatever 3986 says about URIs. I believe that the WG has already concluded that is impossible (at least as many participants in the WG under 3986) and that we need to move past it. If that discussion is going to be reopened, let's do it explicitly, rather than trying to do it by debating the fine points of either of these URNBIS documents. john From nobody Wed Jun 29 14:09:18 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8005812D831 for ; Wed, 29 Jun 2016 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kQveFOVpSIGz for ; Wed, 29 Jun 2016 14:09:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8312D828 for ; Wed, 29 Jun 2016 14:08:56 -0700 (PDT) Received: from aither.local (unknown [65.158.198.6]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AB235E8291; Wed, 29 Jun 2016 15:22:24 -0600 (MDT) To: "urn@ietf.org" From: Peter Saint-Andre Message-ID: <6e338769-e16c-48c0-ff36-a11bc35047b5@stpeter.im> Date: Wed, 29 Jun 2016 15:08:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] interim meeting results X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 21:09:16 -0000 Many thanks to the chairs and to the WG participants who joined the interim meeting earlier today. It was very productive to work through issues in real time! John and I (as editors) will update 2141bis soon to incorporate the feedback we received. Peter