From julian.reschke@gmx.de Wed May 22 08:52:48 2013 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 3485A21F9655 for ; Wed, 22 May 2013 08:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFUeoYyhoJ-G for ; Wed, 22 May 2013 08:52:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id E991D21F964C for ; Wed, 22 May 2013 08:52:24 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MTMkb-1V5Cvg49l1-00SNSb for ; Wed, 22 May 2013 17:52:24 +0200 Received: (qmail invoked by alias); 22 May 2013 15:52:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 22 May 2013 17:52:23 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/yePYYQsryNPXwBClfrRgYyb5yJMW8xJlPIMBfgJ RU2f2gd6feiAE2 Message-ID: <519CE9B5.8000503@gmx.de> Date: Wed, 22 May 2013 17:52:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [urn] registry format X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:52:49 -0000 Hi there, looking at : 1) It has a "value" column (and it is sorted by "value"). What is this good for? 2) It mixes lowercase and uppercase NIS notations, where the NIS is supposed to be case-insensitive, right? Should I notify IANA? Best regards, Julian From marc.blanchet@viagenie.ca Wed May 22 08:59:12 2013 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 8E5F121F9683 for ; Wed, 22 May 2013 08:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTZOi4C4Iik0 for ; Wed, 22 May 2013 08:59:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A9A9F21F93E6 for ; Wed, 22 May 2013 08:59:11 -0700 (PDT) Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0618C425F2; Wed, 22 May 2013 11:59:10 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C901B55-8295-4622-B700-8E123F377A1D" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: <519CE9B5.8000503@gmx.de> Date: Wed, 22 May 2013 11:59:10 -0400 Message-Id: References: <519CE9B5.8000503@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1503) Cc: "urn@ietf.org" Subject: Re: [urn] registry format X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:59:12 -0000 --Apple-Mail=_1C901B55-8295-4622-B700-8E123F377A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2013-05-22 =E0 11:52, Julian Reschke a =E9crit = : > Hi there, >=20 > looking at = : >=20 > 1) It has a "value" column (and it is sorted by "value"). What is this = good for? >=20 > 2) It mixes lowercase and uppercase NIS notations, where the NIS is = supposed to be case-insensitive, right? RFC2141: ::=3D "urn:" ":" Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::=3D [ 1,31 ] ::=3D | | | "-" ::=3D | | ::=3D "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::=3D "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" Marc. >=20 > Should I notify IANA? >=20 > Best regards, Julian > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn --Apple-Mail=_1C901B55-8295-4622-B700-8E123F377A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 julian.reschke@gmx.de> a = =E9crit :
Hi there,

looking at <http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml>= :

1) It has a "value" column (and it is sorted by "value"). What = is this good for?

2) It mixes lowercase and uppercase NIS = notations, where the NIS is supposed to be case-insensitive, = right?

RFC2141:

 =
                   <URN> ::=3D "urn:" <NID> ":" <NSS>


Namespace Identifier Syntax


   The following is the syntax for the Namespace Identifier. To (a) be
   consistent with all potential resolution schemes and (b) not put any
   undue constraints on any potential resolution scheme, the syntax for
   the Namespace Identifier is:

   <NID>         ::=3D <let-num> [ 1,31<let-num-hyp> ]

   <let-num-hyp> ::=3D <upper> | <lower> | =
<number> | "-"

   <let-num>     ::=3D <upper> | <lower> | =
<number>

   <upper>       ::=3D "A" | "B" | "C" | "D" | "E" | "F" | "G" | =
"H" |
                     "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                     "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                     "Y" | "Z"

   <lower>       ::=3D "a" | "b" | "c" | "d" | "e" | "f" | "g" | =
"h" |
                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                     "y" | =
"z"

Marc.


Should I notify IANA?

Best regards, = Julian
_______________________________________________
urn mailing = list
urn@ietf.org
https://www.ietf.org/mail= man/listinfo/urn

= --Apple-Mail=_1C901B55-8295-4622-B700-8E123F377A1D-- From barryleiba.mailing.lists@gmail.com Wed May 22 10:20:11 2013 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 F12A921F9622 for ; Wed, 22 May 2013 10:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ16X1-KFShY for ; Wed, 22 May 2013 10:20:11 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7424521F961B for ; Wed, 22 May 2013 10:20:11 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id q12so1438406vbe.8 for ; Wed, 22 May 2013 10:20:10 -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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Fv0Of4oI9Ya2R50YBmJpvDM9oeTlaB8t/Vq6f6kxRAU=; b=U2a03mJa0VDjk9lFukgsZso2UHoAx1tWr09DveoyZN2X571VRxH49JUZ+QRyVl5EGa si+DHyWM48LXOHXFfsvNcGy5nfvQAwicPlrioZTMn7G68nhxUcd5JFSgph936YYs+KNV ApW1CTGKK4bFExcoXulTrHb9Wv6BJMYqYrOeI9G0ViYU1+YyrrcDq+0eqZ7AsrupVLKy sOCgChMY2WHDuAFaX3g8AJ3RfEEO28jbdGJV5SocBUJtklRrkMvpQG1WNuqlxYygKoB+ CYLhl4H71MwVn+EFSfAd4Qy/Yda3hmk5HvyCf+HF3GBA1m9/121kQowjIyv0T/S7IhnM ULUA== MIME-Version: 1.0 X-Received: by 10.59.3.9 with SMTP id bs9mr3139399ved.38.1369243210868; Wed, 22 May 2013 10:20:10 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Wed, 22 May 2013 10:20:10 -0700 (PDT) In-Reply-To: References: <519CE9B5.8000503@gmx.de> Date: Wed, 22 May 2013 13:20:10 -0400 X-Google-Sender-Auth: jkbuaRk_acj4Omz3lhMzKdxr59w Message-ID: From: Barry Leiba To: Marc Blanchet Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] registry format X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:20:12 -0000 Julian: > 1) It has a "value" column (and it is sorted by "value"). What is this good > for? I suspect that this might have been a misunderstanding of the "version" in the template as specified in RFC 2611: - registration version number: starting with 1, incrementing by 1 with each new version ...though I could be wrong about that. In any case, you're certainly right that there's no use for the value field, and sorting by it is actually bad. Julian: > 2) It mixes lowercase and uppercase NIS notations, where the NIS is supposed > to be case-insensitive, right? Marc notes the ABNF, but misses this from RFC 2141, right below the grammar: Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. Yes, we should have the "value" field removed, the "URN namespace" field rendered in lower case, and the table sorted by URN namespace. As the responsible AD, I will contact IANA about this, and see what they say. Barry From marc.blanchet@viagenie.ca Wed May 22 10:24:07 2013 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 599AD21F9640 for ; Wed, 22 May 2013 10:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRMmHUp1KjI9 for ; Wed, 22 May 2013 10:24:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D9D9421F9622 for ; Wed, 22 May 2013 10:24:06 -0700 (PDT) Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1F1BF47536; Wed, 22 May 2013 13:24:06 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: Date: Wed, 22 May 2013 13:24:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0D513D94-022E-4D39-A508-976978AC6355@viagenie.ca> References: <519CE9B5.8000503@gmx.de> To: Barry Leiba X-Mailer: Apple Mail (2.1503) Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] registry format X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:24:07 -0000 Le 2013-05-22 =E0 13:20, Barry Leiba a =E9crit = : > Julian: >> 1) It has a "value" column (and it is sorted by "value"). What is = this good >> for? >=20 > I suspect that this might have been a misunderstanding of the > "version" in the template as specified in RFC 2611: >=20 > - registration version number: starting with 1, incrementing by 1 > with each new version >=20 > ...though I could be wrong about that. In any case, you're certainly > right that there's no use for the value field, and sorting by it is > actually bad. >=20 > Julian: >> 2) It mixes lowercase and uppercase NIS notations, where the NIS is = supposed >> to be case-insensitive, right? >=20 > Marc notes the ABNF, but misses this from RFC 2141, right below the = grammar: >=20 > Further, the Namespace > Identifier is case insensitive, so that "ISBN" and "isbn" refer to > the same namespace. >=20 > Yes, we should have the "value" field removed, the "URN namespace" > field rendered in lower case, and the table sorted by URN namespace. >=20 well, I'm not sure I want us to spend too much time on this, but my = point is that lowercase and uppercase are allowed in the syntax. = Therefore, I guess IANA has just copied whatever the requestor sent as = the string to be registered.=20 Obviously, on the protocol point of view, there are case-insensitive. Marc. > As the responsible AD, I will contact IANA about this, and see what = they say. >=20 > Barry From stpeter@stpeter.im Wed May 22 10:26:14 2013 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 9B1CB21F96FE for ; Wed, 22 May 2013 10:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMfIer0n7gjl for ; Wed, 22 May 2013 10:26:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9517F21F9410 for ; Wed, 22 May 2013 10:26:09 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B7BE34115B; Wed, 22 May 2013 11:38:34 -0600 (MDT) Message-ID: <519CFFAF.8080100@stpeter.im> Date: Wed, 22 May 2013 11:26:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Barry Leiba References: <519CE9B5.8000503@gmx.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] registry format X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:26:14 -0000 On 5/22/13 11:20 AM, Barry Leiba wrote: > Yes, we should have the "value" field removed, the "URN namespace" > field rendered in lower case, and the table sorted by URN namespace. > > As the responsible AD, I will contact IANA about this, and see what they say. It sounds like something to fix in 2141bis... Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba@gmail.com Wed May 22 10:29:47 2013 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 F1C5521F9050 for ; Wed, 22 May 2013 10:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsA6gh5WMM8m for ; Wed, 22 May 2013 10:29:47 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFCF21F901F for ; Wed, 22 May 2013 10:29:46 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id lx15so2283329lab.38 for ; Wed, 22 May 2013 10:29:46 -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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=c51u5T16XLwDekqiU/sZXtDM6sPEVJOKjItehMCnz/8=; b=BipwozD2N/8PRvbDSfR8jRLrhdvr+KadSs4W6khjrBQTrd+pWJlkWfA2pEivdJTpHk bSZZlRiuD6fUxc5rYSAGosRCvSHYT4AxMokVS1cYkY+dxiesXa0qogShtStK4hUBbvoK muy+UwVIfxA2ArpVQaS87JwhIKa5CMkcPS+e5bJHhDf/mu6q9g96WAyHVmxj2Cq7/sj+ wWjMbepxNy8WAxq5qLh29hZN1e/6vVl6756cy70quAki0Xg0jW9X5m0iIpk59S7HuAVT QUmu7RfJfWKOuXQoxef6Li7Luk3A4C15G63gLbL2V+p/mmfPaDAWtcSgbNBu74cO1tAe RXhA== MIME-Version: 1.0 X-Received: by 10.112.131.232 with SMTP id op8mr4490116lbb.2.1369243786099; Wed, 22 May 2013 10:29:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.20.70 with HTTP; Wed, 22 May 2013 10:29:46 -0700 (PDT) In-Reply-To: <519CFFAF.8080100@stpeter.im> References: <519CE9B5.8000503@gmx.de> <519CFFAF.8080100@stpeter.im> Date: Wed, 22 May 2013 13:29:46 -0400 X-Google-Sender-Auth: MOQO_I2RTBVt__RMgmAQNnC4tfk Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] registry format X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:29:48 -0000 >> Yes, we should have the "value" field removed, the "URN namespace" >> field rendered in lower case, and the table sorted by URN namespace. >> >> As the responsible AD, I will contact IANA about this, and see what they say. > > It sounds like something to fix in 2141bis... Perhaps, but I don't see that it's necessary to do it that way. I can't find anything in any RFC that specifies the table as it is, so it shouldn't need an RFC to fix it. I think I can just work this out with IANA. Barry From stpeter@stpeter.im Wed May 22 10:35:45 2013 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 3A2A721F9676 for ; Wed, 22 May 2013 10:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4IIGi1xD4EM for ; Wed, 22 May 2013 10:35:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2DA821F9662 for ; Wed, 22 May 2013 10:35:39 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 208414115B; Wed, 22 May 2013 11:48:04 -0600 (MDT) Message-ID: <519D01E9.1060608@stpeter.im> Date: Wed, 22 May 2013 11:35:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Barry Leiba References: <519CE9B5.8000503@gmx.de> <519CFFAF.8080100@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] registry format X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:35:45 -0000 On 5/22/13 11:29 AM, Barry Leiba wrote: >>> Yes, we should have the "value" field removed, the "URN namespace" >>> field rendered in lower case, and the table sorted by URN namespace. >>> >>> As the responsible AD, I will contact IANA about this, and see what they say. >> >> It sounds like something to fix in 2141bis... > > Perhaps, but I don't see that it's necessary to do it that way. I > can't find anything in any RFC that specifies the table as it is, so > it shouldn't need an RFC to fix it. I think I can just work this out > with IANA. Great! Peter -- Peter Saint-Andre https://stpeter.im/ From L.Svensson@dnb.de Thu May 23 05:47:48 2013 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 1818221F939E for ; Thu, 23 May 2013 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkN8I5ubCD-1 for ; Thu, 23 May 2013 05:47:44 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0391921F9301 for ; Thu, 23 May 2013 05:47:43 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 86C7892906 for ; Thu, 23 May 2013 14:45:14 +0200 (CEST) From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Queries in URNs (was: AW: [urn] URN fragments) Thread-Index: Ac5Xs7WVKUiZ6nPqTwuza2Ew76OdIg== Date: Thu, 23 May 2013 12:47:40 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.245] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 12:47:48 -0000 All, I revive this thread about queries in URNs again since we need a resolution= on this in order to proceed with standardization in other (bibliographic) = areas [1]. SHORT VERSION I propose the following: 1) We do not allow queries in URNs, since they only make sense in the conte= xt of URN resolution services. 2) We defer the question of how to handle queries in resolution services to= RFC2483bis. If someone can give me a compelling case for the use of queries in URNs *ou= tside* of URN resolution services, I'd be most happy to discuss that and to= withdraw my proposal. LONGER VERSION Starting point was the question, if adding a query to a URN creates a new r= esource or not and if the query is part of the URN or not: [Julian] > > > It's up to the URN or NIS syntax to describe what the query part > > > means, and how it applies to different namespaces. But in *general*, > > > adding a query part to a URI changes the resource being identified. Even if it doesn't change the resource, at least it identifies another (pri= mary) resource (as opposed to fragment, where adding a fragment makes it a = different identifier while still identifying the same primary resource). [Juha] > > You have to be careful with the word "identify" in the URN context. > > > > From the URN point of view, the resource identified does not change > > when a query is added, if queries are used to facilitate the services > > specified in RFC 2483. All these services are related to one and only > > one identified resource. A user can request for instance the resource > > itself, metadata about it, its current URL or URLs, and so forth. In > > practice, HTTP URIs (locations) the URN resolves to and the things > > that are being retrieved change, but the resource identified by the > > (location > > independent) URN does not. [Lars] > As to the question if the query is part of the urn or not, my reading of = rfc > 3986 =A73.4 is that it _is_ part of the urn [[ The query component is ind= icated by > the first question mark ("?") character and terminated by a number sign (= "#") > character or by the end of the URI.]] If the query component ends at the = end > of the URI, it must be part of it. Question: Can we agree that the query part is part of the URI and thus part= of the URN? Then I went on to the question if we might need to distinguish between diff= erent kinds of queries when discussing URNs. I shall not repeat my example = here; if you are interested, cf. [2] My main point was that we need to distinguish between queries operating on = the URN itself and queries relating to URN resolution services. If we allow= queries on URNs (e. g. urn:example:12345?a=3Db), what happens when I send = that URN to an http-baser resolution service? Do I need to percent-encode t= he URN's query in order not to get into conflict with potential queries spe= cific to that service? Example: If I send the URN urn:example:12345?a=3Db to the resolution service at http= ://example.com/resolver and want to add the query ?c=3Dd, would I need to w= rite http://example.com/resolver?urn:example:12345%3Fa=3Db?c=3Dd ? Having given this topic a fair amount of thought, I suggest the following: 1) We do not allow queries in URNs, since they only make sense in the conte= xt of URN resolution services. 2) We defer the question of how to handle queries in resolution services to= RFC2483bis. If someone can give me a compelling case for the use of queries in URNs *ou= tside* of URN resolution services, I'd be most happy to discuss that and to= withdraw my proposal. [1] cf. a related mail by Juha on the BIBFRAME list: http://listserv.loc.go= v/cgi-bin/wa?A2=3Dind1305&L=3Dbibframe&T=3D0&P=3D31005 [2] http://www.ietf.org/mail-archive/web/urn/current/msg01887.html=20 Thanks, Lars ***Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. German National Library*** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de From jehakala@mappi.helsinki.fi Thu May 23 08:45:59 2013 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 5075721F97A5 for ; Thu, 23 May 2013 08:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3xQL7SXysRq for ; Thu, 23 May 2013 08:45:54 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7007821F8EAD for ; Thu, 23 May 2013 08:45:54 -0700 (PDT) Received: from localhost (webmail-3.mappi.helsinki.fi [128.214.20.217]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r4NFjpP6023700; Thu, 23 May 2013 18:45:51 +0300 Received: from a88-114-110-201.elisa-laajakaista.fi (a88-114-110-201.elisa-laajakaista.fi [88.114.110.201]) by webmail.helsinki.fi (Horde Framework) with HTTP; Thu, 23 May 2013 18:45:51 +0300 Date: Thu, 23 May 2013 18:45:51 +0300 Message-ID: <20130523184551.Horde.SMIbJEMtnWW4rp8UDx1pdw9.jehakala@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:45:59 -0000 Hello Lars, Some comments below. Quoting "Svensson, Lars" : > All, > > I revive this thread about queries in URNs again since we need a > resolution on this in order to proceed with standardization in other > (bibliographic) areas [1]. > > SHORT VERSION > > I propose the following: > > 1) We do not allow queries in URNs, since they only make sense in > the context of URN resolution services. It has been the intention from the beginning that with a query we can pass resolution related guidelines to the appropriate URN resolver. There could be other mechanisms for doing this, such as DDDS record. URNs in general are useful only if there is a resolver that provides the services the users want. > 2) We defer the question of how to handle queries in resolution > services to RFC2483bis. I fail to see how we could first disallow the use of query in 2141bis, and then bring it back in 2483bis. > > If someone can give me a compelling case for the use of queries in > URNs *outside* of URN resolution services, I'd be most happy to > discuss that and to withdraw my proposal. I don't have a compelling case for using URNs without URN resolution services. > > LONGER VERSION > > Starting point was the question, if adding a query to a URN creates > a new resource or not and if the query is part of the URN or not: > > [Julian] >> > > It's up to the URN or NIS syntax to describe what the query part >> > > means, and how it applies to different namespaces. But in *general*, >> > > adding a query part to a URI changes the resource being identified. > > Even if it doesn't change the resource, at least it identifies > another (primary) resource (as opposed to fragment, where adding a > fragment makes it a different identifier while still identifying the > same primary resource). > > [Juha] >> > You have to be careful with the word "identify" in the URN context. >> > >> > From the URN point of view, the resource identified does not change >> > when a query is added, if queries are used to facilitate the services >> > specified in RFC 2483. All these services are related to one and only >> > one identified resource. A user can request for instance the resource >> > itself, metadata about it, its current URL or URLs, and so forth. In >> > practice, HTTP URIs (locations) the URN resolves to and the things >> > that are being retrieved change, but the resource identified by the >> > (location >> > independent) URN does not. > > [Lars] >> As to the question if the query is part of the urn or not, my reading of rfc >> 3986 §3.4 is that it _is_ part of the urn [[ The query component is >> indicated by >> the first question mark ("?") character and terminated by a number >> sign ("#") >> character or by the end of the URI.]] If the query component ends at the end >> of the URI, it must be part of it. > > Question: Can we agree that the query part is part of the URI and > thus part of the URN? This is simple: query is part of URN, since otherwise we would not be compliant with RFC 3986. The difficult question is whether we think that query (or fragment) is a part of the namespace specific string. In the URN system, it is the combination of NID and NSS that identifies things; other parts (the string "urn:" in the beginning and stuff that comes after NSS, if any) does not count in the identification. I do not think query or fragment should be part of the NSS. There are various technical reasons for this, including the fact that fragment does not impact what is being retrieved by HTTP; it is just used by the browser to take the user to a given location within the document. More important than the technical issues are the administrative ones, for me at least. From the URN assignment point of view, incorporating query and fragment into NSS would be a problem because then there would be many namespaces in which it would be a priori impossible to use them. Standard identifiers cannot be extended with something like fragment. If they are not part of the NSS, such limitations disappear, alongside many political issues. Anyone could add a fragment or query to any URN after the URN has been assigned by an authoritative body. If fragment were part of the identifier we would need to specify in namespace registrations who has the right to assign e.g. fragments, and when/how. > > Then I went on to the question if we might need to distinguish > between different kinds of queries when discussing URNs. I shall not > repeat my example here; if you are interested, cf. [2] > > My main point was that we need to distinguish between queries > operating on the URN itself and queries relating to URN resolution > services. IMHO, all the services that have been discussed have been related to the resolution services. But I have a problem grasping the concept of query operating on the URN itself. If this is a simple mapping from one URN to another, such link should be established between metadata records, not in URNs using a query. If we allow queries on URNs (e. g. urn:example:12345?a=b), > what happens when I send that URN to an http-baser resolution > service? Do I need to percent-encode the URN's query in order not to > get into conflict with potential queries specific to that service? The parameter driven encoding of queries that Alfred Hoenes was working on makes such conflicts unlikely, although not impossible. Queries should of course always be sent to a resolver that can deal with them. If the resolver address is incorporated into the HTTP URI containing the URN and the query, it is not likely that the query will be misdirected any time soon. As far as I am concerned, we should not specify resolution services which operate on the URN itself unless there is a compelling business case to do so. So far, if I have for instance a URN for a printed book, and I want to find the URNs for digital versions of the book, this would be done by fetching metadata about the work, which should contain URNs of all the manifestations. Juha > Example: > > If I send the URN urn:example:12345?a=b to the resolution service at > http://example.com/resolver and want to add the query ?c=d, would I > need to write > http://example.com/resolver?urn:example:12345%3Fa=b?c=d ? > > Having given this topic a fair amount of thought, I suggest the following: > > 1) We do not allow queries in URNs, since they only make sense in > the context of URN resolution services. > 2) We defer the question of how to handle queries in resolution > services to RFC2483bis. > > If someone can give me a compelling case for the use of queries in > URNs *outside* of URN resolution services, I'd be most happy to > discuss that and to withdraw my proposal. > > [1] cf. a related mail by Juha on the BIBFRAME list: > http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&P=31005 > [2] http://www.ietf.org/mail-archive/web/urn/current/msg01887.html > > Thanks, > > Lars > > ***Lesen. Hören. Wissen. Deutsche Nationalbibliothek*** > ***Reading. Listening. Understanding. German National Library*** > > -- > Dr. Lars G. Svensson > Deutsche Nationalbibliothek / Informationstechnik > http://www.dnb.de/ > l.svensson@dnb.de > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From L.Svensson@dnb.de Fri May 24 00:34:18 2013 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 BFC4721F9651 for ; Fri, 24 May 2013 00:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKOS2mel678x for ; Fri, 24 May 2013 00:34:13 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6C721F966F for ; Fri, 24 May 2013 00:34:12 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 05B127EE36; Fri, 24 May 2013 09:31:36 +0200 (CEST) From: "Svensson, Lars" To: "jehakala@mappi.helsinki.fi" Thread-Topic: [urn] Queries in URNs (was: AW: URN fragments) Thread-Index: AQHOV8yinDHqsEUufEGtIVvZWgnFrpkT438A Date: Fri, 24 May 2013 07:34:03 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4343C74@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <20130523184551.Horde.SMIbJEMtnWW4rp8UDx1pdw9.jehakala@webmail.helsinki.fi> In-Reply-To: <20130523184551.Horde.SMIbJEMtnWW4rp8UDx1pdw9.jehakala@webmail.helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 07:34:18 -0000 SnVoYSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBNeSBhbnN3ZXJzIGFyZSBpbmxpbmUu DQoNCj4gPiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCj4gPg0KPiA+IDEpIFdlIGRvIG5vdCBh bGxvdyBxdWVyaWVzIGluIFVSTnMsIHNpbmNlIHRoZXkgb25seSBtYWtlIHNlbnNlIGluIHRoZQ0K PiA+IGNvbnRleHQgb2YgVVJOIHJlc29sdXRpb24gc2VydmljZXMuDQo+IA0KPiBJdCBoYXMgYmVl biB0aGUgaW50ZW50aW9uIGZyb20gdGhlIGJlZ2lubmluZyB0aGF0IHdpdGggYSBxdWVyeSB3ZSBj YW4gcGFzcw0KPiByZXNvbHV0aW9uIHJlbGF0ZWQgZ3VpZGVsaW5lcyB0byB0aGUgYXBwcm9wcmlh dGUgVVJOIHJlc29sdmVyLg0KPiBUaGVyZSBjb3VsZCBiZSBvdGhlciBtZWNoYW5pc21zIGZvciBk b2luZyB0aGlzLCBzdWNoIGFzIERERFMgcmVjb3JkLg0KDQpIZXJlIHdlIGRlZmluaXRlbHkgYWdy ZWUuIE15IHF1ZXN0aW9uIGlzIGlmIHRoZSBxdWVyeSwgd2hpY2ggaXMgYWltZWQgYXQgdGhlIHJl c29sdmVyLCBzaG91bGQgYmUgcGFydCBvZiB0aGUgVVJOIG9yIG5vdC4gQ29uc2lkZXJlZCB0aGF0 IFVSTnMgYXJlIGlkZW50aWZpZXJzLCBJIHRoaW5rIHRoZXJlIGNvdWxkIGJlIGNvbnNlbnN1cyBv biB3aGF0IHVybjpleGFtcGxlOjEyMzQ1NiBpZGVudGlmaWVzLCBidXQgd2hhdCB3b3VsZCB1cm46 ZXhhbXBsZToxMjM0NTY/c2VydmljZT1pMmwgaWRlbnRpZnk/DQoNCj4gVVJOcyBpbiBnZW5lcmFs IGFyZSB1c2VmdWwgb25seSBpZiB0aGVyZSBpcyBhIHJlc29sdmVyIHRoYXQgcHJvdmlkZXMgdGhl DQo+IHNlcnZpY2VzIHRoZSB1c2VycyB3YW50Lg0KDQpBcmUgdGhleSBub3QgdXNlZnVsIGFzIGlk ZW50aWZpZXJzLCBldmVuIHdpdGhvdXQgcmVzb2x2ZXIgc2VydmljZXM/IFRoZXJlIHdpbGwgcHJv YmFibHkgbmV2ZXIgYmUgYSByZXNvbHZlciBzZXJ2aWNlIGZvciB1cm46dXVpZCAoYW5kIHBvc3Np Ymx5IG5vdCBmb3IgbWFueSBVUk4gbmFtZXNwYWNlcykuIFRoZSBjb21tdW5pdHkgYWdyZWVzIHRo YXQgdGhleSBhcmUgdXNlZnVsIGFzIGlkZW50aWZpZXJzLCB0aGF0IGlzIHdoeSB0aG9zZSBuYW1l c3BhY2VzIGV4aXN0Lg0KIA0KPiA+IDIpIFdlIGRlZmVyIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8g aGFuZGxlIHF1ZXJpZXMgaW4gcmVzb2x1dGlvbg0KPiA+IHNlcnZpY2VzIHRvIFJGQzI0ODNiaXMu DQo+IA0KPiBJIGZhaWwgdG8gc2VlIGhvdyB3ZSBjb3VsZCBmaXJzdCBkaXNhbGxvdyB0aGUgdXNl IG9mIHF1ZXJ5IGluIDIxNDFiaXMsIGFuZCB0aGVuDQo+IGJyaW5nIGl0IGJhY2sgaW4gMjQ4M2Jp cy4NCg0KTXkgaWRlYSBpcyB0aGF0IHNpbmNlIHRoZSBpbnRlbnRpb24gaXMgdG8gdXNlIHF1ZXJp ZXMgdG8gcGFzcyBpbmZvcm1hdGlvbiAob3IgcGFyYW1ldGVycykgdG8gYSByZXNvbHV0aW9uIHNl cnZpY2UsIHRoZSBxdWVyeSBzaG91bGQgYmUgc3BlY2lmaWVkIF9mb3IgdGhlIHJlc29sdXRpb24g c2VydmljZV8gYW5kIG5vdCBmb3IgdGhlIFVSTi4gQW4gZXhhbXBsZToNCg0KR2l2ZW4gdGhlIFVS TiB1cm46ZXhhbXBsZToxMjM0NTYgYW5kIHRoZSByZXNvbHV0aW9uIHNlcnZpY2UgaHR0cDovL2V4 YW1wbGUuY29tL3Jlc29sdmVyIEkgY2FuIGJ1aWxkIHRoZSByZXNvbHV0aW9uIHJlcXVlc3QgaHR0 cDovL2V4YW1wbGUuY29tL3Jlc29sdmVyL3VybjpleGFtcGxlOjEyMzQ1NiBhbmQgdGhlIHJlc29s dmVyIHdvdWxkIHBlcmZvcm0gaXRzIGRlZmF1bHQgc2VydmljZS4gTm93IGlmIEkgc3BlY2lmaWNh bGx5IHdhbnQgdG8gaW52b2tlIHRoZSBpMmwgc2VydmljZSBJIHdvdWxkIGJ1aWxkIHRoZSByZXF1 ZXN0IGh0dHA6Ly9leGFtcGxlLmNvbS9yZXNvbHZlci91cm46ZXhhbXBsZToxMjM0NTY/c2Vydmlj ZT1pMmwgLg0KDQpUaGlzIHdlIGNhbiBzcGxpdCBpbnRvIHRocmVlIHBhcnRzOg0KDQpodHRwOi8v ZXhhbXBsZS5jb20vcmVzb2x2ZXIvDQp1cm46ZXhhbXBsZToxMjM0NTYNCj9zZXJ2aWNlPWkybA0K DQpUaGUgdW5jbGVhciBwb2ludCBzZWVtcyB0byBiZSB3aGV0aGVyID9zZXJ2aWNlPWkybCBzaG91 bGQgYmUgc2VlbiBhcyBwYXJ0IG9mIHRoZSBVUk4gb3IgYXMgc29tZXRoaW5nIHNlbnQgdG8gdGhl IHJlc29sdXRpb24gc2VydmljZSBhdCBodHRwOi8vZXhhbXBsZS5jb20vcmVzb2x2ZXIvDQoNCk15 IHZpZXcgaXMgdGhhdCA/c2VydmljZT1pMmwgaXMgc29tZXRoaW5nIHNlbnQgdG8gdGhlIHJlc29s dXRpb24gc2VydmljZSBhbmQgbm90IHBhcnQgb2YgdGhlIFVSTi4gVGh1cyBJIGNhbiBkaXNhbGxv dyBxdWVyeSBpbiBSRkMgMjE0MWJpcyBhbmQgc3RpbGwgc3BlY2lmeSBpdHMgdXNlIGluIFJGQyAy NDgzYmlzLg0KDQo+ID4gSWYgc29tZW9uZSBjYW4gZ2l2ZSBtZSBhIGNvbXBlbGxpbmcgY2FzZSBm b3IgdGhlIHVzZSBvZiBxdWVyaWVzIGluDQo+ID4gVVJOcyAqb3V0c2lkZSogb2YgVVJOIHJlc29s dXRpb24gc2VydmljZXMsIEknZCBiZSBtb3N0IGhhcHB5IHRvDQo+ID4gZGlzY3VzcyB0aGF0IGFu ZCB0byB3aXRoZHJhdyBteSBwcm9wb3NhbC4NCj4gDQo+IEkgZG9uJ3QgaGF2ZSBhIGNvbXBlbGxp bmcgY2FzZSBmb3IgdXNpbmcgVVJOcyB3aXRob3V0IFVSTiByZXNvbHV0aW9uDQo+IHNlcnZpY2Vz Lg0KDQpPSy4NCg0KW3NraXBwaW5nIG9sZGVyIGRpc2N1c3Npb25dDQo+ID4NCj4gPiBRdWVzdGlv bjogQ2FuIHdlIGFncmVlIHRoYXQgdGhlIHF1ZXJ5IHBhcnQgaXMgcGFydCBvZiB0aGUgVVJJIGFu ZCB0aHVzDQo+ID4gcGFydCBvZiB0aGUgVVJOPw0KPiANCj4gVGhpcyBpcyBzaW1wbGU6IHF1ZXJ5 IGlzIHBhcnQgb2YgVVJOLCBzaW5jZSBvdGhlcndpc2Ugd2Ugd291bGQgbm90IGJlDQo+IGNvbXBs aWFudCB3aXRoIFJGQyAzOTg2DQoNCk9LLiBIZXJlIHdlIGFncmVlLiBJIGd1ZXNzIHdlIGFsc28g YWdyZWUgdGhhdCB0aGUgZnJhZ21lbnQgaXMgcGFydCBvZiB0aGUgVVJOLCB0b28sIGZvciB0aGUg c2FtZSByZWFzb24uDQogDQo+IFRoZSBkaWZmaWN1bHQgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB0 aGluayB0aGF0IHF1ZXJ5IChvciBmcmFnbWVudCkgaXMgYSBwYXJ0DQo+IG9mIHRoZSBuYW1lc3Bh Y2Ugc3BlY2lmaWMgc3RyaW5nLiBJbiB0aGUgVVJOIHN5c3RlbSwgaXQgaXMgdGhlIGNvbWJpbmF0 aW9uIG9mDQo+IE5JRCBhbmQgTlNTIHRoYXQgaWRlbnRpZmllcyB0aGluZ3M7IG90aGVyIHBhcnRz ICh0aGUgc3RyaW5nICJ1cm46IiBpbiB0aGUNCj4gYmVnaW5uaW5nIGFuZCBzdHVmZiB0aGF0IGNv bWVzIGFmdGVyIE5TUywgaWYgYW55KSBkb2VzIG5vdCBjb3VudCBpbiB0aGUNCj4gaWRlbnRpZmlj YXRpb24uDQo+IA0KPiBJIGRvIG5vdCB0aGluayBxdWVyeSBvciBmcmFnbWVudCBzaG91bGQgYmUg cGFydCBvZiB0aGUgTlNTLiBUaGVyZSBhcmUgdmFyaW91cw0KPiB0ZWNobmljYWwgcmVhc29ucyBm b3IgdGhpcywgaW5jbHVkaW5nIHRoZSBmYWN0IHRoYXQgZnJhZ21lbnQgZG9lcyBub3QgaW1wYWN0 DQo+IHdoYXQgaXMgYmVpbmcgcmV0cmlldmVkIGJ5IEhUVFA7IGl0IGlzIGp1c3QgdXNlZCBieSB0 aGUgYnJvd3NlciB0byB0YWtlIHRoZQ0KPiB1c2VyIHRvIGEgZ2l2ZW4gbG9jYXRpb24gd2l0aGlu IHRoZSBkb2N1bWVudC4NCg0KTXkgZ3V0IGZlZWxpbmcgaXMgYWxzbyB0aGF0IG5laXRoZXIgZnJh Z21lbnQgbm9yIHF1ZXJ5IHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBOU1MuIENhbiB5b3UgZXhwYW5k IGEgYml0IG9uIHdoaWNoIHRlY2huaWNhbCByZWFzb25zIHlvdSBoYXZlPw0KDQo+IE1vcmUgaW1w b3J0YW50IHRoYW4gdGhlIHRlY2huaWNhbCBpc3N1ZXMgYXJlIHRoZSBhZG1pbmlzdHJhdGl2ZSBv bmVzLCBmb3IgbWUNCj4gYXQgbGVhc3QuIEZyb20gdGhlIFVSTiBhc3NpZ25tZW50IHBvaW50IG9m IHZpZXcsIGluY29ycG9yYXRpbmcgcXVlcnkgYW5kDQo+IGZyYWdtZW50IGludG8gTlNTIHdvdWxk IGJlIGEgcHJvYmxlbSBiZWNhdXNlIHRoZW4gdGhlcmUgd291bGQgYmUgbWFueQ0KPiBuYW1lc3Bh Y2VzIGluIHdoaWNoIGl0IHdvdWxkIGJlIGEgcHJpb3JpIGltcG9zc2libGUgdG8gdXNlIHRoZW0u IFN0YW5kYXJkDQo+IGlkZW50aWZpZXJzIGNhbm5vdCBiZSBleHRlbmRlZCB3aXRoIHNvbWV0aGlu ZyBsaWtlIGZyYWdtZW50LiBJZiB0aGV5IGFyZSBub3QNCj4gcGFydCBvZiB0aGUgTlNTLCBzdWNo IGxpbWl0YXRpb25zIGRpc2FwcGVhciwgYWxvbmdzaWRlIG1hbnkgcG9saXRpY2FsIGlzc3Vlcy4N Cj4gQW55b25lIGNvdWxkIGFkZCBhIGZyYWdtZW50IG9yIHF1ZXJ5IHRvIGFueSBVUk4gYWZ0ZXIg dGhlIFVSTiBoYXMgYmVlbg0KPiBhc3NpZ25lZCBieSBhbiBhdXRob3JpdGF0aXZlIGJvZHkuDQo+ IElmIGZyYWdtZW50IHdlcmUgcGFydCBvZiB0aGUgaWRlbnRpZmllciB3ZSB3b3VsZCBuZWVkIHRv IHNwZWNpZnkgaW4NCj4gbmFtZXNwYWNlIHJlZ2lzdHJhdGlvbnMgd2hvIGhhcyB0aGUgcmlnaHQg dG8gYXNzaWduIGUuZy4gZnJhZ21lbnRzLCBhbmQNCj4gd2hlbi9ob3cuDQoNCk9LLiBTbyB3ZSBk byBub3QgYWNjZXB0IGZyYWdtZW50cyAodGhvdWdoIEknZCBzYXkgdGhhdCB0aGUgdGVjaG5pY2Fs IHJlYXNvbiAtLSB1bmlmb3JtIHNlbWFudGljcyBmb3IgYWxsIHJlcHJlc2VudGF0aW9ucyBmb3Ig YWxsIGZ1dHVyZSAtLSBzaG91bGQgYmUgYSByZWFzb24gZ29vZCBlbm91Z2guLi4pLg0KDQo+ID4g VGhlbiBJIHdlbnQgb24gdG8gdGhlIHF1ZXN0aW9uIGlmIHdlIG1pZ2h0IG5lZWQgdG8gZGlzdGlu Z3Vpc2ggYmV0d2Vlbg0KPiA+IGRpZmZlcmVudCBraW5kcyBvZiBxdWVyaWVzIHdoZW4gZGlzY3Vz c2luZyBVUk5zLiBJIHNoYWxsIG5vdCByZXBlYXQgbXkNCj4gPiBleGFtcGxlIGhlcmU7IGlmIHlv dSBhcmUgaW50ZXJlc3RlZCwgY2YuIFsyXQ0KPiA+DQo+ID4gTXkgbWFpbiBwb2ludCB3YXMgdGhh dCB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gcXVlcmllcw0KPiA+IG9wZXJhdGluZyBv biB0aGUgVVJOIGl0c2VsZiBhbmQgcXVlcmllcyByZWxhdGluZyB0byBVUk4gcmVzb2x1dGlvbg0K PiA+IHNlcnZpY2VzLg0KPiANCj4gSU1ITywgYWxsIHRoZSBzZXJ2aWNlcyB0aGF0IGhhdmUgYmVl biBkaXNjdXNzZWQgaGF2ZSBiZWVuIHJlbGF0ZWQgdG8gdGhlDQo+IHJlc29sdXRpb24gc2Vydmlj ZXMuIEJ1dCBJIGhhdmUgYSBwcm9ibGVtIGdyYXNwaW5nIHRoZSBjb25jZXB0IG9mIHF1ZXJ5DQo+ IG9wZXJhdGluZyBvbiB0aGUgVVJOIGl0c2VsZi4gSWYgdGhpcyBpcyBhIHNpbXBsZSBtYXBwaW5n IGZyb20gb25lIFVSTiB0bw0KPiBhbm90aGVyLCBzdWNoIGxpbmsgc2hvdWxkIGJlIGVzdGFibGlz aGVkIGJldHdlZW4gbWV0YWRhdGEgcmVjb3Jkcywgbm90IGluDQo+IFVSTnMgdXNpbmcgYSBxdWVy eS4NCg0KSSBoYXZlIHByb2JsZW1zIGVudmlzaW9uaW5nIHF1ZXJpZXMgb3BlcmF0aW5nIG9uIFVS TnMsIHRvby4gVGhlIG9ubHkgSSBjb3VsZCBjb21lIHVwIHdpdGggd2FzIHRoZSByYXRoZXIgc2ls bHkgZXhhbXBsZSB3aXRoIHRoZSBpbnRlZ2Vycy4NCg0KPiA+IElmIHdlIGFsbG93IHF1ZXJpZXMg b24gVVJOcyAoZS4gZy4gdXJuOmV4YW1wbGU6MTIzNDU/YT1iKSwNCj4gPiB3aGF0IGhhcHBlbnMg d2hlbiBJIHNlbmQgdGhhdCBVUk4gdG8gYW4gaHR0cC1iYXNlciByZXNvbHV0aW9uIHNlcnZpY2U/ DQo+ID4gRG8gSSBuZWVkIHRvIHBlcmNlbnQtZW5jb2RlIHRoZSBVUk4ncyBxdWVyeSBpbiBvcmRl ciBub3QgdG8gZ2V0IGludG8NCj4gPiBjb25mbGljdCB3aXRoIHBvdGVudGlhbCBxdWVyaWVzIHNw ZWNpZmljIHRvIHRoYXQgc2VydmljZT8NCj4gDQo+IFRoZSBwYXJhbWV0ZXIgZHJpdmVuIGVuY29k aW5nIG9mIHF1ZXJpZXMgdGhhdCBBbGZyZWQgSG9lbmVzIHdhcyB3b3JraW5nCQ0KPiBvbiBtYWtl cyBzdWNoIGNvbmZsaWN0cyB1bmxpa2VseSwgYWx0aG91Z2ggbm90IGltcG9zc2libGUuDQo+IA0K PiBRdWVyaWVzIHNob3VsZCBvZiBjb3Vyc2UgYWx3YXlzIGJlIHNlbnQgdG8gYSByZXNvbHZlciB0 aGF0IGNhbiBkZWFsIHdpdGgNCj4gdGhlbS4gSWYgdGhlIHJlc29sdmVyIGFkZHJlc3MgaXMgaW5j b3Jwb3JhdGVkIGludG8gdGhlIEhUVFAgVVJJIGNvbnRhaW5pbmcNCj4gdGhlIFVSTiBhbmQgdGhl IHF1ZXJ5LCBpdCBpcyBub3QgbGlrZWx5IHRoYXQgdGhlIHF1ZXJ5IHdpbGwgYmUgbWlzZGlyZWN0 ZWQgYW55DQo+IHRpbWUgc29vbi4NCg0KWWVzLCBidXQgd2UgYWx3YXlzIHRhbGsgYWJvdXQgcXVl cmllcyBzZW50IHRvIGEgcmVzb2x2ZXIsIGFuZCBub3QgYWJvdXQgcXVlcmllcyB0aGF0IG1ha2Ug c2Vuc2UgZm9yIHRoZSBVUk5zIHRoZW1zZWx2ZXMuIFRoYXQgaXMgd2h5IEkgc3VnZ2VzdCB0aGF0 IHdlIGRvIG5vdCBhbGxvdyBxdWVyaWVzIGluIHRoZSBVUk4gc3ludGF4LCBidXQgb25seSBkaXNj dXNzIHF1ZXJpZXMgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHJlc29sdXRpb24gc2VydmljZXMuDQoN Cj4gQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCB3ZSBzaG91bGQgbm90IHNwZWNpZnkgcmVzb2x1 dGlvbiBzZXJ2aWNlcyB3aGljaA0KPiBvcGVyYXRlIG9uIHRoZSBVUk4gaXRzZWxmIHVubGVzcyB0 aGVyZSBpcyBhIGNvbXBlbGxpbmcgYnVzaW5lc3MgY2FzZSB0byBkbyBzby4NCj4gU28gZmFyLCBp ZiBJIGhhdmUgZm9yIGluc3RhbmNlIGEgVVJOIGZvciBhIHByaW50ZWQgYm9vaywgYW5kIEkgd2Fu dCB0byBmaW5kIHRoZQ0KPiBVUk5zIGZvciBkaWdpdGFsIHZlcnNpb25zIG9mIHRoZSBib29rLCB0 aGlzIHdvdWxkIGJlIGRvbmUgYnkgZmV0Y2hpbmcNCj4gbWV0YWRhdGEgYWJvdXQgdGhlIHdvcmss IHdoaWNoIHNob3VsZCBjb250YWluIFVSTnMgb2YgYWxsIHRoZQ0KPiBtYW5pZmVzdGF0aW9ucy4N Cg0KWWVzLiBBdCB0aGUgcmlzayBvZiByZXBlYXRpbmcgbXlzZWxmIGluZmluaXRlbHk6IElmIHRo ZSBxdWVyeSBkb2VzIG5vdCBtYWtlIHNlbnNlIHdpdGhvdXQgdGhlIHJlc29sdmVyLCB3ZSBkbyBu b3QgbmVlZCBpdCBpbiBSRkMgMjE0MWJpcy4NCg0KTG9va2luZyBmb3J3YXJkIHRvIGNvbW1lbnRz IHJlZmVycmluZyB0byBvdGhlciBuYW1lc3BhY2VzIHRoYW4gdXJuOmlzYm4gYW5kIHVybjpuYm4u DQoNCkxhcnMNCg== From stpeter@stpeter.im Fri May 24 15:56:48 2013 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 3D8F711E812B for ; Fri, 24 May 2013 15:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4mQrWddaf7k for ; Fri, 24 May 2013 15:56:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8CF21F93D4 for ; Fri, 24 May 2013 15:56:43 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5D90B41177 for ; Fri, 24 May 2013 17:09:15 -0600 (MDT) Message-ID: <519FF02B.20801@stpeter.im> Date: Fri, 24 May 2013 16:56:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "urn@ietf.org" References: <20130524195753.BD9C762102@rfc-editor.org> In-Reply-To: <20130524195753.BD9C762102@rfc-editor.org> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130524195753.BD9C762102@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [urn] Fwd: BCP 183, RFC 6963 on A Uniform Resource Name (URN) Namespace for Examples X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 22:56:48 -0000 FYI. -------- Original Message -------- Subject: BCP 183, RFC 6963 on A Uniform Resource Name (URN) Namespace for Examples Date: Fri, 24 May 2013 12:57:53 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. BCP 183 RFC 6963 Title: A Uniform Resource Name (URN) Namespace for Examples Author: P. Saint-Andre Status: Best Current Practice Stream: IETF Date: May 2013 Mailbox: psaintan@cisco.com Pages: 7 Characters: 11749 See Also: BCP 183 I-D Tag: draft-saintandre-urn-example-05.txt URL: http://www.rfc-editor.org/rfc/rfc6963.txt This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From moore@network-heretics.com Wed May 29 09:51:11 2013 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 5B9C421F968E for ; Wed, 29 May 2013 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um5OWnyJHXyW for ; Wed, 29 May 2013 09:51:05 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 38E7B21F95A0 for ; Wed, 29 May 2013 09:51:01 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 25769209D8; Wed, 29 May 2013 12:51:00 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([unixlocal]) by compute5.internal (MEProxy); Wed, 29 May 2013 12:51:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Cn7VOk/nKDv2tjeFGfwwNI 32EfQ=; b=FoNhgYQEyJLGaZKtijoW6V78MRF9VtK/KyqegY5YyeJoLPIRvCug1V glyvsWkO9sqjy6eHuQUc4dbK20etJdMFFoSsFCvu9tE0ziPVrfcrSPA0AQ+BVvNU 2X2NRR+AnJBHhNA+/VLt7iz1nDd3vebvC1F+qfWbx8NOTb2A7zbjo= X-Sasl-enc: ymrdPCra47KHCaHtMTe2Wxk5/gDz0X27Onov3hwpbLkf 1369846259 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7CEC920016F; Wed, 29 May 2013 12:50:59 -0400 (EDT) Message-ID: <51A631CD.2010302@network-heretics.com> Date: Wed, 29 May 2013 12:50:21 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:51:11 -0000 On 05/23/2013 08:47 AM, Svensson, Lars wrote: > All, > > I revive this thread about queries in URNs again since we need a resolution on this in order to proceed with standardization in other (bibliographic) areas [1]. > > SHORT VERSION > > I propose the following: > > 1) We do not allow queries in URNs, since they only make sense in the context of URN resolution services. > 2) We defer the question of how to handle queries in resolution services to RFC2483bis. > > If someone can give me a compelling case for the use of queries in URNs *outside* of URN resolution services, I'd be most happy to discuss that and to withdraw my proposal. 3) when a query is appended to the URN, the query is transmitted to the resource named by the URN. It has no effect on resolution. It's a really Bad Idea to make URL query syntax mean something different for URNs than it does for URLs. Keith From moore@network-heretics.com Wed May 29 09:55:18 2013 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 3ACB921F9718 for ; Wed, 29 May 2013 09:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id popf+bp2dvX2 for ; Wed, 29 May 2013 09:55:06 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 03DA021F96CB for ; Wed, 29 May 2013 09:55:03 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AAD1C2099B for ; Wed, 29 May 2013 12:55:00 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([unixlocal]) by compute4.internal (MEProxy); Wed, 29 May 2013 12:55:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=0cp4rN7pDAG5ryLXkvYfkq 4hYto=; b=g5LIEb6jNjSppgRm8Y4Ct0ZEtEDuhEAJ4V3hXo1ut3BHtmJfxlmhL7 +uWbO4jQZfM96ZFTp2Q17ljcE3hHHW4xFSbpr7ZZxVX2nFGNJl1L/CPBqU1Hu4hB rPzKt3VQ+goLWOV5QgApx68MwDkn2keJIImuBowsfeQvUA2dS57IQ= X-Sasl-enc: lJjJaTcqMGWJbA8X8d7qKDDExdCkk+w+iqRH0bD7ZKS0 1369846500 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 1FF3A20008D; Wed, 29 May 2013 12:55:00 -0400 (EDT) Message-ID: <51A632BE.9090707@network-heretics.com> Date: Wed, 29 May 2013 12:54:22 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <20130523184551.Horde.SMIbJEMtnWW4rp8UDx1pdw9.jehakala@webmail.helsinki.fi> In-Reply-To: <20130523184551.Horde.SMIbJEMtnWW4rp8UDx1pdw9.jehakala@webmail.helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:55:18 -0000 On 05/23/2013 11:45 AM, jehakala@mappi.helsinki.fi wrote: > Hello Lars, > > Some comments below. > > Quoting "Svensson, Lars" : > >> All, >> >> I revive this thread about queries in URNs again since we need a >> resolution on this in order to proceed with standardization in other >> (bibliographic) areas [1]. >> >> SHORT VERSION >> >> I propose the following: >> >> 1) We do not allow queries in URNs, since they only make sense in the >> context of URN resolution services. > > It has been the intention from the beginning that with a query we can > pass resolution related guidelines to the appropriate URN resolver. > There could be other mechanisms for doing this, such as DDDS record. Whose intention? Which beginning? > URNs in general are useful only if there is a resolver that provides > the services the users want. Some people would argue that they have other uses, but that was the originally intended purpose of URNs. However, there was never any consensus that said that "the services the users want" are to be specified as part of the URN itself. The URN names the resource, not some attribute of the resource. IMO, people are too invested in a web browser model where the user doesn't specify what he wants from a resource, he just clicks on it. He has no choice about how to interact with that resource, other than to click or to not click. URNs were never intended to be limited to that style of interaction. Keith From stpeter@stpeter.im Wed May 29 10:28:03 2013 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 B9F8C21F8FF8 for ; Wed, 29 May 2013 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2JDPzrefJPk for ; Wed, 29 May 2013 10:27:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB4D21F9058 for ; Wed, 29 May 2013 10:27:59 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C288241111; Wed, 29 May 2013 11:40:47 -0600 (MDT) Message-ID: <51A63A9D.8070503@stpeter.im> Date: Wed, 29 May 2013 11:27:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> In-Reply-To: <51A631CD.2010302@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:28:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/29/13 10:50 AM, Keith Moore wrote: > On 05/23/2013 08:47 AM, Svensson, Lars wrote: >> All, >> >> I revive this thread about queries in URNs again since we need a >> resolution on this in order to proceed with standardization in >> other (bibliographic) areas [1]. >> >> SHORT VERSION >> >> I propose the following: >> >> 1) We do not allow queries in URNs, since they only make sense in >> the context of URN resolution services. 2) We defer the question >> of how to handle queries in resolution services to RFC2483bis. >> >> If someone can give me a compelling case for the use of queries >> in URNs *outside* of URN resolution services, I'd be most happy >> to discuss that and to withdraw my proposal. > 3) when a query is appended to the URN, the query is transmitted to > the resource named by the URN. It has no effect on resolution. Keith, are you agreeing with (1) and (2) and adding (3), or proposing (3) instead of (1) and (2)? > It's a really Bad Idea to make URL query syntax mean something > different for URNs than it does for URLs. Personally I think allowing queries in URNs is a bad idea, but that passing a URN as a parameter to a URN resolution service would be fine (where the "URN-string" might be contained in the query component of, say, an HTTP URI whose authority component is the resolution service). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpjqcAAoJEOoGpJErxa2pa0EP/3ErKDhv5MP+ZiH/1fh+WsNk OckIpwGZRqbXVgHUoQJNrHK/0PQnJLmPTZ10mjqX5ZUGF4RtXrv8CPnH0vTpULbm 5PLulSwwoWGS5YVtrAAPpTckjs8YmfgYCgRoahfYE9PwA2BDSyy/WPKrAnpRbwM4 dWCWeK5v9X/PtuJenXO9RYwqrji8B36bqhtRhxpmjlgCeCLmZuvmNKAfYq5Bm+tb sKsv/ljQPDb8+WKrDC9Xv3IWpiS2zQk6PiMt/n6jZWWKnIKZhyDBNdvymINiMmVn foToKHk8VY/oOzTjOhE7BWtJ7lXzzkq6dlkXI+KFj53ELwe9fTBrYfIaatfeKNEX YjAp+uePUfX5Fa/6e4HX1Uo4btclUuIUqe3osDFkpp5GDfznMQMNcltuRIpgjIt1 wh2+IdPsb9MThBGxzYxIdc7eP9AY7y4tqn/EmMRTsYInCGxioyrdqWAzYbByF2aU UWJdEvH51tRzmsg7wPbhI3S6HoENGAVwDHcSmosCISzcOzLHkv0zSYg6jdm6VtDa Q2KbOKHyI18F4ChRGzeIiu8gTHTTR1+VF02j4h5gHNWEbk5YgpxY9/bOR5I6UZkp d0VnjohfLndz57Dr4JRZkHrf5mfBhpo5vjeV3U76+AIeZerwRDAgSrAfCXgb/ebV IrRPQ+afFKPfquUwNwLN =/4o2 -----END PGP SIGNATURE----- From moore@network-heretics.com Wed May 29 10:52:38 2013 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 17D5021F95E0 for ; Wed, 29 May 2013 10:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27n-L7HyoyML for ; Wed, 29 May 2013 10:52:31 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4093421F95D7 for ; Wed, 29 May 2013 10:52:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9DB2D20E9C; Wed, 29 May 2013 13:52:28 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([unixlocal]) by compute2.internal (MEProxy); Wed, 29 May 2013 13:52:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=lOf6N2OAf25LbjdE2FmQ5u flvnQ=; b=fXm5x7EuWqy6uR9xICrgv8/p/QUvwCDGAF96Z1kBQgE0K7xbLq64CO GA0wKUplMwpa5035AV4RwgOG+14eX/mkK3RnOSI54QwjRuWdiOiFCHHv3jXvwl5L eW769YzDjNw1dfvn1YDI8DHKRKLFBbSF5G6p7DJuRoEnQg38LQPB4= X-Sasl-enc: Ghq9hIXP0n+cIuE/Ra/fA0rRNA4G5JC4378a9y26eL6y 1369849947 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2601420032F; Wed, 29 May 2013 13:52:27 -0400 (EDT) Message-ID: <51A64034.8070402@network-heretics.com> Date: Wed, 29 May 2013 13:51:48 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> In-Reply-To: <51A63A9D.8070503@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:52:38 -0000 On 05/29/2013 01:27 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 5/29/13 10:50 AM, Keith Moore wrote: >> On 05/23/2013 08:47 AM, Svensson, Lars wrote: >>> All, >>> >>> I revive this thread about queries in URNs again since we need a >>> resolution on this in order to proceed with standardization in >>> other (bibliographic) areas [1]. >>> >>> SHORT VERSION >>> >>> I propose the following: >>> >>> 1) We do not allow queries in URNs, since they only make sense in >>> the context of URN resolution services. 2) We defer the question >>> of how to handle queries in resolution services to RFC2483bis. >>> >>> If someone can give me a compelling case for the use of queries >>> in URNs *outside* of URN resolution services, I'd be most happy >>> to discuss that and to withdraw my proposal. >> 3) when a query is appended to the URN, the query is transmitted to >> the resource named by the URN. It has no effect on resolution. > Keith, are you agreeing with (1) and (2) and adding (3), or proposing > (3) instead of (1) and (2)? I'm proposing (3) instead of (1) and (2). >> It's a really Bad Idea to make URL query syntax mean something >> different for URNs than it does for URLs. > Personally I think allowing queries in URNs is a bad idea, but that > passing a URN as a parameter to a URN resolution service would be fine > (where the "URN-string" might be contained in the query component of, > say, an HTTP URI whose authority component is the resolution service). I don't think that it makes sense to have the resolution service interpret the query string at all. If you do that then you block the ability of the resolved resource to accept query strings. Either that or you have to create some registry for query parameters so that the resolution service can tell which parameters belong to it and which belong to the resource. That way lies madness, and it's too late to try to restrict what kinds of query parameters a resource can use. So the solution: stop trying to overload the query string as a way to communicate preferences to the resolution service. Keith From stpeter@stpeter.im Wed May 29 11:25:45 2013 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 C017621F91B7 for ; Wed, 29 May 2013 11:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nj3o2s+MfkLY for ; Wed, 29 May 2013 11:25:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 74B3721F8756 for ; Wed, 29 May 2013 11:25:24 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2CD794115C; Wed, 29 May 2013 12:38:13 -0600 (MDT) Message-ID: <51A64812.20805@stpeter.im> Date: Wed, 29 May 2013 12:25:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <51A64034.8070402@network-heretics.com> In-Reply-To: <51A64034.8070402@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 18:25:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/29/13 11:51 AM, Keith Moore wrote: > On 05/29/2013 01:27 PM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 5/29/13 10:50 AM, Keith Moore wrote: >>> On 05/23/2013 08:47 AM, Svensson, Lars wrote: >>>> All, >>>> >>>> I revive this thread about queries in URNs again since we >>>> need a resolution on this in order to proceed with >>>> standardization in other (bibliographic) areas [1]. >>>> >>>> SHORT VERSION >>>> >>>> I propose the following: >>>> >>>> 1) We do not allow queries in URNs, since they only make >>>> sense in the context of URN resolution services. 2) We defer >>>> the question of how to handle queries in resolution services >>>> to RFC2483bis. >>>> >>>> If someone can give me a compelling case for the use of >>>> queries in URNs *outside* of URN resolution services, I'd be >>>> most happy to discuss that and to withdraw my proposal. >>> 3) when a query is appended to the URN, the query is >>> transmitted to the resource named by the URN. It has no effect >>> on resolution. >> Keith, are you agreeing with (1) and (2) and adding (3), or >> proposing (3) instead of (1) and (2)? > > I'm proposing (3) instead of (1) and (2). >>> It's a really Bad Idea to make URL query syntax mean something >>> different for URNs than it does for URLs. >> Personally I think allowing queries in URNs is a bad idea, but >> that passing a URN as a parameter to a URN resolution service >> would be fine (where the "URN-string" might be contained in the >> query component of, say, an HTTP URI whose authority component is >> the resolution service). > > I don't think that it makes sense to have the resolution service > interpret the query string at all. If you do that then you block > the ability of the resolved resource to accept query strings. > Either that or you have to create some registry for query > parameters so that the resolution service can tell which parameters > belong to it and which belong to the resource. That way lies > madness, and it's too late to try to restrict what kinds of query > parameters a resource can use. > > So the solution: stop trying to overload the query string as a way > to communicate preferences to the resolution service. I have no opinions whatsoever on how best to interact with a resolution service. If a service provider like resolver.example.com wants to use https://resolver.example.com?input=stringified-urn then that's fine with me. Now, as to your proposal (3), are you suggesting that we allow query components on URNs? What exactly does it mean for a query to be transmitted to the resource named by the URN? What exactly is the resource in, say, URN:ISBN:0-395-36341-1 (RFC 3187) or urn:service:sos.fire (RFC 5031) or urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)? Perhaps it's just my lack of imagination, but I'm having a hard time visualizing how we would pass a query component to a bound book in a library, to the name of an XML namespace, etc. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpkgSAAoJEOoGpJErxa2pZQYQAKF/OFRJ9c1D98K0tfdUzdsx W9yCCEBYXvvORqcYcdv8T+5n/ZZXNix29G/CUKHqP6f9BNW2KgdamWkNMCIbzqT1 QYdf99dYcmkvWo21U5UCbvg0dAvoMGnV83m5bi5DRqOM6oF77tFnKttVajUnmH/2 QkPdbGXhoTqZ1ebIUbj1SOGgSJkF3s0XhEXVqEagSW1NRCjOBvlStzCV/gHehzCO hhALwucmrASXvG4ZH8TmlWX1vyWCRul1xuUFhAdWXmXTvqigdq+NhvF507V+/CO6 I44NbC319D+wds/5YhFD70aaMEM9BqoTs1+pdYMR3jS7RUX+T8FKesS8rt4SkJs5 h8DjMLNtdhn9qEQOixyGENd/lKIbwB+OAxGBziWI/XpGIdCTKYfr9+jp7F2hED6/ jPJyb67fzATK2+GG0TEhmkrMzOYF8dMAawO2AWZXd0VCfEnsHbuIRaOOF3S0D/d1 voFls33K0Q0HIR0dMnkdV+H8hlhfivJhzALDEIU5XmgiY+O+aKT0O06olB4NCNgp GtBOMZFBQ5L4ht6WUTRBhUsMuFPHdbcO8d0/IX3Rdnhj/kRR3PK1+MjrBO+V0cn+ YvEpo0uYQVugT3xicjfratZ6V2FlHDc1P8rPygDho5QW7dQiFSSXyDt+BExMQWg6 tdJpLTLb8Y3kjbRZ3Lun =5W1J -----END PGP SIGNATURE----- From moore@network-heretics.com Wed May 29 11:50:21 2013 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 9650921F9485 for ; Wed, 29 May 2013 11:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5+-G42KRjPu for ; Wed, 29 May 2013 11:50:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id B4FD321F946F for ; Wed, 29 May 2013 11:50:15 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B2E50209DA; Wed, 29 May 2013 14:50:14 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([unixlocal]) by compute6.internal (MEProxy); Wed, 29 May 2013 14:50:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from :subject:date:to; s=smtpout; bh=sfSIPtJ6kzyemuLSVq/l8zjb/Cg=; b= qARSX4EulfPOrJ8qWDwWRR82QwjptAR/K51EG3157kFmyRlMyYQOXUmbKMwj2WVt on6UBJeFUZJrKpI3Z7WR08x818mEuAbhhP7ezvC1Y6wAReYtc6nI1hA7bIpZPzxY 2TwNtioh25a9W7F4Z2rzf3US2Hd5/Z38kHwknfSpD3c= X-Sasl-enc: Ti/htpPnFfcrgxStrYsKvsKIP/LhLlgsDqSyY2wkUru9 1369853410 Received: from [192.168.22.209] (unknown [173.164.14.141]) by mail.messagingengine.com (Postfix) with ESMTPA id EB4ECC8000E; Wed, 29 May 2013 14:50:10 -0400 (EDT) References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <51A64034.8070402@network-heretics.com> <51A64812.20805@stpeter.im> In-Reply-To: <51A64812.20805@stpeter.im> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-22493CD1-932C-4157-855E-E306066CD74D Message-Id: X-Mailer: iPhone Mail (10B329) From: Keith Moore Date: Wed, 29 May 2013 14:50:08 -0400 To: Peter Saint-Andre Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 18:50:21 -0000 --Apple-Mail-22493CD1-932C-4157-855E-E306066CD74D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Now, as to your proposal (3), are you suggesting that we allow query compo= nents on URNs? What exactly does it mean for a query to be transmitted to th= e resource named by the URN? What exactly is the resource in, say, URN:ISBN:= 0-395-36341-1(RFC 3187) or urn:service:sos.fire (RFC 5031) or urn:cablelabs:= packetcable-example:ue:rst-sample (RFC 6289)?=20 If any of those URNs resolves to a resource for which query strings have mea= ning (note that this can change over time), the URN with the query string ap= pended means whatever it means to access that resource using that query stri= ng.=20 Of course, query strings aren't meaningful for all resource types and not co= mpatible with all access protocols. To ask what a URN with a query string a= ppended if the resource or access protocol don't support query strings is a b= it like asking what an ftp: URL with a query string means. Though it does occur to me that perhaps the presence of a query string shoul= d affect URN resolution in one way: it should perhaps indicate a preference t= o have the URN resolved to an instance of the resource and access protocol t= hat are compatible with query strings. Sent from my iPhone On May 29, 2013, at 2:25 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 5/29/13 11:51 AM, Keith Moore wrote: >> On 05/29/2013 01:27 PM, Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>=20 >>> On 5/29/13 10:50 AM, Keith Moore wrote: >>>> On 05/23/2013 08:47 AM, Svensson, Lars wrote: >>>>> All, >>>>>=20 >>>>> I revive this thread about queries in URNs again since we >>>>> need a resolution on this in order to proceed with >>>>> standardization in other (bibliographic) areas [1]. >>>>>=20 >>>>> SHORT VERSION >>>>>=20 >>>>> I propose the following: >>>>>=20 >>>>> 1) We do not allow queries in URNs, since they only make >>>>> sense in the context of URN resolution services. 2) We defer >>>>> the question of how to handle queries in resolution services >>>>> to RFC2483bis. >>>>>=20 >>>>> If someone can give me a compelling case for the use of >>>>> queries in URNs *outside* of URN resolution services, I'd be >>>>> most happy to discuss that and to withdraw my proposal. >>>> 3) when a query is appended to the URN, the query is >>>> transmitted to the resource named by the URN. It has no effect >>>> on resolution. >>> Keith, are you agreeing with (1) and (2) and adding (3), or >>> proposing (3) instead of (1) and (2)? >>=20 >> I'm proposing (3) instead of (1) and (2). >>>> It's a really Bad Idea to make URL query syntax mean something=20 >>>> different for URNs than it does for URLs. >>> Personally I think allowing queries in URNs is a bad idea, but >>> that passing a URN as a parameter to a URN resolution service >>> would be fine (where the "URN-string" might be contained in the >>> query component of, say, an HTTP URI whose authority component is >>> the resolution service). >>=20 >> I don't think that it makes sense to have the resolution service=20 >> interpret the query string at all. If you do that then you block >> the ability of the resolved resource to accept query strings. >> Either that or you have to create some registry for query >> parameters so that the resolution service can tell which parameters >> belong to it and which belong to the resource. That way lies >> madness, and it's too late to try to restrict what kinds of query >> parameters a resource can use. >>=20 >> So the solution: stop trying to overload the query string as a way >> to communicate preferences to the resolution service. >=20 > I have no opinions whatsoever on how best to interact with a > resolution service. If a service provider like resolver.example.com > wants to use https://resolver.example.com?input=3Dstringified-urn then > that's fine with me. >=20 > Now, as to your proposal (3), are you suggesting that we allow query > components on URNs? What exactly does it mean for a query to be > transmitted to the resource named by the URN? What exactly is the > resource in, say, URN:ISBN:0-395-36341-1 (RFC 3187) or > urn:service:sos.fire (RFC 5031) or > urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)? Perhaps > it's just my lack of imagination, but I'm having a hard time > visualizing how we would pass a query component to a bound book in a > library, to the name of an XML namespace, etc. >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJRpkgSAAoJEOoGpJErxa2pZQYQAKF/OFRJ9c1D98K0tfdUzdsx > W9yCCEBYXvvORqcYcdv8T+5n/ZZXNix29G/CUKHqP6f9BNW2KgdamWkNMCIbzqT1 > QYdf99dYcmkvWo21U5UCbvg0dAvoMGnV83m5bi5DRqOM6oF77tFnKttVajUnmH/2 > QkPdbGXhoTqZ1ebIUbj1SOGgSJkF3s0XhEXVqEagSW1NRCjOBvlStzCV/gHehzCO > hhALwucmrASXvG4ZH8TmlWX1vyWCRul1xuUFhAdWXmXTvqigdq+NhvF507V+/CO6 > I44NbC319D+wds/5YhFD70aaMEM9BqoTs1+pdYMR3jS7RUX+T8FKesS8rt4SkJs5 > h8DjMLNtdhn9qEQOixyGENd/lKIbwB+OAxGBziWI/XpGIdCTKYfr9+jp7F2hED6/ > jPJyb67fzATK2+GG0TEhmkrMzOYF8dMAawO2AWZXd0VCfEnsHbuIRaOOF3S0D/d1 > voFls33K0Q0HIR0dMnkdV+H8hlhfivJhzALDEIU5XmgiY+O+aKT0O06olB4NCNgp > GtBOMZFBQ5L4ht6WUTRBhUsMuFPHdbcO8d0/IX3Rdnhj/kRR3PK1+MjrBO+V0cn+ > YvEpo0uYQVugT3xicjfratZ6V2FlHDc1P8rPygDho5QW7dQiFSSXyDt+BExMQWg6 > tdJpLTLb8Y3kjbRZ3Lun > =3D5W1J > -----END PGP SIGNATURE----- --Apple-Mail-22493CD1-932C-4157-855E-E306066CD74D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Now, as to your proposal (3), are you suggesting that we allow= query components on URNs? What exactly does it mean for a query to be transmitted to t= he resource named by the URN? What exactly is the resource in, say, URN:ISBN:0-395-363= 41-1(RFC 3187= ) or = urn:service:sos.fire (RFC 5031) or urn:cablelabs:packetcable-example:ue:rst-sampl= e (RFC 6289)?Sent from my iPhone

On May 29, 2013,= at 2:25 PM, Peter Saint-Andre <stp= eter@stpeter.im> wrote:

-----BEGIN PGP SIGNED MESSAGE-= ----
Hash: SHA1

On 5/29/13 1= 1:51 AM, Keith Moore wrote:
On 05/= 29/2013 01:27 PM, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAG= E----- Hash: SHA1

On 5/29/13 10:50 AM, K= eith Moore wrote:
On 05/23/2013 0= 8:47 AM, Svensson, Lars wrote:
All,

=
I revive this thread about queries in URNs again since we
=
need a resolution on this in order to proceed with
<= span>standardization in other (bibliographic) areas [1].

SHORT VERSION

= I propose the following:

1) We do no= t allow queries in URNs, since they only make
sense in th= e context of URN resolution services. 2) We defer
the qu= estion of how to handle queries in resolution services
t= o RFC2483bis.
=

If someone can give m= e a compelling case for the use of
queries in URNs *outs= ide* of URN resolution services, I'd be
=
most happy to di= scuss that and to withdraw my proposal.
=
3) when a query is appended to the URN, th= e query is
transmit= ted to the resource named by the URN.  It has no effect
on resolution.
Keith, are you agreeing with (1) and (2) and adding (3), or
proposing (3) instead of (1) and (2)?

I'm proposing (3) instead of (1) and (2).
<= /blockquote>
It's a really Bad Idea to make URL query syntax mean some= thing
different fo= r URNs than it does for URLs.
Personally I th= ink allowing queries in URNs is a bad idea, but
that passi= ng a URN as a parameter to a URN resolution service
<= /blockquote>
would b= e fine (where the "URN-string" might be contained in the
q= uery component of, say, an HTTP URI whose authority component is
<= /blockquote>
the resolution service).

I don't think that it makes sense to have the resolution service =
interpret the query string a= t all.   If you do that then you block
the ability of the resolved resource to accept q= uery strings.
Either t= hat or you have to create some registry for query
parameters so that the resolution service can t= ell which parameters
= belong to it and which belong to the resource.   That way lies
madness, and it's too la= te to try to restrict what kinds of query
parameters a resource can use.
<= blockquote type=3D"cite">
So the solution: stop trying to overload the query string as a wa= y
to communicate pref= erences to the resolution service.

<= span>I have no opinions whatsoever on how best to interact with a
= resolution service. If a service provider like resolver.example.com
wants to use https://resolver= .example.com?input=3Dstringified-urn then
that's fine wi= th me.

Now, as to your proposal (3), are yo= u suggesting that we allow query
components on URNs? What ex= actly does it mean for a query to be
transmitted to the reso= urce named by the URN? What exactly is the
resource in, say,= URN:ISBN:0-395-36341-1 (RFC 3187) or
urn:service:sos.fire (= RFC 5031) or
urn:cablelabs:packetcable-example:ue:rst-sample= (RFC 6289)? Perhaps
it's just my lack of imagination, but I= 'm having a hard time
visualizing how we would pass a query c= omponent to a bound book in a
library, to the name of an XML= namespace, etc.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

=
-----BEGIN PGP SIGNATURE-----
Version= : GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Us= ing GnuPG with Thunderbird - http://www= .enigmail.net/

iQIcBAEBAgAGBQJRpkgSAAoJ= EOoGpJErxa2pZQYQAKF/OFRJ9c1D98K0tfdUzdsx
W9yCCEBYXvvORqcYcdv= 8T+5n/ZZXNix29G/CUKHqP6f9BNW2KgdamWkNMCIbzqT1
QYdf99dYcmkvWo= 21U5UCbvg0dAvoMGnV83m5bi5DRqOM6oF77tFnKttVajUnmH/2
QkPdbGXho= TqZ1ebIUbj1SOGgSJkF3s0XhEXVqEagSW1NRCjOBvlStzCV/gHehzCO
hhAL= wucmrASXvG4ZH8TmlWX1vyWCRul1xuUFhAdWXmXTvqigdq+NhvF507V+/CO6
I44NbC319D+wds/5YhFD70aaMEM9BqoTs1+pdYMR3jS7RUX+T8FKesS8rt4SkJs5
= h8DjMLNtdhn9qEQOixyGENd/lKIbwB+OAxGBziWI/XpGIdCTKYfr9+jp7F2hED6/
jPJyb67fzATK2+GG0TEhmkrMzOYF8dMAawO2AWZXd0VCfEnsHbuIRaOOF3S0D/d1<= /span>
voFls33K0Q0HIR0dMnkdV+H8hlhfivJhzALDEIU5XmgiY+O+aKT0O06olB4N= CNgp
GtBOMZFBQ5L4ht6WUTRBhUsMuFPHdbcO8d0/IX3Rdnhj/kRR3PK1+Mj= rBO+V0cn+
YvEpo0uYQVugT3xicjfratZ6V2FlHDc1P8rPygDho5QW7dQiFS= SXyDt+BExMQWg6
tdJpLTLb8Y3kjbRZ3Lun
=3D5W1J<= /span>
-----END PGP SIGNATURE-----
= --Apple-Mail-22493CD1-932C-4157-855E-E306066CD74D-- From L.Svensson@dnb.de Thu May 30 07:11:50 2013 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 BAC6B21F8607 for ; Thu, 30 May 2013 07:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ4QqoZWyhFo for ; Thu, 30 May 2013 07:11:43 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4563521F84CE for ; Thu, 30 May 2013 07:11:34 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 608207EE29; Thu, 30 May 2013 16:09:00 +0200 (CEST) From: "Svensson, Lars" To: Keith Moore , Peter Saint-Andre Thread-Topic: Re: [urn] Queries in URNs Thread-Index: Ac5dP4svpRa6i/N2RO2qC1nKPilwSw== Date: Thu, 30 May 2013 14:11:31 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4345E9D@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:11:51 -0000 Pj4gTm93LCBhcyB0byB5b3VyIHByb3Bvc2FsICgzKSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQg d2UgYWxsb3cgcXVlcnkNCj4+IGNvbXBvbmVudHMgb24gVVJOcz8gV2hhdCBleGFjdGx5IGRvZXMg aXQgbWVhbiBmb3IgYSBxdWVyeSB0byBiZQ0KPj4gdHJhbnNtaXR0ZWQgdG8gdGhlIHJlc291cmNl IG5hbWVkIGJ5IHRoZSBVUk4/IFdoYXQgZXhhY3RseSBpcyB0aGUgcmVzb3VyY2UNCj4+IGluLCBz YXksIFVSTjpJU0JOOjAtMzk1LTM2MzQxLTEoUkZDIDMxODcpIG9yIHVybjpzZXJ2aWNlOnNvcy5m aXJlIChSRkMgNTAzMSkNCj4+IG9yIHVybjpjYWJsZWxhYnM6cGFja2V0Y2FibGUtZXhhbXBsZTp1 ZTpyc3Qtc2FtcGxlIChSRkMgNjI4OSk/DQo+IA0KPiANCj4gSWYgYW55IG9mIHRob3NlIFVSTnMg cmVzb2x2ZXMgdG8gYSByZXNvdXJjZSBmb3Igd2hpY2ggcXVlcnkgc3RyaW5ncyBoYXZlDQo+IG1l YW5pbmcgKG5vdGUgdGhhdCB0aGlzIGNhbiBjaGFuZ2Ugb3ZlciB0aW1lKSwgdGhlIFVSTiB3aXRo IHRoZSBxdWVyeSBzdHJpbmcNCj4gYXBwZW5kZWQgbWVhbnMgd2hhdGV2ZXIgaXQgbWVhbnMgdG8g YWNjZXNzIHRoYXQgcmVzb3VyY2UgdXNpbmcgdGhhdCBxdWVyeQ0KPiBzdHJpbmcuDQoNCkp1c3Qg dG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHk6DQoNClNheSBJIGNyZWF0ZSBh IFVSTiBmb3IgbXkgbWFpbGJveDogdXJuOmV4YW1wbGU6bWJveDpsYXJzIHdoaWNoIHJlc29sdmVz IHRvIGxhcnNAZXhhbXBsZS5jb20gLiBUaGVuIHVybjpleGFtcGxlOm1ib3g6bGFycz9zdWJqZWN0 PUhpJTIwdGhlcmUmYm9keT1IZWxsbyUyMHdvcmxkIHdvdWxkIHJlc29sdmUgdG8gbGFyc0BleGFt cGxlLmNvbT9zdWJqZWN0PUhpJTIwdGhlcmUmYm9keT1IZWxsbyUyMHdvcmxkICh3aGljaCBpcyBP SyBhY2NvcmRpbmcgdG8gcmZjIDYwNjggWzFdKQ0KIA0KPiBPZiBjb3Vyc2UsIHF1ZXJ5IHN0cmlu Z3MgYXJlbid0IG1lYW5pbmdmdWwgZm9yIGFsbCByZXNvdXJjZSB0eXBlcyBhbmQgbm90DQo+IGNv bXBhdGlibGUgd2l0aCBhbGwgYWNjZXNzIHByb3RvY29scy4gDQoNClZlcnkgdHJ1ZS4NCg0KPiBU byBhc2sgd2hhdCBhIFVSTiB3aXRoIGEgcXVlcnkgc3RyaW5nDQo+IGFwcGVuZGVkIGlmIHRoZSBy ZXNvdXJjZSBvciBhY2Nlc3MgcHJvdG9jb2wgZG9uJ3Qgc3VwcG9ydCBxdWVyeSBzdHJpbmdzIGlz IGENCj4gYml0IGxpa2UgYXNraW5nIHdoYXQgYW4gZnRwOiBVUkwgd2l0aCBhIHF1ZXJ5IHN0cmlu ZyBtZWFucy4NCg0KT3Igc2VuZGluZyBhIHF1ZXJ5IHRvIGFuIGh0dHAgcmVzb3VyY2Ugd2hpY2gg Y2Fubm90IGhhbmRsZSBpdDogSXQncyBzeW50YWN0aWNhbGx5IE9LIGJ1dCBzZW1hbnRpY2FsbHkg dXNlbGVzcy4NCg0KSWYgbXkgYWJvdmUgcmVhZGluZyBvZiB5b3VyIHByb3Bvc2FsIGlzIHdoYXQg eW91IG1lYW50IGl0IHRvIGJlIEknZCB3aWxsaW5nIHRvIHN1cHBvcnQgdGhhdC4gQSBmaXJzdCBz dGFiICh1c2luZyB3b3JkaW5nIGJ5IEtlaXRoKToNCg0KW1sNCngueSBRdWVyaWVzDQoNClRoaXMg c3BlY2lmaWNhdGlvbiBhZGRzIG5vIHN5bnRhY3RpY2FsIHJlc3RyaWN0aW9uIG9uIHF1ZXJpZXMg YXMgcGFydHMgb2YgVVJOcyBvdGhlciB0aGFuIHRob3NlIHNwZWNpZmllZCBpbiBSRkMgMzk4Ni4g V2hlbiBhIHF1ZXJ5IGlzIGFwcGVuZGVkIHRvIHRoZSBVUk4sIHRoZSBxdWVyeSBpcyB0cmFuc21p dHRlZCB0byB0aGUgcmVzb3VyY2UgbmFtZWQgYnkgdGhlIFVSTi4NCg0KVGhlIGV4YWN0IHNlbWFu dGljcyBvZiB0aGUgcXVlcnkgcGFydCBvZiB0aGUgVVJOIGRlcGVuZHMgb24gdGhlIHR5cGUgb2Yg dGhlIHJlc291cmNlIHRoZSBVUk4gaWRlbnRpZmllcyBhbmQgaXMgYmV5b25kIHRoZSBzY29wZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24uIEl0IHNob3VsZCBiZSBub3RlZCAtLSBob3dldmVyIC0tIHRo YXQgcXVlcmllcyBhcmUgbm90IG1lYW5pbmdmdWwgZm9yIGFsbCByZXNvdXJjZSB0eXBlcyBhbmQg bm90IGNvbXBhdGlibGUgd2l0aCBhbGwgYWNjZXNzIHByb3RvY29sczsgdGhlIGV4YWN0IG1lYW5p bmcgb2YgYSBxdWVyeSBjYW4gb25seSBiZSBkZXRlcm1pbmVkIHdoZW4gdGhvc2UgdHdvIGFyZSBr bm93bi4gQXMgYW4gZXhhbXBsZSwgdXJuOmlzYm46MC0xMjMtNDU2NzgtOT9wYWdlPTEyIG1pZ2h0 IGJlIG1lYW5pbmdmdWwgaWYgdXJuOmlzYm46MC0xMjMtNDU2NzgtOSByZXNvbHZlcyB0byBhIHdl YiBwYWdlIGF0IGh0dHA6Ly9leGFtcGxlLmNvbS9pc2JuLzAtMTIzLTQ1Njc4LTkgYW5kIHRoYXQg aHR0cCByZXNvdXJjZSBpcyBhIHNlcnZpY2UgdGhhdCBjYW4gaGFuZGxlIHF1ZXJpZXMgKGluIHdo aWNoIGNhc2UgcGFnZSAxMiBtaWdodCBiZSBkaXNwbGF5ZWQpLiBJZiAtLSBob3dldmVyIC0tIHVy bjppc2JuOjAtMTIzLTQ1Njc4LTkgaWRlbnRpZmllcyBhIFBERiBkb2N1bWVudCByZXNpZGluZyBh dCBodHRwOi8vZXhhbXBsZS5jb20vaXNibi8wLTEyMy00NTY3OC05LCB0aGUgcXVlcnkgcGFydCAo J3BhZ2U9MTInKSBNVVNUIGJlIHBhc3NlZCBvbiB0byB0aGUgUERGIGRvY3VtZW50IGlkZW50aWZp ZWQgYnkgdGhhdCBVUkkuIFNpbWlsYXJseSwgaWYgdXJuOmV4YW1wbGU6bWJveDptZSBpZGVudGlm aWVzIHRoZSBtYWlsYm94IG1haWx0bzptZUBleGFtcGxlLmNvbSwgdXJuOmV4YW1wbGU6bWJveDpt ZT9zdWJqZWN0PUhlbGxvJXdvcmxkIHdvdWxkIHJlc29sdmUgdG8gbWFpbHRvOm1lQGV4YW1wbGUu Y29tP3N1YmplY3Q9SGVsbG8lMjB3b3JsZCAuDQoNClF1ZXJpZXMgYXMgcGFydHMgb2YgVVJOcyBo YXZlIGhhcyBubyBlZmZlY3Qgb24gcmVzb2x1dGlvbiBhbmQgYXJlIG5vdCB0byBiZSBjb25mdXNl ZCB3aXRoIHF1ZXJpZXMgc2VudCB0byAoaHR0cC1iYXNlZCkgcmVzb2x2ZXJzIGluIG9yZGVyIHRv IGNvbnRyb2wgc2VydmljZSBpbnZvY2F0aW9uLiBUaG9zZSBxdWVyaWVzIGFyZSBub3QgcGFydCBv ZiB0aGUgVVJOIGFuZCBhcmUgZGVhbHQgd2l0aCBpbiBSRkMgMjQ4MyBiaXMuIElmIGEgVVJOIHdp dGggYSBxdWVyeSBpcyBwYXNzZWQgYXMgYW4gYXJndW1lbnQgdG8gYW4gaHR0cC1iYXNlZCByZXNv bHV0aW9uIHNlcnZpY2UsIHRoZSBxdWVyeSBwYXJ0IC0tIGluY2x1ZGluZyB0aGUgaW50cm9kdWN0 b3J5ICc/JyAtLSBvZiB0aGUgVVJOIE1VU1QgYmUgcGVyY2VudC1lc2NhcGVkIGFjY29yZGluZyB0 byB0aGUgcnVsZXMgaW4gUkZDIDM5ODYuDQpdXQ0KDQo+IFRob3VnaCBpdCBkb2VzIG9jY3VyIHRv IG1lIHRoYXQgcGVyaGFwcyB0aGUgcHJlc2VuY2Ugb2YgYSBxdWVyeSBzdHJpbmcNCj4gc2hvdWxk IGFmZmVjdCBVUk4gcmVzb2x1dGlvbiBpbiBvbmUgd2F5OiBpdCBzaG91bGQgcGVyaGFwcyBpbmRp Y2F0ZSBhDQo+IHByZWZlcmVuY2UgdG8gaGF2ZSB0aGUgVVJOIHJlc29sdmVkIHRvIGFuIGluc3Rh bmNlIG9mIHRoZSByZXNvdXJjZSBhbmQNCj4gYWNjZXNzIHByb3RvY29sIHRoYXQgYXJlIGNvbXBh dGlibGUgd2l0aCBxdWVyeSBzdHJpbmdzLg0KDQpXb3J0aCB0aGlua2luZyBhYm91dCB3aGVuIHdl IGdvIG9uIHRvIFJGQyAyNDgzYmlzLg0KDQpbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjA2OA0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+IA0KPiBPbiBNYXkgMjksIDIwMTMsIGF0 IDI6MjUgUE0sIFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+DQo+IHdyb3Rl Og0KPiANCj4gDQo+IA0KPiAJLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KPiAJ SGFzaDogU0hBMQ0KPiANCj4gCU9uIDUvMjkvMTMgMTE6NTEgQU0sIEtlaXRoIE1vb3JlIHdyb3Rl Og0KPiANCj4gDQo+IAkJT24gMDUvMjkvMjAxMyAwMToyNyBQTSwgUGV0ZXIgU2FpbnQtQW5kcmUg d3JvdGU6DQo+IA0KPiANCj4gCQkJLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLSBI YXNoOiBTSEExDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gCQkJT24gNS8yOS8xMyAxMDo1MCBBTSwg S2VpdGggTW9vcmUgd3JvdGU6DQo+IA0KPiANCj4gCQkJCU9uIDA1LzIzLzIwMTMgMDg6NDcgQU0s IFN2ZW5zc29uLCBMYXJzDQo+IHdyb3RlOg0KPiANCj4gDQo+IAkJCQkJQWxsLA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IAkJCQkJSSByZXZpdmUgdGhpcyB0aHJlYWQgYWJvdXQgcXVlcmllcyBpbg0K PiBVUk5zIGFnYWluIHNpbmNlIHdlDQo+IA0KPiANCj4gCQkJCQluZWVkIGEgcmVzb2x1dGlvbiBv biB0aGlzIGluIG9yZGVyIHRvDQo+IHByb2NlZWQgd2l0aA0KPiANCj4gDQo+IAkJCQkJc3RhbmRh cmRpemF0aW9uIGluIG90aGVyIChiaWJsaW9ncmFwaGljKQ0KPiBhcmVhcyBbMV0uDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gCQkJCQlTSE9SVCBWRVJTSU9ODQo+IA0KPiANCj4gDQo+IA0KPiANCj4g CQkJCQlJIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAJCQkJ CTEpIFdlIGRvIG5vdCBhbGxvdyBxdWVyaWVzIGluIFVSTnMsDQo+IHNpbmNlIHRoZXkgb25seSBt YWtlDQo+IA0KPiANCj4gCQkJCQlzZW5zZSBpbiB0aGUgY29udGV4dCBvZiBVUk4NCj4gcmVzb2x1 dGlvbiBzZXJ2aWNlcy4gMikgV2UgZGVmZXINCj4gDQo+IA0KPiAJCQkJCXRoZSBxdWVzdGlvbiBv ZiBob3cgdG8gaGFuZGxlIHF1ZXJpZXMNCj4gaW4gcmVzb2x1dGlvbiBzZXJ2aWNlcw0KPiANCj4g DQo+IAkJCQkJdG8gUkZDMjQ4M2Jpcy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAJCQkJCUlmIHNv bWVvbmUgY2FuIGdpdmUgbWUgYSBjb21wZWxsaW5nDQo+IGNhc2UgZm9yIHRoZSB1c2Ugb2YNCj4g DQo+IA0KPiAJCQkJCXF1ZXJpZXMgaW4gVVJOcyAqb3V0c2lkZSogb2YgVVJODQo+IHJlc29sdXRp b24gc2VydmljZXMsIEknZCBiZQ0KPiANCj4gDQo+IAkJCQkJbW9zdCBoYXBweSB0byBkaXNjdXNz IHRoYXQgYW5kIHRvDQo+IHdpdGhkcmF3IG15IHByb3Bvc2FsLg0KPiANCj4gDQo+IAkJCQkzKSB3 aGVuIGEgcXVlcnkgaXMgYXBwZW5kZWQgdG8gdGhlIFVSTiwgdGhlDQo+IHF1ZXJ5IGlzDQo+IA0K PiANCj4gCQkJCXRyYW5zbWl0dGVkIHRvIHRoZSByZXNvdXJjZSBuYW1lZCBieSB0aGUNCj4gVVJO LiAgSXQgaGFzIG5vIGVmZmVjdA0KPiANCj4gDQo+IAkJCQlvbiByZXNvbHV0aW9uLg0KPiANCj4g DQo+IAkJCUtlaXRoLCBhcmUgeW91IGFncmVlaW5nIHdpdGggKDEpIGFuZCAoMikgYW5kIGFkZGlu Zw0KPiAoMyksIG9yDQo+IA0KPiANCj4gCQkJcHJvcG9zaW5nICgzKSBpbnN0ZWFkIG9mICgxKSBh bmQgKDIpPw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IAkJSSdtIHByb3Bvc2luZyAoMykgaW5zdGVh ZCBvZiAoMSkgYW5kICgyKS4NCj4gDQo+IA0KPiAJCQkJSXQncyBhIHJlYWxseSBCYWQgSWRlYSB0 byBtYWtlIFVSTCBxdWVyeSBzeW50YXgNCj4gbWVhbiBzb21ldGhpbmcNCj4gDQo+IA0KPiAJCQkJ ZGlmZmVyZW50IGZvciBVUk5zIHRoYW4gaXQgZG9lcyBmb3IgVVJMcy4NCj4gDQo+IA0KPiAJCQlQ ZXJzb25hbGx5IEkgdGhpbmsgYWxsb3dpbmcgcXVlcmllcyBpbiBVUk5zIGlzIGEgYmFkDQo+IGlk ZWEsIGJ1dA0KPiANCj4gDQo+IAkJCXRoYXQgcGFzc2luZyBhIFVSTiBhcyBhIHBhcmFtZXRlciB0 byBhIFVSTg0KPiByZXNvbHV0aW9uIHNlcnZpY2UNCj4gDQo+IA0KPiAJCQl3b3VsZCBiZSBmaW5l ICh3aGVyZSB0aGUgIlVSTi1zdHJpbmciIG1pZ2h0IGJlDQo+IGNvbnRhaW5lZCBpbiB0aGUNCj4g DQo+IA0KPiAJCQlxdWVyeSBjb21wb25lbnQgb2YsIHNheSwgYW4gSFRUUCBVUkkgd2hvc2UNCj4g YXV0aG9yaXR5IGNvbXBvbmVudCBpcw0KPiANCj4gDQo+IAkJCXRoZSByZXNvbHV0aW9uIHNlcnZp Y2UpLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IAkJSSBkb24ndCB0aGluayB0aGF0IGl0IG1ha2Vz IHNlbnNlIHRvIGhhdmUgdGhlIHJlc29sdXRpb24NCj4gc2VydmljZQ0KPiANCj4gDQo+IAkJaW50 ZXJwcmV0IHRoZSBxdWVyeSBzdHJpbmcgYXQgYWxsLiAgIElmIHlvdSBkbyB0aGF0IHRoZW4geW91 IGJsb2NrDQo+IA0KPiANCj4gCQl0aGUgYWJpbGl0eSBvZiB0aGUgcmVzb2x2ZWQgcmVzb3VyY2Ug dG8gYWNjZXB0IHF1ZXJ5IHN0cmluZ3MuDQo+IA0KPiANCj4gCQlFaXRoZXIgdGhhdCBvciB5b3Ug aGF2ZSB0byBjcmVhdGUgc29tZSByZWdpc3RyeSBmb3IgcXVlcnkNCj4gDQo+IA0KPiAJCXBhcmFt ZXRlcnMgc28gdGhhdCB0aGUgcmVzb2x1dGlvbiBzZXJ2aWNlIGNhbiB0ZWxsIHdoaWNoDQo+IHBh cmFtZXRlcnMNCj4gDQo+IA0KPiAJCWJlbG9uZyB0byBpdCBhbmQgd2hpY2ggYmVsb25nIHRvIHRo ZSByZXNvdXJjZS4gICBUaGF0IHdheSBsaWVzDQo+IA0KPiANCj4gCQltYWRuZXNzLCBhbmQgaXQn cyB0b28gbGF0ZSB0byB0cnkgdG8gcmVzdHJpY3Qgd2hhdCBraW5kcyBvZg0KPiBxdWVyeQ0KPiAN Cj4gDQo+IAkJcGFyYW1ldGVycyBhIHJlc291cmNlIGNhbiB1c2UuDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gCQlTbyB0aGUgc29sdXRpb246IHN0b3AgdHJ5aW5nIHRvIG92ZXJsb2FkIHRoZSBxdWVy eSBzdHJpbmcgYXMgYQ0KPiB3YXkNCj4gDQo+IA0KPiAJCXRvIGNvbW11bmljYXRlIHByZWZlcmVu Y2VzIHRvIHRoZSByZXNvbHV0aW9uIHNlcnZpY2UuDQo+IA0KPiANCj4gDQo+IAlJIGhhdmUgbm8g b3BpbmlvbnMgd2hhdHNvZXZlciBvbiBob3cgYmVzdCB0byBpbnRlcmFjdCB3aXRoIGENCj4gCXJl c29sdXRpb24gc2VydmljZS4gSWYgYSBzZXJ2aWNlIHByb3ZpZGVyIGxpa2UgcmVzb2x2ZXIuZXhh bXBsZS5jb20NCj4gCXdhbnRzIHRvIHVzZSBodHRwczovL3Jlc29sdmVyLmV4YW1wbGUuY29tP2lu cHV0PXN0cmluZ2lmaWVkLXVybg0KPiB0aGVuDQo+IAl0aGF0J3MgZmluZSB3aXRoIG1lLg0KPiAN Cj4gCU5vdywgYXMgdG8geW91ciBwcm9wb3NhbCAoMyksIGFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0 IHdlIGFsbG93IHF1ZXJ5DQo+IAljb21wb25lbnRzIG9uIFVSTnM/IFdoYXQgZXhhY3RseSBkb2Vz IGl0IG1lYW4gZm9yIGEgcXVlcnkgdG8gYmUNCj4gCXRyYW5zbWl0dGVkIHRvIHRoZSByZXNvdXJj ZSBuYW1lZCBieSB0aGUgVVJOPyBXaGF0IGV4YWN0bHkgaXMgdGhlDQo+IAlyZXNvdXJjZSBpbiwg c2F5LCBVUk46SVNCTjowLTM5NS0zNjM0MS0xIChSRkMgMzE4Nykgb3INCj4gCXVybjpzZXJ2aWNl OnNvcy5maXJlIChSRkMgNTAzMSkgb3INCj4gCXVybjpjYWJsZWxhYnM6cGFja2V0Y2FibGUtZXhh bXBsZTp1ZTpyc3Qtc2FtcGxlIChSRkMgNjI4OSk/DQo+IFBlcmhhcHMNCj4gCWl0J3MganVzdCBt eSBsYWNrIG9mIGltYWdpbmF0aW9uLCBidXQgSSdtIGhhdmluZyBhIGhhcmQgdGltZQ0KPiAJdmlz dWFsaXppbmcgaG93IHdlIHdvdWxkIHBhc3MgYSBxdWVyeSBjb21wb25lbnQgdG8gYSBib3VuZCBi b29rDQo+IGluIGENCj4gCWxpYnJhcnksIHRvIHRoZSBuYW1lIG9mIGFuIFhNTCBuYW1lc3BhY2Us IGV0Yy4NCj4gDQo+IAlQZXRlcg0KPiANCj4gCS0gLS0NCj4gCVBldGVyIFNhaW50LUFuZHJlDQo+ IAlodHRwczovL3N0cGV0ZXIuaW0vDQo+IA0KPiANCj4gCS0tLS0tQkVHSU4gUEdQIFNJR05BVFVS RS0tLS0tDQo+IAlWZXJzaW9uOiBHbnVQRy9NYWNHUEcyIHYyLjAuMTkgKERhcndpbikNCj4gCUNv bW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cDovL2dwZ3Rvb2xzLm9yZw0KPiAJQ29tbWVudDogVXNpbmcg R251UEcgd2l0aCBUaHVuZGVyYmlyZCAtDQo+IGh0dHA6Ly93d3cuZW5pZ21haWwubmV0Lw0KPiAN Cj4gCWlRSWNCQUVCQWdBR0JRSlJwa2dTQUFvSkVPb0dwSkVyeGEycFpRWVFBS0YvT0ZSSjljMUQ5 OEswDQo+IHRmZFV6ZHN4DQo+IAlXOXlDQ0VCWVh2dk9ScWNZY2R2OFQrNW4vWlpYTml4MjlHL0NV S0hxUDZmOUJOVzJLZ2RhbQ0KPiBXa05NQ0lienFUMQ0KPiAJUVlkZjk5ZFljbWt2V28yMVU1VUNi dmcwZEF2b01HblY4M201Ymk1RFJxT002b0Y3N3RGbg0KPiBLdHRWYWpVbm1ILzINCj4gCVFrUGRi R1hob1RxWjFlYklVYmoxU09HZ1NKa0YzczBYaEVYVnFFYWdTVzFOUkNqT0J2bFN0ekNWDQo+IC9n SGVoekNPDQo+IAloaEFMd3VjbXJBU1h2RzRaSDhUbWxXWDF2eVdDUnVsMXh1VUZoQWRXWG1YVHZx aWdkcStODQo+IGh2RjUwN1YrL0NPNg0KPiAJSTQ0TmJDMzE5RCt3ZHMvNVloRkQ3MGFhTUVNOUJx b1RzMStwZFlNUjNqUzdSVVgrVDhGS2VzDQo+IFM4cnQ0U2tKczUNCj4gCWg4RGpNTE50ZGhuOXFF UU9peHlHRU5kL2xLSWJ3QitPQXhHQnppV0kvWHBHSWRDVEtZZnI5K2pwDQo+IDdGMmhFRDYvDQo+ IAlqUEp5YjY3ZnpBVEsyK0dHMFRFaG1rck16T1lGOGRNQWF3TzJBV1pYZDBWQ2ZFbnNIYnVJUmEN Cj4gT09GM1MwRC9kMQ0KPiAJdm9GbHMzM0swUTBISVIwZE1ua2RWK0g4aGxoZml2Smh6QUxERUlV NVhtZ2lZK08rYUtUME8wNm9sQg0KPiA0TkNOZ3ANCj4gCUd0Qk9NWkZCUTVMNGh0NldVVFJCaFVz TXVGUEhkYmNPOGQwL0lYM1JkbmhqL2tSUjNQSzErDQo+IE1qckJPK1YwY24rDQo+IAlZdkVwbzB1 WVFWdWdUM3hpY2pmcmF0WjZWMkZsSERjMVA4clB5Z0RobzVRVzdkUWlGU1NYeUR0K0JFDQo+IHhN UVdnNg0KPiAJdGRKcExUTGI4WTNramJSWjNMdW4NCj4gCT01VzFKDQo+IAktLS0tLUVORCBQR1Ag U0lHTkFUVVJFLS0tLS0NCj4gDQoNCg== From michael@refactored-networks.com Thu May 30 07:20:51 2013 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 8660A21F8F6E for ; Thu, 30 May 2013 07:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60zXimx7k9x1 for ; Thu, 30 May 2013 07:20:45 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5D17321F885A for ; Thu, 30 May 2013 07:20:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D3EE4390005; Thu, 30 May 2013 09:20:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIcWGt3QBbrB; Thu, 30 May 2013 09:20:42 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B1440390058; Thu, 30 May 2013 09:20:42 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9B7D5390086; Thu, 30 May 2013 09:20:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vPMbNSaQ-qwv; Thu, 30 May 2013 09:20:42 -0500 (CDT) Received: from [192.168.0.103] (50-199-114-66-static.hfc.comcastbusiness.net [50.199.114.66]) by smtp-out-2.01.com (Postfix) with ESMTPSA id C723E390005; Thu, 30 May 2013 09:20:41 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Mealling In-Reply-To: Date: Thu, 30 May 2013 10:20:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4D5E983B-B213-4512-8275-EF3A2E522EA0@refactored-networks.com> References: <24637769D123E644A105A0AF0E1F92EFA4345E9D@dnbf-ex1.AD.DDB.DE> To: "Svensson, Lars" X-Mailer: Apple Mail (2.1503) Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:20:51 -0000 (Yes, I'm eavesdropping=85) That language needs to be much clearer when it uses "part of" and = "append to". What is being suggested is that you can include a query = string along with a URN that you can then send to the resource but that = DOES NOT make that query string part of the URN itself. It is a separate = thing. There is no 'query part' to a URN. You can carry around a bag of = characters with the URN that you send to the resource, and you can even = specify a syntax for how you carry them around together, but the query = string is still something that is evaluated by the Resource. So be very very careful about language such as "part of" or "URN with". = URNs stand alone. -MM Michael Mealling Co-Founder Pipefish.com +1-678-640-6884 @mmealling Schedule a meeting: http://meetme.so/michaelmealling On May 30, 2013, at 10:11 AM, "Svensson, Lars" = wrote: > This specification adds no syntactical restriction on queries as parts = of URNs other than those specified in RFC 3986. When a query is appended = to the URN, the query is transmitted to the resource named by the URN. >=20 > The exact semantics of the query part of the URN depends on the type = of the resource the URN identifies and is beyond the scope of this = specification. It should be noted -- however -- that queries are not = meaningful for all resource types and not compatible with all access = protocols; the exact meaning of a query can only be determined when = those two are known. As an example, urn:isbn:0-123-45678-9?page=3D12 = might be meaningful if urn:isbn:0-123-45678-9 resolves to a web page at = http://example.com/isbn/0-123-45678-9 and that http resource is a = service that can handle queries (in which case page 12 might be = displayed). If -- however -- urn:isbn:0-123-45678-9 identifies a PDF = document residing at http://example.com/isbn/0-123-45678-9, the query = part ('page=3D12') MUST be passed on to the PDF document identified by = that URI. Similarly, if urn:example:mbox:me identifies the mailbox = mailto:me@example.com, urn:example:mbox:me?subject=3DHello%world would = resolve to mailto:me@example.com?su > bject=3DHello%20world . >=20 > Queries as parts of URNs have has no effect on resolution and are not = to be confused with queries sent to (http-based) resolvers in order to = control service invocation. Those queries are not part of the URN and = are dealt with in RFC 2483 bis. If a URN with a query is passed as an = argument to an http-based resolution service, the query part -- = including the introductory '?' -- of the URN MUST be percent-escaped = according to the rules in RFC 3986. > ]] >=20 >> Though it does occur to me that perhaps the presence of a query = string >> should affect URN resolution in one way: it should perhaps indicate a >> preference to have the URN resolved to an instance of the resource = and >> access protocol that are compatible with query strings. >=20 > Worth thinking about when we go on to RFC 2483bis. >=20 > [1] http://tools.ietf.org/html/rfc6068 >> Sent from my iPhone >>=20 >> On May 29, 2013, at 2:25 PM, Peter Saint-Andre >> wrote: >>=20 >>=20 >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 5/29/13 11:51 AM, Keith Moore wrote: >>=20 >>=20 >> On 05/29/2013 01:27 PM, Peter Saint-Andre wrote: >>=20 >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 5/29/13 10:50 AM, Keith Moore wrote: >>=20 >>=20 >> On 05/23/2013 08:47 AM, Svensson, Lars >> wrote: >>=20 >>=20 >> All, >>=20 >>=20 >>=20 >>=20 >>=20 >> I revive this thread about = queries in >> URNs again since we >>=20 >>=20 >> need a resolution on this in = order to >> proceed with >>=20 >>=20 >> standardization in other = (bibliographic) >> areas [1]. >>=20 >>=20 >>=20 >>=20 >>=20 >> SHORT VERSION >>=20 >>=20 >>=20 >>=20 >>=20 >> I propose the following: >>=20 >>=20 >>=20 >>=20 >>=20 >> 1) We do not allow queries in = URNs, >> since they only make >>=20 >>=20 >> sense in the context of URN >> resolution services. 2) We defer >>=20 >>=20 >> the question of how to handle = queries >> in resolution services >>=20 >>=20 >> to RFC2483bis. >>=20 >>=20 >>=20 >>=20 >>=20 >> If someone can give me a = compelling >> case for the use of >>=20 >>=20 >> queries in URNs *outside* of URN >> resolution services, I'd be >>=20 >>=20 >> most happy to discuss that and = to >> withdraw my proposal. >>=20 >>=20 >> 3) when a query is appended to the URN, = the >> query is >>=20 >>=20 >> transmitted to the resource named by the >> URN. It has no effect >>=20 >>=20 >> on resolution. >>=20 >>=20 >> Keith, are you agreeing with (1) and (2) and = adding >> (3), or >>=20 >>=20 >> proposing (3) instead of (1) and (2)? >>=20 >>=20 >>=20 >>=20 >>=20 >> I'm proposing (3) instead of (1) and (2). >>=20 >>=20 >> It's a really Bad Idea to make URL query = syntax >> mean something >>=20 >>=20 >> different for URNs than it does for = URLs. >>=20 >>=20 >> Personally I think allowing queries in URNs is a = bad >> idea, but >>=20 >>=20 >> that passing a URN as a parameter to a URN >> resolution service >>=20 >>=20 >> would be fine (where the "URN-string" might be >> contained in the >>=20 >>=20 >> query component of, say, an HTTP URI whose >> authority component is >>=20 >>=20 >> the resolution service). >>=20 >>=20 >>=20 >>=20 >>=20 >> I don't think that it makes sense to have the resolution >> service >>=20 >>=20 >> interpret the query string at all. If you do that then = you block >>=20 >>=20 >> the ability of the resolved resource to accept query = strings. >>=20 >>=20 >> Either that or you have to create some registry for = query >>=20 >>=20 >> parameters so that the resolution service can tell which >> parameters >>=20 >>=20 >> belong to it and which belong to the resource. That = way lies >>=20 >>=20 >> madness, and it's too late to try to restrict what kinds = of >> query >>=20 >>=20 >> parameters a resource can use. >>=20 >>=20 >>=20 >>=20 >>=20 >> So the solution: stop trying to overload the query = string as a >> way >>=20 >>=20 >> to communicate preferences to the resolution service. >>=20 >>=20 >>=20 >> I have no opinions whatsoever on how best to interact with a >> resolution service. If a service provider like = resolver.example.com >> wants to use https://resolver.example.com?input=3Dstringified-urn >> then >> that's fine with me. >>=20 >> Now, as to your proposal (3), are you suggesting that we allow = query >> components on URNs? What exactly does it mean for a query to be >> transmitted to the resource named by the URN? What exactly is = the >> resource in, say, URN:ISBN:0-395-36341-1 (RFC 3187) or >> urn:service:sos.fire (RFC 5031) or >> urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)? >> Perhaps >> it's just my lack of imagination, but I'm having a hard time >> visualizing how we would pass a query component to a bound book >> in a >> library, to the name of an XML namespace, etc. >>=20 >> Peter >>=20 >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - >> http://www.enigmail.net/ >>=20 >> iQIcBAEBAgAGBQJRpkgSAAoJEOoGpJErxa2pZQYQAKF/OFRJ9c1D98K0 >> tfdUzdsx >> W9yCCEBYXvvORqcYcdv8T+5n/ZZXNix29G/CUKHqP6f9BNW2Kgdam >> WkNMCIbzqT1 >> QYdf99dYcmkvWo21U5UCbvg0dAvoMGnV83m5bi5DRqOM6oF77tFn >> KttVajUnmH/2 >> QkPdbGXhoTqZ1ebIUbj1SOGgSJkF3s0XhEXVqEagSW1NRCjOBvlStzCV >> /gHehzCO >> hhALwucmrASXvG4ZH8TmlWX1vyWCRul1xuUFhAdWXmXTvqigdq+N >> hvF507V+/CO6 >> I44NbC319D+wds/5YhFD70aaMEM9BqoTs1+pdYMR3jS7RUX+T8FKes >> S8rt4SkJs5 >> h8DjMLNtdhn9qEQOixyGENd/lKIbwB+OAxGBziWI/XpGIdCTKYfr9+jp >> 7F2hED6/ >> jPJyb67fzATK2+GG0TEhmkrMzOYF8dMAawO2AWZXd0VCfEnsHbuIRa >> OOF3S0D/d1 >> voFls33K0Q0HIR0dMnkdV+H8hlhfivJhzALDEIU5XmgiY+O+aKT0O06olB >> 4NCNgp >> GtBOMZFBQ5L4ht6WUTRBhUsMuFPHdbcO8d0/IX3Rdnhj/kRR3PK1+ >> MjrBO+V0cn+ >> YvEpo0uYQVugT3xicjfratZ6V2FlHDc1P8rPygDho5QW7dQiFSSXyDt+BE >> xMQWg6 >> tdJpLTLb8Y3kjbRZ3Lun >> =3D5W1J >> -----END PGP SIGNATURE----- >>=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From moore@network-heretics.com Thu May 30 07:31:58 2013 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 9D96021F90EF for ; Thu, 30 May 2013 07:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5wMSprsZqRT for ; Thu, 30 May 2013 07:31:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9683C21F91B8 for ; Thu, 30 May 2013 07:30:38 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7BA9520734; Thu, 30 May 2013 10:30:27 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([unixlocal]) by compute4.internal (MEProxy); Thu, 30 May 2013 10:30:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=SzugEexe8kvHQm34RPFFTi fiyBk=; b=SFjfVufWsTABu0d5y7BoYoRIW1nQIAPyCXGrFoiGy8sl2cy9kxaW8E YpgZFuE+H/czrvliBDPKSNS+pUGGLvqtPJ1rzrKiJYt5RsKWSfB+XL5KtJUuD0WM ZehOPu3Zn2rao90oz/BgISbgfp/Cw4DPjsFJBydYQWBk4sqhTgrCc= X-Sasl-enc: MYOlObkwXlb2E4c88wBKqJnwtKiaKrDoNkQg2IfLIFhg 1369924226 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F2AD20032A; Thu, 30 May 2013 10:30:26 -0400 (EDT) Message-ID: <51A7625A.1060006@network-heretics.com> Date: Thu, 30 May 2013 10:29:46 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EFA4345E9D@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4345E9D@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "urn@ietf.org" Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:31:59 -0000 On 05/30/2013 10:11 AM, Svensson, Lars wrote: >>> Now, as to your proposal (3), are you suggesting that we allow query >>> components on URNs? What exactly does it mean for a query to be >>> transmitted to the resource named by the URN? What exactly is the res= ource >>> in, say, URN:ISBN:0-395-36341-1(RFC 3187) or urn:service:sos.fire (RF= C 5031) >>> or urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)? >> >> If any of those URNs resolves to a resource for which query strings ha= ve >> meaning (note that this can change over time), the URN with the query = string >> appended means whatever it means to access that resource using that qu= ery >> string. > Just to make sure I understand it correctly: > > Say I create a URN for my mailbox: urn:example:mbox:lars which resolves= to lars@example.com . Then urn:example:mbox:lars?subject=3DHi%20there&bo= dy=3DHello%20world would resolve to lars@example.com?subject=3DHi%20there= &body=3DHello%20world (which is OK according to rfc 6068 [1]) > =20 >> Of course, query strings aren't meaningful for all resource types and = not >> compatible with all access protocols. > Very true. > >> To ask what a URN with a query string >> appended if the resource or access protocol don't support query string= s is a >> bit like asking what an ftp: URL with a query string means. > Or sending a query to an http resource which cannot handle it: It's syn= tactically OK but semantically useless. > > If my above reading of your proposal is what you meant it to be I'd wil= ling to support that. Your above reading seems to me to be consistent with what I'm proposing. > A first stab (using wording by Keith): > > [[ > x.y Queries > > This specification adds no syntactical restriction on queries as parts = of URNs other than those specified in RFC 3986. When a query is appended = to the URN, the query is transmitted to the resource named by the URN. > > The exact semantics of the query part of the URN depends on the type of= the resource the URN identifies and is beyond the scope of this specific= ation. It should be noted -- however -- that queries are not meaningful f= or all resource types and not compatible with all access protocols; the e= xact meaning of a query can only be determined when those two are known. = As an example, urn:isbn:0-123-45678-9?page=3D12 might be meaningful if ur= n:isbn:0-123-45678-9 resolves to a web page at http://example.com/isbn/0-= 123-45678-9 and that http resource is a service that can handle queries (= in which case page 12 might be displayed). If -- however -- urn:isbn:0-12= 3-45678-9 identifies a PDF document residing at http://example.com/isbn/0= -123-45678-9, the query part ('page=3D12') MUST be passed on to the PDF d= ocument identified by that URI. Similarly, if urn:example:mbox:me identif= ies the mailbox mailto:me@example.com, urn:example:mbox:me?subject=3DHell= o%world would resolve to mailto:me@example.com?subject=3DHello%20world . > > Queries as parts of URNs have has no effect on resolution and are not t= o be confused with queries sent to (http-based) resolvers in order to con= trol service invocation. Those queries are not part of the URN and are de= alt with in RFC 2483 bis. If a URN with a query is passed as an argument = to an http-based resolution service, the query part -- including the intr= oductory '?' -- of the URN MUST be percent-escaped according to the rules= in RFC 3986. > ]] Except that I am not sure that I would say "have no effect on resolution"= =2E But again, even without bringing URNs into the picture, we have the=20 issue with HTTP content negotiation that a query string or a fragment=20 identifier can mean different things depending on the type of document=20 that is negotiated. Presumably the burden is on whoever runs the HTTP = server to make sure that query strings and fragment identifiers are=20 consistently interpreted in the face of content negotiation. Should=20 the burden similarly be on whoever maintains the URN resolution and=20 resource servers for a URN to make sure that query strings and fragment=20 identifiers are consistently interpreted in the face of URN=20 resolution? I'm not entirely comfortable with the idea, but I'm not=20 sure that I have a better answer. The alternative - that URN=20 resolutions should be made with an awareness of fragment identifiers and = query strings - seems similarly unappealing. Keith From stpeter@stpeter.im Thu May 30 21:16:03 2013 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 C3B5921F9997 for ; Thu, 30 May 2013 21:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oth-erI-sfjv for ; Thu, 30 May 2013 21:15:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 842B621F9994 for ; Thu, 30 May 2013 21:15:58 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D9DEF41111; Thu, 30 May 2013 22:28:50 -0600 (MDT) Message-ID: <51A823FC.9020105@stpeter.im> Date: Thu, 30 May 2013 22:15:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EFA4345E9D@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4345E9D@dnbf-ex1.AD.DDB.DE> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 04:16:03 -0000 On 5/30/13 8:11 AM, Svensson, Lars wrote: >>> Now, as to your proposal (3), are you suggesting that we allow >>> query components on URNs? What exactly does it mean for a query >>> to be transmitted to the resource named by the URN? What exactly >>> is the resource in, say, URN:ISBN:0-395-36341-1(RFC 3187) or >>> urn:service:sos.fire (RFC 5031) or >>> urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)? >> >> >> If any of those URNs resolves to a resource for which query strings >> have meaning (note that this can change over time), the URN with >> the query string appended means whatever it means to access that >> resource using that query string. > > Just to make sure I understand it correctly: > > Say I create a URN for my mailbox: urn:example:mbox:lars which > resolves to lars@example.com . Then > urn:example:mbox:lars?subject=Hi%20there&body=Hello%20world would > resolve to lars@example.com?subject=Hi%20there&body=Hello%20world > (which is OK according to rfc 6068 [1]) I'm confused by this example. Why do we have a URN for your mailbox when mailto:lars@example.com is already a perfectly acceptable URI? And can we even claim that it's possible to have a persistent, location-independent identifier for something as transient as a particular person's email inbox at a particular email service provider? >> Of course, query strings aren't meaningful for all resource types >> and not compatible with all access protocols. > > Very true. > >> To ask what a URN with a query string appended if the resource or >> access protocol don't support query strings is a bit like asking >> what an ftp: URL with a query string means. > > Or sending a query to an http resource which cannot handle it: It's > syntactically OK but semantically useless. > > If my above reading of your proposal is what you meant it to be I'd > willing to support that. A first stab (using wording by Keith): > > [[ x.y Queries > > This specification adds no syntactical restriction on queries as > parts of URNs other than those specified in RFC 3986. When a query is > appended to the URN, the query is transmitted to the resource named > by the URN. I agree with Michael that we need to be very, very careful about what we mean here. As stated, personally I would prefer not to make query components part of URNs, or to append query components to URNs themselves. If you want to pass a query component to a resolution service (e.g., via an HTTP URI for the resolution service), that's something quite different and it seems fine to me. > The exact semantics of the query part of the URN depends on the type > of the resource the URN identifies and is beyond the scope of this > specification. It should be noted -- however -- that queries are not > meaningful for all resource types and not compatible with all access > protocols; the exact meaning of a query can only be determined when > those two are known. As an example, urn:isbn:0-123-45678-9?page=12 > might be meaningful if urn:isbn:0-123-45678-9 resolves to a web page > at http://example.com/isbn/0-123-45678-9 and that http resource is a > service that can handle queries (in which case page 12 might be > displayed). If -- however -- urn:isbn:0-123-45678-9 identifies a PDF > document residing at http://example.com/isbn/0-123-45678-9, the query > part ('page=12') MUST be passed on to the PDF document identified by > that URI. Similarly, if urn:example:mbox:me identifies the mailbox > mailto:me@example.com, urn:example:mbox:me?subject=Hello%world would > resolve to mailto:me@example.com?subject=Hello%20world . > > Queries as parts of URNs have has no effect on resolution and are not > to be confused with queries sent to (http-based) resolvers in order > to control service invocation. Those queries are not part of the URN > and are dealt with in RFC 2483 bis. If a URN with a query is passed > as an argument to an http-based resolution service, the query part -- > including the introductory '?' -- of the URN MUST be percent-escaped > according to the rules in RFC 3986. ]] I am still confused and indeed mystified as to why the URNs need to have query components, as opposed to URIs at which URNs are resolved. Am I just dense, or has this not been explained very clearly by the proponents? >> Though it does occur to me that perhaps the presence of a query >> string should affect URN resolution in one way: it should perhaps >> indicate a preference to have the URN resolved to an instance of >> the resource and access protocol that are compatible with query >> strings. > > Worth thinking about when we go on to RFC 2483bis. I fully agree, but I would put it this way: query components are worth thinking about in relation to resolution, but not in relation to the core definition of URNs. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba.mailing.lists@gmail.com Fri May 31 12:23:48 2013 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 DC8EC21F8F0C for ; Fri, 31 May 2013 12:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.377 X-Spam-Level: X-Spam-Status: No, score=-100.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxa8Q2PxKxlg for ; Fri, 31 May 2013 12:23:43 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7A721F8E89 for ; Fri, 31 May 2013 12:23:40 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gd11so1313433vcb.25 for ; Fri, 31 May 2013 12:23:36 -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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2+qOvF8f42Q376eQsjxDxhxiDuabI2u1k04PeOU6VPM=; b=EqtObb0Yw8iZn9uflusHF4oBw5xFsQQnzrkeUFQS/ETF8kH8IEBaWrI26+Vp/MnfW5 b8KCh6h3zPchTpUJhYhAFiuWtQRqaNhNXgSwiDJE55HOj7ko1YfmRh0sL1AP0pRnemiU 0qj4AhgqbxDEi03lK7EfzCL/qoHzWrk0bS49HUbQehcvTb1NfDBDnYy3/ke6xILCrcKP 7asHjsVXlu2sVwzq2fwADIyRgqghHVFNPENt8js6DVJPuaEAygFZX1w9AEERik3XIF1Q Ni9Ne/oSwRAz1UgO424PDnzvVy2QDcLAfYeyFyk5/doDmujO7eVZpwqkIq1YLbOgPCIK XoDw== MIME-Version: 1.0 X-Received: by 10.58.106.77 with SMTP id gs13mr11618727veb.22.1370028216469; Fri, 31 May 2013 12:23:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Fri, 31 May 2013 12:23:36 -0700 (PDT) In-Reply-To: <51A63A9D.8070503@stpeter.im> References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> Date: Fri, 31 May 2013 15:23:36 -0400 X-Google-Sender-Auth: VOWytTiZuk4l-Z0NxFQaUqVFlJk Message-ID: From: Barry Leiba To: Peter Saint-Andre , L.Svensson@dnb.de Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 19:23:49 -0000 >> On 05/23/2013 08:47 AM, Svensson, Lars wrote: >>> I revive this thread about queries in URNs again since we need a >>> resolution on this in order to proceed with standardization in >>> other (bibliographic) areas [1]. I've been meaning to comment on this thread, with my AD hat *off*, for a while. I'd better get to it: >>> 1) We do not allow queries in URNs, since they only make sense in >>> the context of URN resolution services. 2) We defer the question >>> of how to handle queries in resolution services to RFC2483bis. Keith proposes a third option: >> 3) when a query is appended to the URN, the query is transmitted to >> the resource named by the URN. It has no effect on resolution. >> It's a really Bad Idea to make URL query syntax mean something >> different for URNs than it does for URLs. > > Personally I think allowing queries in URNs is a bad idea, but that > passing a URN as a parameter to a URN resolution service would be fine > (where the "URN-string" might be contained in the query component of, > say, an HTTP URI whose authority component is the resolution service). My thoughts: (1) Queries and fragments are valid URI syntax, and URNs are URIs. It seems reasonable to syntactically allow them in URNs, if we can agree on what they semantically mean. (2) I see a very strong use case for fragments, and would strongly support having fragments in the *name* (regardless of resolution). For example, if a book has an ISBN URN such as this: urn:isbn:666-0-123-45678-9 ...then it reasonable and useful to be able to refer to, say, Chapter 5 in that book this way: urn:isbn:666-0-123-45678-9#chapter=5 ...or to Part 2: urn:isbn:666-0-123-45678-9#part=2 ...or, if it's a play, to Act III, Scene 2: urn:isbn:666-0-123-45678-9#act=III;scene=2 Now, whether that should be done with a fragment (my preference) or a query is up for argument, and forgive any clumsy syntax in the examples above -- they're to get the point across, and I haven't checked them. (3) Other than as a substitute for fragment in (2) above, I don't see a use case for a query part being part of the *name* of a thing. That said, it's entirely possible that there are things I haven't thought of that could seriously benefit from it, and I'd probably prefer to avoid ruling them out. (4) Looking at Lars's example and PSA's response to it: >> Say I create a URN for my mailbox: urn:example:mbox:lars which >> resolves to lars@example.com . Then >> urn:example:mbox:lars?subject=Hi%20there&body=Hello%20world would >> resolve to lars@example.com?subject=Hi%20there&body=Hello%20world >> (which is OK according to rfc 6068 [1]) > > I'm confused by this example. Why do we have a URN for your mailbox when > mailto:lars@example.com is already a perfectly acceptable URI? And can > we even claim that it's possible to have a persistent, > location-independent identifier for something as transient as a > particular person's email inbox at a particular email service provider? I would think that such a URN wouldn't be the same as the mailto: URI, and wouldn't be a persistent name for a specific email box. Rather, I'd think that such a URN would be a name for "Lars Svensson's primary mailbox", wherever that lives, and it seems like a reasonably useful thing to me, actually. Assuming the uniqueness of identifiers could be dealt with, the idea would be that urn:example:mbox:lars would *name* (not locate!) Lars Svensson's mailbox, and if it's given to an "I want to send mail there" service it would be turned into something like "mailto:L.Svensson@dnb.de" today, but might be "mailto:larslarslars@example.com" tomorrow. But if it's given to an "I want to access this mailbox" service, it might instead resolve to an imap: URL, or to an http: URL for a webmail service. Adding to that, the fragment could then get us to a folder within the mail store: urn:example:mbox:lars#inbox or urn:example:mbox:lars#ietf%20stuff ...and a query could do what Lars suggested, selecting messages with a certain subject. Though once we get beyond naming the mailbox / folder, we're arguably out of the realm of *names*, so it's not clear whether having the query makes sense or not. Am I all wet here? Or is there some dry land on which to have discussion? Barry