From nobody Sun Nov 1 15:35:44 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683641B3A6E for ; Sun, 1 Nov 2015 15:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y-_IMRmDBVe for ; Sun, 1 Nov 2015 15:35:42 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511AA1B3A75 for ; Sun, 1 Nov 2015 15:35:42 -0800 (PST) Received: by oies66 with SMTP id s66so85906587oie.1 for ; Sun, 01 Nov 2015 15:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=1b56sIB2zCG1NXesShfDlMzjY6u+pNJHK8Hg/NhJGyU=; b=aZlgv1TkVC0MD+LFdxWcgk49bTvYLa3eI/F0y4Xqt3au061+GAwX3B1NQAGdg9U8H7 W9WL9zQRYRaW1RBhHvAOcp1N9PhlCESelMsAm/Fgm2TSDrUjxQ4FkeRwIDDcRedPHHSP s+rndShqAfGyUPftrW21Oetu3hWZSwijSKDb2IAmJiFy19M8uUZ8xAH3KX6hKrE+/qEH Fz6sRJtti1epMntpZ5lyxJ8yWf7bUwI3pHJ97lKA/Cv24aYvv7OflUyklmnYIwTkZkBU m6W0CXzSJNHsBvE5YvIhrjHO1Wflvo5hELOvUM6kTf54LSFJ7vQKLTJAHKx2kruEeGTJ 0xEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=1b56sIB2zCG1NXesShfDlMzjY6u+pNJHK8Hg/NhJGyU=; b=hlFWaBC+S5MtyhfMv7NN40zWIxn13ua35lPoSexMyea4knOvMfVio7ohICfZiHdisk b4dM5kuT4w8JRJcaEuLhesektLm0SpckOyG592+Y7ajzI9fnuZRxEz5RIhIxk4SbKW+0 cxuGD8KhkK99pKO1vzuoaYaPrYFNwJRa45Fb4jQNOPL1ZxZ1/3yHg1Eh+U2ANtBQBjyi 9OJaHpq8YEMd7X7PCSqO6I3GtjqihVipSk3kY56JQPnSG2GCku8z4OCG3mV0rfaS+r5p 9fGAe374vSriAWcCbsM08Bwof+7DMG10DamQo7re58m1S7YSkJ5SQNBTuA7HPObWOH/S /wAA== X-Gm-Message-State: ALoCoQk77w9ecVbznSSps2oHfwNs0KblwTjVugASbl2EQTXWHS4rH2AC2hvk0kJVy33MuK7h0V6U X-Received: by 10.202.200.140 with SMTP id y134mr11879183oif.5.1446420941637; Sun, 01 Nov 2015 15:35:41 -0800 (PST) Received: from aither.local ([2601:282:4201:ef5b:68a6:6e5b:f422:66c2]) by smtp.googlemail.com with ESMTPSA id a134sm4227841oih.17.2015.11.01.15.35.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 15:35:40 -0800 (PST) To: John C Klensin , Sean Leonard References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> From: Peter Saint-Andre Message-ID: <5636A1CC.40604@andyet.net> Date: Sun, 1 Nov 2015 16:35:40 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] discard q-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 23:35:43 -0000 On 10/31/15 10:01 AM, John C Klensin wrote: > I think we are at a fork in the virtual road. On one path, we > just figure out how to make separate q- and r-components work, > making sure that 2141bis contains appropriate qualifying > language. On the other, we take a more extreme version of > Keith's "URNA" proposal, depreciate URNs as having gotten just > much too confused and now representing a bad combination of > incompatible concepts, and then start efforts to define a new > set of typologies for generic name-type things that may or may > not define or point to resources. Or we can stand in the road, > looking at the fork, and either jumping from one foot to the > other or running in small circles until some truck comes along > and puts an end to the discussion. I say we take the first path: let's make q- and r-components work and finish 2141bis. Peter From nobody Sun Nov 1 15:38:43 2015 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3431B3AAA; Sun, 1 Nov 2015 15:38:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151101233833.2570.99597.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 15:38:33 -0800 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-14.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 23:38:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-14.txt Pages : 33 Date : 2015-11-01 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 1 15:40:29 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA84D1A1B46 for ; Sun, 1 Nov 2015 15:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfFumap-4tRi for ; Sun, 1 Nov 2015 15:40:19 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E931A0121 for ; Sun, 1 Nov 2015 15:40:19 -0800 (PST) Received: by oiad129 with SMTP id d129so86429830oia.0 for ; Sun, 01 Nov 2015 15:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=DqQiu68A4m0muMZ9eLVNQd5uv7089WmI91xmp5sJ+hA=; b=aoKZx41L+8VG1nFkgUeYlgX5NNTolcEVQEA8wLI6st0J8IcBskJ0o5Q4tFxNB8D60r DAL++TmAYeW9Wb9bdJV0boFvDPxcmVnUVQXlAMwNEQ0VCtt37HlIx1mHBqcNtFBDpvG3 eB3ooSJ4Ur+7mj3+A1VjCRzUlNPQHLpNy+6gJUbncWDKBM5zx6HkMy8R3/cytAIXawLU 3JuLrA4PEGqlBVt04y2hz+HMsP1SAZvZlipyRh9riuFwiTkx6GzLqJUfy2+0xO0L2nJM nK6/K5hQaxEVPHdW7BLIwKhXimOPZZfKcwGMHhds7LB2ZC55Ho6zYxl/bOzCFJkI7T2R i5Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=DqQiu68A4m0muMZ9eLVNQd5uv7089WmI91xmp5sJ+hA=; b=SH0BsHNhsJYzrTkbeIILgkEgO7UOeiU1euR9dQHir6QlEzulSQTCOIJNFN2eMxEYmY EioXwUCAjFhGNWuzjXrb1vujpkjoNQ8icQUuOONipjM0PlDxaS3C4dsTSgxfBQ1yLjaL KrEb/wVG7Vx7370FkYOJqQBIfikNobpfZo64+twNjVD2Qy+EjpHWZ6BOyaxlNp/uNhjZ I0EaUqzExwOcK4XUNMKlp02eFXbhIJnJqMFeFQIixqLk3FMX4J3bGPE/+jtDew6r6nBA Abx11CEOB3b0M3E6P7qFG3gWPtKmzPOoq3i0Stqxlf8uwBkIopo7SgNsVkofLdwQFReX op+A== X-Gm-Message-State: ALoCoQkXZNM51Uw5ExU+e1XapMOSXElRrBAbRGZVkKLp3PIlBr4vwa66eQyYpqLija1eLUMhIDHr X-Received: by 10.202.215.136 with SMTP id o130mr11901515oig.85.1446421219179; Sun, 01 Nov 2015 15:40:19 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id u8sm6632331obf.5.2015.11.01.15.40.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 15:40:18 -0800 (PST) To: "urn@ietf.org" From: Peter Saint-Andre Message-ID: <5636A2E2.90209@andyet.net> Date: Sun, 1 Nov 2015 16:40:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 23:40:25 -0000 I've just submitted version -14, reflecting John's proposed text and list discussion since -13. If you have comments, please send them along as soon as you can. Extra points if you send proposed text. Let's get this done! Peter From nobody Sun Nov 1 15:49:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CDF1B3B02 for ; Sun, 1 Nov 2015 15:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwSNg4DcMxY3 for ; Sun, 1 Nov 2015 15:49:33 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BF71B3B01 for ; Sun, 1 Nov 2015 15:49:33 -0800 (PST) Received: by pacfv9 with SMTP id fv9so133970398pac.3 for ; Sun, 01 Nov 2015 15:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=VJRFCJlwyjmfN8ehipaA9O9AYuvzb46Jc/9loaIHiiI=; b=miqGBgUulCOYXqf/U8rfmM+6oyHPBQKIuex7Fzu3+VUrBRZr9jriy8dtbmxbFvwbHY TEMAzuWNKSgIMrpk70GK+ycPvI7wFx3L14VikueOFTRxgKIqt7pIoWQuj8cKeCuMmLA9 MR4eYtysLTcL8Waep4H7KIN7lvdv7r55XTyl716OhbGcBILaxYUm6lTr7brkve5s4oJm C24XhlzMojymNUeK2/64vKZtr1MR/GRdmH8q9zERZ5RdZgTLSO+dxUGHb2ah0OIQ1LLB eUP3uL25ZEQIECP5M+cQuJSxozbckCkRGFzKK5ewM1ptEuM4Y60cm9+VC9f2EnPhLqBq pAuw== X-Received: by 10.68.179.101 with SMTP id df5mr23432777pbc.73.1446421773398; Sun, 01 Nov 2015 15:49:33 -0800 (PST) Received: from ?IPv6:2001:c40::3032:e4b3:76c0:f161:fa36? (t20010c4000003032e4b376c0f161fa36.v6.meeting.ietf94.jp. [2001:c40:0:3032:e4b3:76c0:f161:fa36]) by smtp.gmail.com with ESMTPSA id nu5sm20270206pbb.65.2015.11.01.15.49.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 15:49:32 -0800 (PST) To: Peter Saint-Andre , "urn@ietf.org" References: <5636A2E2.90209@andyet.net> From: Melinda Shore Message-ID: <5636A50D.3000700@gmail.com> Date: Mon, 2 Nov 2015 08:49:33 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5636A2E2.90209@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 23:49:34 -0000 Thank you, Peter! All: please review the document and get comments to the list. Let's get this pushed along, and maybe, perhaps, we can get this into wglc in 2015. Thanks, Melinda From nobody Sun Nov 1 19:16:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85F71B43FF for ; Sun, 1 Nov 2015 19:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NKWR_jWuuRj for ; Sun, 1 Nov 2015 19:16:16 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9561B4400 for ; Sun, 1 Nov 2015 19:16:16 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 55BBD20543 for ; Sun, 1 Nov 2015 22:16:15 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 01 Nov 2015 22:16:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sCeklxShXc9EUDY j6GRaw4uSn/U=; b=f9ewjj6sOEGTUF3W3EJlW6do8K3482IwNi/g8h1qhTidDAy nd+j0w4TxoOVNUBxRNxkjfRpkEqWo6lFxmS2vgcBIbxgiUC5Rp0OmFYVzUH4SetM 5pwOi1SrovIUVY5ynQdiVnfpLaujSDdXEAYnZk1VB7P9H6hxsDjQitW6f48o= X-Sasl-enc: SKa38XEqTC12I4w/51ma0Us2Xn1nY0MFYq2caBM7q3cU 1446434175 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id E16FB680099; Sun, 1 Nov 2015 22:16:14 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> From: Keith Moore Message-ID: <5636D564.8060009@network-heretics.com> Date: Sun, 1 Nov 2015 22:15:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5636A50D.3000700@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:16:17 -0000 On 11/01/2015 06:49 PM, Melinda Shore wrote: > Thank you, Peter! > > All: please review the document and get comments to the list. > Let's get this pushed along, and maybe, perhaps, we can get this > into wglc in 2015. When the few active participants on this list can't even agree on the purpose of URNs, pushing for WGLC seems very premature. Keith From nobody Sun Nov 1 19:26:26 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D111B329D for ; Sun, 1 Nov 2015 19:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3bS2wc1ESii for ; Sun, 1 Nov 2015 19:26:23 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC921B329B for ; Sun, 1 Nov 2015 19:26:23 -0800 (PST) Received: by oifu63 with SMTP id u63so88962086oif.2 for ; Sun, 01 Nov 2015 19:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=zddfKmnLOD93pPTD8eiRDCSG0gbShR73FaQ+GOUrfOw=; b=R9j/bfZtijyuSiOliFAGADR2v5F+rYc5+yEiIbcKzYeOfUOC0GDrTZa7h5Z+B8EJPh YTg3xYg+0ZRZdG+pWj9MjOYSwLlOpy/Yf0kK6vmg9wkNYVkCjryVRdIXBjvQCL0hVoJO qpzOhed4z4vBGsD7aXh2vUoYPRmGAXw9SRejYaXrtaNBOJZriuRGfzEAZdaSmqOdSGyP FLTbYiZwd4sWEUFcAp6PaANQqdXD6c3jw+PVbtRetn2WhE1Yj/RkHd1O/gNHKEBLZ2Hh NPgJWdNhK3XmDLcoUR6j1A2Tltz3uPcBD9i7UT0qEEr9fdJdVvX26b7MnfvB0x78pE4N 4cAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=zddfKmnLOD93pPTD8eiRDCSG0gbShR73FaQ+GOUrfOw=; b=FBn1/pp4TFGtHyqLi0hbHvO93WkwXgZxuN32JwOuN0Pl3yRcG5Mr7bcb6EaJR+NIEl Bg+Fz+6QjzjepzLPUSLnSx6kOU3dP2k9kqJzHXqdLKDlpywf8HdSnVkAFpbz23GJ07qR kXM9QZXEdjriQGWevTEHwlKmw/o9wjOQny9zgBKzVqjtLX1yZyp9UWHvIBsH70KfFX5w ftJprWR8iJXbtFSfhXms3gl3b7QOZyCgEKhV/US6LqWbquWIhkVMitw20yiAjzMEPxDa X1OeYgfHggv4UwyxxTKR9KcDtPKC8dvwWHZOmdgaRGIvWPkOffENVEuQFLnX/AFURNzy LP+g== X-Gm-Message-State: ALoCoQm8shFVzFjsbAyLR34rkYteWTag4OCIl8Y712ngXVGHpT3vH7jleEPPPEp5zzw/+bubIyIG X-Received: by 10.202.212.74 with SMTP id l71mr12134290oig.54.1446434783174; Sun, 01 Nov 2015 19:26:23 -0800 (PST) Received: from aither.local ([2601:282:4201:ef5b:87:2ae:6b28:a9bd]) by smtp.googlemail.com with ESMTPSA id k8sm8171232oia.10.2015.11.01.19.26.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 19:26:21 -0800 (PST) To: Keith Moore , urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> From: Peter Saint-Andre Message-ID: <5636D7DD.2040906@andyet.net> Date: Sun, 1 Nov 2015 20:26:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5636D564.8060009@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:26:25 -0000 On 11/1/15 8:15 PM, Keith Moore wrote: > On 11/01/2015 06:49 PM, Melinda Shore wrote: >> Thank you, Peter! >> >> All: please review the document and get comments to the list. >> Let's get this pushed along, and maybe, perhaps, we can get this >> into wglc in 2015. > > When the few active participants on this list can't even agree on the > purpose of URNs, pushing for WGLC seems very premature. If that's the case, we might as well close the WG now. Perhaps I'm deluding myself, but I tend to think the disagreements here aren't as serious as they might first appear, and that participants are not all that far apart when it comes to the actual text of the spec. Peter From nobody Sun Nov 1 19:39:03 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7BD1ACEEA for ; Sun, 1 Nov 2015 19:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsB8StsMB5em for ; Sun, 1 Nov 2015 19:38:53 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4E61ACF54 for ; Sun, 1 Nov 2015 19:38:53 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CA7EF205F8 for ; Sun, 1 Nov 2015 22:38:52 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 01 Nov 2015 22:38:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=BPxGX/rIw2H8jgv Ye0wF1CjMW9M=; b=FgYjQPL0Srg+Zywi0iqSAxRqbw8KZI++d/FiCElZUOJb4f+ 8IbNpJImDC3XpVfanDgIoQrpc/IUaBL/GZz5ti/m0//U8KjFpiCgQjag0hTQmcbQ UK4w8AiqvvmZGNQk+rTefClrRDSHbD90a4afp+KpjTU0D4Ln71OvGSIIay5k= X-Sasl-enc: myG2gPoABAWgxaU4B4tp1H76mJ0uGmO0rjDDSsGOOs6U 1446435532 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 43D9A680099; Sun, 1 Nov 2015 22:38:52 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> From: Keith Moore Message-ID: <5636DAB2.8000002@network-heretics.com> Date: Sun, 1 Nov 2015 22:38:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5636D7DD.2040906@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:38:59 -0000 On 11/01/2015 10:26 PM, Peter Saint-Andre wrote: > On 11/1/15 8:15 PM, Keith Moore wrote: >> On 11/01/2015 06:49 PM, Melinda Shore wrote: >>> Thank you, Peter! >>> >>> All: please review the document and get comments to the list. >>> Let's get this pushed along, and maybe, perhaps, we can get this >>> into wglc in 2015. >> >> When the few active participants on this list can't even agree on the >> purpose of URNs, pushing for WGLC seems very premature. > > If that's the case, we might as well close the WG now. > > Perhaps I'm deluding myself, but I tend to think the disagreements > here aren't as serious as they might first appear, and that > participants are not all that far apart when it comes to the actual > text of the spec. I suspect that the current text is very close to being what we need, but what's left unsaid or misstated by the current text (even if only slightly) is of huge importance. I think we need to produce some detailed examples of how we expect URNs to work. Maybe they don't end up in the document (or maybe in a separate informational document) but those examples might expose significant disagreements or ambiguities in 2141bis that we need to resolve. Keith From nobody Sun Nov 1 20:26:02 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154131B44DB for ; Sun, 1 Nov 2015 20:26:01 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4nYpH_MVxAj for ; Sun, 1 Nov 2015 20:25:57 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42161B44BC for ; Sun, 1 Nov 2015 20:25:57 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DA8D6208C2 for ; Sun, 1 Nov 2015 23:25:56 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 01 Nov 2015 23:25:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yaRa+mm8OUztGmE 0+ItkeFBNd1E=; b=mhWofPTSJItrgS+Rg7oY5hejavek+stXVjNNLSYQPUPqebO vuzaagRPd5UkQUans/f3Ep4Nomyhs/83r4T5Acm0n8oh7yJHs+m92U4WXiySFen/ K/a5Alvb6ftxUVP7viNfbD2V1WdVcxjfqqngeew/FB6ITvxzxteAWnww4tU8= X-Sasl-enc: BFpY8/XEC7P7XrLGPgSSF/L+KWWXCVcuHqUUqlEmSmIQ 1446438356 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 69807C013FE; Sun, 1 Nov 2015 23:25:56 -0500 (EST) To: urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> From: Keith Moore Message-ID: <5636E5BB.9070909@network-heretics.com> Date: Sun, 1 Nov 2015 23:25:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 04:26:01 -0000 On 10/27/2015 07:20 AM, Hakala, Juha E wrote: > Hello, > > Usually it will be enough to have just r- or q-component in the URN string. That is, normally resolution related parameters are passed either to the URN resolver or to the target system, but not to both of them at the same time. I agree with this statement, or at least I suspect the interaction between r- and q-component is not well-understood at this time. For instance, if the r-component selects between several alternative representations of a resource, the interpretation of the q-component (or f-component) could vary from one representation to another. > If a user wants for instance metadata about the identified resource, the request can be made either with an r-component or with a q-component. In the former case the r-component specifies the requested resolution service, and it is up to the resolver to turn that into a URI that will be accepted by the target system. In the latter case, q-component must contain a string the target will be able to deal with without conversion by the URN resolver. So for a hypothetical ISTC (International Standard Text Code) A02-2009-000004BE-A there could be URN (provided that namespace ISTC has been registered): > > URN:ISTC:A02-2009-000004BE-A > > We can then add an r-component indicating that the user wants Dublin Core metadata about this work > > URN:ISTC:A02-2009-000004BE-A??s=I2C&p=DC > > A URN resolver might map this URN into e.g. > > http://lx2.loc.gov:210/lcdb?version=1.1&operation=searchRetrieve&query=A02-2009-000004BE-A&recordSchema=dc > > which is an SRU (http://www.loc.gov/standards/sru/index.html ) search to be sent to the SRU server in the Library of Congress (the search does not work since ISTC in the example is not real). Whenever protocol version or the address of the target system changes, the URN resolver URN to SRU mapping must be updated accordingly. But r-component will remain the same, and is therefore more persistent than the q-component. This is an interesting example, and I hope an atypical one. Ideally the URN resolver would itself perform the search and return either the resource content itself (if its static), one or more URLs of the actual resource, or (when applicable) URNs of specific instances/versions/manifestations of the resource named by the original URN. The reason I hope this example is atypical is that the URL returned by the resolution service is of a search engine rather than the resource itself, and the URL contains a query, which is not a good result if the resource itself accepts queries. My understanding is that ISTC is only for purely text and not interactive resources, so maybe it's not actually a problem for this specific example. But that's a subtle distinction. But I don't think this is an incorrect example. The URN resolution service shouldn't be expected to know the details of the URLs it returns. If an authoritative source associates a URL containing a query with a URN in the resolution service, the resolution service shouldn't reject it. > If the target system does not support a standard search protocol, proprietary search can be "hard-coded" into a q-component. But a simple use case such as "find metadata about the identified resource" should not require use of both components in the same time, no matter how the target system behaves. Agreed. If the use case is "find metadata" then normally only the r-component would be specified. The q-component is intended for interaction with the named resource itself, so is not really applicable to a "find metadata" use case. But I think we need to consider several use cases side-by-side. > > However, a user who knows the work identifier may want to retrieve a specific manifestation of the work - for instance, a PDF version - without knowing its identifier (in the worst case, the book may not have an identifier at all). Getting from works to manifestations may require slightly more complex communication between the URN resolver and the target system, and the use of both r and q components may be necessary. > > The URN to start the process could be something like > > URN:ISTC:A02-2009-000004BE-A??s=I2CS?s=I2R&p=PDF This seems like a very strange example, and probably not a valid one. The user doesn't know (or shouldn't rely on knowing) that the above URN will resolve to a URL that refers to a specific kind of search engine -- unless, perhaps, he knows that the named resource actually is a search engine (which is not the case in the above example - the resource is a text document). And the q-component is intended for interaction with the actual resource named by the assigned-portion of the URN, not for interaction with a search engine that will return the resource. So if the user wants to request a PDF manifestation of the work, that request needs to be made via the r-component. And this leads me to a somewhat awkward conclusion, which is that r-components aren't just for use by the resolution service. Clients need to know something about them also. I can think of a couple of examples off the top of my head: - the URN specifies an r-component that requests resource content (I2R), but the resolution service only supports the ability to return resource locations (URLs). The client needs to know how to interpret the r-component enough to understand the type of request, and implement it by getting URLs from the resolution service and getting the resource content from one of those URLs. - the URN specifies and r-component that specifies a particular kind of resource manifestation (e.g. PDF). The resolution service might not provide sufficient detail to let the client know which of the URLs it returns (for example) will return a PDF manifestation. The client might then need to contact multiple URLs and use (for example) HTTP content-negotiation to insist on a PDF manifestation of the content, until it finds such a manifestation. So the client needs to be able to understand that the URN is requesting a particular kind of resource manifestation. (of course this scenario can work out in other ways also: The resolution service might be able to limit its result to PDF manifestations, or the client might be able to tell from the results returned by the resolution service which of those URLs can provide PDF manifestations) Which leads me to some other conclusions: - either r-component facets must be a managed name space, or there needs to be a way to distinguish namespace-independent facet names from other facet names - at least some r-component facets must be standardized and independent of URN namespace. - it's dangerous to publish 2141bis until such standards exist > In these examples and also generally, neither r- nor q-component have a role in identification (which is what we have agreed on ages ago). It would be very confusing to say that the ISTC identifies anything else than the work itself. And although q- and r-components could be presented in any order, IMO it is more logical to express the r-component first. Some actions by the URN resolver (based on the r-component) may be required before the target system can carry on using the guidelines provided in the q-component. I agree with these statements. Though I want to reread the text in 2141bis about interaction between r- and q-components and make sure that it's unambigious as to which has precedence in the event that a resolution service returns a URL with a query. Does the q-component from the URN replace that query, or is the q-component discarded, or is this perhaps an error that should result in a failure to access the resource? I'm not even sure what the right answer is, but it needs to be the same for all cases. Keith From nobody Sun Nov 1 21:05:05 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BCC1B45B6 for ; Sun, 1 Nov 2015 21:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF-Q0aN263pR for ; Sun, 1 Nov 2015 21:05:02 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BA11B45B3 for ; Sun, 1 Nov 2015 21:05:02 -0800 (PST) Received: by wmff134 with SMTP id f134so50560220wmf.0 for ; Sun, 01 Nov 2015 21:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=23QGyiOvG6JfkpGI2LnZsdv5+iPAiCsJyDpVXck3KXg=; b=QtvS4uZeESUsjsyO3nqhu+NVWKKVNaYRf9OkESUDpQvoEldvm3GOjCykz4onJiXjM5 R5H54pRA2dQ/l8l0Cf9vpFE3T1wTB1r2bvPO79VNifAVG5fPNyGODvVWnK7FKXkmFo5e C5c39IN8dszFS8Bai3I+yysBPd97MLCElz2AG9sHNjr3AhUcW6QOBaA4ZGEORZJT9zWu h+iyb3LSUE7YLE4aHZqFrIfTmELGj2y+SGHJwk/DqK0t+amb/VHAgyNL1CTzUDFF8MvQ Cf9su3RuiwLRZmBT4prAtvQwfmE7xRbhiBJB4sQTeuSmub7KxnOMvBr/CDvE+uzpeDPZ cFQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=23QGyiOvG6JfkpGI2LnZsdv5+iPAiCsJyDpVXck3KXg=; b=ROvCtPkByhp7GZbwm8duwtZuEcZ7M/TgDPF/vWpVxqLQs5Ig1I/vsEgQ2H0VezpTKh do3URBuLGK8uCk8LdtXxclj+uWeO6tyCp+dzOP1+g6NpIz9oZwbavPDt1blet6fWNl9i lrj+f0MVvMN0w28bJFZHooj9i6Jr7t1Gnemw9UFucYjRMFcp0HXKDVQRPrjgX0BHHs7G EwoF/qh65sybeLeSVz5AhujkMK+145LUncT6h7v194eHqkSgPZW5gT1CUNQXRg/4LIZI bCwvfiVPHbL20rxipkEoi9QmxYuewn2v1Q4qM3PT5aBGhcM9Wmkjo7wRL4GPXLXaZsrO u9cw== X-Gm-Message-State: ALoCoQl3nLjFIajJYYPcOSH5zogfMElcDpmrQ0KP6/AkvTrYcp0kcAELtnoXcXFnclM6AMOibo4M MIME-Version: 1.0 X-Received: by 10.28.229.212 with SMTP id c203mr10290976wmh.11.1446440701082; Sun, 01 Nov 2015 21:05:01 -0800 (PST) Received: by 10.194.91.134 with HTTP; Sun, 1 Nov 2015 21:05:01 -0800 (PST) X-Originating-IP: [2001:c40:0:3024:8876:c1bb:f04e:f712] In-Reply-To: References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> Date: Mon, 2 Nov 2015 00:05:01 -0500 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" , Peter Saint-Andre Subject: Re: [urn] Think about r-components and q-components differently X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 05:05:03 -0000 On Wed, Oct 28, 2015 at 11:39 PM, John C Klensin wrote: > > specialChar1 and specialChar2 should be chosen to minimize the > likelihood of collisions with URL queries. I'd guess that most > of the characters other than left parentheses, left brackets, > and single-quote listed for in 3986 would be > reasonable candidates. To the extent to which queries > ordinarily take the form > ? [SP] phrase ... > or > ? [SP} keyword = value ... > forms like > ? > are just not going to be an issue. 3986 lists: gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" ']' is in gen-delims, and ')' is in sub-delims. -andy From nobody Sun Nov 1 23:05:42 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CB31A0163 for ; Sun, 1 Nov 2015 23:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oP8eT6k_4dD for ; Sun, 1 Nov 2015 23:05:39 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8AC41AD0B6 for ; Sun, 1 Nov 2015 23:05:38 -0800 (PST) Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 071F9509BE; Mon, 2 Nov 2015 02:05:35 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_03E6069E-F118-48D6-9429-6C55991D5939"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <5636DAB2.8000002@network-heretics.com> Date: Mon, 2 Nov 2015 16:03:27 +0900 Message-Id: References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 07:05:41 -0000 --Apple-Mail=_03E6069E-F118-48D6-9429-6C55991D5939 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 2, 2015, at 12:38 PM, Keith Moore = wrote: > On 11/01/2015 10:26 PM, Peter Saint-Andre wrote: >> the disagreements here aren't as serious as they might first appear, = and that participants are not all that far apart when it comes to the = actual text of the spec. I agree with this sentiment. >=20 > I suspect that the current text is very close to being what we need, = but what's left unsaid or misstated by the current text (even if only = slightly) is of huge importance. >=20 > I think we need to produce some detailed examples of how we expect = URNs to work. I also agree with this sentiment. > Maybe they don't end up in the document (or maybe in a separate = informational document) but those examples might expose significant = disagreements or ambiguities in 2141bis that we need to resolve. I do not agree so much with this sentiment. I strongly propose that we = use the WG Wiki: http://trac.tools.ietf.org/wg/urnbis/trac/wiki To record some specific detailed examples, as well as areas of = significant disagreements or ambiguities. In particular, though, I propose that we use the WG wiki to document = agreements that this WG has reached historically, as a record of = milestones of progress, and so that if people disagree, we can point to = somewhere (other than the urnbis draft itself) on where are are with the = status quo. Sean --Apple-Mail=_03E6069E-F118-48D6-9429-6C55991D5939 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTAyMDcwNTI5WjAjBgkqhkiG9w0BCQQxFgQUZYf+S/OxQ8LDdWc6ln2qWwgoq/QwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAKt/0DOK+e2w25z3R37Zqv7JoVPDmDIb7a4u4PXdwEQu02UwiGdBo+qh/wC3fO7MYCRq Xb/baL7b9JHabNeufzxXDMeHmHvtmElszh4ec0FSmYYWYXjsTEzuIkEIdz6rZN1DBcD6js7ZJOg6 KqYV3NeBS93JH//ADpiX0yqIzMIfo1t5RxoSBe7fnBjz7CvrcDplbwCL811rgO/Rj/uE7NMmrcjs Vtl/HYQjRV57vSf5Ews2m1gVLFliH8U3Ki/SXSHx1VydYKE2+mrqUyfeS5W/qVcFZUICBmJZRCdA BZ66cHqZFj7lo5S9ExiFNdl8zmrWCcjTpI6r2RmB2aVxa5cAAAAAAAA= --Apple-Mail=_03E6069E-F118-48D6-9429-6C55991D5939-- From nobody Mon Nov 2 04:29:12 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBBC1A8826 for ; Mon, 2 Nov 2015 04:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9rqmVGBb6Bi for ; Mon, 2 Nov 2015 04:29:09 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B351A8825 for ; Mon, 2 Nov 2015 04:29:09 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtEEV-000EAU-9b; Mon, 02 Nov 2015 07:29:07 -0500 Date: Mon, 02 Nov 2015 07:29:02 -0500 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> In-Reply-To: <5636DAB2.8000002@network-heretics.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 12:29:10 -0000 --On Sunday, November 01, 2015 22:38 -0500 Keith Moore wrote: > On 11/01/2015 10:26 PM, Peter Saint-Andre wrote: >... >> Perhaps I'm deluding myself, but I tend to think the >> disagreements here aren't as serious as they might first >> appear, and that participants are not all that far apart >> when it comes to the actual text of the spec. Agreed. These details are important, but I don't see much that is insurmountable if we can stay focused. On the other hand, I would also have said that a year ago, which is one of the things that makes part of this process so frustrating... and, I assume, not just to me. > I suspect that the current text is very close to being what we > need, but what's left unsaid or misstated by the current text > (even if only slightly) is of huge importance. I mostly agree with that too, but I think we need to be careful and reasonable. Perfection is impossible and not every detail is important (hugely or not) and I would hope that any "this needs to be fully specified and/or fixed before the document(s) can go into WGLC" statements would be accompanied by an explanation for that particular case as to why. In particular, if there are things we are going to leave to the discretion and needs of individual namespaces (I think, given the nature of URNs, that is inevitable and consistent with 2141 and earlier documents), then it is important to be clear about the boundary but anything we say beyond that has to be in the form of non-normative examples. > I think we need to produce some detailed examples of how we > expect URNs to work. Following on the above, yes, but only if we can be very clear that the set of examples is neither normative nor exhaustive. I think that, if we get "comprehensive typology of URN namespaces or their uses" into the critical path, the earlier comments about just giving up probably apply. I don't think Keith was suggesting that, but the wording above might tend to drift in that direction. > Maybe they don't end up in the > document (or maybe in a separate informational document) but > those examples might expose significant disagreements or > ambiguities in 2141bis that we need to resolve. Yes, but let's do it in I-D form or some other form that will expire and be seen as non-normative if we don't decide to publish it as a consensus document. The problem with doing it in a Wiki is the same as the problem with "tutorials" about a standard that are produced by the body that produced the standard: because they are almost inevitably easier to read than the standard itself (if only because of the details that are left out), they tend to become the standard in practice. That, in turn, leads to interoperability issues between implementations of the standard and implementation of the informal, supplementary, non-consensus materials. Especially with the combination of a Wiki and controversial issues, the "winner" tends to be whomever has the most energy for the longest time, not community rough consensus. john From nobody Mon Nov 2 05:02:25 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13E01B360A for ; Mon, 2 Nov 2015 05:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpbyPDdwRHBK for ; Mon, 2 Nov 2015 05:02:20 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019BB1B360D for ; Mon, 2 Nov 2015 05:02:20 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtEkY-000EEk-RW; Mon, 02 Nov 2015 08:02:14 -0500 Date: Mon, 02 Nov 2015 08:02:09 -0500 From: John C Klensin To: Andrew Newton Message-ID: <1A1A7E70D89427063F516DE7@JcK-HP8200.jck.com> In-Reply-To: References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, Peter Saint-Andre Subject: [urn] Component delimiters (was: Re: Think about r-components and q-components differently) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 13:02:23 -0000 --On Monday, November 02, 2015 00:05 -0500 Andrew Newton wrote: > On Wed, Oct 28, 2015 at 11:39 PM, John C Klensin > wrote: >> >> specialChar1 and specialChar2 should be chosen to minimize the >> likelihood of collisions with URL queries. I'd guess that >> most of the characters other than left parentheses, left >> brackets, and single-quote listed for in 3986 >> would be reasonable candidates. To the extent to which >> queries ordinarily take the form >> ? [SP] phrase ... >> or >> ? [SP} keyword = value ... >> forms like >> ? >> are just not going to be an issue. > > 3986 lists: > > gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" > > sub-delims = "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=" > > ']' is in gen-delims, and ')' is in sub-delims. Andy, I deliberately did not propose specific delimiters. The two I did choose were because they seems to made good illustrations of what I was talking about, but not either proposals or examples. Indeed, I knew that "]" was on the gen-delims list and used it in the hope of kicking off a discussion of delimiters if the WG decided it preferred a model of r-string = "?" specialChar2 r-component q-string = "?" specialChar1 q-component to r-string = "?" "?" r-component q-string = "?" q-component or q-string = "?" q-component (I think we are at one of the latter two or something between them in 2141bis-14) Thanks for touching off the "which delimiters" discussion even though I think we should resolve the other one first: if we prefer sticking with single and double question marks, the delimiter choice is a non-issue. john From nobody Mon Nov 2 05:12:15 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CB01B3625 for ; Mon, 2 Nov 2015 05:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qwDBHMJLyMM for ; Mon, 2 Nov 2015 05:12:12 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E521B3623 for ; Mon, 2 Nov 2015 05:12:11 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6930720B11 for ; Mon, 2 Nov 2015 08:12:11 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 02 Nov 2015 08:12:11 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=KHT+L+ZImrxKQK9 oNrClaS2hY0I=; b=dNMjAfbTMoqAZdZs3+AMvhJieYyOjjAx3Hkz5TZy6tm8Lih +HY4MdvTvOubdrNgZ3vK0CDyuSJ5m/BxZXVU5SEIg6hBQ4R5qsNOXPd0owFj0+SC DKPRGKnyh+Xp775hREtDlljXX4xvM8P2S8dZ/tm61gDAnjlDEvN8zrf2dsZc= X-Sasl-enc: coLH3SRHgL04xyDYANYZD6wzElFmVHH4fI4WZlxrEL5H 1446469931 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id F15FDC016F4; Mon, 2 Nov 2015 08:12:10 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <56376110.90203@network-heretics.com> Date: Mon, 2 Nov 2015 08:11:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 13:12:14 -0000 On 11/02/2015 07:29 AM, John C Klensin wrote: > > --On Sunday, November 01, 2015 22:38 -0500 Keith Moore > wrote: > >> On 11/01/2015 10:26 PM, Peter Saint-Andre wrote: >> ... >>> Perhaps I'm deluding myself, but I tend to think the >>> disagreements here aren't as serious as they might first >>> appear, and that participants are not all that far apart >>> when it comes to the actual text of the spec. > Agreed. These details are important, but I don't see much that > is insurmountable if we can stay focused. On the other hand, I > would also have said that a year ago, which is one of the things > that makes part of this process so frustrating... and, I assume, > not just to me. > >> I suspect that the current text is very close to being what we >> need, but what's left unsaid or misstated by the current text >> (even if only slightly) is of huge importance. > I mostly agree with that too, but I think we need to be careful > and reasonable. Perfection is impossible and not every detail > is important (hugely or not) and I would hope that any "this > needs to be fully specified and/or fixed before the document(s) > can go into WGLC" statements would be accompanied by an > explanation for that particular case as to why. In particular, > if there are things we are going to leave to the discretion and > needs of individual namespaces (I think, given the nature of > URNs, that is inevitable and consistent with 2141 and earlier > documents), then it is important to be clear about the boundary > but anything we say beyond that has to be in the form of > non-normative examples. It's that kind of language that makes me worry. I am very skeptical that leaving things to "the discretion and needs of individual namespaces" is at all appropriate. It is essential that clients be able to process URNs without having to know details about specific namespaces. Saying we can leave things to namespace discretion seems basically like a failure to do our job in creating a standard. I do accept that different resolution services will probably recognize somewhat different sets of r-parameter facets and offer somewhat different kinds of metadata, if for no other reason than that these need to be able to evolve over time. But I don't think this is a namespace-specific attribute, but rather an attribute of the resolution service. Can you cite examples of things that need to be left to namespace discretion? > >> I think we need to produce some detailed examples of how we >> expect URNs to work. > Following on the above, yes, but only if we can be very clear > that the set of examples is neither normative nor exhaustive. Agreed, and that's part of why I suggested that these go into a separate Informational document. It's obvious to me at least that there's a tremendous amount of potential flexibility in how URNs are resolved to enable users to access resource content or metadata, and trying to pin all of that down is probably like commanding the tides to recede. And yet, there does need to be some discipline and constraints in how URNs and their various components are used (at least, if we want clients to be able to use them in a repeatable/reliable fashion), and we don't seem to have made much progress at discovering what that discipline and those constraints should be. >> Maybe they don't end up in the >> document (or maybe in a separate informational document) but >> those examples might expose significant disagreements or >> ambiguities in 2141bis that we need to resolve. > Yes, but let's do it in I-D form or some other form that will > expire and be seen as non-normative if we don't decide to > publish it as a consensus document. The problem with doing it > in a Wiki is the same as the problem with "tutorials" about a > standard that are produced by the body that produced the > standard: because they are almost inevitably easier to read than > the standard itself (if only because of the details that are > left out), they tend to become the standard in practice. That, > in turn, leads to interoperability issues between > implementations of the standard and implementation of the > informal, supplementary, non-consensus materials. Especially > with the combination of a Wiki and controversial issues, the > "winner" tends to be whomever has the most energy for the > longest time, not community rough consensus. I agree with not using a Wiki, for that and other reasons. I would like to start with mailing list discussion and evolve it to an I-D. Of course it won't be published as a WG document if WG consensus isn't reached. Keith From nobody Mon Nov 2 07:14:05 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C001B46E3 for ; Mon, 2 Nov 2015 07:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m7LTSrterY5 for ; Mon, 2 Nov 2015 07:14:02 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F141B46E1 for ; Mon, 2 Nov 2015 07:14:01 -0800 (PST) Received: by wijp11 with SMTP id p11so53681217wij.0 for ; Mon, 02 Nov 2015 07:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RbVUjT4ac5sJ8OYnCocVe0u6GqPl0BBjEWC0lHyr2DM=; b=KYZq8la/JT8Kw+z3XQ8GBKC2EfFKYTRLA4A5RG2BwQz90kXLLe9dYG2lrBikHbp0m3 o4JW8PC8HUtFEHwxcTvdWODC/UilEIsucoZ3AN1gPJXgYi4RwVIISwS2455aLi7u9/vy 0pzRkMMSzX/wkZW7FYzfOaDiaOSiYk+sXEGS/WFimYqx7OjuMl2xhwxFt7GGluBTOe7A ykTquYois7qa9c/xMGPj+8y4AtOAIRLdSTofPz5LFfBe+JoyYIfS8/jlM5kqxdwueCDo uFWD7+LzdA0OhGG3k3lBu+v+Ln/6AHxRskU0pZlmqQfg8odDPtwti60TUDsVp1Og4xft 7Krw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RbVUjT4ac5sJ8OYnCocVe0u6GqPl0BBjEWC0lHyr2DM=; b=AJLuLKRrP5VCze85tXjhyaLArgILJ8oLUJHJQYE8DSX05Dua1tK8TBqHcBrZmi6xC/ Mjy/J0s9Mr23UGBRmU6/M3uXsgXGmffSasKeA+/k+9+eQVv+aD69rn90rHLpihynGg8P Xg3jMqN8y2DggJQhNDpLtd2ruuYbIYcy9rvJiGJay7w9A+yEiu9pSX8zK78az9D/Xuga iE7ixr3Spm3h2wUyIzrIAqTQZw8E6OviVBZrqfRna6wS7TmexrT39I4Hc2s1IcfD2FzX VFDw3BwIWM2CpYJTTTXK6G9kpRuuDHwheYHJ9zBSD1xbqtqHYUuoxbUssHyWAxp/oa3H uE7Q== X-Gm-Message-State: ALoCoQkNe3RhEjdS7Qkstp5aO4Tgf5ZPR2hDWhiL+3ZpwqkO7CUDkhzWoRssSDmtuvXJ1CQF55uD MIME-Version: 1.0 X-Received: by 10.195.11.98 with SMTP id eh2mr24443915wjd.59.1446477240206; Mon, 02 Nov 2015 07:14:00 -0800 (PST) Received: by 10.194.91.134 with HTTP; Mon, 2 Nov 2015 07:14:00 -0800 (PST) X-Originating-IP: [2001:c40:0:3080:d9ad:bbe5:ee0:440a] In-Reply-To: <1A1A7E70D89427063F516DE7@JcK-HP8200.jck.com> References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> <1A1A7E70D89427063F516DE7@JcK-HP8200.jck.com> Date: Mon, 2 Nov 2015 10:14:00 -0500 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" , Peter Saint-Andre Subject: Re: [urn] Component delimiters (was: Re: Think about r-components and q-components differently) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 15:14:03 -0000 On Mon, Nov 2, 2015 at 8:02 AM, John C Klensin wrote: > Thanks for touching off the "which delimiters" discussion even > though I think we should resolve the other one first: if we > prefer sticking with single and double question marks, the > delimiter choice is a non-issue. Sorry, that subtly of the proposal was lost on me. I'll blame it on jet lag or lack of caffeine, because it certainly can't be that navigating the discussions on this list are in any way difficult. :) So let me summarize what I think the issue is: we have not yet been able to get '??' to work right in the ABNF. And therefore we have several thought experiments which have ranged from just noting the issue in the prose to trying harder to throwing everything we've done so far away. Do I have that right? If I do, then here is the chair guidance: let the document authors figure it out, and the rest of us just need to live with it. To me this seems like a small matter that does not need endless discussion. You and Peter can thumb wrestle or throw darts or whatever, and if you decide to try to get the ABNF 100% perfect (and good luck with that, I think I know the outcome), so be it. If you decide that an ABNF comment or prose comment or both are appropriate, so be it. Or if you decide that special character delimiters are needed, pick two and so be it (and btw, I hate the two you picked but if that's where you want to go, I'll live with my hate of ')' and ']'). I'm not trying to sound harsh to any discussion participants here, but from my perspective this is a small matter we should trust to the judgement of the document authors. -andy From nobody Mon Nov 2 07:37:53 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF3D1B489B for ; Mon, 2 Nov 2015 07:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKvJ4cxrDtkL for ; Mon, 2 Nov 2015 07:37:50 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FED91B4893 for ; Mon, 2 Nov 2015 07:37:50 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtHB5-000Ebw-Vp; Mon, 02 Nov 2015 10:37:47 -0500 Date: Mon, 02 Nov 2015 10:37:42 -0500 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <56376110.90203@network-heretics.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 15:37:53 -0000 --On Monday, November 02, 2015 08:11 -0500 Keith Moore wrote: >... >> I mostly agree with that too, but I think we need to be >> careful and reasonable. Perfection is impossible and not >> every detail is important (hugely or not) and I would hope >> that any "this needs to be fully specified and/or fixed >> before the document(s) can go into WGLC" statements would be >> accompanied by an explanation for that particular case as to >> why. In particular, if there are things we are going to >> leave to the discretion and needs of individual namespaces (I >> think, given the nature of URNs, that is inevitable and >> consistent with 2141 and earlier documents), then it is >> important to be clear about the boundary but anything we say >> beyond that has to be in the form of non-normative examples. > > It's that kind of language that makes me worry. I am very > skeptical that leaving things to "the discretion and needs of > individual namespaces" is at all appropriate. It is > essential that clients be able to process URNs without having > to know details about specific namespaces. Saying we can > leave things to namespace discretion seems basically like a > failure to do our job in creating a standard. This is precisely the kind of disagreement (whether apparent or real) that I think needs to be exposed, discussed, resolved, and then taken sufficiently off the table that attempts to reopen it are strongly resisted by the WG. If we are to make progress, that is true independent of which of us are correct. Now, let me be sure that I understand what you are suggesting. If a "client" has to be able to "process URNs without having to know details about specific namespaces", that means to me that one cannot have per-namespace "resolvers" or resolution mechanisms, i.e., that, if any URN is resolvable, all URNs must be, and that there must be a generic resolution mechanism that works for all URNs and that, moreover, that there be no namespace-specific resolution machinery to be applied for any namespace after that generic resolution mechanism does its job. That, in turn, suggests to me that, from the following category-descriptions, one can have valid URNs in only one of them, not all three (or others) (ignoring for the moment whether I'm talking about the entire URN string (2141bis "namestring") or what 2141bis-14 calls an "assigned-name"): (a) Pure identifiers that do not resolve at all, but are merely tested for string equality. (b) URNs that map into ("resolve to") some sort of URL. (c) URNs that identify a (presumably digital) object in some other way. For example in that regard, assume a URN that names a particular text but, without embedding a DOI string in the URN namestring, resolves to a DOI. Whether that DOI is then made part of a URL (in doi.org or elsewhere) is not a URN definition problem. Similar examples would apply to URNs that name or refer to library objects but that resolve, not to a URL but to an accession number or shelf location. My impression was that the WG agreed to the validity of all of those three casss as URNs long ago, at least for the second and third probably about the time we decided that DDDS was _a_ way to resolve _some_ URNs but not a necessary element of a generic URN system. However, one doesn't even need to look to 2141bis and history since 2141 (May 1997) or 2483 (January 1999) to have that per-namespace problem. urn:ISSN:1046-8188 (from RFC 3044 Section 3.1) treats the NSS at the identifier within the ISSN namespace but urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637 (RFC 6963, Section 5) involves a "sub-namespace" that much be interpreted differently at some point rather than viewing the NSS as atomic. Presumably urn:ISSN:foobar:9999-9999 would be considered a syntax error. At least something namespace-specific would want to reject it rather than passing it on to some resolution machinery. Because of that, I think 2141 itself works iff one uses generic URN processing to identify the NID and then passes the NSS off to an NID-family-specific processor (I say "family" because I don't believe we will have, or should have, separate processors for each NID even though I expect the total number of processors will be much larger than one). Now, if you agree with the above, I've very confused about what you are talking about or where the boundaries lie. In particular... > I do accept that different resolution services will probably > recognize somewhat different sets of r-parameter facets and > offer somewhat different kinds of metadata, if for no other > reason than that these need to be able to evolve over time. > But I don't think this is a namespace-specific attribute, but > rather an attribute of the resolution service. Again, that completely confuses me, at least in part because I think that a generic URN processor can be expected to do only three things: (i) Parse the namestring, identifying the elements of and .[1] (ii) Try to find an appropriate resolution service based on the NID. If it cannot find one, do something reasonable [2]. (iii) If it can, identify a resolution service that it understands [3], pass the NSS, and any of q-component, r-component, and maybe f-component that are present, to the resolution service [4]. Note that the above implies that the semantics and within-string syntax of r-component and the handling of q-component are mostly the problem of the resolution service. Because we expect the resolution service to digest r-components, we don't need to be as specific about its within-string syntax as we do about q-component (or f-component), which, at least as I understand our definitions so far, we expect to be passed more or less intact from the resolution service. > Can you cite examples of things that need to be left to > namespace discretion? Whether the namespace is resolved at all. Whether sub-namespaces are allowed. Whether q-component and/or f-components are consider valid. Whether r-components are accepted and what syntax and semantics they have. >... best, john [1] Given the way URIs are defined, this is actually a rather difficult problem because, whether there are generic URI parsers or not, there is really no such thing as a generic URI (or even URN) resolver that can encounter and generically report error states. If I put "http:[[]]" into an href, any standardized error-handling is part of the HTML spec (very much scheme and content-specific) not part of either 3986 or, IIR, the http spec. I hope we don't have a URK in our future named "fail" whose hier-part is unspecified but might be an error message or code, which it would be one way to deal with putative URNs that cannot be parsed. Especially if we need to be as specific as I gather you want (and as my instincts tell me will probably be necessary), I don't see how to avoid saying something about this in 2141bis but don't, at the moment, know what to say. [2] This is obviously a mess. It is the mess that NAPTR and DDDS were intended to solve by creating a DNS-based indirection mechanism for binding resolution mechanisms for NIDs, but that has failed to achieve wide adoption and the WG (and the DDDS specs themselves) have decided that not all URNs are required to be bound to DDDS. Maybe that was a mistake, but the horse has left the barn and vanished over the horizon. I'm sure, based on experience, that "look the NID up in the IANA registry in real time" is not going to be acceptable operationally (even if there were no other issues). The result is that I don't see any alternative to doing some handwaving around "find a resolver based on the NID and do something intelligent if you can't find one" and then either assuming that "can't find resolver with a reasonable amount of effort" means "this NID does not resolve" or "need to return some sort of 'fail' indication". That makes me _very_ unhappy but, given where we have gotten, I'm having trouble figuring out alternatives that do not require inventing a somewhat more general and flexible successor to DDDS and insisting that all URNs be able to use it. [4] If we were modeling a process, rather than syntax and (at least some) semantics, we could specify the difference between generic-engine CALLS NID-resolver(NSS, r-component) GETS BACK CONSTRUCTS (string, decoded-q-component, f-component) and returns that to wherever it goes and generic-engine CALLS NID-resolver(NSS, r-component, q-component, f-component) GETS BACK a string that includes q-component and f-component as appropriate and returns that to wherever it goes with "string" in both cases being more or less the hier-part of a URL for case (b) (and I don't know how to think about (a) and (c), much less others). But we can't so, if we are are going to define a generic resolution service, we are going to need to define what it can return and probably the operations it performs to get there. I don't think we can do that for the reasons that make the three different URN cases identified above as (a), (b), and (c) (and others) important. From nobody Mon Nov 2 07:49:44 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539351B48C5 for ; Mon, 2 Nov 2015 07:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0Vk-hipphvb for ; Mon, 2 Nov 2015 07:49:42 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E205E1B48C4 for ; Mon, 2 Nov 2015 07:49:41 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtHMX-000Ect-8W; Mon, 02 Nov 2015 10:49:37 -0500 Date: Mon, 02 Nov 2015 10:49:32 -0500 From: John C Klensin To: Andrew Newton Message-ID: <1ED292FC6724FDD8D8BCDA7E@JcK-HP8200.jck.com> In-Reply-To: References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> <1A1A7E70D89427063F516DE7@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, Peter Saint-Andre Subject: Re: [urn] Component delimiters (was: Re: Think about r-components and q-components differently) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 15:49:43 -0000 --On Monday, November 02, 2015 10:14 -0500 Andrew Newton wrote: > On Mon, Nov 2, 2015 at 8:02 AM, John C Klensin > wrote: >> Thanks for touching off the "which delimiters" discussion even >> though I think we should resolve the other one first: if we >> prefer sticking with single and double question marks, the >> delimiter choice is a non-issue. > > Sorry, that subtly of the proposal was lost on me. I'll blame > it on jet lag or lack of caffeine, because it certainly can't > be that navigating the discussions on this list are in any way > difficult. :) I've noticed the problem and, unlike you, at least can't blame jet lag :-( > So let me summarize what I think the issue is: we have not yet > been able to get '??' to work right in the ABNF. And therefore > we have several thought experiments which have ranged from > just noting the issue in the prose to trying harder to > throwing everything we've done so far away. Do I have that > right? I think that is right, although, IMO, the ABNF difficulties are just a symptom of some more basic conceptual problems, with the ordering of r- versus q-components being another symptom. > If I do, then here is the chair guidance: let the document > authors figure it out, and the rest of us just need to live > with it. To me this seems like a small matter that does not > need endless discussion. You and Peter can thumb wrestle or > throw darts or whatever, and if you decide to try to get the > ABNF 100% perfect (and good luck with that, I think I know the > outcome), so be it. If you decide that an ABNF comment or > prose comment or both are appropriate, so be it. Or if you > decide that special character delimiters are needed, pick two > and so be it (and btw, I hate the two you picked but if that's > where you want to go, I'll live with my hate of ')' and ']'). Part of my "symptom of conceptual problem" concern is that I think Keith (and maybe others) are convinced that we need to rather precisely define the boundary between the appropriate content for q-components and r-components (or get rid or one or both). I don't think so and maybe I misunderstand what Keith is asking for -- see long note I just sent -- but, unlike some details of syntax, I think decisions at that level need to be made by the WG, not by Peter and myself. For the record, I hate the idea of making syntax decisions based on what is easy to express in ABNF rather than what works well for the application, but I could say (and have said) the same thing about what works well for UNRs in the context of 3986. > I'm not trying to sound harsh to any discussion participants > here, but from my perspective this is a small matter we should > trust to the judgement of the document authors. I'd be ok with going off with Peter and making a decision, but see above. BTW, the reason I selected ")" and "]" for those examples was that I hate them and hope that others would hate them enough to force a conversation. If left to my own devices, I guarantee you won't see them in a final proposal (and that I'll fight Peter if he likes them) :-) thanks, john From nobody Mon Nov 2 14:20:02 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F6B1A891E for ; Mon, 2 Nov 2015 14:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HC0D3vYPzj8 for ; Mon, 2 Nov 2015 14:19:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1791A891D for ; Mon, 2 Nov 2015 14:19:59 -0800 (PST) Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0819B509BF; Mon, 2 Nov 2015 17:19:55 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_E9E20749-3E61-4746-B45A-47014F44D538"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> Date: Tue, 3 Nov 2015 07:17:56 +0900 Message-Id: <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 22:20:01 -0000 --Apple-Mail=_E9E20749-3E61-4746-B45A-47014F44D538 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 2, 2015, at 9:29 PM, John C Klensin wrote: > The problem with doing it > in a Wiki is the same as the problem with "tutorials" about a > standard that are produced by the body that produced the > standard: because they are almost inevitably easier to read than > the standard itself (if only because of the details that are > left out), they tend to become the standard in practice. Then put a disclaimer at the top of the Wiki that this is just for = brainstorming and discussion only, and delete the Wiki when done. If the Wiki is easier to read than the standard document, that=92s an = indictment of the standard document. Don=92t choose things because they = are more difficult to use. Look: the alternative is what is happening here: years and years of = endless discussions by e-mail with various points brought up again or = rehashed in variant form by different participants. Sean --Apple-Mail=_E9E20749-3E61-4746-B45A-47014F44D538 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTAyMjIxOTQ1WjAjBgkqhkiG9w0BCQQxFgQUi6mAwelW74Tc8v6WbDafOODD3hwwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBABhL5eRfN0Zb79itCDfbttLGnJDGPFIbspI1iXLMG0SnpCuX7f0JAUENKHXSeu0gDkik Wv5MSPQZ/ks4aDTCH1Kn2YU08MHjHrRonv0O7hkZy265ungGuSmJrxi9tqn4mDnL2oObBs1TO1Ph hYxlMQCDLLGfGUUqcyrR5Cp/JeHLzGf7pGHJqaPN3nkvIuIqq1dCGGSmGGmwlZOxYgp7EcWfwUsN vmcbP5fk4RNX5W+FhLdQ1zf7W95IlJ7fG93AQun3lQXqh4TwUfDHIeAbVDVHPuxLnqF/INm2g/De Yopjcj3VlcORyLyBe80Ab5UMUmbTXVKK0846/ywJnbN0NXEAAAAAAAA= --Apple-Mail=_E9E20749-3E61-4746-B45A-47014F44D538-- From nobody Mon Nov 2 14:28:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF121A8990 for ; Mon, 2 Nov 2015 14:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Iz17uB3xCbd for ; Mon, 2 Nov 2015 14:28:34 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A421A897F for ; Mon, 2 Nov 2015 14:28:34 -0800 (PST) Received: by obctp1 with SMTP id tp1so106235859obc.2 for ; Mon, 02 Nov 2015 14:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=brKEhXMx1B4MA19FEIGrkwez/7g45bAqgD8l9vdXqmU=; b=FqKxJJAlRBVcna5cShASFdRNj5FNOS7s+loE2CIGlWsQLha1iJp7o23HbMJN2Bnz5Q PPib3qdBBx0DVh3an+8QV5QHqNC6gp9A8PPzeH1oabQmIOn/4PDpQ+b1alApAgOrV5LL aLPhxBSZ/qW4D2VrVn1NRYhIELJk9E4sz50UmkLH97Skf4yT3K191ka/cwXBQiGvLVaE yKWAZqy9ZVjsmUMyeASWq8SaQoQMg2JG8Z4D0YegUz81Ji+7OuAADtMJM31aV562TZOg UcN6Jwbq7Domm69jQpdGirpgX0ZCxpXt6cNSf6dqMy0pyOx96XQw9S3UsiKA4kygf2AZ IZcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=brKEhXMx1B4MA19FEIGrkwez/7g45bAqgD8l9vdXqmU=; b=BpevjEnY3N+DP989E2/vhcUGi8tw7J1yc1VJb3uTB77qMnCJn21S+SxpeO+Xmq3WzA yTHKxmpxS92Qh2KGnIehKWg0vg8iPmrDjcykGBV7pyl5vitbiMzrYESqCbvV019lNgDR 1PhcUqfUe6+zjx3BmZvN9gF5XYVMEVhsA4XS/V34Fmhrlq/COMrZoIYZxD08HVRYcUPp Qi8a3kFmyMWTHVqycDPtcdSjylC7ogbbvRrnhwuc06dRHO6uP7E5xqowQMOFtvaei5vb Eu046EkGcZCs1lBC63Qv5aoZ3C/HIwSAZ1lmJ5gp8m95bmc1O2UtiITc19ot2p8/zsfz uXEg== X-Gm-Message-State: ALoCoQnNq12PrO6SjDHeTaA1GgZzFGHAbs3ep5Q+3eTIRPaCpABqwmGgI0GmmzSbsoCxKJ/IR2gO X-Received: by 10.182.97.97 with SMTP id dz1mr15689619obb.17.1446503313975; Mon, 02 Nov 2015 14:28:33 -0800 (PST) Received: from aither.local ([2601:282:4201:ef5b:846a:c822:4509:add2]) by smtp.googlemail.com with ESMTPSA id co5sm9754930obb.15.2015.11.02.14.28.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 14:28:32 -0800 (PST) To: Sean Leonard , John C Klensin References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> From: Peter Saint-Andre Message-ID: <5637E38E.2050704@andyet.net> Date: Mon, 2 Nov 2015 15:28:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 22:28:36 -0000 On 11/2/15 3:17 PM, Sean Leonard wrote: > > On Nov 2, 2015, at 9:29 PM, John C Klensin > wrote: > >> The problem with doing it in a Wiki is the same as the problem with >> "tutorials" about a standard that are produced by the body that >> produced the standard: because they are almost inevitably easier to >> read than the standard itself (if only because of the details that >> are left out), they tend to become the standard in practice. > > Then put a disclaimer at the top of the Wiki that this is just for > brainstorming and discussion only, and delete the Wiki when done. > > If the Wiki is easier to read than the standard document, that’s an > indictment of the standard document. Don’t choose things because they > are more difficult to use. > > Look: the alternative is what is happening here: years and years of > endless discussions by e-mail with various points brought up again or > rehashed in variant form by different participants. I don't think that using a different tool will magically help us through this impasse. Pointing to a wiki page isn't all that different from pointing to the list archive. Peter From nobody Mon Nov 2 15:03:43 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E01A8BC4 for ; Mon, 2 Nov 2015 15:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gfhmmBRcbr8 for ; Mon, 2 Nov 2015 15:03:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A798D1A8F35 for ; Mon, 2 Nov 2015 15:03:32 -0800 (PST) Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76640509BE; Mon, 2 Nov 2015 18:03:28 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_BE1F2811-73CC-4BB4-A2FA-10BFE3E523B4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Tue, 3 Nov 2015 08:01:02 +0900 Message-Id: References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> To: John C Klensin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 23:03:40 -0000 --Apple-Mail=_BE1F2811-73CC-4BB4-A2FA-10BFE3E523B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 3, 2015, at 12:37 AM, John C Klensin wrote: >=20 >=20 > --On Monday, November 02, 2015 08:11 -0500 Keith Moore > wrote: >=20 >> ... >>> I mostly agree with that too, but I think we need to be >>> careful and reasonable. Perfection is impossible and not >>> every detail is important (hugely or not) and I would hope >>> that any "this needs to be fully specified and/or fixed >>> before the document(s) can go into WGLC" statements would be >>> accompanied by an explanation for that particular case as to >>> why. In particular, if there are things we are going to >>> leave to the discretion and needs of individual namespaces (I >>> think, given the nature of URNs, that is inevitable and >>> consistent with 2141 and earlier documents), then it is >>> important to be clear about the boundary but anything we say >>> beyond that has to be in the form of non-normative examples. >>=20 >> It's that kind of language that makes me worry. I am very >> skeptical that leaving things to "the discretion and needs of >> individual namespaces" is at all appropriate. It is >> essential that clients be able to process URNs without having >> to know details about specific namespaces. Saying we can >> leave things to namespace discretion seems basically like a >> failure to do our job in creating a standard. >=20 > This is precisely the kind of disagreement (whether apparent or > real) that I think needs to be exposed, discussed, resolved, and > then taken sufficiently off the table that attempts to reopen it > are strongly resisted by the WG. If we are to make progress, > that is true independent of which of us are correct. >=20 > Now, let me be sure that I understand what you are suggesting. > If a "client" has to be able to "process URNs without having to > know details about specific namespaces", that means to me that > one cannot have per-namespace "resolvers" or resolution > mechanisms, i.e., that, if any URN is resolvable, all URNs must > be, and that there must be a generic resolution mechanism that > works for all URNs and that, moreover, that there be no > namespace-specific resolution machinery to be applied for any > namespace after that generic resolution mechanism does its job. > That, in turn, suggests to me that, from the following > category-descriptions, one can have valid URNs in only one of > them, not all three (or others) (ignoring for the moment whether > I'm talking about the entire URN string (2141bis "namestring") > or what 2141bis-14 calls an "assigned-name"): >=20 > (a) Pure identifiers that do not resolve at all, but are > merely tested for string equality. > =09 > (b) URNs that map into ("resolve to") some sort of URL. > =09 > (c) URNs that identify a (presumably digital) object in > some other way. For example in that regard, assume a > URN that names a particular text but, without embedding > a DOI string in the URN namestring, resolves to a DOI. > Whether that DOI is then made part of a URL (in doi.org > or elsewhere) is not a URN definition problem. Similar > examples would apply to URNs that name or refer to > library objects but that resolve, not to a URL but to an > accession number or shelf location. >=20 > My impression was that the WG agreed to the validity of all of > those three casss as URNs long ago, at least for the second and > third probably about the time we decided that DDDS was _a_ way > to resolve _some_ URNs but not a necessary element of a generic > URN system. I can=92t speak about DDDS. But I think that (a), (b), and (c) are all = valid URNs. No complaints about that model or what the WG already = established. Some resolutions will naturally be specific to and defined by the = namespace (or sub-namespace, if so inclined to view things that way). = For example: urn:xmlns:foobar2015 is meant to represent an XML namespace. If resolved and dereferenced, it = is supposed to always return an XML schema (.xsd, application/xml or = text/xml), namely the XML schemas that are registered with IANA on a = first-come, first-served basis. Most resolutions, however, are not specific to or defined by the = namespace. For or = , they could be resolved = in lots of ways (accession number, shelf location, Amazon.com product = page, data: URI, abstract pointer to in-memory security object) and I = believe that Keith=92s essential points are that all of these = resolutions are contextually valid and that namespaces such as isbn: and = uuid: SHOULD NOT be read to restrict the resolution possibilities. But what=92s good for one set of identifiers may not be good for another = set of identifiers. And my argument is that even though you could = identify an XML namespace with urn:xmlns:foobar2015 and then resolve it = into something utterly tangential to the original purpose (e.g., a = picture of cats), there really is no functional value in doing so. >=20 > However, one doesn't even need to look to 2141bis and history > since 2141 (May 1997) or 2483 (January 1999) to have that > per-namespace problem. >=20 > urn:ISSN:1046-8188 (from RFC 3044 Section 3.1) treats the NSS > at the identifier within the ISSN namespace but >=20 > urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637 > (RFC 6963, Section 5) involves a "sub-namespace" that much be > interpreted differently at some point rather than viewing the > NSS as atomic. I object to this example on two grounds. First of all, it *is* a sub-namespace. urn:ietf:params, urn:ietf:rfc, = and urn:ietf:bcp, are sub-namespaces. A sub-namespace is a subset of a = namespace. But urn:isbn:817525 is also a sub-namespace. Anything that is a partial = string is a sub-namespace because it divides the namespace. Whether = those divisions have namespace-specific semantics is *defined by the = namespace registration*. My point is that urn:ietf:par is a = sub-namespace because it forecloses urn:ietf:pas or urn:ietf:pat. But it = is not internally significant, in contrast to urn:ietf:params:, which is = significant. In the case of urn:isbn:817525, that is a significant = sub-namespace because 81 is the group ID and 7525 is the publisher ID. = Therefore, everything starting with urn:ietf:817525 will be titles = published by the same publisher. A generic URN processor does not need to care about these internal = divisions. An urn:isbn: specific processor might actually care. Secondly, there is reasonable disagreement about whether SHA-1 = (cryptographic) hashes can or should be sufficient as namespace = identifiers, without any other guarantees about uniqueness beyond its = mathematical processes. After trying to do certspec = (draft-seantek-certspec) as urn:cert, I have given up on that approach. > [4] If we were modeling a process, rather than syntax and (at > least some) semantics, we could specify the difference between >=20 > generic-engine CALLS NID-resolver(NSS, r-component) > GETS BACK > CONSTRUCTS (string, decoded-q-component, f-component) > and returns that to wherever it goes >=20 > and >=20 > generic-engine CALLS NID-resolver(NSS, r-component, > q-component, f-component) > GETS BACK a string that includes q-component and=20 > f-component as appropriate > and returns that to wherever it goes >=20 > with "string" in both cases being more or less the hier-part of > a URL for case (b) (and I don't know how to think about (a) and > (c), much less others). The resolution model I am using/proposing is: urn: URI gets parsed into NID, NSS, r-component, q-component, = f-component generic-engine CALLS resolver(NID, NSS, r-component, q-component): resolver calls resolver-for(NID) IF NID-specific resolver exists, then NID-resolver(NSS, r-component, = q-component) ELSE (NID, NSS, r-component, = q-component) =3D> GETS BACK text/uri-list client can choose which URIs to use and dereference. The text/uri-list = only contains URI productions [RFC3986] (no relative-ref productions). If URI does not have f-component in text/uri-list, the final URI (with = fragment) is the URI in the text/uri-list and the fragment that is the = f-component of the original urn: URI. If URI has f-component in text/uri-list, the final URI (with fragment) = is undefined. As I have stated before, I have proposed eliminating q-component, making = everything r-component. In the algorithm above all functions take = (r-component, q-component) together, and return URIs that have query = components. That is the logical premise on why separating r-component = and q-component isn=92t necessary. Actually, I have proposed: urn: URI gets parsed into NID, NSS, r-service-component, = r-authority-component, r-params-component, f-component generic-engine CALLS resolver(NID, NSS, r-service-component, = r-authority-component, r-params-component): resolver calls resolver-at(r-authority-component) IF EXISTS, THEN resolver-at-authority(NID, NSS, r-service-component, = r-params-component) ELSE: resolver calls resolver-for-service(NID, r-service-component) IF EXISTS, THEN service-resolver(NID, NSS, r-params-component) ELSE: resolver calls resolver-for(NID) IF NID-specific resolver exists, then NID-resolver(NSS) ELSE (NID, NSS) =3D> GETS BACK text/uri-list (Note that in this proposal, r-params-component has no semantics apart = from what r-service-component provides.) Sean= --Apple-Mail=_BE1F2811-73CC-4BB4-A2FA-10BFE3E523B4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTAyMjMwMzI2WjAjBgkqhkiG9w0BCQQxFgQUAVR3ibJTM4YRkROUqmb5wZH5FfAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAHhdHb8ICMWFBsCZ4zmWxzeGjsfy7BW8SS+VeV3bUtZ33D1cFGR7l1XZAFwTqzFqsTYo U1lAEVQqEZrvpfZSocjxZGTrDVeKRotR2/QKbeJchr/ULcSYF5Q0SfI60lh462XraOp92fJf97ZB OXn4l+pZ79vpPyQK/IrX6nSyukKfpcz8unVIatye/LxBVYE+m2jiAGiX14m7oGpIVshvOyieuUj5 9ndLhkL2lxxD4qf+bpsk7rovuWHtgMEdVpJmK5H/aHShBlItL8x54Ys6M5RX338xSqBg9jhply+9 ze/ajbtzohhCBXt33Wl1sF2wKvdGZ7JUYTz78QkeVVNNtE4AAAAAAAA= --Apple-Mail=_BE1F2811-73CC-4BB4-A2FA-10BFE3E523B4-- From nobody Mon Nov 2 17:42:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9221B2B54 for ; Mon, 2 Nov 2015 17:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjlIfGVJKy9e for ; Mon, 2 Nov 2015 17:42:32 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE221B2B4D for ; Mon, 2 Nov 2015 17:42:32 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtQcI-000FqN-CZ; Mon, 02 Nov 2015 20:42:30 -0500 Date: Mon, 02 Nov 2015 20:42:25 -0500 From: John C Klensin To: Peter Saint-Andre , Sean Leonard Message-ID: <8FE8331AD32AB8E2A6FB74F3@JcK-HP8200.jck.com> In-Reply-To: <5637E38E.2050704@andyet.net> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> <5637E38E.2050704@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:42:33 -0000 --On Monday, November 02, 2015 15:28 -0700 Peter Saint-Andre wrote: > On 11/2/15 3:17 PM, Sean Leonard wrote: >... > >> On Nov 2, 2015, at 9:29 PM, John C Klensin >> wrote: >> >>> The problem with doing it in a Wiki is the same as the >>> problem with "tutorials" about a standard that are produced >>> by the body that produced the standard: because they are >>> almost inevitably easier to read than the standard itself >>> (if only because of the details that are left out), they >>> tend to become the standard in practice. >> >> Then put a disclaimer at the top of the Wiki that this is >> just for brainstorming and discussion only, and delete the >> Wiki when done. >> >> If the Wiki is easier to read than the standard document, >> that's an indictment of the standard document. Don't >> choose things because they are more difficult to use. No, it is at least as often the result of the tutorial making simplifying assumptions or leaving things out while the standard really has to cover all of the cases. >> Look: the alternative is what is happening here: years and >> years of endless discussions by e-mail with various points >> brought up again or rehashed in variant form by different >> participants. > I don't think that using a different tool will magically help > us through this impasse. Pointing to a wiki page isn't all > that different from pointing to the list archive. Mostly agreed. To clarify my concern, had Sean said "issue tracker" I wouldn't have objected significantly. My concern about a Wiki page is almost exactly the same as my objection to pointing to the list archive: neither is authoritative in itself and both can be taken over by anyone with a lot of energy and time on their hands (whether long-lived or not). While either can provide evidence that something was discussed, neither provides ready organization of material in a way that highlights what issues have been closed out and which ones are still being actively discussed or, worse, had the discussions fizzle out without resolution but left in a state where it is perfectly reasonable to bring them up again and start over. best, john From nobody Mon Nov 2 17:44:32 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9661B2B63 for ; Mon, 2 Nov 2015 17:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfShdRSB5ShN for ; Mon, 2 Nov 2015 17:44:29 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494551B2B62 for ; Mon, 2 Nov 2015 17:44:29 -0800 (PST) Received: by wmeg8 with SMTP id g8so3419466wme.1 for ; Mon, 02 Nov 2015 17:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=3yODdohplwjYYAOP/Ai8fyzc/bCnT/yibFTH8h6voHY=; b=eLQW+Z4A1mm2nlPgrnG3oBZFR/q/k29sjuE5dlqMd/mV7TRLxyT4EhJ9hnYcTIZLhK ZwicASOBRjFsISFo8S81nlqRPkov6AxSmY8FhSR66p/kRZHFc5gi8RGG+dCfZyrHocCi xrp++GY+EQGiZ52sK2oMDskL/f73I/abKhrjnminaZJuZSQHfD7ei6sDecWxfWMnDicg ltA0lqbceDPROibyg/qr7L6NcNLqppU7ZRVDkRD5X52ksSW+NiPDRFXBhFD+pUTJUpKL AhY7+0Sy0+V+/+RnWk0wjLL6f+NFs5c8slNIKOxfTYNOTUEVskG55foBRaKFHzj5NpdE IrWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=3yODdohplwjYYAOP/Ai8fyzc/bCnT/yibFTH8h6voHY=; b=QApaeATuCK6lxL2lIdCXh4zT61K/BAhYAte7dv9fp0JiQp2M3T0GnYhZuWHjqhcfKu 12p+yiBwmr3qFDOhTIcnYm8SqIWgqug0IjFUzFI0SEsNg4c1YuKrWS6AdtHQFxMO6pr4 kmGtAIZOoZ85jQsgCaB/OWdDOs8UijW7qiNA4iTeLTWZk9Jg+5Msazqb6ml6+MTzf7Nc p9OR+KNMO9aXkay5xTK0sNarQCxwGmoEGfXD56ddex21H5UcF4CFUAnEu1O8G5ZrDaL6 5WsEZqCfyFy83OSTgX6bNO/BamjKJvJRbHoiTkR7oHjZUMfhUInVkw/BJOeBu7J+y+dv Cp9g== X-Gm-Message-State: ALoCoQlaXwSaJ0PTG/H92NyhmYLJCJJop+gw2LFHWHmOWcyiFGvIhh+7zrfjS+WpeEaZi2mrr+uI MIME-Version: 1.0 X-Received: by 10.28.23.208 with SMTP id 199mr15494654wmx.11.1446515067857; Mon, 02 Nov 2015 17:44:27 -0800 (PST) Received: by 10.194.91.134 with HTTP; Mon, 2 Nov 2015 17:44:27 -0800 (PST) X-Originating-IP: [2001:c40:0:3024:d88:b051:3d8c:db8b] Date: Mon, 2 Nov 2015 20:44:27 -0500 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [urn] Are we at an impasse? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:44:30 -0000 All, Recent discussions have intertwined multiple issues, and I need to make some observations as co-chair regarding what may or may not be an impasse. It is my opinion that we are not there yet. 1) Discussion of reworking the model of r,q, and f components at a fundamental level will simply end this working group. Too much time and energy has been spent on the current approach that if we come to a conclusion that we made a mistake then it is inconceivable there remains sufficient momentum to start over. I'm not making this statement as a chair edict but rather noting the highest likely outcome of arguing for such a fundamental change. 2) As co-chair, I am asking that the document authors address the syntax issue as best they see fit, and that the rest of us abide by their technical decision. 3) With regard to a universal URN processor... well, that topic deserves its own thread. I'll send a separate message on it. -andy From nobody Mon Nov 2 18:21:55 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E061ACD92 for ; Mon, 2 Nov 2015 18:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYNQoFc01M4L for ; Mon, 2 Nov 2015 18:21:54 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4D91ACDA9 for ; Mon, 2 Nov 2015 18:21:12 -0800 (PST) Received: by wicfx6 with SMTP id fx6so60984316wic.1 for ; Mon, 02 Nov 2015 18:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=QoIvL9p23RUhzi/rtbBwtxdrgbkTP/NuQCSbnFX6d9o=; b=FK1AwSX/+I3CLvWRpw6HLqeGOfefrgiG6qSqLs2FpHW+0xO23lmHxqR5oH+2vIKq+S yNNYPWxyqIVMLh14t5VW3GLjSsvR9H/701L2ViQuNX6CMXajNGxbhOTyAA55vnx/c8d8 WzdGBy6EWN5X7sDuLRvCglR0TXZeg3DEj3LpS63YOI3XMKeZbaaLTo8kNOg1OQF0ClOV PAFQZA++2UNNgTjffZTfFL0mrJ+UHLs0GZ+Ph8FqqXbuSR7ixLSW9RhZ6BLI8LvV5n4j T6dhV0tnCupvkYFAYeJL1NsSYr9cKNLXBlqNn6yzhsqoApj0gZEuLa0NndK8/FOAWWzz bsyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=QoIvL9p23RUhzi/rtbBwtxdrgbkTP/NuQCSbnFX6d9o=; b=V0cReq9A0DAP87HPc+8zpAPgWvIVaWhT/pbNcth4dTdrYby/FdFed7x66hjgXxVT/s dqI1PDO1K0JBO61qZtxLeWTY1lAHZUj9xlwjD3Dh9lkuqUa3rCkV/ViObgIY8RXIL0pL HzNnTvtFTqegVNYwmK6ictSyJmMKS05cOPmfNcgjsCnlX+k3a3oHMsGhxnrBOLOU2zoa jewMLgEqk576u+MoKKOPHRC0g7tXKPxGus8WExmHH7I3ejIW5D+i3Dgl5OQzGtY3Qkqw DAgxLnRzN3b3EhWGdSltZj0RfxOF4dHjjG6Bsu6IMiszyYyARwUxD7ta69jhDHwiPxTk PE5A== X-Gm-Message-State: ALoCoQn9SKnbm784wnjIV6lQGI365N69hnoIPmuP5EoBQXHJTsabeqHgD+pwSDRxd0get1DFO/4D MIME-Version: 1.0 X-Received: by 10.194.114.135 with SMTP id jg7mr26588393wjb.11.1446517271533; Mon, 02 Nov 2015 18:21:11 -0800 (PST) Received: by 10.194.91.134 with HTTP; Mon, 2 Nov 2015 18:21:11 -0800 (PST) X-Originating-IP: [2001:c40:0:3024:d88:b051:3d8c:db8b] Date: Mon, 2 Nov 2015 21:21:11 -0500 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:21:55 -0000 The topic of a generic or universal URN resolver has come up in the past, and I had thought we had brilliantly side-stepped the issue. But it appears we have not. It is my view that there is a difference between a generic or universal URN resolver capable of resolving all types of URNs and a standard for URNs capable of conveying different, definable components of a URN to URN processing software where relying processes have URN specific behavior. Or in other words, the development of a specification for a generic URN resolver is not the same thing as avoiding namespace specific URN syntax. To my knowledge, there never has been a generic URN resolver. And while that may have been a design goal at one time, the reality is that URNs are a sufficiently large and broad concept that such a critter is highly unlikely to ever exist. None of us can predict the future, but I'm willing to bet cash money on this prediction. Therefore I suggest we discontinue any focus on one. However, it does seem worthwhile to have a specification where namespace specific knowledge is not required to pull apart the components of a URN. A URN parsing library should be able to provide to client processes the various components of a URN, even though the meaning of those components are only meaningful in the context of a specific namespace or resource. So here is a question to the working group. Does this distinction define the correct goal (URN parsing) and non-goal (generic URN resolver)? -andy From nobody Mon Nov 2 18:29:41 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88F11ACDF6 for ; Mon, 2 Nov 2015 18:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqgUoSafjb5P for ; Mon, 2 Nov 2015 18:29:37 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F181ACDF1 for ; Mon, 2 Nov 2015 18:29:37 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtRLp-000Fud-PB; Mon, 02 Nov 2015 21:29:33 -0500 Date: Mon, 02 Nov 2015 21:29:28 -0500 From: John C Klensin To: Sean Leonard Message-ID: <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> In-Reply-To: References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:29:40 -0000 Sean, I think, modulo some ways of thinking about the issue and consequent terminology, we may be in agreement with each other after all... but not in agreement with Keith if I correctly understand him. Specifically... --On Tuesday, November 03, 2015 08:01 +0900 Sean Leonard wrote: >... >> That, in turn, suggests to me that, >> from the following category-descriptions, one can have valid >> URNs in only one of them, not all three (or others) (ignoring >> for the moment whether I'm talking about the entire URN >> string (2141bis "namestring") or what 2141bis-14 calls an >> "assigned-name"): >> >> (a) Pure identifiers that do not resolve at all, but are >> merely tested for string equality. >> >> (b) URNs that map into ("resolve to") some sort of URL. >> >> (c) URNs that identify a (presumably digital) object in >> some other way. For example in that regard, assume a >> URN that names a particular text but, without embedding >> a DOI string in the URN namestring, resolves to a DOI. >> Whether that DOI is then made part of a URL (in doi.org >> or elsewhere) is not a URN definition problem. Similar >> examples would apply to URNs that name or refer to >> library objects but that resolve, not to a URL but to an >> accession number or shelf location. >... > I can't speak about DDDS. But I think that (a), (b), and (c) > are all valid URNs. No complaints about that model or what the > WG already established. Good. Agreed there. > Some resolutions will naturally be specific to and defined by > the namespace (or sub-namespace, if so inclined to view things > that way). For example: > > urn:xmlns:foobar2015 > > is meant to represent an XML namespace. If resolved and > dereferenced, it is supposed to always return an XML schema > (.xsd, application/xml or text/xml), namely the XML schemas > that are registered with IANA on a first-come, first-served > basis. Ok. > Most resolutions, however, are not specific to or defined by > the namespace. For or > , they could be > resolved in lots of ways (accession number, shelf location, > Amazon.com product page, data: URI, abstract pointer to > in-memory security object) and I believe that Keith's > essential points are that all of these resolutions are > contextually valid and that namespaces such as isbn: and uuid: > SHOULD NOT be read to restrict the resolution possibilities. I think we need to hear from Keith because I've understood some of his comments as wanting to prohibit resolutions that are namespace-specific. > But what's good for one set of identifiers may not be good > for another set of identifiers. And my argument is that even > though you could identify an XML namespace with > urn:xmlns:foobar2015 and then resolve it into something > utterly tangential to the original purpose (e.g., a picture of > cats), there really is no functional value in doing so. Ok. >... >> urn:ISSN:1046-8188 (from RFC 3044 Section 3.1) treats the NSS >> at the identifier within the ISSN namespace but >> >> urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637 >> (RFC 6963, Section 5) involves a "sub-namespace" that much be >> interpreted differently at some point rather than viewing the >> NSS as atomic. > > I object to this example on two grounds. > > First of all, it *is* a sub-namespace. urn:ietf:params, > urn:ietf:rfc, and urn:ietf:bcp, are sub-namespaces. A > sub-namespace is a subset of a namespace. > But urn:isbn:817525 is also a sub-namespace. Anything that is > a partial string is a sub-namespace because it divides the > namespace. Whether those divisions have namespace-specific > semantics is *defined by the namespace registration*. My point > is that urn:ietf:par is a sub-namespace because it forecloses > urn:ietf:pas or urn:ietf:pat. But it is not internally > significant, in contrast to urn:ietf:params:, which is > significant. In the case of urn:isbn:817525, that is a > significant sub-namespace because 81 is the group ID and 7525 > is the publisher ID. Therefore, everything starting with > urn:ietf:817525 will be titles published by the same publisher. I was trying to make a slightly different point about the difference between dividing the namespace into partitions that had their own rules about the rest of the hier-part of the URI versus single-element partitions. But I'm ok with your definition too -- please suggest specific text for 2141bis. > A generic URN processor does not need to care about these > internal divisions. An urn:isbn: specific processor might > actually care. Yes, I hope. >... > The resolution model I am using/proposing is: > > urn: URI gets parsed into NID, NSS, r-component, q-component, > f-component generic-engine CALLS resolver(NID, NSS, > r-component, q-component): resolver calls resolver-for(NID) > IF NID-specific resolver exists, then NID-resolver(NSS, > r-component, q-component) ELSE > (NID, NSS, r-component, > q-component) > > => GETS BACK text/uri-list Quibble: If "text" is interpreted broadly, then "uri-list" is just a subset and should not be an "or"-type conditino (or do I misunderstand your notation as ABNF-like?). If "text" is interpreted narrowly, then I think the above implies that there are two sorts of URNs (whether NID-specific resolvers exist or not): those that, when resolved, return text and those that, when resolved, return one or more URIs. That excludes both those that don't resolve and those that resolve to something other than URI(s) or text. More important, while it is possible to make a clear statement about whether the resolver in "resolver(NID, NSS, r-component, q-component):" knows about a particular NID-specific resolver or not, making a statement about whether or not such a resolver exists requires a universal resolver-finder (aka a universal NID-> resolver mapper) from which a negative result implies "no NID-specific resolver exists". Taking the DDDS and URC concepts up tens of thousands of meters (perhaps high enough that their originators would not recognize them because I'm about to suggest something with with they might disagree), the idea was precisely to have a universal resolver-finder: one could get a URN, look the NID up in the DNS, and get back either one or more pointers to resolvers with preferences, structure, and relevant properties (providing a reliable existence test) or fail (with whatever implications that had). But, for better or worse, while URNs have caught on, neither DDDS nor URCs have seen enough adoption for use with URNs to be relevant as candidate universal-anything. > client can choose which URIs to use and dereference. The > text/uri-list only contains URI productions [RFC3986] (no > relative-ref productions). I'm happy to see you prohibiting relative-refs (and hope we never have to revisit that topic), but, again, the apparent restriction to URNs that resolve and resolve to URIs is troubling... and appears to me to contradict your acceptance of all of my (a)...(c) as valid. > If URI does not have f-component in text/uri-list, the final > URI (with fragment) is the URI in the text/uri-list and the > fragment that is the f-component of the original urn: URI. If > URI has f-component in text/uri-list, the final URI (with > fragment) is undefined. Not sure I understand this. I would have guessed you were heading toward exactly the opposite... unless you mean to say that, unless the resolution mechanism knows what to do with fragments, the fragment applies to the URN-string and not to the result. If the latter is what you intend, people who claim to be experts on 3986 have claimed it violates that spec because that spec requires that fragments belong to the finally-resolved object (presumably not even the URI but the object located by that URI). > As I have stated before, I have proposed eliminating > q-component, making everything r-component. In the algorithm > above all functions take (r-component, q-component) together, > and return URIs that have query components. That is the > logical premise on why separating r-component and q-component > isn't necessary. See above with regard to URNs that do not resolve to URIs and my prior note about other sorts of requirements. > Actually, I have proposed: > > urn: URI gets parsed into NID, NSS, r-service-component, > r-authority-component, r-params-component, f-component > generic-engine CALLS resolver(NID, NSS, r-service-component, > r-authority-component, r-params-component): resolver calls > resolver-at(r-authority-component) > IF EXISTS, THEN resolver-at-authority(NID, NSS, > r-service-component, r-params-component) ELSE: > resolver calls resolver-for-service(NID, > r-service-component) IF EXISTS, THEN service-resolver(NID, > NSS, r-params-component) ELSE: > resolver calls resolver-for(NID) > IF NID-specific resolver exists, then NID-resolver(NSS) > ELSE (NID, NSS) > > => GETS BACK text/uri-list > > (Note that in this proposal, r-params-component has no > semantics apart from what r-service-component provides.) And that, fwiw, takes us even further down the path to which I understand Keith is objecting: a lot of namespace-specific syntax and semantics. We've also been there a very long time ago: the syntax models were different, but I think that, functionally, the idea of separating information or specifications about the resolver (or resolver service), from information or specifications for the resolver and authority, from parameter information to be passed to the resolver (which might, in turn, include things that a resolver would pass to an object or included in an output URI) was present in the very first "structure the query and reserve some sets of keywords" ideas that I sketched out (with a lot of help from Juha) in around the IETF 85 timeframe, well prior to Peter's suggestion of q-components and r-components. That idea of forcing query syntax for all URNs (that used them at all) into name=value pairs and then taking advantage of clusters of reserved name keywords was, in retrospect, not a good idea, but the intent was, if I understand you, very similar to where you are trying to go with the above breakdown. Another idea I thought we had closed out. best, john From nobody Mon Nov 2 19:39:16 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8E1B2C34 for ; Mon, 2 Nov 2015 19:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw2RgFiUgVOp for ; Mon, 2 Nov 2015 19:39:13 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697631B2C33 for ; Mon, 2 Nov 2015 19:39:13 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtSRD-000G5K-S6; Mon, 02 Nov 2015 22:39:11 -0500 Date: Mon, 02 Nov 2015 22:39:06 -0500 From: John C Klensin To: Andrew Newton , urn@ietf.org Message-ID: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 03:39:14 -0000 --On Monday, November 02, 2015 21:21 -0500 Andrew Newton wrote: > The topic of a generic or universal URN resolver has come up > in the past, and I had thought we had brilliantly side-stepped > the issue. But it appears we have not. > > It is my view that there is a difference between a generic or > universal URN resolver capable of resolving all types of URNs > and a standard for URNs capable of conveying different, > definable components of a URN to URN processing software where > relying processes have URN specific behavior. Or in other > words, the development of a specification for a generic URN > resolver is not the same thing as avoiding namespace specific > URN syntax. Yes, exactly, although I would have added "namespace specific semantic interpretations within the components of that syntax" to your list of things we probably can't nail down and shouldn't try. Put a bit differently and picking up on your terminology below, we can (and, IMO, should) be very clear about how to pull apart the various pieces of URN syntax (specifically into the NID, NSS, q-component, r-component, and f-component pieces specified in 2141bis-14) but that we need to accept that there will be namespace-specific syntax and semantic interpretations within those pieces (including whether a given one of the x-components is allowed and considered meaningful). If we can draw the boundaries there, I think we can succeed. If we have to specify very much about the interpretation semantics of the NSS or the q-component or r-component pieces, I have almost the same reaction you do to revisiting q-components and r-components: I don't think the WG can survive such a process. > To my knowledge, there never has been a generic URN resolver. > And while that may have been a design goal at one time, the > reality is that URNs are a sufficiently large and broad > concept that such a critter is highly unlikely to ever exist. > None of us can predict the future, but I'm willing to bet cash > money on this prediction. Therefore I suggest we discontinue > any focus on one. Yes. And thanks. > However, it does seem worthwhile to have a specification where > namespace specific knowledge is not required to pull apart the > components of a URN. A URN parsing library should be able to > provide to client processes the various components of a URN, > even though the meaning of those components are only > meaningful in the context of a specific namespace or resource. Yes. That is consistent with the above and with what I believe Peter and I have been trying to do (in our loosely coordinated way) with 2141bis. Again, if people find things in -14 that seem insufficient to that goal, I wish they would point them out quickly and ideally provide draft text. > So here is a question to the working group. Does this > distinction define the correct goal (URN parsing) and non-goal > (generic URN resolver)? My opinion is "yes", again with "URN parsing" interpreted as breaking what 2141bis calls a "namestring" into the three components of and the q-, r-, and f-components. john From nobody Mon Nov 2 22:40:13 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D211B2E5E for ; Mon, 2 Nov 2015 22:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSUy6JgsM6bZ for ; Mon, 2 Nov 2015 22:40:07 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280D71B2E43 for ; Mon, 2 Nov 2015 22:40:06 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1AFB5209A3 for ; Tue, 3 Nov 2015 01:40:06 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 03 Nov 2015 01:40:06 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=LWbRQ3dGiyYzTtJ ysHJxQ9ffnL8=; b=i1BpZ67ilLUfT/x7RFTaYNqWDSbv5gfLDSVCiMQ9zYaAEcf BFpEceg+cJ/L/FnbwiZq3eJ4RwBlVP79P8fk1P/oLTUc63hpk8WyCYTxurljhifm 0O8SGGDchRKNfDinvcnGWT4Zks5UN5VV5FicdiNDFCcIeJwh0pVhG47bJmGI= X-Sasl-enc: uaHTbsLAtBMrNsS0NvIm2HVsJBnWlsvyyxufDNNbHHAs 1446532805 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B262C016F3; Tue, 3 Nov 2015 01:40:05 -0500 (EST) To: John C Klensin , urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> From: Keith Moore Message-ID: <563856A9.6020509@network-heretics.com> Date: Tue, 3 Nov 2015 01:39:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 06:40:12 -0000 On 11/02/2015 10:37 AM, John C Klensin wrote: > > --On Monday, November 02, 2015 08:11 -0500 Keith Moore > wrote: > >> ... >>> I mostly agree with that too, but I think we need to be >>> careful and reasonable. Perfection is impossible and not >>> every detail is important (hugely or not) and I would hope >>> that any "this needs to be fully specified and/or fixed >>> before the document(s) can go into WGLC" statements would be >>> accompanied by an explanation for that particular case as to >>> why. In particular, if there are things we are going to >>> leave to the discretion and needs of individual namespaces (I >>> think, given the nature of URNs, that is inevitable and >>> consistent with 2141 and earlier documents), then it is >>> important to be clear about the boundary but anything we say >>> beyond that has to be in the form of non-normative examples. >> It's that kind of language that makes me worry. I am very >> skeptical that leaving things to "the discretion and needs of >> individual namespaces" is at all appropriate. It is >> essential that clients be able to process URNs without having >> to know details about specific namespaces. Saying we can >> leave things to namespace discretion seems basically like a >> failure to do our job in creating a standard. > This is precisely the kind of disagreement (whether apparent or > real) that I think needs to be exposed, discussed, resolved, and > then taken sufficiently off the table that attempts to reopen it > are strongly resisted by the WG. If we are to make progress, > that is true independent of which of us are correct. Naming is inherently a difficult topic to discuss because (as computer scientists like to say) all problems can be solved by adding another layer of indirection. It follows that any time someone proposes a new kind of name, particularly something as vaguely defined as "uniform resource name", anyone can imagine his particular problem being addressed by that naming and indirection scheme. What seems to have happened for the entire history of URN discussions is that different participants each imagined URNs addressing the particular problem that he or she wanted to solve. As long as the URN definition focused entirely on syntax and "persistence" (vaguely defined), the conflicts between those goals were not exposed. But as soon as we talk about resolution, the conflicts rear their ugly heads. Some would like to finesse those conflicts by simply declaring resolution a namespace-dependent behavior. I don't think that accomplishes anything because it doesn't facilitate interoperability. If we can't define URN standards with sufficient precision to permit interoperability, what's the point of this effort? I believe that we can do so, otherwise I wouldn't be investing time in this. I should define what I mean by interoperability in this space. A few things that immediately come to mind: a) interoperability across namespaces - a client that supports operations on URNs should be able to support those operations for URNs of any namespace, as long as resolution services for the namespace adhere to one of a hopefully-small number of standards, and those resolution services are advertised and accessible to the client. b) interoperability across clients - if two standards-conforming clients both support URNs, they should behave similarly when given the same URN and the same request for use of that URN (whether specified in the r-component of that URN, by context, or by some other means). c) interoperability across resolution services - it should be possible to design a resolution service protocol that serves the needs of most if not all NIDs, and also possible to implement a server for that protocol that serves the needs of most if not all NIDs. This, to me, implies that namespace-specific behavior should be kept to a minimum, or at least, that it should be possible for a client to implement common operations without relying on either specific knowledge of namespaces or nonstandard features of resolution services. If there are additional operations that are possible by exploiting such namespace-specific knowledge or nonstandard features, that's not a catastrophe especially if it there is a path that facilitates standardization of the necessary features. > Now, let me be sure that I understand what you are suggesting. > If a "client" has to be able to "process URNs without having to > know details about specific namespaces", that means to me that > one cannot have per-namespace "resolvers" or resolution > mechanisms, i.e., that, if any URN is resolvable, all URNs must > be, and that there must be a generic resolution mechanism that > works for all URNs and that, moreover, that there be no > namespace-specific resolution machinery to be applied for any > namespace after that generic resolution mechanism does its job. I don't believe that. In particular, I expect to have a DDDS-like database, that is distributed by various means (not necessarily or specifically DNS), that advertises (namespace-id, protocol, service-URL) tuples, where protocol is an IANA-registered URN resolution protocol identifier, and service-URL specifies how to contact the resolution service (the details can be protocol-specific). If DDDS is insufficient for this, replace it. But even if DDDS has some specific flaws, the core idea of distributing this database over the network is sound. (And maybe we need those tuples to be slightly more elaborate, or to be a different data structure, in order to facilitate earlier matching of resolution services with the assigned portion of URNs and the requested services. So this is more of a concept than a proposal. I'm trying to avoid having to draft protocol specifications for both the database and the resolution services just to answer this email.) > That, in turn, suggests to me that, from the following > category-descriptions, one can have valid URNs in only one of > them, not all three (or others) I don't believe this either. A resolution service advertised by the above means should be able to return both URLs of resource locations (when applicable) and various kinds of metadata about the resource (when applicable). > My impression was that the WG agreed to the validity of all of > those three casss as URNs long ago, at least for the second and > third probably about the time we decided that DDDS was _a_ way > to resolve _some_ URNs but not a necessary element of a generic > URN system. Well, of course _some_ URNs aren't resolvable, or even intended to be resolvable. So any time you ask a resolution service about a particular URN, one of the potential answers can always be "I don't know anything about that URN". The existence of a resolution service for a namespace doesn't assure that all URNs from that namespace are resolvable. > However, one doesn't even need to look to 2141bis and history > since 2141 (May 1997) or 2483 (January 1999) to have that > per-namespace problem. > > urn:ISSN:1046-8188 (from RFC 3044 Section 3.1) treats the NSS > at the identifier within the ISSN namespace but > > urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637 > (RFC 6963, Section 5) involves a "sub-namespace" that much be > interpreted differently at some point rather than viewing the > NSS as atomic. Presumably urn:ISSN:foobar:9999-9999 would be > considered a syntax error. At least something > namespace-specific would want to reject it rather than passing > it on to some resolution machinery. URNs namespaces have always been able to have structure within the NSS. Also, each namespace has always been able to define its own particular syntax for its NSSs, and also particular equivalence rules for its NSSs. I'm not proposing to change those decisions. But it's not strictly necessary to advertise each namespace's structure, syntax, and equivalence rules to every client. If a client queries a resolution service about a URN that happens to be invalid, the resolution service can say "I don't know anything about that URN". Or it can say "that URN is malformed" if it knows enough to say that. Or it can say "I can't answer your query, but I can refer your query to resolution service X which should have specific information about that URN". Similarly, a client could ask a resolution service whether two URNs from the same namespace were equivalent according to that namespace's rules. As an optimization, some information about the structure of an NSS or how its queries are delegated, or the equivalence rules for a namespace could be advertised by some means. This might reduce load on the resolution servers. In the 1990s, we tried using regular expression rewrite rules to advertise those sorts of things; today we might try a different approach. Worst case, the namespace database could advertise a separate javascript library for each namespace that could be called to pick apart delegation structure and/or determine equivalence. It's not my favorite approach (and might even have more pitfalls than NAPTR records) but I'm open to considering different ways of doing it. > Because of that, I think 2141 itself works iff one uses generic > URN processing to identify the NID and then passes the NSS off > to an NID-family-specific processor (I say "family" because I > don't believe we will have, or should have, separate processors > for each NID even though I expect the total number of processors > will be much larger than one). I hope the total number of resolution protocols will be small, though I never expect it to be one. There can of course be a great many resolution services, both for redundancy and to serve multiple NIDs or subspaces within an NID. > > Now, if you agree with the above, I've very confused about what > you are talking about or where the boundaries lie. In > particular... > >> I do accept that different resolution services will probably >> recognize somewhat different sets of r-parameter facets and >> offer somewhat different kinds of metadata, if for no other >> reason than that these need to be able to evolve over time. >> But I don't think this is a namespace-specific attribute, but >> rather an attribute of the resolution service. > Again, that completely confuses me, at least in part because I > think that a generic URN processor can be expected to do only > three things: > > (i) Parse the namestring, identifying the elements of > and .[1] > > (ii) Try to find an appropriate resolution service based > on the NID. If it cannot find one, do something > reasonable [2]. > > (iii) If it can, identify a resolution service that it > understands [3], pass the NSS, and any of q-component, > r-component, and maybe f-component that are present, > to the resolution service [4]. I disagree that these are the only things that a generic URN client can be expected to do. I agree that (i) and (ii) are reasonable expectations. Beyond those things, I think a generic URN client should be able to (iv) request URLs that represent locations of the resource named by the URN (which will be returned by the resolution service only if the request is applicable to that kind of resource, the resolution service has the information, etc.) (v) obtain the content of the resource named by the URN (again, when applicable for the resource named by the URN, when a resolution service has that information). (vi) learn about the kinds of metadata that are available for that URN (vii) obtain any specific kind of metadata that is available for the URN This implies that the client needs to be able to parse the r-component to determine the type of service being requested, as well as any constraints that the r-component imposes on resource content. It's also possible to have a conflict between a service requested in an r-component and the service that's implied by the context in which the URN appears, so clients may need to detect some of those conflicts. I also disagree significantly about (iii). Neither the q-component nor the f-component should be passed to a resolution service UNLESS, perhaps, the resolution service is being requested to return the resource content - and even then, passing the f-component is dubious. You really don't want the resolution service trying to interpret q-component or f-component. It strikes me as the worst kind of layering violation, because it blurs an otherwise clean separation between the responsibilities of a URN namespace and the responsibilities of the resource owner/maintainer. (I'm also skeptical that resolution services should ever be entrusted to return resource content, though I recognize that there are probably corner cases for which this makes sense.) > Note that the above implies that the semantics and within-string > syntax of r-component and the handling of q-component are mostly > the problem of the resolution service. r-component - mostly but (unfortunately) not entirely. q-component - it's not for the resolution service at all, but exclusively for use by the named resource. > Because we expect the > resolution service to digest r-components, we don't need to be > as specific about its within-string syntax as we do about > q-component (or f-component), which, at least as I understand > our definitions so far, we expect to be passed more or less > intact from the resolution service. I believe we do need to be somewhat specific about r-components because clients will need to digest them to some degree. q-components and f-components should never be passed to the resolution service. > >> Can you cite examples of things that need to be left to >> namespace discretion? > Whether the namespace is resolved at all. I think I see your point, though I believe private "resolution" services will be very important. (Call them something other than resolution services if you want, but they should support the same protocols and operations.) So the namespace can decide whether or not it wants to advertise "authoritative" resolution services, but it can't forbid private resolution. > Whether sub-namespaces are allowed. Sure, each namespace determines the structure of its NSS (including whether there is any). Though I find myself wondering whether you're talking about NSS structure or delegation structure, which don't have to be along the same lines. > Whether q-component and/or f-components are consider valid. Disagree. Whether q-component is valid depends on the type of resource being named and/or the protocol being used to access it. A namespace can elect to not assign names to any resources for which a q-component could possibly be valid (e.g. it could only assign names to paper books or physical sound recording media), or it could elect to not return any URLs which support query syntax. But the meaning of the q-component is namespace independent, and it's important that this be made clear. Similarly, the meaning of the f-component is entirely dependent on the media type of the resource and the content itself, and is not within the purview of the namespace to define. Even if a namespace refuses to assign any of its names to any resources that contain fragment identifiers, there are fragments that are meaningful even in the absence of fragment identifiers in the resource content. For better or worse, this is the web architecture, and we aren't going to change that. > Whether r-components are accepted and what syntax and semantics they have. Disagree. R-components need to be standardized, at least in broad terms, because clients need to be able to interpret them to some degree. Furthermore, it appears that clients may need to be able to add r-components to URNs in order to request the services that they need (e.g. to get resource content or URLs or metadata) in the absence of an explicit request in the r-component. And even though there might inevitably be a need for some namespace-specific requests that can be included in an r-component, resolution services will need to support a "common core" of r-component requests and semantics. > (i) Parse the namestring, identifying the elements of > and .[1] > [1] Given the way URIs are defined, this is actually a rather > difficult problem because, whether there are generic URI parsers > or not, there is really no such thing as a generic URI (or even > URN) resolver that can encounter and generically report error > states. If I put "http:[[]]" into an href, any standardized > error-handling is part of the HTML spec (very much scheme and > content-specific) not part of either 3986 or, IIR, the http > spec. I hope we don't have a URK in our future named "fail" > whose hier-part is unspecified but might be an error message or > code, which it would be one way to deal with putative URNs that > cannot be parsed. Especially if we need to be as specific as I > gather you want (and as my instincts tell me will probably be > necessary), I don't see how to avoid saying something about this > in 2141bis but don't, at the moment, know what to say. I'm not sure what you're saying here. A URI parser might not be able to detect every possible kind of syntax error in a URI, but it can certainly detect some kinds of errors. That parser can do no more (and should do no less) than to pass the error indication to its caller. What the caller does with that error is up to either the protocol specification being implemented by that caller, or to the implementation itself. If some kinds of syntax errors effectively get interpreted by the caller as "resource not found", that's perhaps unfortunate, but it shouldn't preclude a parser reporting more precise errors just in case some caller will handle them intelligently. Anyway, having written generic URI parsers that seemed to be sufficient to the task, I don't really see the problem here. > (ii) Try to find an appropriate resolution service based > on the NID. If it cannot find one, do something > reasonable [2]. > > [2] This is obviously a mess. It is the mess that NAPTR and > DDDS were intended to solve by creating a DNS-based indirection > mechanism for binding resolution mechanisms for NIDs, but that > has failed to achieve wide adoption and the WG (and the DDDS > specs themselves) have decided that not all URNs are required to > be bound to DDDS. Maybe that was a mistake, but the horse has > left the barn and vanished over the horizon. Even when DDDS was being hashed out, I don't recall anyone who expected all URNs to be required to be bound to DDDS. It wasn't a mistake, it was simply a consequence of other decisions and painfully-acquired understanding, e.g. (a) URNs weren't only to be used for network-accessible resources; (b) even among network-accessible resources, there would always be URNs that you couldn't resolve without access rights (and some for which the existence of the resource wouldn't even be acknowledged without access rights -- if I recall correctly Ron Daniel argued this quite convincingly); (c) some URN namespaces which we thought desirable simply didn't lend themselves to centralized collection of either locations or metadata. Also, many of us realized that DDDS was more of a proof-of-concept than anything else. We hoped we could get something deployed enough to show what could be done with URNs even though we realized that if it were successful, it would have to either evolve or be replaced. Also, even though the DNS realization of DDDS was the most obvious one, DDDS is not and was not intended to be specific to DNS. > I'm sure, based on > experience, that "look the NID up in the IANA registry in real > time" is not going to be acceptable operationally (even if there > were no other issues). Well, no, not if we're using the current IANA servers that are only provisioned and maintained according to current expectations. But we should all know better than to assume that. I imagine that IANA would maintain the registry but not run the equivalent of the root servers for real-time lookup of NID space. There are other ways of distributing that information than having IANA provide the service directly. For example, it could outsource that via a large-scale DNS service provider if DNS were still used to advertise that information (which is perhaps not the best possible way, but certainly not the worst, and probably can be made sufficient). Alternatively, it could provide the top-level NID-to-service mapping information to the public on a rate-limited basis - anyone could get the information but the response would be slow enough that no client implementation would want to use it to do the lookup in real time. Publishers of software using URNs could obtain the information and distribute the information to their customers via normal software update channels. I'm not saying I have the best answer right off the bat. I am saying that arguments of the form "DDDS failed, therefore no net-based distribution of the NID mapping information can work" don't seem to have much merit. At the very least, they need more detail and/or supporting evidence to be convincing. > The result is that I don't see any > alternative to doing some handwaving around "find a resolver > based on the NID and do something intelligent if you can't find > one" and then either assuming that "can't find resolver with a > reasonable amount of effort" means "this NID does not resolve" > or "need to return some sort of 'fail' indication". That makes > me _very_ unhappy but, given where we have gotten, I'm having > trouble figuring out alternatives that do not require inventing > a somewhat more general and flexible successor to DDDS and > insisting that all URNs be able to use it. For reasons alluded to above, failure will always be a possible outcome where URN lookup is concerned. I don't know why that should bother us, because while we expected that URNs could be used to name (almost) anything, we never expected to be able to build an oracle that could find every resource that could possibly be named. So: general and flexible successor to DDDS - yes; insisting that all URNs be able to use it - no. Maybe insisting that it be potentially applicable to most namespaces is a reasonable goal, but we can't force namespaces to operate or advertise resolution services or even recommend some services operated by others. And even if every applicable namespace operated a resolution service, they won't necessarily be able to populate their services with information about every URN assigned under their namespace (again, because of confidentiality requirements). > > [4] If we were modeling a process, rather than syntax and (at > least some) semantics, we could specify the difference between > > generic-engine CALLS NID-resolver(NSS, r-component) > GETS BACK > CONSTRUCTS (string, decoded-q-component, f-component) > and returns that to wherever it goes > > and > > generic-engine CALLS NID-resolver(NSS, r-component, > q-component, f-component) > GETS BACK a string that includes q-component and > f-component as appropriate > and returns that to wherever it goes > > with "string" in both cases being more or less the hier-part of > a URL for case (b) (and I don't know how to think about (a) and > (c), much less others). > > But we can't so, if we are are going to define a generic > resolution service, we are going to need to define what it can > return and probably the operations it performs to get there. I > don't think we can do that for the reasons that make the three > different URN cases identified above as (a), (b), and (c) (and > others) important. I don't see the problem. I think the NID-resolver gets called with the assigned-portion of the URN + the r-component, plus perhaps some additional client-supplied parameters indicating what the client wants and/or what protocol(s) and result data models the client supports (or maybe the client modifies the r-component to include its request). I think the NID-resolver returns either: - an error indication, - a redirect, - one of the types of result documents expected/requested by the client, which depending on the request might be a list of URLs, or a set of metadata, - or maybe even the resource content itself (though maybe that's a bad idea). So to me the resolution service is fairly simple in concept and can be defined as some HTTP FORM parameters: ?urn=urn:example:foo??some-r-component&request_type=xxx&result_types=(aaa,bbb,ccc) Of course, working out the details of the result documents and how the various kinds of results relate to one another is a huge task, though I expect that librarians and archivists are well along this path already. IETF will do well enough to establish a protocol framework, some basic request types, an IANA registry for result types, a generic syntax for r-components, and an IANA registry for r-component facet names. Defining client behavior is a bit trickier, because the client will need to handle several different scenarios in order to do what the user or requesting resource wants. To get resource content it might need to consult multiple resolution services, follow redirects, first get a list of URLs and then try to find one of those that satisfies its selection criteria (French language, PDF format). It might find that the requested resource isn't available but there is a related resource that is available (later version, HTML format instead), and determine whether that resource is acceptable. In some cases it can ask the user; in other cases it will have to decide based on predetermined preferences and/or heuristics. Keith From nobody Tue Nov 3 02:29:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDE11B31A0 for ; Tue, 3 Nov 2015 02:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 891Hjfsw3jBI for ; Tue, 3 Nov 2015 02:29:15 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BF11B3199 for ; Tue, 3 Nov 2015 02:29:14 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZtYq0-000H81-DD; Tue, 03 Nov 2015 05:29:12 -0500 Date: Tue, 03 Nov 2015 05:29:07 -0500 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <8C692BACD263F8DAB652A192@JcK-HP8200.jck.com> In-Reply-To: <563856A9.6020509@network-heretics.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <563856A9.6020509@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 10:29:17 -0000 --On Tuesday, November 03, 2015 01:39 -0500 Keith Moore wrote: > On 11/02/2015 10:37 AM, John C Klensin wrote: >> >> --On Monday, November 02, 2015 08:11 -0500 Keith Moore >> wrote: >> >>> ... >>>> I mostly agree with that too, but I think we need to be >>>> careful and reasonable. Perfection is impossible and not >>>> every detail is important (hugely or not) and I would hope >>>> that any "this needs to be fully specified and/or fixed >>>> before the document(s) can go into WGLC" statements would be >>>> accompanied by an explanation for that particular case as to >>>> why. In particular, if there are things we are going to >>>> leave to the discretion and needs of individual namespaces >>>> (I think, given the nature of URNs, that is inevitable and >>>> consistent with 2141 and earlier documents), then it is >... >> This is precisely the kind of disagreement (whether apparent >> or real) that I think needs to be exposed, discussed, >> resolved, and then taken sufficiently off the table that >> attempts to reopen it are strongly resisted by the WG. If >> we are to make progress, that is true independent of which of >> us are correct. > > Naming is inherently a difficult topic to discuss because (as > computer scientists like to say) all problems can be solved by > adding another layer of indirection. It follows that any time > someone proposes a new kind of name, particularly something as > vaguely defined as "uniform resource name", anyone can imagine > his particular problem being addressed by that naming and > indirection scheme. >... Keith, I found this very helpful in understanding what you are asking for. Rather than my responding with yet more over-long text now, could you read Andy's most recent text and respond to that as well? I'd like to see if we (all three of us) can converge by trying to separate your comments/requests into things that fit within the scope of that note and things that he suggests leaving out, but can't reasonably do that until I understand if you accept his general principles. If you do not, I should probably stop adding long notes to the conversation until you and he sort that out. As a preview, I completely agree with your initial comments about naming and the history of URNs and actually think I wrote very similar paragraphs in the past. There are other places where I think we appear to disagree only because I made what I thought were general comments or examples that I considered non-comprehensive that you apparently interpreted as a comprehensive listing and responded on that basis. That sort of difference should be easily straightened out and resolved. For example, you wrote > In particular, I expect to have a DDDS-like database, that is > distributed by various means (not necessarily or specifically > DNS), that advertises (namespace-id, protocol, service-URL) > tuples, where protocol is an IANA-registered URN resolution > protocol identifier, and service-URL specifies how to contact > the resolution service (the details can be protocol-specific). > If DDDS is insufficient for this, replace it. But even if > DDDS has some specific flaws, the core idea of distributing > this database over the network is sound. A non-DNS distribution mechanism for URNs has never been specified, much less deployed, and that, as far as I know (and much to my regret), we haven't had a reference or dispatching database associated with an element of major protocol successfully distributed by anything other than the DNS since (depending on what you count) we stopped distributing host tables or gave up on X.500. That (and some other remarks) concern me because it feels as if you are putting major new design work and consensus about it the critical path of progress on the current effort. However, that generalization of DDDS (or even an analysis, redesign, and successor) doesn't change my basic point: I believe that, if one is going to have a resolution method, or resolution-method-finder, that is namespace independent and works in a consistent way for all URN namespaces, then there either needs to be a single resolver that works for all URNs (an idea that was abandoned years ago, certainly before DDDS was specified) or that mechanism has to have access to a comprehensive database and query process that identifies a resolution mechanism for each URN. That hypothesis is true independent (or not) of how similar the database is to that anticipated by DDDS and to whether or not the query mechanism for the database is DDDS. It is also not dependent of just what information is in the database and how is is retrieved. best, john From nobody Tue Nov 3 15:24:11 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D151B35A7 for ; Tue, 3 Nov 2015 15:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2qvmR65jYe9 for ; Tue, 3 Nov 2015 15:24:08 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CFE91B3597 for ; Tue, 3 Nov 2015 15:24:08 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A7D5820A8C for ; Tue, 3 Nov 2015 18:24:07 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 03 Nov 2015 18:24:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=AchkUL8czvo291Q PpFpvrBcgZk4=; b=P4Bk0OeTx9j0TYu1wfSQcMWfjKUnx99KBxGiUdNFDzxhrqb uCh98OxnWjWUW3H4VNSzg73y/ShugkKqjXvRTfTxP2Gz3MUvzETu285Q3fx0BFxa ks2R0wD3fFZz3nO4BWtu6AB1QVxgVP+O7fTtwyAuTUc76gOxzsbv6tTuldAI= X-Sasl-enc: 2XkOSlqDVet0UX+Kb0882pXC2LBDmBMscZgrw6jiimcy 1446593047 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 4971F6801D3; Tue, 3 Nov 2015 18:24:07 -0500 (EST) To: urn@ietf.org References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> <1A1A7E70D89427063F516DE7@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <563941F9.6090209@network-heretics.com> Date: Tue, 3 Nov 2015 18:23:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Component delimiters X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 23:24:10 -0000 On 11/02/2015 10:14 AM, Andrew Newton wrote: > On Mon, Nov 2, 2015 at 8:02 AM, John C Klensin wrote: >> Thanks for touching off the "which delimiters" discussion even >> though I think we should resolve the other one first: if we >> prefer sticking with single and double question marks, the >> delimiter choice is a non-issue. > Sorry, that subtly of the proposal was lost on me. I'll blame it on > jet lag or lack of caffeine, because it certainly can't be that > navigating the discussions on this list are in any way difficult. :) > > So let me summarize what I think the issue is: we have not yet been > able to get '??' to work right in the ABNF. And therefore we have > several thought experiments which have ranged from just noting the > issue in the prose to trying harder to throwing everything we've done > so far away. Do I have that right? > > If I do, then here is the chair guidance: let the document authors > figure it out, and the rest of us just need to live with it. To me > this seems like a small matter that does not need endless discussion. > You and Peter can thumb wrestle or throw darts or whatever, and if you > decide to try to get the ABNF 100% perfect (and good luck with that, I > think I know the outcome), so be it. If you decide that an ABNF > comment or prose comment or both are appropriate, so be it. Or if you > decide that special character delimiters are needed, pick two and so > be it (and btw, I hate the two you picked but if that's where you want > to go, I'll live with my hate of ')' and ']'). > > I'm not trying to sound harsh to any discussion participants here, but > from my perspective this is a small matter we should trust to the > judgement of the document authors. I agree that this should not require a significant discussion. ABNF is entirely sufficient for this purpose, and it is indeed possible to write relatively succinct ABNF that unambiguously recognizes whatever syntax for r- and q- components we decide on. I'm happy to let the authors do it, but if they can't, I'm sure myself or someone else can. There are far more important issues at hand than how to represent the syntax in ABNF, and focusing on the ABNF seems like an unhelpful distraction. Keith From nobody Tue Nov 3 15:33:01 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB541B35F6 for ; Tue, 3 Nov 2015 15:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq5e1WwlmCmX for ; Tue, 3 Nov 2015 15:32:59 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70471B3606 for ; Tue, 3 Nov 2015 15:32:58 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 50D8A20A6D for ; Tue, 3 Nov 2015 18:32:58 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 03 Nov 2015 18:32:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=0h2kFkE30FcVMoO 9ymZpjiuPQ7A=; b=AUWnD9eGf/BatFZ2R38Ay3QqbVB/0jP9ySRdachmqyW6wYF YOaXtEyRU30R2XB48fTDjwgvRCeNOzoUIcXYm56vMPmMqp40Tz2Rlx7ofxT9uHQr lyrEE79FeZQ1IoLK9H1zbo6u2C2QBJ0VLM0iJepMmZG6MtZQP70TSCqvvlWo= X-Sasl-enc: HFqWyfIzeTfHcVUYeJsTE0CqDKMSPDmps7f8cIBwNxyx 1446593578 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id E304A6800C6; Tue, 3 Nov 2015 18:32:57 -0500 (EST) To: urn@ietf.org References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> <1A1A7E70D89427063F516DE7@JcK-HP8200.jck.com> <1ED292FC6724FDD8D8BCDA7E@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <5639440B.3050402@network-heretics.com> Date: Tue, 3 Nov 2015 18:32:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1ED292FC6724FDD8D8BCDA7E@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Component delimiters X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 23:33:00 -0000 On 11/02/2015 10:49 AM, John C Klensin wrote: > > Part of my "symptom of conceptual problem" concern is that I > think Keith (and maybe others) are convinced that we need to > rather precisely define the boundary between the appropriate > content for q-components and r-components (or get rid or one or > both). I am indeed convinced that we need to rather precisely define the boundary between appropriate content for q-components and r-components. I thought it was already understood and agreed to that the r-component needed to exist because there was a need to clearly separate the parameters passed to resolution services (r-component) from those passed to resources (q-component). The cases in which both will be used with the same base URN at the same time are IMO significant - basically any time it is desired to use a URN to name a service which takes parameters that are passed via a URL query. Getting rid of either r-component or q-component would IMO be a step backward. If we did that I'd have to wonder what value we were adding over RFC 2141. > I don't think so and maybe I misunderstand what Keith is > asking for -- see long note I just sent -- but, unlike some > details of syntax, I think decisions at that level need to be > made by the WG, not by Peter and myself. This is indeed a distinct issue from syntax, so it's important to not confuse the two issues. The choice of syntax is a relatively minor issue. It doesn't matter much what the syntax for r-components and q-components is as long as that syntax is unambiguous, and as long as the way that q-components are transferred to URLs (when applicable) is clear and likely to be implemented correctly. Keith From nobody Tue Nov 3 15:36:49 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30421B361E for ; Tue, 3 Nov 2015 15:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W5wQB8EnCWn for ; Tue, 3 Nov 2015 15:36:46 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37781B361D for ; Tue, 3 Nov 2015 15:36:45 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5CBC020DCD for ; Tue, 3 Nov 2015 18:36:45 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 03 Nov 2015 18:36:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=6ait/PoXnl7KXw+ Q+wBIErZHF5w=; b=czBJQrTOgX5MIB+cjpyy+LT0ZugIIr1Xbhok+U7vO7Aexvu eKA8tmHEK0WpASC7cc7/3B66Pv1gs/kD+sNhcqe1WrvflGYfHb5r9sabHLLI0ewb ehUU6H6zAFRBWe4jqXy19wTz+bZ1ftNjeJYM4Q4wTAlUzSgNrhJ3D7iUkPFM= X-Sasl-enc: kPxciWkYFYMb9/GdMtW73U1rLsofRUzxzVk1g0LZfG89 1446593805 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id ED5DBC016C4; Tue, 3 Nov 2015 18:36:44 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> From: Keith Moore Message-ID: <563944EE.3070603@network-heretics.com> Date: Tue, 3 Nov 2015 18:36:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 23:36:47 -0000 On 11/02/2015 05:17 PM, Sean Leonard wrote: > On Nov 2, 2015, at 9:29 PM, John C Klensin wrote: > >> >The problem with doing it >> >in a Wiki is the same as the problem with "tutorials" about a >> >standard that are produced by the body that produced the >> >standard: because they are almost inevitably easier to read than >> >the standard itself (if only because of the details that are >> >left out), they tend to become the standard in practice. > Then put a disclaimer at the top of the Wiki that this is just for brainstorming and discussion only, and delete the Wiki when done. > > If the Wiki is easier to read than the standard document, that’s an indictment of the standard document. Don’t choose things because they are more difficult to use. > > Look: the alternative is what is happening here: years and years of endless discussions by e-mail with various points brought up again or rehashed in variant form by different participants. It's hard enough to read through an email discussion. Trying to keep track of a Wiki discussion, or worse, a discussion that takes place partially in a wiki and partially in email, sounds like a task of Sisyphus. I'd be happy to find a better discussion medium than email (which actually seems to have become less effective in the last 20 years or so) but I don't think Wiki is it. Also, it seems like the last thing that this group needs to be dealing with is coming up to speed on new tools. Can't we try instead to focus on matters of substance? Keith From nobody Tue Nov 3 15:56:41 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7B41B2D3C for ; Tue, 3 Nov 2015 15:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7Jc6CF5zIVo for ; Tue, 3 Nov 2015 15:56:37 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DB21B340F for ; Tue, 3 Nov 2015 15:56:37 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8FB41209EF for ; Tue, 3 Nov 2015 18:56:36 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 03 Nov 2015 18:56:36 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=EIwKgJQTM5b2l1E 8/D0RQsdRNVE=; b=PxVHnvexgfUgpPVTNfatUpnRtRpqsnZhJ5BUDKOQ+NMZw+G 1U0IL98Pdmj9VV9oF9SCh54yAE/0flWAydE7Wd5ZoG8I5ZvJ5hvJhFxz+at1hg1l s3OeTWRuh9U0lm1p5X/4+0/DCgI8/SEilmo8LcTjYAZ7980Yyb/Ml5gQM36E= X-Sasl-enc: DSM7BSfaGxicZVyjFtMI3XNhHJNCc8P9tNBC1uSjCzo3 1446594996 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 2018AC016DB; Tue, 3 Nov 2015 18:56:36 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> From: Keith Moore Message-ID: <56394996.7000507@network-heretics.com> Date: Tue, 3 Nov 2015 18:56:06 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 23:56:39 -0000 On 11/02/2015 06:01 PM, Sean Leonard wrote: > On Nov 3, 2015, at 12:37 AM, John C Klensin wrote: > >> >> --On Monday, November 02, 2015 08:11 -0500 Keith Moore >> wrote: >> >>> ... >>>> I mostly agree with that too, but I think we need to be >>>> careful and reasonable. Perfection is impossible and not >>>> every detail is important (hugely or not) and I would hope >>>> that any "this needs to be fully specified and/or fixed >>>> before the document(s) can go into WGLC" statements would be >>>> accompanied by an explanation for that particular case as to >>>> why. In particular, if there are things we are going to >>>> leave to the discretion and needs of individual namespaces (I >>>> think, given the nature of URNs, that is inevitable and >>>> consistent with 2141 and earlier documents), then it is >>>> important to be clear about the boundary but anything we say >>>> beyond that has to be in the form of non-normative examples. >>> It's that kind of language that makes me worry. I am very >>> skeptical that leaving things to "the discretion and needs of >>> individual namespaces" is at all appropriate. It is >>> essential that clients be able to process URNs without having >>> to know details about specific namespaces. Saying we can >>> leave things to namespace discretion seems basically like a >>> failure to do our job in creating a standard. >> This is precisely the kind of disagreement (whether apparent or >> real) that I think needs to be exposed, discussed, resolved, and >> then taken sufficiently off the table that attempts to reopen it >> are strongly resisted by the WG. If we are to make progress, >> that is true independent of which of us are correct. >> >> Now, let me be sure that I understand what you are suggesting. >> If a "client" has to be able to "process URNs without having to >> know details about specific namespaces", that means to me that >> one cannot have per-namespace "resolvers" or resolution >> mechanisms, i.e., that, if any URN is resolvable, all URNs must >> be, and that there must be a generic resolution mechanism that >> works for all URNs and that, moreover, that there be no >> namespace-specific resolution machinery to be applied for any >> namespace after that generic resolution mechanism does its job. >> That, in turn, suggests to me that, from the following >> category-descriptions, one can have valid URNs in only one of >> them, not all three (or others) (ignoring for the moment whether >> I'm talking about the entire URN string (2141bis "namestring") >> or what 2141bis-14 calls an "assigned-name"): >> >> (a) Pure identifiers that do not resolve at all, but are >> merely tested for string equality. >> >> (b) URNs that map into ("resolve to") some sort of URL. >> >> (c) URNs that identify a (presumably digital) object in >> some other way. For example in that regard, assume a >> URN that names a particular text but, without embedding >> a DOI string in the URN namestring, resolves to a DOI. >> Whether that DOI is then made part of a URL (in doi.org >> or elsewhere) is not a URN definition problem. Similar >> examples would apply to URNs that name or refer to >> library objects but that resolve, not to a URL but to an >> accession number or shelf location. >> >> My impression was that the WG agreed to the validity of all of >> those three casss as URNs long ago, at least for the second and >> third probably about the time we decided that DDDS was _a_ way >> to resolve _some_ URNs but not a necessary element of a generic >> URN system. > I can’t speak about DDDS. But I think that (a), (b), and (c) are all valid URNs. No complaints about that model or what the WG already established. > > Some resolutions will naturally be specific to and defined by the namespace (or sub-namespace, if so inclined to view things that way). For example: > > urn:xmlns:foobar2015 > > is meant to represent an XML namespace. If resolved and dereferenced, it is supposed to always return an XML schema (.xsd, application/xml or text/xml), namely the XML schemas that are registered with IANA on a first-come, first-served basis. Two questions: 1. In the case of a URN that named an XML namespace, would returning the XML schema be equivalent to accessing the content of that URN, or would that need to be a distinct operation? If not, why not? 2. Say there's an XML namespace that's named by URN that's not an xmlns URN. Should the operation to retrieve the XML schema associated with that namespace be different than for a namespace named by an xmlns URN? If so, why? > Most resolutions, however, are not specific to or defined by the namespace. For or , they could be resolved in lots of ways (accession number, shelf location, Amazon.com product page, data: URI, abstract pointer to in-memory security object) and I believe that Keith’s essential points are that all of these resolutions are contextually valid and that namespaces such as isbn: and uuid: SHOULD NOT be read to restrict the resolution possibilities. yes. > But what’s good for one set of identifiers may not be good for another set of identifiers. My suspicion is that most, but not all, of the resolution services and parameters that people want to associate with particular namespaces are not in fact inherently specific to those namespaces. So while it's probably necessary to be able to support namespace-specific services and resolution parameters, it would be unfortunate if every namespace developed its own completely different set of services and parameters. > And my argument is that even though you could identify an XML namespace with urn:xmlns:foobar2015 and then resolve it into something utterly tangential to the original purpose (e.g., a picture of cats), there really is no functional value in doing so. I'm not sure how that argument applies to this discussion, but I agree with the statement. > >> [4] If we were modeling a process, rather than syntax and (at >> least some) semantics, we could specify the difference between >> >> generic-engine CALLS NID-resolver(NSS, r-component) >> GETS BACK >> CONSTRUCTS (string, decoded-q-component, f-component) >> and returns that to wherever it goes >> >> and >> >> generic-engine CALLS NID-resolver(NSS, r-component, >> q-component, f-component) >> GETS BACK a string that includes q-component and >> f-component as appropriate >> and returns that to wherever it goes >> >> with "string" in both cases being more or less the hier-part of >> a URL for case (b) (and I don't know how to think about (a) and >> (c), much less others). > The resolution model I am using/proposing is: > > urn: URI gets parsed into NID, NSS, r-component, q-component, f-component > generic-engine CALLS resolver(NID, NSS, r-component, q-component): > resolver calls resolver-for(NID) > IF NID-specific resolver exists, then NID-resolver(NSS, r-component, q-component) > ELSE (NID, NSS, r-component, q-component) As I stated elsewhere, I don't think it's appropriate to pass q-component to resolution services, since q-component is intended to be mapped to "queries" passed in resource URLs, or similar uses when a URL isn't involved. q-component isn't for the resolution service, it's for the resource itself. > => GETS BACK text/uri-list I think resolution services should not inherently constrain the content-type of the result document. There will be a need for resolution services to support a variety of existing and future formats for location information and metadata. (though it's fine with me if a simple uri-list is one of the kinds of content that a resolution service could return) > client can choose which URIs to use and dereference. The text/uri-list only contains URI productions [RFC3986] (no relative-ref productions). > > If URI does not have f-component in text/uri-list, the final URI (with fragment) is the URI in the text/uri-list and the fragment that is the f-component of the original urn: URI. > If URI has f-component in text/uri-list, the final URI (with fragment) is undefined. I doubt that a fragment in a URI returned from a resolution service should override an f-component specified in the original URN. In general, I think it's a Very Bad Idea to have the resolution service try to mediate access between the user/client and the resource - partly because it doesn't scale well, partly because it essentially makes the resolution service behave as a central point of control for access to a large set of resources. The resolution service is supposed to facilitate access, not act as a central gatekeeper or DRM enforcer. > As I have stated before, I have proposed eliminating q-component, making everything r-component. This would be absolutely unacceptable, as it would either make URNs useless for referring to resources that accept queries, or it would put the resolution service in the position of being a central gatekeeper. > In the algorithm above all functions take (r-component, q-component) together, and return URIs that have query components. That is the logical premise on why separating r-component and q-component isn’t necessary. It's absolutely necessary. Because it's none of the resolution service's business what queries the user is making, and it's certainly not within the resolution service's purview to alter or filter such queries. Keith From nobody Tue Nov 3 16:04:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C631B3650 for ; Tue, 3 Nov 2015 16:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaIk-jZJS2yE for ; Tue, 3 Nov 2015 16:04:15 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C7E1B364F for ; Tue, 3 Nov 2015 16:04:15 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 34667208E0 for ; Tue, 3 Nov 2015 19:04:15 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 03 Nov 2015 19:04:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Pc0oQUtgpCikPA4 fwA+TQShWXR4=; b=C6rHCs04WTsjs4GX2bZcteRhrtqiWwN5LqaQqSz58dqCIL6 lexhYRFC+FHmV+EKbjIYJuGBdMNU+TBLQEVbrps1d0dVC/Uu3y61AxRl7tmEtIfG Vsp1xN7MEARHpr7U9XcwTfIAwrcBQ2Qb10tIuBVrTnTL+Ziw4/myAAy02qy8= X-Sasl-enc: jxHJoIpWwEd/0FQPc7cNc+l55LrviIDZo8sCQGL/O8TH 1446595454 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id CFD3DC016EE; Tue, 3 Nov 2015 19:04:14 -0500 (EST) To: urn@ietf.org References: From: Keith Moore Message-ID: <56394B60.3060102@network-heretics.com> Date: Tue, 3 Nov 2015 19:03:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:04:17 -0000 On 11/02/2015 09:21 PM, Andrew Newton wrote: > The topic of a generic or universal URN resolver has come up in the > past, and I had thought we had brilliantly side-stepped the issue. But > it appears we have not. > > It is my view that there is a difference between a generic or > universal URN resolver capable of resolving all types of URNs and a > standard for URNs capable of conveying different, definable components > of a URN to URN processing software where relying processes have URN > specific behavior. Or in other words, the development of a > specification for a generic URN resolver is not the same thing as > avoiding namespace specific URN syntax. > > To my knowledge, there never has been a generic URN resolver. And > while that may have been a design goal at one time, the reality is > that URNs are a sufficiently large and broad concept that such a > critter is highly unlikely to ever exist. None of us can predict the > future, but I'm willing to bet cash money on this prediction. > Therefore I suggest we discontinue any focus on one. Assuming I understand you correctly, I disagree in the strongest possible terms. Extending URNs in such a way as to make development of generic URN handling tools infeasible would make URNs almost useless. I don't believe that is an acceptable outcome of this working group. I also believe that any standards-track proposal with that likely result would grossly fail the "no known technical omissions" requirement of RFC 2026. > However, it does seem worthwhile to have a specification where > namespace specific knowledge is not required to pull apart the > components of a URN. A URN parsing library should be able to provide > to client processes the various components of a URN, even though the > meaning of those components are only meaningful in the context of a > specific namespace or resource. Parsing a URN is easy, but there's a lot more to this than parsing. > > So here is a question to the working group. Does this distinction > define the correct goal (URN parsing) and non-goal (generic URN > resolver)? > Absolutely not. Keith From nobody Tue Nov 3 16:10:58 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885761B364F for ; Tue, 3 Nov 2015 16:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX1d2mmAuxeO for ; Tue, 3 Nov 2015 16:10:55 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4981B364D for ; Tue, 3 Nov 2015 16:10:55 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 997F520BE9 for ; Tue, 3 Nov 2015 19:10:54 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 03 Nov 2015 19:10:54 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=7rnyuyT51/FByrR Hf7KqmUtgqsU=; b=h4Us4LTbYiu7zPvORzJSB5xVOpv+Qe9qhCDVZ1VCMaD2OtX sOrRY/qOhfm9ypy92d8wdnnqIZRzYn5uWYJSkCQPvMty3ezoGL4MXdjXPTXCZ7Tv Zv568WpH+LmjMov3Ns1xBqazi5JAYAFHniKUorxDRtgSaAKhB20a2ltWNHdM= X-Sasl-enc: TCjNIqhQgBEK3UhN5S7j+lc1HIUR3zQVgdqEdo+GKFr4 1446595854 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 30A67680197; Tue, 3 Nov 2015 19:10:54 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <56394CEF.1080302@network-heretics.com> Date: Tue, 3 Nov 2015 19:10:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:10:57 -0000 On 11/02/2015 09:29 PM, John C Klensin wrote: > >> Most resolutions, however, are not specific to or defined by >> the namespace. For or >> , they could be >> resolved in lots of ways (accession number, shelf location, >> Amazon.com product page, data: URI, abstract pointer to >> in-memory security object) and I believe that Keith's >> essential points are that all of these resolutions are >> contextually valid and that namespaces such as isbn: and uuid: >> SHOULD NOT be read to restrict the resolution possibilities. > I think we need to hear from Keith because I've understood some > of his comments as wanting to prohibit resolutions that are > namespace-specific. I don't want to absolutely prohibit them, as I think they will be necessary in corner cases, or to let namespaces and resolution services experiment with new r-component parameters and types of requests. But I do want to discourage namespace-specific requests and r-component parameters, or at least encourage development of standard resolution protocols and standard resolution requests and results that are applicable across the vast majority of cases. The last thing we need is for every namespace to go off and do its own thing. Keith From nobody Tue Nov 3 16:22:09 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417491B36BC for ; Tue, 3 Nov 2015 16:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR6o17HrD_2d for ; Tue, 3 Nov 2015 16:22:02 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC751B36B5 for ; Tue, 3 Nov 2015 16:21:45 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 76C5F20D89 for ; Tue, 3 Nov 2015 19:21:44 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 03 Nov 2015 19:21:44 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ogNXe9j1JSm5ueO 4NdFSSEOwsHI=; b=NRdR8zbjH7xdvOCcbvklrc3uwQzPXO0e6cEs0PuFBZ0VISN +FcDTvoYbweOtZRz/+53LuChA/tDUWwyCXDRkl4WOlmP9ErmZgczOAShapCVU+9d kQnuTjOj5mGfGz2OlKAYScAPx8IxBoAk5d6E7tVthljyH9wDg9GwEQcpSdzE= X-Sasl-enc: oh6Ug2a6l21kscUPS/EltSmZTGIWMk8WjYcS/nG1fKR6 1446596504 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 110446801CD; Tue, 3 Nov 2015 19:21:44 -0500 (EST) To: urn@ietf.org References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <56394F79.5090907@network-heretics.com> Date: Tue, 3 Nov 2015 19:21:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:22:04 -0000 On 11/02/2015 10:39 PM, John C Klensin wrote: > > --On Monday, November 02, 2015 21:21 -0500 Andrew Newton > wrote: > >> The topic of a generic or universal URN resolver has come up >> in the past, and I had thought we had brilliantly side-stepped >> the issue. But it appears we have not. >> >> It is my view that there is a difference between a generic or >> universal URN resolver capable of resolving all types of URNs >> and a standard for URNs capable of conveying different, >> definable components of a URN to URN processing software where >> relying processes have URN specific behavior. Or in other >> words, the development of a specification for a generic URN >> resolver is not the same thing as avoiding namespace specific >> URN syntax. > Yes, exactly, although I would have added "namespace specific > semantic interpretations within the components of that syntax" > to your list of things we probably can't nail down and shouldn't > try. Put a bit differently and picking up on your terminology > below, we can (and, IMO, should) be very clear about how to pull > apart the various pieces of URN syntax (specifically into the > NID, NSS, q-component, r-component, and f-component pieces > specified in 2141bis-14) but that we need to accept that there > will be namespace-specific syntax and semantic interpretations > within those pieces I do accept that there will be some (hopefully few) of these, as a necessary evil. > (including whether a given one of the > x-components is allowed and considered meaningful). I have yet to see a single justification for that, and as far as I can tell it makes no sense whatsoever. Interpretation of q-component is entirely the purview of the resource named by the URN. Interpretation of f-component is entirely defined by the media type of the resulting content. Neither the namespace nor the resolution service has any business dictating or the interpretation or applicability of either one. That would break relative references, it would also thwart URN interoperability. > If we can > draw the boundaries there, I think we can succeed. If we have > to specify very much about the interpretation semantics of the > NSS or the q-component or r-component pieces, I have almost the > same reaction you do to revisiting q-components and > r-components: I don't think the WG can survive such a process. as far as I can tell, it's actually pretty simple: 1. interpretation of both f-components and q-components are out of scope for resolution services and namespaces. full stop. 2. an IANA registry of r-component facets, with namespaces strongly discouraged from defining facet names that appear to be generic but are actually namespace-specific Keitih From nobody Tue Nov 3 16:50:29 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4DB1A70FD for ; Tue, 3 Nov 2015 16:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp7_99rU7Hr1 for ; Tue, 3 Nov 2015 16:50:25 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707D81A86F6 for ; Tue, 3 Nov 2015 16:50:21 -0800 (PST) Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6C864509BE; Tue, 3 Nov 2015 19:50:17 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_E509D030-AFF9-4B27-AF8D-907E86D33DBD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> Date: Wed, 4 Nov 2015 09:48:05 +0900 Message-Id: <564D51F3-C4C8-402E-AE84-098211246A63@seantek.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:50:28 -0000 --Apple-Mail=_E509D030-AFF9-4B27-AF8D-907E86D33DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello: (Trying to pay attention to another WG meeting=85 :) ) On Nov 3, 2015, at 11:29 AM, John C Klensin wrote: > Sean, >> [=85] >> =3D> GETS BACK text/uri-list >=20 > Quibble: If "text" is interpreted broadly, then "uri-list" is > just a subset and should not be an "or"-type conditino (or do I > misunderstand your notation as ABNF-like?). If "text" is > interpreted narrowly, then I think the above implies that there > are two sorts of URNs (whether NID-specific resolvers exist or > not): those that, when resolved, return text and those that, > when resolved, return one or more URIs. That excludes both > those that don't resolve and those that resolve to something > other than URI(s) or text. To be clear: I was referring to the Internet media type =93text/uri-list=94= , namely, the media type defined in RFC 2483, but not necessarily with = the rest of the text of that RFC. A text/uri-list is just a CRLF-delimited list of URIs, with optional # = comment lines. So, when I said =93text/uri-list=94, I meant that the algorithm returns = a list of 0 or more ordered URIs. The URIs are in order so that implies = that first URIs are more preferable than later URIs (much like DNS SRV = records, and weights). A URI can represent (unfortunately) =85 anything. A significant class of = URIs will resolve to content that has an Internet media type, e.g., = http: URIs, data: URIs, mid: and cid: URIs, etc.; others (like ftp:) = have an implicit media type but the URI scheme doesn=92t really say how = to map them (hence you can assume that .html is text/html but that is = not an Internet standard, just a de-facto one); and still others have no = media type. I suppose you could have a urn:service: URN that turns into = a tel: or mailto: URI, neither of which represent content with media = types, but both more-or-less do the thing that you want them to (i.e., = contact the service). Further to this point, Keith said: On Nov 4, 2015, at 8:56 AM, Keith Moore = wrote: >>=20 >> =3D> GETS BACK text/uri-list >=20 > I think resolution services should not inherently constrain the = content-type of the result document. There will be a need for = resolution services to support a variety of existing and future formats = for location information and metadata. >=20 > (though it's fine with me if a simple uri-list is one of the kinds of = content that a resolution service could return) In discussing how resolution works, it=92s very helpful to have some = concrete result. If we talk about the algorithm in very hand-wavy = high-level terms, we don=92t have anything implementable. Saying that = the algorithm returns a list of URIs, is an implementable algorithm. Yes it kicks the can down to another level of indirection, since URIs = can be pretty much anything. But it=92s computable and I would say = that=92s what we need to get this URNBIS work done. An uri-list (obviously) does not constrain the content-type of the final = things. Furthermore, if you want to have a URI that only represents = location information and metadata, you can do that. For example, the = geo: URI scheme was recently standardized, and that will give you = location info quite nicely. Above, I said that uri-list is a list of URIs in priority order. An = alternative interpretation is that the uri-list is a SET of URIs = (possibly in priority order) that are equally valid. For example, = suppose that you want to get purchasing information about a book, = urn:isbn:999=85 etc. The returned uri-list can be = https://www.amazon.com/dp/=85, http://www.worldcat.org/=85, a list of = geo: URIs for nearby stores and libraries that carry the book, callto: = for a Skype handle to the publisher, and tel: for your local libraries = that carry the book. None of these URIs are =93more important=94 than = the other; they are just different ways of getting access to information = related to the identified thing. Sean --Apple-Mail=_E509D030-AFF9-4B27-AF8D-907E86D33DBD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTA0MDA1MDEwWjAjBgkqhkiG9w0BCQQxFgQUzy4/vbbXksYsGcZosEDm/vKDAAIwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBADh2icuzK3xtItWHvjp6DfiNLi5tZ3Pqfv6YoZIe64NP1pl+Y94fJJysRRTEIUuaS0YP dpA0CEbO1Mg84Ku5Qg9B9LtBNumpg28v5EODF+pYw3DBNogkuj47fHcTGVR+wBPxTZkZoPUlk9H2 0AkfECfLNnJosBYDNqxJh/sHRJGOdYdZDvdXXg4YgHIza27f2lvnSLK+qUB+q3p7P+uX/9QxDglJ UJJjRlm4Cz0wuPzl5amatO1LN4A9m/4JvaZSQeRkpnutxTs6H1HoVH3ElVs1p7yQfQErCrkvmiqK R1SNjiHDoH4fXABDTNxuo29IxmXH4PRcbDrIcfLTbjkl7WIAAAAAAAA= --Apple-Mail=_E509D030-AFF9-4B27-AF8D-907E86D33DBD-- From nobody Tue Nov 3 17:07:43 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1389B1A87CD for ; Tue, 3 Nov 2015 17:07:42 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl4ajsp2bXyf for ; Tue, 3 Nov 2015 17:07:39 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FE81A87DE for ; Tue, 3 Nov 2015 17:07:35 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5B8942049C for ; Tue, 3 Nov 2015 20:07:34 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Nov 2015 20:07:34 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=zcu/6Tccb/j1BPD5XBkx0eEVbPc=; b=gbALC u7PVn8zaI2E+oHeR/B056B7gDO7TZL/dE90R7RyLOY75fpLMNPB9Y7k6qQP4felD oGA7+rlKrOPu9I5vG6jiNgRmldUYGXi/YiU931850ZLhgA9Mh9xaQkz7mwu5szEa D64G06bswBrDH0A0YEtpJX+mAfn7ZvfX8BBK74= X-Sasl-enc: WvzYTPoOrePPP3aukNDW7jMd+7Qid+dn/tvMoilXRii5 1446599253 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B7CAE68016C; Tue, 3 Nov 2015 20:07:33 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <563856A9.6020509@network-heretics.com> <8C692BACD263F8DAB652A192@JcK-HP8200.jck.com> From: Keith Moore Message-ID: <56395A37.1090000@network-heretics.com> Date: Tue, 3 Nov 2015 20:07:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8C692BACD263F8DAB652A192@JcK-HP8200.jck.com> Content-Type: multipart/alternative; boundary="------------040700000809090106000903" Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 01:07:42 -0000 This is a multi-part message in MIME format. --------------040700000809090106000903 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/03/2015 05:29 AM, John C Klensin wrote: >> Naming is inherently a difficult topic to discuss because (as >> computer scientists like to say) all problems can be solved by >> adding another layer of indirection. It follows that any time >> someone proposes a new kind of name, particularly something as >> vaguely defined as "uniform resource name", anyone can imagine >> his particular problem being addressed by that naming and >> indirection scheme. >> ... > Keith, > > I found this very helpful in understanding what you are asking > for. Rather than my responding with yet more over-long text > now, could you read Andy's most recent text and respond to that > as well? I'd like to see if we (all three of us) can converge > by trying to separate your comments/requests into things that > fit within the scope of that note and things that he suggests > leaving out, but can't reasonably do that until I understand if > you accept his general principles. If you do not, I should > probably stop adding long notes to the conversation until you > and he sort that out. I do not. As far as I can tell, he and I are nearly diametrically opposed. In particular, I emphatically do not agree that a general-purpose URN resolution system is infeasible. I also regard any change to URNs that breaks the ability to have a general-purpose resolution system as a fundamental change to URNs that is outside of the scope of this working group. URNs were specifically designed to facilitate not only resolution but general resolution mechanisms, and this group is not chartered to break that functionality. However, in case it helps: * By saying the above things I do not mean that every URN has to be resolvable. I agree that that is not achievable given the broad overall scope of URNs. This was also generally understood by people discussing URNs as early as 1994. * By saying these things I do not mean that every namespace has to support a resolution service, only that it be possible for every namespace to do so if it makes sense for the resources named by that namespace. * By saying these things I do not mean that if a namespace supports a resolution service, the namespace must be able to return information for every URN coined by that namespace. * By saying these things I do not intend to prohibit all namespace-specific resolution operations or interpretation of r-components. > As a preview, I completely agree with your initial comments > about naming and the history of URNs and actually think I wrote > very similar paragraphs in the past. There are other places > where I think we appear to disagree only because I made what I > thought were general comments or examples that I considered > non-comprehensive that you apparently interpreted as a > comprehensive listing and responded on that basis. A lot of misunderstandings in all directions seem to result from the need to compromise between being brief and being precise. > That sort of > difference should be easily straightened out and resolved. For > example, you wrote > >> In particular, I expect to have a DDDS-like database, that is >> distributed by various means (not necessarily or specifically >> DNS), that advertises (namespace-id, protocol, service-URL) >> tuples, where protocol is an IANA-registered URN resolution >> protocol identifier, and service-URL specifies how to contact >> the resolution service (the details can be protocol-specific). >> If DDDS is insufficient for this, replace it. But even if >> DDDS has some specific flaws, the core idea of distributing >> this database over the network is sound. > A non-DNS distribution mechanism for URNs has never been > specified, much less deployed, and that, as far as I know (and > much to my regret), we haven't had a reference or dispatching > database associated with an element of major protocol > successfully distributed by anything other than the DNS since > (depending on what you count) we stopped distributing host > tables or gave up on X.500. That (and some other remarks) > concern me because it feels as if you are putting major new > design work and consensus about it the critical path of progress > on the current effort. Okay, just so you know, statements of the form "X for URNs has never existed" (especially if the implication is "and it never will") aren't very relevant to me, because URNs are in their infancy. They're like similar statements made a few years ago of the form "X for IPv6 has never existed". But I am not intending to put design of a resolution service on this group's charter - I realize that's not going to happen. I only want the group to understand that it shouldn't make decisions that thwart general-purpose resolution. > > However, that generalization of DDDS (or even an analysis, > redesign, and successor) doesn't change my basic point: I > believe that, if one is going to have a resolution method, or > resolution-method-finder, that is namespace independent and > works in a consistent way for all URN namespaces, then there > either needs to be a single resolver that works for all URNs Why do you believe that? (or perhaps I should ask, "What do you mean when you say things like that?") Do we need to have a single SMTP server that accepts all incoming mail? A single web server that handles all web content? The whole history of IETF has been one of defining specifications that allow multiple implementors to produce implementations that behave reasonably consistently from one to another. Why is defining a standard protocol, standard requests, and standard result formats, not a valid approach to general-purpose URN resolution? > or that mechanism has to have access to a > comprehensive database and query process that identifies a > resolution mechanism for each URN. Given that providing resolution for every single URN was never a goal, or at least, that that goal was abandoned before the URN WG was ever chartered, why is that suddenly a requirement now? Why do you consider that a requirement when (as far as I can tell) everybody else involved in URN work abandoned it by 1995? Even the language in RFC 1737 (published in December 1994) reflects that understanding. for example: o Resolution: A URN will not impede resolution (translation into a URL, q.v.). To be more specific,/for URNs that have corresponding URLs, there must be some feasible mechanism to translate a URN to a URL/. (section 2, last bullet) It doesn't say that the mechanism must exist, it says it must be feasible. o It is/strongly recommended/ that there be a mapping between the names generated by each naming authority and URLs. At any specific time there will be zero or more URLs into which a particular URN can be mapped. The naming authority itself need not provide the mapping from URN to URL. (section 4, penultimate bullet) It doesn't say "required", it says "strongly recommended". (note: I am not saying that the RFC 1737 text is perfect, just that it attempted to reflect the general understanding as of late 1994.) Keith --------------040700000809090106000903 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/03/2015 05:29 AM, John C Klensin wrote:
Naming is inherently a difficult topic to discuss because (as
computer scientists like to say) all problems can be solved by
adding another layer of indirection.  It follows that any time
someone proposes a new kind of name, particularly something as
vaguely defined as "uniform resource name", anyone can imagine
his particular problem being addressed by that naming and
indirection scheme.
...

Keith,

I found this very helpful in understanding what you are asking
for.  Rather than my responding with yet more over-long text
now, could you read Andy's most recent text and respond to that
as well?  I'd like to see if we (all three of us) can converge
by trying to separate your comments/requests into things that
fit within the scope of that note and things that he suggests
leaving out, but can't reasonably do that until I understand if
you accept his general principles.  If you do not, I should
probably stop adding long notes to the conversation until you
and he sort that out.

I do not.  As far as I can tell, he and I are nearly diametrically opposed.

In particular, I emphatically do not agree that a general-purpose URN resolution system is infeasible.   I also regard any change to URNs that breaks the ability to have a general-purpose resolution system as a fundamental change to URNs that is outside of the scope of this working group.   URNs were specifically designed to facilitate not only resolution but general resolution mechanisms, and this group is not chartered to break that functionality.

However, in case it helps: 

  • By saying the above things I do not mean that every URN has to be resolvable.   I agree that that is not achievable given the broad overall scope of URNs.    This was also generally understood by people discussing URNs as early as 1994.
      
  • By saying these things I do not mean that every namespace has to support a resolution service, only that it be possible for every namespace to do so if it makes sense for the resources named by that namespace.

  • By saying these things I do not mean that if a namespace supports a resolution service, the namespace must be able to return information for every URN coined by that namespace.

  • By saying these things I do not intend to prohibit all namespace-specific resolution operations or interpretation of r-components.
As a preview, I completely agree with your initial comments
about naming and the history of URNs and actually think I wrote
very similar paragraphs in the past.  There are other places
where I think we appear to disagree only because I made what I
thought were general comments or examples that I considered
non-comprehensive that you apparently interpreted as a
comprehensive listing and responded on that basis.

A lot of misunderstandings in all directions seem to result from the need to compromise between being brief and being precise.   

 That sort of
difference should be easily straightened out and resolved.  For
example, you wrote


In particular, I expect to have a DDDS-like database, that is
distributed by various means (not necessarily or specifically
DNS), that advertises (namespace-id, protocol, service-URL)
tuples, where protocol is an IANA-registered URN resolution
protocol identifier, and service-URL specifies how to contact
the resolution service (the details can be protocol-specific).
If DDDS is insufficient for this, replace it.   But even if
DDDS has some specific flaws, the core idea of distributing
this database over the network is sound.

A non-DNS distribution mechanism for URNs has never been
specified, much less deployed, and that, as far as I know (and
much to my regret), we haven't had a reference or dispatching
database associated with an element of major protocol
successfully distributed by anything other than the DNS since
(depending on what you count) we stopped distributing host
tables or gave up on X.500.   That (and some other remarks)
concern me because it feels as if you are putting major new
design work and consensus about it the critical path of progress
on the current effort.

Okay, just so you know, statements of the form "X for URNs has never existed" (especially if the implication is "and it never will") aren't very relevant to me, because URNs are in their infancy.  They're like similar statements made a few years ago of the form "X for IPv6 has never existed". 

But I am not intending to put design of a resolution service on this group's charter - I realize that's not going to happen.  I only want the group to understand that it shouldn't make decisions that thwart general-purpose resolution.


However, that generalization of DDDS (or even an analysis,
redesign, and successor) doesn't change my basic point: I
believe that, if one is going to have a resolution method, or
resolution-method-finder, that is namespace independent and
works in a consistent way for all URN namespaces, then there
either needs to be a single resolver that works for all URNs
Why do you believe that?   (or perhaps I should ask, "What do you mean when you say things like that?")

Do we need to have a single SMTP server that accepts all incoming mail?   A single web server that handles all web content?   The whole history of IETF has been one of defining specifications that allow multiple implementors to produce implementations that behave reasonably consistently from one to another.   Why is defining a standard protocol, standard requests, and standard result formats, not a valid approach to general-purpose URN resolution?


 or that mechanism has to have access to a
comprehensive database and query process that identifies a
resolution mechanism for each URN.
Given that providing resolution for every single URN was never a goal, or at least, that that goal was abandoned before the URN WG was ever chartered, why is that suddenly a requirement now?   Why do you consider that a requirement when (as far as I can tell) everybody else involved in URN work abandoned it by 1995? 

Even the language in RFC 1737 (published in December 1994) reflects that understanding.  for example:

   o Resolution: A URN will not impede resolution (translation into a
     URL, q.v.). To be more specific, for URNs that have corresponding
     URLs, there must be some feasible mechanism to translate a URN to a
     URL.
(section 2, last bullet)   It doesn't say that the mechanism must exist, it says it must be feasible.
   o It is strongly recommended that there be a mapping between the
     names generated by each naming authority and URLs.  At any specific
     time there will be zero or more URLs into which a particular URN
     can be mapped.  The naming authority itself need not provide the
     mapping from URN to URL.
(section 4, penultimate bullet)   It doesn't say "required", it says "strongly recommended".

(note: I am not saying that the RFC 1737 text is perfect, just that it attempted to reflect the general understanding as of late 1994.)


Keith

--------------040700000809090106000903-- From nobody Tue Nov 3 17:22:23 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25561A887E for ; Tue, 3 Nov 2015 17:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeYbWlIswkKE for ; Tue, 3 Nov 2015 17:22:16 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54331A887C for ; Tue, 3 Nov 2015 17:22:15 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 365A820FE9 for ; Tue, 3 Nov 2015 20:22:14 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 03 Nov 2015 20:22:14 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=UTCjkQXJ4A2MPMS OrGJhwnxOwZ8=; b=Qp2ps10qKVE1m9MLKtKpnxXs9WHOe1UK3zo6CW/4j5i8OfE SC5QQEo2vO2Y+KK/zvfrBXvVR12MA465sw1s+wvl3w9e13Uy+lXzQd2Nxe7u02je 72rOQbzEYoJ51oZiCDusbCcPBqxeDXXNgPMDeqDreXtcSjbnEorcg773wK9o= X-Sasl-enc: ZbHRlbLfpSbAecoT7A14D+i0G+nXRQfZCt3aghyLHvk0 1446600133 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C193E6801B8; Tue, 3 Nov 2015 20:22:13 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> <564D51F3-C4C8-402E-AE84-098211246A63@seantek.com> From: Keith Moore Message-ID: <56395DA7.6010803@network-heretics.com> Date: Tue, 3 Nov 2015 20:21:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564D51F3-C4C8-402E-AE84-098211246A63@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 01:22:21 -0000 On 11/03/2015 07:48 PM, Sean Leonard wrote: > Further to this point, Keith said: On Nov 4, 2015, at 8:56 AM, Keith > Moore wrote: >>> => GETS BACK text/uri-list >> I think resolution services should not inherently constrain the content-type of the result document. There will be a need for resolution services to support a variety of existing and future formats for location information and metadata. >> >> (though it's fine with me if a simple uri-list is one of the kinds of content that a resolution service could return) > > In discussing how resolution works, it’s very helpful to have some concrete result. If we talk about the algorithm in very hand-wavy high-level terms, we don’t have anything implementable. Saying that the algorithm returns a list of URIs, is an implementable algorithm. I understand the discussion dilemma, and often face that myself. Too much precision and you lose the reader, too little and the reader can get misleading impressions - especially in a discussion like this one. I don't think that text/uri-list is a good choice if it's the only output format that can be returned, for several reasons. Perhaps the most obvious is that resolution services will be expected to do more than provide a list of URLs - they will also be expected to provide metadata. There are several existing formats for various kinds of metadata, and it would make good sense if resolution services could return them. Also, even if the service requested is a list of URLs, the resolution service is not in a good position to determine ordering for the client. Finally I would suggest that if there's going to be a designated format for a list of URLs, it should allow each URL to be tagged with zero or more attributes to help the client decide which order to consult them in. (To cite one example from previous experience: Having the resolution service act as a DNS cache for the URL servers' IP addresses can result in a tremendous improvement in access times.) But I agree that having a standard way to request a list of URLs of the resource, and a standard response format, would be appropriate. I also agree that the standard should be simple. (but it should also be extensible) My suggestion would be content-type: application/json.uri-list where the result consists of a single JSON list, each element of the list is a JSON object, and each such object has the required the tag "uri" and may have other optional tags (defined in an IANA registry, but one such tag would be "addresses", and each address would be a tuple consisting of an IPv4 or IPv6 address (as a string) and a cache-expiration date-time. Keith From nobody Wed Nov 4 12:04:32 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535001B33AB for ; Wed, 4 Nov 2015 12:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gentCciD0P8 for ; Wed, 4 Nov 2015 12:04:30 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D3E1B33A8 for ; Wed, 4 Nov 2015 12:04:29 -0800 (PST) Received: by wikq8 with SMTP id q8so99332365wik.1 for ; Wed, 04 Nov 2015 12:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xV06iapmmcPsSvclFqio7M11jlGKUwZdwqjB/qE0TO0=; b=uLvK70zzXGATGW7QCpJrUND3v3z74XsazhH88jG5D/Dru8ElXc7rGvGQVE6AAYlrDS KQNNcfllWkku91r/CLI2qlgS9UNphO6QJvwatGLzPcM/KufdE32PA6epmU8Zs6DJ7c1i 9Gb0K2mr8Pu+EYrVeXcZbjxGNt73Vg/T33Ta4lkKC1NHewdeOcIylgiRcwGuBxBgNwkX YyqlWKZfEwBGZmhRpKsMIjsK0k4odf8FkKnxlcgB4poKm/16i2jfkm41CeMmOCYk1fqt fACYWui4aGEM+OUM6g6tJu6zkBoHyhQloqPj834UFtIgWj6G+iIs6V7GLx0KLN9/LArV HGDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xV06iapmmcPsSvclFqio7M11jlGKUwZdwqjB/qE0TO0=; b=eEPi4npnB/fzao9iWf7LYm+ezgpZmqd67BMyMLkcd5y+CAMUHxlZwSUNHXBNfBqwxY l+j8dz0TRg+9TxHpYMobQfI5XNTv4zdxJLtmP+DNxstUkR5z7tpzXlsH9bJvooiCGLhU MT3cq8SC2k7UJn55tFY9qFiFLU+TcvNfCxKrijOh3nQobUvBltzAscKQv636ryU9unhx UBHN2Yv79vScYQmEvvcNhPZTVqIJywthbDXFkGPUxC2nV1v84HQ73MgUDioqWNRjkeSD qdyYry0uE6IosefbDlaVk9J0+A6Xge17fMjtEF7rRPPBblTWxIT/KHsy3bMBBNcIukuE lzPg== X-Gm-Message-State: ALoCoQkeR8FAl+MTdCoUBgpe0blLeMynQXyE4Q9Ps5uASXUOcuXEYCc6H6F8IEGgXAJDcGjpaRWk MIME-Version: 1.0 X-Received: by 10.194.112.199 with SMTP id is7mr4042626wjb.11.1446667468504; Wed, 04 Nov 2015 12:04:28 -0800 (PST) Received: by 10.194.91.134 with HTTP; Wed, 4 Nov 2015 12:04:28 -0800 (PST) X-Originating-IP: [133.93.86.12] In-Reply-To: <56394B60.3060102@network-heretics.com> References: <56394B60.3060102@network-heretics.com> Date: Wed, 4 Nov 2015 15:04:28 -0500 Message-ID: From: Andrew Newton To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 20:04:31 -0000 On Tue, Nov 3, 2015 at 7:03 PM, Keith Moore wrote: > Assuming I understand you correctly, I disagree in the strongest possible > terms. Extending URNs in such a way as to make development of generic URN > handling tools infeasible would make URNs almost useless. You have changed the terminology here. "generic URN handling tools" and a generic URN resolver are not the same thing. The term you are using does not necessarily include URN resolution. Note that I have specifically said "resolver". > I don't believe > that is an acceptable outcome of this working group. I also believe that > any standards-track proposal with that likely result would grossly fail the > "no known technical omissions" requirement of RFC 2026. The complete sentence from 2026 is: "A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it." (Also note that 2026 states that even this is not an absolute). The very fact that it is necessary to have this discussion is proof that a generic URN resolver is not a requirement that has been placed upon this working group by the IESG or previous IETF consensus. Even if there were previous IETF consensus, the fact that the IETF has ratified URNs that cannot resolve would show that the IETF consensus changed. To my knowledge this working group is not bound by any requirement for a generic URN resolver, and the acceptance or rejection of that requirement is a matter this working group may choose. To the contrary, if your position is that a generic URN resolver is a requirement and this working group puts forward a specification that cannot resolve all URNs, that is a known technical omission. It might be useful for you to define the specific operations upon ALL URNs for which you believe a "generic URN handling tool" MUST be capable. But you have clearly stated in other threads that you do not believe resolution is one of them, as you have clearly noted that all URNs are not resolvable. -andy From nobody Wed Nov 4 12:10:55 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BCF1B33B1 for ; Wed, 4 Nov 2015 12:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiDFKH8yVUOh for ; Wed, 4 Nov 2015 12:10:53 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB531B2A37 for ; Wed, 4 Nov 2015 12:10:52 -0800 (PST) Received: by wijp11 with SMTP id p11so99562970wij.0 for ; Wed, 04 Nov 2015 12:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aIZgCi15d8fUaoFwLAEgj21jAXQZzE7KQdK7QpgMm7Q=; b=mH/+notTJBOFwW6t9aI3hEfrqq3Mb2ppoF78PfcNUwDRVqaTFggBJllwysPCV4GFeU xWVEzT02fr4A4JnThHVyX8aEFLSqGIol5yUxyEZCl2fowcKFlQ4LqGXnWWAOj4O68wCn QdamKzfwgPzfP5HZYAKQ0yxAnVwTqwqFoNL5W5Cx5a7anIQp2tWgqoeAUSeI7GnxKjaz mlUlBHK52Xlu2EKzRNyWe4e33utKHxXShRtQEXcS2FBzmllSWPCc47PcOMMZ9Q5c1hod 1bZo8yCvwvBO23gkVD8hMhbfWWVmKsQUK0DaFdXmKKpnkHd/MQ8uOgJxw73hyJfN0q61 LzcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aIZgCi15d8fUaoFwLAEgj21jAXQZzE7KQdK7QpgMm7Q=; b=CKuL7S8tsxxtJGCvXmfy2chJWnb2o8ofYoh/6fRr2/n8ti8VzzpwhFTRlmUuD6s6At NM0XP6W/I1tTthpJd/zQHkTeYoh3KAH7MSOQEtQR0xN0UtFa6r4CaOJcXWgkYNFOBqJg //qk+qVUueFl7cICk6EC8Ap6swb5oTnSS5oBUnp4RSStXUPsvTpsNMhKfCB1U/8GmC1O Y7acSxhpKji7eHDQ/8UGhSLVXHqra0eRX3j0YlShOTYaKsDjn7xw/wol6cvmMZoydLvv JgnVixmjWI/swT58V1st9GWnqvqYBMyiFxezcYWpr46HR46rHhTXmDYUWFhJi3PW1FJw jbUQ== X-Gm-Message-State: ALoCoQnFHnYOZccXdbeXXpRhci5TzJb0Eednn3UsCzyR/szgvtbNsDR1/rsMCd7b77zZqLgiMizj MIME-Version: 1.0 X-Received: by 10.194.112.199 with SMTP id is7mr4071553wjb.11.1446667851183; Wed, 04 Nov 2015 12:10:51 -0800 (PST) Received: by 10.194.91.134 with HTTP; Wed, 4 Nov 2015 12:10:51 -0800 (PST) X-Originating-IP: [133.93.86.12] In-Reply-To: <56394F79.5090907@network-heretics.com> References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> Date: Wed, 4 Nov 2015 15:10:51 -0500 Message-ID: From: Andrew Newton To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 20:10:53 -0000 On Tue, Nov 3, 2015 at 7:21 PM, Keith Moore wrote: > 2. an IANA registry of r-component facets, with namespaces strongly > discouraged from defining facet names that appear to be generic but are > actually namespace-specific This seems like a fine idea for the working group to consider. But it does not guarantee resolution of all URN namespaces, nor does it guarantee resolution of all URN namespaces that can be resolved. An implementer cannot take the 2141bis RFC and be assured that whatever new URN pops up in the future will be compatible with their URN resolver. They must periodically check the IANA registry and add new behavior to their software from time to time. -andy From nobody Wed Nov 4 12:22:06 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8841B2AA0 for ; Wed, 4 Nov 2015 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6V_ydrgTWh4 for ; Wed, 4 Nov 2015 12:22:03 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB041B2A9F for ; Wed, 4 Nov 2015 12:22:03 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Zu4ZD-000LI9-Rs; Wed, 04 Nov 2015 15:21:59 -0500 Date: Wed, 04 Nov 2015 15:21:54 -0500 From: John C Klensin To: Andrew Newton , Keith Moore Message-ID: In-Reply-To: References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 20:22:04 -0000 --On Wednesday, November 04, 2015 15:10 -0500 Andrew Newton wrote: > On Tue, Nov 3, 2015 at 7:21 PM, Keith Moore > wrote: >> 2. an IANA registry of r-component facets, with namespaces >> strongly discouraged from defining facet names that appear to >> be generic but are actually namespace-specific > > This seems like a fine idea for the working group to consider. > But it does not guarantee resolution of all URN namespaces, > nor does it guarantee resolution of all URN namespaces that > can be resolved. An implementer cannot take the 2141bis RFC > and be assured that whatever new URN pops up in the future > will be compatible with their URN resolver. They must > periodically check the IANA registry and add new behavior to > their software from time to time. Andy, one addition to this. I'm not quite sure what a "r-component facet" is, but the proposal that started us down the path toward separation of q-components and r-components was one to require that URN X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9DF1A88E1 for ; Wed, 4 Nov 2015 13:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEfzWNMu5vA0 for ; Wed, 4 Nov 2015 13:24:06 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0B41A8973 for ; Wed, 4 Nov 2015 13:23:56 -0800 (PST) Received: by wmll128 with SMTP id l128so2659248wml.0 for ; Wed, 04 Nov 2015 13:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vsVUC+qnJfPs+H0MxgVj6UwLQ9eIKIJ6mpU9GYlwwMw=; b=sCFuzKE0Cdn3JqR24ZiJgnTI4sZqsv4QSj9Xb2B4pE2Vq2tmGaHkwIMmxg0wDZgnqj CPSCks8trrMa4zNnC8FTVumzZhnPSnIObFUfRJqyPAr0IZLOqF61WlFgla+5V8cGp/lf iTx+KHXepzJHHuWhvbCuwLIZvxkSAwZhp/m8a+F3xcQ6/POMmnfPGh6pX/3rxsJZe5Hh 5ZkjmmYhu1h69LZ8bB9fGJkZMjJwdiZES3GtQh/0E15dUXKmPEzniOVBJEL+c5vucLWM 5+3MHH07jbCs+Sj6/ts7ZQza9Wyzf9x2Gh5mCsHyM4wh+N1O+xVkOIi7mCNTdjPC+Zxo rFnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vsVUC+qnJfPs+H0MxgVj6UwLQ9eIKIJ6mpU9GYlwwMw=; b=O7gHdUZ3Inp9C7uPRiig0XnkdMCfru5QVv3wof2GAhzHsqKYJmCQKFhteTuJ0b9y+l Uo8rnzbN+Pafx021zxU+05wTW1Io/PSaO/LbaiHACMkpW6hIDIqoYeKYwCSfH2RFukCj Pb+/DBnYPP7OVo3yt8yXlFWgYn5dDKbTZ+WYwMGPI635mD/Tn/noWSd5k77J2GB7swAD VDP2LQVcdqvAdnvoH9qaeMazbgsJOumJCwYi2GHv+SpO4Pdo7veNpe84vUlNDmO8VJfZ +/W50xk8nq7QhohffKDyLICMKLlkLhRv9r2R25Ygi2Nmo4EXZS6J+AN+mUT8GvKWDC+c UteQ== X-Gm-Message-State: ALoCoQlTxJW1WUqQumPJbPgucBiWIo/dNMoy0hIDGBUFNWsABt8h1inb85QuLXQdWaAhF9M8rAO8 MIME-Version: 1.0 X-Received: by 10.28.229.212 with SMTP id c203mr26585854wmh.11.1446672235302; Wed, 04 Nov 2015 13:23:55 -0800 (PST) Received: by 10.194.91.134 with HTTP; Wed, 4 Nov 2015 13:23:55 -0800 (PST) X-Originating-IP: [2001:c40:0:3080:9563:8c33:cf08:4dfb] In-Reply-To: References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> Date: Wed, 4 Nov 2015 16:23:55 -0500 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 21:24:07 -0000 On Wed, Nov 4, 2015 at 3:21 PM, John C Klensin wrote: > > > --On Wednesday, November 04, 2015 15:10 -0500 Andrew Newton > wrote: > >> On Tue, Nov 3, 2015 at 7:21 PM, Keith Moore >> wrote: >>> 2. an IANA registry of r-component facets, with namespaces >>> strongly discouraged from defining facet names that appear to >>> be generic but are actually namespace-specific >> >> This seems like a fine idea for the working group to consider. >> But it does not guarantee resolution of all URN namespaces, >> nor does it guarantee resolution of all URN namespaces that >> can be resolved. An implementer cannot take the 2141bis RFC >> and be assured that whatever new URN pops up in the future >> will be compatible with their URN resolver. They must >> periodically check the IANA registry and add new behavior to >> their software from time to time. > > Andy, one addition to this. I'm not quite sure what a > "r-component facet" is, but the proposal that started us down > the path toward separation of q-components and r-components was > one to require that URN pairs and that a registry of those names be created to identify > ones with global (across-URN) meanings. The WG didn't like that > idea at all (in retrospect, for good reason). > Thanks John. I had missed that aspect. And I'll have to defer to your history as my mind has blocked the trauma of the rickety bridge that has gotten here. :) I think a better definition of "facet" with respect to r-components is a good thing, along with some examples. As it stands, I don't know what it means either. > In addition, in principle, we could simplify the spec somewhat > by (again) proposing and defining such global keywords and > eliminating the syntactic distinction between the two component > types. I mention that, not to restart the separation argument > but to suggest it illustrates why a design conditioned on such a > registry -- one that I think essentially requires an implementer > to predict what facet names will be registering the future as a > condition for predictable operation -- is a non-starter. I think we are saying the same thing. The addition of an item in an IANA protocol registry does not magically change software behavior. We should probably have a better grasp of the use of this IANA protocol registry before creating it. -andy From nobody Wed Nov 4 19:45:06 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03111A895D for ; Wed, 4 Nov 2015 19:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTrV_hnuYnrG for ; Wed, 4 Nov 2015 19:45:02 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBE11A893B for ; Wed, 4 Nov 2015 19:45:02 -0800 (PST) Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4220E509BB; Wed, 4 Nov 2015 22:44:56 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_8FBD17D3-C4C5-4345-AC64-EE2B6831E2AF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <8FE8331AD32AB8E2A6FB74F3@JcK-HP8200.jck.com> Date: Thu, 5 Nov 2015 12:43:08 +0900 Message-Id: <81B28DDA-B129-45D8-92C4-1C3A6D3CFF08@seantek.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> <5637E38E.2050704@andyet.net> <8FE8331AD32AB8E2A6FB74F3@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org, Peter Saint-Andre Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 03:45:04 -0000 --Apple-Mail=_8FBD17D3-C4C5-4345-AC64-EE2B6831E2AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 3, 2015, at 10:42 AM, John C Klensin wrote: >=20 >=20 > --On Monday, November 02, 2015 15:28 -0700 Peter Saint-Andre > wrote: >=20 >> On 11/2/15 3:17 PM, Sean Leonard wrote: >> ... >>=20 >>> On Nov 2, 2015, at 9:29 PM, John C Klensin >>> wrote: >>>=20 >>>> The problem with doing it in a Wiki is the same as the >>>> problem with "tutorials" about a standard that are produced >>>> by the body that produced the standard: because they are >>>> almost inevitably easier to read than the standard itself >>>> (if only because of the details that are left out), they >>>> tend to become the standard in practice. >>>=20 >>> Then put a disclaimer at the top of the Wiki that this is >>> just for brainstorming and discussion only, and delete the >>> Wiki when done. >>>=20 >>> If the Wiki is easier to read than the standard document, >>> that's an indictment of the standard document. Don't >>> choose things because they are more difficult to use. >=20 > No, it is at least as often the result of the tutorial making > simplifying assumptions or leaving things out while the standard > really has to cover all of the cases. >=20 >>> Look: the alternative is what is happening here: years and >>> years of endless discussions by e-mail with various points >>> brought up again or rehashed in variant form by different >>> participants. >=20 >> I don't think that using a different tool will magically help >> us through this impasse. Pointing to a wiki page isn't all >> that different from pointing to the list archive. >=20 > Mostly agreed. To clarify my concern, had Sean said "issue > tracker" I wouldn't have objected significantly. Issue tracker could work. Anyway well now that we=92ve generated so much e-mail traffic, may as = well finish this out here, until we completely peter out or start = getting elliptical about arguments twice or three times in a row=85 Sean --Apple-Mail=_8FBD17D3-C4C5-4345-AC64-EE2B6831E2AF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTA1MDM0NDU0WjAjBgkqhkiG9w0BCQQxFgQURYe5Li/ojOA7VdcCe+lJGtec7qIwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBALPa968OcHSHwIUwi/EztLR6Kqs59Rn9DoKofsddUXvNihllhVhXmQt3DJgJB0jbOaaA 63dWbM5jjt+J65R7ZYb166Leoy3Ck8QcK2y9+jY2T+U6AO+KTEwo8EUSjqSOHCQg6q1vBJNes+28 S5E95gWcrUcRszwgMwdYJ/JuffePmZCoCB8VBXlwARUGeJ/ieHxb3JDkfcp2Y6PWdro7bn5lMQOI ttfR2aVJoJojoOz+450YhlAy6FJxMa0fzw6CfvhqZQ/4kloRmuhiZqTHLfDdVqAn1KPEY9gLKS5N 4s60+8ALsRIKMVrF/Ef4DJT7daiEVphfqWhBd2cxOq7Z9BgAAAAAAAA= --Apple-Mail=_8FBD17D3-C4C5-4345-AC64-EE2B6831E2AF-- From nobody Wed Nov 4 20:01:09 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10F1A8A1F for ; Wed, 4 Nov 2015 20:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlojtS9leYeC for ; Wed, 4 Nov 2015 20:01:08 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6C01A8A1C for ; Wed, 4 Nov 2015 20:01:07 -0800 (PST) Received: by wimw2 with SMTP id w2so1908619wim.1 for ; Wed, 04 Nov 2015 20:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9Nxh1XCwdIOF1NcK8j0IEDdexgZpe4TzZaJz/MtAY6k=; b=VXY7ExONgVgFVrdqJpmIbJZYsnb62QKJEGRK0/ThPjFZsYUQiD8x5G3KnRFAV4glmS 3NCWkcjhkrPrsKTr13TsdWnvyKh7a1N3FhSs8+NH4gJCkn8N5ikXrBhejER/m0HQ01IG TE2pcNjEIIEfMQzPZL3oiJlp/exraRxwL0NG6sshtOjdZwhoAX7pIcJkJtgmtBKKbqmH KYGAglG1UY3BeZK3Y89x0nhmA1ikt5ahaUha4Hn8jcRtBCE4XpKorjIRwz+Acn5FbazH tR/WgefijLiLGwwFeq28d5aPKPbSd0IVCucAxSR1bQujZhe8Me73jHZDf910xDXfGlEm xbHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9Nxh1XCwdIOF1NcK8j0IEDdexgZpe4TzZaJz/MtAY6k=; b=N8poWYf5ckmygDnYXTqBzlXow8rxTBtHNJcmlvNE3rqsXJGi7HrAup7yb/ckdaO82p XnLpnqucDUQGx7dGIVh39zCohssCVo88lfMXuaXFGnuV/wLEP+PS4sp/wCb44aYJC6GG M1jA5UejctMKNVEzJaYnVI1RM6EcTDYGSfyarKsAaqnJz/ihDYnXMc8uoU0lo4cW/OKk WMjLKvwZEEm+/ONIJ7JCS/bX+X18cyvfLHvwTBzP3aZarHOEKE2BjoPesqgmwIrfsELk 0pbmy5B0agm8I6MpTuIdS69zkFXwbndU5Dip4+gCsr6tMqyPMNrcTL5QHn/5Fair5Vlz 7DuQ== X-Gm-Message-State: ALoCoQnXeyk+A8TgZ51bOmVeLmzdY4bkPfXiuPWMthTUaBsAMUcyLlZkx8EsWmGRQ8ErfEuxjzYU MIME-Version: 1.0 X-Received: by 10.194.20.130 with SMTP id n2mr2650341wje.115.1446696066477; Wed, 04 Nov 2015 20:01:06 -0800 (PST) Received: by 10.194.91.134 with HTTP; Wed, 4 Nov 2015 20:01:06 -0800 (PST) X-Originating-IP: [133.93.86.12] In-Reply-To: <81B28DDA-B129-45D8-92C4-1C3A6D3CFF08@seantek.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> <5637E38E.2050704@andyet.net> <8FE8331AD32AB8E2A6FB74F3@JcK-HP8200.jck.com> <81B28DDA-B129-45D8-92C4-1C3A6D3CFF08@seantek.com> Date: Thu, 5 Nov 2015 13:01:06 +0900 Message-ID: From: Andrew Newton To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "urn@ietf.org" , Peter Saint-Andre Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:01:09 -0000 On Thu, Nov 5, 2015 at 12:43 PM, Sean Leonard wrote: > Anyway well now that we=E2=80=99ve generated so much e-mail traffic, may = as well finish this out here, until we completely peter out or start gettin= g elliptical about arguments twice or three times in a row=E2=80=A6 I've been thinking about this issue. And just because the wiki idea has not found favor does not mean there is no problem. Discussions on this list can be extremely hard to follow. It's funny that you mention an issue tracker. I use a GitHub issue tracker for one of my drafts, and it works great. But we tried that here without success. Perhaps we need a lot more mailing list discipline. I've seen TZDIST treat their list like an issue tracker. Maybe we should do the same. -andy From nobody Wed Nov 4 20:41:34 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E441A1A4B for ; Wed, 4 Nov 2015 20:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwb2enbQiB7B for ; Wed, 4 Nov 2015 20:41:31 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1E21A1A15 for ; Wed, 4 Nov 2015 20:41:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C0B7F20E40 for ; Wed, 4 Nov 2015 23:41:30 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 04 Nov 2015 23:41:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=7oWbD1hHWFOjnDY Nyypl+coIrYw=; b=ZHSTx4Pl2wqlgwOnkfgrEu5FN8m9Odst/LqCI5861GyPKjx BdNd69W/ZBZdbicvmzTcYRqvbaejduKX+7H0K7sSLwm0Kay7ut28BybwvPwq+xJA efX7op1U/uvoLgP0XGv28pngzcuxP74RqbIIWTyp2y5NQ9qzBZAZPjNIVDQY= X-Sasl-enc: SRFGTsND7mxlQz+l6OtDQ3DxiuagRIXFNaCDuiBkTtBN 1446698490 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 52C75C016C4; Wed, 4 Nov 2015 23:41:30 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <04A62AC9-11B3-4C6E-9DE7-6C50441BBE9E@seantek.com> <5637E38E.2050704@andyet.net> <8FE8331AD32AB8E2A6FB74F3@JcK-HP8200.jck.com> <81B28DDA-B129-45D8-92C4-1C3A6D3CFF08@seantek.com> From: Keith Moore Message-ID: <563ADDD8.3010606@network-heretics.com> Date: Wed, 4 Nov 2015 23:40:56 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <81B28DDA-B129-45D8-92C4-1C3A6D3CFF08@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:41:33 -0000 On 11/04/2015 10:43 PM, Sean Leonard wrote: > Issue tracker could work. An issue tracker can work well when the issues are entirely independent, and a decision on one issue isn't likely to have significant ripple effects. I'm not sure that's the case for the current state of discussion. When there are significant dependencies between issues, you can get rough consensus on a lot of separate issues that, taken together, preclude a solution. Keith From nobody Wed Nov 4 20:52:02 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FD21A911F for ; Wed, 4 Nov 2015 20:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uRbODvsQWNO for ; Wed, 4 Nov 2015 20:51:53 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2993D1B38EB for ; Wed, 4 Nov 2015 20:51:53 -0800 (PST) Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 85CD3509BE; Wed, 4 Nov 2015 23:51:49 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_0EE12B15-5E74-4645-8671-EB5B4749E36B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <56394996.7000507@network-heretics.com> Date: Thu, 5 Nov 2015 13:49:58 +0900 Message-Id: <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:51:54 -0000 --Apple-Mail=_0EE12B15-5E74-4645-8671-EB5B4749E36B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 4, 2015, at 8:56 AM, Keith Moore = wrote: > On 11/02/2015 06:01 PM, Sean Leonard wrote: >> On Nov 3, 2015, at 12:37 AM, John C Klensin = wrote: >>=20 >>>=20 >>> --On Monday, November 02, 2015 08:11 -0500 Keith Moore >>> wrote: >>>=20 >>>> [...] >> Some resolutions will naturally be specific to and defined by the = namespace (or sub-namespace, if so inclined to view things that way). = For example: >>=20 >> urn:xmlns:foobar2015 >>=20 >> is meant to represent an XML namespace. If resolved and dereferenced, = it is supposed to always return an XML schema (.xsd, application/xml or = text/xml), namely the XML schemas that are registered with IANA on a = first-come, first-served basis. > Two questions: >=20 > 1. In the case of a URN that named an XML namespace, would returning = the XML schema be equivalent to accessing the content of that URN, or = would that need to be a distinct operation? If not, why not? >=20 > 2. Say there's an XML namespace that's named by URN that's not an = xmlns URN. Should the operation to retrieve the XML schema associated = with that namespace be different than for a namespace named by an xmlns = URN? If so, why? >=20 >> Most resolutions, however, are not specific to or defined by the = namespace. For or = , they could be resolved = in lots of ways (accession number, shelf location, Amazon.com product = page, data: URI, abstract pointer to in-memory security object) and I = believe that Keith=92s essential points are that all of these = resolutions are contextually valid and that namespaces such as isbn: and = uuid: SHOULD NOT be read to restrict the resolution possibilities. >=20 > yes. >=20 >> But what=92s good for one set of identifiers may not be good for = another set of identifiers. >=20 > My suspicion is that most, but not all, of the resolution services and = parameters that people want to associate with particular namespaces are = not in fact inherently specific to those namespaces. So while it's = probably necessary to be able to support namespace-specific services and = resolution parameters, it would be unfortunate if every namespace = developed its own completely different set of services and parameters. Keith I see your point, and I gather that the overall gist is that there = should be a resolution operation, =93get XML namespace schema=94, that = applies with equal semantics across all URNs. The difference is that = urn:xmlns guarantees that such content is available; other namespaces = (e.g., urn:oid, urn:uuid) do not make such guarantees but are = sufficiently broad or abstract that such schemas can be associated with = them; and still other sub-namespaces (urn:ietf:params) are designed to = identify XML namespaces but not . So your point is that a common verb or operation token should apply with = equal force across all URNs, rather than defining a =93getxmlschema=94 = verb that works in one way with urn:xmlns, but behaves completely = differently for another NID. Is that correct? Another example: urn:isbn identifies books and published works, but some = urn:nato identifiers could equally be about books and published works = (namely those created by NATO). And perhaps one day the ISBN = organization (International ISBN Agency) could totally change its = purpose and designate urn:isbn:foobar:=85 to identify something totally = different. So your point is that the verb =93return library locations=94 = should apply with equal force across this whole range of URNs. Is that = correct? >=20 >> And my argument is that even though you could identify an XML = namespace with urn:xmlns:foobar2015 and then resolve it into something = utterly tangential to the original purpose (e.g., a picture of cats), = there really is no functional value in doing so. >=20 > I'm not sure how that argument applies to this discussion, but I agree = with the statement. My point is that if you have ,= and the XML implementation wants to get the schema, the *default* = retrieval/resolution action is to return the XSD/XML schema, since = =93?getxmlschema=94 is not appended. I suppose that there is an implicit context in this case, namely that = XML processors will dereference URIs with the contextual purpose of = filtering through the results for the kinds of things it wants. For = example if the URI is HTTP, then the XML processor should set the = Accept: header so that application/xml resources are preferably = returned. So too with URN resolution: the resolver is queried with some = contextual information that says that particular things are being sought = (in this case, ?getxmlschema), and that is regardless of what urn: NID = is in place. Sean --Apple-Mail=_0EE12B15-5E74-4645-8671-EB5B4749E36B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTA1MDQ1MTQ3WjAjBgkqhkiG9w0BCQQxFgQUGbH4ZveiLyGJOQs4n1/VvKrjxuswgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBABqOkKyVTwJUBdyM6jd14pVDVdxtA3QNNT1uBG72a1dVL0IEl0xb1uXRZR4pc6ZqPyDs WFszxs5b7+sbdewunNEWp3KHJU98s9wHiyPIAIUfhU5Qk56QOtJR785YrdrNje8p2YeWDYreLGiV 9bTLDJyOkA4e89I8wGM1v5tysedwR1c7l+dDXlFY8At+x/vvXQHJFtj1BnYvK2Ei9tM5QP1LyxgA WRBlX/TraHbmoJDiAutvjb6j62ZAQdQ7K+5aycXnSNhk8fRPzGf9m7gLVNSOBWgnqzX0UB3vf+wF g/syd0Y4AysIIQN0+i8gxyyOnjvRNCbxaIwWjt5qIO8XFh8AAAAAAAA= --Apple-Mail=_0EE12B15-5E74-4645-8671-EB5B4749E36B-- From nobody Wed Nov 4 21:23:45 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB541B3994 for ; Wed, 4 Nov 2015 21:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt53Ft0LROxZ for ; Wed, 4 Nov 2015 21:23:42 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29AC11B399B for ; Wed, 4 Nov 2015 21:23:42 -0800 (PST) Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B4AAB509BE; Thu, 5 Nov 2015 00:23:39 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_0D1416BC-12DE-44FD-AFBE-5D1FE34F37F5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <56395DA7.6010803@network-heretics.com> Date: Thu, 5 Nov 2015 14:21:44 +0900 Message-Id: <41227A89-C0B0-47C8-AB1A-8E46109CB483@seantek.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> <564D51F3-C4C8-402E-AE84-098211246A63@seantek.com> <56395DA7.6010803@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:23:44 -0000 --Apple-Mail=_0D1416BC-12DE-44FD-AFBE-5D1FE34F37F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 4, 2015, at 10:21 AM, Keith Moore = wrote: > On 11/03/2015 07:48 PM, Sean Leonard wrote: >> [SNIP] >> In discussing how resolution works, it=92s very helpful to have some = concrete result. If we talk about the algorithm in very hand-wavy = high-level terms, we don=92t have anything implementable. Saying that = the algorithm returns a list of URIs, is an implementable algorithm. >=20 > I understand the discussion dilemma, and often face that myself. Too = much precision and you lose the reader, too little and the reader can = get misleading impressions - especially in a discussion like this one. >=20 > I don't think that text/uri-list is a good choice if it's the only = output format that can be returned, for several reasons. Perhaps the = most obvious is that resolution services will be expected to do more = than provide a list of URLs - they will also be expected to provide = metadata. There are several existing formats for various kinds of = metadata, and it would make good sense if resolution services could = return them. Also, even if the service requested is a list of URLs, = the resolution service is not in a good position to determine ordering = for the client. Finally I would suggest that if there's going to be a = designated format for a list of URLs, it should allow each URL to be = tagged with zero or more attributes to help the client decide which = order to consult them in. (To cite one example from previous = experience: Having the resolution service act as a DNS cache for the = URL servers' IP addresses can result in a tremendous improvement in = access times.) >=20 > But I agree that having a standard way to request a list of URLs of = the resource, and a standard response format, would be appropriate. I = also agree that the standard should be simple. (but it should also be = extensible) >=20 > My suggestion would be [JSON list] I am all in favor of adding optional attributes to URIs (URLs) for = metadata as you describe. I actually have been working on a very similar = technology for certspec (draft-seantek-certspec), which is a uniform way = to identify PKIX certificates and convey associated attributes, which = may be preferences, friendly names, trust information, and so on. This = used to be urn:cert but I am taking a different approach where the = string is not a URI at all. It is of the form: certid [=93|=94 certattrs] [=93#=94 certfrag] Namely | is the separator character between the identifier for the = certificate, and optional tagged attributes. This is different from the = fragment for straightforward reasons. Similarly, I propose =93text/uri-list2=94, which is a CRLF-delimited = list of URIs, where the URI has optional tagged attributes after the | = character: http://www.amazon.com/dp/abcde|attribute1=3D"buy",ip=3D"33.33.33.222"=20= data:text/html,base64;MIICS=85|attribute1=3D"info" etc. (In this example, the attributes are formatted as JSON. The = outermost data element is a JSON object without the { } characters, CRLF = is prohibited since that=92s the delimiter between lines, and attribute = names do not need to be quoted.) The reason for this instead of straight JSON is that it is shorter, and = we don=92t commit ourselves to JSON specifically as the nature and = format of attributes is probably way out-of-scope for the URNBIS draft. = Also as a bike shedding matter, I prefer CBOR to JSON. :) But as an analytical framework, hopefully we can reach consensus on the = principle that a resolver returns a list (ordered) or set (unordered) of = resources--which are URIs or at least representable as URIs--along with = optional attributes. Sean= --Apple-Mail=_0D1416BC-12DE-44FD-AFBE-5D1FE34F37F5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTA1MDUyMzM3WjAjBgkqhkiG9w0BCQQxFgQUHIp8ZbG2vVr+NgDb7cyoZuT/8QAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAIWIrxVIPu0vuYjKVCZYWSmiUUKL+P4qcrJocUOb8NEiqgXTUp7ayk5BvrHifHlbTHMB fdOF28fYUueaNJBJQG2i8QXPH0MhUayg824YbopGb921te2HT/8+J34eZQG3Si2xJ8XJHmPGLJMv 8NbMHeVHuc3cRWnT7X3b88MOj61bMx1gQMxu8gChYDEl+YdvfgqOCX4u1o+7i2sSjQh3U9QE/IKv 5LU0jTEgybW71WsrCl3bwJDxc1qAZnFdGeWevEK0IsRjLEYev977IgY486ooiG7vLA226oWBpnT/ lkCaUbezGSx1bwhbRajFpyrD531ChZld6BimZp8B84PEXV4AAAAAAAA= --Apple-Mail=_0D1416BC-12DE-44FD-AFBE-5D1FE34F37F5-- From nobody Thu Nov 5 00:03:26 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6B1B36C5 for ; Thu, 5 Nov 2015 00:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBJJqKLP8aZU for ; Thu, 5 Nov 2015 00:00:49 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DCD1B33B2 for ; Thu, 5 Nov 2015 00:00:49 -0800 (PST) Received: from [192.168.178.20] (unknown [84.187.59.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 83E0D15A064E; Thu, 5 Nov 2015 09:00:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1446710447; bh=nIpVPYxfoHnk1m87RFzA2UJXxu70UPXlY7J8+2bUstc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CWv0JQFZ5Cgfyqb2j7pjv/CVmKj75Xl5sr3Oo41FsyMBt2KvN4Ll12i3agLvwsiAj S+IBx6GIXiR/hL209OkFUQ0jfGRfQwCJb4eaTwhjk5vDh6pUXycwP0jN+E+CQeunam KHm7lF4/ZnCiUYSwELaMNCTzG5uGTiz/qVYoB0EA= To: Keith Moore , urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> <564D51F3-C4C8-402E-AE84-098211246A63@seantek.com> <56395DA7.6010803@network-heretics.com> From: Julian Reschke Message-ID: <563B0CAF.6020808@greenbytes.de> Date: Thu, 5 Nov 2015 09:00:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56395DA7.6010803@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 05 Nov 2015 00:03:25 -0800 Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:00:52 -0000 On 2015-11-04 02:21, Keith Moore wrote: > ... > But I agree that having a standard way to request a list of URLs of the > resource, and a standard response format, would be appropriate. I also > agree that the standard should be simple. (but it should also be > extensible) > > My suggestion would be > > content-type: application/json.uri-list > > where the result consists of a single JSON list, each element of the > list is a JSON object, and each such object has the required the tag > "uri" and may have other optional tags (defined in an IANA registry, but > one such tag would be "addresses", and each address would be a tuple > consisting of an IPv4 or IPv6 address (as a string) and a > cache-expiration date-time. > ... Which reminds me of ; in particular have a look at the way link relations are defined (and they have a IANA registry). Best regards, Julian From nobody Thu Nov 5 00:06:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490A91B3BB8 for ; Thu, 5 Nov 2015 00:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZGJhf_eRZxP for ; Thu, 5 Nov 2015 00:06:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B87A1B3580 for ; Thu, 5 Nov 2015 00:06:32 -0800 (PST) Received: from [192.168.178.20] ([84.187.59.11]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M93Jp-1Zk6A81XNV-00COUm; Thu, 05 Nov 2015 09:06:25 +0100 To: Keith Moore , urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> <564D51F3-C4C8-402E-AE84-098211246A63@seantek.com> <56395DA7.6010803@network-heretics.com> From: Julian Reschke Message-ID: <563B0E01.4040601@gmx.de> Date: Thu, 5 Nov 2015 09:06:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56395DA7.6010803@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:x825oEWSJxhNxCDhaiF5J0HbW2Epn8S0MgyvBf43PSYiA++A8XT tatZdGnV3+8QmptcCeOX2M/KnGQQ/n3dNn4mGc1Sl15DNkBvpuBAG1aKvF6twATqGHHV/KD Kxjcno6z8wGQpj5SsMeR7g0kdCxb5eWBs5jAQHRTb2FMGGQYjyjuj1/soijXUu53eY4tohL 7nWAJCigRvbFhe4Bc5hpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:dI+K+vgaeEo=:1a/wHfJxyV3fdTEBc75at0 TPIgeyvhPJNg5qUG33YLDbXgimLE8Jc2d9LQz0I9x43D+7noU2+5NVh7Cpt4BCYrDChttePe5 nYfUJ/uOJ4uK8OQQbalbCSNS6WAjmdMC4W9jQKbxO/nzpw1wWunIPN3K925505fWeX4XlnkJr GTO0ZkINKCqpmKAiZqqpURMVAlPNT8v96OZwGOIAT83kXTLg7G2ZpCtrAJAUO0J5fIWWezQqS EGOTAZgaw/As8BToVVI8ILZf0dNmObG23hDVfL8ToaI3+/0OQWa59ie25RdD/YWnXNt+bjcW3 2ezw1VSKvey7+iNGZCzEkHWWhjRq58XW5EgVQ4GEvD3rhXeriYv8P5VR3wFc2hogPnRWi+WeK 2+TSTyVUzQymvTzJF00ipIdBIbOzYeV9Gawrur5jgLQMShruF6TgYj7t9AUG/leFNcbskO6Dt vdJWLr9kpFOUtIkUP6JQA1zP/UGsTc/KnjacW0nSK8gtOw1dyAgluYoccw8vTtOQsmJssuu8j KhXrvWaa2Ghmf1TAKc071TiSAlQ5/hbZw3RqPLEowp69yOkaA/e2WcF44KlQW2yC0vQhvlL/V F4VEjWM+wbSb27P8egjVRspdEWHvcyT6G32jYDjDNc/BwqwhPSVN1/G2i6M2C0j4wTmDl7/mQ fkzrBnV62bh7NCWIs4XBVxgHQoAQe8DiU01USiIjY34QWoNlK1mSFn6tyVUTcV9hp7yyjDv8x qBr7xlrhwztrmQOvMVTddHsvhf+KhE8lQQKCkfDasqn9bGmnoyC96vGLn1VtzIUstc4F2NF4T Ii1X0Jb Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:06:34 -0000 On 2015-11-04 02:21, Keith Moore wrote: > ... > But I agree that having a standard way to request a list of URLs of the > resource, and a standard response format, would be appropriate. I also > agree that the standard should be simple. (but it should also be > extensible) > > My suggestion would be > > content-type: application/json.uri-list > > where the result consists of a single JSON list, each element of the > list is a JSON object, and each such object has the required the tag > "uri" and may have other optional tags (defined in an IANA registry, but > one such tag would be "addresses", and each address would be a tuple > consisting of an IPv4 or IPv6 address (as a string) and a > cache-expiration date-time. > ... Which reminds me of ; in particular have a look at the way link relations are defined (and they have a IANA registry). Best regards, Julian From nobody Thu Nov 5 04:18:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FE91AD0BF for ; Thu, 5 Nov 2015 04:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhLYh5Pr_FS0 for ; Thu, 5 Nov 2015 04:17:58 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CBA1AD0BE for ; Thu, 5 Nov 2015 04:17:58 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4F4AA21B5D for ; Thu, 5 Nov 2015 07:17:57 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 05 Nov 2015 07:17:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=K4DBzlNJ5vcGTzD TVE6Np1RQ4lo=; b=owtdnN3nf4Mz64tn5gECzT289CbYvWwS3tprGz6g9/Octu7 1CRbnCHTaR1U3a7FMvewWjt+lgVNgnPas+jjk4SYOKTTvRD6iDVlVqg83dfObgMl lTG90owZh69ti3pFw47bSw+HmHoNMU6MS+DF5WXDJbjRxvrI2MUkeyZkeHYs= X-Sasl-enc: w+CPAcBRveL7gNR4LKfCefC5IalIVDQMXQ6TW+lBRa61 1446725877 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id D0C4D680134; Thu, 5 Nov 2015 07:17:56 -0500 (EST) To: Sean Leonard References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <4C54F1FBC78A7BC0D27A15D6@JcK-HP8200.jck.com> <564D51F3-C4C8-402E-AE84-098211246A63@seantek.com> <56395DA7.6010803@network-heretics.com> <41227A89-C0B0-47C8-AB1A-8E46109CB483@seantek.com> From: Keith Moore Message-ID: <563B48D0.1070906@network-heretics.com> Date: Thu, 5 Nov 2015 07:17:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <41227A89-C0B0-47C8-AB1A-8E46109CB483@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 12:17:59 -0000 On 11/05/2015 12:21 AM, Sean Leonard wrote: > But as an analytical framework, hopefully we can reach consensus on the principle that a resolver returns a list (ordered) or set (unordered) of resources--which are URIs or at least representable as URIs--along with optional attributes. Agree that that's one possible result. But if the request isn't for URLs but instead for a particular kind of metadata, the resolution service should be able to return the requested kind of metadata. The service should also potentially be able to return information about URIs related to (but not necessarily the same as) the resource named by the requested URI. (e.g. the URN I have is for version 2, is there a later version available?) And finally the service should be able to return a list of the kinds of information which it possesses about the URI. Keith From nobody Thu Nov 5 05:09:16 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64C81B2ADC for ; Thu, 5 Nov 2015 05:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooNo-fpIwL8m for ; Thu, 5 Nov 2015 05:09:11 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BDB1B2ADD for ; Thu, 5 Nov 2015 05:09:08 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E45E521A99 for ; Thu, 5 Nov 2015 08:09:07 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 05 Nov 2015 08:09:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=6yOuEP0T4P9miDWJZDORRqR33vo=; b=IEPCU 1KGXOuDR+j8lxD0zpIHdS9sSK7YAYLqkmPii7OYxoiVwLvQubwDIOlp30qW8pV8J PTs1bI6KfIPQwoznH980KV9sSEUZWRoqsHGEA9gumsvOPtM7UfwzxMWb9sZnCB8K O6UD/2s/TFyXLeZx+P8eYrCwOhYc9nFbLtrfGg= X-Sasl-enc: 4WdBTvQmqyAybetUHAnl91yszk1WgLTDxXO9sAIgmzlv 1446728947 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 7275B6800AA; Thu, 5 Nov 2015 08:09:07 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> From: Keith Moore Message-ID: <563B54D0.90602@network-heretics.com> Date: Thu, 5 Nov 2015 08:08:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> Content-Type: multipart/alternative; boundary="------------050802080600020401070300" Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 13:09:13 -0000 This is a multi-part message in MIME format. --------------050802080600020401070300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit >>> Some resolutions will naturally be specific to and defined by the namespace (or sub-namespace, if so inclined to view things that way). For example: >>> >>> urn:xmlns:foobar2015 >>> >>> is meant to represent an XML namespace. If resolved and dereferenced, it is supposed to always return an XML schema (.xsd, application/xml or text/xml), namely the XML schemas that are registered with IANA on a first-come, first-served basis. >> Two questions: >> >> 1. In the case of a URN that named an XML namespace, would returning the XML schema be equivalent to accessing the content of that URN, or would that need to be a distinct operation? If not, why not? >> >> 2. Say there's an XML namespace that's named by URN that's not an xmlns URN. Should the operation to retrieve the XML schema associated with that namespace be different than for a namespace named by an xmlns URN? If so, why? >> >>> Most resolutions, however, are not specific to or defined by the namespace. For or , they could be resolved in lots of ways (accession number, shelf location, Amazon.com product page, data: URI, abstract pointer to in-memory security object) and I believe that Keith’s essential points are that all of these resolutions are contextually valid and that namespaces such as isbn: and uuid: SHOULD NOT be read to restrict the resolution possibilities. >> yes. >> >>> But what’s good for one set of identifiers may not be good for another set of identifiers. >> My suspicion is that most, but not all, of the resolution services and parameters that people want to associate with particular namespaces are not in fact inherently specific to those namespaces. So while it's probably necessary to be able to support namespace-specific services and resolution parameters, it would be unfortunate if every namespace developed its own completely different set of services and parameters. > > Keith I see your point, and I gather that the overall gist is that there should be a resolution operation, “get XML namespace schema”, that applies with equal semantics across all URNs. Well, that's not really what I was thinking. I suppose it depends on the defined relationship between the URI that names an XML namespace and the XML schema of the namespace. If the defined relationship is such that the XML schema of a namespace is the /content/ of that URI, then there's no need for there to be a special purpose resolution operation "get XML namespace schema", the ordinary "get URLs associated with this URI" is sufficient because the schema could then be obtained from one of those URLs. I believe that the fewer resolution operations that only apply to a few URIs, the better. But if that's not the defined relationship between the URI and the schema, you probably do need a special operation. That said, I believe that resolution services will need to potentially support a very wide range of metadata types that are associated with any particular resource, and most of these will be opaque to the resolution service protocol engine itself. So for instance, if the client asks the resolution service for metadata of arbitrary type FOO, the service will simply look to see if it has a file of metadata of type FOO associated with that URI. If it does, it returns that metadata; if not, it says "sorry, I can't do that". (There might be also the capability to translate between a few kinds of known metadata to others. So if the client asks for Simple Dublin Core XML, and the service doesn't have that, it might however have the equivalent information in some other format and be willing to translate.) So it might be that the client could just say: I want metadata about this URI, and the particular form of metadata that I want is the XML schema of the namespace that this URI represents. To me that sounds like stretching the definition of "metadata" a bit. But the protocols would support it, and it would avoid having to define an entirely new operation. > The difference is that urn:xmlns guarantees that such content is available; other namespaces (e.g., urn:oid, urn:uuid) do not make such guarantees but are sufficiently broad or abstract that such schemas can be associated with them; and still other sub-namespaces (urn:ietf:params) are designed to identify XML namespaces but not . Yes. Though if I recall correctly the XML namespace specification doesn't even constrain the URI to that degree - any URI that uniquely names the namespace would do. (In general I have the impression that people are placing far too much emphasis on what they think a particular URN namespace "means". I believe the purpose of URN namespaces is simply to permit federated assignment of URNs while still preserving uniqueness and persistence properties of URNs, and people and (especially) software shouldn't be inferring resource types by looking at the namespace. So for instance no XML processor should be looking at the URN namespace and saying "sorry, that URN namespace is not sufficiently broad or abstract to be used to name an XML schema" - it should instead try to obtain the schema itself via the normal means. If that operation fails it can say "sorry, I couldn't obtain the schema".) > So your point is that a common verb or operation token should apply with equal force across all URNs, rather than defining a “getxmlschema” verb that works in one way with urn:xmlns, but behaves completely differently for another NID. Is that correct? I'm not sure what "equal force" means. But I'm fairly confident that if we can define a small number of common resolution operations (things like "get URLs of locations of this resource and please return them in format X, or Y, or Z" and "get metadata of type FOO associated with this resource and return it in either format A or format B") that are potentially applicable to most URNs, we'll get more clients that are capable of doing things with URNs, than if we require a separate, specific operation like "getxmlschema" to be defined and implemented and deployed in resolution services for every different kind of request that someone or some client might need to make. > Another example: urn:isbn identifies books and published works, but some urn:nato identifiers could equally be about books and published works (namely those created by NATO). And perhaps one day the ISBN organization (International ISBN Agency) could totally change its purpose and designate urn:isbn:foobar:… to identify something totally different. So your point is that the verb “return library locations” should apply with equal force across this whole range of URNs. Is that correct? Something like that. If a "return library locations" operation seems widely applicable rather than inherently specific to ISBNs (and it does to me) then it makes more sense to standardize a "return library locations" operation for potential use by any URN than to make that operation specific to a namespace or resolution service provider. Or if "return library locations" can be accomplished by get_metadata(type=xml-library-locations), where xml-library-locations is an identifier for some well-defined schema, that might be better still - because a resolution service already supporting "get_metadata" could support it without needing a software update.) >>> And my argument is that even though you could identify an XML namespace with urn:xmlns:foobar2015 and then resolve it into something utterly tangential to the original purpose (e.g., a picture of cats), there really is no functional value in doing so. >> I'm not sure how that argument applies to this discussion, but I agree with the statement. > > My point is that if you have , and the XML implementation wants to get the schema, the *default* retrieval/resolution action is to return the XSD/XML schema, since “?getxmlschema” is not appended. > > I suppose that there is an implicit context in this case, namely that XML processors will dereference URIs with the contextual purpose of filtering through the results for the kinds of things it wants. For example if the URI is HTTP, then the XML processor should set the Accept: header so that application/xml resources are preferably returned. So too with URN resolution: the resolver is queried with some contextual information that says that particular things are being sought (in this case, ?getxmlschema), and that is regardless of what urn: NID is in place. > That sounds right. Keith --------------050802080600020401070300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 
Some resolutions will naturally be specific to and defined by the namespace (or sub-namespace, if so inclined to view things that way). For example:

urn:xmlns:foobar2015

is meant to represent an XML namespace. If resolved and dereferenced, it is supposed to always return an XML schema (.xsd, application/xml or text/xml), namely the XML schemas that are registered with IANA on a first-come, first-served basis.

Two questions:

1.  In the case of a URN that named an XML namespace, would returning the XML schema be equivalent to accessing the content of that URN, or would that need to be a distinct operation?   If not, why not?

2. Say there's an XML namespace that's named by URN that's not an xmlns URN.   Should the operation to retrieve the XML schema associated with that namespace be different than for a namespace named by an xmlns URN?   If so, why?


Most resolutions, however, are not specific to or defined by the namespace. For <urn:isbn:9999-9999> or <urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>, they could be resolved in lots of ways (accession number, shelf location, Amazon.com product page, data: URI, abstract pointer to in-memory security object) and I believe that Keith’s essential points are that all of these resolutions are contextually valid and that namespaces such as isbn: and uuid: SHOULD NOT be read to restrict the resolution possibilities.

yes.


But what’s good for one set of identifiers may not be good for another set of identifiers.

My suspicion is that most, but not all, of the resolution services and parameters that people want to associate with particular namespaces are not in fact inherently specific to those namespaces.   So while it's probably necessary to be able to support namespace-specific services and resolution parameters, it would be unfortunate if every namespace developed its own completely different set of services and parameters.


Keith I see your point, and I gather that the overall gist is that there should be a resolution operation, “get XML namespace schema”, that applies with equal semantics across all URNs.

Well, that's not really what I was thinking.   I suppose it depends on the defined relationship between the URI that names an XML namespace and the XML schema of the namespace.   If the defined relationship is such that the XML schema of a namespace is the content of that URI, then there's no need for there to be a special purpose resolution operation "get XML namespace schema", the ordinary "get URLs associated with this URI" is sufficient because the schema could then be obtained from one of those URLs.   I believe that the fewer resolution operations that only apply to a few URIs, the better.   But if that's not the defined relationship between the URI and the schema, you probably do need a special operation.

That said, I believe that resolution services will need to potentially support a very wide range of metadata types that are associated with any particular resource, and most of these will be opaque to the resolution service protocol engine itself.   So for instance, if the client asks the resolution service for metadata of arbitrary type FOO, the service will simply look to see if it has a file of metadata of type FOO associated with that URI.   If it does, it returns that metadata; if not, it says "sorry, I can't do that".   (There might be also the capability to translate between a few kinds of known metadata to others.   So if the client asks for Simple Dublin Core XML, and the service doesn't have that, it might however have the equivalent information in some other format and be willing to translate.)

So it might be that the client could just say: I want metadata about this URI, and the particular form of metadata that I want is the XML schema of the namespace that this URI represents.   To me that sounds like stretching the definition of "metadata" a bit.   But the protocols would support it, and it would avoid having to define an entirely new operation.

The difference is that urn:xmlns guarantees that such content is available; other namespaces (e.g., urn:oid, urn:uuid) do not make such guarantees but are sufficiently broad or abstract that such schemas can be associated with them; and still other sub-namespaces (urn:ietf:params) are designed to identify XML namespaces but not .

Yes.   Though if I recall correctly the XML namespace specification doesn't even constrain the URI to that degree - any URI that uniquely names the namespace would do.

(In general I have the impression that people are placing far too much emphasis on what they think a particular URN namespace "means".  I believe the purpose of URN namespaces is simply to permit federated assignment of URNs while still preserving uniqueness and persistence properties of URNs,  and people and (especially) software shouldn't be inferring resource types by looking at the namespace.  So for instance no XML processor should be looking at the URN namespace and saying "sorry, that URN namespace is not sufficiently broad or abstract to be used to name an XML schema" - it should instead try to obtain the schema itself via the normal means.   If that operation fails it can say "sorry, I couldn't obtain the schema".)

So your point is that a common verb or operation token should apply with equal force across all URNs, rather than defining a “getxmlschema” verb that works in one way with urn:xmlns, but behaves completely differently for another NID. Is that correct?

I'm not sure what "equal force" means.   But I'm fairly confident that if we can define a small number of common resolution operations (things like "get URLs of locations of this resource and please return them in format X, or Y, or Z" and "get metadata of type FOO associated with this resource and return it in either format A or format B")  that are potentially applicable to most URNs, we'll get more clients that are capable of doing things with URNs, than if we require a separate, specific operation like "getxmlschema" to be defined and implemented and deployed in resolution services for every different kind of request that someone or some client might need to make.

Another example: urn:isbn identifies books and published works, but some urn:nato identifiers could equally be about books and published works (namely those created by NATO). And perhaps one day the ISBN organization (International ISBN Agency) could totally change its purpose and designate urn:isbn:foobar:… to identify something totally different. So your point is that the verb “return library locations” should apply with equal force across this whole range of URNs. Is that correct?

Something like that.  If a "return library locations" operation seems widely applicable rather than inherently specific to ISBNs (and it does to me) then it makes more sense to standardize a "return library locations" operation for potential use by any URN than to make that operation specific to a namespace or resolution service provider.   Or if "return library locations" can be accomplished by get_metadata(type=xml-library-locations), where xml-library-locations is an identifier for some well-defined schema, that might be better still - because a resolution service already supporting "get_metadata" could support it without needing a software update.)
And my argument is that even though you could identify an XML namespace with urn:xmlns:foobar2015 and then resolve it into something utterly tangential to the original purpose (e.g., a picture of cats), there really is no functional value in doing so.

I'm not sure how that argument applies to this discussion, but I agree with the statement.


My point is that if you have <foo xmlns:bar=“urn:xmlns:foobar2015”>, and the XML implementation wants to get the schema, the *default* retrieval/resolution action is to return the XSD/XML schema, since “?getxmlschema” is not appended.

I suppose that there is an implicit context in this case, namely that XML processors will dereference URIs with the contextual purpose of filtering through the results for the kinds of things it wants. For example if the URI is HTTP, then the XML processor should set the Accept: header so that application/xml resources are preferably returned. So too with URN resolution: the resolver is queried with some contextual information that says that particular things are being sought (in this case, ?getxmlschema), and that is regardless of what urn: NID is in place.
That sounds right.

Keith

--------------050802080600020401070300-- From nobody Thu Nov 5 11:55:06 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9141B3514 for ; Thu, 5 Nov 2015 11:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAXwSKIlc-Fx for ; Thu, 5 Nov 2015 11:55:04 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBD51B350A for ; Thu, 5 Nov 2015 11:55:03 -0800 (PST) Received: by ykek133 with SMTP id k133so151130702yke.2 for ; Thu, 05 Nov 2015 11:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xiT78xj8JoM5RKqZ/TApa4ORo6v+ueg29IXopsb8x4o=; b=X59cuvV9BJhejG15M1rBRhg7rtJDdbyB8a4U88kroHd3w/+tHhadVrlk4wz9ljV1CK Qq7TcgWKyfG0jVMrzv9gcUBpMAPOHzgMUGo3TqfeXlke6U8yF8ovOdy+C+wtlH3PTMcD PRAyUnT4CZ4hIUkoidvJvD5L/Pv9QhHAiw0BBGbrKt1zdOHBYcm+Tr45wQ5iLg5/Tl3I Sf3BTNrPxXlTnjqaI72pBSRZ94/aL2juj5TaFrbb7BzBzLNirwvCQU9Vwg8rqV66I2xW Uxg/1ZGsNMY4IdR/Cw5cYjzLYpsjGotdFjHXgBP4o5wcA/WODQH4VzBJDPESAR4DrTOg KYbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xiT78xj8JoM5RKqZ/TApa4ORo6v+ueg29IXopsb8x4o=; b=cExlnwJAiEsAtnW1Mrnwf+hMMvv7ajUim+rKhu67dKg4ia0rIjoXO62K+fdJ1C3dsI rdtDsqX2cOdECg1zbF7OxM/v6DmeU6lKXfutKDrnadT2AcjZXBQDcObFzp0Gr7EwwDK8 VTWzDpxunjD7LIqOGrVczsNXhmfW6LLYNc9YfWxqcgVYuBehv3mu4+hcicCLplXNLmlr ujLdT6oQGSW2KcvjPhvl4wLXMAPBM5GoNUkUv6rCW5aWdG6/2f2pTevUafa3dftAL6rq /YfMoFUMc0crT6tkfYLNCw2FJvhFRYHq/5IACsQhEi1+9DRwoIJWvqDaaEZxTaoEkMjD j/3w== X-Gm-Message-State: ALoCoQm9Sdg2rGvMPW2UBz6vFt2L4/cSuUpqkcp5BFrTfW3ldoDHHx8rwTSvCbR8DPg2KUn05OEC MIME-Version: 1.0 X-Received: by 10.129.94.87 with SMTP id s84mr7889046ywb.268.1446753302864; Thu, 05 Nov 2015 11:55:02 -0800 (PST) Received: by 10.37.85.197 with HTTP; Thu, 5 Nov 2015 11:55:02 -0800 (PST) X-Originating-IP: [2001:c40:0:3080:65c7:4ca0:9ab5:b5eb] In-Reply-To: <563B54D0.90602@network-heretics.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> <563B54D0.90602@network-heretics.com> Date: Fri, 6 Nov 2015 04:55:02 +0900 Message-ID: From: Andrew Newton To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 19:55:05 -0000 On Thu, Nov 5, 2015 at 10:08 PM, Keith Moore wrote: > I'm not sure what "equal force" means. But I'm fairly confident that if we > can define a small number of common resolution operations (things like "get > URLs of locations of this resource and please return them in format X, or Y, > or Z" and "get metadata of type FOO associated with this resource and return > it in either format A or format B") that are potentially applicable to most > URNs, we'll get more clients that are capable of doing things with URNs, > than if we require a separate, specific operation like "getxmlschema" to be > defined and implemented and deployed in resolution services for every > different kind of request that someone or some client might need to make. What specific changes are you asking for in 2141bis? As the IETF saying goes, "send text". Otherwise I think this line of thought should end here. -andy From nobody Thu Nov 5 20:06:47 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A23D1AD0A7 for ; Thu, 5 Nov 2015 20:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH6QNFfglLd2 for ; Thu, 5 Nov 2015 20:06:44 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A4D1A8A50 for ; Thu, 5 Nov 2015 20:06:44 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DB3A02070C for ; Thu, 5 Nov 2015 23:06:43 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 05 Nov 2015 23:06:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sP8JLun1k+B0l7q OqpyejpDod1w=; b=f81FfZQSGnzp9MvKctY1A84u0Ks+wwY4xSVNvwQl6A/Fme5 sKPKs+GbXm912j3plzjhsgLdOxGRLo68PoPdVESn6Ykr0axfKMtLqdAp/9LowC0t WSdgn6rJXYDaUCT4u76PFjuJWR0u28q3BguisknR6eb0DMUiwmLPDiiwKiW0= X-Sasl-enc: 5NqeVB5qarB/WklkvJtg16leToiAjjGn5uBM0jWd3PBU 1446782803 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 743A2C016EE; Thu, 5 Nov 2015 23:06:43 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> <563B54D0.90602@network-heretics.com> From: Keith Moore Message-ID: <563C272F.6020000@network-heretics.com> Date: Thu, 5 Nov 2015 23:06:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 04:06:46 -0000 On 11/05/2015 02:55 PM, Andrew Newton wrote: > On Thu, Nov 5, 2015 at 10:08 PM, Keith Moore wrote: >> I'm not sure what "equal force" means. But I'm fairly confident that if we >> can define a small number of common resolution operations (things like "get >> URLs of locations of this resource and please return them in format X, or Y, >> or Z" and "get metadata of type FOO associated with this resource and return >> it in either format A or format B") that are potentially applicable to most >> URNs, we'll get more clients that are capable of doing things with URNs, >> than if we require a separate, specific operation like "getxmlschema" to be >> defined and implemented and deployed in resolution services for every >> different kind of request that someone or some client might need to make. > What specific changes are you asking for in 2141bis? As the IETF > saying goes, "send text". Otherwise I think this line of thought > should end here. So when people make handwaving arguments to the effect that there's no need to make sure that URNs can be resolved in a general fashion, those unsupportable arguments are apparently just fine. But when people try to discuss specifics of how it could be done, as a proof of concept, those arguments are out of order? I'm really getting tired of all of the efforts to cripple URNs. Keith From nobody Thu Nov 5 20:32:37 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952B61B34F9 for ; Thu, 5 Nov 2015 20:32:35 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us-f1vcSD_X4 for ; Thu, 5 Nov 2015 20:32:33 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A901B34F3 for ; Thu, 5 Nov 2015 20:32:33 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 6B7D22034D for ; Thu, 5 Nov 2015 23:32:32 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 05 Nov 2015 23:32:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=u5i9G5ErxVUTRn3g3omHKml697w=; b=kSE6Z MTra2qzmtNhrjTdPAgTbcddjUeeRH8H5Tx5huXScCr4EPgjCUrnQUZvEsvW1sujt lg6SSQj1W69e9ifoD2kXrGycRrIfVra7F/OTz6L8oX5k4kcKXwg6ZI7TojgBm1uU CzZwXQ/VZ9Gc9r+Z2CwWXHXMAMFDKhcfB4GvqM= X-Sasl-enc: mya9hBx3y7XjCgYVIAmEdpY8LCD10s/JqivdJtZxas58 1446784352 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id AEE9E680109; Thu, 5 Nov 2015 23:32:31 -0500 (EST) To: Andrew Newton References: <56394B60.3060102@network-heretics.com> From: Keith Moore Message-ID: <563C2D3A.2020207@network-heretics.com> Date: Thu, 5 Nov 2015 23:31:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010709050509090508000501" Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 04:32:35 -0000 This is a multi-part message in MIME format. --------------010709050509090508000501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/04/2015 03:04 PM, Andrew Newton wrote: > On Tue, Nov 3, 2015 at 7:03 PM, Keith Moore wrote: >> Assuming I understand you correctly, I disagree in the strongest possible >> terms. Extending URNs in such a way as to make development of generic URN >> handling tools infeasible would make URNs almost useless. > You have changed the terminology here. "generic URN handling tools" > and a generic URN resolver are not the same thing. The term you are > using does not necessarily include URN resolution. Note that I have > specifically said "resolver". > >> I don't believe >> that is an acceptable outcome of this working group. I also believe that >> any standards-track proposal with that likely result would grossly fail the >> "no known technical omissions" requirement of RFC 2026. > The complete sentence from 2026 is: "A Proposed Standard should have > no known technical omissions with respect to the requirements placed > upon it." (Also note that 2026 states that even this is not an > absolute). > > The very fact that it is necessary to have this discussion is proof > that a generic URN resolver is not a requirement that has been placed > upon this working group by the IESG or previous IETF consensus. No it is not. All that this discussion demonstrates is that some people are either misinformed about URNs, or think they can redefine URN requirements that were settled by consensus twenty years ago, without a broad consensus to do so. 1. RFC 1737 was a consensus output of the URI working group. 2. RFC 1737 defined requirements for URNs, among which were: o Resolution: A URN will not impede resolution (translation into a URL, q.v.). To be more specific, for URNs that have corresponding URLs, there must be some feasible mechanism to translate a URN to a URL. and o It is strongly recommended that there be a mapping between the names generated by each naming authority and URLs. At any specific time there will be zero or more URLs into which a particular URN can be mapped. The naming authority itself need not provide the mapping from URN to URL. 3. The URN working group that produced RFC 2141 was required to adhere to RFC 1737 as a condition of its charter. 4. Revisiting URN requirements is not within the scope of this working group according to its charter. In particular, that charter states: For all document revisions, backward compatibility with previous URN-related RFCs will be retained. > Even > if there were previous IETF consensus, the fact that the IETF has > ratified URNs that cannot resolve would show that the IETF consensus > changed. No it would not, because: a) There was never any requirement that every URN be resolvable (read the above requirements carefully, they do not go that far) b) IETF does not ratify "URNs" it only approves namespaces c) Even if IETF made a mistake in approving an URN namespace or two, that's not the same thing as revoking RFC 1737. > To my knowledge this working group is not bound by any requirement for > a generic URN resolver, and the acceptance or rejection of that > requirement is a matter this working group may choose. Strongly disagree. This working group is NOT chartered to redefine URNs, and RFC 1737 is part of the definition of URNs. > To the contrary, if your position is that a generic URN resolver is a > requirement and this working group puts forward a specification that > cannot resolve all URNs, that is a known technical omission. Different WG participants might assign different meanings to "generic URN resolver". But every time someone starts to explore what that might mean, some people insist that it can't be done (without providing any justification) and others insist that it's out of scope for the group. > It might be useful for you to define the specific operations upon ALL > URNs for which you believe a "generic URN handling tool" MUST be > capable. But you have clearly stated in other threads that you do not > believe resolution is one of them, as you have clearly noted that all > URNs are not resolvable. To me, "generic" doesn't mean it applies to all URNs. It means that any URN in any namespace can be made resolvable if its namespace is willing to advertise one or more resolution services for that namespace. It means that there's a standard framework for parsing URNs, interpreting r-components, discovering resolution services, querying resolution services, and interpreting results of those queries, such that at least the most common operations (basically I2L and I2C with negotiation for which kind of metadata) can be supported for any URN for which they make sense. Keith --------------010709050509090508000501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/04/2015 03:04 PM, Andrew Newton wrote:
On Tue, Nov 3, 2015 at 7:03 PM, Keith Moore <moore@network-heretics.com> wrote:

Assuming I understand you correctly, I disagree in the strongest possible
terms.  Extending URNs in such a way as to make development of generic URN
handling tools infeasible would make URNs almost useless.

You have changed the terminology here. "generic URN handling tools"
and a generic URN resolver are not the same thing. The term you are
using does not necessarily include URN resolution. Note that I have
specifically said "resolver".


I don't believe
that is an acceptable outcome of this working group.   I also believe that
any standards-track proposal with that likely result would grossly fail the
"no known technical omissions" requirement of RFC 2026.

The complete sentence from 2026 is: "A Proposed Standard should have
no known technical omissions with respect to the requirements placed
upon it." (Also note that 2026 states that even this is not an
absolute).

The very fact that it is necessary to have this discussion is proof
that a generic URN resolver is not a requirement that has been placed
upon this working group by the IESG or previous IETF consensus.

No it is not.   All that this discussion demonstrates is that some people are either misinformed about URNs, or think they can redefine URN requirements that were settled by consensus twenty years ago, without a broad consensus to do so.


1. RFC 1737 was a consensus output of the URI working group.


2. RFC 1737 defined requirements for URNs, among which were:

   o Resolution: A URN will not impede resolution (translation into a
     URL, q.v.). To be more specific, for URNs that have corresponding
     URLs, there must be some feasible mechanism to translate a URN to a
     URL.
and
   o It is strongly recommended that there be a mapping between the
     names generated by each naming authority and URLs.  At any specific
     time there will be zero or more URLs into which a particular URN
     can be mapped.  The naming authority itself need not provide the
     mapping from URN to URL.
3. The URN working group that produced RFC 2141 was required to adhere to RFC 1737 as a condition of its charter.

4. Revisiting URN requirements is not within the scope of this working group according to its charter.

In particular, that charter states:
  For all document revisions, backward compatibility with previous
  URN-related RFCs will be retained.
Even
if there were previous IETF consensus, the fact that the IETF has
ratified URNs that cannot resolve would show that the IETF consensus
changed.

No it would not, because:

a) There was never any requirement that every URN be resolvable (read the above requirements carefully, they do not go that far)
b) IETF does not ratify "URNs" it only approves namespaces
c) Even if IETF made a mistake in approving an URN namespace or two, that's not the same thing as revoking RFC 1737.   

To my knowledge this working group is not bound by any requirement for
a generic URN resolver, and the acceptance or rejection of that
requirement is a matter this working group may choose.

Strongly disagree.   This working group is NOT chartered to redefine URNs, and RFC 1737 is part of the definition of URNs.


To the contrary, if your position is that a generic URN resolver is a
requirement and this working group puts forward a specification that
cannot resolve all URNs, that is a known technical omission.

Different WG participants might assign different meanings to "generic URN resolver".   But every time someone starts to explore what that might mean, some people insist that it can't be done (without providing any justification) and others insist that it's out of scope for the group.   

It might be useful for you to define the specific operations upon ALL
URNs for which you believe a "generic URN handling tool" MUST be
capable. But you have clearly stated in other threads that you do not
believe resolution is one of them, as you have clearly noted that all
URNs are not resolvable.

To me, "generic" doesn't mean it applies to all URNs.  It means that any URN in any namespace can be made resolvable if its namespace is willing to advertise one or more resolution services for that namespace.   It means that there's a standard framework for parsing URNs, interpreting r-components, discovering resolution services, querying resolution services, and interpreting results of those queries, such that at least the most common operations (basically I2L and I2C with negotiation for which kind of metadata) can be supported for any URN for which they make sense.

Keith

--------------010709050509090508000501-- From nobody Thu Nov 5 20:32:59 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0CD1B34FC for ; Thu, 5 Nov 2015 20:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iicNfJIuoavU for ; Thu, 5 Nov 2015 20:32:57 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCF51B34F1 for ; Thu, 5 Nov 2015 20:32:57 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id CEB0D201B6 for ; Thu, 5 Nov 2015 23:32:56 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 05 Nov 2015 23:32:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sT2PTG4TKoODdsY O/iyJGv447kQ=; b=GwICD7eVjhunsfYKtMuuPkGs7wYFBvsBiHcdsdu3k7ZnOmu y3D3wrOTgxGrghulSzV0Om0OnH0a0JntMOnn58Ogg3+Cz50zeBoXsIg0mNONUXH8 sNAdPxTPiGv53Qvd+RWuy7PmOAoVJ7KGTZXCZpUS4qiYji89WQu+OBl8MXkg= X-Sasl-enc: 2FrXVSMNmciwW33HLFtlyFAuGlML3aliAlkLkn18mKUe 1446784376 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 5BDE26800E3; Thu, 5 Nov 2015 23:32:56 -0500 (EST) To: Andrew Newton References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> From: Keith Moore Message-ID: <563C2D54.5080602@network-heretics.com> Date: Thu, 5 Nov 2015 23:32:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 04:32:59 -0000 On 11/04/2015 03:10 PM, Andrew Newton wrote: > On Tue, Nov 3, 2015 at 7:21 PM, Keith Moore wrote: >> 2. an IANA registry of r-component facets, with namespaces strongly >> discouraged from defining facet names that appear to be generic but are >> actually namespace-specific > This seems like a fine idea for the working group to consider. But it > does not guarantee resolution of all URN namespaces, nor does it > guarantee resolution of all URN namespaces that can be resolved. I don't believe I ever claimed that it did. Nor do I understand that as a requirement. It was never a requirement that all namespaces be resolvable. (That's not even really a property of a namespace, since a namespace is potentially free to assign its names to any resources it wishes, whether or not they're resolvable.) It was never a requirement to guarantee resolution of all URN namespaces that can be resolved. (I don't even know what that means, since a namespace isn't resolvable anyway. Some URNs within a namespace might be resolvable, but that's not the same thing.) Basically 1737's requirements boil down to this: If a set of URNs are used to name network-accessible resources that can be accessed via one or more URLs, it should be possible to implement a mechanism for those URN to be resolved. (I'll infer a bit here: it clearly doesn't scale for every URN to have its own separate resolution mechanism that needs to be discovered - the implication is that there will be few enough such mechanisms for them to be widely implemented by clients.) But it does not require that the namespace provide such a mechanism for the names that it assigns. > An implementer cannot take the 2141bis RFC and be assured that whatever > new URN pops up in the future will be compatible with their URN > resolver. They must periodically check the IANA registry and add new > behavior to their software from time to time. I don't fundamentally disagree with that either. In particular, the set of protocols used to resolve URNs and the formats of metadata returned from resolution services will necessarily evolve over time, and that means that multiple protocols and formats will inevitably coexist. Implementations will need to be updated over time to accommodate new resolution protocols and metadata formats. As for checking the IANA registry, many widely-used applications routinely consult various kinds of internet databases (including but not limited to DNS) and we don't consider that unusual or a showstopper. Nor do we consider it infeasible to distribute database updates as part of software updates (for example, the Olson timezone database is widely distributed in this manner). Keith From nobody Thu Nov 5 20:43:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993C11B352F for ; Thu, 5 Nov 2015 20:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X387oJDUhAY7 for ; Thu, 5 Nov 2015 20:42:57 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56A21B352A for ; Thu, 5 Nov 2015 20:42:57 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1B24720234 for ; Thu, 5 Nov 2015 23:33:28 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 05 Nov 2015 23:33:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=fz2aU0FC8a5oSwT WI/+gNW7wCCM=; b=mz37qQxiFoibZXPpPvz4j/HI0DyXWnlL7hNqvP3zqX6zny8 ITcQO6IuVSmziY4EAYPtT7u89tgQQ9vk6I5cN+pVXx0XQchr1Obbl+vbB1loCWzX pwio20VmC79NKKI6KMQF+DvgQIMqOklC8jdpHf0/SDj2tsQ9Me/2A3KbCuZs= X-Sasl-enc: Ffo74ZDleGVAP/dMzPD4Yw9MEMfwotvzXRZ8XaCrcoHE 1446784407 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E652680092; Thu, 5 Nov 2015 23:33:27 -0500 (EST) To: John C Klensin , Andrew Newton References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> From: Keith Moore Message-ID: <563C2D72.2020708@network-heretics.com> Date: Thu, 5 Nov 2015 23:32:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 04:42:59 -0000 On 11/04/2015 03:21 PM, John C Klensin wrote: > > --On Wednesday, November 04, 2015 15:10 -0500 Andrew Newton > wrote: > >> On Tue, Nov 3, 2015 at 7:21 PM, Keith Moore >> wrote: >>> 2. an IANA registry of r-component facets, with namespaces >>> strongly discouraged from defining facet names that appear to >>> be generic but are actually namespace-specific >> This seems like a fine idea for the working group to consider. >> But it does not guarantee resolution of all URN namespaces, >> nor does it guarantee resolution of all URN namespaces that >> can be resolved. An implementer cannot take the 2141bis RFC >> and be assured that whatever new URN pops up in the future >> will be compatible with their URN resolver. They must >> periodically check the IANA registry and add new behavior to >> their software from time to time. > Andy, one addition to this. I'm not quite sure what a > "r-component facet" is, but the proposal that started us down > the path toward separation of q-components and r-components was > one to require that URN pairs and that a registry of those names be created to identify > ones with global (across-URN) meanings. The WG didn't like that > idea at all (in retrospect, for good reason). I didn't really like that idea either, partially because URL queries aren't required to conform to any syntax other than that specified by RFC 3986 or their individual URL scheme, and partially because trying to define a set of attribute names that won't conflict with any of the vast number of HTTP-accessible resources out there that have each been allowed to define their own sets of attribute names for over 20 years now, seems rather infeasible. Having a separate, distinguished syntax for resolver parameters addresses that problem. > It seems to me that going down the path toward the sort of > registry Keith suggests, one in which some "facet names" are > generic and in a registry and others are not, takes us back > around that loop again, even if it just applies to r-component > strings and not what we would consider today to be both > r-components and q-components. Fortunately no r-component facet names have been defined yet, so it's entirely feasible to reserve some space of r-component facet names for specific purposes, than it is to reserve some space of HTTP form attribute names for specific purposes at this late date. I don't see how it's significantly different from reserving IPv4 or IPv6 address prefixes for specific purposes. > In addition, in principle, we could simplify the spec somewhat > by (again) proposing and defining such global keywords and > eliminating the syntactic distinction between the two component > types. That wouldn't really simplify things, it would just add complexity and make it somebody else's (bigger) problem. (Of course, if the only goal were really to simplify things, we would just unplug all of our computers and dismantle the Internet. Yes, it would be simpler in some sense if we never built any resolution services or clients that could use them. It's only because some of us believe that having resolvable long-term stable names would provide a benefit that's more than worth the cost and complexity that we're pursuing this effort.) > I mention that, not to restart the separation argument > but to suggest it illustrates why a design conditioned on such a > registry -- one that I think essentially requires an implementer > to predict what facet names will be registering the future as a > condition for predictable operation -- is a non-starter. I agree that requiring an implementer to predict what facet names will be registered in the future is a non-starter. I would instead propose that all facet names require registration before use, and/or that there be a reserved space of facet names specifically for private use by namespaces. (and perhaps others for private use by specific resolution protocols, or specific resolution service providers) Again, this is really no different than several other attribute namespaces that we've been using for years. Implementors of email user agents don't have to be able to predict every header field name that will exist in the future either. Keith From nobody Thu Nov 5 23:28:02 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320DE1B3521 for ; Thu, 5 Nov 2015 23:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bvT49s2TLk0 for ; Thu, 5 Nov 2015 23:27:57 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D761B34F5 for ; Thu, 5 Nov 2015 23:27:55 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.318.15; Fri, 6 Nov 2015 07:27:35 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0312.014; Fri, 6 Nov 2015 07:27:34 +0000 From: "Hakala, Juha E" To: Keith Moore , Andrew Newton Thread-Topic: [urn] generic/universal URN resolver Thread-Index: AQHRFd5wsgZsRj8t6k2TFGcYOu/a/J6JpqQAgAFbC4CAAUxhgIACHnIAgAAmb/A= Date: Fri, 6 Nov 2015 07:27:34 +0000 Message-ID: References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> <563C2D54.5080602@network-heretics.com> In-Reply-To: <563C2D54.5080602@network-heretics.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 5:O4QrXQ6Qi+j7zjbDkOVw6dravHgiPj+mg4mB3EXLvXC725Xq/FXFhSx9ruyXB3GyE5ieL4G+aJTZQLlnGtwpU0MVd2An9kNeqidRwXFDqmys9UQbd53gRjVIKClG9qS1ubHSAjIKEamIUbAYj1iMVw==; 24:Dswn8x/bAGvRPpJxErBAE8pFDBYDGQNFJ39/m+N3Tmfw11GPppgG++l6faUd/TMFMBv2j+w7H2ew9YZjsDUV72vMK2cH0/h66jiDh9rQjPc=; 20:TwKE7K7pbhW/Wzp3w9wzFdPXo7ZC0cxkZOW+0fM5q8UKE1tTF/JvBF7QT94KS6K2oUxw8fPKiwXDQsLr1Y9NVg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 07521929C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(479174004)(13464003)(199003)(377454003)(5004730100002)(40100003)(5003600100002)(92566002)(189998001)(74482002)(10400500002)(77096005)(33656002)(2900100001)(5001770100001)(97736004)(74316001)(2950100001)(102836002)(87936001)(5008740100001)(15975445007)(106116001)(19580405001)(106356001)(81156007)(19580395003)(5001960100002)(105586002)(5002640100001)(101416001)(86362001)(93886004)(5007970100001)(50986999)(122556002)(66066001)(54356999)(76576001)(76176999)(41533002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2015 07:27:34.3359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 07:28:01 -0000 Hello,=20 some comments below.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Keith Moore > Sent: 6. marraskuuta 2015 6:32 > To: Andrew Newton > Cc: urn@ietf.org > Subject: Re: [urn] generic/universal URN resolver >=20 > On 11/04/2015 03:10 PM, Andrew Newton wrote: > > On Tue, Nov 3, 2015 at 7:21 PM, Keith Moore heretics.com> wrote: > >> 2. an IANA registry of r-component facets, with namespaces strongly > >> discouraged from defining facet names that appear to be generic but > >> are actually namespace-specific > > This seems like a fine idea for the working group to consider. But it > > does not guarantee resolution of all URN namespaces, nor does it > > guarantee resolution of all URN namespaces that can be resolved. >=20 > I don't believe I ever claimed that it did. Nor do I understand that > as a requirement. >=20 > It was never a requirement that all namespaces be resolvable. (That's not= even > really a property of a namespace, since a namespace is potentially free t= o > assign its names to any resources it wishes, whether or not they're resol= vable.) There are already two kinds of namespaces: ones which may be resolvable, an= d ones which a priori are not.=20 We have agreed a long time ago that it is not a requirement that URNs must = be resolvable. This applies to namespaces of the second type. Suppose someo= ne registers a namespace for non-semantic ("dumb") identifier. The identifi= er itself contains no hint as regards where it can be resolved. If there is= no centralized service to which all resolution requests can be directed, t= hen these URNs are not really resolvable. In practice: all ISSNs can only be resolved in the global ISSN database (or= its mirror sites). If that databases is closed down, there is no single da= tabase out there that would cover all assigned ISSNs. Some services like OC= LC's WorldCat would get close, but service would still be only partial. =20 Of course, the best ISSN database and other bibliographic databases can do = with ISSN resolution for now is to provide metadata about periodicals. If t= he URLs in metadata records are out of date, a user cannot find the periodi= cal, so resolution may not provide useful results.=20 And then there is urn:uuid namespace where, as far as I have understood cor= rectly, it was never even an intention to provide resolution services.=20 =20 > It was never a requirement to guarantee resolution of all URN namespaces = that > can be resolved. (I don't even know what that means, since a > namespace isn't resolvable anyway. Some URNs within a namespace might > be resolvable, but that's not the same thing.) IMO this WG does not need to discuss URN resolution after the basic decisio= n we have taken years ago: one can register a namespace even if the URNs in= it are not even intended to be resolvable. > Basically 1737's requirements boil down to this: If a set of URNs are us= ed to > name network-accessible resources that can be accessed via one or more UR= Ls, > it should be possible to implement a mechanism for those > URN to be resolved. (I'll infer a bit here: it clearly doesn't scale > for every URN to have its own separate resolution mechanism that needs to= be > discovered - the implication is that there will be few enough such mechan= isms > for them to be widely implemented by clients.) My personal opinion is that URNs which are a priori not actionable are not = very useful. But there may be some specific circumstances in which they mak= e sense, so therefore I did not insist on resolvability at least in theory.= =20 > But it does not require that the namespace provide such a mechanism for t= he > names that it assigns. >=20 > > An implementer cannot take the 2141bis RFC and be assured that > > whatever new URN pops up in the future will be compatible with their > > URN resolver. They must periodically check the IANA registry and add > > new behavior to their software from time to time. Not every URN resolver will deal with every URN namespace. It is possible t= o build a hierarchical network of resolvers in which URN - URL mapping tabl= es and other information about resolution is harvested to central resolvers= which may then be able to deal with a larger number of URNs in certain nam= espaces and larger set of namespaces as well. But there are no plans to har= vest all resolution information into a single system. And this would of cou= rse be a challenge for r-component based functionality which requires the r= esolvers to do something special. If and when new r-component based functionality becomes available in one na= mespace, only resolvers which deal with URNs from that namespace need to do= something. Resolvers which harvest mapping tables from native resolvers ma= y omit URNs with r-component service parameters they do not know how to dea= l with, or harvest that data but pass any resolution requests to the resolv= er which "knows" what to do.=20 For now, much of this functionality is missing from resolvers. And in my op= inion it is not the task of this WG to deal with it, at least not now. The = plan has to been to specify the syntax details of the r-component later, an= d after that we can start developing smart resolvers. That development coul= d have started ages ago if URN syntax revision had been finished on schedul= e.=20 =20 > I don't fundamentally disagree with that either. In particular, the > set of protocols used to resolve URNs and the formats of metadata returne= d > from resolution services will necessarily evolve over time, and that mean= s that > multiple protocols and formats will inevitably > coexist. Implementations will need to be updated over time to > accommodate new resolution protocols and metadata formats. Yes. Technical infrastructure libraries etc. are using to manage digital do= cuments is developing fast, and we need persistent identifiers which can ad= apt to this changing environment. It must be easy to specify new resolution= services and service related parameters. Some of these services may be nam= espace specific at least to start with, but others, such as mapping of URNs= to 1-n URLs will be generic.=20 R- and q-components will play a major role in the process of making the res= olvers smarter. If the only service resolvers can provide is to map URN and= other PIDs to URLs, linked data will be much less linked and useful than i= t needs to be.=20 Juha=20 > As for checking the IANA registry, many widely-used applications routinel= y > consult various kinds of internet databases (including but not > limited to DNS) and we don't consider that unusual or a showstopper. > Nor do we consider it infeasible to distribute database updates as part o= f > software updates (for example, the Olson timezone database is widely > distributed in this manner). >=20 > Keith >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri Nov 6 00:30:33 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3086A1A21BD for ; Fri, 6 Nov 2015 00:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaViaiWH2te8 for ; Fri, 6 Nov 2015 00:30:28 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA741A21A7 for ; Fri, 6 Nov 2015 00:30:28 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.318.15; Fri, 6 Nov 2015 08:30:21 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0312.014; Fri, 6 Nov 2015 08:30:21 +0000 From: "Hakala, Juha E" To: Keith Moore , "urn@ietf.org" Thread-Topic: [urn] -14 Thread-Index: AQHRFP67YdFsPsZSqEeCl7k9u5AkLp6H1eyAgAA5oACAAALzgIAAA2AAgACUQACAAAvuAIAAKMgAgAB73gCAAaG3AIAB5HAAgACLTACAAHGTAIAAiTWAgABFf/A= Date: Fri, 6 Nov 2015 08:30:21 +0000 Message-ID: References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> <563B54D0.90602@network-heretics.com> <563C272F.6020000@network-heretics.com> In-Reply-To: <563C272F.6020000@network-heretics.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.173.46] x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 5:amT36/faIoTbYRsesFh3I2pgRrmMlQOOVWUUWy9jJiZ8e+FkvkgagsXMA8XzyYMEOSH/au+PCwTvkAYx6c5WocQkz212VMCfn93Ky/w6BR9vrSNspGh4HpLn9Nav6y2BpnN2TueDiBI0MhVzzFl8/w==; 24:yqoz99P7h4Z2IOMnD7x/N+t3Kt98T2r1NZic95xaZDvt6VP0odQy/GT4zeH53Hmh9rtX5dEq1tuJAc4QGNRyeG5FpVNZYaTTR4RDOjWifTk=; 20:wospk4kASwnVmb6w7khVSIGj6K4KdacidJORIRH2fz/yh7/J2d+5bwhaPDomqqDv+221sVoQwCBBhCQz0uszoQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 07521929C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(479174004)(13464003)(377454003)(24454002)(189002)(19580395003)(5001960100002)(81156007)(5002640100001)(105586002)(2501003)(106116001)(19580405001)(106356001)(76176999)(54356999)(76576001)(101416001)(86362001)(93886004)(5007970100001)(50986999)(66066001)(122556002)(10400500002)(189998001)(74482002)(5001920100001)(77096005)(5003600100002)(5004730100002)(107886002)(40100003)(92566002)(11100500001)(74316001)(87936001)(102836002)(15975445007)(5008740100001)(2950100001)(2900100001)(33656002)(5001770100001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2015 08:30:21.4089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 08:30:32 -0000 Hello,=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Keith Moore > Sent: 6. marraskuuta 2015 6:06 > To: urn@ietf.org > Subject: Re: [urn] -14 >=20 > On 11/05/2015 02:55 PM, Andrew Newton wrote: > > On Thu, Nov 5, 2015 at 10:08 PM, Keith Moore heretics.com> wrote: > >> I'm not sure what "equal force" means. But I'm fairly confident that= if we > >> can define a small number of common resolution operations (things > >> like "get URLs of locations of this resource and please return them > >> in format X, or Y, or Z" and "get metadata of type FOO associated > >> with this resource and return it in either format A or format B") > >> that are potentially applicable to most URNs, we'll get more clients > >> that are capable of doing things with URNs, than if we require a > >> separate, specific operation like "getxmlschema" to be defined and > >> implemented and deployed in resolution services for every different ki= nd of > request that someone or some client might need to make. Defining URN resolution services and r-component syntax related to them wil= l be done once we have agreed that r-component can be used. I have voluntee= red to participate in this work to make sure that services and service para= meters specified will match the real requirements of libraries, archives an= d museums.=20 An obvious starting point is to specify r-component syntax for services spe= cified in RFC 2483. Some of these services must be parametrized; for instan= ce, if metadata about resource is wanted, it is usually also necessary to s= pecify the format (Dublin Core, MARC 21, ONIX and so on). It may also be ne= cessary to specify the type of metadata required (rights metadata, technica= l metadata, descriptive metadata, and so on).=20 There are services which are already possible with the current generation o= f digital asset management systems, but which are not included in RFC 2483.= And once new services emerge, it must be possible to add them. So the firs= t priority is to create mechanism with which the list of services and their= syntax specifications will be maintained.=20 > > What specific changes are you asking for in 2141bis? As the IETF > > saying goes, "send text". Otherwise I think this line of thought > > should end here. >=20 > So when people make handwaving arguments to the effect that there's no ne= ed > to make sure that URNs can be resolved in a general fashion, those > unsupportable arguments are apparently just fine. But when people try > to discuss specifics of how it could be done, as a proof of concept, thos= e > arguments are out of order? >=20 > I'm really getting tired of all of the efforts to cripple URNs. As far as I am concerned, the details of r-component syntax should be dealt= with after 2141bis has been completed. Adding the task of r-component spec= ification to the agenda might delay us further by several months in the wor= st case. And there is definitely no urgent need to specify the details of r= -component now.=20 As regards q-component, we do not need to do anything, since q-components w= ill be something that target systems will be able to deal with, based on (h= opefully) some standards. So SRU protocol can be used to retrieve metadata = from target systems, and other protocols for retrieving the documents thems= elves. 2141bis does not need to be aware of these protocols; we only need t= o specify q-component as a place within which to put the string that does t= he trick required.=20 Juha=20 >=20 > Keith >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri Nov 6 01:13:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC461B3145 for ; Fri, 6 Nov 2015 01:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf5etZ91iRgx for ; Fri, 6 Nov 2015 01:13:32 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1BB1B32F0 for ; Fri, 6 Nov 2015 01:13:31 -0800 (PST) Received: by pacdm15 with SMTP id dm15so93032128pac.3 for ; Fri, 06 Nov 2015 01:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=HGdRiq1G2hXLIg/uIUqPEGeUREs+xAI3vDDqZ5SP/Ug=; b=O9oY9jmxuZxLXon2JnzXJhVHS7va1WuLjr4Kny0yquR/GHl+nvz8HYcpz14R3tUhwp QJgWGhcYDnxbaDG4TsM8yJ0aCSrFLN6UdU2b0kF6yNmgCxKrFa4XGEC+b8xJZGlQkhAH 6A7wItlLHIRqDkKJ1lXza7sa+qmZ99MRmnD0ng6tcNwOQTZx5cw+OkKZALKxRAoIkHXl D9cg1eC56Xz5gI2HOSHyEs4QwRpPMh+VwUgTlqI8ZQ4n/pXHCocIe/Tl04nMysb8MoaP vchRnDKp1x2vm2aBPcXGblcMu/Sn4S6e08vWLhI77qADZ7PqU/3upJ0HIdt5NOIRRflD K02g== X-Received: by 10.67.1.103 with SMTP id bf7mr15719836pad.147.1446801211339; Fri, 06 Nov 2015 01:13:31 -0800 (PST) Received: from [10.71.3.122] ([101.110.53.38]) by smtp.gmail.com with ESMTPSA id f3sm12695572pas.36.2015.11.06.01.13.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Nov 2015 01:13:30 -0800 (PST) To: "urn@ietf.org" From: Melinda Shore Message-ID: <563C6F38.4070801@gmail.com> Date: Fri, 6 Nov 2015 18:13:28 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Stepping down X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 09:13:33 -0000 By way of an update, yesterday I let Barry and Andy know that I'm stepping down as urnbis co-chair. Thank you very much for the work you've done moving the document along and for your efforts to find common ground. I've certainly learned a lot over the past year. Wishing you all the best, Melinda From nobody Fri Nov 6 01:55:01 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A7C1B3835 for ; Fri, 6 Nov 2015 01:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1MKsvfDKvx0 for ; Fri, 6 Nov 2015 01:54:57 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE791B3829 for ; Fri, 6 Nov 2015 01:54:56 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZudjR-0000c4-Hr; Fri, 06 Nov 2015 04:54:53 -0500 Date: Fri, 06 Nov 2015 04:54:48 -0500 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <563C272F.6020000@network-heretics.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> <563B54D0.90602@network-heretics.com> <563C272F.6020000@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 09:55:00 -0000 --On Thursday, November 05, 2015 23:06 -0500 Keith Moore wrote: >... > I'm really getting tired of all of the efforts to cripple URNs. Keith, Independent of the virtues of your substantive positions, I think the above is a severe mischaracterization. As far as I can tell, no one who has been active on this list in recent months is trying to cripple URNs. What we are trying to do is to find a way to write a URN standard that is (i) consistent with known existing uses and plausible future ones that are not completely off the wall and (ii) that can be finished somewhat in advance of the heat death of the universe and preferably within a small number of months. To at least some of us, what we are looking for more nearly resembles "expand the range and functionality to at least match reality" than it does "cripple" At least for me, the means getting very pragmatic rather than, e.g., theorizing about what we might do if it had infinite time and a clean slate. I see the alternative as ending up with no IETF standard to which most actors don't bother to pay attention and either no other standard or a collection of different ones, from different bodies that have different interests and priorities, and that are not consistent or compatible. I don't think we have unlimited time; I'm surprised we haven't run out of time already. Again for me, that means approaching every new (or repeated) idea and proposal with questions like: (i) Is this really critical path? If it is not, can we put it aside (even if only temporarily) and focus on things we actually need to do to get the present set of documents completed and published? (ii) It is likely that this particular idea can be documented and consensus reached in a reasonable amount of it (where "reasonable" includes recognizing that we are already years overdue on the core work)? If not, can we postpone it or set it aside until the base documents, with no normative forward references or statements that would discourage use without the new features, can be completed? (iii) Closely related to be above, is the idea sufficiently clear and specific to be actionable or is it merely a statement of vague principles? If the latter, is it safe to ignore it and, if not, why not. You may not agree with that way of looking at things, but it is motivated by a focus on getting finished, not on an effort to "cripple". There is another important aspect of URNs that I think we should keep in mind. While there are certainly important exceptions, one of them brought about by the idea that one can embed any URI in an HTML "aref", in many, perhaps most, application situations, the application developer is perfectly aware of the range of URNs (with or without other URI types) that are likely to be relevant. For that range, it is entirely reasonable to assume that the application will have knowledge of whether resolution is needed and a resolver, resolution-database or dispatcher, or a set of per-namespace resolvers, readily available. In that situation, a "universal" mechanism is needed only for the namespaces that are relevant. Other kinds of namespaces and their resolution mechanisms are either not relevant or are an attack vector. I don't have time to try to explore all of those details and suspect the WG doesn't either. But, just as I don't think the recent discussions can be reasonably characterized as trying to cripple URNs, I don't think "can't figure out how to either find an authoritative resolver or authoritatively determine that one is not needed" is really a showstopper for the effort to define URNs that are extended enough beyond 2141 to match today's realities. best, john From nobody Fri Nov 6 05:11:34 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1D1A893C for ; Fri, 6 Nov 2015 05:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFGZGCVk8mnp for ; Fri, 6 Nov 2015 05:11:31 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E091A892A for ; Fri, 6 Nov 2015 05:11:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6194D20629 for ; Fri, 6 Nov 2015 08:11:30 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 06 Nov 2015 08:11:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=aCW0cnyDlzHaJmv js7p48u3XviI=; b=b6qPISvoE9kItaj76UaKzy7Ra35LCjWoGAS+TUmWnUtp0Qd mA6tjDwnjeQpFKLl3WzYuL3UUa6Qk2a9mT0f1SQFJyRbBpN15S4P4M0pZjkTg6qt ZcaWENsROhYDpDCaAPnkJdcw6UBmgP1BWqToX4aHj6p116lEgQOmnY72/XU8= X-Sasl-enc: FHKxMLjHh6tDfxn9jnto5p7ikSJzpGwYidCdNmjUIUEU 1446815490 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id DB769C016EE; Fri, 6 Nov 2015 08:11:29 -0500 (EST) To: "Hakala, Juha E" , Andrew Newton References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> <563C2D54.5080602@network-heretics.com> From: Keith Moore Message-ID: <563CA700.2060208@network-heretics.com> Date: Fri, 6 Nov 2015 08:11:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 13:11:33 -0000 On 11/06/2015 02:27 AM, Hakala, Juha E wrote: > Hello, > > some comments below. > >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Keith Moore >> Sent: 6. marraskuuta 2015 6:32 >> To: Andrew Newton >> Cc: urn@ietf.org >> Subject: Re: [urn] generic/universal URN resolver >> >> On 11/04/2015 03:10 PM, Andrew Newton wrote: >>> On Tue, Nov 3, 2015 at 7:21 PM, Keith Moore > heretics.com> wrote: >>>> 2. an IANA registry of r-component facets, with namespaces strongly >>>> discouraged from defining facet names that appear to be generic but >>>> are actually namespace-specific >>> This seems like a fine idea for the working group to consider. But it >>> does not guarantee resolution of all URN namespaces, nor does it >>> guarantee resolution of all URN namespaces that can be resolved. >> I don't believe I ever claimed that it did. Nor do I understand that >> as a requirement. >> >> It was never a requirement that all namespaces be resolvable. (That's not even >> really a property of a namespace, since a namespace is potentially free to >> assign its names to any resources it wishes, whether or not they're resolvable.) > There are already two kinds of namespaces: ones which may be resolvable, and ones which a priori are not. While I think we're in substantial agreement, I'm going to be a bit picky here, because very slight differences in wording, or in interpretations of the wording, can mean very different things in this discussion. As I said above, I don't believe that this is inherently a property of a namespace, because a namespace can at any time choose to start assigning names according to different criteria than it has used in the past. However, I agree that for any URN that is purely a unique string, one that isn't bound to anything at all, resolution (even if it were to to be implemented) would be a fairly meaningless operation. The most that the resolution service could reasonably return is "this name isn't bound to anything". (I do believe this would be useful, as this is a better result than simply "no information can be found".) It occurs to me that a registry that advertises resolution services on a per-namespace basis could be designed in such a way as to allow a namespace to advertise that it has never assigned a URN to any resource - all of the URNs it has generated were merely for the purpose of being unique strings - and this would allow a resolution API to return the result "this URN isn't bound to anything". And we could make entries in that registry for any URN namespaces (e.g. uuid) that are inherently nothing more than unique strings, and don't have an organization to make the entry on their behalf. I also agree that for URNs that are bound to things that inherently aren't accessible over the network, resolution is limited to metadata. I also agree that unless a namespace advertises one or more resolution services for that namespace, there will be no _authoritative_ resolution of the URNs from that namespace. > We have agreed a long time ago that it is not a requirement that URNs must be resolvable. And it was agreed 20 years ago that URNs must not impede resolution. But if you mean that "it is not a requirement to be able to resolve all URNs", I agree with that. > This applies to namespaces of the second type. Suppose someone registers a namespace for non-semantic ("dumb") identifier. The identifier itself contains no hint as regards where it can be resolved. If there is no centralized service to which all resolution requests can be directed, then these URNs are not really resolvable. Mostly agree, though see above. > In practice: all ISSNs can only be resolved in the global ISSN database (or its mirror sites). If that databases is closed down, there is no single database out there that would cover all assigned ISSNs. Some services like OCLC's WorldCat would get close, but service would still be only partial. > > Of course, the best ISSN database and other bibliographic databases can do with ISSN resolution for now is to provide metadata about periodicals. If the URLs in metadata records are out of date, a user cannot find the periodical, so resolution may not provide useful results. Agree with all of the above. Though even when there is a resolution service advertised by a namespace as being authoritative, there should be no requirement that the service provide complete coverage of all of the URNs which it has assigned. > > And then there is urn:uuid namespace where, as far as I have understood correctly, it was never even an intention to provide resolution services. > >> It was never a requirement to guarantee resolution of all URN namespaces that >> can be resolved. (I don't even know what that means, since a >> namespace isn't resolvable anyway. Some URNs within a namespace might >> be resolvable, but that's not the same thing.) > IMO this WG does not need to discuss URN resolution after the basic decision we have taken years ago: one can register a namespace even if the URNs in it are not even intended to be resolvable. I'm not sure how to parse that sentence. But I think we do need to discuss resolution at least to the extent that if some language in the 2141bis draft impedes resolution, we need to be able to explain why this is the case and thus why that language needs to be altered or removed. (And when people make statements to the effect that generic resolution is impossible, as a justification for putting language in 2141bis that impede resolution, it becomes necessary to explain what is really meant by generic resolution, and/or to demonstrate that it is possible.) > >> I don't fundamentally disagree with that either. In particular, the >> set of protocols used to resolve URNs and the formats of metadata returned >> from resolution services will necessarily evolve over time, and that means that >> multiple protocols and formats will inevitably >> coexist. Implementations will need to be updated over time to >> accommodate new resolution protocols and metadata formats. > Yes. Technical infrastructure libraries etc. are using to manage digital documents is developing fast, and we need persistent identifiers which can adapt to this changing environment. It must be easy to specify new resolution services and service related parameters. Some of these services may be namespace specific at least to start with, but others, such as mapping of URNs to 1-n URLs will be generic. > > R- and q-components will play a major role in the process of making the resolvers smarter. If the only service resolvers can provide is to map URN and other PIDs to URLs, linked data will be much less linked and useful than it needs to be. I am still insisting that q-components should not be passed to resolvers, as they are entirely for consumption by the resource itself. This is an important separation of function. I don't understand why people claim that they should be passed to resolvers. Keith From nobody Fri Nov 6 13:21:39 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE7A1A01C6 for ; Fri, 6 Nov 2015 13:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vahWYkVvqSA for ; Fri, 6 Nov 2015 13:21:36 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEC41A00E9 for ; Fri, 6 Nov 2015 13:21:36 -0800 (PST) Received: by wmll128 with SMTP id l128so51215259wml.0 for ; Fri, 06 Nov 2015 13:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CutyJmJcx9h4i74wLutlDGRaknmNixPk6nsKn9LIK/M=; b=DaaNWIx5s5FotbkrrzjGbMQOyMLOEFPZ/8G1X0jq/6+ndhLKdZeTSWmzGijaL4tlUl MI3EIkUla0jtVamv66JVzlGGsgd12Hz004bTtvGaw7QGgCNFlV0V6tBTveJ3jQ0pNqaG OnDFcnuovn3q07qQ7OjofSTCMRb8ynyfqa9I2L4VaCziIPJBxtn0PZH5w4BfJuKpDjyD Lw45AUxWVIsihkd66FG2hiUrK5f9xt2ajxRWPJ4LCgctZJGundMlZn3XWr4b2nPSBKHM IZAKXMtQcyeWxcGBqvqVx/TprnKQJfr9KpfOHR5dQykZHt900ftfUIRaMIKKKSE5UoMw X2zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CutyJmJcx9h4i74wLutlDGRaknmNixPk6nsKn9LIK/M=; b=JBdxqXxAWLwjAN7tlwgRfG1kUvAf9u6oIgX23qlUgTUiRAEx7ICavNhaw9SMl8ObpV SENuF3jDkGgfHZJoU3XJpKwg04Ui5prp5kPcqewKKXbgFUWO9xdx31xQZTeFzDsZNB6s Xju2rrtzrcDZ0ithUn+3GBWv2/Y1BwqJyrvqMSd7B19XGJM4ei050yIq2NUN1bubdnrm E+kStyGecq0kotaW9P025oLjac56wV6uyjdrufDoBH2BnIZk65QYUX69kHqsTToA/7J6 pDA5HHC7GgzS5z+3j5sqvs8nW10ElBm7/1VyLG7A2u0PeI652IPZ4FxG/ebMJQfyPfas ITpQ== X-Gm-Message-State: ALoCoQlckC5K44QJMf7gyGJ+jTTLxGxxkYwpDIYIioB7tMqxEWgM69r+KSwadEM3X4BLNCKoK8FH MIME-Version: 1.0 X-Received: by 10.28.130.12 with SMTP id e12mr12951806wmd.76.1446844894702; Fri, 06 Nov 2015 13:21:34 -0800 (PST) Received: by 10.194.91.134 with HTTP; Fri, 6 Nov 2015 13:21:34 -0800 (PST) X-Originating-IP: [101.110.53.38] In-Reply-To: <563C2D3A.2020207@network-heretics.com> References: <56394B60.3060102@network-heretics.com> <563C2D3A.2020207@network-heretics.com> Date: Sat, 7 Nov 2015 06:21:34 +0900 Message-ID: From: Andrew Newton To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 21:21:37 -0000 There are differences in the two things we are talking about. I am asking about the requirement of one single piece of software to resolve all URNs. You are stating that all URNs must have a definable resolution process if they are in a namespace that has resolution. If you are claiming that we are creating a situation in which some URNs will not have a definable resolution process (if they are meant to be resolved), then I'd appreciate if you would point out the specific aspects that cause this. On Fri, Nov 6, 2015 at 1:31 PM, Keith Moore wrote: > To me, "generic" doesn't mean it applies to all URNs. It means that any URN > in any namespace can be made resolvable if its namespace is willing to > advertise one or more resolution services for that namespace. It means > that there's a standard framework for parsing URNs, interpreting > r-components, discovering resolution services, querying resolution services, > and interpreting results of those queries, such that at least the most > common operations (basically I2L and I2C with negotiation for which kind of > metadata) can be supported for any URN for which they make sense. You lost me at interpreting r-components. Are you suggesting that your proposed IANA protocol registry require IETF standards action to have an entry added to it? -andy From nobody Fri Nov 6 13:27:42 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1AD1A03A6 for ; Fri, 6 Nov 2015 13:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D10XNLuFMgpk for ; Fri, 6 Nov 2015 13:27:39 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411CD1A039D for ; Fri, 6 Nov 2015 13:27:39 -0800 (PST) Received: by wmec201 with SMTP id c201so28112914wme.1 for ; Fri, 06 Nov 2015 13:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BMK32Rdm//SeKhS3Fr0fATPkJ63rOS4Ny837uxT+2Zk=; b=yAJ+0+VLXilmJqnltE09iQr3TBroK41kYquwArkTGGXkWj4dQShErtq5EPGLBU4MZI Ys8HKlvR0QUKESbI/8CFsaLpCwhhiqR1qZ962dzfcJ5uUkRoBO60Yeczs6MddPQ9ejHu mDiDF1xY4Eaa3mPvMVY2Znt926BqvK8eGDmrI2gOJFS4GaFd8scUzncFpDHfW/m2k/0d zpSFCOw/FrzcL0NCcVeZ+3ZGVmEf6Mh/V6r4tKdcooLCC28PwxjA0k7sLoDXjty7tTf7 oYO5vUESOPIt1J4RmoBboiP9aqq+gOzjfJp7yQdENqiJfRLFNccbnhl79IfKXs1xp9Of 1YBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BMK32Rdm//SeKhS3Fr0fATPkJ63rOS4Ny837uxT+2Zk=; b=CLtlJnanVNjl+4BlteiHDhLAntHGqSERbHZ752HEbx1o5P58x8GnKLinVdSaC4IZJT ONilOLWRIU1rYC2tY75NpTsvwWsSyR8ZKtitS1Ajgu39g3EQgDH8guzX+z/CcqalGCoJ cMmpAFZQobc9f9ZLc4PjXa5N1pHn2STWfEPMGStvKSgL3bSHGmhjywYJGLSpvabOZkYM S+HwXLgEzA48yOMsPVYtNFF4ggGtFf2mrMoDPMCbcso/pVLcPSNP6/BHmOrusbhQb+Uh TOmWKfdjbopO3V+9YW7lU5gTjuVtatVw+WddnidXxoPMaMUXLOrtrF3wXdQNmMv5xYmN o/MQ== X-Gm-Message-State: ALoCoQmxfEihs8BPifmX9CO69JSumvdWo1N94XDCYsG0el2xdRKAonxQOf1jzItsYlZx9J+Mi3ba MIME-Version: 1.0 X-Received: by 10.28.229.212 with SMTP id c203mr11700275wmh.11.1446845257899; Fri, 06 Nov 2015 13:27:37 -0800 (PST) Received: by 10.194.91.134 with HTTP; Fri, 6 Nov 2015 13:27:37 -0800 (PST) X-Originating-IP: [101.110.53.38] In-Reply-To: <563C2D72.2020708@network-heretics.com> References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> <563C2D72.2020708@network-heretics.com> Date: Sat, 7 Nov 2015 06:27:37 +0900 Message-ID: From: Andrew Newton To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 21:27:41 -0000 On Fri, Nov 6, 2015 at 1:32 PM, Keith Moore wrote: > Fortunately no r-component facet names have been defined yet, so it's > entirely feasible to reserve some space of r-component facet names for > specific purposes, than it is to reserve some space of HTTP form attribute > names for specific purposes at this late date. I don't see how it's > significantly different from reserving IPv4 or IPv6 address prefixes for > specific purposes. You really need to be much more specific about what a facet name is. At this moment we can only take wild guesses about how you intend r-components to be used and structured, how you intend the IANA registry to be operated, etc... And asking the document authors to add massive amounts of text on a hunch they might get it right is unfair to them. So if you want this, "send text". -andy From nobody Fri Nov 6 13:32:38 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA2B1A1A8C for ; Fri, 6 Nov 2015 13:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SOtPJ4pyUwN for ; Fri, 6 Nov 2015 13:32:36 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1CA1A1A77 for ; Fri, 6 Nov 2015 13:32:36 -0800 (PST) Received: by wmll128 with SMTP id l128so44073000wml.0 for ; Fri, 06 Nov 2015 13:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LAWHZu00u8sUc17Kz/Jz5EW+5HGL/2MnhWj9Y7+Om+c=; b=2M/IAWKzIyGCuhqKdF+wmLTkUjwvPA1Xar3UXL+nFR5Lcfardh6yBApHCuGgzSYNQI P6sRIr8V4fJ0OA/vMOfYz5d+Bbdfxt+amt1t2ZTnBzgpvEhWdF9S9tKXCkTAAKRBTND2 LwnV9AhHGp83+nOHqejx3/xfbXHM6MXZA/BxXcyxC7U1c80YvIod+fIvOSDNmFC3ijXN 5x7gsMXnDd892X5v/S1qw/DnHkv1vBO/MyZKBM0xd4CeXwm84JwNnG4H6AqnKPvaBzyw QZNI/jkY3L6UqsHFfKtigPx+R26qYyd1x9XJeI7Py4zxdJWbDI02dWgE+/t0IAuI+PE2 GOFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LAWHZu00u8sUc17Kz/Jz5EW+5HGL/2MnhWj9Y7+Om+c=; b=YIq0e4m7hmDVd3XNQJ5A4tPiY4hV5Ne5Y4MNAdVAyoJ/iMsdiW0P3tvntYHhOu9bb/ 1tNT6d9/EuMgdNwKGFQGawPj4BeZaUUIzQv0SFoK3xMaq7ANFRfFfvxvCnE43YbTzGex OmlYV/hegrYWzejyaXNw7QmEIzp2f59zO4XiX4hCMZarhfGKthNVta0iIjjYQd9lUrl1 CcIvCVJomJy2Ob180Q2DtOsNXQoTyHmZcQpeNRuRNcgLpPcLD4XTN90Nm11wG1kfmLGG hFJOXJJWFl+F+s3ameDRFH9Tk388hGJnzTwiADqSlj9aWu/qVZnL6PMg3bDHxyWWOKek PtPg== X-Gm-Message-State: ALoCoQkisyI2ipjhcZ4KKiJ1YWYXL6NCNHXgjCg6Ca/GzMz55k0t06kCOiF7yo5vsUV/r4muZZoQ MIME-Version: 1.0 X-Received: by 10.28.88.129 with SMTP id m123mr12988982wmb.76.1446845554651; Fri, 06 Nov 2015 13:32:34 -0800 (PST) Received: by 10.194.91.134 with HTTP; Fri, 6 Nov 2015 13:32:34 -0800 (PST) X-Originating-IP: [101.110.53.38] In-Reply-To: <563C272F.6020000@network-heretics.com> References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> <563B54D0.90602@network-heretics.com> <563C272F.6020000@network-heretics.com> Date: Sat, 7 Nov 2015 06:32:34 +0900 Message-ID: From: Andrew Newton To: Keith Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 21:32:37 -0000 On Fri, Nov 6, 2015 at 1:06 PM, Keith Moore wrote: > So when people make handwaving arguments to the effect that there's no need > to make sure that URNs can be resolved in a general fashion, those > unsupportable arguments are apparently just fine. But when people try to > discuss specifics of how it could be done, as a proof of concept, those > arguments are out of order? Are you discussing specifics of URNs? I cannot discern that. You have been discussing protocols that use Dublin Core XML and some thing that returns URLs in a JSON format that does not yet exist. And you are doing it all in an email thread about the 2141bis -14 draft version. So is there something you want specifically added to the draft? If you do, send text. -andy From nobody Fri Nov 6 15:19:54 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0E01B2A7B for ; Fri, 6 Nov 2015 15:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fckjs7tB-zLR for ; Fri, 6 Nov 2015 15:19:52 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CD21B2A84 for ; Fri, 6 Nov 2015 15:19:51 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZuqIL-00020T-5I; Fri, 06 Nov 2015 18:19:45 -0500 Date: Fri, 06 Nov 2015 18:19:40 -0500 From: John C Klensin To: Keith Moore , "Hakala, Juha E" , Andrew Newton Message-ID: <1FD4589F6F853066CC083FB6@JcK-HP8200.jck.com> In-Reply-To: <563CA700.2060208@network-heretics.com> References: <4C96F9F5130CA1F7CFFBD949@JcK-HP8200.jck.com> <56394F79.5090907@network-heretics.com> <563C2D54.5080602@network-heretics.com> <563CA700.2060208@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] generic/universal URN resolver X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 23:19:53 -0000 --On Friday, November 06, 2015 08:11 -0500 Keith Moore wrote: >... > It occurs to me that a registry that advertises resolution > services on a per-namespace basis could be designed in such a > way as to allow a namespace to advertise that it has never > assigned a URN to any resource - all of the URNs it has > generated were merely for the purpose of being unique strings > - and this would allow a resolution API to return the result > "this URN isn't bound to anything". And we could make > entries in that registry for any URN namespaces (e.g. uuid) > that are inherently nothing more than unique strings, and > don't have an organization to make the entry on their behalf. > > I also agree that for URNs that are bound to things that > inherently aren't accessible over the network, resolution is > limited to metadata. > > I also agree that unless a namespace advertises one or more > resolution services for that namespace, there will be no > _authoritative_ resolution of the URNs from that namespace. Keith, With Andy's recent comments very much in mind, allow me to add a more specific observation: If you are proposing changes to 2141bis (or any other active WG document), please tell us exactly what you are proposing, preferably in the form of specific text. If you are proposing new, separate, functionality, such as a new IANA registry with different structure, contents, or usage (as I infer from the first sentence above), then please write and post an I-D that the WG can consider... starting with considering whether it wants that I-D in its work program and, if so, where it fits in that program and what, if anything, should be said about it in 2141bis. Without more specifics (again, ideally in the form of proposed text), I can't figure out enough about what it means for a namespace (or registry) to "advertise a namespace" to construct text. I can hand wave with the best of them, but, if you are going to object to any hand waving I try to do in that area (as I think you, quite reasonably, would) then I don't want to waste either of our time guessing at such text. And, with apologies for being blunt, if you want the WG to wait while things "occur to you" and you sort out possible designs, please say that explicitly and propose a schedule so the WG can decide whether it wants to wait. If it does, we should probably be quiet and let you push ahead. If it does not, I hope you can propose specific text about future work for 2141bis (or another document) and get the WG to agree to that. There are also a few things in this note and some others that really do need to be nailed down for 2141bis unless hand waving is acceptable. For example, you wrote: > I also agree that for URNs that are bound to things that > inherently aren't accessible over the network, resolution is > limited to metadata. Now that is a very specific assertion ... or not, depending on what metadata means (either generally of for a particular urn. As an only-slightly silly example, suppose one has a namespace for "pirate treasure". I've seen nothing so far that would prohibit such a namespace and associated URN and if there were to be such text in 2141bis-14, I'd argue it is a mistake. That hypothetical URN isn't likely to return gold doubloons, at least until the Internet is upgraded to do matter transport. My guess is that urn:piratetreasure:blackbeard could "resolve" to "unknown location, lots of speculation". I think that is metadata, but I'm not sure. On the other hand, urn:piratetreasure:Whydah might easily resolve to a map, to a list of museums at which artifacts are being exhibited, a collection of photographs, etc. If one assumes that none of those things are any more online ("on the net") than the ship's hull is, then which are data and which are metadata (or whether they are all one or the other) is a function of exactly how the namespace is defined and treated and not, AFAICT, not some intrinsic property of the difference between "data" and "metadata" (or those two and "object"). So, again, if you want something said along the lines of the statement above in 2141bis, we need text that the WG can argue about. I also suggest that, unless you want to severely constrain what sorts of URNs are possible (I prefer "constrain" to "cripple", but the meanings in this context may be similar), you not try defining the difference between "data" and "metadata" in a namespace-independent way. best, john From nobody Sun Nov 8 20:23:54 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663CC1B313D for ; Sun, 8 Nov 2015 20:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeoN6ixamx5D for ; Sun, 8 Nov 2015 20:23:52 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9181B3138 for ; Sun, 8 Nov 2015 20:23:51 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9D4D9509BB for ; Sun, 8 Nov 2015 23:23:50 -0500 (EST) To: "urn@ietf.org" From: Sean Leonard Message-ID: <56401F87.3030109@seantek.com> Date: Sun, 8 Nov 2015 20:22:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060503060108090400020304" Archived-At: Subject: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 04:23:53 -0000 This is a cryptographically signed message in MIME format. --------------ms060503060108090400020304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable This is a consensus check on our understanding of f-components. A urn: URI is parseable into the following components: "urn:" NID NSS "?" r-component q-component "#" f-component (Forget about the specific order for the time being. The list above is=20 unordered.) The f-component is a fragment [RFC3986]. Therefore, the semantics of the = f-component are defined by the media type of the resource, if any. A URN resolver is supposed to take NID, NSS, r-component, and=20 q-component, and depending on various operations, ultimately return a=20 set of URIs--or other kinds of resources or data items--with optional=20 attributes. When all such things are fully dereferenced, the expectation = is that you are supposed to get "content" in the MIME/Internet message=20 sense. Therefore, a URI-using system can forward the f-component as-is=20 to the software subsystem that processes the content according to its=20 media type. E.g., for that is=20 intended for display in a web browser that is application/pdf-aware, the = web browser ultimately gets a content that is application/pdf, opens the = PDF viewer, and has the PDF viewer component receive the fragment "page=3D= 2". A URI "dereferencer" never needs to see the f-component [RFC3986]. It=20 follows that a URN resolver never needs to see the f-component. This understanding does not preclude resolution to non-"content". The=20 urn: URI could ultimately get dereferenced to an octet stream (which has = no media type--any media type would be guessed at with content-sniffing=20 or other means), or to "metadata" (which for our purposes, is=20 implementable as a blank URI with attributes). In such cases the=20 semantics of f-component are undefined. Agree? Disagree? Sean --------------ms060503060108090400020304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MDkwNDIyMzFaMC8GCSqGSIb3DQEJBDEiBCDuH3OLRt1mswJv+6DLLfUdVz0SnmfzvxQ9rcws ryLzWzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQC4W801IKdkovWjzaqD zHjAov2E7St+G3AuTIaKhWdNHL4yf4VmcHCq26YcD/hvAHhamQF8XWHlYNKUi08PjFYtGYOz A0rwp2tbYvSmt/KT9e06ZVNmvQmxsIbAK7RGNfj5E7pWE5iJ/yUS1H/QlT59I4K0VIDRh1cf klXy3yyJumKqQyc/VRAnphAaQiDPvD+RXXaCo956dbfrIAnwlbs4dS/cy+StHxIKmYxQcw8Z ThNIOY2UsIpZzc6XwJsAzomD0IFYKF3ElOaYfHnMP2ob6BlPo1T7nzhph6T4FcXtiBgi8pl/ 1x/TwBz7e7K5jKWhE9CmHMJ6OUOHeEwOAYvmAAAAAAAA --------------ms060503060108090400020304-- From nobody Sun Nov 8 20:40:11 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85C1B6281 for ; Sun, 8 Nov 2015 20:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnYstYZsR2at for ; Sun, 8 Nov 2015 20:40:09 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321961B6274 for ; Sun, 8 Nov 2015 20:40:08 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E38B8509BB for ; Sun, 8 Nov 2015 23:40:06 -0500 (EST) To: "urn@ietf.org" From: Sean Leonard Message-ID: <5640235B.20005@seantek.com> Date: Sun, 8 Nov 2015 20:38:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040907030808090406000702" Archived-At: Subject: [urn] implementing q-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 04:40:10 -0000 This is a cryptographically signed message in MIME format. --------------ms040907030808090406000702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable This is a consensus check on our understanding of q-components. A urn: URI is parseable into the following components: "urn:" NID NSS "?" r-component q-component "#" f-component (Forget about the specific order for the time being. The list above is=20 unordered.) The q-component is a string that is transmitted to the "resource" that=20 is identified after "resolution" takes place with the "URN resolver". We need to conceptualize urn: URI processing into the following=20 components in a client-server model: on client: urn: URI dereferencer: takes string, splits into NID, NSS, r-component,=20 q-component (never sees f-component) client CALLS server(s) on the network: URN resolver / URN resolution / URN resolution service: takes NID, NSS,=20 r-component RETURNS "stuff" urn: URI dereferencer (client): receives "stuff" * combines "stuff" with q-component results in a set of absolute-URIs or other data items, with optional=20 attributes THEN URI dereferencing can happen (on the absolute-URIs). Agree? Disagree? Sean PS In constructing this e-mail I relied on several recent e-mails=20 including those by Keith Moore, who insists "that q-components should=20 not be passed to resolvers"=20 . * I am struggling to see how this is implementable. But I want to check=20 our consensus first. --------------ms040907030808090406000702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MDkwNDM4NTFaMC8GCSqGSIb3DQEJBDEiBCBaepoGyctQPCejbdYlzJm+7K0SbPHFh17T2E89 RrLe9jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQAR1smuyp+ob9jVpNDN WsoVLcsHDoDnxchKXk2W8iSjNCGJty9YXQkqci0oAwpkrANUIsJuA0M2MmDlRqEXj9U5WOr6 aV9fDqYb70EYAVTKB+6dVxf9ETGKy1vwS2a2+9Mjy6QehoukHGvgbWO2reease7qpom3xcgv RZ7bPRgGDp5/v7yAIQGBbuwvFzB3pMxuOueQn36cp3t9/6gOh/1razJnbadLh66HrhdVfWSZ jJFbrvhlCxjS87gf7BgitwXTr0P7TRAhwQUiw/fPcX3avvLJ4NYmISZ2U8IztbcASvW8vppV C9j11Y8xM6oKkzK4tOhwJ/K8mGDgJO8dHDCTAAAAAAAA --------------ms040907030808090406000702-- From nobody Mon Nov 9 02:33:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087401ACD03 for ; Mon, 9 Nov 2015 02:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO8toDxQphU3 for ; Mon, 9 Nov 2015 02:32:56 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 025401ACCF9 for ; Mon, 9 Nov 2015 02:32:54 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tA9AWcuQ016868; Mon, 9 Nov 2015 10:32:43 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tA9AWaCh010024; Mon, 9 Nov 2015 10:32:36 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tA9AWbD0004239; Mon, 9 Nov 2015 10:32:38 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tA9AWaqx004238; Mon, 9 Nov 2015 10:32:36 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Sean Leonard References: <56401F87.3030109@seantek.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 09 Nov 2015 10:32:36 +0000 In-Reply-To: <56401F87.3030109@seantek.com> (Sean Leonard's message of "Sun\, 8 Nov 2015 20\:22\:31 -0800") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 10:32:59 -0000 Sean Leonard writes: > The f-component is a fragment [RFC3986]. Therefore, the semantics of > the f-component are defined by the media type of the resource, if any. Yes (7231 would say "retrieved representation", not "resource", i.e. what you below call "content"). > A URN resolver is supposed to take NID, NSS, r-component, and > q-component, and depending on various operations, ultimately return a > set of URIs--or other kinds of resources or data items--with optional > attributes. When all such things are fully dereferenced, the > expectation is that you are supposed to get "content" in the > MIME/Internet message sense. Therefore, a URI-using system can forward > the f-component as-is to the software subsystem that processes the > content according to its media type. Not quite, see below. > E.g., for that is > intended for display in a web browser that is application/pdf-aware, > the web browser ultimately gets a content that is application/pdf, > opens the PDF viewer, and has the PDF viewer component receive the > fragment "page=2". Yes. > A URI "dereferencer" never needs to see the f-component [RFC3986]. It > follows that a URN resolver never needs to see the f-component. Yes. > This understanding does not preclude resolution to non-"content". The > urn: URI could ultimately get dereferenced to an octet stream (which > has no media type--any media type would be guessed at with > content-sniffing or other means), or to "metadata" (which for our > purposes, is implementable as a blank URI with attributes). In such > cases the semantics of f-component are undefined. (I think including 'sniffing' here is a distraction: if e.g. a browser guesses a media type, processing is no different from when a media-type is part of the response.) > Agree? Disagree? Your introductory description is a little too vague to be sure. In particular, taking your pdf example above, if we suppose a browser encounters that URN in HTML content in, say, the 'href' attribute of an 'a' element, and accordingly (supposing the host page, or some higher authority, has registered some resolvers against the 'urn' URI scheme), an HTTP GET request is sent to one of them. Some of your subsequent discussion is then, in my view, open to misinterpretation, because it leaves something important out. That is, the crucial question wrt the f-component is the HTTP response status code that comes back in response to a GET for a URN. It is this that determines whether the response body is "content" or not. If the response status code is 200, then the body is indeed "content", and the f-component applies to it. If it's _not_ a 200, then the body is _not_ "content", and the f-component does _not_ apply. What I'm trying to get at here is that it's _not_ (or not primarily) what's in an HTTP response body that determines whether it's "content" or "metadata", but the response status code and other parts of the response header. This is not to say that much (anything?) has to change in urnbis, rather just to try to clarify what is in fact out-of-scope for it, at least as far as expectations when HTTP-mediated resolution is involved. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Nov 9 04:14:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866961B29F7 for ; Mon, 9 Nov 2015 04:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nJWnyObvUM7 for ; Mon, 9 Nov 2015 04:14:49 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8CE1B29F5 for ; Mon, 9 Nov 2015 04:14:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3FA8C205A5 for ; Mon, 9 Nov 2015 07:14:48 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 09 Nov 2015 07:14:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=RJHCBhpE2aKD/EP OTRWlMYeK1bA=; b=aAvVhBep1J/pcIJaYL6fzwIW5lohh65FcOyD9MK5yEReN6c hwe5epGnA/CmXlfalsosqu/ey11NmxmdgqIu99XTywxGOJYJHsLcuNiL5ry4GW4v /G7zUyxUDkNho6Bz0v+m6kAn9kgWmXMOR47oEJCfQMG4RYiXPt67qJvQDLO8= X-Sasl-enc: aoEDbMudquBaVtBerDNaq/n42AFflKf5ozvpxEJkXBTt 1447071287 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C548F680170; Mon, 9 Nov 2015 07:14:47 -0500 (EST) To: Sean Leonard , "urn@ietf.org" References: <56401F87.3030109@seantek.com> From: Keith Moore Message-ID: <56408E2F.9040703@network-heretics.com> Date: Mon, 9 Nov 2015 07:14:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56401F87.3030109@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:14:50 -0000 On 11/08/2015 11:22 PM, Sean Leonard wrote: > This is a consensus check on our understanding of f-components. > > A urn: URI is parseable into the following components: > "urn:" > NID > NSS > "?" > r-component > q-component > "#" > f-component > > (Forget about the specific order for the time being. The list above is > unordered.) > > The f-component is a fragment [RFC3986]. Therefore, the semantics of > the f-component are defined by the media type of the resource, if any. > > A URN resolver is supposed to take NID, NSS, r-component, and > q-component, and depending on various operations, ultimately return a > set of URIs--or other kinds of resources or data items--with optional > attributes. When all such things are fully dereferenced, the > expectation is that you are supposed to get "content" in the > MIME/Internet message sense. Therefore, a URI-using system can forward > the f-component as-is to the software subsystem that processes the > content according to its media type. > > E.g., for that is > intended for display in a web browser that is application/pdf-aware, > the web browser ultimately gets a content that is application/pdf, > opens the PDF viewer, and has the PDF viewer component receive the > fragment "page=2". > > A URI "dereferencer" never needs to see the f-component [RFC3986]. It > follows that a URN resolver never needs to see the f-component. > > This understanding does not preclude resolution to non-"content". The > urn: URI could ultimately get dereferenced to an octet stream (which > has no media type--any media type would be guessed at with > content-sniffing or other means), or to "metadata" (which for our > purposes, is implementable as a blank URI with attributes). In such > cases the semantics of f-component are undefined. > > Agree? Disagree? Mostly agree. A couple of minor exceptions: - application/octet-stream is a media type, and it's possible to define f-components (e.g. ranges consisting of offset and length) that make sense with that media type. - While we can't stop clients from "sniffing" to guess what that content "really" means, clients that try to be too smart about such things can also make life difficult for users. So while you might be right about how a particular client would behave when presented with an octet-stream content, I wouldn't want us to specify that behavior. - The expectation of URN resolution isn't inherently to obtain "content". It is reasonable to resolve a URN with the goal of obtaining metadata, or information about related works, or access to a resource in some other way than to download all of its content (e.g. interacting with a remote database, or playing a video and having the video stream - but not the DVD content itself - sent back to one's display). We should not presume that the only way to usefully use a resource is to download the entirety of that resource's content. This expectation could be communicated explicitly via r-component or client request, or implicitly from the context in which the URN appears. (e.g. a URN in a SRC parameter probably requires access to the image content, whereas for a URN in an HREF parameter used in an interactive application like a web browser it might be sufficient to permit the user to interact with that resource). I also agree that semantics of an f-component with a URN that is resolved for the purpose of other than obtaining "content" is currently undefined. I am not sure whether it should remain undefined, be declared inappropriate, or be declared an error to use f-component in this way. Keith From nobody Mon Nov 9 04:19:07 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C941B7BEC for ; Mon, 9 Nov 2015 04:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iALyniWjjzG for ; Mon, 9 Nov 2015 04:19:03 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id E3CEF1B7BEE for ; Mon, 9 Nov 2015 04:19:02 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tA9CIj3s022121; Mon, 9 Nov 2015 12:18:50 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tA9CIhn4015293; Mon, 9 Nov 2015 12:18:43 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tA9CIjZL008478; Mon, 9 Nov 2015 12:18:45 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tA9CIjeI008477; Mon, 9 Nov 2015 12:18:45 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Sean Leonard References: <5640235B.20005@seantek.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 09 Nov 2015 12:18:45 +0000 In-Reply-To: <5640235B.20005@seantek.com> (Sean Leonard's message of "Sun\, 8 Nov 2015 20\:38\:51 -0800") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing q-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:19:06 -0000 Sean Leonard writes: > . . . > We need to conceptualize urn: URI processing into the following > components in a client-server model: > > on client: > urn: URI dereferencer: takes string, splits into NID, NSS, > r-component, q-component > (never sees f-component) > > client CALLS server(s) on the network: > URN resolver / URN resolution / URN resolution service: takes NID, > NSS, r-component > RETURNS "stuff" > > urn: URI dereferencer (client): receives "stuff" * > combines "stuff" with q-component > results in a set of absolute-URIs or other data items, with optional > attributes > > THEN URI dereferencing can happen (on the absolute-URIs). > > Agree? Disagree? Disagree. Why load so much on the client? Why make this so different from how 'real' query-strings are understood and processed today? In particular, this effectively means that I can't write a resolver which assumes almost nothing about the user agent that sent the resoution request except that it will handle 302 responses correctly. That is, consider the following (made up) URN urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml It would, if we _don't_ follow the rule you propose above, be trivial to implement a resolver service as follows. First, do registerProtocolHandler('urn','rfcsearch?uri=%s','IETF RFC Search') on the containing page, say, https://www.rfc-editor.org/latest/, and configuring the rfc-editor server to respond to https://www.rfc-editor.org/latest/rfcsearch?uri=urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml with a 302 response status code and the header Location: https://rfc-editor.yourNearestIETFMirror.ietf.org/search/rfc_search_detail.php?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml Done. No muss, no fuss, no plugin installation, all under the control of the hosting server. > PS In constructing this e-mail I relied on several recent e-mails > including those by Keith Moore, who insists "that q-components should > not be passed to resolvers" > . > * I am struggling to see how this is implementable. But I want to > check our consensus first. I have only skimmed Keith's messages, my apologies if one of his points directly addresses the above. But it seems to me that the desire to do something like the above follows more-or-less directly from 2141's requirement that resolvable URN namespaces must provide a mapping from URNs with 'their' namespace to retrieval-enabled (non-URN) URIs. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Nov 9 04:22:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE351B7BFF for ; Mon, 9 Nov 2015 04:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4TRyjf3AAun for ; Mon, 9 Nov 2015 04:22:31 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442511B7BFE for ; Mon, 9 Nov 2015 04:22:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A193D20816 for ; Mon, 9 Nov 2015 07:22:30 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 09 Nov 2015 07:22:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=4syNf1dYEFK9Lsp fKWVo09QZWEU=; b=oylQB664lT4jekYlrUAe51MpQIED7x/frW8yh8Dsq1wjosS pqZm44zBUXn2eKq9IlbogmjoniuI6o8mlSJ7bMYkloHyJF7jXKZk4lsxJuJbM1pY XxS8BhdvHPgwkuhUi5XH7OyZ8yWrZsfTye/hWIO97fxru7zhz0xA4/V5vBwo= X-Sasl-enc: m99EImMlMQfa+ITAiOEGj9y0IhWV5lJoeNRaxpB+sWcH 1447071750 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 361E3680128; Mon, 9 Nov 2015 07:22:30 -0500 (EST) To: Sean Leonard , "urn@ietf.org" References: <5640235B.20005@seantek.com> From: Keith Moore Message-ID: <56408FFE.8070207@network-heretics.com> Date: Mon, 9 Nov 2015 07:22:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5640235B.20005@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] implementing q-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:22:33 -0000 On 11/08/2015 11:38 PM, Sean Leonard wrote: > This is a consensus check on our understanding of q-components. > > A urn: URI is parseable into the following components: > "urn:" > NID > NSS > "?" > r-component > q-component > "#" > f-component > > (Forget about the specific order for the time being. The list above is > unordered.) > > The q-component is a string that is transmitted to the "resource" that > is identified after "resolution" takes place with the "URN resolver". > > We need to conceptualize urn: URI processing into the following > components in a client-server model: > > on client: > urn: URI dereferencer: takes string, splits into NID, NSS, > r-component, q-component > (never sees f-component) > > client CALLS server(s) on the network: > URN resolver / URN resolution / URN resolution service: takes NID, > NSS, r-component > RETURNS "stuff" > > urn: URI dereferencer (client): receives "stuff" * > combines "stuff" with q-component > results in a set of absolute-URIs or other data items, with optional > attributes > > THEN URI dereferencing can happen (on the absolute-URIs). > > Agree? Disagree? Mostly agree. In particular, the resolution service should never see the q-component. If the URN resolves to one or more URLs, the q-component becomes the query portion of those URLs. If the URN resolves to a resource in some other way, the q-component should be reserved for transmitting input to the resource. (The above assumes that the goal of this resolution operation - whether implicit or explicitly stated in the r-component - is to access the resource itself. If the goal is instead to obtain metadata, it's not immediately clear to me whether the q-component can have a role, whether it should simply be ignored, or whether it should be an error. To me, the simplest, and probably best, model is that the q-component is only used to send input to the resource itself, and all resolution parameters are supplied in the r-component. That seems to assure a clean separation of function between the two and remove any conflict about whether a q-component goes to a resource or a resolution service in any particular case.) > > Sean > > PS In constructing this e-mail I relied on several recent e-mails > including those by Keith Moore, who insists "that q-components should > not be passed to resolvers" > . > * I am struggling to see how this is implementable. But I want to > check our consensus first. I am working on a description of how to implement this, and also how the various pieces fit together. Keith From nobody Mon Nov 9 04:25:23 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9671B7C16 for ; Mon, 9 Nov 2015 04:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aIOFHPOwic9 for ; Mon, 9 Nov 2015 04:25:20 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCCA1B7C13 for ; Mon, 9 Nov 2015 04:25:20 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tA9CP9Gb026552; Mon, 9 Nov 2015 12:25:09 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tA9CP7E3015834; Mon, 9 Nov 2015 12:25:07 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tA9CP8sE008757; Mon, 9 Nov 2015 12:25:08 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tA9CP8Zl008756; Mon, 9 Nov 2015 12:25:08 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Keith Moore References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 09 Nov 2015 12:25:08 +0000 In-Reply-To: <56408E2F.9040703@network-heretics.com> (Keith Moore's message of "Mon\, 9 Nov 2015 07\:14\:39 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:25:22 -0000 Keith Moore writes: > I also agree that semantics of an f-component with a URN that is > resolved for the purpose of other than obtaining "content" is > currently undefined. I am not sure whether it should remain > undefined, be declared inappropriate, or be declared an error to use > f-component in this way. On the one hand, neither server nor client can know what a user's purpose is in attempting to resolve a URN. On the other hand I think it follows from my earlier response that if a server is configured so as not to respond with "content", i.e. with a response status code of other than 200, then (modulo some subtleties to do with 301 and 302 responses) the point is moot: there is no content, so the f-component is irrelevant and, of necessity, ignored. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Nov 9 04:27:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C13F1B7C22 for ; Mon, 9 Nov 2015 04:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJcsOu7gCxNq for ; Mon, 9 Nov 2015 04:27:50 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001B51B7C20 for ; Mon, 9 Nov 2015 04:27:49 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5AA0720456 for ; Mon, 9 Nov 2015 07:27:49 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 09 Nov 2015 07:27:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OmnYIZivlPAejBS Acg8nhvgdHhM=; b=RGuMUQ+yPOWrQSg0QYV5RAb7mpfTI5z11kXdrzl5rzwCMFh 3x6JLgWUb9ticfZiyyWhjcs+obMWehVXbFApisS3G26T+S4V40fMMjMQwgTui/Ud 0jMEMUnmTdNgsPInWC6pxCuwffjE68JhS7iex0pEiFV6rnAskeIDhPRNsfx4= X-Sasl-enc: 6cEtjjveYkV5EQ/yt1UZm2gI8KpJkf0nufjzQc+pTJGs 1447072069 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id D4D526800B4; Mon, 9 Nov 2015 07:27:48 -0500 (EST) To: "Henry S. Thompson" , Sean Leonard References: <56401F87.3030109@seantek.com> From: Keith Moore Message-ID: <5640913C.2000005@network-heretics.com> Date: Mon, 9 Nov 2015 07:27:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:27:51 -0000 On 11/09/2015 05:32 AM, Henry S. Thompson wrote: > > Your introductory description is a little too vague to be sure. In > particular, taking your pdf example above, if we suppose a browser > encounters that URN in HTML content in, say, the 'href' attribute of an > 'a' element, and accordingly (supposing the host page, or some higher > authority, has registered some resolvers against the 'urn' URI scheme), > an HTTP GET request is sent to one of them. Some of your subsequent > discussion is then, in my view, open to misinterpretation, because it > leaves something important out. > > That is, the crucial question wrt the f-component is the HTTP response > status code that comes back in response to a GET for a URN. It is this > that determines whether the response body is "content" or not. If the > response status code is 200, then the body is indeed "content", and the > f-component applies to it. If it's _not_ a 200, then the body is _not_ > "content", and the f-component does _not_ apply. Agree. The f-component only applies if the operation to retrieve the content results in a successful download of that content. It does not apply to an error document, or an incomplete transfer. Note that since a URL fragment is specific to a particular kind of content-type, specifying an f-component of a URN (or fragment of a URL) that exists in multiple content-types isn't terribly useful without including some way to constrain the content-type obtained. Keith From nobody Mon Nov 9 04:33:38 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCC31B7C4E for ; Mon, 9 Nov 2015 04:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PevToSo0spXi for ; Mon, 9 Nov 2015 04:33:35 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4BB1B7C47 for ; Mon, 9 Nov 2015 04:33:35 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BB12020417 for ; Mon, 9 Nov 2015 07:33:34 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Nov 2015 07:33:34 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=iwRL5lvuuScyWWA nSwudmqs/axc=; b=mrAFsbfkqOmGoGbawKLKPSGqVWTzaoqsfe47croIqvPFrp0 eZPcSVlHdCIQ7lmu9lAUZGeLATMRmp3DRI788/GRa/fviYf2I2Lr8f1Cgk7iDior JNQVFWGkpQImJc+2W+JhPDkRgLWkP2wyABPoinrxBW1wQxV5Bq0zGyGYpJ7s= X-Sasl-enc: fXi8uXYmP4elQaRGK4TgymMC9Gby/uRdWl4jNv6I++fa 1447072414 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 451986800B4; Mon, 9 Nov 2015 07:33:34 -0500 (EST) To: "Henry S. Thompson" References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> From: Keith Moore Message-ID: <56409295.5030409@network-heretics.com> Date: Mon, 9 Nov 2015 07:33:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:33:37 -0000 On 11/09/2015 07:25 AM, Henry S. Thompson wrote: > Keith Moore writes: > >> I also agree that semantics of an f-component with a URN that is >> resolved for the purpose of other than obtaining "content" is >> currently undefined. I am not sure whether it should remain >> undefined, be declared inappropriate, or be declared an error to use >> f-component in this way. > On the one hand, neither server nor client can know what a user's > purpose is in attempting to resolve a URN. The client might know. For instance, if a URN appears in a document, a web browser might allow a "right click" on the link or other displayed object, and offer the user options such as "display metadata", "find related works", etc. In other cases the client can infer the purpose by context. If the URN appears in an IMG tag, it's pretty clear that the document author intended that the image be displayed, which probably requires obtaining the content of the image file. Also, the client is not necessarily an interactive web browser, and can potentially be any application that uses URIs. > > On the other hand I think it follows from my earlier response that if a > server is configured so as not to respond with "content", i.e. with a > response status code of other than 200, then (modulo some subtleties to > do with 301 and 302 responses) the point is moot: there is no content, > so the f-component is irrelevant and, of necessity, ignored. Perhaps. That's my current preference, anyway. Keith From nobody Mon Nov 9 04:39:11 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6005D1B7C6A for ; Mon, 9 Nov 2015 04:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLDDH1cZZ8VV for ; Mon, 9 Nov 2015 04:39:07 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 118121B7C69 for ; Mon, 9 Nov 2015 04:39:06 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tA9CcpTM004979; Mon, 9 Nov 2015 12:38:51 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tA9Ccnfi016455; Mon, 9 Nov 2015 12:38:49 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tA9CcofO009359; Mon, 9 Nov 2015 12:38:50 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tA9CcoA6009358; Mon, 9 Nov 2015 12:38:50 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Keith Moore References: <56401F87.3030109@seantek.com> <5640913C.2000005@network-heretics.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 09 Nov 2015 12:38:50 +0000 In-Reply-To: <5640913C.2000005@network-heretics.com> (Keith Moore's message of "Mon\, 9 Nov 2015 07\:27\:40 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:39:10 -0000 Keith Moore writes: > Note that since a URL fragment is specific to a particular kind of > content-type, specifying an f-component of a URN (or fragment of a > URL) that exists in multiple content-types isn't terribly useful > without including some way to constrain the content-type obtained. 3986 attempts to address this by saying that it is the owner/server's responsibility in such cases, in particular if content negotiation is involved, to ensure that the fragment involved applies to _all_ the potentially-returned content types. . . ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Nov 9 04:42:26 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662121B7C84 for ; Mon, 9 Nov 2015 04:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sVOUb1Sk1i2 for ; Mon, 9 Nov 2015 04:42:23 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D301B7C83 for ; Mon, 9 Nov 2015 04:42:23 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E24DE208C3 for ; Mon, 9 Nov 2015 07:42:22 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 09 Nov 2015 07:42:22 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=m71G7udYAzRMwU+ TpANdJb6slfk=; b=KBKnUeItKk9UKD3p26mXDeyaFPvvOv8AAjIkJF+jd6lFixx 6zRJ9Ay948VeHCpNa8UdzakgDTmdrL8FGQiPq5vmpgwDPE/QZV4GHv6LehJ6VJHa RYxprKLctiHsu02tVDjeGKy5xwlp2NwudMnzBr8Ad1wBi6bSnWtZI8ZJIvYc= X-Sasl-enc: c1gWJWzGtE0oD1kPiGk6bRt8RmuAr47WY2kUz0KLnSI+ 1447072942 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 5BCFDC016F0; Mon, 9 Nov 2015 07:42:22 -0500 (EST) To: "Henry S. Thompson" , Sean Leonard References: <5640235B.20005@seantek.com> From: Keith Moore Message-ID: <564094A5.7050307@network-heretics.com> Date: Mon, 9 Nov 2015 07:42:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing q-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:42:25 -0000 On 11/09/2015 07:18 AM, Henry S. Thompson wrote: > Sean Leonard writes: > >> . . . >> We need to conceptualize urn: URI processing into the following >> components in a client-server model: >> >> on client: >> urn: URI dereferencer: takes string, splits into NID, NSS, >> r-component, q-component >> (never sees f-component) >> >> client CALLS server(s) on the network: >> URN resolver / URN resolution / URN resolution service: takes NID, >> NSS, r-component >> RETURNS "stuff" >> >> urn: URI dereferencer (client): receives "stuff" * >> combines "stuff" with q-component >> results in a set of absolute-URIs or other data items, with optional >> attributes >> >> THEN URI dereferencing can happen (on the absolute-URIs). >> >> Agree? Disagree? > Disagree. Why load so much on the client? Why make this so different > from how 'real' query-strings are understood and processed today? I believe Sean's description is consistent with how real query strings are understood and processed today. In both URN and URL cases the client must first obtain the address of the resource server. Then it sends the query to the resource server. This isn't a significant 'load' except when the resolution service can provide multiple URLs for the resource - then the client has the burden of selecting one. (It can, however, just pick one at random. And the client is generally in a better position to choose between multiple URLs than the server is.) What would be inconsistent is to let resolution services try to interpret query strings and second-guess what those strings mean to the resources. It would be inconsistent both in that the same query string associated with the same resource would be interpreted different ways depending on whether the resource were accessed via URN or URL, and it would be inconsistent in the way relative URIs containing query strings were handled. > In particular, this effectively means that I can't write a resolver > which assumes almost nothing about the user agent that sent the > resoution request except that it will handle 302 responses correctly. > That is, consider the following (made up) URN > > urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml > > It would, if we _don't_ follow the rule you propose above, be trivial to > implement a resolver service as follows. > > First, do > > registerProtocolHandler('urn','rfcsearch?uri=%s','IETF RFC Search') > > on the containing page, say, https://www.rfc-editor.org/latest/, and > configuring the rfc-editor server to respond to > > https://www.rfc-editor.org/latest/rfcsearch?uri=urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml > > with a 302 response status code and the header > > Location: https://rfc-editor.yourNearestIETFMirror.ietf.org/search/rfc_search_detail.php?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml > > Done. No muss, no fuss, no plugin installation, all under the control > of the hosting server. Having the resolution service "control" what the client does is, IMO, an extremely bad idea. Having the client's input sent to the resolution service violates the client's privacy rights. Giving the resolution service the ability to alter the client's input, or refuse to complete the requests, is even worse than that. The role of a namespace is to dole out unique names and ensure their continued uniqueness, not to be a "big brother" that mediates access to resources. >> PS In constructing this e-mail I relied on several recent e-mails >> including those by Keith Moore, who insists "that q-components should >> not be passed to resolvers" >> . >> * I am struggling to see how this is implementable. But I want to >> check our consensus first. > I have only skimmed Keith's messages, my apologies if one of his points > directly addresses the above. But it seems to me that the desire to do > something like the above follows more-or-less directly from 2141's > requirement that resolvable URN namespaces must provide a mapping from > URNs with 'their' namespace to retrieval-enabled (non-URN) URIs. I don't think 2141 requires that this be done with a simple, one URL, HTTP redirect. Keith From nobody Mon Nov 9 04:43:12 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE39B1B7C87 for ; Mon, 9 Nov 2015 04:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZSJNhkCDkPL for ; Mon, 9 Nov 2015 04:43:10 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF9C1B7C86 for ; Mon, 9 Nov 2015 04:43:10 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DC26A2012E for ; Mon, 9 Nov 2015 07:43:09 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 09 Nov 2015 07:43:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=iVi9qsdYuBsG3s7 zYZdhxCowTGk=; b=S0qf6gj92LY3ZQ/9DUyyQzmrKSIY0DVylwdbki/DYX+ObqD cGy71p9kgz/6S5NLkxMqPJpW03DnSBpahtzzS9J+HqqPluaF5t+xozIgJIMPE9J7 nUfzQ4EFEuJVhV7TBbFLWj/iMSisySKlh/S9IorWQtr1kIt3bNQHoNCxGlQg= X-Sasl-enc: oqRCem7l48oxltMjCty7bZLvUHokN0TkPcgv2lN5XZSJ 1447072989 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C806C016EE; Mon, 9 Nov 2015 07:43:09 -0500 (EST) To: "Henry S. Thompson" References: <56401F87.3030109@seantek.com> <5640913C.2000005@network-heretics.com> From: Keith Moore Message-ID: <564094D5.6050909@network-heretics.com> Date: Mon, 9 Nov 2015 07:43:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:43:12 -0000 On 11/09/2015 07:38 AM, Henry S. Thompson wrote: >> >Note that since a URL fragment is specific to a particular kind of >> >content-type, specifying an f-component of a URN (or fragment of a >> >URL) that exists in multiple content-types isn't terribly useful >> >without including some way to constrain the content-type obtained. > 3986 attempts to address this by saying that it is the owner/server's > responsibility in such cases, in particular if content negotiation is > involved, to ensure that the fragment involved applies to_all_ the > potentially-returned content types. . . This is, of course, a sign of delusion. Keith From nobody Mon Nov 9 05:06:31 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC76C1B2A8D for ; Mon, 9 Nov 2015 05:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEeWtkCPHAsu for ; Mon, 9 Nov 2015 05:06:27 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5966E1B2A8B for ; Mon, 9 Nov 2015 05:06:26 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tA9D69h0026940; Mon, 9 Nov 2015 13:06:09 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tA9D674L018261; Mon, 9 Nov 2015 13:06:07 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tA9D684I010722; Mon, 9 Nov 2015 13:06:08 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tA9D68vV010721; Mon, 9 Nov 2015 13:06:08 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Keith Moore References: <5640235B.20005@seantek.com> <564094A5.7050307@network-heretics.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 09 Nov 2015 13:06:08 +0000 In-Reply-To: <564094A5.7050307@network-heretics.com> (Keith Moore's message of "Mon\, 9 Nov 2015 07\:42\:13 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing q-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:06:31 -0000 Keith Moore writes: > What would be inconsistent is to let resolution services try to > interpret query strings and second-guess what those strings mean to > the resources. I call FUD. > It would be inconsistent both in that the same query string > associated with the same resource would be interpreted different ways > depending on whether the resource were accessed via URN or URL, and it > would be inconsistent in the way relative URIs containing query > strings were handled. How does that follow at all from what I illustrated? >> In particular, this effectively means that I can't write a resolver >> which assumes almost nothing about the user agent that sent the >> resoution request except that it will handle 302 responses correctly. >> That is, consider the following (made up) URN >> >> urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml >> >> It would, if we _don't_ follow the rule you propose above, be trivial to >> implement a resolver service as follows. >> >> First, do >> >> registerProtocolHandler('urn','rfcsearch?uri=%s','IETF RFC Search') >> >> on the containing page, say, https://www.rfc-editor.org/latest/, and >> configuring the rfc-editor server to respond to >> >> https://www.rfc-editor.org/latest/rfcsearch?uri=urn:ietf:rfc:toc?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml >> >> with a 302 response status code and the header >> >> Location: https://rfc-editor.yourNearestIETFMirror.ietf.org/search/rfc_search_detail.php?pubstatus[]=Standards+Track=Any&pub_date_type=this_year&abstract_box=xml >> >> Done. No muss, no fuss, no plugin installation, all under the control >> of the hosting server. > > Having the resolution service "control" what the client does is, IMO, > an extremely bad idea. I call FUD again. > Having the client's input sent to the resolution service violates the > client's privacy rights. Hunh? The only way to get anything resolved is by sending it to the service. > Giving the resolution service the ability to alter the client's input, > or refuse to complete the requests, is even worse than that. Once you allow, as you _must_, the conversion of _any_ part of the URN into a retrieval-enabled URI by the resolution service, then you have handed over the interpretation of that URN to a 3rd party. > The role of a namespace is to dole out unique names and ensure their > continued uniqueness, not to be a "big brother" that mediates access > to resources. I call FUD. I encourage you to examine carefully the documentation for registerProtocolHandler [1] before responding again. >>> PS In constructing this e-mail I relied on several recent e-mails >>> including those by Keith Moore, who insists "that q-components should >>> not be passed to resolvers" >>> . >>> * I am struggling to see how this is implementable. But I want to >>> check our consensus first. >> I have only skimmed Keith's messages, my apologies if one of his points >> directly addresses the above. But it seems to me that the desire to do >> something like the above follows more-or-less directly from 2141's >> requirement that resolvable URN namespaces must provide a mapping from >> URNs with 'their' namespace to retrieval-enabled (non-URN) URIs. > > I don't think 2141 requires that this be done with a simple, one URL, > HTTP redirect. Agreed. It just points the way to a relatively trivial way to implement generic resolution. ht [1] http://www.w3.org/TR/html5/webappapis.html#custom-handlers -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Nov 9 05:11:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1911B2AAE for ; Mon, 9 Nov 2015 05:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tqIzdpwGGXs for ; Mon, 9 Nov 2015 05:11:27 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 610DD1B2AAA for ; Mon, 9 Nov 2015 05:11:27 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tA9DBQur029628; Mon, 9 Nov 2015 13:11:26 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tA9DBOTd022243; Mon, 9 Nov 2015 13:11:24 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tA9DBQMr010956; Mon, 9 Nov 2015 13:11:26 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tA9DBQp6010955; Mon, 9 Nov 2015 13:11:26 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Keith Moore References: <5640235B.20005@seantek.com> <56408FFE.8070207@network-heretics.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 09 Nov 2015 13:11:26 +0000 In-Reply-To: <56408FFE.8070207@network-heretics.com> (Keith Moore's message of "Mon\, 9 Nov 2015 07\:22\:22 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] implementing q-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:11:29 -0000 Keith Moore writes: > (... To me, the simplest, and probably best, model is that the > q-component is only used to send input to the resource itself, and all > resolution parameters are supplied in the r-component. That seems to > assure a clean separation of function between the two and remove any > conflict about whether a q-component goes to a resource or a > resolution service in any particular case.) Agreed. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Mon Nov 9 05:16:05 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469F41B2AE6 for ; Mon, 9 Nov 2015 05:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NR4OABSdmqz for ; Mon, 9 Nov 2015 05:16:01 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A4D1B2ADC for ; Mon, 9 Nov 2015 05:16:01 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C6EDD2021F for ; Mon, 9 Nov 2015 08:16:00 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Nov 2015 08:16:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=xSf/ekN2i28XV4S SIe0pHn+TLRA=; b=R0JimlPWWQ07SDCFNglSjJWkhamziBdzM6+G9LDHW69aJgf jDo3Ry/nrp7tyULJoTrMYkiXmJoyaGLUidF2sz0AtEuMykJ/3tPuVV3io+5z8zjo T4bt5Nb2Qjm9rLtDaFRUvJY5E2DYSQ9LcTyZaSxWfMfXrkx6xogbN5UAXyRM= X-Sasl-enc: 0cL1zBm3lfnulcgs+tXNa7bK+bUyoxZRHMMAdr/MUGFr 1447074960 Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 50EF66800B4; Mon, 9 Nov 2015 08:16:00 -0500 (EST) To: urn@ietf.org References: <5636A2E2.90209@andyet.net> <5636A50D.3000700@gmail.com> <5636D564.8060009@network-heretics.com> <5636D7DD.2040906@andyet.net> <5636DAB2.8000002@network-heretics.com> <59AFC6A08A3B43A19489BFA9@JcK-HP8200.jck.com> <56376110.90203@network-heretics.com> <56394996.7000507@network-heretics.com> <1A784C51-805D-48D6-B9BA-B4978318682B@seantek.com> <563B54D0.90602@network-heretics.com> <563C272F.6020000@network-heretics.com> From: Keith Moore Message-ID: <56409C6E.4000105@network-heretics.com> Date: Mon, 9 Nov 2015 08:15:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] -14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:16:04 -0000 On 11/06/2015 04:54 AM, John C Klensin wrote: > > --On Thursday, November 05, 2015 23:06 -0500 Keith Moore > wrote: > >> ... >> I'm really getting tired of all of the efforts to cripple URNs. > Keith, > > Independent of the virtues of your substantive positions, I > think the above is a severe mischaracterization. As far as I > can tell, no one who has been active on this list in recent > months is trying to cripple URNs. What we are trying to do is > to find a way to write a URN standard that is (i) consistent > with known existing uses and plausible future ones that are not > completely off the wall and (ii) that can be finished somewhat > in advance of the heat death of the universe and preferably > within a small number of months. As far as I can tell, the constant demand to keep the scope of the discussion so narrow is actually making the effort take far longer than it needs to take. Take r-components, for example. Having a clean separation between parameters to the resolution service and parameters sent to the resource appears to make good sense. But in order to get the particulars of r-components right or even approximately so, we need to work out in more detail how they'd actually be used. For example: Based on the work I've done so far it appears that the entirety of a service request to a resolution service should be specified in an r-component. That seems to make more sense than trying to separate client-supplied parameters and parameters supplied in the r-component of the URN and having the resolution service resolve the conflicts between the two. It follows that clients need to be able to understand at least some facets of r-components and be able to remove or alter them under some conditions. It follows that at least some of the facets of r-components need to be standardized and applicable across all resolution services, and this begs the question of how to distinguish between those facets and facets that are specific to a particular namespace or resolution protocol. Now it might be the case that a different way of interpreting r-components would work better. The point is that there's no way to know without describing, and discussing, those things in more concrete detail. And there's no way to have a useful discussion without exposing that detail. As long as we're trying to avoid doing those things, everyone's reaction to a proposal is based entirely on speculation and/or fear. When, due to a lack of detail, people constantly overreact to proposals based on what they imagine might be the result, it's difficult to ever reach any kind of agreement. And even if people reach apparent consensus, that apparent consensus might disguise significant differences in how the specifications are interpreted, that will create operational problems later on. > To at least some of us, what > we are looking for more nearly resembles "expand the range and > functionality to at least match reality" than it does "cripple" "Reality", in my experience, is highly subjective. Everyone's idea of reality is different. > At least for me, the means getting very pragmatic rather than, > e.g., theorizing about what we might do if it had infinite time > and a clean slate. Nobody said anything about either infinite time or a clean slate. I have in fact strongly objected to people's efforts to clean the slate, and I'm as painfully aware as anyone that time (both calendar time and real time) is precious. But I've seen a lot of examples of willingness to disregard requirements that were long established, clearly stated (especially in comparison with much of the current discussion), and agreed on by WG consensus, in favor of new requirements that are not clearly stated and for which informed consensus is dubious at best. > I see the alternative as ending up with no > IETF standard to which most actors don't bother to pay attention > and either no other standard or a collection of different ones, > from different bodies that have different interests and > priorities, and that are not consistent or compatible. I don't > think we have unlimited time; I'm surprised we haven't run out > of time already. > > Again for me, that means approaching every new (or repeated) > idea and proposal with questions like: > > (i) Is this really critical path? Yes. > (ii) It is likely that this particular idea can be documented > and consensus reached in a reasonable amount of it (where > "reasonable" includes recognizing that we are already years > overdue on the core work)? Yes, but not if we keep avoiding looking at the situation in sufficient detail. (and let's try to avoid using the sunken cost fallacy as an excuse to avoid doing what makes the most sense now.) > (iii) Closely related to be above, is the idea sufficiently > clear and specific to be actionable or is it merely a statement > of vague principles? If the latter, is it safe to ignore it > and, if not, why not. We absolutely must become more specific in our discussions, because it is not safe to ignore the details of how resolution will work. > There is another important aspect of URNs that I think we should > keep in mind. While there are certainly important exceptions, > one of them brought about by the idea that one can embed any URI > in an HTML "aref", in many, perhaps most, application > situations, the application developer is perfectly aware of the > range of URNs (with or without other URI types) that are likely > to be relevant. For that range, it is entirely reasonable to > assume that the application will have knowledge of whether > resolution is needed and a resolver, resolution-database or > dispatcher, or a set of per-namespace resolvers, readily > available. > > In that situation, a "universal" mechanism is needed only for > the namespaces that are relevant. Having a universal resolution mechanism does not preclude an application from using other mechanisms. Neither are applications precluded from having and exploiting knowledge of specific URN namespaces, because there are clearly at least edge cases where it's useful for applications to be able to do this. At the same time, I resist the notion that URN-aware applications in general should have to be aware of namespaces in order to function, or that it makes sense to let every namespace define its own resolution protocols, r-components and whatnot without any effort to produce a common framework. As I've argued on multiple occasions, this undermines the purpose of URNs of being long-term stable resource names, because without a common framework it's likely that only the most popular namespaces will be supported over a long period of time. So I see the purpose of URN standardization efforts as to work out how URNs and URN resolution work in a general fashion. Specific applications can, and will, do what they wish. It's the general case that requires standardization, not what specific applications do. If a particular namespace wants to say "resolution is meaningless for names in this namespace", fine. We can make that discoverable too. > Other kinds of namespaces and > their resolution mechanisms are either not relevant or are an > attack vector. I don't have time to try to explore all of those > details and suspect the WG doesn't either. But, just as I don't > think the recent discussions can be reasonably characterized as > trying to cripple URNs, I don't think "can't figure out how to > either find an authoritative resolver or authoritatively > determine that one is not needed" is really a showstopper for > the effort to define URNs that are extended enough beyond 2141 > to match today's realities. I'm not even sure what you mean here. Again, the lack of specifics makes it hard to have a useful discussion, and I'm tired of trying to counteract others' vague arguments with my own vague arguments. Keith From nobody Mon Nov 9 10:10:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508641A907B for ; Mon, 9 Nov 2015 10:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUHle_EfHbWK for ; Mon, 9 Nov 2015 10:10:13 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746FA1A1A1C for ; Mon, 9 Nov 2015 10:10:04 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZvqtC-000Eve-5H; Mon, 09 Nov 2015 13:09:58 -0500 Date: Mon, 09 Nov 2015 13:09:53 -0500 From: John C Klensin To: "Henry S. Thompson" , Keith Moore Message-ID: In-Reply-To: References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 18:10:15 -0000 --On Monday, November 09, 2015 12:25 +0000 "Henry S. Thompson" wrote: > Keith Moore writes: > >> I also agree that semantics of an f-component with a URN that >> is resolved for the purpose of other than obtaining "content" >> is currently undefined. I am not sure whether it should >> remain undefined, be declared inappropriate, or be declared >> an error to use f-component in this way. > > On the one hand, neither server nor client can know what a > user's purpose is in attempting to resolve a URN. > > On the other hand I think it follows from my earlier response > that if a server is configured so as not to respond with > "content", i.e. with a response status code of other than 200, > then (modulo some subtleties to do with 301 and 302 responses) > the point is moot: there is no content, so the f-component is > irrelevant and, of necessity, ignored. Henry, I think I agree -- the observation that I'm not sure is symptomatic of some of the problems here-- but find two other sources of confusion in your, and Sean's, analysis. While I obviously accept the importance of processing of HTML (or XML) and interpretation and response codes in HTTP, I think that trying to bind URNs (or, by the way, even RFC 3986) to those functions, implying that they are the only plausible representations or use contexts is a serious mistake. The fact that we've already got, e.g., XMPP URNs that are interpreted by different protocols and used by them in different ways than would be the case in an HTTP context is one of many indications that URNs (or URIs generally) are not just for the web or just to be defined in web-ish terms. So, as soon as you (or others) start talking about, e.g., HTTP response codes being definitive, I neither agree nor disagree; I just think you are carrying out a conversation that is of little interest to me in the context of this WG. This is, perhaps, a generalization or different version of some of what Keith has been saying, but I would go well beyond "client is not necessarily an interactive web browser, and can potentially be any application that uses URIs". For example, I would have said "potentially be any application that uses URNs" because, while 3986 can be interpreted as saying that any application that accepts URIs must be able to accept URNs and do something sensible, I am aware of nothing (in 2141bis or elsewhere) that requires that any application that can accept URNs be able to accept and process generalized URIs. To go a step further, we've heard (and I think the WG has largely accepted although I'm not trying to make a consensus call) that the language of 3986 relative to fragments takes the syntax and interpretation of them out of the hands of any scheme. If we were to interpret that as narrowly as possible, 2141bis should say absolutely nothing about f-components (perhaps even avoid the term) and deal with fragments by pointing to 3986, leaving it to that document to sort out what they mean and how they are interpreted, especially in situations where there is no media (content)-type or other framework for interpretation. I would further note that a narrow reading of 3986 probably doesn't even permit a URN processor to isolate an f-component and concatenate it with a URL that it the target of that URN because, when the "urn:" scheme is processed, if the URNs resolves to a URL, URLs are not bound to a media type. One can get there, but only by interpreting "secondary resource" from the first paragraph of Section 3.5 of RFC 3986 (and subsequent paragraphs) as including "tertiary resources and deeper recursion" as equivalent to it and ignoring parts of the second paragraph. Again, if any of this should lead to changes in 2141bis, particularly if anyone would like the current discussion of f-components and their sometimes-odd relationships to URNs that never leave to resolution to anything that has a media type expanded, please send text or otherwise be very specific. john From nobody Mon Nov 9 10:35:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E88C1B8100 for ; Mon, 9 Nov 2015 10:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr3ixFj8Z6Zb for ; Mon, 9 Nov 2015 10:34:57 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA501B80FD for ; Mon, 9 Nov 2015 10:34:57 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZvrHJ-000ExI-QV; Mon, 09 Nov 2015 13:34:53 -0500 Date: Mon, 09 Nov 2015 13:34:48 -0500 From: John C Klensin To: Keith Moore , "Henry S. Thompson" Message-ID: <963F20F514B251D89F7DB9D9@JcK-HP8200.jck.com> In-Reply-To: <564094D5.6050909@network-heretics.com> References: <56401F87.3030109@seantek.com> <5640913C.2000005@network-heretics.com> <564094D5.6050909@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 18:34:59 -0000 Apologies for not picking this up in my prior note, but... --On Monday, November 09, 2015 07:43 -0500 Keith Moore wrote: > On 11/09/2015 07:38 AM, Henry S. Thompson wrote: >>> > Note that since a URL fragment is specific to a particular >>> > kind of content-type, specifying an f-component of a URN >>> > (or fragment of a URL) that exists in multiple >>> > content-types isn't terribly useful without including some >>> > way to constrain the content-type obtained. >> 3986 attempts to address this by saying that it is the >> owner/server's responsibility in such cases, in particular if >> content negotiation is involved, to ensure that the fragment >> involved applies to_all_ the potentially-returned content >> types. . . > This is, of course, a sign of delusion. I don't want to go quite that far, but, if a particular URN in a particular namespace can return -- based on usage context, r-component contents, or other information-- both information objects that are associated with media types and information that is not associated with media types, then meeting that condition is impossible (at least without a lot of handwaving). As an example, consider urn:ietf:rfc:3986 and assume the definition is expanded to include r-components and fragments. Now: urn:ietf:rfc:3986#Section-3.5 is valid and meaningful independent of whether what comes back on HTTP-style resolution is the text form of the RFC or the PDF form. If the text of 3986 that doesn't permit schemes to limit the use of fragments applies, then it is valid even under 2141 (without any 2141bis) requirements. However, if that URN resolves to whatever http://www.rfc-editor.org/info/rfc3986 produces, that page has a media-type (presumably connected to HTML), but that media type isn't either text/plain or application/pdf. More important, while the fragment is "valid" because HTML allows fragments, there is no "Section-3.5" on that page: to get to something that has such a section, the compound/aggregate/possibly-recursive resolver has to somehow have the intelligence to move beyond the "secondary resource" (that page) and resolve some HTTP or HTTPS link that leads somewhere for which a second number is meaningful. And, as suggested in my prior note, if the "result" of resolving urn:ietf:rfc:3986 (with or without the fragment) is actually http://www.rfc-editor.org/info/rfc3986 then that "secondary resource" is a perfectly good URI, but URIs are not generally considered to have media types. To me, all of the above suggests even more strongly that 2141bis should say as little about fragments as possible. I'm ok with what now appears in Section 3.3 of 2141bis-14 as long as I don't look at it too closely and, e.g., realize that "the f-component is copied verbatim to the fragment portion of the URL" probably violates the provisions of 3986 that appear to require knowledge of a media type to do _anything_ with a fragment. If it is necessary to say something else, including trying to more carefully align that paragraph with 3986, then I suggest that it may be prerequisite to get firm and clear definitions to a lot of the issues and terminology suggested above and by my prior note in this thread. Again, send text. john From nobody Mon Nov 9 20:48:03 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B991B32CE for ; Mon, 9 Nov 2015 20:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DI6s8Q0TpTt for ; Mon, 9 Nov 2015 20:48:00 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251B51B32CF for ; Mon, 9 Nov 2015 20:47:59 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 87770201FD for ; Mon, 9 Nov 2015 23:47:58 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 09 Nov 2015 23:47:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=svOjpxRMCj80XWI 3QYakyle+3TY=; b=YLMPIcKbB4/DWOeGqmCDHKXvRYaGyjNEMmcnA4MXzSPli0N wNIn3OtfKc+Zd/4QAXkPTdP7Bo8SZ5Q7FwVUwhz4iz3LoBFaXeWi1caTQ8XOuKs8 PhyCMlb0/eauf5yrNPoN40PxVQgSBVcn0l4B9uXxTce67xxg/iKuT1rK3CI0= X-Sasl-enc: aeXrDH/DDoOmB20UeiOW+Oq9LE2JLTeDOpp2PJv/uRwi 1447130878 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 08D49680147; Mon, 9 Nov 2015 23:47:57 -0500 (EST) To: John C Klensin , "Henry S. Thompson" References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> From: Keith Moore Message-ID: <564176F3.60508@network-heretics.com> Date: Mon, 9 Nov 2015 23:47:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 04:48:02 -0000 On 11/09/2015 01:09 PM, John C Klensin wrote: > > --On Monday, November 09, 2015 12:25 +0000 "Henry S. Thompson" > wrote: > >> Keith Moore writes: >> >>> I also agree that semantics of an f-component with a URN that >>> is resolved for the purpose of other than obtaining "content" >>> is currently undefined. I am not sure whether it should >>> remain undefined, be declared inappropriate, or be declared >>> an error to use f-component in this way. >> On the one hand, neither server nor client can know what a >> user's purpose is in attempting to resolve a URN. >> >> On the other hand I think it follows from my earlier response >> that if a server is configured so as not to respond with >> "content", i.e. with a response status code of other than 200, >> then (modulo some subtleties to do with 301 and 302 responses) >> the point is moot: there is no content, so the f-component is >> irrelevant and, of necessity, ignored. > Henry, > > I think I agree -- the observation that I'm not sure is > symptomatic of some of the problems here-- but find two other > sources of confusion in your, and Sean's, analysis. While I > obviously accept the importance of processing of HTML (or XML) > and interpretation and response codes in HTTP, I think that > trying to bind URNs (or, by the way, even RFC 3986) to those > functions, implying that they are the only plausible > representations or use contexts is a serious mistake. Assuming I understand what John is saying, I agree. I'm not adverse to using HTTP as a URN resolution protocol, nor am I adverse to using existing HTTP protocol features (including redirects, result codes, and content-negotiation) where they make sense. But I think it would be a serious mistake to insist that URN resolution protocol features be shoehorned into HTTP protocol features, and an even worse mistake to insist that a profile of HTTP be the only URN resolution protocol. > The fact > that we've already got, e.g., XMPP URNs that are interpreted by > different protocols and used by them in different ways than > would be the case in an HTTP context is one of many indications > that URNs (or URIs generally) are not just for the web or just > to be defined in web-ish terms. It would be good to collect some of these examples as use cases, just so that we don't implicitly think of a single use case of URNs. URNs aren't inherently persistent links in web documents (even though this was perhaps what most motivated their creation), nor inherently unique IDs that aren't bound to anything in particular (even if this is perhaps the use case that is visible to the largest number of users or IETF participants), nor inherently reserved for fixed media (even if perhaps the majority of URNs have been assigned for such purposes). A URN can be any of these. And a single namespace can potentially contain URNs from all of these categories. > This is, perhaps, a generalization or different version of some > of what Keith has been saying, but I would go well beyond > "client is not necessarily an interactive web browser, and can > potentially be any application that uses URIs". For example, I > would have said "potentially be any application that uses URNs" > because, while 3986 can be interpreted as saying that any > application that accepts URIs must be able to accept URNs and do > something sensible, I am aware of nothing (in 2141bis or > elsewhere) that requires that any application that can accept > URNs be able to accept and process generalized URIs. Agree. > To go a step further, we've heard (and I think the WG has > largely accepted although I'm not trying to make a consensus > call) that the language of 3986 relative to fragments takes the > syntax and interpretation of them out of the hands of any > scheme. Also agree. > If we were to interpret that as narrowly as possible, > 2141bis should say absolutely nothing about f-components > (perhaps even avoid the term) and deal with fragments by > pointing to 3986, leaving it to that document to sort out what > they mean and how they are interpreted, especially in situations > where there is no media (content)-type or other framework for > interpretation. I find it very useful to have different terms for f-component and fragment even though the f-component should map directly onto a fragment (and similarly for q-component and query). Making a clear distinction between the two seems to make it easier to write clear text. I also find that 3986 is confusingly written enough, especially where it addresses the topic of URNs or tries to shoehorn URNs into its assumptions, that I believe it's necessary for 2141bis to clarify some things - even though 2141bis tries to adhere to the spirit of 3986 as much as is reasonable. > I would further note that a narrow reading of > 3986 probably doesn't even permit a URN processor to isolate an > f-component and concatenate it with a URL that it the target of > that URN because, when the "urn:" scheme is processed, if the > URNs resolves to a URL, URLs are not bound to a media type. By that reasoning, fragments shouldn't be used with URLs either. Given the way fragments were defined in an ad hoc manner on a per-media-type basis, and especially that some fragments aren't defined in terms of explicit markers in the resource, I have never believed that one could expect fragment meaning to be invariant across content-negotiation. If one insists on this constraint, it essentially means that a resource can exist in only one media format. Also, I don't see that URNs and URN resolution make this any worse than it already is in HTTP. Keith From nobody Tue Nov 10 02:04:38 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB9B1B35C9 for ; Tue, 10 Nov 2015 02:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jca7vS49Ww9U for ; Tue, 10 Nov 2015 02:04:30 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1A31B35C7 for ; Tue, 10 Nov 2015 02:04:30 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Zw5mr-000HqS-Tx; Tue, 10 Nov 2015 05:04:25 -0500 Date: Tue, 10 Nov 2015 05:04:20 -0500 From: John C Klensin To: Keith Moore , "Henry S. Thompson" Message-ID: <34C92E53466C3AF7CD2C5CB7@JcK-HP8200.jck.com> In-Reply-To: <564176F3.60508@network-heretics.com> References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> <564176F3.60508@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 10:04:37 -0000 --On Monday, November 09, 2015 23:47 -0500 Keith Moore wrote: >... >> If we were to interpret that as narrowly as possible, >> 2141bis should say absolutely nothing about f-components >> (perhaps even avoid the term) and deal with fragments by >> pointing to 3986, leaving it to that document to sort out what >> they mean and how they are interpreted, especially in >> situations where there is no media (content)-type or other >> framework for interpretation. > > I find it very useful to have different terms for f-component > and fragment even though the f-component should map directly > onto a fragment (and similarly for q-component and query). > Making a clear distinction between the two seems to make it > easier to write clear text. I also find that 3986 is > confusingly written enough, especially where it addresses the > topic of URNs or tries to shoehorn URNs into its assumptions, > that I believe it's necessary for 2141bis to clarify some > things - even though 2141bis tries to adhere to the spirit of > 3986 as much as is reasonable. Wfm. >> I would further note that a narrow reading of >> 3986 probably doesn't even permit a URN processor to isolate >> an f-component and concatenate it with a URL that it the >> target of that URN because, when the "urn:" scheme is >> processed, if the URNs resolves to a URL, URLs are not bound >> to a media type. > By that reasoning, fragments shouldn't be used with URLs > either. No, because the relevant discussion of fragments in 3986 talks about "primary" and "secondary" resources and seems, at least to me on my most recent reading, to be fairly clear about that they mean. If my reading of that material is correct, attaching a fragment to a URL, having a user agent use that URL to obtain a resource-object (one with a media type), and then using the fragment string to identify part of that resource-object works just fine and is exactly how things are defined. However, the text does not provide for having a resolver pass a fragment from one URI to another -- that operation would have to be done by a client and clients don't do anything with fragments other than apply them to objects that have media types. Since URLs are not objects, much less objects with media types, there is a disconnect. Now, to be clear, I think there are other ways to read 3986. One can assume that the discussion of primary and secondary resources and the use of the term "indirect referencing" implies that recursion is permitted (and assumed), potentially to arbitrary depth and that fragments, once "separated from the rest of the URI prior to a dereference", are somehow kept separate (including not being processed other than parsing by any generic resolver) until a final object is obtained and then applied, by the user agent, to the object. But I think that making any sort of strong claim that the 3986 fragment text (primarily Section 3.5) requires any particular behavior of URNs, such as either requiring that they resolve to URLs or that a URN processor peel off the fragment component and catenate it with the URLs that are produced is, well, a stretch. > Given the way fragments were defined in an ad hoc manner on a > per-media-type basis, and especially that some fragments > aren't defined in terms of explicit markers in the resource, I > have never believed that one could expect fragment meaning to > be invariant across content-negotiation. If one insists on > this constraint, it essentially means that a resource can > exist in only one media format. I think that is correct. Coming back to the example used above, the language of Section 3.5 clearly allows a URI-author to construct urn:ietf:rfc:3986#Page-24 despite years of warnings by the RFC Editor against basing citations on page numbers. While the "chapter" reference above clearly works with text and PDF objects, if an HTML object, or one optimized for some sort of electronic reader, is retrieved, there may be no page numbers and the fragment may become meaningless. > Also, I don't see that URNs and URN resolution make this any > worse than it already is in HTTP. By specifying a specific location for an object, an HTTP URL does not create some sort of choice mechanism on resolution. One may reasonably argue non-persistence, but I'm not sure that changes the expectation of retrieving an object that has a media type. best, john From nobody Tue Nov 10 02:13:12 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810261B3600 for ; Tue, 10 Nov 2015 02:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jw0Z61J9eWL for ; Tue, 10 Nov 2015 02:13:08 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED31B35FE for ; Tue, 10 Nov 2015 02:13:06 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tAAACePY001068; Tue, 10 Nov 2015 10:12:46 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tAAACbok020993; Tue, 10 Nov 2015 10:12:38 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tAAACcPK026707; Tue, 10 Nov 2015 10:12:38 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tAAACabL026706; Tue, 10 Nov 2015 10:12:36 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 10 Nov 2015 10:12:36 +0000 In-Reply-To: (John C. Klensin's message of "Mon\, 09 Nov 2015 13\:09\:53 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 10:13:11 -0000 John C Klensin writes: > --On Monday, November 09, 2015 12:25 +0000 "Henry S. Thompson" > wrote: > >> Keith Moore writes: >> >>> I also agree that semantics of an f-component with a URN that >>> is resolved for the purpose of other than obtaining "content" >>> is currently undefined. I am not sure whether it should >>> remain undefined, be declared inappropriate, or be declared >>> an error to use f-component in this way. >> >> On the one hand, neither server nor client can know what a >> user's purpose is in attempting to resolve a URN. >> >> On the other hand I think it follows from my earlier response >> that if a server is configured so as not to respond with >> "content", i.e. with a response status code of other than 200, >> then (modulo some subtleties to do with 301 and 302 responses) >> the point is moot: there is no content, so the f-component is >> irrelevant and, of necessity, ignored. > > I think I agree -- the observation that I'm not sure is > symptomatic of some of the problems here-- but find two other > sources of confusion in your, and Sean's, analysis. While I > obviously accept the importance of processing of HTML (or XML) > and interpretation and response codes in HTTP, I think that > trying to bind URNs (or, by the way, even RFC 3986) to those > functions, implying that they are the only plausible > representations or use contexts is a serious mistake. Of course. I entirely agree, and in a previous life spent rather a lot of energy and political capital trying to keep the Internet safe for user agents other than web browsers, ditto the use of URIs outside HTTP. > The fact that we've already got, e.g., XMPP URNs that are interpreted > by different protocols and used by them in different ways than would > be the case in an HTTP context is one of many indications that URNs > (or URIs generally) are not just for the web or just to be defined in > web-ish terms. > > So, as soon as you (or others) start talking about, e.g., HTTP > response codes being definitive, I neither agree nor disagree; I > just think you are carrying out a conversation that is of little > interest to me in the context of this WG. That's too bad, because I think the _architectural_ points of my two replies to Andy transcend the particular example of HTTP. As soon as we're in the request/response, message exchange, _protocol_ space at all (and that's precisely how Andy framed his queries), questions of data vs. metadata, content vs. protocol element and so on arise. That 3986 depends on the representation/resource distinction for what it says about the semantics of '#' is clear. It follows that for a client (in _any_ protocol-governed exchange), knowing whether the response it gets to some request is content or not (error/metadata/forwarding information/...) is essential to its ability to correctly use a fragment. So of course HTTP response codes are only definitive for HTTP-governed exchanges, but any _other_ protocol must have an equivalent mechanism. > To go a step further, we've heard (and I think the WG has > largely accepted although I'm not trying to make a consensus > call) that the language of 3986 relative to fragments takes the > syntax and interpretation of them out of the hands of any > scheme. For in-principle resolvable URIs, yes. > If we were to interpret that as narrowly as possible, > 2141bis should say absolutely nothing about f-components > (perhaps even avoid the term) and deal with fragments by > pointing to 3986, leaving it to that document to sort out what > they mean and how they are interpreted, especially in situations > where there is no media (content)-type or other framework for > interpretation. I would further note that a narrow reading of > 3986 probably doesn't even permit a URN processor to isolate an > f-component and concatenate it with a URL that it the target of > that URN because, when the "urn:" scheme is processed, if the > URNs resolves to a URL, URLs are not bound to a media type. Depends in part on how useful you think the HTTP model is. What Keith and I were agreeing on is that insofar as the f-component is treated as HTTP treats fragments, then the client won't even _send_ the fragment to the URN processor, so no question of concatenation or anything like it arises. I know that 3986 doesn't say this, and given that urnbis is not explicitly addressing protocols (which I think we agree it shouldn't, any more than 3986 does), this is _all_ just about what doors we leave open versus what we shut. Specifically, that generic URI processing via HTTP or anything similar that strips f-components before attempting resolution MUST NOT be _ipso facto_ in conflict with urnbis. > Again, if any of this should lead to changes in 2141bis, > particularly if anyone would like the current discussion of > f-components and their sometimes-odd relationships to URNs that > never leave to resolution to anything that has a media type > expanded, please send text or otherwise be very specific. For my money, this case (unlike the q-component case) is just violent agreement on all sides. So no, no changes required. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue Nov 10 03:00:45 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B531A8A0E for ; Tue, 10 Nov 2015 03:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBy5_QJ_3gVK for ; Tue, 10 Nov 2015 03:00:40 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 278D21A8A1B for ; Tue, 10 Nov 2015 03:00:39 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tAAB0JUH005338; Tue, 10 Nov 2015 11:00:24 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tAAB0HGS023994; Tue, 10 Nov 2015 11:00:17 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tAAB0IfI028571; Tue, 10 Nov 2015 11:00:18 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tAAB0IdG028568; Tue, 10 Nov 2015 11:00:18 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <56401F87.3030109@seantek.com> <5640913C.2000005@network-heretics.com> <564094D5.6050909@network-heretics.com> <963F20F514B251D89F7DB9D9@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 10 Nov 2015 11:00:18 +0000 In-Reply-To: <963F20F514B251D89F7DB9D9@JcK-HP8200.jck.com> (John C. Klensin's message of "Mon\, 09 Nov 2015 13\:34\:48 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 11:00:43 -0000 John C Klensin writes: > Apologies for not picking this up in my prior note, but... > > --On Monday, November 09, 2015 07:43 -0500 Keith Moore > wrote: > >> On 11/09/2015 07:38 AM, Henry S. Thompson wrote: >>>> > Note that since a URL fragment is specific to a particular >>>> > kind of content-type, specifying an f-component of a URN >>>> > (or fragment of a URL) that exists in multiple >>>> > content-types isn't terribly useful without including some >>>> > way to constrain the content-type obtained. > >>> 3986 attempts to address this by saying that it is the >>> owner/server's responsibility in such cases, in particular if >>> content negotiation is involved, to ensure that the fragment >>> involved applies to_all_ the potentially-returned content >>> types. . . > >> This is, of course, a sign of delusion. > > I don't want to go quite that far, but, if a particular URN in a > particular namespace can return -- based on usage context, > r-component contents, or other information-- both information > objects that are associated with media types and information > that is not associated with media types, then meeting that > condition is impossible (at least without a lot of handwaving). > > As an example, consider > urn:ietf:rfc:3986 > > and assume the definition is expanded to include r-components > and fragments. Now: > urn:ietf:rfc:3986#Section-3.5 > > is valid and meaningful independent of whether what comes back > on HTTP-style resolution is the text form of the RFC or the PDF > form. If the text of 3986 that doesn't permit schemes to limit > the use of fragments applies, then it is valid even under 2141 > (without any 2141bis) requirements. However, if that URN > resolves to whatever > http://www.rfc-editor.org/info/rfc3986 > > produces, that page has a media-type (presumably connected to > HTML), but that media type isn't either text/plain or > application/pdf. This is precisely the kind of example I was trying to get specific about with my discussion of HTTP response status codes. If whoever resolves that request signals (with an HTTP response status code of 200 _or in any other way_) that the response body (or whatever corresponds to that) is a representation of the resource identified by "urn:ietf:rfc:3986", then its inviting a client to interpret the f-component wrt that text/html response, and that resolver is broken. Because the response I get today to a request for is _not_ a representation of that RFC, it's a bunch of useful, interesting, IETF status information regarding that RFC. My view is that however your postulated resolver behaves, it should _either_ be responding to the client as to how it can redirect from to , in a way that makes clear that what it will find there is _not_ the thing itself, but a source of metadata (what HTTP would use 303 "See Other" for), or, if it does the HTTP retrieval itself, return the resulting landing page representation packaged in a way that similarly indicates that it's not the RFC itself). > To me, all of the above suggests even more strongly that 2141bis > should say as little about fragments as possible. Still violent agreement! > I'm ok with what now appears in Section 3.3 of 2141bis-14 as long as I > don't look at it too closely and, e.g., realize that "the f-component > is copied verbatim to the fragment portion of the URL" probably > violates the provisions of 3986 that appear to require knowledge of a > media type to do _anything_ with a fragment. Interesting -- I read that as implicitly about what _clients_ do, particularly given the immediately preceding "The f-component is intended to be interpreted _by the client_" (emphasis added).n That is, I read the bit you quote above as equivalent to "the f-component is treated by the client as if it were an f-component of the URL". In particular, I don't see anything there that implies that the _resolver_ has done anything at all with the f-component, or even seen it. > If it is necessary to say something else, including trying to more > carefully align that paragraph with 3986, then I suggest that it may > be prerequisite to get firm and clear definitions to a lot of the > issues and terminology suggested above and by my prior note in this > thread. Again, send text. Hmm. I see that the quoted phrase actually occurs twice, once in the 3.3 introduction, and once in 3.3.3. Sigh. On re-reading all of 3.3, I'm concerned that the procedural language takes us into dangerous territory. In particular, it fails to recognise in any way the distinction which HTTP makes with (200, 301 or 302) versus (303), that is, the distinction between (representations of) the requested resource, and (representations of) relevant information _about_ that resource, but not it. As you say above, that means treating a landing page as if it were the thing itself, which makes life difficult in more ways than just f-component processing. Less is more. I need to think more about how to manage this -- given that we surely _don't_ want to start talking about protocols, or (less surely?) expanding the discussion of resolution to distinguish between what one might call 'indirect' vs. 'direct' resolution (here's a locator for what you asked for vs. here's what you asked for), exactly how to best define the relationship of f- (and q-) components to the results of resolution isn't obvious at all. But talking explicitly about concatenation seems to carry way too many assumptions about resolution to be the right answer. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue Nov 10 03:02:25 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161601A8A25 for ; Tue, 10 Nov 2015 03:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA3-CdpkB6-J for ; Tue, 10 Nov 2015 03:02:22 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 196351A8A3E for ; Tue, 10 Nov 2015 03:02:20 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tAAB2Ku3006402; Tue, 10 Nov 2015 11:02:20 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tAAB2Iwf024094; Tue, 10 Nov 2015 11:02:18 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tAAB2JVU028684; Tue, 10 Nov 2015 11:02:19 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tAAB2J3o028683; Tue, 10 Nov 2015 11:02:19 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Keith Moore References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> <564176F3.60508@network-heretics.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 10 Nov 2015 11:02:19 +0000 In-Reply-To: <564176F3.60508@network-heretics.com> (Keith Moore's message of "Mon\, 9 Nov 2015 23\:47\:47 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 11:02:23 -0000 Keith Moore writes: > Assuming I understand what John is saying, I agree. I'm not adverse > to using HTTP as a URN resolution protocol, nor am I adverse to using > existing HTTP protocol features (including redirects, result codes, > and content-negotiation) where they make sense. But I think it would > be a serious mistake to insist that URN resolution protocol features > be shoehorned into HTTP protocol features, and an even worse mistake > to insist that a profile of HTTP be the only URN resolution protocol. Lest there be any residual doubt about this, I agree 100% ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue Nov 10 03:29:12 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDBA1B36FB for ; Tue, 10 Nov 2015 03:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvXAQcM1egtA for ; Tue, 10 Nov 2015 03:29:08 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id B83A51B36F7 for ; Tue, 10 Nov 2015 03:29:07 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id tAABT5Ht024749; Tue, 10 Nov 2015 11:29:05 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id tAABT3dL025769; Tue, 10 Nov 2015 11:29:03 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id tAABT5CP029964; Tue, 10 Nov 2015 11:29:05 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id tAABT463029962; Tue, 10 Nov 2015 11:29:04 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> <564176F3.60508@network-heretics.com> <34C92E53466C3AF7CD2C5CB7@JcK-HP8200.jck.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 10 Nov 2015 11:29:04 +0000 In-Reply-To: <34C92E53466C3AF7CD2C5CB7@JcK-HP8200.jck.com> (John C. Klensin's message of "Tue\, 10 Nov 2015 05\:04\:20 -0500") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 11:29:12 -0000 John C Klensin writes: > Now, to be clear, I think there are other ways to read 3986. > One can assume that the discussion of primary and secondary > resources and the use of the term "indirect referencing" implies > that recursion is permitted (and assumed), potentially to > arbitrary depth and that fragments, once "separated from the > rest of the URI prior to a dereference", are somehow kept > separate (including not being processed other than parsing by > any generic resolver) until a final object is obtained and then > applied, by the user agent, to the object. That's certainly how the HTTP specs call for fragments to be interepreted. It's moderately important (to me!) that if you type http://www.w3.org/TR/REC-xml.html#sec-xml-wg into a web browser or pass it to the Python or Java HTTP libraries that the fragment is first removed, the resulting URI resolved, then the resulting redirection Location resolved, and _then_ the fragment semantics implemented. > But I think that making any sort of strong claim that the 3986 > fragment text (primarily Section 3.5) requires any particular > behavior of URNs, such as either requiring that they resolve to > URLs or that a URN processor peel off the fragment component and > catenate it with the URLs that are produced is, well, a stretch. Agreed. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue Nov 10 05:44:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CDB1ACF24 for ; Tue, 10 Nov 2015 05:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTNXrjGPJycU for ; Tue, 10 Nov 2015 05:44:49 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B971ACF1D for ; Tue, 10 Nov 2015 05:44:48 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Zw9E4-000IG9-FU; Tue, 10 Nov 2015 08:44:44 -0500 Date: Tue, 10 Nov 2015 08:44:39 -0500 From: John C Klensin To: "Henry S. Thompson" Message-ID: <044660EA8177D010F3D90113@JcK-HP8200.jck.com> In-Reply-To: References: <56401F87.3030109@seantek.com> <5640913C.2000005@network-heretics.com> <564094D5.6050909@network-heretics.com> <963F20F514B251D89F7DB9D9@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 13:44:51 -0000 --On Tuesday, November 10, 2015 11:00 +0000 "Henry S. Thompson" wrote: >... >> As an example, consider >> urn:ietf:rfc:3986 >> >> and assume the definition is expanded to include r-components >> and fragments. Now: >> urn:ietf:rfc:3986#Section-3.5 >... > This is precisely the kind of example I was trying to get > specific about with my discussion of HTTP response status > codes. If whoever resolves that request signals (with an HTTP > response status code of 200 _or in any other way_) that the > response body (or whatever corresponds to that) is a > representation of the resource identified by > "urn:ietf:rfc:3986", then its inviting a client to interpret > the f-component wrt that text/html response, and that resolver > is broken. Ok, but... > Because the response I get today to a request for > is _not_ a > representation of that RFC, it's a bunch of useful, > interesting, IETF status information regarding that RFC. My > view is that however your postulated resolver behaves, it > should _either_ be responding to the client as to how it can > redirect from to > , in a way that makes > clear that what it will find there is _not_ the thing itself, > but a source of metadata (what HTTP would use 303 "See Other" > for), or, if it does the HTTP retrieval itself, return the > resulting landing page representation packaged in a way that > similarly indicates that it's not the RFC itself). However, and here is where your thinking and explanation get HTTP-specific because there is no 3986 requirement for a redirect function and that function is, indeed, rare for many or most of the protocols for which URIs have been standardized. There are other issues embedded in that example that may be worth some thought: First, for many years, any possible resolver for would point to ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt. That requires a two-stage resolution to get to an object (rather than descriptive material) and, while the object would work perfectly well with a "Section"-style fragment, but the FTP protocol (and "ftp" URI scheme) do not identify or return media types, so the fragment cannot be applied by the FTP client. Second, if anyone wants to pin down "persistence", they need to consider whether the change from resolution to an FTP URL that points to an object to resolution to an HTTP URL that points to a description that, in turn, contains multiple links to objects is reasonable or fundamentally undermines whatever we mean by persistence. >> To me, all of the above suggests even more strongly that >> 2141bis should say as little about fragments as possible. > > Still violent agreement! > >> I'm ok with what now appears in Section 3.3 of 2141bis-14 as >> long as I don't look at it too closely and, e.g., realize >> that "the f-component is copied verbatim to the fragment >> portion of the URL" probably violates the provisions of 3986 >> that appear to require knowledge of a media type to do >> _anything_ with a fragment. > > Interesting -- I read that as implicitly about what _clients_ > do, particularly given the immediately preceding "The > f-component is intended to be interpreted _by the client_" > (emphasis added). > That is, I read the bit you quote above as equivalent to "the > f-component is treated by the client as if it were an > f-component of the URL". In particular, I don't see anything > there that implies that the _resolver_ has done anything at > all with the f-component, or even seen it. And this is where the difference in conceptual models may make a difference, especially to the "universal URI resolver" or even "universal URN resolver" themes. Noting that I don't think anyone has a problem with a "universal URI parser" that merely divides a URI into components that are consistent with the symtax of 3986, suppose a program encounters something it identifies as a URI, one with an arbitrary scheme. Now it seems to me that there are two possibilities either of which is, in principle, compatible with 3986. (i) The client program contains code that recognizes the scheme and knows what to do with it, just as web browsers know what to do with http, https, ftp, and a handful of other schemes. If it doesn't know what to do (or if the scheme is a URN -- see below), then it either produces a "don't have a clue what to about about that scheme" error or has to go to the second option. (ii) The client program calls on a universal URI resolver that can figure out what to do with almost any scheme and return either an object, an error code, or an indication as to what to do next. Whether the client parses the URI, separates out any fragment for later use, and passes the rest of the URI to the universal resolver or whether it passes the entire URI string to the universal resolver, gets back the fragment as a separate piece of data structure and then applies it is a small matter of programming (and terminology) that really does not affect either standards-compliance or anything external to that client. Ok so far? However, URNs are different because, unlike, e.g., an http or ftp URL, they inherently are not self-contained: a lookup or resolution process has to involve the NID and NSS and there is no universal mechanism for getting from the NID to the relevant lookup or resolution process. That turns option (i) above into "recognize the scheme _and_ recognize the NID" and means that the universal resolver hypothesized under (ii) has to be a lot more sophisticated (and has to have a much more elaborate unexpected condition reporting structure) than we normally assume for URLs. >> If it is necessary to say something else, including trying to >> more carefully align that paragraph with 3986, then I suggest >> that it may be prerequisite to get firm and clear definitions >> to a lot of the issues and terminology suggested above and by >> my prior note in this thread. Again, send text. > > Hmm. I see that the quoted phrase actually occurs twice, once > in the 3.3 introduction, and once in 3.3.3. > > Sigh. On re-reading all of 3.3, I'm concerned that the > procedural language takes us into dangerous territory. In > particular, it fails to recognise in any way the distinction > which HTTP makes with (200, 301 or 302) versus (303), that is, > the distinction between (representations of) the requested > resource, and (representations of) relevant information > _about_ that resource, but not it. As you say above, that > means treating a landing page as if it were the thing itself, > which makes life difficult in more ways than just f-component > processing. Indeed. And although I believe the HTTP case is the easy one, that is why I'm trying to tease this out a bit more. > Less is more. I need to think more about how to manage this > -- given that we surely _don't_ want to start talking about > protocols, or (less surely?) expanding the discussion of > resolution to distinguish between what one might call > 'indirect' vs. 'direct' resolution (here's a locator for what > you asked for vs. here's what you asked for), exactly how to > best define the relationship of f- (and q-) components to the > results of resolution isn't obvious at all. But talking > explicitly about concatenation seems to carry way too many > assumptions about resolution to be the right answer. Agreed. I look forward to proposed text. john From nobody Tue Nov 10 05:48:43 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23291AD06F for ; Tue, 10 Nov 2015 05:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp7R60bRzKSa for ; Tue, 10 Nov 2015 05:48:39 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB6E1AD06D for ; Tue, 10 Nov 2015 05:48:39 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Zw9Hp-000IGO-AB; Tue, 10 Nov 2015 08:48:37 -0500 Date: Tue, 10 Nov 2015 08:48:32 -0500 From: John C Klensin To: "Henry S. Thompson" Message-ID: <9EEAF5C480E0B1DEF24CF379@JcK-HP8200.jck.com> In-Reply-To: References: <56401F87.3030109@seantek.com> <56408E2F.9040703@network-heretics.com> <564176F3.60508@network-heretics.com> <34C92E53466C3AF7CD2C5CB7@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] implementing f-components, consensus check X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 13:48:41 -0000 --On Tuesday, November 10, 2015 11:29 +0000 "Henry S. Thompson" wrote: > John C Klensin writes: > >> Now, to be clear, I think there are other ways to read 3986. >> One can assume that the discussion of primary and secondary >> resources and the use of the term "indirect referencing" >> implies that recursion is permitted (and assumed), >> potentially to arbitrary depth and that fragments, once >> "separated from the rest of the URI prior to a dereference", >> are somehow kept separate (including not being processed >> other than parsing by any generic resolver) until a final >> object is obtained and then applied, by the user agent, to >> the object. > > That's certainly how the HTTP specs call for fragments to be > interepreted. It's moderately important (to me!) that if you > type > > http://www.w3.org/TR/REC-xml.html#sec-xml-wg > > into a web browser or pass it to the Python or Java HTTP > libraries that the fragment is first removed, the resulting > URI resolved, then the resulting redirection Location > resolved, and _then_ the fragment semantics implemented. And no one has questioned the appropriateness of the HTTP specs --or any other spec of the "locator" family-- to be written that way. >> But I think that making any sort of strong claim that the 3986 >> fragment text (primarily Section 3.5) requires any particular >> behavior of URNs, such as either requiring that they resolve >> to URLs or that a URN processor peel off the fragment >> component and catenate it with the URLs that are produced is, >> well, a stretch. > > Agreed. Yep. Again, the question is to how to tune the 2141bis text to match what we seem to be agreeing on... and being sure that agreement reflects WG consensus. john From nobody Mon Nov 16 13:11:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A21B3190 for ; Mon, 16 Nov 2015 13:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0IXzr9MZiUb for ; Mon, 16 Nov 2015 13:11:25 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931FC1B318A for ; Mon, 16 Nov 2015 13:11:23 -0800 (PST) Received: from [192.168.123.105] (unknown [75.83.2.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 25AB5509C2 for ; Mon, 16 Nov 2015 16:11:20 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_D5351720-8BAC-4EA1-854C-17DA4C1CBE11"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Mon, 16 Nov 2015 13:09:59 -0800 To: urn@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 21:11:33 -0000 --Apple-Mail=_D5351720-8BAC-4EA1-854C-17DA4C1CBE11 Content-Type: multipart/mixed; boundary="Apple-Mail=_8F2B2ABD-90CF-4F2C-98EF-3527EAC94AF1" --Apple-Mail=_8F2B2ABD-90CF-4F2C-98EF-3527EAC94AF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 URNies: Please find a revision of urnbis-rfc2141bis attached (if these = attachments get accepted), which you can refer to as the =9314-seantek=94 = (or =9314s=94) revision. I used the XML version posted directly on = ietf.org and edited that. I am also including the output of rfcdiff. This is what I want to see added to the draft, based on discussions over = the last ~4 to 6 months. People (notably the chairs) have been asking to = =93send text=94 so here is the text. Key points: * (informative) resolution-to-resources model discussed, illustrating = interaction of assigned-name, r-component, q-component, f-component * fixed the ambiguity between q-component and r-component * r-component syntax and semantics defined * a variety of small editorial fixes * updated text/uri-list registration * fixed and improved ABNF Please: read the text before commenting on these points. If you don=92t = like the direction, take it up with the text, and *send different text*. Thank you and I look forward to productive discussion. Kind regards, Sean PS If you want to use rfcdiff , use = this URL for the text source: = https://dl.dropboxusercontent.com/content_link/mi4xwZzmQgkdmK94enMHvod9pto= SUPOpnRBgATxa9iYoAWNiB1TBoSZuWYy9NsgR/file PPS I also have a brainstorming scratch text file where I put extensive = notes on why and how the syntax is derived to be as it is in the = 14-seantek draft. If people want to see it I can send it or paste it in. = Symbols were carefully chosen to eliminate ambiguity, ease parsing, = maximize compatibility, and maintain compatibility with existing APIs. --Apple-Mail=_8F2B2ABD-90CF-4F2C-98EF-3527EAC94AF1 Content-Disposition: attachment; filename=draft-ietf-urnbis-rfc2141bis-urn-14-seantek.xml Content-Type: application/xml; name="draft-ietf-urnbis-rfc2141bis-urn-14-seantek.xml" Content-Transfer-Encoding: quoted-printable =0A=0A=20=20=20=20=20]>=0A=0A= =0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=20=0A=0A=20=20= =0A=0A=20=20=20=20Uniform=20Resource=20= Names=20(URNs)=0A=0A=20=20=20=20=0A=20=20=20=20= =20=20&yet=0A=20=20=20=20=20=20=
=0A=20=20=20=20=20=20=20=20peter@andyet.com=0A=20= =20=20=20=20=20=20=20https://andyet.com/=0A=20=20=20=20=20=20=
=0A=20=20=20=20=0A=0A=20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=
=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =201770=20Massachusetts=20Ave,=20Ste=20322=0A=20=20=20=20= =20=20=20=20=20=20Cambridge=0A=20=20=20=20=20=20=20=20=20=20= MA=0A=20=20=20=20=20=20=20=20=20=2002140=0A= =20=20=20=20=20=20=20=20=20=20USA=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20+1=20617=20245=20= 1457=0A=20=20=20=20=20=20=20=20john-ietf@jck.com=0A= =20=20=20=20=20=20
=0A=20=20=20=20=0A=0A=20=20=20=20= =0A=0A=20=20=20=20Applications=0A=20=20=20=20= URNBIS=0A=20=20=20=20Uniform=20Resource=20= Name=0A=20=20=20=20URN=0A=20=20=20=20= Uniform=20Resource=20Identifier=0A=20=20=20=20= URI=0A=0A=20=20=20=20=0A=20=20=20=20=20=20= A=20Uniform=20Resource=20Name=20(URN)=20is=20a=20Uniform=20Resource=20= Identifier=20(URI)=20that=20is=20assigned=20under=20the=20"urn"=20scheme=20= and=20a=20particular=20URN=20namespace,=20with=20the=20intent=20that=20= the=20URN=20will=20be=20either=20a=20persistent,=20location-independent=20= resource=20identifier=20or=20in=20some=20cases=20an=20abstract=20= designator=20that=20is=20persistent=20but=20that=20does=20not=20identify=20= a=20resource.=20=20With=20regard=20to=20URN=20syntax,=20this=20document=20= defines=20the=20canonical=20syntax=20for=20URNs=20(in=20a=20way=20that=20= is=20consistent=20with=20URI=20syntax),=20specifies=20methods=20for=20= determining=20URN=20equivalence,=20and=20discusses=20URI=20conformance.=20= =20With=20regard=20to=20URN=20namespaces,=20this=20document=20specifies=20= a=20method=20for=20defining=20a=20URN=20namespace=20and=20associating=20= it=20with=20a=20namespace=20identifier,=20and=20describes=20procedures=20= for=20registering=20namespace=20identifiers=20with=20the=20Internet=20= Assigned=20Numbers=20Authority=20(IANA).=20=20This=20document=20= obsoletes=20both=20RFC=202141=20and=20RFC=203406.=0A=20=20=20=20= =0A=0A=20=20=0A=0A=20=20=0A=0A=20=20=20=20= =0A=20=20=20=20=20=20= A=20Uniform=20Resource=20Name=20(URN)=20is=20a=20Uniform=20Resource=20= Identifier=20(URI)=20=20that=20is=20assigned=20= under=20the=20"urn"=20scheme=20and=20a=20particular=20namespace,=20with=20= the=20intent=20that=20the=20URN=20will=20be=20either=20a=20persistent,=20= location-independent=20resource=20identifier=20or=20in=20some=20cases=20= an=20abstract=20designator=20that=20is=20persistent=20but=20that=20does=20= not=20identify=20a=20resource.=20=20A=20URN=20namespace=20is=20a=20= collection=20of=20such=20identifiers,=20each=20of=20which=20is=20(1)=20= unique,=20(2)=20assigned=20in=20a=20consistent=20and=20managed=20way,=20= and=20(3)=20assigned=20according=20to=20a=20common=20definition.=20=20= (Some=20URN=20namespaces=20create=20names=20that=20exist=20only=20as=20= URNs,=20whereas=20others=20create=20URNs=20out=20of=20names=20that=20= already=20exist=20in=20other=20identifier=20systems,=20such=20as=20ISBNs=20= =20and=20ISSNs=20.)=0A=20=20=20=20=20=20The=20assignment=20of=20= URNs=20is=20done=20by=20an=20organization=20(or,=20in=20some=20cases,=20= according=20to=20an=20algorithm=20or=20other=20automated=20process)=20= that=20has=20been=20formally=20delegated=20a=20namespace=20within=20the=20= "urn"=20scheme=20(e.g.,=20a=20URN=20in=20the=20'example'=20namespace=20= =20might=20be=20of=20the=20form=20= "urn:example:foo").=0A=20=20=20=20=20=20This=20document=20rests=20= on=20two=20key=20assumptions:=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20= Assignment=20of=20a=20URN=20is=20a=20managed=20process.=0A=20=20=20= =20=20=20=20=20=20=20The=20space=20of=20URN=20namespaces=20is=20= itself=20managed.=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20While=20other=20URI=20schemes=20may=20= allow=20identifiers=20to=20be=20freely=20chosen=20and=20assigned,=20such=20= is=20not=20the=20case=20for=20URNs.=20=20The=20syntactical=20correctness=20= of=20a=20string=20starting=20with=20"urn:"=20is=20not=20sufficient=20to=20= make=20it=20a=20URN.=20=20In=20order=20for=20the=20string=20to=20be=20a=20= valid=20URN,=20the=20namespace=20identifier=20needs=20to=20be=20= registered=20in=20accordance=20with=20the=20rules=20defined=20here=20and=20= the=20remaining=20parts=20of=20the=20assigned-name=20portion=20of=20the=20= URN=20needs=20to=20be=20generated=20in=20accordance=20with=20the=20rules=20= for=20the=20registered=20namespace.=0A=20=20=20=20=20=20So=20that=20= information=20about=20both=20URN=20syntax=20and=20URN=20namespaces=20is=20= available=20in=20one=20place,=20this=20document=20does=20the=20= following:=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20Defines=20the=20= canonical=20syntax=20for=20URNs=20in=20general=20(in=20a=20way=20that=20= is=20consistent=20with=20URI=20syntax),=20specifies=20methods=20for=20= determining=20URN=20equivalence,=20and=20discusses=20URI=20= conformance.=0A=20=20=20=20=20=20=20=20=20=20Specifies=20a=20= method=20for=20defining=20a=20URN=20namespace=20and=20associating=20it=20= with=20a=20namespace=20identifier,=20and=20describes=20procedures=20for=20= registering=20namespace=20identifiers=20with=20the=20Internet=20Assigned=20= Numbers=20Authority=20(IANA).=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=0A=20=20=20=20=20=20For=20URN=20syntax=20and=20= URN=20namespaces,=20this=20document=20modernizes=20and=20replaces=20the=20= definitions=20from=20=20and=20.=20=20These=20modifications=20build=20on=20the=20= key=20requirements=20provided=20in=20=20and=20= many=20years=20of=20experience=20with=20URNs,=20in=20both=20cases=20= attempting=20to=20make=20the=20smallest=20reasonable=20set=20of=20= changes=20from=20the=20previous=20definitions.=20=20The=20intent=20is=20= to=20define=20URNs=20in=20a=20consistent=20manner=20so=20that,=20= wherever=20practical,=20the=20parsing,=20handling,=20and=20resolution=20= of=20URNs=20can=20be=20independent=20of=20the=20namespace=20within=20= which=20a=20given=20URN=20is=20assigned.=0A=20=20=20=20=20=20This=20= document=20obsoletes=20both=20=20and=20.=0A=20=20=20=20=0A=0A=20=20=20=20= =0A=20=20=20=20=20=20= This=20document=20uses=20the=20terms=20"resolution"=20and=20= "resolver"=20in=20roughly=20the=20sense=20from=20,=20i.e.,=20"resolution"=20is=20the=20act=20of=20= supplying=20services=20related=20to=20the=20identified=20resource,=20= such=20as=20translating=20the=20persistent=20name=20into=20one=20or=20= more=20current=20locators=20for=20the=20resource,=20or=20delivering=20= metadata=20about=20the=20resource=20in=20an=20appropriate=20format.=20=20= At=20the=20time=20of=20this=20writing,=20resolution=20services=20are=20= defined=20in=20.=20=20In=20order=20to=20= underline=20the=20difference=20between=20the=20names=20and=20locators,=20= this=20document=20uses=20the=20term=20Uniform=20Resource=20Locator=20= (URL),=20rather=20than=20the=20generic=20term=20Uniform=20Resource=20= Identifier=20(URI),=20to=20refer=20to=20locators;=20see=20also=20Section=20= 1.1.3=20of=20.=0A=0A=0A=20=20=20=20=20=20= If=20there=20are=20or=20will=20be=20resolution=20services=20available=20= for=20a=20URN,=20this=20document=20calls=20the=20URN=20a=20resource=20= identifier=20in=20roughly=20the=20sense=20from=20.=20=20If=20there=20is=20no=20intention=20to=20= provide=20any=20resolution=20services,=20this=20document=20calls=20the=20= URN=20an=20abstract=20designator.=0A=20=20=20=20=20=20Several=20= other=20important=20terms=20used=20in=20this=20document,=20including=20= some=20"normalization"=20operations=20that=20are=20not=20part=20of=20the=20= Unicode=20Standard=20,=20are=20defined=20in=20= the=20URI=20specification=20.=0A=20=20=20= =20=20=20The=20key=20words=20"MUST",=20"MUST=20NOT",=20"REQUIRED",=20= "SHALL",=20"SHALL=20NOT",=20"SHOULD",=20"SHOULD=20NOT",=20"RECOMMENDED",=20= "NOT=20RECOMMENDED",=20"MAY",=20and=20"OPTIONAL"=20in=20this=20document=20= are=20to=20be=20interpreted=20as=20described=20in=20.=0A=20=20=20=20=0A=0A=20=20=20=20= =0A=20=20=20=20=20=20= The=20syntax=20of=20URNs=20as=20provided=20in=20=20was=20defined=20before=20the=20updated=20= specification=20of=20URIs=20in=20.=20=20The=20= definition=20of=20URN=20syntax=20is=20updated=20in=20this=20document=20= to=20do=20the=20following:=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20= Ensure=20consistency=20with=20the=20URI=20syntax.=0A=20=20=20=20=20= =20=20=20=20=20Facilitate=20the=20use=20of=20URNs=20with=20parameters=20= similar=20to=20URI=20queries=20and=20fragments.=0A=20=20=20=20=20=20=20= =20=20=20Permit=20parameters=20influencing=20URN=20resolution.=0A=20= =20=20=20=20=20=20=20=20=20Ease=20the=20use=20of=20URNs=20with=20= naming=20systems=20that=20include=20the=20'/'=20character.=0A=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= In=20particular,=20this=20specification=20does=20the=20following:=0A= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20Extends=20URN=20syntax=20to=20= explicitly=20allow=20the=20characters=20'/',=20"?",=20and=20"#",=20which=20= were=20reserved=20for=20future=20use=20by=20;=20= this=20change=20effectively=20also=20allows=20several=20components=20of=20= the=20URI=20syntax=20although=20without=20necessarily=20tying=20those=20= components=20to=20URI=20semantics.=0A=20=20=20=20=20=20=20=20=20=20= Defines=20syntax=20for=20an=20additional=20component=20that=20can=20= be=20used=20in=20interactions=20with=20a=20URN=20resolution=20= service.=0A=20=20=20=20=20=20=20=20=20=20Makes=20several=20= smaller=20syntax=20adjustments.=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=0A=20=20=20=20=20=20However,=20this=20= specification=20does=20not=20extend=20the=20URN=20syntax=20to=20allow=20= characters=20outside=20the=20ASCII=20range=20,=20= which=20implies=20that=20any=20such=20characters=20need=20to=20be=20= percent-encoded=20as=20described=20in=20Section=202.1=20of=20the=20URI=20= specification=20.=0A=20=20=20=20=20=20= The=20syntax=20for=20a=20URN=20is=20defined=20as=20follows=20using=20= the=20Augmented=20Backus-Naur=20Form=20(ABNF)=20as=20specified=20in=20= =20and=20.=20= =20Rules=20not=20defined=20here=20(e.g.,=20alphanum,=20fragment,=20and=20= pchar)=20are=20defined=20as=20part=20of=20the=20URI=20syntax=20=20and=20used=20here=20to=20point=20out=20the=20= syntactic=20relationship=20with=20the=20terms=20used=20there.=20=0A=09= =20=20
=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=
=0A=20=20=20=20=20=20The=20question=20mark=20character=20"?"=20= can=20be=20used=20without=20percent-encoding=20inside=20q-components=20= and=20f-components.=20=20It=20SHALL=20NOT=20appear=20inside=20= r-components,=20unless=20it=20is=20percent-encoded.=0A=20=20=20=20=20= =20The=20following=20sections=20provide=20additional=20information=20= about=20the=20syntactic=20elements=20of=20URNs.=0A=0A=20=20=20=20=20=20= =0A=20= =20=20=20=20=20=20=20The=20syntax=20here=20is=20slightly=20more=20= restrictive=20than=20what=20was=20defined=20in=20,=20because=20it=20prohibits=20the=20character=20"-"=20= at=20the=20end=20of=20a=20NID.=0A=20=20=20=20=20=20=20=20NIDs=20= are=20case=20insensitive=20(e.g.,=20"ISBN"=20and=20"isbn"=20are=20= equivalent).=0A=20=20=20=20=20=20=20=20Characters=20outside=20the=20= ASCII=20range=20=20are=20not=20permitted=20in=20= NIDs,=20and=20no=20encoding=20mechanism=20for=20such=20characters=20is=20= supported.=0A=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20The=20namespace=20= specific=20string=20(NSS)=20is=20a=20unique=20identifier=20that=20is=20= assigned=20and=20managed=20in=20a=20consistent=20way=20and=20that=20= conforms=20to=20the=20definition=20of=20the=20relevant=20namespace.=20=20= The=20combination=20of=20the=20NID=20(unique=20across=20the=20entire=20= "urn"=20scheme)=20and=20the=20NSS=20(unique=20within=20the=20namespace)=20= ensures=20that=20the=20resulting=20URN=20is=20a=20globally=20unique=20= URI.=0A=20=20=20=20=20=20=20=20This=20document=20modifies=20the=20= syntax=20of=20the=20NSS=20to=20allow=20the=20following=20characters:=20= "/",=20"~",=20and=20"&".=20=20In=20particular,=20allowing=20the=20= "/"=20character=20effectively=20makes=20it=20possible=20to=20encapsulate=20= hierarchical=20identifiers=20from=20other=20naming=20systems.=20=20For=20= instance,=20consider=20the=20hypothetical=20example=20of=20a=20= hierarchical=20naming=20system=20in=20which=20the=20identifiers=20take=20= the=20form=20of=20a=20series=20of=20numbers=20separated=20by=20the=20"/"=20= character,=20such=20as=20"1/406/47452/2".=20=20If=20the=20naming=20= authority=20for=20such=20identifiers=20were=20to=20use=20URNs,=20it=20= would=20be=20natural=20to=20place=20the=20existing=20identifiers=20in=20= the=20NSS,=20resulting=20in=20URNs=20such=20as=20= "urn:example:1/406/47452/2".=0A=20=20=20=20=20=20=20=20However,=20= the=20foregoing=20changes=20to=20the=20syntax=20for=20the=20NSS=20do=20= not=20modify=20the=20encoding=20rules=20for=20URN=20namespaces=20that=20= were=20defined=20in=20accordance=20with=20.=20= =20If=20any=20such=20URN=20namespace=20that=20is=20used=20outside=20of=20= the=20URN=20context=20(i.e.,=20as=20a=20standalone=20identifier=20space)=20= also=20allows=20the=20use=20of=20"/",=20"~",=20or=20"&"=20in=20the=20= native=20form=20within=20that=20identifier=20space,=20then=20the=20= encoding=20rules=20for=20that=20namespace=20are=20not=20changed=20by=20= this=20specification.=0A=20=20=20=20=20=20=20=20Depending=20on=20= the=20rules=20governing=20a=20namespace,=20names=20that=20are=20valid=20= in=20a=20namespace=20might=20contain=20characters=20that=20are=20not=20= allowed=20by=20the=20"pchar"=20production=20referenced=20above=20(e.g.,=20= characters=20outside=20the=20ASCII=20range=20or,=20consistent=20with=20= the=20restrictions=20in=20RFC=203986,=20the=20characters=20"/",=20"?",=20= "#",=20"[",=20and=20"]").=20=20While=20such=20a=20string=20might=20be=20= a=20valid=20name,=20it=20is=20not=20a=20valid=20URN=20until=20it=20has=20= been=20translated=20into=20a=20conformant=20NSS.=20=20In=20the=20case=20= of=20URNs=20that=20are=20formed=20from=20names=20that=20exist=20= separately=20in=20a=20standalone=20identifier=20space,=20translation=20= of=20an=20identifier=20from=20its=20"native"=20format=20to=20URN=20= format=20is=20accomplished=20by=20using=20the=20canonicalization=20and=20= encoding=20methods=20defined=20for=20that=20URN=20namespace.=20=20= Software=20that=20is=20not=20aware=20of=20those=20namespace-specific=20= canonicalization=20and=20encoding=20rules=20MUST=20NOT=20construct=20= URNs=20from=20the=20names=20in=20the=20standalone=20identifier=20= space.=0A=20=20=20=20=20=20=20=20In=20order=20to=20make=20URNs=20= as=20stable=20and=20persistent=20as=20possible=20when=20protocols=20= evolve=20and=20the=20environment=20around=20them=20changes,=20namespaces=20= SHOULD=20NOT=20allow=20characters=20outside=20the=20basic=20Latin=20= repertoire=20=20unless=20the=20nature=20of=20= the=20particular=20namespace=20makes=20such=20characters=20= necessary.=0A=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20= = =0A=20=20=20=20=20=20=20=20As=20compared=20to=20,=20this=20document=20extends=20the=20URN=20syntax=20= to=20permit=20inclusion=20of=20three=20new=20types=20of=20components:=20= q-component,=20r-component,=20and=20f-component.=20=20Each=20of=20these=20= components=20has=20a=20distinct=20role,=20which=20is=20independent=20of=20= the=20URN=20and=20its=20namespace,=20and=20it=20is=20intended=20that=20= clients=20will=20be=20able=20to=20handle=20these=20components=20= uniformly=20for=20all=20URNs.=20=20In=20general:=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=20=20The=20r-component=20is=20intended=20= for=20parameters=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20to=20be=20= transmitted=20to=20resolution=20services=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20and=20interpreted=20by=20those=20services.=0A=20=20=20=20= =20=20=20=20=20=20=20=20The=20q-component=20is=20intended=20for=20= parameters=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20to=20be=20= transmitted=20to=20and=20interpreted=20by=20or=20with=20respect=20to=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20the=20products=20of=20the=20= resolution=20services,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20such=20= as=20resources=20identified=20by=20URIs.=0A=20=20=20=20=20=20=20=20=20= =20=20=20The=20f-component=20is=20intended=20to=20be=20interpreted=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20by=20the=20client=20as=20a=20= specification=20for=20a=20location=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20within,=20or=20region=20of,=20the=20dereferenced=20resources.=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20The=20foregoing=20generalizations=20are=20true=20= regardless=20of=20the=20URN's=20namespace.=0A=20=20=20=20=20=20=20=20= (This=20paragraph=20is=20informative.)=20An=20exemplary=20= resolution-to-resource=20model=20may=20help=20with=20conceptualizing=20= the=20relationship=20between=20the=20components=20of=20a=20urn:=20URI:=0A= =20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20A=20client=20requests=20resources=20by=20urn:=20= URI,=20invoking=20a=20URI=20handler.=0A=20=20=20=20=20=20=20=20=20=20= =20=20A=20URI=20handler=20parses=20the=20"urn"=20URI=20scheme,=20the=20= f-component,=20and=20everything=20else.=0A=20=20=20=20=20=20=20=20=20= =20=20=20The=20URI=20handler=20invokes=20a=20urn:=20URI=20handler,=20= passing=20everything=20else.=0A=20=20=20=20=20=20=20=20=20=20=20=20= The=20urn:=20URI=20handler=20parses=20everything=20else=20into=20the=20= assigned-name,=20r-component,=20and=20q-component.=0A=20=20=20=20=20=20= =20=20=20=20=20=20The=20urn:=20URI=20handler=20calls=20a=20resolution=20= service,=20passing=20the=20assigned-name=20and=20r-component=20to=20it=20= as=20arguments.=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20= resolution=20service=20returns=20some=20intermediate=20products,=20which=20= may=20include=20resources,=20resource=20identifiers=20(i.e.,=20= dereferenceable=20URIs),=20or=20attributes=20such=20as=20metadata.=0A= =20=20=20=20=20=20=20=20=20=20=20=20The=20urn:=20URI=20handler=20= combines=20the=20q-component=20with=20the=20intermediate=20products.=20= When=20the=20combinations=20result=20in=20dereferenceable=20URIs,=20the=20= handler=20dereferences=20the=20URIs.=20(Collectively,=20the=20products=20= of=20the=20resolution=20services=20encompass=20both=20these=20= intermediate=20products=20and=20the=20computing=20resources=20at=20the=20= other=20end=20of=20the=20dereferenceable=20URIs.)=0A=20=20=20=20=20=20= =20=20=20=20=20=20The=20urn:=20URI=20handler=20acquires=20resources,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20which=20may=20be=20content=20= (i.e.,=20having=20Internet=20media=20types).=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20The=20urn:=20URI=20handler=20may=20interact=20with=20the=20= URI=20handler=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20and=20the=20= client=20to=20pick=20from=20among=20the=20resources.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20= urn:=20URI=20handler=20returns=20some=20of=20these=20resources=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20to=20the=20URI=20handler.=0A=20=20=20= =20=20=20=20=20=20=20=20=20The=20URI=20handler=20interprets=20the=20= f-component,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20likely=20= interacting=20with=20a=20media=20type=20handler=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20and=20the=20client=20to=20identify=20and=20locate=20= sub-resources=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20within=20the=20= dereferenced=20resources.=0A=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20To=20assist=20with=20implementing=20URN=20= resolution=20services,=0A=20=20=20=20=20=20=20=20=20=20=20registered=0A=20=20=20=20=20=20=20=20=20=20the=20= text/uri-list=20media=20type.=0A=20=20=20=20=20=20=20=20=20=20=20updates=20that=20media=20type=20registration=0A= =20=20=20=20=20=20=20=20=20=20to=20include=20arbitrary=20attributes.=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20Whenever=20a=20= URN=20resolves=20to=20a=20URL=20which=20may=20be=20used=20to=20access=20= the=20resource,=20there=20is=20a=20more=20specific=20interpretation=20of=20= q-component=20and=20f-component:=20the=20q-component=20is=20copied=20= verbatim=20to=20the=20query=20portion=20of=20the=20URL=20(if=20that=20= URL=20scheme=20supports=20query),=20and=20the=20f-component=20is=20= copied=20verbatim=20to=20the=20fragment=20portion=20of=20the=20URL.=20=20= =20This=20is=20necessary,=20among=20other=20reasons,=20so=20that=20= interpretation=20of=20q-component=20and=20f-component,=20when=20= associated=20with=20URNs,=20will=20be=20consistent=20with=20the=20= interpretation=20of=20relative=20references=20containing=20queries=20or=20= fragments=20within=20documents=20which=20are=20ultimately=20accessible=20= via=20URNs.=20=20Thus,=20for=20URNs=20which=20may=20be=20resolved=20to=20= a=20URL,=20the=20semantics=20of=20q-component=20are=20identical=20to=20= those=20for=20queries=20to=20that=20resource=20and=20the=20semantics=20= of=20f-components=20are=20identical=20to=20those=20of=20fragments=20for=20= that=20resource.=20=20=20The=20semantics=20of=20q-component=20and=20= f-component=20for=20URNs=20that=20inherently=20cannot=20be=20resolved=20= to=20a=20URL=20(i.e.,=20for=20abstract=20designators)=20are=20undefined=20= by=20this=20document;=20however,=20they=20SHOULD=20be=20consistent=20= with=20the=20above=20roles.=0A=20=20=20=20=20=20=20=20In=20= general,=20neither=20the=20syntax=20nor=20the=20semantics=20of=20= q-components=20or=20f-components=20are=20defined=20by,=20or=20dependent=20= on,=20the=20namespace=20of=20the=20URN.=0A=20=20=20=20=20=20=20=20= Any=20of=20these=20components=20MAY=20be=20used=20with=20URNs=20from=20= existing=20namespaces=20whether=20or=20not=20the=20namespace=20= explicitly=20supports=20them.=20=20As=20described=20above,=20the=20= interpretation=20of=20q-component=20and=20f-component=20is=20= namespace-independent.=20=20Interpretation=20of=20an=20r-component=20may=20= be=20namespace-dependent=20to=20some=20degree=20if=20it=20relies=20on=20= behavior=20of=20a=20namespace-specific=20resolution=20service,=20as=20= discussed=20in=20the=20following=20sections.=0A=0A=20=20=20=20=20=20=20= =20=0A=20=20=20=20= =20=20=20=20=20=20The=20URN=20r-component=20has=20no=20syntactic=20= equivalent=20in=20URIs.=0A=20=20=20=20=20=20=20=20=20=20The=20= r-component=20is=20indicated=20by=20a=20first=20question=20mark=20("?")=20= and=20terminated=20by=20a=20second=20question=20mark=20indicating=20a=20= q-component,=20a=20number=20sign=20("#")=20character=20indicating=20an=20= f-component,=20or=20by=20the=20end=20of=20the=20URI.=20=20The=20= characters=20in=20the=20r-component=20have=20been=20carefully=20chosen=20= to=20eliminate=20ambiguity=20and=20to=20ease=20parsing.=20Note=20that=20= characters=20outside=20the=20ASCII=20range=20=20= MUST=20be=20percent-encoded=20using=20the=20method=20defined=20in=20= Section=202.1=20of=20the=20generic=20URI=20specification=20.=20=0A=20=20=20=20=20=20=20=20=20=20As=20= described=20under=20,=20the=20= r-component=20SHALL=20NOT=20be=20taken=20into=20account=20when=20= determining=20URN=20equivalence.=0A=20=20=20=20=20=20=20=20=20=20= However,=20the=20r-component=20SHALL=20be=20supplied=20along=20with=20= the=20URN=20when=20presenting=20a=20request=20to=20a=20URN=20resolution=20= service.=0A=20=20=20=20=20=20=20=20=20=20The=20r-component=20is=20= entirely=20intended=20for=20passing=20information=20in=20requests=20to=20= URN=20resolution=20services.=20=20The=20r-component=20is=20not=20= intended=20for=20passing=20information=20to=20the=20products=20of=20the=20= resolution=20services,=20to=20the=20resources=20identified=20by=20the=20= URN,=20or=20to=20applications=20that=20manage=20such=20resources.=20=20= In=20addition,=20the=20r-component=20is=20not=20intended=20for=20passing=20= information=20to=20any=20underlying=20services=20that=20might=20exist=20= behind=20a=20resolver,=20only=20to=20the=20resolver=20itself.=0A=20=20= =20=20=20=20=20=20=20=20To=20make=20URNs=20implementable,=20this=20= specification=20provides=20a=20syntax=20and=20semantics=20for=20= r-components.=20An=20r-component=20contains=20a=20resolution=20operation=20= (called=20a=20"rop",=20rhymes=20with=20"hop"),=20an=20authority,=20and=20= a=20set=20of=20parameters.=20When=20the=20r-component=20is=20present,=20= the=20rop=20is=20REQUIRED.=0A=20=20=20=20=20=20=20=20=20=20= Consider=20the=20hypothetical=20example=20of=20passing=20parameters=20= to=20resolution=20service=20(say,=20an=20ISO=20alpha-2=20country=20code=20= =20in=20order=20to=20scope=20down=20the=20= preferred=20country=20in=20which=20to=20search=20for=20a=20physical=20= copy=20of=20a=20book).=20=20This=20could=20perhaps=20be=20accomplished=20= by=20specifying=20the=20country=20code=20in=20the=20r-component,=20= resulting=20in=20URNs=20such=20as:=0A=20=20=20=20=20=20=20=20=20=20=
=0A=20=20=20=20=20=20=20=20=20=20However,=20this=20= primary=20purpose=20is=20not=20intended=20to=20forestall=20other=20= potential=20uses=20for=20r-components.=0A=20=20=20=20=20=20=20=20=20=20= =0A=20= =20=20=20=20=20=20=20=20=20=20=20URNs=20that=20are=20not=20abstract=20= designators=20are=20meant=20to=20be=20resolved.=20The=20resolution=20= operation=20or=20"rop"=20(formerly=20called=20a=20"facet"=20or=20= "resolver=20profile"=20during=20WG=20discussion)=20directs=20a=20= resolver=20as=20to=20what=20services=20to=20supply.=20A=20rop=20= generically=20and=20universally=20applies=20to=20all=20URNs;=20it=20is=20= therefore=20orthogonal=20to=20the=20namespace=20identified=20by=20the=20= NID=20production=20in=20a=20urn:=20URI.=20For=20example,=20the=20= urn:isbn=20namespace=20tends=20to=20identify=20books,=20but=20a=20rop=20= "bookinfo"=20should=20succeed=20for=20all=20identifiers=20that=20= correspond=20to=20books,=20not=20just=20to=20those=20with=20ISBNs.=20= Furthermore,=20there=20may=20be=20identifiers=20assigned=20by=20the=20= International=20ISBN=20Agency=20that=20fit=20in=20the=20urn:isbn=20= namespace,=20but=20do=20not=20correspond=20to=20books.=0A=20=20=20=20= =20=20=20=20=20=20=20=20Since=20URNs=20are=20extremely=20generic,=20a=20= syntax=20to=20identify=20resolution=20operations=20should=20likewise=20= be=20generic.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20Unlike=20the=20= persistence=20(i.e.,=20consistent=20and=20managed=20assignment)=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20guarantees=20required=20of=20the=20URN=20= assigned-name=20portion,=20however,=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20defining=20and=20implementing=20novel=20resolution=20operations=20= should=20be=20as=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= frictionless=20as=20possible.=20Removing=20such=20barriers=20will=20= promote=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20development=20= of=20resolution=20services=20in=20a=20variety=20of=20communities=20and=20= use=20cases.=0A=20=20=20=20=20=20=20=20=20=20=20=20This=20= specification=20defines=20five=20types=20of=20rops:=20aop,=20oidop,=20= roidop,=20urnop,=20and=20nsop,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= along=20with=20an=20ABNF-compatible=20extension=20technique=20for=20= future=20specifications.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20For=20= reasons=20that=20follow,=20this=20specification=20RECOMMENDS=20that=20= oidop=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20be=20used=20as=20the=20= primary=20technique=20for=20specifying=20resolution=20operations.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20An=20= Alpha=20rop=20(aop)=20is=20an=20identifier=20that=20starts=20with=20an=20= alphabetic=20character,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= ends=20with=20an=20alphanumeric=20character,=20and=20may=20contain=20= alphanumeric=20or=20hyphen=20characters.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20The=20aop=20production=20SHALL=20NOT=20begin=20with=20= the=20characters=20"urn".=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20The=20aop=20production=20is=20case-insensitive.=20An=20aop=20is=20= globally=20unique.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= bar=20to=20establish=20an=20aop=20identifier=20is=20RFC=20Required=20= .=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20[[NB:=20At=20this=20time,=20there=20is=20no=20IANA=20registry=20= proposed=20for=20aops.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= If=20the=20WG=20feels=20it=20is=20needed,=20it=20should=20probably=20be=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20sub-registry=20of=20= URN=20Namespaces.=20Just=20a=20suggestion.]]=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20As=20a=20stylistic=20suggestion,=20aops=20SHOULD=20= be=20basic=20US-English=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= words=20or=20phrases.=20The=20terms=20should=20be=20simple=20or=20= compound=20verbs=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20that=20= describe=20the=20operation=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20("display",=20"buy",=20"pickfromwarehouse"),=20or=20if=20the=20verb=20= is=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20related=20to=20= retrieving=20a=20representation,=20aka=20"getting"=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20("get=20PDF",=20"get=20price",=20"get=20= scoreboard"),=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= terms=20should=20be=20simple=20or=20compound=20nouns=20with=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20the=20verb=20omitted=20("pdf",=20= "price",=20"scoreboard").=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= For=20exemplary=20purposes,=20this=20specification=20defines=20three=20= aops=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"info",=20= "hinfo",=20and=20"minfo".=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20"info"=20operation=20directs=20a=20resolver=20to=20return=20= information=20about=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= resource=20or=20class=20of=20resources=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20identified=20by=20the=20assigned-name=20of=20the=20urn:=20URI.=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20(This=20definition=20contrasts=20= with=20information=20about=20the=20identifier,=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20such=20as=20a=20written=20explanation=20of=20how=20the=20= identifier=20is=20composed=20or=20broken=20down.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20This=20definition=20also=20contrasts=20with=20= information=20that=20comprises=20the=20resource=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20itself,=20such=20as=20a=20PDF=20copy=20of=20a=20book.)=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20expectation=20is=20that=20= the=20products=20of=20resolution=20will=20eventually=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20dereference=20to=20content=20(data=20with=20= Internet=20media=20types)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= that=20are=20human-readable=20or=20machine-readable.=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20The=20"hinfo"=20operation=20directs=20a=20= resolver=20to=20return=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= human-readable=20information=20about=20the=20resource=20or=20class=20of=20= resources=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20identified=20= by=20the=20assigned-name=20of=20the=20urn:=20URI.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20For=20example,=20content=20would=20be=20= limited=20to=20media=20types=20such=20as=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20text/plain,=20text/html,=20text/rtf,=20or=20= image/jpeg,=20where=20when=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20the=20information=20is=20presented=20to=20a=20human=20being,=20the=20= human=20being=20would=20be=20able=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20to=20understand=20it.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20The=20"minfo"=20operation=20directs=20a=20resolver=20to=20= return=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= machine-readable=20information=20about=20the=20resource=20or=20class=20= of=20resources=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= identified=20by=20the=20assigned-name=20of=20the=20urn:=20URI.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20For=20example,=20content=20would=20= be=20limited=20to=20media=20types=20such=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20as=20application/json=20or=20application/rdf+xml,=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20where=20when=20that=20= information=20is=20fed=20into=20an=20automated=20process,=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20the=20automated=20process=20would=20be=20= able=20to=20take=20concrete=20action=20on=20it.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20For=20purposes=20of=20simplicity,=20these=20aops=20= MAY=20take=20arbitrary=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20r-params=20but=20this=20specification=20does=20= not=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20bother=20to=20define=20= or=20anticipate=20any=20in=20particular.=0A=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20An=20Object=20Identifier=20rop=20(oidop)=20= is=20an=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Object=20Identifier.=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20The=20oidop=20production=20starts=20with=20a=20= number=200,=201,=20or=202,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20followed=20by=20a=20series=20of=20one=20or=20more=20dotted=20whole=20= numbers.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20bar=20= to=20establish=20an=20oidop=20is=20extremely=20low:=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20just=20assign=20an=20OID=20and=20away=20you=20= go.=20OIDs=20are=20compared=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20for=20exact=20equality,=20and=20there=20is=20no=20semantic=20= hierarchy=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20to=20OID=20= components=20other=20than=20those=20assigned=20by=20.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Furthermore,=20implementations=20that=20parse=20and=20present=20URNs=20= to=20humans=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20MAY=20= display=20the=20OID=20with=20a=20human-readable=20equivalent,=20such=20= as=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20localized=20= string.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20For=20these=20= reasons,=20this=20specification=20RECOMMENDS=20that=20implementers=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20use=20oidop=20to=20define=20= resolution=20operations.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= A=20Relative=20Object=20Identifier=20rop=20(roidop)=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20is=20a=20Relative=20= Object=20Identifier.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Syntactically=20the=20roidop=20production=20is=20a=20series=20of=20= one=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20or=20more=20dotted=20= whole=20numbers;=20therefore,=20roidop=20always=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20starts=20with=20a=20dot.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Relative=20Object=20Identifiers=20are=20always=20= defined=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20relative=20to=20= some=20base=20Object=20Identifier.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20This=20specification=20does=20not=20define=20any=20= particular=20base=20OID.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Therefore,=20this=20syntax=20is=20basically=20reserved=20for=20future=20= use.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20An=20= implementation=20MAY=20use=20this=20rop=20type=20internally,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20but=20it=20is=20not=20currently=20= intended=20for=20interchange.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20A=20Uniform=20Resource=20Name=20rop=20= (urnop)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20is=20an=20= operation=20defined=20by=20a=20URN=20namespace=20authority,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20thus=20making=20it=20globally=20= unique.=20An=20urnop=20production=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20SHALL=20begin=20with=20"urn*".=20The=20NID=20follows=20this=20= mandatory=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20prefix.=20= After=20the=20NID=20comes=20another=20"*",=20and=20an=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20operation-specific=20string=20(NSSop)=20= [[NB:=20or=20possibly=20OSS?]].=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20The=20NSSop=20production=20has=20the=20same=20syntax=20as=20= reg-name=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20but=20= different=20semantics:=20it=20is=20an=20opaque=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20string=20assigned=20by=20the=20namespace=20= authority=20for=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= defining=20resolution=20operations.=20The=20"urn*"=20and=20NID=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20productions=20are=20= case-insensitive,=20but=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20NSSop=20production=20MAY=20be=20case-sensitive=20or=20have=20= complex=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20equivalence=20= algorithms,=20depending=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= on=20the=20definition=20promulgated=20by=20the=20namespace=20= authority.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20As=20= stated=20above,=20resolution=20operations=20are=20(at=20least=20= potentially)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20universally=20= applicable,=20rather=20than=20namespace-specific.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20This=20syntax=20provides=20a=20convenient=20means=20= for=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20namespace=20= authority=20to=20construct=20a=20globally=20unique=20string=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20for=20operations=20that=20are=20internally=20= relevant=20to=20its=20identified=20resources,=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20but=20that=20could=20apply=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20more=20broadly=20to=20other=20identifiers.=20The=20NSSop=20= productions=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20occupy=20an=20= orthogonal=20namespace=20to=20the=20NSS=20productions,=20so=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20<urn:example:foobar2015>=20and=20= <urn*example*foobar2015>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= do=20not=20necessarily=20refer=20to=20the=20same=20thing.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20[[NB:=20NSSop=20as=20a=20restricted=20= character=20repertoire=20compared=20with=20NSS,=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20because=20characters=20such=20as=20:=20/=20and=20= @=20lead=20to=20ambiguity=20in=20the=20ABNF,=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20thus=20making=20parsing=20a=20lot=20more=20= complicated.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*=20was=20= chosen=20because=20it=20looks=20like=20a=20bullet=20or=20middle=20dot=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20and=20therefore=20most=20= closely=20resembles=20a=20"generic=20operator".]]=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Due=20to=20the=20potential=20complexity=20= inherent=20in=20the=20equivalence=20question,=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20using=20urnop=20is=20NOT=20RECOMMENDED=20(an=20= oidop=20can=20suffice).=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20A=20Namespace=20rop=20(nsop)=20is=20an=20operation=20= defined=20by=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= same=20URN=20namespace=20authority=20as=20the=20NID=20production=20in=20= the=20urn:=20URI,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20thus=20= making=20it=20globally=20unique.=20It=20has=20the=20same=20semantics=20= as=20urnop=20above,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= except=20that=20"*"=20is=20syntactic=20sugar=20for=20"urn*"=20NID=20"*".=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20syntax=20= basically=20recognizes=20that=20there=20will=20be=20appreciable=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20use=20cases=20where=20the=20= namespace=20authority=20has=20some=20operations=20in=20mind,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20and=20it=20may=20be=20most=20= expedient=20for=20the=20namespace=20authority=20to=20promulgate=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20these=20operations=20itself.=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Due=20to=20the=20potential=20= complexity=20inherent=20in=20the=20equivalence=20question,=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20using=20nsop=20is=20NOT=20= RECOMMENDED=20(an=20oidop=20can=20suffice).=0A=20=20=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20The=20ABNF=20above=20can=20be=20extended=20to=20= include=20syntaxes=20for=20other=20kinds=20of=20operations.=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20The=20five=20rops=20defined=20in=20= this=20specification=20are=20easily=20distinguished=20by=20their=20first=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20characters:=20ALPHA=20= except=20"urn"=20(aop),=200-2=20(oidop),=20"."=20(roidop),=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20"urn*"=20(urnop),=20and=20"*"=20= (nsop).=20Therefore,=20future=20specifications=20MAY=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20provide=20new=20operation=20syntaxes=20= that=20begin=20with=20the=20following=20characters:=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= However,=20the=20following=20characters=20SHALL=20NOT=20be=20used,=20= because=20they=20would=20make=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20the=20subsequent=20components=20ambiguous:=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20
=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20The=20following=20characters=20= could=20be=20used,=20but=20are=20NOT=20RECOMMENDED=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20for=20the=20following=20reasons:=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20= r-authority=20production=20specifies=20which=20resolver=20to=20use=20for=20= URN=20resolution.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= reg-name=20production=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20and=20= semantics=20from=20=20are=20used=20for=20= r-production=20in=20this=20draft.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20When=20r-authority=20is=20present,=20the=20urn:=20URI=20SHALL=20be=20= resolved=20by=20querying=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= named=20resolution=20service=20instead=20of=20the=20resolution=20= services=20typically=20relied=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= upon=20by=20an=20implementation.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Specifically,=20this=20specification=20defines=20r-authority=20to=20= be=20a=20DNS=20name=20at=20which=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20a=20resolver=20service=20may=20be=20addressed.=20The=20manner=20of=20= association=20between=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= DNS=20name=20and=20specific=20resource=20records=20(e.g.,=20NAPTR=20or=20= SRV)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20is=20outside=20the=20= scope=20of=20this=20specification.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20r-authority=20= production=20MAY=20identify=20names=20that=20are=20not=20DNS=20names,=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20consistent=20with=20the=20= reg-name=20discussion=20in=20Section=203.2.2=20of=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20,=20but=20cannot=20and=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20SHALL=20NOT=20identify=20hosts=20= by=20IP=20address.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20[[NB:=20= The=20syntactic=20reason=20is=20because=20":"=20delimits=20r-authority=20= from=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20r-params=20but=20"["=20= and=20"]"=20are=20not=20permitted.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20(Tried=20to=20use=20"!"=20but=20reg-name=20allows=20sub-delims.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Alternative=20is=20to=20restrict=20= reg-name=20to=20RFC=201035=20hostnames,=20but=20that=20excludes=20= non-DNS=20names,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20as=20well=20= as=20technically=20valid=20DNS=20names=20that=20are=20not=20hostnames.)=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20semantic=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20reason=20is=20because=20DNS=20or=20other=20= name-lookup=20technologies=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= are=20sort=20of=20implied=20by=20the=20various=20URN=20specifications=20= over=20the=20last=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=2025=20= years.]]=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20A=20= resolution=20service=20MAY=20accept=20additional=20parameters,=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20the=20semantics=20of=20which=20are=20= defined=20by=20the=20rop.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20To=20= promote=20uniformity,=20this=20specification=20provides=20an=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20overaching=20data=20model=20for=20these=20= parameters.=20The=20syntax=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= is=20based=20on=20experience=20with=20a=20variety=20of=20other=20query=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20and=20fragment=20syntaxes,=20= including=20those=20from=20http:,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20application/x-www-form-urlencoded,=20and=20application/pdf.=0A=20=20= =20=20=20=20=20=20=20=20=20=20[[NB:=20Experience=20over=20the=20last=20= 25=20years=20with=20the=20ambiguities=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20and=20parsing=20craziness=20of=20= application/x-www-form-urlencoded=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20suggests=20that=20it=20is=20better=20for=20us=20to=20define=20how=20= r-params=20work=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20NOW,=20= rather=20than=20leave=20it=20up=20to=20some=20pie-in-the-sky=20= free-for-all=20down=20the=20line.]]=0A=20=20=20=20=20=20=20=20=20=20=20= =20Resolution=20parameters=20formally=20comprise=20a=20multimap=20(or=20= map=20of=20lists).=20Each=0A=20=20=20=20=20=20=20=20=20=20=20=20= (unordered)=20name=20has=20an=20(ordered)=20list=20of=20zero=20or=20more=20= values.=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20repertoire=20of=20= names=20and=20values=20are=20the=20Unicode=20= scalar=20values,=0A=20=20=20=20=20=20=20=20=20=20=20=20plus=20the=20= characters=20"$"=20and=20"+",=20which=20MAY=20have=20further=20reserved=20= purposes.=0A=20=20=20=20=20=20=20=20=20=20=20=20Names=20and=20values=20= are=20case-sensitive=20and=20are=20not=20subject=20to=20Unicode=0A=20=20=20= =20=20=20=20=20=20=20=20=20normalization=20or=20other=20normalizing=20= techniques.=0A=20=20=20=20=20=20=20=20=20=20=20=20Values=20are=20= separated=20by=20",".=20Pairs=20of=20name-plus-optional-values=20are=20= separated=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20by=20";"=20or=20= "&",=20which=20are=20equivalent=20to=20one=20another.=20However,=20= ";"=20is=20RECOMMENDED=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= because=20it=20is=20meant=20to=20be=20visually=20distinct=20from=20the=20= q-component,=20which=20(in=20cases=20where=20HTTP=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20is=20involved)=20will=20likely=20have=20"&"=20= in=20the=20analogous=20positions.=0A=20=20=20=20=20=20=20=20=20=20=20= =20When=20encoded=20in=20r-params=20in=20a=20urn:=20URI,=20Unicode=20= scalar=20values=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20outside=20of=20= unreserved=20!=20'=20(=20)=20*=20SHALL=20be=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20percent-encoded=20in=20UTF-8,=20with=20the=20following=20= special=20considerations.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20gen-delim=20characters=20[=20]=20?=20#=20MUST=20be=20= percent-encoded=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20because=20= they=20do=20not=20conform=20to=20the=20query=20production=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20of=20,=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20or=20because=20they=20delimit=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20the=20r-component=20from=20the=20= subsequent=20components.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20= gen-delim=20characters=20:=20/=20@=20SHOULD=20be=20percent-encoded=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20(and=20the=20ABNF=20mandates=20= this),=20but=20a=20generic=20receiver=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20SHALL=20accept=20unencoded=20:=20/=20@=20characters.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20The=20sub-delim=20characters=20!=20'=20= (=20)=20*=20have=20no=20reserved=20purposes=20and=20therefore=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20SHOULD=20NOT=20be=20percent-encoded;=20= a=20generic=20receiver=20SHALL=20accept=20them=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20whether=20percent-encoded=20or=20not.=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20The=20rop=20MAY=20assign=20reserved=20= purposes=20to=20the=20sub-delim=20characters=20$=20+.=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Therefore,=20a=20generic=20generator=20SHOULD=20= percent-encode=20$=20+=20for=20generic=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20inputs=20(particularly=20user-provided=20inputs)=20unless=20the=20= generator=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20knows=20that=20it=20= is=20invoking=20the=20reserved=20purposes.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20These=20semantics=20exactly=20match=20the=20behavior=20of=20= the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20encodeURIComponent()=20= function=20in=20.=0A=20=20=20=20=20=20=20= =20=20=20=20=20Pairs=20are=20unordered=20and=20names=20are=20unique,=20= so=20generators=20SHALL=20NOT=20generate=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20pairs=20that=20have=20the=20same=20names.=20Generic=20= receivers=20SHALL=20concatenate=20the=20values=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20of=20multiple=20pairs=20that=20have=20the=20same=20= names=20in=20the=20order=20in=20which=20they=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20(both=20the=20pairs=20and=20the=20values)=20are=20= received.=0A=20=20=20=20=20=20=20=20=20=20=20=20In=20the=20event=20= that=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20canonical=20form=20= is=20needed,=20a=20canonical=20generator=20SHALL=20emit=20pairs=20in=20= lexographical=20order=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20(that=20= is,=20=20code=20point=20order)=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20according=20to=20their=20names,=20and=20= SHALL=20use=20";"=20as=20the=20pair=20separator.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20A=20canonical=20generator=20SHALL=20percent-encode=20= characters=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20maked=20as=20= SHOULD=20above,=20and=20SHALL=20NOT=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20percent-encode=20characters=20marked=20as=20SHOULD=20NOT=20above.=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20A=20canonical=20receiver=20MAY=20= reject=20inputs=20that=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20are=20= not=20in=20canonical=20generated=20form=20(i.e.,=20that=20have=20pairs=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20with=20duplicate=20names,=20= that=20use=20"&",=20or=20that=20do=20not=20percent-encode=20= characters=20properly).=0A=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20The=20URN=20q-component=20has=20the=20same=20syntax=20as=20the=20= URI=20query=20component.=20=20If=20a=20URN=20resolves=20to=20a=20URL=20= with=20a=20scheme=20that=20supports=20a=20query=20component,=20the=20= q-component=20from=20the=20URN=20is=20copied=20verbatim=20to=20the=20= query=20component=20of=20the=20URL.=20=20If=20the=20URN=20does=20not=20= resolve=20to=20a=20URL=20(i.e.,=20is=20an=20abstract=20designator),=20= the=20interpretation=20of=20the=20q-component=20is=20undefined=20by=20= this=20specification.=0A=20=20=20=20=20=20=20=20=20=20The=20= characters=20slash=20("/")=20and=20question=20mark=20("?")=20may=20= represent=20data=20within=20the=20q-component.=20=20Note=20that=20= characters=20outside=20the=20ASCII=20range=20=20= MUST=20be=20percent-encoded=20using=20the=20method=20defined=20in=20= Section=202.1=20of=20the=20generic=20URI=20specification=20.=20=0A=20=20=20=20=20=20=20=20=20=20As=20= described=20under=20,=20the=20= q-component=20SHALL=20NOT=20be=20taken=20into=20account=20when=20= determining=20URN=20equivalence.=0A=20=20=20=20=20=20=20=20=20=20= Similarly,=20the=20q-component=20SHALL=20NOT=20be=20taken=20into=20= account=20when=20resolving=20a=20URN=20to=20a=20URL=20and=20MUST=20NOT=20= be=20used=20to=20communicate=20parameters=20to=20a=20resolution=20= service.=0A=20=20=20=20=20=20=20=20=20=20Consider=20the=20= hypothetical=20example=20of=20passing=20parameters=20to=20an=20= application=20that=20returns=20weather=20reports=20from=20different=20= regions=20or=20for=20different=20time=20periods.=20=20This=20could=20= perhaps=20be=20accomplished=20by=20specifying=20latitude/longitude=20= coordinates=20and=20datetimes=20in=20the=20URN's=20q-component,=20= resulting=20in=20URNs=20such=20as:=0A=
=0A=20=20=20=20= =20=20=20=20=20=20However,=20this=20primary=20purpose=20is=20not=20= intended=20to=20forestall=20other=20potential=20uses=20for=20= q-components=20for=20URNs=20that=20do=20not=20resolve=20to=20URLs.=0A= =20=20=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20The=20URN=20f-component=20has=20the=20same=20syntax=20as=20the=20= URI=20fragment=20component.=20=20=20When=20a=20URN=20containing=20an=20= f-component=20resolves=20to=20a=20URL,=20the=20f-component=20from=20the=20= URN=20is=20copied=20verbatim=20into=20the=20fragment=20of=20that=20URL.=20= =20If=20the=20URN=20does=20not=20resolve=20to=20a=20URL=20(i.e.,=20is=20= an=20abstract=20designator),=20the=20interpretation=20of=20the=20= f-component=20is=20undefined=20by=20this=20specification.=0A=20=20=20= =20=20=20=20=20=20=20The=20f-component=20is=20indicated=20by=20the=20= presence=20of=20a=20number=20sign=20("#")=20character=20and=20terminated=20= by=20the=20end=20of=20the=20URI.=20=20Note=20that=20characters=20outside=20= the=20ASCII=20range=20=20MUST=20be=20= percent-encoded=20using=20the=20method=20defined=20in=20Section=202.1=20= of=20the=20generic=20URI=20specification=20.=20=0A=20=20=20=20=20=20=20=20=20=20As=20= described=20under=20,=20the=20= f-component=20SHALL=20NOT=20be=20taken=20into=20account=20when=20= determining=20URN=20equivalence.=0A=20=20=20=20=20=20=20=20=20=20= Similarly,=20the=20f-component=20MUST=20NOT=20be=20passed=20to=20= resolution=20servers=20when=20querying=20them=20for=20resource=20= locations=20or=20metadata.=0A=20=20=20=20=20=20=20=20=20=20The=20= f-component=20is=20primarily=20intended=20to=20distinguish=20the=20= constituent=20parts=20of=20resources=20named=20by=20URNs.=20=20Thus,=20= for=20URNs=20that=20resolve=20to=20URLs,=20the=20semantics=20of=20an=20= f-component=20are=20defined=20by=20the=20media=20type=20of=20those=20= resources,=20not=20by=20the=20namespace.=0A=20=20=20=20=20=20=20=20=20= =20Consider=20the=20hypothetical=20example=20of=20obtaining=20= resources=20that=20are=20part=20of=20a=20larger=20entity=20(say,=20the=20= chapters=20of=20a=20book).=20=20Each=20part=20could=20be=20specified=20= in=20the=20f-component,=20resulting=20in=20URNs=20such=20as:=0A=20=20= =20=20=20=20=20=20=20=20=
=
=0A=20=20=20=20=20=20=20=20=20=20However,=20this=20primary=20= purpose=20is=20not=20intended=20to=20forestall=20other=20potential=20= uses=20for=20f-components=20for=20URNs=20that=20do=20not=20resolve=20to=20= URLs.=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=0A=20=20=20=20=0A=20=20=20=20= =20=20=0A= =20=20=20=20=20=20=20=20For=20various=20purposes=20such=20as=20= caching,=20often=20it=20is=20desirable=20to=20determine=20if=20two=20= URNs=20are=20"the=20same".=20=20This=20is=20done=20by=20testing=20for=20= equivalence=20(see=20Section=206.1=20of=20).=0A=20=20=20=20=20=20=20=20The=20generic=20= URI=20specification=20=20is=0A=09=09=20=20=20= very=20flexible=20about=20=0A=09=09=20=20=20equality=20comparisons,=20= putting=20the=20focus=20on=20allowing=20false=0A=09=09=20=20=20negatives=20= and=20avoiding=20false=20positives.=20=20If=20comparisons=0A=09=09=20=20=20= are=20made=20in=20a=20scheme-independent=20way,=20i.e.,=20as=20URI=0A=09=09= =20=20=20comparisons=20only,=20URNs=20that=20this=20specification=20= considers=0A=09=09=20=20=20equal=20would=20be=20rejected.=20=20The=20= discussion=20below=20applies=0A=09=09=20=20=20when=20the=20URIs=20= involved=20are=20known=20to=20be=20URNs.=20=0A=20=20=20=20=20=20=20=20= Two=20URNs=20are=20equivalent=20if=20their=20<assigned-name>=20= portions=20are=20octet-by-octet=20equal=20after=20applying=20case=20= normalization=20(as=20specified=20in=20Section=206.2.2.1=20of=20)=20to=20the=20following=20constructs:=0A=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20the=20URI=20= scheme=20"urn",=20by=20conversion=20to=20lower=20case=0A=20=20=20=20=20= =20=20=20=20=20=20=20the=20NID,=20by=20conversion=20to=20lower=20= case=0A=20=20=20=20=20=20=20=20=20=20=20=20any=20percent-encoded=20= characters=20in=20the=20NSS=20(that=20is,=20all=20character=20triplets=20= that=20match=20the=20<pct-encoding>=20production=20found=20in=20= Section=202.1=20of=20the=20base=20URI=20specification=20),=20by=20conversion=20to=20upper=20case=20for=20the=20= digits=20A-F.=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20Percent-encoded=20characters=20= MUST=20NOT=20be=20decoded,=20i.e.,=20percent-encoding=20normalization=20= (as=20specified=20in=20Section=206.2.2.2=20of=20)=20MUST=20NOT=20be=20applied.=0A=20=20=20=20=20=20= =20=20If=20a=20q-component,=20r-component,=20or=20f-component=20(or=20= any=20combination=20thereof)=20are=20included=20in=20a=20URN,=20they=20= MUST=20be=20ignored=20for=20purposes=20of=20determining=20= equivalence.=0A=20=20=20=20=20=20=20=20URN=20namespace=20= definitions=20MAY=20include=20additional=20rules=20for=20equivalence,=20= such=20as=20case-insensitivity=20of=20the=20NSS=20(or=20parts=20= thereof).=20=20Such=20rules=20MUST=20always=20have=20the=20effect=20of=20= eliminating=20some=20of=20the=20false=20negatives=20obtained=20by=20the=20= procedure=20above=20and=20MUST=20NOT=20result=20in=20treating=20two=20= URNs=20as=20not=20equivalent=20if=20the=20procedure=20here=20says=20they=20= are=20equivalent.=20=20For=20related=20considerations=20with=20regard=20= to=20NID=20registration,=20see=20below.=0A=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20This=20= section=20shows=20a=20variety=20of=20URNs=20(using=20the=20"example"=20= NID=20defined=20in=20)=20that=20highlight=20= the=20equivalence=20rules.=0A=20=20=20=20=20=20=20=20First,=20= because=20the=20scheme=20and=20NID=20are=20case-insensitive,=20the=20= following=20URNs=20are=20equivalent=20to=20each=20other:=0A=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20urn:example:a123,z456=0A=20= =20=20=20=20=20=20=20=20=20=20=20URN:example:a123,z456=0A=20=20=20= =20=20=20=20=20=20=20=20=20urn:EXAMPLE:a123,z456=0A=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20Second,=20because=20the=20q-component=20and=20f-component=20are=20= not=20taken=20into=20account=20for=20purposes=20of=20testing=20= equivalence,=20the=20following=20URNs=20are=20equivalent=20to=20the=20= first=20three=20examples=20above:=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20urn:example:a123,z456?abc=0A=20=20=20=20=20=20=20= =20=20=20=20=20urn:example:a123,z456#789=0A=20=20=20=20=20=20=20=20= =20=20=20=20urn:example:a123,z456#abc=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= Third,=20because=20the=20"/"=20character=20(and=20anything=20that=20= follows=0A=09=09=20=20=20it)=20in=20the=20NSS=20is=20taken=20into=20= account=20for=20purposes=20of=0A=09=09=20=20=20equivalence,=20the=20= following=20URNs=20are=20not=20equivalent=20to=20each=0A=09=09=20=20=20= other=20or=20to=20the=20preceding=20URNs:=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20urn:example:a123,z456/foo=0A=20=20=20=20= =20=20=20=20=20=20=20=20urn:example:a123,z456/bar=0A=20=20=20=20=20= =20=20=20=20=20=20=20urn:example:a123,z456/baz=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20Fourth,=20because=20of=20percent-encoding,=20the=20following=20= URNs=20are=20equivalent=20only=20to=20each=20other=20(although=20%2C=20= is=20the=20percent-encoded=20transformation=20of=20","=20from=20the=20= previous=20examples,=20such=20sequences=20are=20not=20decoded=20for=20= purposes=20of=20testing=20equivalence):=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20urn:example:a123%2Cz456=0A=20=20=20=20=20= =20=20=20=20=20=20=20URN:EXAMPLE:a123%2cz456=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= Fifth,=20because=20characters=20other=20than=20percent-encoded=20= sequences=20in=20the=20NSS=20are=20treated=20in=20a=20case-sensitive=20= manner=20(unless=20otherwise=20specified=20for=20the=20namespace=20in=20= question),=20the=20following=20URNs=20are=20not=20equivalent=20to=20the=20= first=20three=20URNs:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20urn:example:A123,z456=0A=20=20=20=20=20=20=20=20=20=20=20=20= urn:example:a123,Z456=0A=20=20=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20Sixth,=20on=20= casual=20visual=20inspection=20of=20a=20URN=20presented=20in=20a=20= human-oriented=20interface=20the=20following=20URN=20might=20appear=20= the=20same=20as=20the=20first=20three=20URNs=20(because=20U+0430=20= CYRILLIC=20SMALL=20LETTER=20A=20can=20be=20confused=20with=20U+0061=20= LATIN=20SMALL=20LETTER=20A),=20but=20it=20is=20not=20equivalent:=0A=20= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= urn:example:%D0%B0123,z456=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=0A=20= =20=20=20=0A=0A=20=20=20=20=0A=20=20=20=20=20=20=0A=20= =20=20=20=20=20=20=20Because=20a=20URN=20is,=20syntactically,=20a=20= URI=20under=20the=20"urn"=20scheme,=20in=20theory=20a=20URN=20can=20be=20= placed=20in=20any=20protocol=20slot=20that=20allows=20for=20a=20URI=20= (e.g.,=20the=20'href'=20and=20'src'=20attributes=20in=20HTML,=20the=20= <base/>=20element=20in=20HTML,=20the=20'xml:base'=20attribute=20in=20= XML=20,=20and=20the=20'xmlns'=20attribute=20= in=20XML=20for=20XML=20namespace=20names=20).=0A=20=20=20=20=20=20=20=20However,=20= this=20does=20not=20imply=20that,=20semantically,=20it=20always=20makes=20= sense=20in=20practice=20to=20place=20a=20URN=20in=20a=20given=20URI=20= protocol=20slot;=20in=20particular,=20because=20a=20URN=20might=20not=20= specify=20the=20location=20of=20a=20resource=20or=20even=20point=20= indirectly=20to=20one,=20it=20might=20not=20be=20appropriate=20to=20= place=20a=20URN=20in=20a=20URI=20protocol=20slot=20that=20points=20to=20= a=20resource=20(e.g.,=20the=20aforementioned=20'href'=20and=20'src'=20= attributes).=0A=20=20=20=20=20=20=20=20Ultimately,=20guidelines=20= regarding=20when=20it=20is=20appropriate=20to=20use=20URIs=20under=20the=20= "urn"=20scheme=20(or=20any=20other=20scheme)=20are=20the=20= responsibility=20of=20specifications=20for=20individual=20URI=20protocol=20= slots=20(e.g.,=20the=20specification=20for=20the=20'xml:base'=20= attribute=20in=20XML=20might=20recommend=20that=20it=20is=20= inappropriate=20to=20use=20URNs=20in=20that=20protocol=20slot).=20=20= This=20specification=20cannot=20possibly=20anticipate=20all=20of=20the=20= relevant=20cases,=20and=20it=20is=20not=20the=20place=20of=20this=20= specification=20to=20require=20or=20restrict=20usage=20for=20individual=20= protocol=20slots.=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20=20In=20part=20because=20of=20the=20separation=20of=20semantics=20= from=20syntax=20,=20= generic=20URI=20processors=20need=20to=20pay=20special=20attention=20to=20= the=20parsing=20and=20analysis=20rules=20of=20RFC=203986=20and,=20in=20= particular,=20must=20treat=20the=20URI=20as=20opaque=20unless=20the=20= scheme=20and=20its=20requirements=20are=20recognized,=20in=20which=20= case=20they=20may=20be=20in=20a=20position=20to=20invoke=20= scheme-appropriate=20processing=20such=20as=20by=20a=20URN=20resolver.=20= =20The=20URN=20resolver=20can=20either=20be=20an=20external=20resolver=20= that=20the=20URI=20resolver=20knows=20of,=20or=20it=20can=20be=20= functionality=20built=20into=20the=20URI=20resolver.=20=20Note=20that=20= this=20requirement=20might=20impose=20constraints=20on=20the=20contexts=20= in=20which=20URNs=20are=20appropriately=20used;=20see=20.=0A=20=20=20=20=20=20=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20Section=205.2=20describes=20an=20algorithm=20for=20= converting=20a=20URI=20reference=20that=20might=20be=20relative=20to=20a=20= given=20base=20URI=20into=20"parsed=20components"=20of=20the=20target=20= of=20that=20reference,=20which=20can=20then=20be=20recomposed=20per=20= RFC=203986=20Section=205.3=20into=20a=20target=20URI.=20=20=20This=20= algorithm=20cannot=20be=20applied=20directly=20to=20URNs=20because=20= their=20syntax=20does=20not=20support=20the=20necessary=20path=20= components.=20=20The=20notion=20of=20a=20URN=20as=20a=20"persistent",=20= "permanent"=20identifier=20does=20not=20reconcile=20easily=20with=20= relative=20referencing.=20=20However,=20resources=20named=20with=20URNs=20= may=20contain=20relative=20references=20that=20do=20not=20apply=20to=20= the=20URN=20itself.=0A=20=20=20=20=20=20=20=20Therefore=20a=20= relative=20reference=20SHOULD=20NOT=20be=20evaluated=20directly=20with=20= respect=20to=20a=20URN.=20=20=20Instead,=20a=20relative=20reference=20= SHOULD=20be=20evaluated=20indirectly=20with=20respect=20to=20one=20of=20= the=20following:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= a=20base=20URI=20(other=20than=20a=20URN)=20declared=20by=20the=20= resource=20itself;=20or=0A=20=20=20=20=20=20=20=20=20=20=20=20a=20= base=20URI=20(other=20than=20a=20URN)=20obtained=20through=20the=20URN=20= resolution=20process;=20or=0A=20=20=20=20=20=20=20=20=20=20=20=20= the=20URL=20of=20the=20resource=20as=20obtained=20through=20the=20URN=20= resolution=20process=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20(Case=202=20permits=20= the=20resolution=20process=20to=20explicitly=20supply=20a=20base=20URI=20= if=20the=20resource=20content=20is=20supplied=20directly=20by=20the=20= resolution=20service=20rather=20than=20via=20an=20intermediate=20= "location"=20URI.)=0A=20=20=20=20=20=20=20=20If=20no=20such=20= base=20URI=20exists,=20use=20of=20a=20relative=20reference=20with=20= respect=20to=20a=20URN=20is=20an=20error.=20=20Client=20behavior=20in=20= this=20case=20is=20undefined.=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20Resolution=20services=20SHOULD=20ensure=20that=20a=20base=20URI=20= is=20supplied=20any=20time=20they=20provide=20resource=20content=20= directly=20to=20a=20client.=0A=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20When=20URNs=20are=20= transported=20and=20exchanged,=20they=20MUST=20be=20represented=20in=20= the=20format=20defined=20herein.=20=20Further,=20all=20URN-aware=20= applications=20MUST=20offer=20the=20option=20of=20displaying=20URNs=20in=20= this=20canonical=20form=20to=20allow=20for=20direct=20transcription=20= (for=20example=20by=20cut-and-paste=20techniques).=20=20Such=20= applications=20might=20support=20display=20of=20URNs=20in=20a=20more=20= human-friendly=20form=20and=20might=20use=20a=20character=20set=20that=20= includes=20characters=20that=20are=20not=20permitted=20in=20URN=20syntax=20= as=20defined=20in=20this=20specification=20(e.g.,=20when=20displaying=20= URNs=20to=20humans,=20such=20applications=20might=20replace=20= percent-encoded=20strings=20with=20characters=20from=20an=20extended=20= character=20repertoire=20such=20as=20Unicode=20).=0A=20=20=20=20=20=20=20=20To=20minimize=20= user=20confusion,=20a=20URI=20browser=20SHOULD=20display=20the=20= complete=20URN=20(including=20the=20"urn"=20scheme=20and=20any=20= components)=20to=20ensure=20that=20there=20is=20no=20confusion=20between=20= URN=20namespace=20identifiers=20and=20URI=20scheme=20identifiers.=20=20= For=20example,=20a=20URI=20beginning=20with=20"urn:xmpp:"=20=20is=20very=20different=20from=20a=20URI=20= beginning=20with=20"xmpp:"=20.=20=20= Similarly,=20a=20potential=20DOI=20URI=20scheme=20=20is=20different=20from,=20and=20possibly=20= completely=20unrelated=20to,=20a=20possible=20DOI=20URN=20namespace.=0A= =20=20=20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20As=20mentioned,=20the=20assignment=20of=20URNs=20is=20a=20managed=20= process,=20as=20is=20the=20assignment=20of=20namespaces=20themselves.=20=20= Although=20design=20of=20the=20URNs=20to=20be=20assigned=20within=20a=20= given=20namespace=20is=20ceded=20by=20this=20specification=20to=20the=20= namespace=20owner,=20doing=20so=20in=20a=20managed=20way=20avoids=20the=20= problems=20inherent=20in=20unmanaged=20generation=20of=20URIs=20as=20= described=20in=20the=20recommendations=20regarding=20URI=20design=20and=20= ownership=20.=0A=20=20=20=20=20=20= =0A=20=20=20=20=0A=0A=20=20=20=20=0A=20=20=20=20=20=20A=20= URN=20namespace=20is=20a=20collection=20of=20identifiers=20that=20obey=20= three=20constraints:=20each=20identifier=20is=20(1)=20unique,=20(2)=20= assigned=20in=20a=20consistent=20way,=20and=20(3)=20assigned=20according=20= to=20a=20common=20definition.=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20= The=20"uniqueness"=20constraint=20means=20that=20an=20identifier=20= within=20the=20namespace=20is=20never=20assigned=20to=20more=20than=20= one=20resource=20and=20never=20reassigned=20to=20a=20different=20= resource=20(for=20the=20kind=20of=20"resource"=20identified=20by=20URNs=20= assigned=20within=20the=20namespace).=20=20This=20holds=20true=20even=20= if=20the=20identifier=20itself=20is=20deprecated=20or=20becomes=20= obsolete.=0A=20=20=20=20=20=20=20=20=20=20The=20"consistent=20= assignment"=20constraint=20means=20that=20an=20identifier=20within=20the=20= namespace=20is=20assigned=20by=20an=20organization=20or=20created=20in=20= accordance=20with=20a=20process=20or=20algorithm=20that=20is=20always=20= followed.=0A=20=20=20=20=20=20=20=20=20=20The=20"common=20= definition"=20constraint=20means=20that=20there=20are=20clear=20= definitions=20for=20the=20syntax=20of=20identifiers=20within=20the=20= namespace=20and=20for=20the=20process=20of=20assigning=20or=20creating=20= them.=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=0A=20= =20=20=20=20=20A=20URN=20namespace=20is=20identified=20by=20a=20= particular=20NID=20in=20order=20to=20ensure=20the=20global=20uniqueness=20= of=20URNs=20and,=20optionally,=20to=20provide=20a=20cue=20regarding=20= the=20structure=20of=20URNs=20assigned=20within=20a=20namespace.=0A=20= =20=20=20=20=20With=20regard=20to=20global=20uniqueness,=20using=20= different=20NIDs=20for=20different=20collections=20of=20identifiers=20= ensures=20that=20no=20two=20URNs=20will=20be=20the=20same=20for=20= different=20resources,=20since=20each=20collection=20is=20required=20to=20= uniquely=20assign=20each=20identifier.=20=20However,=20a=20single=20= resource=20MAY=20have=20more=20than=20one=20URN=20assigned=20to=20it,=20= either=20in=20the=20same=20namespace=20(if=20the=20namespace=20permits=20= it)=20or=20in=20different=20namespaces,=20and=20either=20for=20similar=20= purposes=20or=20different=20purposes.=20=20(For=20example,=20if=20a=20= book=20were=20published=20in=20a=20monograph=20series,=20it=20could=20= have=20both=20an=20ISBN=20=20and=20an=20ISSN=20= =20assigned=20to=20it,=20resulting=20in=20= two=20URNs=20referring=20to=20the=20same=20book.)=20=20Subject=20to=20= other=20constraints,=20such=20as=20those=20imposed=20by=20the=20URI=20= syntax=20,=20the=20rules=20of=20the=20URN=20= scheme=20are=20intended=20to=20allow=20preserving=20the=20normal=20and=20= natural=20form=20of=20identifiers=20specified=20=20elsewhere=20when=20= they=20are=20treated=20as=20URN=20namespaces.=0A=20=20=20=20=20=20= With=20regard=20to=20the=20structure=20of=20URNs=20assigned=20within=20= a=20namespace,=20the=20development=20of=20an=20identifier=20structure=20= (and=20thereby=20a=20collection=20of=20identifiers)=20depends=20on=20the=20= requirements=20of=20the=20community=20defining=20the=20identifiers,=20= how=20the=20identifiers=20will=20be=20assigned=20and=20used,=20etc.=20=20= These=20issues=20are=20beyond=20the=20scope=20of=20URN=20syntax=20and=20= the=20general=20rules=20for=20URN=20namespaces,=20because=20they=20are=20= specific=20to=20the=20community=20defining=20a=20namespace=20(e.g.,=20= the=20bibliographic=20and=20publishing=20communities=20in=20the=20case=20= of=20the=20'ISBN'=20and=20'ISSN'=20namespaces,=20or=20the=20developers=20= of=20extensions=20to=20the=20Extensible=20Messaging=20and=20Presence=20= Protocol=20in=20the=20case=20of=20the=20'XMPP'=20namespace).=0A=20=20= =20=20=20=20URN=20namespaces=20inherit=20certain=20rights=20and=20= responsibilities=20by=20the=20nature=20of=20URNs,=20e.g.:=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20They=20uphold=20the=20general=20principles=20= of=20a=20well-managed=20URN=20namespace=20by=20providing=20persistent=20= identification=20of=20resources=20and=20unique=20assignment=20of=20= identifier=20strings=20in=20accordance=20with=20a=20common=20= definition.=0A=20=20=20=20=20=20=20=20=20=20Optionally,=20they=20= can=20be=20registered=20in=20global=20registration=20services.=0A=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= There=20are=20two=20types=20of=20URN=20namespace:=20formal=20and=20= informal.=20=20These=20are=20distinguished=20by=20the=20expected=20level=20= of=20service,=20the=20information=20needed=20to=20define=20the=20= namespace,=20and=20the=20procedures=20for=20registration.=20=20Because=20= the=20majority=20of=20the=20namespaces=20registered=20so=20far=20have=20= been=20formal,=20this=20document=20concentrates=20on=20formal=20= namespaces.=0A=20=20=20=20=20=20Note:=20[RFC3406]=20defined=20a=20= third=20type=20of=20"experimental=20namespaces",=20denoted=20by=20= prefixing=20the=20namespace=20identifier=20with=20the=20string=20"X-".=20= =20Consistent=20with=20general=20IETF=20conclusions=20about=20similar=20= approaches=20,=20this=20specification=20= removes=20the=20experimental=20category=20and=20syntax.=20=20Because=20= experimental=20namespaces=20were=20never=20registered,=20removing=20the=20= experimental=20category=20has=20no=20impact=20on=20the=20existing=20= registries.=20=20However,=20to=20avoid=20the=20potential=20for=20= conflict=20between=20previously-allowed=20unregistered=20experimental=20= namespaces=20and=20namespaces=20registered=20in=20the=20future,=20no=20= registrations=20will=20be=20accepted=20for=20new=20namespaces=20= beginning=20with=20"X-".=20=20Because=20they=20are=20not=20registered,=20= strings=20that=20refer=20to=20experimental=20namespaces=20are=20not=20= valid=20URNs.=20=20Truly=20experimental=20usages=20MAY,=20of=20course,=20= employ=20the=20'example'=20namespace=20.=0A= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20A=20formal=20= namespace=20provides=20benefit=20to=20some=20subset=20of=0A=09=09=20=20=20= users=20on=20the=20Internet.=20=20In=20particular,=20it=20would=20not=20= make=0A=09=09=20=20=20sense=20for=20a=20formal=20namespace=20to=20be=20= used=20only=20by=20a=0A=09=09=20=20=20community=20or=20network=20that=20= is=20not=20connected=20to=20the=0A=09=09=20=20=20Internet.=20=20For=20= example,=20it=20would=20be=20inappropriate=20for=20a=0A=09=09=20=20=20= NID=20to=20effectively=20force=20someone=20to=20use=20a=20proprietary=0A=09= =09=20=20=20network=20or=20service=20not=20open=20to=20the=20general=20= Internet=20user.=0A=09=09=20=20=20The=20intent=20is=20that,=20while=20= the=20community=20of=20those=20who=20might=0A=09=09=20=20=20actively=20= use=20the=20names=20assigned=20within=20that=20NID=20might=20be=0A=09=09=20= =20=20small,=20the=20potential=20use=20of=20identifiers=20within=20that=20= NID=20is=0A=09=09=20=20=20open=20to=20any=20user=20on=20the=20Internet.=20= =20Formal=20NIDs=20might=20be=0A=09=09=20=20=20appropriate=20even=20when=20= some=20aspects=20are=20not=20fully=20open.=20=20For=0A=09=09=20=20=20= example,=20a=20namespace=20might=20make=20use=20of=20a=20fee-based,=0A=09= =09=20=20=20privately=20managed,=20or=20proprietary=20registry=20for=20= assignment=0A=09=09=20=20=20of=20URNs=20in=20the=20namespace.=20=20= However,=20it=20might=20still=20benefit=0A=09=09=20=20=20some=20Internet=20= users=20if=20the=20associated=20services=20have=0A=09=09=20=20=20= openly-published=20identifiers.=0A=20=20=20=20=20=20=20=20An=20= organization=20that=20will=20assign=20URNs=20within=20a=20formal=20= namespace=20SHOULD=20meet=20=0A=20=20=20=20=20=20=20=20=20=20=20the=20= following=20criteria:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20Organizational=20stability=20and=20the=20ability=20to=20= maintain=20the=20URN=20namespace=20for=20a=20long=20time;=20absent=20= such=20evidence,=20it=20ought=20to=20be=20clear=20how=20the=20namespace=20= can=20remain=20viable=20if=20the=20organization=20can=20no=20longer=20= maintain=20the=20namespace.=0A=20=20=20=20=20=20=20=20=20=20=20=20= Competency=20in=20name=20assignment.=20=20This=20will=20improve=20the=20= likelihood=20of=20persistence=20(e.g.=20to=20minimize=20the=20likelihood=20= of=20conflicts).=0A=20=20=20=20=20=20=20=20=20=20=20=20Commitment=20= to=20not=20reassigning=20existing=20names=20and=20to=20allowing=20old=20= names=20to=20continue=20to=20be=20valid=20(e.g.,=20if=20the=20assignee=20= of=20a=20name=20is=20no=20longer=20a=20member=20or=20customer=20of=20the=20= assigning=20organization,=20if=20various=20information=20about=20the=20= assignee=20or=20named=20entity=20happens=20to=20change,=20or=20even=20if=20= the=20assignee=20or=20the=20named=20entity=20itself=20is=20no=20longer=20= in=20existence;=20in=20all=20these=20cases,=20the=20name=20is=20still=20= valid).=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20A=20formal=20namespace=20= establishes=20a=20particular=20NID,=20subject=20to=20the=20following=20= constraints=20(above=20and=20beyond=20the=20syntax=20rules=20already=20= specified):=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20= It=20MUST=20NOT=20be=20an=20already-registered=20NID.=0A=20=20=20=20= =20=20=20=20=20=20=20=20It=20MUST=20NOT=20start=20with=20"urn-"=20= (which=20is=20reserved=20for=20informal=20namespaces).=0A=20=20=20=20= =20=20=20=20=20=20=20=20It=20MUST=20be=20more=20than=20two=20= characters=20long.=0A=20=20=20=20=20=20=20=20=20=20=20=20It=20= MUST=20NOT=20start=20with=20ALPHA=20ALPHA=20"-",=20i.e.,=20any=20string=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20consisting=20of=20two=20= letters=20followed=20by=20one=20hyphen.=0A=20=20=20=20=20=20=20=20=20= =20=20=20It=20MUST=20NOT=20start=20with=20the=20string=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"xn--"=20or=20any=20other=20string=20= consisting=20of=20two=20letters=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20followed=20by=20two=20hyphens.=20=20Such=20strings=20are=20reserved=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20for=20potential=20= representation=20of=20DNS=20A-labels=20and=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20similar=20strings=20in=20the=20future=20.=0A=20=20=20=20=20=20=20=20=20=20=20=20It=20= MUST=20NOT=20start=20with=20the=20string=20"X-"=20so=20that=20it=20will=20= not=20be=20confused=20with=20or=20conflict=20any=20experimental=20= namespace=20previously=20permitted=20by=20.=0A=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= All=20two-letter=20strings,=20and=20all=20two-letter=20strings=0A=09=09= =20=20=20followed=20by=20"-"=20and=20any=20sequence=20of=20valid=20NID=20= characters,=0A=09=09=20=20=20are=20reserved=20for=20potential=20use=20as=20= NIDs=20based=20on=20ISO=20alpha-2=0A=09=09=20=20=20country=20codes=20= =0A=09=09=20=20=20for=20eventual=20= national=20registrations=20of=20URN=20namespaces.=0A=09=09=20=20=20The=20= definition=20and=20scoping=20of=20rules=20for=20allocation=20of=0A=09=09=20= =20=20responsibility=20for=20such=20country-code-based=20namespaces=20is=0A= =09=09=20=20=20beyond=20the=20scope=20of=20this=20document.=0A=09=09=0A= =09=09=09Applicants=20and=20reviewers=20considering=20new=20NIDs=20= should=0A=09=09=09also=20be=20aware=20that=20they=20may=20be=20= considered=20as=20names=20with=0A=09=09=09semantic=20implications=20and=20= hence=20a=20source=20of=20conflict.=0A=09=09=09Particular=20attention=20= should=20be=20paid=20to=20strings=20that=0A=09=09=09might=20be=20= construed=20as=20names=20of,=20or=20registered=20under=20the=0A=09=09=09= authority=20of,=20countries=20(including=20ISO=203166-1=20alpha-3=0A=09=09= =09codes)=20and=20to=20strings=20that=20might=20imply=20association=20= with=0A=09=09=09existing=20URI=20schemes,=20identifier=20systems,=20or=20= trademarks.=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20However,=20in=20line=20with=20traditional=0A=09=09=09= policies,=20disputes=20about=20"ownership"=20of=20particular=0A=09=09=09= strings=20are=20disagreements=20among=20the=20parties=20involved;=0A=09=09= =09neither=20IANA=20nor=20the=20IETF=20will=20become=20involved=20in=20= such=0A=09=09=09disputes=20except=20in=20response=20to=20orders=20from=20= a=20court=20of=0A=09=09=09competent=20jurisdiction.=0A=20=20=20=20=20= =20=0A=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= Informal=20namespaces=20are=20full-fledged=20URN=20namespaces,=20with=20= all=20the=20associated=20rights=20and=20responsibilities.=20=20Informal=20= namespaces=20differ=20from=20formal=20namespaces=20in=20the=20process=20= for=20assigning=20a=20NID:=20for=20an=20informal=20namespace,=20the=20= registrant=20does=20not=20designate=20the=20NID;=20instead,=20IANA=20= assigns=20a=20NID=20consisting=20of=20the=20string=20'urn-'=20followed=20= by=20one=20or=20more=20digits=20(e.g.,=20"urn-7")=20where=20the=20digits=20= consist=20of=20the=20next=20available=20number=20in=20the=20sequence=20= of=20positive=20integers=20assigned=20to=20informal=20namespaces.=20=20= Thus=20the=20syntax=20of=20an=20informal=20namespace=20is:=0A=20=20=20= =20=20=20=20=20
=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20
=0A=20=20=20= =20=20=20=20=20The=20only=20restrictions=20on=20<Number>=20are=20= that=20it=20(1)=0A=09=09=20=20=20consist=20strictly=20of=20ASCII=20= digits,=20that=20it=20(2)=20not=20have=20leading=0A=09=09=20=20=20zeros,=20= and=20that=20it=20(3)=20not=20cause=20the=20NID=20to=20exceed=20the=0A=09= =09=20=20=20length=20limitations=20defined=20for=20the=20URN=20= syntax.=20=0A=20=20=20=20=20=20=0A=0A=20=20=20=20= =0A=0A=20=20=20=20=0A=0A=20=20=20= =20=20=20=0A= =20=20=20=20=20=20=20=20Because=20the=20space=20of=20URN=20namespaces=20= is=20itself=20managed,=20the=20definition=20=0A=20=20=20=20=20=20=20=20=20= =20=20of=20a=20namespace=20SHOULD=20pay=20particular=20attention=20= to:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20The=20purpose=20of=20= the=20namespace.=0A=20=20=20=20=20=20=20=20=20=20The=20syntax=20= of=20URNs=20assigned=20within=20the=20namespace,=20including=0A=20=20=20=20= =20=20=20=20=20=20=20=20the=20anticipated=20effects=20of=20q-components,=20= r-components,=0A=20=20=20=20=20=20=20=20=20=20=20=20and=20= f-components.=0A=20=20=20=20=20=20=20=20=20=20The=20process=20for=20= assigning=20URNs=20within=20the=20namespace.=0A=20=20=20=20=20=20=20=20= =20=20The=20security=20implications=20of=20assigning=20URNs=20within=20= the=20namespace=20and=20using=20the=20assigned=20URNs.=0A=20=20=20=20= =20=20=20=20=20=20Any=20potential=20interoperability=20issues=20with=20= URNs=20assigned=20within=20the=20namespace.=0A=20=20=20=20=20=20=20=20= =20=20Optionally,=20the=20process=20for=20resolving=20URNs=20issued=20= within=20the=20namespace.=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20The=20section=20on=20completing=20= the=20template=20()=20explains=20= these=20matters=20in=20greater=20detail.=20=20While=20the=20registration=20= templates=20are=20the=20same,=20slightly=20different=20procedures=20are=20= used=20depending=20on=20the=20source=20of=20the=20registration.=0A=0A= =20=20=20=20=20=20=0A=0A=20=20=20=20=20=20=0A=0A=20=20= =20=20=20=20=20=20The=20basic=20registration=20policy=20for=20URN=20= namespaces=20is=20Expert=0A=09=09=20=20=20Review=20as=20defined=20in=20= the=20"IANA=20Considerations"=20document=0A=09=09=20=20=20.=20=20For=20namespaces=20or=20their=0A=09=09=20=20=20= definitions=20that=20are=20intended=20to=20become=20standards=20or=0A=09=09= =20=20=20normative=20components=20of=20standards,=20the=20output=20of=20= the=20Expert=0A=09=09=20=20=20Review=20process=20is=20intended=20to=20be=20= a=20report,=20rather=20than=0A=09=09=20=20=20instructions=20to=20IANA=20= to=20take=20action=20(see=20below).=0A=09=09=20=20=20The=20key=20steps=20= are:=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= Fill=20out=20the=20namespace=20registration=20template=20(see=20=20and=20).=20= =20This=20can=20be=20done=20as=20part=20of=20an=20Internet-Draft=20or=20= a=20specification=20in=20another=20series,=20although=20that=20is=20not=20= necessary.=0A=20=20=20=20=20=20=20=20=20=20=20=20Send=20the=20= completed=20template=20to=20the=20urn@ietf.org=20discussion=20list=20for=20= review.=0A=20=20=20=20=20=20=20=20=20=20=20=20If=20necessary=20to=20= address=20comments=20received,=20repeat=20steps=201=20and=202.=0A=20=20= =20=20=20=20=20=20=20=20=20=20If=20the=20designated=20experts=20= approve=20the=20request=20and=20no=0A=09=09=09=20=20=20standardization=20= action=20is=20involved,=20the=20IANA=20will=0A=09=09=09=20=20=20register=20= the=20requested=20NID.=20=20If=20standardization=20is=0A=09=09=09=20=20=20= anticipated,=20the=20designated=20experts=20will=20prepare=20a=0A=09=09=09= =20=20=20report=20and=20forward=20it=20to=20the=20appropriate=20= standards=0A=09=09=09=20=20=20approval=20body=20(the=20IESG=20in=20the=20= case=20of=20the=20IETF)=20and=0A=09=09=09=20=20=20IANA=20will=20register=20= the=20requested=20NID=20only=20after=0A=09=09=09=20=20=20receiving=20= directions=20from=20that=20body=20and=20a=20copy=20of=20the=0A=09=09=09=20= =20=20expert=20review=20report.=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20A=20= namespace=20registration=20can=20be=20revised=20by=20updating=0A=09=09=20= =20=20the=20registration=20template,=20following=20the=20same=20steps=0A=09= =09=20=20=20outlined=20above=20for=20new=20registrations.=20=20A=20= revised=0A=09=09=20=20=20registration=20MUST=20describe=20differences=20= from=20prior=20versions=0A=09=09=20=20=20and=20SHOULD=20make=20special=20= note=20of=20any=20relevant=0A=09=09=20=20=20changes=20in=20the=20= underlying=20technologies=20or=20namespace=0A=09=09=20=20=20management=20= processes.=0A=20=20=20=20=20=20=20=20Experience=20to=20date=20= with=20namespace=20registration=20requests=20has=20shown=20that=20=0A=20=20= =20=20=20=20=20=20=20=20=20registrants=20sometimes=20do=20not=20= initially=20understand=20some=20of=20the=20subtleties=20=0A=20=20=20=20=20= =20=20=20=20=20=20of=20URN=20namespaces,=20and=20that=20defining=20the=20= namespace=20in=20the=20form=20of=20a=20=0A=20=20=20=20=20=20=20=20=20=20=20= specification=20enables=20the=20registrants=20to=20clearly=20formulate=20= their=20"contract"=20=0A=20=20=20=20=20=20=20=20=20=20=20with=20the=20= intended=20user=20community.=20=20Therefore,=20although=20the=20= registration=20=0A=20=20=20=20=20=20=20=20=20=20=20policy=20for=20formal=20= namespaces=20is=20Expert=20Review=20and=20a=20specification=20is=20=0A=20= =20=20=20=20=20=20=20=20=20=20not=20strictly=20required,=20it=20is=20= RECOMMENDED=20for=20registrants=20to=20provide=20a=20stable=20=0A=20=20=20= =20=20=20=20=20=20=20=20specification=20documenting=20the=20namespace=20= definition=20and=20expanding=20upon=20the=0A=20=20=20=20=20=20=20=20=20=20= =20issues=20described=20herein.=0A=20=20=20=20=20=20=20=20Because=20= naming=20can=20be=20difficult=20and=20contentious,=20namespace=20= registrants=20and=20the=0A=20=20=20=20=20=20=20=20=20=20=20designated=20= experts=20are=20strongly=20encouraged=20to=20work=20together=20in=20a=20= spirit=20of=20good=20=0A=20=20=20=20=20=20=20=20=20=20=20faith=20and=20= mutual=20understanding=20to=20achieve=20rough=20consensus=20=0A=20=20=20=20= =20=20=20=20=20=20=20(see=20)=20on=20= handling=20registration=20=0A=20=20=20=20=20=20=20=20=20=20=20requests.=20= =20They=20are=20also=20encouraged=20to=20bring=20additional=20expertise=20= into=20the=20=0A=20=20=20=20=20=20=20=20=20=20=20discussion=20if=20that=20= would=20be=20helpful=20in=20providing=20perspective=20or=20otherwise=20=0A= =20=20=20=20=20=20=20=20=20=20=20resolving=20issues.=0A=09=09= Especially=20when=20iterations=20in=20the=20registration=20process=20= are=0A=09=09=20=20=20prolonged,=20designated=20experts=20are=20expected=20= to=20take=0A=09=09=20=20=20reasonable=20precautions=20to=20avoid=20race=20= conditions=20on=20proposed=0A=09=09=20=20=20NID=20names=20and,=20if=20= such=20situations=20arise,=20to=20encourage=0A=09=09=20=20=20applicants=20= to=20work=20out=20any=20conflicts=20among=20themselves.=0A=0A=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20The=20IETF=20recognizes=20that=20situations=20will=20= arise=20in=20which=20URN=20namespaces=20will=20be=20created=20to=20= either=20embed=20existing=20and=20established=20standards=20or=20to=20= reflect=20knowledge,=20terminology,=20or=20information=20organization=20= that=20lie=20well=20outside=20the=20IETF's=20scope=20or=20the=20likely=20= subject=20matter=20knowledge=20of=20its=20Designated=20Experts.=20=20In=20= situations=20in=20which=20the=20registration=20request=20originates=20= from,=20or=20is=20authorized=20by,=20a=20recognized=20standards-related=20= organization,=20scientific=20society,=20or=20similar=20body,=20a=20= somewhat=20different=20procedure=20is=20available=20at=20the=20option=20= of=20that=20body:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= The=20namespace=20registration=20template=20is=20filled=20out=20and=20= submitted=20as=20in=20steps=201=20and=202=20above.=0A=20=20=20=20=20=20= =20=20=20=20=20=20A=20specification=20is=20required=20that=20reflects=20= of=20points=20to=20the=20needed=20external=20standards=20or=20= specifications.=20=20Publication=20in=20the=20RFC=20Series=20or=20= through=20an=20IETF=20process=20(e.g.,=20posting=20as=20an=20Internet=20= Draft)=20is=20not=20expected=20and=20would=20be=20appropriate=20only=20= under=20very=20unusual=20circumstances.=0A=20=20=20=20=20=20=20=20=20= =20=20=20The=20reviews=20on=20the=20discussion=20list=20and=20by=20= the=20designated=20experts=20are,=20however,=20strictly=20advisory,=20= with=20the=20decisions=20about=20what=20advice=20to=20accept=20and=20the=20= length=20of=20time=20to=20allocate=20to=20the=20process=20strictly=20= under=20the=20control=20of=20the=20external=20body.=0A=20=20=20=20=20= =20=20=20=20=20=20=20When=20that=20body=20concludes=20that=20the=20= application=20is=20sufficiently=20mature,=20they=20will=20request=20that=20= IANA=20will=20complete=20the=20registration=20for=20the=20NID=20and=20= IANA=20will=20do=20so.=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20Decisions=20about=20= whether=20to=20recognize=20the=20requesting=20entity=20as=20a=20= standards-related=20organization,=20scientific=20society,=20or=20similar=20= body=20are=20the=20responsibility=20of=20the=20IESG.=0A=20=20=20=20=20= =20=20=20Note=20that=20a=20similar=20model=20has=20already=20been=20= defined=20for=20recognized=20standards-related=20organizations=20that=20= wish=20to=20register=20Media=20Types.=20=20The=20document=20describing=20= that=20mechanism=20=20provides=20somewhat=20= more=20information=20about=20the=20general=20approach.=0A=20=20=20=20= =20=20=0A=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20A=20template=20for=20defining=20and=20registering=20a=20URN=20= namespace=20is=20provided=20in=20.=20=20= This=20section=20describes=20considerations=20for=20completing=20the=20= template.=20=0A=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20The=20= "Purpose"=20section=20of=20the=20template=20describes=20matters=20such=20= as:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20The=20= kinds=20of=20resources=20identified=20by=20URNs=20assigned=20within=20= the=20namespace.=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20= scope=20and=20applicability=20of=20the=20URNs=20assigned=20within=20the=20= namespace;=20this=20might=20include=20information=20about=20the=20= community=20of=20use=20(e.g.,=20a=20particular=20nation,=20industry,=20= technology,=20or=20organization),=20whether=20the=20assigned=20URNs=20= will=20be=20used=20on=20public=20networks=20or=20private=20networks,=20= etc.=0A=20=20=20=20=20=20=20=20=20=20=20=20How=20the=20intended=20= community=20(and=20the=20Internet=20community=20at=20large)=20will=20= benefit=20from=20using=20or=20resolving=20the=20assigned=20URNs.=0A=20= =20=20=20=20=20=20=20=20=20=20=20How=20the=20namespace=20relates=20to=20= and=20complements=20existing=20URN=20namespaces,=20URI=20schemes,=20and=20= identifier=20systems.=0A=20=20=20=20=20=20=20=20=20=20=20=20The=20= kinds=20of=20software=20applications=20that=20can=20use=20or=20resolve=20= the=20assigned=20URNs=20(e.g.,=20by=20differentiating=20among=20= disparate=20namespaces,=20identifying=20resources=20in=20a=20persistent=20= fashion,=20or=20meaningfully=20resolving=20and=20accessing=20services=20= associated=20with=20the=20namespace).=0A=20=20=20=20=20=20=20=20=20=20= =20=20Whether=20resolution=20services=20are=20available=20or=20will=20= be=20available=20(and,=20if=20so,=20the=20nature=20or=20identity=20of=20= the=20services).=20=20Examples=20of=20q-=20and=20r-component=20semantics=20= and=20syntax=20are=20helpful=20here,=20even=20if=20they=20are=20= registered=20or=20defined=20elsewhere=20later.=0A=20=20=20=20=20=20=20= =20=20=20=20=20Whether=20the=20namespace=20or=20its=20definition=20= are=20expected=20to=20become=20an=20integral=20or=20normative=20element=20= of=20a=20standard=20being=20developed=20in=20the=20IETF=20or=20some=20= other=20recognized=20standards=20body.=0A=09=09=20=20=0A=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=0A=0A=20=20=20= =20=20=20=0A=20= =20=20=20=20=20=20=20The=20"Syntax"=20section=20of=20the=20template=20= contains:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20A=20= description=20of=20the=20structure=20of=20URNs=20within=20the=20= namespace,=20in=20conformance=20with=20the=20fundamental=20URN=20syntax.=20= =20The=20structure=20might=20be=20described=20in=20terms=20of=20a=20= formal=20definition=20(e.g.,=20using=20Augmented=20BNF=20for=20Syntax=20= Specifications=20(ABNF)=20as=20specified=20in=20),=20an=20algorithm=20for=20generating=20conformant=20= URNs,=20or=20a=20regular=20expression=20for=20parsing=20the=20identifier=20= into=20components;=20alternatively,=20the=20structure=20might=20be=20= opaque.=0A=20=20=20=20=20=20=20=20=20=20=20=20Any=20special=20= character=20encoding=20rules=20for=20assigned=20URNs=0A=09=09=09=20=20=20= (e.g.,=20which=20character=20ought=20to=20always=20be=20used=20for=0A=09=09= =09=20=20=20quotes).=0A=20=20=20=20=20=20=20=20=20=20=20=20Rules=20= for=20determining=20equivalence=20between=20two=0A=09=09=09=20=20=20= identifiers=20in=20the=20namespace.=20=20Such=20rules=20ought=20to=0A=09=09= =09=20=20=20always=20have=20the=20effect=20of=20eliminating=20false=20= negatives=0A=09=09=09=20=20=20that=20might=20otherwise=20result=20from=20= comparison.=20=20If=20it=20is=0A=09=09=09=20=20=20appropriate=20and=20= helpful,=20reference=20can=20be=20made=20to=0A=09=09=09=20=20=20specific=20= equivalence=20rules=20defined=20in=20the=20URI=0A=09=09=09=20=20=20= specification=20.=0A=09=09=09=20=20=20=0A=09=09=09=20= =20=20Examples=20of=0A=09=09=09=20=20=20equivalence=20rules=20include=20= equivalence=20between=0A=09=09=09=20=20=20uppercase=20and=20lowercase=20= characters=20in=20the=20Namespace=0A=09=09=09=20=20=20Specific=20String,=20= between=20hyphenated=20and=20non-hyphenated=0A=09=09=09=20=20=20= groupings=20in=20the=20identifier=20string,=20or=20between=0A=09=09=09=20= =20=20single-quotes=20and=20double-quotes.=0A=09=09=09=20=20=20=0A=09=09= =09=20=20=20(Note=20that=20these=20are=0A=09=09=09=20=20=20not=20= normative=20statements=20for=20any=20kind=20of=20best=20practice=0A=09=09= =09=20=20=20related=20to=20handling=20of=20equivalences=20between=20= characters=0A=09=09=09=20=20=20in=20general;=20they=20are=20statements=20= limited=20to=20one=20particular=20namespace=20only.)=0A=20=20=20=20=20= =20=20=20=20=20=20=20Any=20special=20considerations=20necessary=20for=20= conforming=20with=20the=20URN=20syntax.=20=20This=20is=20particularly=20= applicable=20in=20the=20case=20of=20existing=20naming=20systems=20that=20= are=20used=20in=20the=20context=20of=20URNs.=20=20For=20example,=20if=20= a=20namespace=20is=20used=20in=20contexts=20other=20than=20URNs,=20it=20= might=20make=20use=20of=20characters=20that=20are=20reserved=20in=20the=20= URN=20syntax.=20=20This=20section=20ought=20to=20note=20any=20such=20= characters,=20and=20outline=20necessary=20mappings=20to=20conform=20to=20= URN=20syntax.=20=20Normally,=20this=20will=20be=20handled=20by=20= percent-encoding=20the=20character=20as=20specified=20in=20Section=202.1=20= of=20the=20URI=20specification=20.=0A=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20The=20= "Assignment"=20section=20of=20the=20template=20describes=20matters=20= such=20as:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20= Mechanisms=20or=20authorities=20for=20assigning=20URNs=20to=0A=09=09=09= =20=20=20resources.=20=20It=20ought=20to=20make=20clear=20whether=20= assignment=0A=09=09=09=20=20=20is=20completely=20open=20(e.g.,=20= following=20a=20particular=0A=09=09=09=20=20=20procedure=20such=20as=20= first-come,=20first-served=20(FCFS)),=0A=09=09=09=20=20=20completely=20= closed=20(e.g.,=20for=20a=20private=20=0A=09=09=09=20=20=20= organization),=20or=20limited=20in=20various=20ways=20(e.g.,=0A=09=09=09=20= =20=20delegated=20to=20authorities=20recognized=20by=20a=20particular=0A=09= =09=09=20=20=20organization);=20if=20limited,=20it=20ought=20to=20= explain=20how=20to=0A=09=09=09=20=20=20become=20an=20assigner=20of=20= identifiers=20or=20how=20to=20request=0A=09=09=09=20=20=20assignment=20= of=20identifiers=20from=20existing=20assignment=20authorities.=0A=20=20= =20=20=20=20=20=20=20=20=20=20Methods=20for=20ensuring=20that=20URNs=20= within=20the=20namespace=20are=20unique.=20=20For=20example,=20= identifiers=20might=20be=20assigned=20sequentially=20or=20in=20= accordance=20with=20some=20well-defined=20process=20by=20a=20single=20= authority,=20assignment=20might=20be=20partitioned=20among=20delegated=20= authorities=20that=20are=20individually=20responsible=20for=20respecting=20= uniqueness=20rules,=20or=20URNs=20might=20be=20created=20independently=20= following=20an=20algorithm=20that=20itself=20guarantees=20= uniqueness.=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=0A=20=20=20=20=20=20=0A=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20The=20= "Security=20and=20Privacy"=20section=20of=20the=20template=20describes=20= any=20potential=20issues=20related=20to=20security=20and=20privacy=20= with=20regard=20to=20assignment,=20use,=20and=20resolution=20of=20= identifiers=20within=20the=20namespace.=20=20Examples=20of=20such=20= issues=20include:=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= The=20consequences=20of=20producing=20false=20negatives=20and=20false=20= positives=20during=20comparison=20for=20equivalence=20(see=20"Issues=20= in=20Identifier=20Comparison=20for=20Security=20Purposes"=20)=0A=20=20=20=20=20=20=20=20=20=20=20=20= Leakage=20of=20private=20information=20when=20identifiers=20are=20= communicated=20on=20the=20public=20Internet=0A=20=20=20=20=20=20=20=20= =20=20=20=20The=20potential=20for=20directory=20harvesting=0A=20=20= =20=20=20=20=20=20=20=20=20=20Various=20issues=20discussed=20in=20the=20= guidelines=20for=20security=20considerations=20in=20RFCs=20=20and=20the=20privacy=20considerations=20for=20= Internet=20protocols=20.=20=0A=20=20=20=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=0A=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20The=20"Interoperability"=20section=20MUST=20specify=20= any=20potential=20issues=0A=20=20=20=20=20=20=20=20=20=20related=20to=20= interoperability.=20=20Examples=20include=20possible=20confusion=0A=20=20= =20=20=20=20=20=20=20=20with=20other=20URN=20namespaces=20or=20naming=20= systems=20because=20of=20syntax=20(e.g.,=0A=20=20=20=20=20=20=20=20=20=20= percent-encoding=20of=20certain=20characters)=20or=20scope=20(e.g.,=20= overlapping=0A=20=20=20=20=20=20=20=20=20=20areas=20of=20interest).=20=20= If=20at=20all=20possible,=20concerns=20that=0A=09=09=20=20arise=20during=20= the=20registration=20of=20a=20URN=20namespace=20(e.g.,=20due=20to=0A=09=09= =20=20the=20syntax=20or=20scope=20of=20an=20identifier=20system)=20= SHOULD=0A=09=09=20=20be=20resolved=20as=20part=20of=20the=20registration=20= process.=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=0A= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20The=20= "Resolution"=20section=20MUST=20specify=20whether=20resolution=20= mechanisms=0A=20=20=20=20=20=20=20=20=20=20=20are=20intended=20or=20= anticipated=20for=20URNs=20assigned=20within=20the=0A=20=20=20=20=20=20=20= =20=20=20=20namespace=20(e.g.,=20URNs=20within=20some=20namespaces=20are=20= intended=20to=20act=20as=0A=20=20=20=20=20=20=20=20=20=20=20abstract=20= designators=20and=20thus=20are=20not=20intended=20to=20be=20resolved).=0A= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20If=20= resolution=20is=20intended,=20then=20this=20section=20SHOULD=20specify=20= whether=20the=20=0A=20=20=20=20=20=20=20=20=20=20=20organization=20that=20= assigns=20URNs=20within=20the=20namespace=20intends=20to=20operate=20or=20= =0A=20=20=20=20=20=20=20=20=20=20=20recommend=20any=20resolution=20= services=20for=20URNs=20within=20that=20namespace.=20=20In=20=0A=20=20=20= =20=20=20=20=20=20=20=20addition,=20if=20the=20assigning=20organization=20= intends=20to=20implement=20registration=20=0A=20=20=20=20=20=20=20=20=20=20= =20for=20publicly=20advertised=20resolution=20services=20(for=20example=20= using=20a=20system=20=0A=20=20=20=20=20=20=20=20=20=20=20based=20on=20= principles=20similar=20to=20those=20described=20in=20=0A=20=20=20=20=20=20=20=20=20=20=20and=20),=20then=20this=20section=20SHOULD=20=0A=20=20=20=20= =20=20=20=20=20=20=20list=20or=20reference=20the=20requirements=20for=20= being=20publicly=20advertised=20by=20the=20=0A=20=20=20=20=20=20=20=20=20= =20=20assigning=20organization.=0A=20=20=20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20[[NB:=20This=20section=20should=20also=20be=20updated=20= to=20allow=20definitions=0A=20=20=20=20=20=20=20=20=20=20or=20pointers=20= to=20definitions=20of=20oidops=0A=20=20=20= =20=20=20=20=20=20=20and=20urnops.]]=0A= =20=20=20=20=20=20=0A=0A=20=20=20=20=0A=20=20=20=20= =0A=0A=20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20This=20section=20= updates=20the=20registration=20of=20the=20'urn'=20URI=0A=09=09=20=20=20= scheme=20in=20the=20Permanent=20URI=20Registry=20=20.=0A=20=20=20=20=20=20=20=20[Note=20= to=20RFC=20Editor:=20please=20replace=20"[=20&ThisDoc;=20]"=20with=0A=09=09= =20=20=20"RFC"=20and=20the=20number=20assigned=20to=20this=20document=20= upon=20publication.]=0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20urn=0A=20=20=20=20=20=20=20= =20=20=20=20=20permanent=0A=20=20=20=20=20=20= =20=20=20=20=20=20See=0A=09=09=09= =20=20=20=20of=20[=20&ThisDoc;=20].=0A=20=20= =20=20=20=20=20=20=20=20=20=20The=20'urn'=20scheme=20identifies=20Uniform=20Resource=20= Names,=20which=20are=20persistent,=20location-independent=20resource=20= identifiers.=0A=20=20=20=20=20=20=20=20=20=20=20=20See=0A=09=09=09=20=20=20=20of=20[=20&ThisDoc;=20].=0A=20=20=20=20=20=20=20= =20=20=20=20=20Uniform=20Resource=20Names=20are=20used=20= in=20a=20wide=20variety=20of=20applications,=20including=20bibliographic=20= reference=20systems=20and=20as=20names=20for=20Extensible=20Markup=20= Language=20(XML)=20namespaces.=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=09=09=09=20=20=20= See=20=20of=20[=20&ThisDoc;=20].=0A=20= =20=20=20=20=20=20=20=20=20=20=20See=0A=09=09=09=20=20=20=20and=0A=09=09=09=20=20=20=20=20of=20[=20&ThisDoc;=20].=0A=20=20=20=20=20=20= =20=20=20=20=20=20URNBIS=20WG=20= [mailto:urn@ietf.org]=0A=20=20=20=20=20=20=20=20=20=20=20=20This=20scheme=20is=20registered=20= under=20the=20IETF=20tree.=20=20As=20such,=20the=20IETF=20maintains=20= change=20control.=0A=20=20=20=20=20=20=20=20=20=20=20=20None.=0A=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=0A=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20This=20document=20= outlines=20the=20processes=20for=20registering=20URN=20namespaces,=20and=20= has=20implications=20for=20the=20IANA=20in=20terms=20of=20registries=20= to=20be=20maintained=20(see=20especially=20).=20=20In=20all=20cases,=20the=20IANA=20ought=20= to=20assign=20the=20appropriate=20NID=20(formal=20or=20informal)=20once=20= the=20procedures=20outlined=20in=20this=20document=20have=20been=20= completed.=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20IANA=20is=20to=20= update=20the=20text/uri-list=20media=20type=20with=20the=20following=20= registration=20template:=0A=20=20=20=20=20=20=20=20=
=20and=20pairs=20are=20delimited=0A=20=20= by=20",".=20Names=20that=20are=20not=20basic=20keywords/symbols=20MUST=20= be=20quoted.=0A=20=20The=20value=20is=20a=20JSON=20value.=20Essentially=20= the=20syntax=20looks=20like=0A=20=20a=20JavaScript=20object=20with=20the=20= enclosing=20{=20}=20braces=20cut=20off.=0A=20=20=0A=20=20When=20the=20= attrfmt=20is=20"cbor-base64":=0A=20=20=0A=20=20Attribute=20syntax=20is=20= the=20base64=20encoding=20of=20a=20CBOR-encoded=20item.=0A=20=20The=20= CBOR=20item=20is=20a=20map=20where=20the=20keys=20are=20anything=20and=20= the=20values=0A=20=20are=20anything.=0A=20=20=0A=20=20Additional=20= attrfmt=20values=20can=20be=20provided:=20the=20standard=0A=20=20for=20= adding=20such=20values=20is=20RFC=20Required=20[RFC5226].=0A=20=20=0A=20=20= 3)=20As=20for=20all=20text/*=20formats,=20lines=20are=20terminated=20= with=20a=20CRLF=20pair.=0A=0A=20=20In=20applications=20where=20one=20URI=20= has=20been=20mapped=20to=20a=20list=20of=20URIs,=20the=0A=20=20first=20= line=20of=20the=20text/uri-list=20response=20SHOULD=20be=20a=20comment=20= giving=0A=20=20the=20original=20URI.=0A=0A=20=20An=20example=20of=20the=20= format=20is=20given=20below:=0A=0A=20=20#=20urn:isbn:0-201-08372-8=0A=20=20= http://www.huh.org/books/foo.html=0A=20=20= http://www.huh.org/books/foo.pdf=0A=20=20= ftp://ftp.foo.org/books/foo.txt|font=3D"Inconsolata",ct=3D"text/plain"=0A= =0AApplications=20that=20use=20this=20media=20type:=0A=0A=20=20URN=20= resolvers=20are=20the=20initial=20applications.=0A=20=20Web=20clients=20= and=20proxies=20are=20applicaitons=20that=20are=20likely=0A=20=20to=20= support=20this=20format=20in=20the=20future.=0A=0AFragment=20identifier=20= considerations:=20None.=0A=0AAdditional=20information:=0A=0A=20=20Magic=20= number(s):=20None=0A=20=20File=20extension(s):=20.uris,=20.uri=0A=20=20= Macintosh=20file=20type=20code(s):=0A=20=20=20=20URIs=20or=20TEXT.=20A=20= uniform=20type=20identifier=20(UTI)=20of=0A=20=20=20=20"public.XXX",=20= which=20conforms=20to=20"public.plain-text",=0A=20=20=20=20is=20= RECOMMENDED.=0A=0APerson=20&=20email=20address=20to=20contact=20for=20= further=20information:=0A=0A=20=20Sean=20Leonard=20= =0A=0ARestrictions=20on=20usage:=20None.=0A=0A= Author/Change=20controller:=20The=20IESG=0A=0AIntended=20usage:=20= LIMITED=20USE=0A=20=20The=20text/uri-list=20media=20type=20is=20intended=20= for=20use=20in=20applications=0A=20=20that=20use=20URIs=20for=20= replicated=20resources.=0A=0AProvisional=20registration?=20No=0A=0A[[NB:=20= put=20other=20things=20here]]=0A= [[andblahblahblah]]]]>
=0A=20=20=20=20=20=20=0A= =20=20=20=20=0A=0A=20=20=20=20=0A=20=20=20=20=20=20= The=20definition=20of=20a=20URN=20namespace=20needs=20to=20account=20= for=20potential=20security=20and=20privacy=20issues=20related=20to=20= assignment,=20use,=20and=20resolution=20of=20identifiers=20within=20the=20= namespace=20(e.g.,=20some=20namespace=20resolvers=20might=20assign=20= special=20meaning=20to=20certain=20characters=20in=20the=20Namespace=20= Specific=20String);=20see=20=20= for=20further=20discussion.=0A=20=20=20=20=20=20In=20most=20= cases,=20URN=20namespaces=20provide=20a=20way=20to=20declare=20public=20= information.=20=20Nominally,=20these=20declarations=20will=20have=20a=20= relatively=20low=20security=20profile,=20however=20there=20is=20always=20= the=20danger=20of=20"spoofing"=20and=20providing=20misinformation.=20=20= Information=20in=20these=20declarations=20ought=20to=20be=20taken=20as=20= advisory.=0A=20=20=20=20=0A=0A=20=20=0A=0A=20=20= =0A=0A=20=20=20=20=0A= =0A=0A=0AASCII=20format=20= for=20network=20interchange=0A=0AUniversity=20= California=20Los=20Angeles=20(UCLA)=0A=0A=0A= For=20concreteness,=20we=20suggest=20the=20use=20of=20standard=20= 7-bit=20ASCII=20embedded=20in=20an=208=20bit=20byte=20whose=20high=20= order=20bit=20is=20always=200.=0A=0A=0A=0A=0A=0A=0A= Key=20words=20for=20use=20in=20= RFCs=20to=20Indicate=20Requirement=20Levels=0A=0A= Harvard=20University=0A
=0A=0A= 1350=20Mass.=20Ave.=0ACambridge=0A= MA=2002138=0A-=20+1=20617=20495=20= 3864=0Asob@harvard.edu
=0A=0AGeneral=0A= keyword=0A=0A=0A=20=20=20In=20many=20= standards=20track=20documents=20several=20words=20are=20used=20to=20= signify=0A=20=20=20the=20requirements=20in=20the=20specification.=20=20= These=20words=20are=20often=0A=20=20=20capitalized.=20=20This=20document=20= defines=20these=20words=20as=20they=20should=20be=0A=20=20=20interpreted=20= in=20IETF=20documents.=20=20Authors=20who=20follow=20these=20guidelines=0A= =20=20=20should=20incorporate=20this=20phrase=20near=20the=20beginning=20= of=20their=20document:=0A=0A=0A=20=20=20=20=20=20The=20key=20= words=20"MUST",=20"MUST=20NOT",=20"REQUIRED",=20"SHALL",=20"SHALL=0A=20=20= =20=20=20=20NOT",=20"SHOULD",=20"SHOULD=20NOT",=20"RECOMMENDED",=20=20= "MAY",=20and=0A=20=20=20=20=20=20"OPTIONAL"=20in=20this=20document=20are=20= to=20be=20interpreted=20as=20described=20in=0A=20=20=20=20=20=20RFC=20= 2119.=0A=0A=0A=20=20=20Note=20that=20the=20force=20of=20= these=20words=20is=20modified=20by=20the=20requirement=0A=20=20=20level=20= of=20the=20document=20in=20which=20they=20are=20used.=0A= =0A=0A= =0A=0A=0A= =0A= =0A=0A=0A=0AUniform=20Resource=20Identifier=20= (URI):=20Generic=20Syntax=0A=0A= World=20Wide=20Web=20= Consortium=0A
=0A=0AMassachusetts=20= Institute=20of=20Technology=0A77=20Massachusetts=20= Avenue=0ACambridge=0AMA=0A= 02139=0AUSA=0A= +1-617-253-5702=0A+1-617-258-5999=0A= timbl@w3.org=0A= http://www.w3.org/People/Berners-Lee/
=0A= =0ADay=20= Software=0A
=0A=0A5251=20= California=20Ave.,=20Suite=20110=0AIrvine=0A= CA=0A92617=0A= USA=0A+1-949-679-2960=0A= +1-949-679-2972=0A= fielding@gbiv.com=0A= http://roy.gbiv.com/
=0A=0A= Adobe=20Systems=20= Incorporated=0A
=0A=0A345=20Park=20= Ave=0ASan=20Jose=0ACA=0A= 95110=0AUSA=0A= +1-408-536-3024=0ALMM@acm.org=0A= http://larry.masinter.net/
=0A=0AApplications=0A= uniform=20resource=20identifier=0A= URI=0AURL=0AURN=0A= WWW=0Aresource=0A=0A=0A= A=20Uniform=20Resource=20Identifier=20(URI)=20is=20a=20compact=20= sequence=20of=20characters=0Athat=20identifies=20an=20abstract=20or=20= physical=20resource.=20=20This=20specification=0Adefines=20the=20generic=20= URI=20syntax=20and=20a=20process=20for=20resolving=20URI=20references=0A= that=20might=20be=20in=20relative=20form,=20along=20with=20guidelines=20= and=20security=0Aconsiderations=20for=20the=20use=20of=20URIs=20on=20the=20= Internet.=0AThe=20URI=20syntax=20defines=20a=20grammar=20that=20is=20a=20= superset=20of=20all=20valid=20URIs,=0Aallowing=20an=20implementation=20= to=20parse=20the=20common=20components=20of=20a=20URI=0Areference=20= without=20knowing=20the=20scheme-specific=20requirements=20of=20every=0A= possible=20identifier.=20=20This=20specification=20does=20not=20define=20= a=20generative=0Agrammar=20for=20URIs;=20that=20task=20is=20performed=20= by=20the=20individual=0Aspecifications=20of=20each=20URI=20scheme.=0A= =0A=0A= =0A=0A=0A= =0A= =0A=0A=0A=0A= Guidelines=20for=20Writing=20an=20IANA=20Considerations=20Section=20= in=20RFCs=0A=0A=0A=0A= =0A=0A= =0AMany=20protocols=20make=20use=20of=20identifiers=20= consisting=20of=20constants=20and=20other=20well-known=20values.=20Even=20= after=20a=20protocol=20has=20been=20defined=20and=20deployment=20has=20= begun,=20new=20values=20may=20need=20to=20be=20assigned=20(e.g.,=20for=20= a=20new=20option=20type=20in=20DHCP,=20or=20a=20new=20encryption=20or=20= authentication=20transform=20for=20IPsec).=20To=20ensure=20that=20such=20= quantities=20have=20consistent=20values=20and=20interpretations=20across=20= all=20implementations,=20their=20assignment=20must=20be=20administered=20= by=20a=20central=20authority.=20For=20IETF=20protocols,=20that=20role=20= is=20provided=20by=20the=20Internet=20Assigned=20Numbers=20Authority=20= (IANA).</t><t>=20In=20order=20for=20IANA=20to=20manage=20a=20given=20= namespace=20prudently,=20it=20needs=20guidelines=20describing=20the=20= conditions=20under=20which=20new=20values=20can=20be=20assigned=20or=20= when=20modifications=20to=20existing=20values=20can=20be=20made.=20If=20= IANA=20is=20expected=20to=20play=20a=20role=20in=20the=20management=20of=20= a=20namespace,=20IANA=20must=20be=20given=20clear=20and=20concise=20= instructions=20describing=20that=20role.=20This=20document=20discusses=20= issues=20that=20should=20be=20considered=20in=20formulating=20a=20policy=20= for=20assigning=20values=20to=20a=20namespace=20and=20provides=20= guidelines=20for=20authors=20on=20the=20specific=20text=20that=20must=20= be=20included=20in=20documents=20that=20place=20demands=20on=20= IANA.</t><t>=20This=20document=20obsoletes=20RFC=202434.=20This=20= document=20specifies=20an=20Internet=20Best=20Current=20Practices=20for=20= the=20Internet=20Community,=20and=20requests=20discussion=20and=20= suggestions=20for=20improvements.=0A=0A=0A=0A=0A= =0A=0A=0AAugmented=20BNF=20= for=20Syntax=20Specifications:=20ABNF=0A=0A=0A=0A=0A=0A=0AInternet=20= technical=20specifications=20often=20need=20to=20define=20a=20formal=20= syntax.=20=20Over=20the=20years,=20a=20modified=20version=20of=20= Backus-Naur=20Form=20(BNF),=20called=20Augmented=20BNF=20(ABNF),=20has=20= been=20popular=20among=20many=20Internet=20specifications.=20=20The=20= current=20specification=20documents=20ABNF.=20=20It=20balances=20= compactness=20and=20simplicity=20with=20reasonable=20representational=20= power.=20=20The=20differences=20between=20standard=20BNF=20and=20ABNF=20= involve=20naming=20rules,=20repetition,=20alternatives,=20= order-independence,=20and=20value=20ranges.=20=20This=20specification=20= also=20supplies=20additional=20rule=20definitions=20and=20encoding=20for=20= a=20core=20lexical=20analyzer=20of=20the=20type=20common=20to=20several=20= Internet=20specifications.=20[STANDARDS-TRACK]=0A= =0A=0A=0A=0A=0A=0A=0A=20=20= =0A=20=20=20=20Comprehensive=20Core=20Rules=20and=20= References=20for=20ABNF=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20=20= =0A=20=20=20=20=0A=20=20=20=20This=20document=20extends=20= the=20base=20definition=20of=20ABNF=20(Augmented=20Backus-=20Naur=20= Form)=20to=20include=20comprehensive=20support=20for=20certain=20symbols=20= related=20to=20ASCII,=20and=20defines=20a=20reference=20syntax.=0A=20=20=20= =20=0A=20=20=20=20=0A=20=20=0A=20=20=0A=20=20=0A=0A=0A=0A=20= =20=0A=20=20=20=20=0A=20=20=20=20=20=20Information=20= Technology=20-=20Procedures=20for=20the=0A=20=20=20=20=20=20operation=20= of=20object=20identifier=20registration=0A=20=20=20=20=20=20authorities:=20= General=20procedures=20and=20top=20arcs=20of=0A=20=20=20=20=20=20the=20= international=20object=20identifier=20tree=0A=20=20=20=20=0A=20=20= =20=20=0A=20=20=20=20=20=20International=20= Telecommunications=20Union=0A=20=20=20=20=0A=20=20= =20=20=0A=20=20=0A=20=20= =0A= =0A=0A=0A=20=20=0A=20=20= =20=20=0A=20=20=20=20=20=20Information=20Technology=20-=20= Abstract=20Syntax=20Notation=20One=20(ASN.1):=20Specification=20of=20= basic=20notation=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=20= =20=20=20International=20Telecommunications=20= Union=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=0A=20=20=0A=0A=0A=20= =20=20=20=0A=0A=20=20=20=20=0A=0A=0A=0AURN=20= Semantics=20Clarification=0A=0A=20=20=20=20= =0A=0A=0AExperience=20has=20shown=20that=20= identifiers=20associated=20with=20persistent=20names=20have=20properties=20= and=20requirements=20that=20may=20be=20somewhat=20different=20from=20= identifiers=20associated=20with=20the=20locations=20of=20objects.=20=20= This=20is=20especially=20true=20when=20such=20names=20are=20expected=20= to=20be=20stable=20for=20a=20very=20long=20time=20or=20when=20they=20= identify=20large=20and=20complex=20entities.=20=20In=20order=20to=20= allow=20Uniform=20Resource=20Names=20(URNs)=20to=20evolve=20to=20meet=20= the=20needs=20of=20the=20Library,=20Museum,=20Publisher,=20and=20= Informational=20Sciences=20communities=20and=20other=20users,=20this=20= specification=20separates=20URNs=20from=20the=20semantic=20constraints=20= that=20many=20people=20believe=20are=20part=20of=20the=20specification=20= for=20Uniform=20Resource=20Identifiers=20(URIs)=20specified=20in=20RFC=20= 3986,=20updating=20that=20document=20accordingly.=20=20The=20syntax=20of=20= URNs=20is=20still=20constrained=20to=20that=20of=20RFC=203986,=20so=20= generic=20URI=20parsers=20are=20unaffected=20by=20this=20= change.=0A=0A=0A=0A=0A=0A=20=0A=20= =20=20=0A=09=20=20The=20"doi"=20URI=20Scheme=20for=20the=20= Digital=20Object=20Identifier=0A=09=09=20(DOI)=0A=09=20=20= =0A=09=09=20= =0A=09=20=20=0A=09=20=20=20=0A=09=20=20=20=0A=09=20= =20=0A= =09=20=20=0A=20=20=20=0A= =09=0A=0A=0A=0A=0A= =20=20=20=0A=09=20=20Codes=20for=20the=20representation=20= of=20names=20of=20countries=20and=0A=09=09=20their=20subdivisions=20--=20= Part=201:=20Country=20codes=20=20=0A=09=20=20=0A=09=09=20= =20ISO=20=0A=09=20=20=0A=09=20=20= =0A=20=20=20=0A=20=20=20=0A=0A=0A=0A=20=20=20=0A=20=20=20Permanent=20URI=20= Schemes=0A=20=20=20=0A=09=20=20= IANA=0A=20=20=20=0A=20=20=20=0A=20=20=20=0A=0A=20=20=20=0A=0A=0AFunctional=20Requirements=20for=20Uniform=20= Resource=20Names=0A=0AMIT=20Laboratory=20for=20= Computer=20Science=0A
=0A=0A545=20= Technology=20Square=0ACambridge=0A= MA=0A02139=0A= US=0A+1=20617=20253=202673=0A= sollins@lcs.mit.edu
=0A=0A= Xerox=20Palo=20Alto=20Research=20Center=0A=
=0A=0A3333=20Coyote=20Hill=20Road=0A= Palo=20Alto=0ACA=0A94304=0A= US=0A+1=20415=20812=204365=0A= +1=20415=20812=204333=0A= masinter@parc.xerox.com
=0A=0A=0A=0A=0A=0A=0A=0A= URN=20Syntax=0A=0A= AT&T=0A
=0A=0A= 15621=20Drexel=20Circle=0AOmaha=0A= NE=2068135-2358=0AUSA=0A= +1=20402=20894-9456=0A= jayhawk@ds.internic.net
=0A=0AApplications=0A= URN=0Auniform=20resource=0A= =0A=0A=20=20=20Uniform=20Resource=20Names=20(URNs)=20are=20= intended=20to=20serve=20as=20persistent,=0A=20=20=20= location-independent,=20resource=20identifiers.=20This=20document=20sets=0A= =20=20=20forward=20the=20canonical=20syntax=20for=20URNs.=20=20A=20= discussion=20of=20both=20existing=0A=20=20=20legacy=20and=20new=20= namespaces=20and=20requirements=20for=20URN=20presentation=20and=0A=20=20= =20transmission=20are=20presented.=20=20Finally,=20there=20is=20a=20= discussion=20of=20URN=0A=20=20=20equivalence=20and=20how=20to=20= determine=20it.=0A=0A=0A=0A=0A= =0A= =0A=0A=0A=0AArchitectural=20Principles=20of=20Uniform=20= Resource=20Name=20Resolution=0A=0AMIT=20= Laboratory=20for=20Computer=20Science=0A
=0A= =0A545=20Technology=20Sq.=0A= Cambridge=0AMA=2002139=0A= +1=20617=20253=206006=0A= sollins@lcs.mit.edu
=0A=0AApplications=0A= security=0Auniform=20resource=0A= =0A=0A=20=20=20This=20document=20addresses=20the=20issues=20= of=20the=20discovery=20of=20URN=20(Uniform=0A=20=20=20Resource=20Name)=20= resolver=20services=20that=20in=20turn=20will=20directly=20translate=0A=20= =20=20URNs=20into=20URLs=20(Uniform=20Resource=20Locators)=20and=20URCs=20= (Uniform=20Resource=0A=20=20=20Characteristics).=20=20The=20document=20= falls=20into=20three=20major=20parts,=20the=0A=20=20=20assumptions=20= underlying=20the=20work,=20the=20guidelines=20in=20order=20to=20be=20a=0A= =20=20=20viable=20Resolver=20Discovery=20Service=20or=20RDS,=20and=20a=20= framework=20for=0A=20=20=20designing=20RDSs.=20=20The=20guidelines=20= fall=20into=20three=20principle=20areas:=0A=20=20=20evolvability,=20= usability,=20and=20security=20and=20privacy.=20=20An=20RDS=20that=20is=0A= =20=20=20compliant=20with=20the=20framework=20will=20not=20necessarily=20= be=20compliant=20with=0A=20=20=20the=20guidelines.=20=20Compliance=20= with=20the=20guidelines=20will=20need=20to=20be=0A=20=20=20validated=20= separately.=0A=0A=0A=0A=0A= =0A=0A=0A=0AURI=20Resolution=20Services=20= Necessary=20for=20URN=20Resolution=0A=0A= Network=20Solutions=0A
=0A=0A= 505=20Huntmar=20Park=20Drive=0AHerndon=0A= VA=0A22070=0A= USA=0A+1=20703=20742=200400=0A= +1=20703=20742=209552=0A= michaelm@rwhois.net
=0A=0A= Los=20Alamos=20National=20Laboratory,=20,Advanced=20= Computing=20Lab=0A
=0A=0AMS=20= B287=0ALos=20Alamos=0ANM=0A= 87545=0AUSA=0A+1=20505=20= 665=200597=0A+1=20505=20665=204939=0A= rdaniel@lanl.gov
=0A=0AApplications=0Auniform=20= resource=20identifier=0AURI=0A=0A= =0A=20=20=20Retrieving=20the=20resource=20identified=20by=20a=20= Uniform=20Resource=20Identifier=0A=20=20=20(URI)=20=20is=20only=20one=20= of=20the=20operations=20that=20can=20be=20performed=20on=20a=0A=20=20=20= URI.=20=20One=20might=20also=20ask=20for=20and=20get=20a=20list=20of=20= other=20identifiers=20that=0A=20=20=20are=20aliases=20for=20the=20= original=20URI=20or=20a=20bibliographic=20description=20of=0A=20=20=20= the=20resource=20the=20URI=20denotes,=20for=20example.=20This=20applies=20= to=20both=0A=20=20=20Uniform=20Resource=20Names=20(URNs)=20and=20Uniform=20= Resource=20Locators=20(URLs).=0A=20=20=20Uniform=20Resource=20= Characteristics=20(URCs)=20are=20discussed=20in=20this=0A=20=20=20= document=20but=20only=20as=20descriptions=20of=20resources=20rather=20= than=0A=20=20=20identifiers.=0A=0A=0A=20=20=20A=20service=20in=20= the=20network=20providing=20access=20to=20a=20resource=20may=20provide=0A= =20=20=20one=20or=20some=20of=20these=20options,=20but=20it=20need=20not=20= provide=20all=20of=20them.=0A=20=20=20This=20memo=20specifies=20an=20= initial=20set=20of=20these=20operations=20that=20can=20be=0A=20=20=20= used=20to=20describe=20the=20interactions=20provided=20by=20a=20given=20= access=20service.=0A=20=20=20It=20also=20suggests=20guidelines=20that=20= should=20be=20adhered=20to=20when=20those=0A=20=20=20operations=20are=20= encoded=20in=20a=20protocol.=0A=0A=0A=0A=0A= =0A= =0A=0A=0A=0A= Using=20The=20ISSN=20(International=20Serial=20Standard=20Number)=20= as=20URN=20(Uniform=20Resource=20Names)=20within=20an=20ISSN-URN=20= Namespace=0A=0A=0A=0A=0AThis=20document=20= presents=20how=20the=20ISSN=20-=20International=20Standard=20Serial=20= Number=20-=20which=20is=20a=20persistent=20number=20for=20unique=20= identification=20of=20serials=20widely=20recognised=20and=20used=20in=20= the=20bibliographic=20world,=20can=20be=20supported=20within=20the=20= Uniform=20Resource=20Name=20(URN)=20framework=20as=20a=20specific=20URN=20= namespace=20identifier.=20=20This=20memo=20provides=20information=20for=20= the=20Internet=20community.=0A=0A=0A=0A=0A=0A=0A= Using=20International=20Standard=20Book=20Numbers=20as=20Uniform=20= Resource=20Names=0A=0A=0A=0A= =0A=0A=0AThis=20document=20discusses=20how=20International=20= Standard=20Book=20Numbers=20(ISBN)=20can=20be=20supported=20within=20the=20= URN=20(Uniform=20Resource=20Names)=20framework=20and=20the=20syntax=20= for=20URNs=20defined=20in=20RFC=202141.=20=20Much=20of=20the=20= discussion=20below=20is=20based=20on=20the=20ideas=20expressed=20in=20= RFC=202288.=20=20This=20memo=20provides=20information=20for=20the=20= Internet=20community.=0A=0A=0A=0A= =0A=0A=0AUniform=20= Resource=20Names=20(URN)=20Namespace=20Definition=20Mechanisms=0A= =0A=0A=0A=0A=0A=0A=0A= =0A=0A=0AThis=20document=20lays=20out=20general=20= definitions=20of=20and=20mechanisms=20for=20establishing=20Uniform=20= Resource=20Names=20(URN)=20"namespaces".=20=20The=20URN=20WG=20has=20= defined=20a=20syntax=20for=20URNs=20in=20RFC=202141,=20as=20well=20as=20= some=20proposed=20mechanisms=20for=20their=20resolution=20and=20use=20in=20= Internet=20applications=20in=20RFC=203401=20and=20RFC=203405.=20=20The=20= whole=20rests=20on=20the=20concept=20of=20individual=20"namespaces"=20= within=20the=20URN=20structure.=20=20Apart=20from=20proof-of-concept=20= namespaces,=20the=20use=20of=20existing=20identifiers=20in=20URNs=20has=20= been=20discussed=20in=20RFC=202288.=20=20This=20document=20specifies=20= an=20Internet=20Best=20Current=20Practices=20for=20the=20Internet=20= Community,=20and=20requests=20discussion=20and=20suggestions=20for=20= improvements.=0A=0A=0A= =0A=0A= =0A=0A=0AGuidelines=20for=20= Writing=20RFC=20Text=20on=20Security=20Considerations=0A=0A= =0A=0A=0A=0A=0A= All=20RFCs=20are=20required=20to=20have=20a=20Security=20= Considerations=20section.=20=20Historically,=20such=20sections=20have=20= been=20relatively=20weak.=20=20This=20document=20provides=20guidelines=20= to=20RFC=20authors=20on=20how=20to=20write=20a=20good=20Security=20= Considerations=20section.=20=20This=20document=20specifies=20an=20= Internet=20Best=20Current=20Practices=20for=20the=20Internet=20= Community,=20and=20requests=20discussion=20and=20suggestions=20for=20= improvements.=0A=0A=0A= =0A=0A= =0A=0A=0AA=20Uniform=0AResource=20Name=20= (URN)=20Namespace=20for=20Extensions=20to=20the=20Extensible=20Messaging=20= and=20Presence=20Protocol=20(XMPP)=0A=0A= XMPP=20Standards=20= Foundation=0A
=0A=0AP.O.=20Box=20= 1641=0ADenver=0ACO=0A= 80201=0AUSA=0A= stpeter@jabber.org=0A= xmpp:stpeter@jabber.org
=0A=0AApplications=0A= Extensible=20Messaging=20and=20Presence=20Protocol=0A= XMPP=0AJabber=0AInstant=20= Messaging=0APresence=0AUniform=20= Resource=20Name=0AURN=0A=0A= This=20document=20describes=20a=20Uniform=20Resource=20Name=20(URN)=20= namespace=20for=20uniquely=20identifying=20Extensible=20Markup=20= Language=20(XML)=20formats=20and=20protocols=20that=20provide=20= extensions=20to=20the=20Extensible=20Messaging=20and=20Presence=20= Protocol=20(XMPP)=20and=20are=20defined=20in=20specifications=20= published=20by=20the=20XMPP=20Standards=20Foundation=20= (XSF).=0A=0A=0A=0A= =0A= =0A=0A=0A=0A= Internationalized=20Resource=20Identifiers=20(IRIs)=20and=20= Uniform=20Resource=20Identifiers=20(URIs)=20for=20the=20Extensible=20= Messaging=20and=20Presence=20Protocol=20(XMPP)=0A=0A=0A=0A=0AThis=20document=20defines=20= the=20use=20of=20Internationalized=20Resource=20Identifiers=20(IRIs)=20= and=20Uniform=20Resource=20Identifiers=20(URIs)=20in=20identifying=20or=20= interacting=20with=20entities=20that=20can=20communicate=20via=20the=20= Extensible=20Messaging=20and=20Presence=20Protocol=20(XMPP).=20= [STANDARDS-TRACK]=0A=0A=0A=0A= =0A=0A=0AInternationalized=20= Domain=20Names=20for=20Applications=20(IDNA):=20Definitions=20and=20= Document=20Framework=0A=0A=0A=0A=0A= This=20document=20is=20one=20of=20a=20collection=20that,=20together,=20= describe=20the=20protocol=20and=20usage=20context=20for=20a=20revision=20= of=20Internationalized=20Domain=20Names=20for=20Applications=20(IDNA),=20= superseding=20the=20earlier=20version.=20=20It=20describes=20the=20= document=20collection=20and=20provides=20definitions=20and=20other=20= material=20that=20are=20common=20to=20the=20set.=20= [STANDARDS-TRACK]=0A=0A=0A=0A= =0A=0A=0ADeprecating=20the=20= "X-"=20Prefix=20and=20Similar=20Constructs=20in=20Application=20= Protocols=0A=0A=0A=0A= =0A=0A=0A=0A=0A= Historically,=20designers=20and=20implementers=20of=20application=20= protocols=20have=20often=20distinguished=20between=20standardized=20and=20= unstandardized=20parameters=20by=20prefixing=20the=20names=20of=20= unstandardized=20parameters=20with=20the=20string=20"X-"=20or=20similar=20= constructs.=20=20In=20practice,=20that=20convention=20causes=20more=20= problems=20than=20it=20solves.=20=20Therefore,=20this=20document=20= deprecates=20the=20convention=20for=20newly=20defined=20parameters=20= with=20textual=20(as=20opposed=20to=20numerical)=20names=20in=20= application=20protocols.=20=20This=20memo=20documents=20an=20Internet=20= Best=20Current=20Practice.=0A=0A=0A=0A=0A= =0A=0A=0AMedia=20Type=20= Specifications=20and=20Registration=20Procedures=0A=0A= =0A=0A=0A=0A=0A=0A=0AThis=20document=20= defines=20procedures=20for=20the=20specification=20and=20registration=20= of=20media=20types=20for=20use=20in=20HTTP,=20MIME,=20and=20other=20= Internet=20protocols.=20=20This=20memo=20documents=20an=20Internet=20= Best=20Current=20Practice.=0A=0A=0A=0A=0A= =0A=0A=0AIssues=20in=20= Identifier=20Comparison=20for=20Security=20Purposes=0A=0A= =0A=0A= =0AIdentifiers=20such=20as=20hostnames,=20URIs,=20IP=20= addresses,=20and=20email=20addresses=20are=20often=20used=20in=20= security=20contexts=20to=20identify=20security=20principals=20and=20= resources.=20=20In=20such=20contexts,=20an=20identifier=20presented=20= via=20some=20protocol=20is=20often=20compared=20using=20some=20policy=20= to=20make=20security=20decisions=20such=20as=20whether=20the=20security=20= principal=20may=20access=20the=20resource,=20what=20level=20of=20= authentication=20or=20encryption=20is=20required,=20etc.=20=20If=20the=20= parties=20involved=20in=20a=20security=20decision=20use=20different=20= algorithms=20to=20compare=20identifiers,=20then=20failure=20scenarios=20= ranging=20from=20denial=20of=20service=20to=20elevation=20of=20privilege=20= can=20result.=20=20This=20document=20provides=20a=20discussion=20of=20= these=20issues=20that=20designers=20should=20consider=20when=20defining=20= identifiers=20and=20protocols,=20and=20when=20constructing=20= architectures=20that=20use=20multiple=20= protocols.=0A=0A=0A=0A= =0A=0A=0AA=20Uniform=20= Resource=20Name=20(URN)=20Namespace=20for=20Examples=0A=0A=0A=0A=0AThis=20document=20defines=20a=20= Uniform=20Resource=20Name=20(URN)=20namespace=20identifier=20enabling=20= the=20generation=20of=20URNs=20that=20are=20appropriate=20for=20use=20in=20= documentation=20and=20in=20URN-related=20testing=20and=20= experimentation.=0A=0A=0A= =0A=0A= =0A=0A=0APrivacy=20= Considerations=20for=20Internet=20Protocols=0A=0A= =0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A= =0A=0A=0AThis=20document=20offers=20guidance=20for=20= developing=20privacy=20considerations=20for=20inclusion=20in=20protocol=20= specifications.=20=20It=20aims=20to=20make=20designers,=20implementers,=20= and=20users=20of=20Internet=20protocols=20aware=20of=20privacy-related=20= design=20choices.=20=20It=20suggests=20that=20whether=20any=20individual=20= RFC=20warrants=20a=20specific=20privacy=20considerations=20section=20= will=20depend=20on=20the=20document's=20content.=0A= =0A=0A=0A=0A=0A=0A= On=20Consensus=20and=20Humming=20in=20the=20IETF=0A= =0A=0A=0A=0AThe=20IETF=20has=20had=20a=20long=20= tradition=20of=20doing=20its=20technical=20work=20through=20a=20= consensus=20process,=20taking=20into=20account=20the=20different=20views=20= among=20IETF=20participants=20and=20coming=20to=20(at=20least=20rough)=20= consensus=20on=20technical=20matters.=20In=20particular,=20the=20IETF=20= is=20supposed=20not=20to=20be=20run=20by=20a=20"majority=20rule"=20= philosophy.=20This=20is=20why=20we=20engage=20in=20rituals=20like=20= "humming"=20instead=20of=20voting.=20However,=20more=20and=20more=20of=20= our=20actions=20are=20now=20indistinguishable=20from=20voting,=20and=20= quite=20often=20we=20are=20letting=20the=20majority=20win=20the=20day=20= without=20consideration=20of=20minority=20concerns.=20This=20document=20= explains=20some=20features=20of=20rough=20consensus,=20what=20is=20not=20= rough=20consensus,=20how=20we=20have=20gotten=20away=20from=20it,=20how=20= we=20might=20think=20about=20it=20differently,=20and=20the=20things=20we=20= can=20do=20in=20order=20to=20really=20achieve=20rough=20= consensus.</t><t>=20Note:=20This=20document=20is=20quite=20= consciously=20being=20put=20forward=20as=20Informational.=20It=20does=20= not=20propose=20to=20change=20any=20IETF=20processes=20and=20is=20= therefore=20not=20a=20BCP.=20It=20is=20simply=20a=20collection=20of=20= principles,=20hopefully=20around=20which=20the=20IETF=20can=20come=20to=20= (at=20least=20rough)=20consensus.=0A=0A=0A=0A=0A=0A=0A= URI=20Design=20and=20Ownership=0A=0A=0A=0A=0A= Section=201.1.1=20of=20RFC=203986=20defines=20URI=20syntax=20as=20"a=20= federated=20and=20extensible=20naming=20system=20wherein=20each=20= scheme's=20specification=20may=20further=20restrict=20the=20syntax=20and=20= semantics=20of=20identifiers=20using=20that=20scheme."=20In=20other=20= words,=20the=20structure=20of=20a=20URI=20is=20defined=20by=20its=20= scheme.=20=20While=20it=20is=20common=20for=20schemes=20to=20further=20= delegate=20their=20substructure=20to=20the=20URI's=20owner,=20publishing=20= independent=20standards=20that=20mandate=20particular=20forms=20of=20URI=20= substructure=20is=20inappropriate,=20because=20that=20essentially=20= usurps=20ownership.=20=20This=20document=20further=20describes=20this=20= problematic=20practice=20and=20provides=20some=20acceptable=20= alternatives=20for=20use=20in=20standards.=0A= =0A=0A=0A=0A=0A=0A=20=20=0A=20= =20=20=20The=20Unicode=20Standard=0A=20=20=20=20=0A= =20=20=20=20=20=20The=20Unicode=20= Consortium=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=0A=0A=0A=0A=0A= XML=20Base=20(Second=20Edition)=0A=0A=20=20=20=20= =0A=0A=0A=20=20=20=20= =0A=0A=0A=0A=0A= =0A= =0A=0A=0A=0A= Namespaces=20in=20XML=201.0=20(Third=20Edition)=0A=0A=20=20=20=20=0A=0A=0A= =20=20=20=20=0A=0A=0A=20=20=20=20= =0A=0A=0A=20=20=20=20=0A=0A=0A=20=20=20=20=0A= =0A=0A= =0A=0A=0A= =0A=0A=20=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20= ECMAScript=202015=20Language=20Specification=0A=20=20=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20European=20Computer=20Manufacturers=20= Association=0A=20=20=20=20=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=0A=0A=20=20=20=20= =0A=0A=20=20=20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20Requested=20of=20IANA=20(formal)=20or=20= assigned=20by=20IANA=20(informal).=0A=20=20=20=20=20=20=20=20=20=20= The=20version=20of=20the=20registration,=20= starting=20with=201=20and=20incrementing=20by=201=20with=20each=20new=20= version.=0A=20=20=20=20=20=20=20=20=20=20The=20= date=20when=20the=20registration=20is=20requested=20of=20IANA,=20using=20= the=20format=20YYYY-MM-DD.=0A=20=20=20=20=20=20=20=20=20=20The=20person=20or=20organization=20that=20has=20= registered=20the=20NID,=20including=20the=20name=20and=20address=20of=20= the=20registering=20organization,=20as=20well=20as=20the=20name=20and=20= contact=20information=20(email,=20phone=20number,=20or=20postal=20= address)=20of=20the=20designated=20contact=20person.=20If=20the=20= registrant=20is=20a=20recognized=20standards=20development=20= organization=20or=20scientific=20society=20requesting=20the=20fact=20= track=20registration=20procedure=20(see=20),=20that=20information=20= should=20be=20clearly=20indicated=20in=20this=20section=20of=20the=20= template.=0A=20=20=20=20=20=20=20=20=20=20Described=20under=20=20of=20this=20document.=0A=20=20=20=20= =20=20=20=20=20=20Described=20under=20=20of=20this=20document.=20=20Unless=20the=20= registration=20explicitly=20says=20otherwise,=20use=20of=20q-components=20= and=20f-components=20is=20not=20allowed=20for=20this=20namespace.=0A=20= =20=20=20=20=20=20=20=20=20Described=20= under=20=20of=20this=20= document.=0A=20=20=20=20=20=20=20=20=20=20Described=20under=20=20of=20this=20document.=0A=20=20=20=20= =20=20=20=20=20=20Described=20under=20= =20of=20this=20document.=0A=20= =20=20=20=20=20=20=20=20=20Described=20= under=20=20of=20this=20= document.=0A=20=20=20=20=20=20=20=20=20=20A=20pointer=20to=20an=20RFC,=20a=20= specification=20published=20by=20another=20standards=20development=20= organization,=20or=20another=20stable=20document=20that=20provides=20= further=20information=20about=20the=20namespace.=0A=20=20=20=20=20=20= =20=20=20=20Description=20of=20= changes=20from=20prior=20version(s).=20(Applicable=20only=20when=20= earlier=20registrations=20have=20been=20revised.)=0A=20=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20=0A=20=20=20=20=0A=0A=20=20= =20=20=0A=20=20=20=20=20=20This=20document=20makes=20= the=20following=20substantive=20changes=20from=20:=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20= Formally=20registers=20'urn'=20as=20a=20URI=20scheme.=0A=20=20=20=20= =20=20=20=20=20=20Disallows=20"-"=20at=20the=20end=20of=20a=20= NID.=0A=20=20=20=20=20=20=20=20=20=20Allows=20the=20"/",=20"~",=20= and=20"&"=20characters=20in=20the=20namespace-specific=20string=20= (NSS).=0A=20=20=20=20=20=20=20=20=20=20Allows=20q-components,=20= r-components,=20and=20f-components.=0A=20=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=0A=0A=20=20=20=20= =0A=20=20=20=20=20=20This=20document=20makes=20= the=20following=20substantive=20changes=20from=20:=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20Relaxes=20= the=20registration=20policy=20for=20formal=20namespaces=0A=09=09=09=20= from=20"IETF=20Review"=20to=20"Expert=20Review"=20as=20discussed=20in=0A=09= =09=09=20.=0A=20= =20=20=20=20=20=20=20=20=20Removes=20the=20category=20of=20= experimental=20namespaces,=20consistent=20with=20.=0A=20=20=20=20=20=20=20=20=20=20Simplifies=20= the=20registration=20template.=0A=20=20=20=20=20=20=20=20=0A=20= =20=20=20=20=20=0A=20=20=20=20=20=20In=20addition,=20some=20of=20= the=20text=20has=20been=20updated=20to=20be=0A=09=09=20consistent=20with=20= the=20definition=20of=20Uniform=20Resource=0A=09=09=20Identifiers=20= (URIs)=20=20and=20the=0A=09=09=20processes=20= for=20registering=20information=20with=20the=20IANA=0A=09=09=20,=20as=20well=20as=20more=20modern=20guidance=0A=09=09= =20with=20regard=20to=20security=20=0A=09=09=20= and=20privacy=20=20issues=0A=09=09=20and=20= identifier=20comparison=20.=0A=20=20=20=20= =0A=0A=20=20=20=20=0A=20=20=20=20=20=20RFC=202141,=20which=20= provided=20the=20basis=20for=20the=20syntax=20portion=20of=20this=20= document,=20was=20authored=20by=20Ryan=20Moats.=0A=20=20=20=20=20=20= RFC=203406,=20which=20provided=20the=20basis=20for=20the=20namespace=20= portion=20of=20this=20document,=20was=20authored=20by=20Leslie=20Daigle,=20= Dirk-Willem=20van=20Gulik,=20Renato=20Iannella,=20and=20Patrik=20= Faltstrom.=0A=20=20=20=20=20=20Their=20work=20is=20gratefully=20= acknowledged.=0A=20=20=20=20=0A=0A=20=20=20=20=0A=20=20=20=20=20=20= Many=20thanks=20to=20Marc=20Blanchet,=20Leslie=20Daigle,=20Martin=20= Duerst,=20Juha=20Hakala,=20=0A=20=20=20=20=20=20=20=20=20Ted=20Hardie,=20= Alfred=20Hoenes,=20Paul=20Jones,=20Barry=20Leiba,=20Sean=20Leonard,=20= Larry=20Masinter,=20=0A=20=20=20=20=20=20=20=20=20Keith=20Moore,=20Mark=20= Nottingham,=20Julian=20Reschke,=20Lars=20Svensson,=20Henry=20S.=20= Thompson,=20=0A=20=20=20=20=20=20=20=20=20Dale=20Worley,=20and=20other=20= participants=20in=20the=20URNBIS=20WG=20for=20their=20input.=20=20Alfred=20= Hoenes=20=0A=20=20=20=20=20=20=20=20=20in=20particular=20edited=20an=20= earlier=20version=20of=20this=20document=20and=20served=20as=20co-chair=20= of=20=0A=20=20=20=20=20=20=20=20=20the=20URNBIS=20WG.=0A=20=20=20=20=20= =20Juha=20Hakala=20deserves=20special=20recognition=20for=20his=20= dedication=0A=09=20to=20successfully=20completing=20this=20work,=20as=20= do=20Andrew=20Newton=20and=0A=09=20Melinda=20Shore=20in=20their=20roles=20= as=20working=20group=20co-chairs=20and=0A=09=20Barry=20Leiba=20in=20his=20= role=20as=20area=20director.=20=0A=20=20=20=20=0A=0A=09= =0A=09=20=20=20[[RFC=20Editor:=20= please=20remove=20this=20appendix=20before=0A=09=09=20=20= publication.]]=0A=09=20=20=20=0A=09=09=20=20=20=0A=09=09=09= =20Altered=20the=20text=20in=20=20to=0A= =09=09=09=09reflect=20list=20discussions=20about=20the=20earlier=0A=09=09= =09=09phrasing.=20=20Also=20added=20DOI=20example=20and=20citation=0A=09=09= =09=09to=20that=20section.=0A=09=09=09=20Clarified=20the=20naming=20= rules=20for=20formal=20namespaces=20and=0A=09=09=09=09their=20= relationship=20to=20ISO=203166,=20IDNA,=20etc.,=20reserved=0A=09=09=09=09= strings.=0A=09=09=09=20Added=20an=20explicit=20statement=20about=20= use=20of=20URNs=20in=0A=09=09=09=09various=20protocols=20and=20contexts=20= to=0A=09=09=09=09.=0A=09=09=09=20= Clarified=20that=20experimental=20namespace=20NIDs,=20which=20were=0A=09= =09=09=09explicitly=20not=20registered,=20are=20not=20valid=20URNs=0A=09=09= =09=09(in=20.=0A=09=09=09=20Transformed=20= the=20partial=20production=20in=0A=09=09=09=09=20into=20valid=20ABNF.=0A=09=09=09=20= Added=20more=20text=20about=20p-/q-/f-components=20and=0A=09=09=09=09= recommendations=20about=20use.=0A=09=09=09=20Added=20clarifying=20= note=20about=20"?"=20within=20q-components=0A=09=09=09=09and=20= f-components.=0A=09=09=09=20Added=20explicit=20requirement=20that=20= revisions=20of=20existing=0A=09=09=09=09registrations=20document=20the=20= changes=20and=20added=20a=20slot=0A=09=09=09=09for=20that=20description=20= to=20the=20template.=0A=09=09=09=20Many=20small=20editorial=20= changes=20and=20adjustments=20including=0A=09=09=09=09adding=20= additional=20references=20and=20cross-references=20for=0A=09=09=09=09= clarification.=0A=09=09=09=20Inserted=20a=20placeholder=20for=20= additional=20examples.=0A=09=09=20=20=0A=09=20=20=20= =0A=09=20=20=20=0A=09=09=20=20=20=0A=09=09=09=20= Several=20clarifying=20editorial=20changes,=20most=20suggested=0A=09=09= =09=09by=20Ted=20Hardie=20and=20Henry=20S.=20Thompson=20(some=20of=20= them=0A=09=09=09=09off-list).=0A=09=09=09=20=20Added=20a=20large=20= number=20of=20placeholders=20that=20identify=0A=09=09=09=09issues=20that=20= require=20WG=20consideration=20and=20resolution=0A=09=09=09=09(or=20WG=20= delegation=20to=20the=20editors).=0A=09=09=20=20=0A=09=20=20= =20=0A=09=20=20=20=0A=09=09=20=20=20=0A=09=09=09=20= =20Removed=20most=20of=20the=20placeholders=20added=20in=20-10.=0A=09=09= =09=09Supplied=20new=20text=20as=20required=20or=20suggested=20by=20= on-list=0A=09=09=09=09discussion=20of=20those=20issues.=0A=09=09=09=20= =20Replaced=20the=20conformance=0A=09=09=09=09examples=20=20with=20a=0A=09=09=09=09more=20= complete=20collection=20and=20discussion.=0A=09=09=09=20Revised=20= and=20consolidated=20the=20registration=20procedure,=0A=09=09=09=09and=20= added=20provisions=20for=20NIDs=20that=20are=20the=20subject=20of=0A=09=09= =09=09standards=20and=20for=20avoiding=20race=20conditions=20about=0A=09=09= =09=09NID=20strings.=0A=09=09=09=20In=20response=20to=20= independent=20comments=20from=20Ted=20Hardie=0A=09=09=09=09and=20Henry=20= S.=20Thompson,=20called=20attention=20to=20the=0A=09=09=09=09possibility=20= of=20conflicts=20between=20NID=20strings=20and=0A=09=09=09=09various=20= claims=20of=20national,=20corporate,=20and=20other=0A=09=09=09=09= perogatives.=20=0A=09=09=09=20Changed=20the=20production=20for=20= assigned-name=20as=20suggested=0A=09=09=09=09by=20Lars=20Svensson.=0A= =09=09=09=20Several=20clarifying=20editorial=20changes=20including=0A=09= =09=09=09correcting=20a=20glitch=20in=20instructions=20to=20the=20RFC=20= Editor.=0A=09=09=20=20=0A=09=20=20=20=0A=09=20=20= =20=0A=0A=09=09=20=20= =20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Removed=20p-components=20as=20a=20= standalone=20construct,=20and=20instead=20folded=20them=20into=20the=20= NSS.=0A=09=09=09=20Defined=20syntax=20for=20r-components=20as=20a=20= way=20to=20pass=20information=20to=20resolvers,=20but=20left=20the=20= semantics=20for=20future=20standardization=20efforts.=0A=09=09=09=20= Further=20tuned=20the=20discussion=20of=20interoperability=20and=0A=09= =09=09=09related=20registration=20issues.=0A=09=09=09=20Made=20a=20= number=20of=20editorial=20corrections=20and=20reorganized=0A=09=09=09=09= the=20syntax=20material=20in=20=0A=09=09=09=09= somewhat=20to=20make=20it=20internally=20consistent=20and=20keep=0A=09=09= =09=09the=20relationship=20to=20RFC=203986=20clear.=20=0A=09=09=20=20= =0A=09=20=20=20=09=09=09=20=0A=09=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= More=20precisely=20defined=20the=20semantics=20of=20the=20optional=20= components.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Defined=20the=20term=20"resolution"=20and=20clarified=20several=20= related=20matters=20throughout=20the=20text.=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Clarified=20terminological=20relationship=20= to=20RFC=203986.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Further=20cleansed=20the=20document=20of=20p-components.=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Corrected=20several=20= examples=20to=20avoid=20confusion=20with=20existing=20identifier=20= systems.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Improved=20text=20regarding=20the=20purpose=20of=20namespaces=20being=20= registered.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=0A=09=20=20=20=09=09= =09=20=0A=09=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Reverted=20the=20ABNF=20to=20what=20had=20= been=20defined=20in=20version=20-12.=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Added=20fast-track=20approval=20process=20for=20= standards-related=20organizations,=20scientific=20societies,=20and=20= similar=20bodies=20(similar=20to=20RFC=206838=20for=20Media=20= Types).=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=0A=09=20=20=20=09=09=09=20= =0A=09=0A=0A=20=20=0A=0A= --Apple-Mail=_8F2B2ABD-90CF-4F2C-98EF-3527EAC94AF1 Content-Disposition: attachment; filename=draft-ietf-urnbis-rfc2141bis-urn-14-seantek.txt Content-Type: text/plain; name="draft-ietf-urnbis-rfc2141bis-urn-14-seantek.txt" Content-Transfer-Encoding: quoted-printable URNBIS P. Saint-Andre Internet-Draft &yet Obsoletes: 2141, 3406 (if approved) J. Klensin Intended status: Standards Track Expires: May 19, 2016 November 16, 2015 Uniform Resource Names (URNs) draft-ietf-urnbis-rfc2141bis-urn-14-seantek Abstract A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 19, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Saint-Andre & Klensin Expires May 19, 2016 [Page 1] =0C Internet-Draft URNs November 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Namespace Identifier . . . . . . . . . . . . . . . . . . 8 3.2. Namespace Specific String . . . . . . . . . . . . . . . . 8 3.3. Optional Components . . . . . . . . . . . . . . . . . . . 9 3.3.1. r-component . . . . . . . . . . . . . . . . . . . . . 11 3.3.2. q-component . . . . . . . . . . . . . . . . . . . . . 17 3.3.3. f-component . . . . . . . . . . . . . . . . . . . . . 18 4. Equivalence of URNs . . . . . . . . . . . . . . . . . . . . . 19 4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 5. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 21 5.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. URNs and Relative References . . . . . . . . . . . . . . 22 5.4. Transport and Display . . . . . . . . . . . . . . . . . . 23 5.5. URI Design and Ownership . . . . . . . . . . . . . . . . 23 6. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 25 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 27 7. Defining and Registering a URN Namespace . . . . . . . . . . 27 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2. Registration Policy and Process: Community Registrations 28 Saint-Andre & Klensin Expires May 19, 2016 [Page 2] =0C Internet-Draft URNs November 2015 7.3. Registration Policy and Process: Fast Track for Standards Development Organizations, Scientific Societies, and Similar Bodies . . . . . . . . . . . . . . . . . . . . . 29 7.4. Completing the Template . . . . . . . . . . . . . . . . . 30 7.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 30 7.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 31 7.4.3. Assignment . . . . . . . . . . . . . . . . . . . . . 31 7.4.4. Security and Privacy . . . . . . . . . . . . . . . . 32 7.4.5. Interoperability . . . . . . . . . . . . . . . . . . 32 7.4.6. Resolution . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 33 8.2. Registration of URN Namespaces . . . . . . . . . . . . . 34 8.3. Updated text/uri-list Media Type . . . . . . . . . . . . 34 9. Security and Privacy Considerations . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Registration Template . . . . . . . . . . . . . . . 41 Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 42 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 42 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 42 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 43 Appendix F. Change log for versions of draft-ietf-urnbis- rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 43 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 43 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 44 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 44 F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 44 F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 45 F.6. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) [RFC3986] that is assigned under the "urn" scheme and a particular namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. A URN namespace is a collection of such identifiers, each of which is (1) unique, (2) assigned in a consistent and managed way, and (3) assigned according to a common definition. (Some URN namespaces create names that exist only as URNs, whereas others create URNs out of names that already exist in other identifier systems, such as ISBNs [RFC3187] and ISSNs [RFC3044].) Saint-Andre & Klensin Expires May 19, 2016 [Page 3] =0C Internet-Draft URNs November 2015 The assignment of URNs is done by an organization (or, in some cases, according to an algorithm or other automated process) that has been formally delegated a namespace within the "urn" scheme (e.g., a URN in the 'example' namespace [RFC6963] might be of the form "urn:example:foo"). This document rests on two key assumptions: 1. Assignment of a URN is a managed process. 2. The space of URN namespaces is itself managed. While other URI schemes may allow identifiers to be freely chosen and assigned, such is not the case for URNs. The syntactical correctness of a string starting with "urn:" is not sufficient to make it a URN. In order for the string to be a valid URN, the namespace identifier needs to be registered in accordance with the rules defined here and the remaining parts of the assigned-name portion of the URN needs to be generated in accordance with the rules for the registered namespace. So that information about both URN syntax and URN namespaces is available in one place, this document does the following: 1. Defines the canonical syntax for URNs in general (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. 2. Specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). For URN syntax and URN namespaces, this document modernizes and replaces the definitions from [RFC2141] and [RFC3406]. These modifications build on the key requirements provided in [RFC1737] and many years of experience with URNs, in both cases attempting to make the smallest reasonable set of changes from the previous definitions. The intent is to define URNs in a consistent manner so that, wherever practical, the parsing, handling, and resolution of URNs can be independent of the namespace within which a given URN is assigned. This document obsoletes both [RFC2141] and [RFC3406]. Saint-Andre & Klensin Expires May 19, 2016 [Page 4] =0C Internet-Draft URNs November 2015 2. Terminology This document uses the terms "resolution" and "resolver" in roughly the sense from [RFC2276], i.e., "resolution" is the act of supplying services related to the identified resource, such as translating the persistent name into one or more current locators for the resource, or delivering metadata about the resource in an appropriate format. At the time of this writing, resolution services are defined in [RFC2483]. In order to underline the difference between the names and locators, this document uses the term Uniform Resource Locator (URL), rather than the generic term Uniform Resource Identifier (URI), to refer to locators; see also Section 1.1.3 of [RFC3986]. If there are or will be resolution services available for a URN, this document calls the URN a resource identifier in roughly the sense from [RFC3986]. If there is no intention to provide any resolution services, this document calls the URN an abstract designator. Several other important terms used in this document, including some "normalization" operations that are not part of the Unicode Standard [UNICODE], are defined in the URI specification [RFC3986]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. URN Syntax The syntax of URNs as provided in [RFC2141] was defined before the updated specification of URIs in [RFC3986]. The definition of URN syntax is updated in this document to do the following: o Ensure consistency with the URI syntax. o Facilitate the use of URNs with parameters similar to URI queries and fragments. o Permit parameters influencing URN resolution. o Ease the use of URNs with naming systems that include the '/' character. In particular, this specification does the following: o Extends URN syntax to explicitly allow the characters '/', "?", and "#", which were reserved for future use by [RFC2141]; this change effectively also allows several components of the URI Saint-Andre & Klensin Expires May 19, 2016 [Page 5] =0C Internet-Draft URNs November 2015 syntax although without necessarily tying those components to URI semantics. o Defines syntax for an additional component that can be used in interactions with a URN resolution service. o Makes several smaller syntax adjustments. However, this specification does not extend the URN syntax to allow characters outside the ASCII range [RFC20], which implies that any such characters need to be percent-encoded as described in Section 2.1 of the URI specification [RFC3986]. The syntax for a URN is defined as follows using the Augmented Backus-Naur Form (ABNF) as specified in [RFC5234] and [ABNFMORE]. Rules not defined here (e.g., alphanum, fragment, and pchar) are defined as part of the URI syntax [RFC3986] and used here to point out the syntactic relationship with the terms used there. alphanum =3D alphanum@[RFC3986] query =3D query@[RFC3986] fragment =3D fragment@[RFC3986] pchar =3D pchar@[RFC3986] reg-name =3D reg-name@[RFC3986] ; numericoid@[RFC4512] is deficient--it permits ; prefixes other than 0-2. ; pct-encoded /may/ be deficient--in some places only UTF-8 ; percent-encoding is permitted. (NB: this yields "interesting" ; problems when combined with q-components and f-components in ; some other unspecified character set/encoding.) urn-uri =3D "urn" ":" assigned-name [ "?" r-component [ "?" q-component ] ] [ "#" f-component ] assigned-name =3D NID ":" NSS NID =3D alphanum 0*30ldh alphanum ldh =3D alphanum / "-" NSS =3D pchar *(pchar / "/") q-component =3D query f-component =3D fragment r-component =3D rop [ "@" r-authority ] [ ":" r-params ] ; extension point: use different prefix symbols rop =3D aop / oidop / roidop / urnop / nsop aop =3D ( %x41-54 / %x56-5A / %x61-74 / %x76-7A ) 0*30ldh alphanum / Saint-Andre & Klensin Expires May 19, 2016 [Page 6] =0C Internet-Draft URNs November 2015 "u" ( "-" / DIGIT / %x41-51 / %x53-5A / %x61-71 / %x73-7A ) 0*29ldh alphanum / "ur" ( "-" / DIGIT / %x41-4D / %x4F-5A / %x61-6D / %x6F-7A ) 0*28ldh alphanum oidop =3D numericoid ; compare with numericoid@[RFC4512], oid@[RFC3061] numericoid =3D %x30-32 1*( "." number ) number =3D DIGIT / ( %x31-39 1*DIGIT ) roidop =3D numericroid numericroid =3D 1*( "." number ) urnop =3D "urn" "*" NID "*" NSSop nsop =3D "*" NSSop NSSop =3D reg-name ; syntax, not semantics r-authority =3D reg-name ; overall repertoire is *(pchar / "/") ; NB: shall we structure r-params here, or defer, ; or make it rop-dependent? r-params =3D r-param *( ( ";" / "&" ) r-param ) r-param =3D rp-name [ "=3D" rp-values ] rp-name =3D rp-word rp-values =3D rp-value *( "," rp-value ) rp-value =3D rp-word ; mostly isomorphic with encodeURIComponent except $ and + ; but that is intentional rp-word =3D *( unreserved / pct-encoded / "!" / "$" / "'" / "(" / ")" / "*" / "+" ) The question mark character "?" can be used without percent-encoding inside q-components and f-components. It SHALL NOT appear inside r-components, unless it is percent-encoded. The following sections provide additional information about the syntactic elements of URNs. Saint-Andre & Klensin Expires May 19, 2016 [Page 7] =0C Internet-Draft URNs November 2015 3.1. Namespace Identifier The syntax here is slightly more restrictive than what was defined in [RFC2141], because it prohibits the character "-" at the end of a NID. NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent). Characters outside the ASCII range [RFC20] are not permitted in NIDs, and no encoding mechanism for such characters is supported. 3.2. Namespace Specific String The namespace specific string (NSS) is a unique identifier that is assigned and managed in a consistent way and that conforms to the definition of the relevant namespace. The combination of the NID (unique across the entire "urn" scheme) and the NSS (unique within the namespace) ensures that the resulting URN is a globally unique URI. This document modifies the syntax of the NSS to allow the following characters: "/", "~", and "&". In particular, allowing the "/" character effectively makes it possible to encapsulate hierarchical identifiers from other naming systems. For instance, consider the hypothetical example of a hierarchical naming system in which the identifiers take the form of a series of numbers separated by the "/" character, such as "1/406/47452/2". If the naming authority for such identifiers were to use URNs, it would be natural to place the existing identifiers in the NSS, resulting in URNs such as "urn:example:1/406/47452/2". However, the foregoing changes to the syntax for the NSS do not modify the encoding rules for URN namespaces that were defined in accordance with [RFC2141]. If any such URN namespace that is used outside of the URN context (i.e., as a standalone identifier space) also allows the use of "/", "~", or "&" in the native form within that identifier space, then the encoding rules for that namespace are not changed by this specification. Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed by the "pchar" production referenced above (e.g., characters outside the ASCII range or, consistent with the restrictions in RFC 3986, the characters "/", "?", "#", "[", and "]"). While such a string might be a valid name, it is not a valid URN until it has been translated into a conformant NSS. In the case of URNs that are formed from names that exist separately in a standalone identifier space, translation of an identifier from its "native" format to URN format Saint-Andre & Klensin Expires May 19, 2016 [Page 8] =0C Internet-Draft URNs November 2015 is accomplished by using the canonicalization and encoding methods defined for that URN namespace. Software that is not aware of those namespace-specific canonicalization and encoding rules MUST NOT construct URNs from the names in the standalone identifier space. In order to make URNs as stable and persistent as possible when protocols evolve and the environment around them changes, namespaces SHOULD NOT allow characters outside the basic Latin repertoire [RFC20] unless the nature of the particular namespace makes such characters necessary. 3.3. Optional Components As compared to [RFC2141], this document extends the URN syntax to permit inclusion of three new types of components: q-component, r-component, and f-component. Each of these components has a distinct role, which is independent of the URN and its namespace, and it is intended that clients will be able to handle these components uniformly for all URNs. In general: o The r-component is intended for parameters to be transmitted to resolution services and interpreted by those services. o The q-component is intended for parameters to be transmitted to and interpreted by or with respect to the products of the resolution services, such as resources identified by URIs. o The f-component is intended to be interpreted by the client as a specification for a location within, or region of, the dereferenced resources. The foregoing generalizations are true regardless of the URN's namespace. (This paragraph is informative.) An exemplary resolution-to-resource model may help with conceptualizing the relationship between the components of a urn: URI: 1. A client requests resources by urn: URI, invoking a URI handler. 2. A URI handler parses the "urn" URI scheme, the f-component, and everything else. 3. The URI handler invokes a urn: URI handler, passing everything else. 4. The urn: URI handler parses everything else into the assigned- name, r-component, and q-component. Saint-Andre & Klensin Expires May 19, 2016 [Page 9] =0C Internet-Draft URNs November 2015 5. The urn: URI handler calls a resolution service, passing the assigned-name and r-component to it as arguments. 6. The resolution service returns some intermediate products, which may include resources, resource identifiers (i.e., dereferenceable URIs), or attributes such as metadata. 7. The urn: URI handler combines the q-component with the intermediate products. When the combinations result in dereferenceable URIs, the handler dereferences the URIs. (Collectively, the products of the resolution services encompass both these intermediate products and the computing resources at the other end of the dereferenceable URIs.) 8. The urn: URI handler acquires resources, which may be content (i.e., having Internet media types). The urn: URI handler may interact with the URI handler and the client to pick from among the resources. 9. The urn: URI handler returns some of these resources to the URI handler. 10. The URI handler interprets the f-component, likely interacting with a media type handler and the client to identify and locate sub-resources within the dereferenced resources. To assist with implementing URN resolution services, [RFC2483] registered the text/uri-list media type. Section 8.3 updates that media type registration to include arbitrary attributes. Whenever a URN resolves to a URL which may be used to access the resource, there is a more specific interpretation of q-component and f-component: the q-component is copied verbatim to the query portion of the URL (if that URL scheme supports query), and the f-component is copied verbatim to the fragment portion of the URL. This is necessary, among other reasons, so that interpretation of q-component and f-component, when associated with URNs, will be consistent with the interpretation of relative references containing queries or fragments within documents which are ultimately accessible via URNs. Thus, for URNs which may be resolved to a URL, the semantics of q-component are identical to those for queries to that resource and the semantics of f-components are identical to those of fragments for that resource. The semantics of q-component and f-component for URNs that inherently cannot be resolved to a URL (i.e., for abstract designators) are undefined by this document; however, they SHOULD be consistent with the above roles. Saint-Andre & Klensin Expires May 19, 2016 [Page 10] =0C Internet-Draft URNs November 2015 In general, neither the syntax nor the semantics of q-components or f-components are defined by, or dependent on, the namespace of the URN. Any of these components MAY be used with URNs from existing namespaces whether or not the namespace explicitly supports them. As described above, the interpretation of q-component and f-component is namespace-independent. Interpretation of an r-component may be namespace-dependent to some degree if it relies on behavior of a namespace-specific resolution service, as discussed in the following sections. 3.3.1. r-component The URN r-component has no syntactic equivalent in URIs. The r-component is indicated by a first question mark ("?") and terminated by a second question mark indicating a q-component, a number sign ("#") character indicating an f-component, or by the end of the URI. The characters in the r-component have been carefully chosen to eliminate ambiguity and to ease parsing. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the r-component SHALL NOT be taken into account when determining URN equivalence. However, the r-component SHALL be supplied along with the URN when presenting a request to a URN resolution service. The r-component is entirely intended for passing information in requests to URN resolution services. The r-component is not intended for passing information to the products of the resolution services, to the resources identified by the URN, or to applications that manage such resources. In addition, the r-component is not intended for passing information to any underlying services that might exist behind a resolver, only to the resolver itself. To make URNs implementable, this specification provides a syntax and semantics for r-components. An r-component contains a resolution operation (called a "rop", rhymes with "hop"), an authority, and a set of parameters. When the r-component is present, the rop is REQUIRED. Consider the hypothetical example of passing parameters to resolution service (say, an ISO alpha-2 country code [ISO3166-1] in order to scope down the preferred country in which to search for a physical Saint-Andre & Klensin Expires May 19, 2016 [Page 11] =0C Internet-Draft URNs November 2015 copy of a book). This could perhaps be accomplished by specifying the country code in the r-component, resulting in URNs such as: urn:example:book3292323923?loc:cc=3Dde However, this primary purpose is not intended to forestall other potential uses for r-components. 3.3.1.1. Resolution Operation (rop) URNs that are not abstract designators are meant to be resolved. The resolution operation or "rop" (formerly called a "facet" or "resolver profile" during WG discussion) directs a resolver as to what services to supply. A rop generically and universally applies to all URNs; it is therefore orthogonal to the namespace identified by the NID production in a urn: URI. For example, the urn:isbn namespace tends to identify books, but a rop "bookinfo" should succeed for all identifiers that correspond to books, not just to those with ISBNs. Furthermore, there may be identifiers assigned by the International ISBN Agency that fit in the urn:isbn namespace, but do not correspond to books. Since URNs are extremely generic, a syntax to identify resolution operations should likewise be generic. Unlike the persistence (i.e., consistent and managed assignment) guarantees required of the URN assigned-name portion, however, defining and implementing novel resolution operations should be as frictionless as possible. Removing such barriers will promote the development of resolution services in a variety of communities and use cases. This specification defines five types of rops: aop, oidop, roidop, urnop, and nsop, along with an ABNF-compatible extension technique for future specifications. For reasons that follow, this specification RECOMMENDS that oidop be used as the primary technique for specifying resolution operations. 3.3.1.1.1. Alpha rop An Alpha rop (aop) is an identifier that starts with an alphabetic character, ends with an alphanumeric character, and may contain alphanumeric or hyphen characters. The aop production SHALL NOT begin with the characters "urn". The aop production is case- insensitive. An aop is globally unique. The bar to establish an aop identifier is RFC Required [RFC5226]. [[NB: At this time, there is no IANA registry proposed for aops. If the WG feels it is needed, it should probably be a sub-registry of URN Namespaces. Just a suggestion.]] Saint-Andre & Klensin Expires May 19, 2016 [Page 12] =0C Internet-Draft URNs November 2015 As a stylistic suggestion, aops SHOULD be basic US-English words or phrases. The terms should be simple or compound verbs that describe the operation ("display", "buy", "pickfromwarehouse"), or if the verb is related to retrieving a representation, aka "getting" ("get PDF", "get price", "get scoreboard"), the terms should be simple or compound nouns with the verb omitted ("pdf", "price", "scoreboard"). For exemplary purposes, this specification defines three aops "info", "hinfo", and "minfo". The "info" operation directs a resolver to return information about the resource or class of resources identified by the assigned-name of the urn: URI. (This definition contrasts with information about the identifier, such as a written explanation of how the identifier is composed or broken down. This definition also contrasts with information that comprises the resource itself, such as a PDF copy of a book.) The expectation is that the products of resolution will eventually dereference to content (data with Internet media types) that are human-readable or machine-readable. The "hinfo" operation directs a resolver to return human-readable information about the resource or class of resources identified by the assigned-name of the urn: URI. For example, content would be limited to media types such as text/plain, text/html, text/rtf, or image/jpeg, where when the information is presented to a human being, the human being would be able to understand it. The "minfo" operation directs a resolver to return machine-readable information about the resource or class of resources identified by the assigned-name of the urn: URI. For example, content would be limited to media types such as application/json or application/ rdf+xml, where when that information is fed into an automated process, the automated process would be able to take concrete action on it. For purposes of simplicity, these aops MAY take arbitrary r-params (Section 3.3.1.3) but this specification does not bother to define or anticipate any in particular. 3.3.1.1.2. Object Identifier rop An Object Identifier rop (oidop) is an Object Identifier [X.660]. The oidop production starts with a number 0, 1, or 2, followed by a series of one or more dotted whole numbers. The bar to establish an oidop is extremely low: just assign an OID and away you go. OIDs are compared for exact equality, and there is no semantic hierarchy to OID components other than those assigned by [X.660]. Furthermore, implementations that parse and present URNs to humans MAY display the Saint-Andre & Klensin Expires May 19, 2016 [Page 13] =0C Internet-Draft URNs November 2015 OID with a human-readable equivalent, such as a localized string. For these reasons, this specification RECOMMENDS that implementers use oidop to define resolution operations. 3.3.1.1.3. Relative Object Identifier rop A Relative Object Identifier rop (roidop) is a Relative Object Identifier [X.680]. Syntactically the roidop production is a series of one or more dotted whole numbers; therefore, roidop always starts with a dot. Relative Object Identifiers are always defined relative to some base Object Identifier. This specification does not define any particular base OID. Therefore, this syntax is basically reserved for future use. An implementation MAY use this rop type internally, but it is not currently intended for interchange. 3.3.1.1.4. Uniform Resource Name rop A Uniform Resource Name rop (urnop) is an operation defined by a URN namespace authority, thus making it globally unique. An urnop production SHALL begin with "urn*". The NID follows this mandatory prefix. After the NID comes another "*", and an operation-specific string (NSSop) [[NB: or possibly OSS?]]. The NSSop production has the same syntax as reg-name but different semantics: it is an opaque string assigned by the namespace authority for defining resolution operations. The "urn*" and NID productions are case-insensitive, but the NSSop production MAY be case-sensitive or have complex equivalence algorithms, depending on the definition promulgated by the namespace authority. As stated above, resolution operations are (at least potentially) universally applicable, rather than namespace-specific. This syntax provides a convenient means for a namespace authority to construct a globally unique string for operations that are internally relevant to its identified resources, but that could apply more broadly to other identifiers. The NSSop productions occupy an orthogonal namespace to the NSS productions, so and do not necessarily refer to the same thing. [[NB: NSSop as a restricted character repertoire compared with NSS, because characters such as : / and @ lead to ambiguity in the ABNF, thus making parsing a lot more complicated. * was chosen because it looks like a bullet or middle dot and therefore most closely resembles a "generic operator".]] Due to the potential complexity inherent in the equivalence question, using urnop is NOT RECOMMENDED (an oidop can suffice). Saint-Andre & Klensin Expires May 19, 2016 [Page 14] =0C Internet-Draft URNs November 2015 3.3.1.1.5. Namespace rop A Namespace rop (nsop) is an operation defined by the same URN namespace authority as the NID production in the urn: URI, thus making it globally unique. It has the same semantics as urnop above, except that "*" is syntactic sugar for "urn*" NID "*". This syntax basically recognizes that there will be appreciable use cases where the namespace authority has some operations in mind, and it may be most expedient for the namespace authority to promulgate these operations itself. Due to the potential complexity inherent in the equivalence question, using nsop is NOT RECOMMENDED (an oidop can suffice). 3.3.1.1.6. Extension Technique The ABNF above can be extended to include syntaxes for other kinds of operations. The five rops defined in this specification are easily distinguished by their first characters: ALPHA except "urn" (aop), 0-2 (oidop), "." (roidop), "urn*" (urnop), and "*" (nsop). Therefore, future specifications MAY provide new operation syntaxes that begin with the following characters: - _ ~ $ & ' + =3D "urn" (anything other than *) (any number greater than 2) However, the following characters SHALL NOT be used, because they would make the subsequent components ambiguous: # f-component ? q-component @ r-authority : r-params [ ] only in IP literals The following characters could be used, but are NOT RECOMMENDED for the following reasons: Saint-Andre & Klensin Expires May 19, 2016 [Page 15] =0C Internet-Draft URNs November 2015 / implies hierarchical thing going on ( ) implies matching with other parenthesis , confused with separator, e.g., in r-params ; confused with separator, e.g., in r-params 3.3.1.2. Resolution Authority (r-authority) The r-authority production specifies which resolver to use for URN resolution. The reg-name production and semantics from [RFC3986] are used for r-production in this draft. When r-authority is present, the urn: URI SHALL be resolved by querying the named resolution service instead of the resolution services typically relied upon by an implementation. Specifically, this specification defines r-authority to be a DNS name at which a resolver service may be addressed. The manner of association between the DNS name and specific resource records (e.g., NAPTR or SRV) is outside the scope of this specification. The r-authority production MAY identify names that are not DNS names, consistent with the reg-name discussion in Section 3.2.2 of [RFC3986], but cannot and SHALL NOT identify hosts by IP address. [[NB: The syntactic reason is because ":" delimits r-authority from r-params but "[" and "]" are not permitted. (Tried to use "!" but reg-name allows sub-delims. Alternative is to restrict reg-name to RFC 1035 hostnames, but that excludes non-DNS names, as well as technically valid DNS names that are not hostnames.) The semantic reason is because DNS or other name-lookup technologies are sort of implied by the various URN specifications over the last 25 years.]] 3.3.1.3. Resolution Parameters (r-params) A resolution service MAY accept additional parameters, the semantics of which are defined by the rop. To promote uniformity, this specification provides an overaching data model for these parameters. The syntax is based on experience with a variety of other query and fragment syntaxes, including those from http:, application/x-www- form-urlencoded, and application/pdf. [[NB: Experience over the last 25 years with the ambiguities and parsing craziness of application/x-www-form-urlencoded suggests that it is better for us to define how r-params work NOW, rather than leave it up to some pie-in-the-sky free-for-all down the line.]] Resolution parameters formally comprise a multimap (or map of lists). Each (unordered) name has an (ordered) list of zero or more values. The repertoire of names and values are the Unicode scalar values [UNICODE], plus the characters "$" and "+", which MAY have further reserved purposes. Names and values are case-sensitive and are not subject to Unicode normalization or other normalizing techniques. Saint-Andre & Klensin Expires May 19, 2016 [Page 16] =0C Internet-Draft URNs November 2015 Values are separated by ",". Pairs of name-plus-optional-values are separated by ";" or "&", which are equivalent to one another. However, ";" is RECOMMENDED because it is meant to be visually distinct from the q-component, which (in cases where HTTP is involved) will likely have "&" in the analogous positions. When encoded in r-params in a urn: URI, Unicode scalar values outside of unreserved ! ' ( ) * SHALL be percent-encoded in UTF-8, with the following special considerations. The gen-delim characters [ ] ? # MUST be percent-encoded because they do not conform to the query production of [RFC3986], or because they delimit the r-component from the subsequent components. The gen-delim characters : / @ SHOULD be percent-encoded (and the ABNF mandates this), but a generic receiver SHALL accept unencoded : / @ characters. The sub-delim characters ! ' ( ) * have no reserved purposes and therefore SHOULD NOT be percent-encoded; a generic receiver SHALL accept them whether percent-encoded or not. The rop MAY assign reserved purposes to the sub-delim characters $ +. Therefore, a generic generator SHOULD percent-encode $ + for generic inputs (particularly user-provided inputs) unless the generator knows that it is invoking the reserved purposes. These semantics exactly match the behavior of the encodeURIComponent() function in [ECMA-262]. Pairs are unordered and names are unique, so generators SHALL NOT generate pairs that have the same names. Generic receivers SHALL concatenate the values of multiple pairs that have the same names in the order in which they (both the pairs and the values) are received. In the event that a canonical form is needed, a canonical generator SHALL emit pairs in lexographical order (that is, [UNICODE] code point order) according to their names, and SHALL use ";" as the pair separator. A canonical generator SHALL percent-encode characters maked as SHOULD above, and SHALL NOT percent-encode characters marked as SHOULD NOT above. A canonical receiver MAY reject inputs that are not in canonical generated form (i.e., that have pairs with duplicate names, that use "&", or that do not percent-encode characters properly). 3.3.2. q-component The URN q-component has the same syntax as the URI query component. If a URN resolves to a URL with a scheme that supports a query component, the q-component from the URN is copied verbatim to the query component of the URL. If the URN does not resolve to a URL (i.e., is an abstract designator), the interpretation of the q-component is undefined by this specification. Saint-Andre & Klensin Expires May 19, 2016 [Page 17] =0C Internet-Draft URNs November 2015 The characters slash ("/") and question mark ("?") may represent data within the q-component. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the q-component SHALL NOT be taken into account when determining URN equivalence. Similarly, the q-component SHALL NOT be taken into account when resolving a URN to a URL and MUST NOT be used to communicate parameters to a resolution service. Consider the hypothetical example of passing parameters to an application that returns weather reports from different regions or for different time periods. This could perhaps be accomplished by specifying latitude/longitude coordinates and datetimes in the URN's q-component, resulting in URNs such as: urn:example:weather?map?lat=3D39.56&lon=3D-104.85& datetime=3D1969-07-21T02:56:15Z However, this primary purpose is not intended to forestall other potential uses for q-components for URNs that do not resolve to URLs. 3.3.3. f-component The URN f-component has the same syntax as the URI fragment component. When a URN containing an f-component resolves to a URL, the f-component from the URN is copied verbatim into the fragment of that URL. If the URN does not resolve to a URL (i.e., is an abstract designator), the interpretation of the f-component is undefined by this specification. The f-component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986]. As described under Section 4, the f-component SHALL NOT be taken into account when determining URN equivalence. Similarly, the f-component MUST NOT be passed to resolution servers when querying them for resource locations or metadata. The f-component is primarily intended to distinguish the constituent parts of resources named by URNs. Thus, for URNs that resolve to Saint-Andre & Klensin Expires May 19, 2016 [Page 18] =0C Internet-Draft URNs November 2015 URLs, the semantics of an f-component are defined by the media type of those resources, not by the namespace. Consider the hypothetical example of obtaining resources that are part of a larger entity (say, the chapters of a book). Each part could be specified in the f-component, resulting in URNs such as: urn:example:book2398292821#chapter2 However, this primary purpose is not intended to forestall other potential uses for f-components for URNs that do not resolve to URLs. 4. Equivalence of URNs 4.1. Procedure For various purposes such as caching, often it is desirable to determine if two URNs are "the same". This is done by testing for equivalence (see Section 6.1 of [RFC3986]). The generic URI specification [RFC3986] is very flexible about equality comparisons, putting the focus on allowing false negatives and avoiding false positives. If comparisons are made in a scheme- independent way, i.e., as URI comparisons only, URNs that this specification considers equal would be rejected. The discussion below applies when the URIs involved are known to be URNs. Two URNs are equivalent if their portions are octet- by-octet equal after applying case normalization (as specified in Section 6.2.2.1 of [RFC3986]) to the following constructs: 1. the URI scheme "urn", by conversion to lower case 2. the NID, by conversion to lower case 3. any percent-encoded characters in the NSS (that is, all character triplets that match the production found in Section 2.1 of the base URI specification [RFC3986]), by conversion to upper case for the digits A-F. Percent-encoded characters MUST NOT be decoded, i.e., percent- encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) MUST NOT be applied. If a q-component, r-component, or f-component (or any combination thereof) are included in a URN, they MUST be ignored for purposes of determining equivalence. Saint-Andre & Klensin Expires May 19, 2016 [Page 19] =0C Internet-Draft URNs November 2015 URN namespace definitions MAY include additional rules for equivalence, such as case-insensitivity of the NSS (or parts thereof). Such rules MUST always have the effect of eliminating some of the false negatives obtained by the procedure above and MUST NOT result in treating two URNs as not equivalent if the procedure here says they are equivalent. For related considerations with regard to NID registration, see below. 4.2. Examples This section shows a variety of URNs (using the "example" NID defined in [RFC6963]) that highlight the equivalence rules. First, because the scheme and NID are case-insensitive, the following URNs are equivalent to each other: o urn:example:a123,z456 o URN:example:a123,z456 o urn:EXAMPLE:a123,z456 Second, because the q-component and f-component are not taken into account for purposes of testing equivalence, the following URNs are equivalent to the first three examples above: o urn:example:a123,z456?abc o urn:example:a123,z456#789 o urn:example:a123,z456#abc Third, because the "/" character (and anything that follows it) in the NSS is taken into account for purposes of equivalence, the following URNs are not equivalent to each other or to the preceding URNs: o urn:example:a123,z456/foo o urn:example:a123,z456/bar o urn:example:a123,z456/baz Fourth, because of percent-encoding, the following URNs are equivalent only to each other (although %2C is the percent-encoded transformation of "," from the previous examples, such sequences are not decoded for purposes of testing equivalence): Saint-Andre & Klensin Expires May 19, 2016 [Page 20] =0C Internet-Draft URNs November 2015 o urn:example:a123%2Cz456 o URN:EXAMPLE:a123%2cz456 Fifth, because characters other than percent-encoded sequences in the NSS are treated in a case-sensitive manner (unless otherwise specified for the namespace in question), the following URNs are not equivalent to the first three URNs: o urn:example:A123,z456 o urn:example:a123,Z456 Sixth, on casual visual inspection of a URN presented in a human- oriented interface the following URN might appear the same as the first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be confused with U+0061 LATIN SMALL LETTER A), but it is not equivalent: o urn:example:%D0%B0123,z456 5. URI Conformance 5.1. Use in URI Protocol Slots Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI (e.g., the 'href' and 'src' attributes in HTML, the element in HTML, the 'xml:base' attribute in XML [XML-BASE], and the 'xmlns' attribute in XML for XML namespace names [XML-NAMES]). However, this does not imply that, semantically, it always makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN might not specify the location of a resource or even point indirectly to one, it might not be appropriate to place a URN in a URI protocol slot that points to a resource (e.g., the aforementioned 'href' and 'src' attributes). Ultimately, guidelines regarding when it is appropriate to use URIs under the "urn" scheme (or any other scheme) are the responsibility of specifications for individual URI protocol slots (e.g., the specification for the 'xml:base' attribute in XML might recommend that it is inappropriate to use URNs in that protocol slot). This specification cannot possibly anticipate all of the relevant cases, and it is not the place of this specification to require or restrict usage for individual protocol slots. Saint-Andre & Klensin Expires May 19, 2016 [Page 21] =0C Internet-Draft URNs November 2015 5.2. Parsing In part because of the separation of semantics from syntax [I-D.ietf-urnbis-semantics-clarif], generic URI processors need to pay special attention to the parsing and analysis rules of RFC 3986 and, in particular, must treat the URI as opaque unless the scheme and its requirements are recognized, in which case they may be in a position to invoke scheme-appropriate processing such as by a URN resolver. The URN resolver can either be an external resolver that the URI resolver knows of, or it can be functionality built into the URI resolver. Note that this requirement might impose constraints on the contexts in which URNs are appropriately used; see Section 5.1. 5.3. URNs and Relative References [RFC3986] Section 5.2 describes an algorithm for converting a URI reference that might be relative to a given base URI into "parsed components" of the target of that reference, which can then be recomposed per RFC 3986 Section 5.3 into a target URI. This algorithm cannot be applied directly to URNs because their syntax does not support the necessary path components. The notion of a URN as a "persistent", "permanent" identifier does not reconcile easily with relative referencing. However, resources named with URNs may contain relative references that do not apply to the URN itself. Therefore a relative reference SHOULD NOT be evaluated directly with respect to a URN. Instead, a relative reference SHOULD be evaluated indirectly with respect to one of the following: 1. a base URI (other than a URN) declared by the resource itself; or 2. a base URI (other than a URN) obtained through the URN resolution process; or 3. the URL of the resource as obtained through the URN resolution process (Case 2 permits the resolution process to explicitly supply a base URI if the resource content is supplied directly by the resolution service rather than via an intermediate "location" URI.) If no such base URI exists, use of a relative reference with respect to a URN is an error. Client behavior in this case is undefined. Resolution services SHOULD ensure that a base URI is supplied any time they provide resource content directly to a client. Saint-Andre & Klensin Expires May 19, 2016 [Page 22] =0C Internet-Draft URNs November 2015 5.4. Transport and Display When URNs are transported and exchanged, they MUST be represented in the format defined herein. Further, all URN-aware applications MUST offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by cut-and-paste techniques). Such applications might support display of URNs in a more human- friendly form and might use a character set that includes characters that are not permitted in URN syntax as defined in this specification (e.g., when displaying URNs to humans, such applications might replace percent-encoded strings with characters from an extended character repertoire such as Unicode [UNICODE]). To minimize user confusion, a URI browser SHOULD display the complete URN (including the "urn" scheme and any components) to ensure that there is no confusion between URN namespace identifiers and URI scheme identifiers. For example, a URI beginning with "urn:xmpp:" [RFC4854] is very different from a URI beginning with "xmpp:" [RFC5122]. Similarly, a potential DOI URI scheme [DOI-URI] is different from, and possibly completely unrelated to, a possible DOI URN namespace. 5.5. URI Design and Ownership As mentioned, the assignment of URNs is a managed process, as is the assignment of namespaces themselves. Although design of the URNs to be assigned within a given namespace is ceded by this specification to the namespace owner, doing so in a managed way avoids the problems inherent in unmanaged generation of URIs as described in the recommendations regarding URI design and ownership [RFC7320]. 6. URN Namespaces A URN namespace is a collection of identifiers that obey three constraints: each identifier is (1) unique, (2) assigned in a consistent way, and (3) assigned according to a common definition. 1. The "uniqueness" constraint means that an identifier within the namespace is never assigned to more than one resource and never reassigned to a different resource (for the kind of "resource" identified by URNs assigned within the namespace). This holds true even if the identifier itself is deprecated or becomes obsolete. 2. The "consistent assignment" constraint means that an identifier within the namespace is assigned by an organization or created in accordance with a process or algorithm that is always followed. Saint-Andre & Klensin Expires May 19, 2016 [Page 23] =0C Internet-Draft URNs November 2015 3. The "common definition" constraint means that there are clear definitions for the syntax of identifiers within the namespace and for the process of assigning or creating them. A URN namespace is identified by a particular NID in order to ensure the global uniqueness of URNs and, optionally, to provide a cue regarding the structure of URNs assigned within a namespace. With regard to global uniqueness, using different NIDs for different collections of identifiers ensures that no two URNs will be the same for different resources, since each collection is required to uniquely assign each identifier. However, a single resource MAY have more than one URN assigned to it, either in the same namespace (if the namespace permits it) or in different namespaces, and either for similar purposes or different purposes. (For example, if a book were published in a monograph series, it could have both an ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two URNs referring to the same book.) Subject to other constraints, such as those imposed by the URI syntax [RFC3986], the rules of the URN scheme are intended to allow preserving the normal and natural form of identifiers specified elsewhere when they are treated as URN namespaces. With regard to the structure of URNs assigned within a namespace, the development of an identifier structure (and thereby a collection of identifiers) depends on the requirements of the community defining the identifiers, how the identifiers will be assigned and used, etc. These issues are beyond the scope of URN syntax and the general rules for URN namespaces, because they are specific to the community defining a namespace (e.g., the bibliographic and publishing communities in the case of the 'ISBN' and 'ISSN' namespaces, or the developers of extensions to the Extensible Messaging and Presence Protocol in the case of the 'XMPP' namespace). URN namespaces inherit certain rights and responsibilities by the nature of URNs, e.g.: 1. They uphold the general principles of a well-managed URN namespace by providing persistent identification of resources and unique assignment of identifier strings in accordance with a common definition. 2. Optionally, they can be registered in global registration services. There are two types of URN namespace: formal and informal. These are distinguished by the expected level of service, the information needed to define the namespace, and the procedures for registration. Saint-Andre & Klensin Expires May 19, 2016 [Page 24] =0C Internet-Draft URNs November 2015 Because the majority of the namespaces registered so far have been formal, this document concentrates on formal namespaces. Note: [RFC3406] defined a third type of "experimental namespaces", denoted by prefixing the namespace identifier with the string "X-". Consistent with general IETF conclusions about similar approaches [RFC6648], this specification removes the experimental category and syntax. Because experimental namespaces were never registered, removing the experimental category has no impact on the existing registries. However, to avoid the potential for conflict between previously-allowed unregistered experimental namespaces and namespaces registered in the future, no registrations will be accepted for new namespaces beginning with "X-". Because they are not registered, strings that refer to experimental namespaces are not valid URNs. Truly experimental usages MAY, of course, employ the 'example' namespace [RFC6963]. 6.1. Formal Namespaces A formal namespace provides benefit to some subset of users on the Internet. In particular, it would not make sense for a formal namespace to be used only by a community or network that is not connected to the Internet. For example, it would be inappropriate for a NID to effectively force someone to use a proprietary network or service not open to the general Internet user. The intent is that, while the community of those who might actively use the names assigned within that NID might be small, the potential use of identifiers within that NID is open to any user on the Internet. Formal NIDs might be appropriate even when some aspects are not fully open. For example, a namespace might make use of a fee-based, privately managed, or proprietary registry for assignment of URNs in the namespace. However, it might still benefit some Internet users if the associated services have openly-published identifiers. An organization that will assign URNs within a formal namespace SHOULD meet the following criteria: 1. Organizational stability and the ability to maintain the URN namespace for a long time; absent such evidence, it ought to be clear how the namespace can remain viable if the organization can no longer maintain the namespace. 2. Competency in name assignment. This will improve the likelihood of persistence (e.g. to minimize the likelihood of conflicts). 3. Commitment to not reassigning existing names and to allowing old names to continue to be valid (e.g., if the assignee of a name is no longer a member or customer of the assigning organization, if Saint-Andre & Klensin Expires May 19, 2016 [Page 25] =0C Internet-Draft URNs November 2015 various information about the assignee or named entity happens to change, or even if the assignee or the named entity itself is no longer in existence; in all these cases, the name is still valid). A formal namespace establishes a particular NID, subject to the following constraints (above and beyond the syntax rules already specified): 1. It MUST NOT be an already-registered NID. 2. It MUST NOT start with "urn-" (which is reserved for informal namespaces). 3. It MUST be more than two characters long. 4. It MUST NOT start with ALPHA ALPHA "-", i.e., any string consisting of two letters followed by one hyphen. 5. It MUST NOT start with the string "xn--" or any other string consisting of two letters followed by two hyphens. Such strings are reserved for potential representation of DNS A-labels and similar strings in the future [RFC5890]. 6. It MUST NOT start with the string "X-" so that it will not be confused with or conflict any experimental namespace previously permitted by [RFC3406]. All two-letter strings, and all two-letter strings followed by "-" and any sequence of valid NID characters, are reserved for potential use as NIDs based on ISO alpha-2 country codes [ISO3166-1] for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such country-code-based namespaces is beyond the scope of this document. Applicants and reviewers considering new NIDs should also be aware that they may be considered as names with semantic implications and hence a source of conflict. Particular attention should be paid to strings that might be construed as names of, or registered under the authority of, countries (including ISO 3166-1 alpha-3 codes) and to strings that might imply association with existing URI schemes, identifier systems, or trademarks. However, in line with traditional policies, disputes about "ownership" of particular strings are disagreements among the parties involved; neither IANA nor the IETF will become involved in such disputes except in response to orders from a court of competent jurisdiction. Saint-Andre & Klensin Expires May 19, 2016 [Page 26] =0C Internet-Draft URNs November 2015 6.2. Informal Namespaces Informal namespaces are full-fledged URN namespaces, with all the associated rights and responsibilities. Informal namespaces differ from formal namespaces in the process for assigning a NID: for an informal namespace, the registrant does not designate the NID; instead, IANA assigns a NID consisting of the string 'urn-' followed by one or more digits (e.g., "urn-7") where the digits consist of the next available number in the sequence of positive integers assigned to informal namespaces. Thus the syntax of an informal namespace is: InformalNamespaceName =3D "urn-" Number Number =3D DigitNonZero 0*Digit DigitNonZero =3D "1"/ "2" / "3" / "4"/ "5" / "6" / "7" / "8" / "9" Digit =3D "0" / DigitNonZero The only restrictions on are that it (1) consist strictly of ASCII digits, that it (2) not have leading zeros, and that it (3) not cause the NID to exceed the length limitations defined for the URN syntax. 7. Defining and Registering a URN Namespace 7.1. Overview Because the space of URN namespaces is itself managed, the definition of a namespace SHOULD pay particular attention to: 1. The purpose of the namespace. 2. The syntax of URNs assigned within the namespace, including the anticipated effects of q-components, r-components, and f-components. 3. The process for assigning URNs within the namespace. 4. The security implications of assigning URNs within the namespace and using the assigned URNs. 5. Any potential interoperability issues with URNs assigned within the namespace. 6. Optionally, the process for resolving URNs issued within the namespace. The section on completing the template (Section 7.4) explains these matters in greater detail. While the registration templates are the Saint-Andre & Klensin Expires May 19, 2016 [Page 27] =0C Internet-Draft URNs November 2015 same, slightly different procedures are used depending on the source of the registration. 7.2. Registration Policy and Process: Community Registrations The basic registration policy for URN namespaces is Expert Review as defined in the "IANA Considerations" document [RFC5226]. For namespaces or their definitions that are intended to become standards or normative components of standards, the output of the Expert Review process is intended to be a report, rather than instructions to IANA to take action (see below). The key steps are: 1. Fill out the namespace registration template (see Section 7.4 and Appendix A). This can be done as part of an Internet-Draft or a specification in another series, although that is not necessary. 2. Send the completed template to the urn@ietf.org discussion list for review. 3. If necessary to address comments received, repeat steps 1 and 2. 4. If the designated experts approve the request and no standardization action is involved, the IANA will register the requested NID. If standardization is anticipated, the designated experts will prepare a report and forward it to the appropriate standards approval body (the IESG in the case of the IETF) and IANA will register the requested NID only after receiving directions from that body and a copy of the expert review report. A namespace registration can be revised by updating the registration template, following the same steps outlined above for new registrations. A revised registration MUST describe differences from prior versions and SHOULD make special note of any relevant changes in the underlying technologies or namespace management processes. Experience to date with namespace registration requests has shown that registrants sometimes do not initially understand some of the subtleties of URN namespaces, and that defining the namespace in the form of a specification enables the registrants to clearly formulate their "contract" with the intended user community. Therefore, although the registration policy for formal namespaces is Expert Review and a specification is not strictly required, it is RECOMMENDED for registrants to provide a stable specification documenting the namespace definition and expanding upon the issues described herein. Because naming can be difficult and contentious, namespace registrants and the designated experts are strongly encouraged to Saint-Andre & Klensin Expires May 19, 2016 [Page 28] =0C Internet-Draft URNs November 2015 work together in a spirit of good faith and mutual understanding to achieve rough consensus (see [RFC7282]) on handling registration requests. They are also encouraged to bring additional expertise into the discussion if that would be helpful in providing perspective or otherwise resolving issues. Especially when iterations in the registration process are prolonged, designated experts are expected to take reasonable precautions to avoid race conditions on proposed NID names and, if such situations arise, to encourage applicants to work out any conflicts among themselves. 7.3. Registration Policy and Process: Fast Track for Standards Development Organizations, Scientific Societies, and Similar Bodies The IETF recognizes that situations will arise in which URN namespaces will be created to either embed existing and established standards or to reflect knowledge, terminology, or information organization that lie well outside the IETF's scope or the likely subject matter knowledge of its Designated Experts. In situations in which the registration request originates from, or is authorized by, a recognized standards-related organization, scientific society, or similar body, a somewhat different procedure is available at the option of that body: 1. The namespace registration template is filled out and submitted as in steps 1 and 2 above. 2. A specification is required that reflects of points to the needed external standards or specifications. Publication in the RFC Series or through an IETF process (e.g., posting as an Internet Draft) is not expected and would be appropriate only under very unusual circumstances. 3. The reviews on the discussion list and by the designated experts are, however, strictly advisory, with the decisions about what advice to accept and the length of time to allocate to the process strictly under the control of the external body. 4. When that body concludes that the application is sufficiently mature, they will request that IANA will complete the registration for the NID and IANA will do so. Decisions about whether to recognize the requesting entity as a standards-related organization, scientific society, or similar body are the responsibility of the IESG. Saint-Andre & Klensin Expires May 19, 2016 [Page 29] =0C Internet-Draft URNs November 2015 Note that a similar model has already been defined for recognized standards-related organizations that wish to register Media Types. The document describing that mechanism [RFC6838] provides somewhat more information about the general approach. 7.4. Completing the Template A template for defining and registering a URN namespace is provided in Appendix A. This section describes considerations for completing the template. 7.4.1. Purpose The "Purpose" section of the template describes matters such as: 1. The kinds of resources identified by URNs assigned within the namespace. 2. The scope and applicability of the URNs assigned within the namespace; this might include information about the community of use (e.g., a particular nation, industry, technology, or organization), whether the assigned URNs will be used on public networks or private networks, etc. 3. How the intended community (and the Internet community at large) will benefit from using or resolving the assigned URNs. 4. How the namespace relates to and complements existing URN namespaces, URI schemes, and identifier systems. 5. The kinds of software applications that can use or resolve the assigned URNs (e.g., by differentiating among disparate namespaces, identifying resources in a persistent fashion, or meaningfully resolving and accessing services associated with the namespace). 6. Whether resolution services are available or will be available (and, if so, the nature or identity of the services). Examples of q- and r-component semantics and syntax are helpful here, even if they are registered or defined elsewhere later. 7. Whether the namespace or its definition are expected to become an integral or normative element of a standard being developed in the IETF or some other recognized standards body. Saint-Andre & Klensin Expires May 19, 2016 [Page 30] =0C Internet-Draft URNs November 2015 7.4.2. Syntax The "Syntax" section of the template contains: 1. A description of the structure of URNs within the namespace, in conformance with the fundamental URN syntax. The structure might be described in terms of a formal definition (e.g., using Augmented BNF for Syntax Specifications (ABNF) as specified in [RFC5234]), an algorithm for generating conformant URNs, or a regular expression for parsing the identifier into components; alternatively, the structure might be opaque. 2. Any special character encoding rules for assigned URNs (e.g., which character ought to always be used for quotes). 3. Rules for determining equivalence between two identifiers in the namespace. Such rules ought to always have the effect of eliminating false negatives that might otherwise result from comparison. If it is appropriate and helpful, reference can be made to specific equivalence rules defined in the URI specification [RFC3986]. Examples of equivalence rules include equivalence between uppercase and lowercase characters in the Namespace Specific String, between hyphenated and non-hyphenated groupings in the identifier string, or between single-quotes and double-quotes. (Note that these are not normative statements for any kind of best practice related to handling of equivalences between characters in general; they are statements limited to one particular namespace only.) 4. Any special considerations necessary for conforming with the URN syntax. This is particularly applicable in the case of existing naming systems that are used in the context of URNs. For example, if a namespace is used in contexts other than URNs, it might make use of characters that are reserved in the URN syntax. This section ought to note any such characters, and outline necessary mappings to conform to URN syntax. Normally, this will be handled by percent-encoding the character as specified in Section 2.1 of the URI specification [RFC3986]. 7.4.3. Assignment The "Assignment" section of the template describes matters such as: 1. Mechanisms or authorities for assigning URNs to resources. It ought to make clear whether assignment is completely open (e.g., following a particular procedure such as first-come, first-served (FCFS)), completely closed (e.g., for a private organization), or limited in various ways (e.g., delegated to authorities Saint-Andre & Klensin Expires May 19, 2016 [Page 31] =0C Internet-Draft URNs November 2015 recognized by a particular organization); if limited, it ought to explain how to become an assigner of identifiers or how to request assignment of identifiers from existing assignment authorities. 2. Methods for ensuring that URNs within the namespace are unique. For example, identifiers might be assigned sequentially or in accordance with some well-defined process by a single authority, assignment might be partitioned among delegated authorities that are individually responsible for respecting uniqueness rules, or URNs might be created independently following an algorithm that itself guarantees uniqueness. 7.4.4. Security and Privacy The "Security and Privacy" section of the template describes any potential issues related to security and privacy with regard to assignment, use, and resolution of identifiers within the namespace. Examples of such issues include: o The consequences of producing false negatives and false positives during comparison for equivalence (see "Issues in Identifier Comparison for Security Purposes" [RFC6943]) o Leakage of private information when identifiers are communicated on the public Internet o The potential for directory harvesting o Various issues discussed in the guidelines for security considerations in RFCs [RFC3552] and the privacy considerations for Internet protocols [RFC6973]. 7.4.5. Interoperability The "Interoperability" section MUST specify any potential issues related to interoperability. Examples include possible confusion with other URN namespaces or naming systems because of syntax (e.g., percent-encoding of certain characters) or scope (e.g., overlapping areas of interest). If at all possible, concerns that arise during the registration of a URN namespace (e.g., due to the syntax or scope of an identifier system) SHOULD be resolved as part of the registration process. Saint-Andre & Klensin Expires May 19, 2016 [Page 32] =0C Internet-Draft URNs November 2015 7.4.6. Resolution The "Resolution" section MUST specify whether resolution mechanisms are intended or anticipated for URNs assigned within the namespace (e.g., URNs within some namespaces are intended to act as abstract designators and thus are not intended to be resolved). If resolution is intended, then this section SHOULD specify whether the organization that assigns URNs within the namespace intends to operate or recommend any resolution services for URNs within that namespace. In addition, if the assigning organization intends to implement registration for publicly advertised resolution services (for example using a system based on principles similar to those described in [RFC2276] and [RFC2483]), then this section SHOULD list or reference the requirements for being publicly advertised by the assigning organization. [[NB: This section should also be updated to allow definitions or pointers to definitions of oidops (Section 3.3.1.1.2) and urnops (Section 3.3.1.1.4).]] 8. IANA Considerations 8.1. URI Scheme This section updates the registration of the 'urn' URI scheme in the Permanent URI Registry [URI-Registry] . [Note to RFC Editor: please replace "[ this document ]" with "RFC" and the number assigned to this document upon publication.] URI Scheme Name: urn Status: permanent URI Scheme Syntax: See Section 3 of [ this document ]. URI Scheme Semantics: The 'urn' scheme identifies Uniform Resource Names, which are persistent, location-independent resource identifiers. Encoding Considerations: See Section 3 of [ this document ]. Applications/Protocols That Use This URI Scheme Name: Uniform Resource Names are used in a wide variety of applications, including bibliographic reference systems and as names for Extensible Markup Language (XML) namespaces. Saint-Andre & Klensin Expires May 19, 2016 [Page 33] =0C Internet-Draft URNs November 2015 Interoperability Considerations: See Section 5 of [ this document ]. Security Considerations: See Section 7.4.4 and Section 9 of [ this document ]. Contact: URNBIS WG [mailto:urn@ietf.org] Author/Change Controller: This scheme is registered under the IETF tree. As such, the IETF maintains change control. References None. 8.2. Registration of URN Namespaces This document outlines the processes for registering URN namespaces, and has implications for the IANA in terms of registries to be maintained (see especially Section 7). In all cases, the IANA ought to assign the appropriate NID (formal or informal) once the procedures outlined in this document have been completed. 8.3. Updated text/uri-list Media Type IANA is to update the text/uri-list media type with the following registration template: Type name: text Subtype name: uri-list Required parameters: charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. The default value is US-ASCII. Implementations MUST support UTF-8; however, since UTF-8 is not the default, UTF-8 MUST be specified as a parameter when the content is encoded that way. Regardless of the charset, the URI productions are still [RFC3986]-based, not [RFC3987]-based (i.e., the URIs are not IRIs). Therefore, the charset primarily affects the attribute syntax and the comments rather than the URI productions. Optional parameters: [[NB: none currently but maybe attrfmt to define particular attribute formats.]] Encoding considerations: Some transfer protocols, such as SMTP, Saint-Andre & Klensin Expires May 19, 2016 [Page 34] =0C Internet-Draft URNs November 2015 place limits on the length of lines. Very long URIs might exceed those limits. Systems must therefore be prepared to use a suitable content transfer encoding. This is anticipated to occur rarely unless attributes are specified. Security considerations: Client software should be aware of the security considerations of URIs. For example, accessing some URIs can result in sending a death threat to a head of state, frequently prompting a visit from the relevant protective service. Accessing other URIs may result in financial obligations, or access to resources considered inappropriate by one's employer. While the legitimate provider of a uri-list could exploit these properties for good or ill, it is more likely that uri-lists will be falsified in order to exploit such characteristics of URIs. Additionally, the lookup and reverse lookup potential of the uri- list may be attractive to traffic analysts. URI lists may also reveal confidential information, such as the location of sensitive information. Because of these considerations, external confidentiality measures should be available to protect uri-list responses when appropriate. As any URI is potentially valid in a uri-list, a malicious condition may arise in which the URIs loop indefinitely when dereferenced. For example, resolving urn:example:foo may return a text/uri-list that contains urn:example:foo, possibly triggering an infinite loop. A parser SHOULD implement cycle detection algorithms and limits to prevent this type of condition. Interoperability considerations: None known. Published specification: Uniform Resource Locators (URLs) and Uniform Resource Names (URNs) are two instances of the more general class of identifiers known as Uniform Resource Identifiers (URIs). URN resolution methods frequently wish to return lists of URLs for a resource so that fault-tolerance and load balancing can be achieved. The text/uri-list format is intended to be a very simple format for communicating such lists of URLs (and URNs) in a form suitable for automatic processing. The format of text/uri-list resources is: Saint-Andre & Klensin Expires May 19, 2016 [Page 35] =0C Internet-Draft URNs November 2015 1) Any lines beginning with the '#' character are comment lines and are ignored during processing. (Note that URIs may contain the '#' character, so it is only a comment character when it is the first character on a line.) 2) The remaining non-comment lines SHALL be URIs (URNs or URLs), encoded according to the [RFC3986] or [[NB: this document]]. Each URI shall appear on one and only one line. Very long URIs are not broken in the text/uri-list format. Content-transfer-encodings may be used to enforce line length limitations. A non-comment line MAY also include arbitrary attributes associated with the URI. The attribute delimiter "|" is used for this purpose, since it is not a valid URI character. Everything following the first "|" up to the end of the line comprises the attribute content. A non-comment line MAY begin with "|", which indicates arbitrary attributes that are not associated with any particular URI. An implementation MAY use this syntax to convey arbitrary metadata without designating a URI; for example, the arbitrary metadata may be information about the originally requested URI (URN specifically, for URN resolvers). [[NB: The syntax of attributes is not currently defined, but... proposal:]] Attribute syntax is defined by the attrfmt parameter. When the attrfmt is "json": Attribute syntax is comprised of name/value pairs; the pairs are unordered. The format is and pairs are delimited by ",". Names that are not basic keywords/symbols MUST be quoted. The value is a JSON value. Essentially the syntax looks like a JavaScript object with the enclosing { } braces cut off. When the attrfmt is "cbor-base64": Attribute syntax is the base64 encoding of a CBOR-encoded item. The CBOR item is a map where the keys are anything and the values are anything. Additional attrfmt values can be provided: the standard for adding such values is RFC Required [RFC5226]. 3) As for all text/* formats, lines are terminated with a CRLF pair. Saint-Andre & Klensin Expires May 19, 2016 [Page 36] =0C Internet-Draft URNs November 2015 In applications where one URI has been mapped to a list of URIs, the first line of the text/uri-list response SHOULD be a comment giving the original URI. An example of the format is given below: # urn:isbn:0-201-08372-8 http://www.huh.org/books/foo.html http://www.huh.org/books/foo.pdf ftp://ftp.foo.org/books/foo.txt|font=3D"Inconsolata",ct=3D"text/plain"= Applications that use this media type: URN resolvers are the initial applications. Web clients and proxies are applicaitons that are likely to support this format in the future. Fragment identifier considerations: None. Additional information: Magic number(s): None File extension(s): .uris, .uri Macintosh file type code(s): URIs or TEXT. A uniform type identifier (UTI) of "public.XXX", which conforms to "public.plain-text", is RECOMMENDED. Person & email address to contact for further information: Sean Leonard Restrictions on usage: None. Author/Change controller: The IESG Intended usage: LIMITED USE The text/uri-list media type is intended for use in applications that use URIs for replicated resources. Provisional registration? No [[NB: put other things here]] [[andblahblahblah]] Saint-Andre & Klensin Expires May 19, 2016 [Page 37] =0C Internet-Draft URNs November 2015 9. Security and Privacy Considerations The definition of a URN namespace needs to account for potential security and privacy issues related to assignment, use, and resolution of identifiers within the namespace (e.g., some namespace resolvers might assign special meaning to certain characters in the Namespace Specific String); see Section 7.4.4 for further discussion. In most cases, URN namespaces provide a way to declare public information. Nominally, these declarations will have a relatively low security profile, however there is always the danger of "spoofing" and providing misinformation. Information in these declarations ought to be taken as advisory. 10. References 10.1. Normative References [ABNFMORE] Leonard, S., "Comprehensive Core Rules and References for ABNF", draft-seantek-abnf-more-core-rules-04 (work in progress), October 2015. [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [X.660] International Telecommunications Union, "Information Technology - Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree", ITU-T Recommendation X.660, July 2011. Saint-Andre & Klensin Expires May 19, 2016 [Page 38] =0C Internet-Draft URNs November 2015 [X.680] International Telecommunications Union, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, August 2015. 10.2. Informative References [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The "doi" URI Scheme for the Digital Object Identifier (DOI)", June 2003, . [ECMA-262] European Computer Manufacturers Association, "ECMAScript 2015 Language Specification", June 2015, . [I-D.ietf-urnbis-semantics-clarif] Klensin, J., "URN Semantics Clarification", draft-ietf- urnbis-semantics-clarif-02 (work in progress), August 2015. [ISO3166-1] ISO, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 2013. [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999. [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001. [RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001. Saint-Andre & Klensin Expires May 19, 2016 [Page 39] =0C Internet-Draft URNs November 2015 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)", RFC 4854, April 2007. [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security Purposes", RFC 6943, May 2013. [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace for Examples", BCP 183, RFC 6963, May 2013. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, June 2014. [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, July 2014. [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015-, . Saint-Andre & Klensin Expires May 19, 2016 [Page 40] =0C Internet-Draft URNs November 2015 [URI-Registry] IANA, "Permanent URI Schemes", . [XML-BASE] Marsh, J. and R. Tobin, "XML Base (Second Edition)", World Wide Web Consortium Recommendation REC-xmlbase-20090128, January 2009, . [XML-NAMES] Thompson, H., Hollander, D., Layman, A., Bray, T., and R. Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, . Appendix A. Registration Template Namespace ID: Requested of IANA (formal) or assigned by IANA (informal). Version: The version of the registration, starting with 1 and incrementing by 1 with each new version. Date: The date when the registration is requested of IANA, using the format YYYY-MM-DD. Registrant: The person or organization that has registered the NID, including the name and address of the registering organization, as well as the name and contact information (email, phone number, or postal address) of the designated contact person. If the registrant is a recognized standards development organization or scientific society requesting the fact track registration procedure (see Section 7.3), that information should be clearly indicated in this section of the template. Purpose: Described under Section 7.4.1 of this document. Syntax: Described under Section 7.4.2 of this document. Unless the registration explicitly says otherwise, use of q-components and f-components is not allowed for this namespace. Assignment: Described under Section 7.4.3 of this document. Security and Privacy: Described under Section 7.4.4 of this document. Saint-Andre & Klensin Expires May 19, 2016 [Page 41] =0C Internet-Draft URNs November 2015 Interoperability: Described under Section 7.4.5 of this document. Resolution: Described under Section 7.4.6 of this document. Documentation A pointer to an RFC, a specification published by another standards development organization, or another stable document that provides further information about the namespace. Revision Information: Description of changes from prior version(s). (Applicable only when earlier registrations have been revised.) Appendix B. Changes from RFC 2141 This document makes the following substantive changes from [RFC2141]: o Formally registers 'urn' as a URI scheme. o Disallows "-" at the end of a NID. o Allows the "/", "~", and "&" characters in the namespace-specific string (NSS). o Allows q-components, r-components, and f-components. Appendix C. Changes from RFC 3406 This document makes the following substantive changes from [RFC3406]: 1. Relaxes the registration policy for formal namespaces from "IETF Review" to "Expert Review" as discussed in Section 7.2. 2. Removes the category of experimental namespaces, consistent with [RFC6648]. 3. Simplifies the registration template. In addition, some of the text has been updated to be consistent with the definition of Uniform Resource Identifiers (URIs) [RFC3986] and the processes for registering information with the IANA [RFC5226], as well as more modern guidance with regard to security [RFC3552] and privacy [RFC6973] issues and identifier comparison [RFC6943]. Appendix D. Contributors RFC 2141, which provided the basis for the syntax portion of this document, was authored by Ryan Moats. Saint-Andre & Klensin Expires May 19, 2016 [Page 42] =0C Internet-Draft URNs November 2015 RFC 3406, which provided the basis for the namespace portion of this document, was authored by Leslie Daigle, Dirk-Willem van Gulik, Renato Iannella, and Patrik Faltstrom. Their work is gratefully acknowledged. Appendix E. Acknowledgements Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other participants in the URNBIS WG for their input. Alfred Hoenes in particular edited an earlier version of this document and served as co-chair of the URNBIS WG. Juha Hakala deserves special recognition for his dedication to successfully completing this work, as do Andrew Newton and Melinda Shore in their roles as working group co-chairs and Barry Leiba in his role as area director. Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn [[RFC Editor: please remove this appendix before publication.]] F.1. Changes from -08 to -09 o Altered the text in Section 5 to reflect list discussions about the earlier phrasing. Also added DOI example and citation to that section. o Clarified the naming rules for formal namespaces and their relationship to ISO 3166, IDNA, etc., reserved strings. o Added an explicit statement about use of URNs in various protocols and contexts to Section 5. o Clarified that experimental namespace NIDs, which were explicitly not registered, are not valid URNs (in Section 6. o Transformed the partial production in Section 6.2 into valid ABNF. o Added more text about p-/q-/f-components and recommendations about use. o Added clarifying note about "?" within q-components and f-components. Saint-Andre & Klensin Expires May 19, 2016 [Page 43] =0C Internet-Draft URNs November 2015 o Added explicit requirement that revisions of existing registrations document the changes and added a slot for that description to the template. o Many small editorial changes and adjustments including adding additional references and cross-references for clarification. o Inserted a placeholder for additional examples. F.2. Changes from -09 to -10 o Several clarifying editorial changes, most suggested by Ted Hardie and Henry S. Thompson (some of them off-list). o Added a large number of placeholders that identify issues that require WG consideration and resolution (or WG delegation to the editors). F.3. Changes from -10 to -11 o Removed most of the placeholders added in -10. Supplied new text as required or suggested by on-list discussion of those issues. o Replaced the conformance examples Section 4.2 with a more complete collection and discussion. o Revised and consolidated the registration procedure, and added provisions for NIDs that are the subject of standards and for avoiding race conditions about NID strings. o In response to independent comments from Ted Hardie and Henry S. Thompson, called attention to the possibility of conflicts between NID strings and various claims of national, corporate, and other perogatives. o Changed the production for assigned-name as suggested by Lars Svensson. o Several clarifying editorial changes including correcting a glitch in instructions to the RFC Editor. F.4. Changes from -11 to -12 o Removed p-components as a standalone construct, and instead folded them into the NSS. Saint-Andre & Klensin Expires May 19, 2016 [Page 44] =0C Internet-Draft URNs November 2015 o Defined syntax for r-components as a way to pass information to resolvers, but left the semantics for future standardization efforts. o Further tuned the discussion of interoperability and related registration issues. o Made a number of editorial corrections and reorganized the syntax material in Section 3 somewhat to make it internally consistent and keep the relationship to RFC 3986 clear. F.5. Changes from -12 to -13 o More precisely defined the semantics of the optional components. o Defined the term "resolution" and clarified several related matters throughout the text. o Clarified terminological relationship to RFC 3986. o Further cleansed the document of p-components. o Corrected several examples to avoid confusion with existing identifier systems. o Improved text regarding the purpose of namespaces being registered. F.6. Changes from -13 to -14 o Reverted the ABNF to what had been defined in version -12. o Added fast-track approval process for standards-related organizations, scientific societies, and similar bodies (similar to RFC 6838 for Media Types). Authors' Addresses Peter Saint-Andre &yet Email: peter@andyet.com URI: https://andyet.com/ Saint-Andre & Klensin Expires May 19, 2016 [Page 45] =0C Internet-Draft URNs November 2015 John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Saint-Andre & Klensin Expires May 19, 2016 [Page 46] --Apple-Mail=_8F2B2ABD-90CF-4F2C-98EF-3527EAC94AF1 Content-Disposition: attachment; filename=rfcdiff-urnbis-14-seantek.html Content-Type: text/html; name="rfcdiff-urnbis-14-seantek.html" Content-Transfer-Encoding: 7bit Content-Type: text/html Diff: draft-ietf-urnbis-rfc2141bis-urn-14.txt - draft-ietf-urnbis-rfc2141bis-urn-14-seantek.txt
< draft-ietf-urnbis-rfc2141bis-urn-14.txt   draft-ietf-urnbis-rfc2141bis-urn-14-seantek.txt >
URNBIS P. Saint-Andre URNBIS P. Saint-Andre
Internet-Draft &yet Internet-Draft &yet
Obsoletes: 2141, 3406 (if approved) J. Klensin Obsoletes: 2141, 3406 (if approved) J. Klensin
Intended status: Standards Track Intended status: Standards Track
Expires: May 4, 2016 November 1, 2015 Expires: May 19, 2016 November 16, 2015
Uniform Resource Names (URNs) Uniform Resource Names (URNs)
draft-ietf-urnbis-rfc2141bis-urn-14 draft-ietf-urnbis-rfc2141bis-urn-14-seantek
Abstract Abstract
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
that is assigned under the "urn" scheme and a particular URN that is assigned under the "urn" scheme and a particular URN
namespace, with the intent that the URN will be either a persistent, namespace, with the intent that the URN will be either a persistent,
location-independent resource identifier or in some cases an abstract location-independent resource identifier or in some cases an abstract
designator that is persistent but that does not identify a resource. designator that is persistent but that does not identify a resource.
With regard to URN syntax, this document defines the canonical syntax With regard to URN syntax, this document defines the canonical syntax
for URNs (in a way that is consistent with URI syntax), specifies for URNs (in a way that is consistent with URI syntax), specifies
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2016. This Internet-Draft will expire on May 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Namespace Identifier . . . . . . . . . . . . . . . . . . 6 3.1. Namespace Identifier . . . . . . . . . . . . . . . . . . 8
3.2. Namespace Specific String . . . . . . . . . . . . . . . . 6 3.2. Namespace Specific String . . . . . . . . . . . . . . . . 8
3.3. Optional Components . . . . . . . . . . . . . . . . . . . 7 3.3. Optional Components . . . . . . . . . . . . . . . . . . . 9
4. Equivalence of URNs . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. r-component . . . . . . . . . . . . . . . . . . . . . 11
4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2. q-component . . . . . . . . . . . . . . . . . . . . . 17
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.3. f-component . . . . . . . . . . . . . . . . . . . . . 18
5. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 13 4. Equivalence of URNs . . . . . . . . . . . . . . . . . . . . . 19
5.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 13 4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. URNs and Relative References . . . . . . . . . . . . . . 14 5. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Transport and Display . . . . . . . . . . . . . . . . . . 15 5.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 21
5.5. URI Design and Ownership . . . . . . . . . . . . . . . . 15 5.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. URNs and Relative References . . . . . . . . . . . . . . 22
6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 17 5.4. Transport and Display . . . . . . . . . . . . . . . . . . 23
6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 19 5.5. URI Design and Ownership . . . . . . . . . . . . . . . . 23
7. Defining and Registering a URN Namespace . . . . . . . . . . 19 6. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 25
7.2. Registration Policy and Process: Community Registrations 20 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 27
7. Defining and Registering a URN Namespace . . . . . . . . . . 27
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Registration Policy and Process: Community Registrations 28
7.3. Registration Policy and Process: Fast Track for Standards 7.3. Registration Policy and Process: Fast Track for Standards
Development Organizations, Scientific Societies, and Development Organizations, Scientific Societies, and
Similar Bodies . . . . . . . . . . . . . . . . . . . . . 21 Similar Bodies . . . . . . . . . . . . . . . . . . . . . 29
7.4. Completing the Template . . . . . . . . . . . . . . . . . 30
7.4. Completing the Template . . . . . . . . . . . . . . . . . 22 7.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 25 7.4.3. Assignment . . . . . . . . . . . . . . . . . . . . . 31
8.2. Registration of URN Namespaces . . . . . . . . . . . . . 26 7.4.4. Security and Privacy . . . . . . . . . . . . . . . . 32
9. Security and Privacy Considerations . . . . . . . . . . . . . 26 7.4.5. Interoperability . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4.6. Resolution . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . 27 8.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Registration Template . . . . . . . . . . . . . . . 29 8.2. Registration of URN Namespaces . . . . . . . . . . . . . 34
Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 30 8.3. Updated text/uri-list Media Type . . . . . . . . . . . . 34
Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 30 9. Security and Privacy Considerations . . . . . . . . . . . . . 38
Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Registration Template . . . . . . . . . . . . . . . 41
Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 42
Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 42
Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 42
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 43
Appendix F. Change log for versions of draft-ietf-urnbis- Appendix F. Change log for versions of draft-ietf-urnbis-
rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 31 rfc2141bis-urn . . . . . . . . . . . . . . . . . . . 43
F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 31 F.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 43
F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 32 F.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 44
F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 32 F.3. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 44
F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 32 F.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 44
F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 33 F.5. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 45
F.6. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 33 F.6. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
[RFC3986] that is assigned under the "urn" scheme and a particular [RFC3986] that is assigned under the "urn" scheme and a particular
namespace, with the intent that the URN will be either a persistent, namespace, with the intent that the URN will be either a persistent,
location-independent resource identifier or in some cases an abstract location-independent resource identifier or in some cases an abstract
designator that is persistent but that does not identify a resource. designator that is persistent but that does not identify a resource.
A URN namespace is a collection of such identifiers, each of which is A URN namespace is a collection of such identifiers, each of which is
(1) unique, (2) assigned in a consistent and managed way, and (3) (1) unique, (2) assigned in a consistent and managed way, and (3)
skipping to change at page 5, line 51 skipping to change at page 6, line 18
interactions with a URN resolution service. interactions with a URN resolution service.
o Makes several smaller syntax adjustments. o Makes several smaller syntax adjustments.
However, this specification does not extend the URN syntax to allow However, this specification does not extend the URN syntax to allow
characters outside the ASCII range [RFC20], which implies that any characters outside the ASCII range [RFC20], which implies that any
such characters need to be percent-encoded as described in such characters need to be percent-encoded as described in
Section 2.1 of the URI specification [RFC3986]. Section 2.1 of the URI specification [RFC3986].
The syntax for a URN is defined as follows using the Augmented The syntax for a URN is defined as follows using the Augmented
Backus-Naur Form (ABNF) as specified in [RFC5234]. Rules not defined Backus-Naur Form (ABNF) as specified in [RFC5234] and [ABNFMORE].
here (specifically: alphanum, fragment, and pchar) are defined as Rules not defined here (e.g., alphanum, fragment, and pchar) are
part of the URI syntax [RFC3986] and used here to point out the defined as part of the URI syntax [RFC3986] and used here to point
syntactic relationship with the terms used there. out the syntactic relationship with the terms used there.
namestring = assigned-name alphanum = alphanum@[RFC3986]
[ "?" q-component ] query = query@[RFC3986]
[ "??" r-component ] fragment = fragment@[RFC3986]
pchar = pchar@[RFC3986]
reg-name = reg-name@[RFC3986]
; numericoid@[RFC4512] is deficient--it permits
; prefixes other than 0-2.
; pct-encoded /may/ be deficient--in some places only UTF-8
; percent-encoding is permitted. (NB: this yields "interesting"
; problems when combined with q-components and f-components in
; some other unspecified character set/encoding.)
urn-uri = "urn" ":" assigned-name
[ "?" r-component [ "?" q-component ] ]
[ "#" f-component ] [ "#" f-component ]
assigned-name = "urn" ":" NID ":" NSS assigned-name = NID ":" NSS
NID = (alphanum) 0*30(ldh) (alphanum) NID = alphanum 0*30ldh alphanum
ldh = alphanum / "-" ldh = alphanum / "-"
NSS = pchar *(pchar / "/") NSS = pchar *(pchar / "/")
q-component = pchar *( pchar / "/" / "?" ) q-component = query
r-component = pchar *( pchar / "/" / "?" )
f-component = fragment f-component = fragment
r-component = rop [ "@" r-authority ] [ ":" r-params ]
; extension point: use different prefix symbols
rop = aop / oidop / roidop / urnop / nsop
aop = ( %x41-54 / %x56-5A / %x61-74 / %x76-7A )
0*30ldh alphanum /
"u" ( "-" / DIGIT / %x41-51 / %x53-5A /
%x61-71 / %x73-7A ) 0*29ldh alphanum /
"ur" ( "-" / DIGIT / %x41-4D / %x4F-5A /
%x61-6D / %x6F-7A ) 0*28ldh alphanum
oidop = numericoid
; compare with numericoid@[RFC4512], oid@[RFC3061]
numericoid = %x30-32 1*( "." number )
number = DIGIT / ( %x31-39 1*DIGIT )
roidop = numericroid
numericroid = 1*( "." number )
urnop = "urn" "*" NID "*" NSSop
nsop = "*" NSSop
NSSop = reg-name ; syntax, not semantics
r-authority = reg-name
; overall repertoire is *(pchar / "/")
; NB: shall we structure r-params here, or defer,
; or make it rop-dependent?
r-params = r-param *( ( ";" / "&" ) r-param )
r-param = rp-name [ "=" rp-values ]
rp-name = rp-word
rp-values = rp-value *( "," rp-value )
rp-value = rp-word
; mostly isomorphic with encodeURIComponent except $ and +
; but that is intentional
rp-word = *( unreserved / pct-encoded / "!" / "$" / "'" /
"(" / ")" / "*" / "+" )
The question mark character "?" can be used without percent-encoding The question mark character "?" can be used without percent-encoding
inside q-components, r-components, and f-components. However, it is inside q-components and f-components. It SHALL NOT appear inside
likely to cause confusion if question marks (especially consecutive r-components, unless it is percent-encoded.
ones) are placed inside the r-component, or if a question mark is
placed at the start or end of an r-comonents or q-component;
therefore such usage is discouraged although not prohibited.
The following sections provide additional information about the The following sections provide additional information about the
syntactic elements of URNs. syntactic elements of URNs.
3.1. Namespace Identifier 3.1. Namespace Identifier
The syntax here is slightly more restrictive than what was defined in The syntax here is slightly more restrictive than what was defined in
[RFC2141], because it prohibits the character "-" at the end of a [RFC2141], because it prohibits the character "-" at the end of a
NID. NID.
Note that NIDs are case insensitive (e.g., "ISBN" and "isbn" are NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent).
equivalent).
Characters outside the ASCII range [RFC20] are not permitted in NIDs, Characters outside the ASCII range [RFC20] are not permitted in NIDs,
and no encoding mechanism for such characters is supported. and no encoding mechanism for such characters is supported.
3.2. Namespace Specific String 3.2. Namespace Specific String
The namespace specific string (NSS) is a unique identifier that is The namespace specific string (NSS) is a unique identifier that is
assigned and managed in a consistent way and that conforms to the assigned and managed in a consistent way and that conforms to the
definition of the relevant namespace. The combination of the NID definition of the relevant namespace. The combination of the NID
(unique across the entire "urn" scheme) and the NSS (unique within (unique across the entire "urn" scheme) and the NSS (unique within
skipping to change at page 7, line 48 skipping to change at page 9, line 19
In order to make URNs as stable and persistent as possible when In order to make URNs as stable and persistent as possible when
protocols evolve and the environment around them changes, namespaces protocols evolve and the environment around them changes, namespaces
SHOULD NOT allow characters outside the basic Latin repertoire SHOULD NOT allow characters outside the basic Latin repertoire
[RFC20] unless the nature of the particular namespace makes such [RFC20] unless the nature of the particular namespace makes such
characters necessary. characters necessary.
3.3. Optional Components 3.3. Optional Components
As compared to [RFC2141], this document extends the URN syntax to As compared to [RFC2141], this document extends the URN syntax to
permit inclusion of three new types of components: q-component, permit inclusion of three new types of components: q-component,
r-component, and f-component. Because this specification focuses r-component, and f-component. Each of these components has a
almost exclusively on URN syntax, it does not define detailed distinct role, which is independent of the URN and its namespace, and
semantics for these components for URNs in general. However, each of it is intended that clients will be able to handle these components
these components has a distinct role, which is independent of the URN uniformly for all URNs. In general:
and its namespace, and it is intended that clients will be able to
handle these components uniformly for all URNs. In general:
o The q-component is intended for parameters to be transmitted to
the named resource and interpreted by that resource.
o The r-component is intended for parameters to be transmitted to o The r-component is intended for parameters to be transmitted to
resolution services and interpreted by those services. resolution services and interpreted by those services.
o The q-component is intended for parameters to be transmitted to
and interpreted by or with respect to the products of the
resolution services, such as resources identified by URIs.
o The f-component is intended to be interpreted by the client as a o The f-component is intended to be interpreted by the client as a
specification for a location within, or region of, the named specification for a location within, or region of, the
resource. dereferenced resources.
The foregoing generalizations are true regardless of the URN's The foregoing generalizations are true regardless of the URN's
namespace. namespace.
(This paragraph is informative.) An exemplary resolution-to-resource
model may help with conceptualizing the relationship between the
components of a urn: URI:
1. A client requests resources by urn: URI, invoking a URI handler.
2. A URI handler parses the "urn" URI scheme, the f-component, and
everything else.
3. The URI handler invokes a urn: URI handler, passing everything
else.
4. The urn: URI handler parses everything else into the assigned-
name, r-component, and q-component.
5. The urn: URI handler calls a resolution service, passing the
assigned-name and r-component to it as arguments.
6. The resolution service returns some intermediate products, which
may include resources, resource identifiers (i.e.,
dereferenceable URIs), or attributes such as metadata.
7. The urn: URI handler combines the q-component with the
intermediate products. When the combinations result in
dereferenceable URIs, the handler dereferences the URIs.
(Collectively, the products of the resolution services encompass
both these intermediate products and the computing resources at
the other end of the dereferenceable URIs.)
8. The urn: URI handler acquires resources, which may be content
(i.e., having Internet media types). The urn: URI handler may
interact with the URI handler and the client to pick from among
the resources.
9. The urn: URI handler returns some of these resources to the URI
handler.
10. The URI handler interprets the f-component, likely interacting
with a media type handler and the client to identify and locate
sub-resources within the dereferenced resources.
To assist with implementing URN resolution services, [RFC2483]
registered the text/uri-list media type. Section 8.3 updates that
media type registration to include arbitrary attributes.
Whenever a URN resolves to a URL which may be used to access the Whenever a URN resolves to a URL which may be used to access the
resource, there is a more specific interpretation of q-component and resource, there is a more specific interpretation of q-component and
f-component: the q-component is copied verbatim to the query portion f-component: the q-component is copied verbatim to the query portion
of the URL (if that URL scheme supports query), and the f-component of the URL (if that URL scheme supports query), and the f-component
is copied verbatim to the fragment portion of the URL. This is is copied verbatim to the fragment portion of the URL. This is
necessary, among other reasons, so that interpretation of q-component necessary, among other reasons, so that interpretation of q-component
and f-component, when associated with URNs, will be consistent with and f-component, when associated with URNs, will be consistent with
the interpretation of relative references containing queries or the interpretation of relative references containing queries or
fragments within documents which are ultimately accessible via URNs. fragments within documents which are ultimately accessible via URNs.
Thus, for URNs which may be resolved to a URL, the semantics of Thus, for URNs which may be resolved to a URL, the semantics of
q-component are identical to those for queries to that resource and q-component are identical to those for queries to that resource and
the semantics of f-components are identical to those of fragments for the semantics of f-components are identical to those of fragments for
that resource. The semantics of q-component and f-component for URNs that resource. The semantics of q-component and f-component for URNs
that inherently cannot be resolved to a URL (i.e., for abstract that inherently cannot be resolved to a URL (i.e., for abstract
designators) are undefined by this document; however, they SHOULD be designators) are undefined by this document; however, they SHOULD be
consistent with the above roles. It is expected that additional consistent with the above roles.
specifications will define the semantics of r-components.
Note: In general, neither the syntax nor the semantics of In general, neither the syntax nor the semantics of q-components or
q-components or f-components are defined by, or dependent on, the f-components are defined by, or dependent on, the namespace of the
namespace of the URN. A particular namespace might, however, define URN.
uses of r-components that are specific to its namespace and supported
by the resolution services which that namespace operates or
recommends.
Any of these components MAY be used with URNs from existing Any of these components MAY be used with URNs from existing
namespaces whether or not the namespace explicitly supports them. As namespaces whether or not the namespace explicitly supports them. As
described above, the interpretation of q-component and f-component is described above, the interpretation of q-component and f-component is
namespace-independent. Interpretation of an r-component may be namespace-independent. Interpretation of an r-component may be
namespace-dependent to some degree if it relies on behavior of a namespace-dependent to some degree if it relies on behavior of a
namespace-specific resolution service. If a URN contains namespace-specific resolution service, as discussed in the following
r-components that are not defined by the namespace, the meaning of sections.
the URN and result of resolution are out of scope for this
specification.
3.3.1. q-component
The URN q-component has the same syntax as the URI query component.
If a URN resolves to a URL with a scheme that supports a query
component, the q-component from the URN is copied verbatim to the
query component of the URL. If the URN does not resolve to a URL
(i.e., is an abstract designator), the interpretation of the
q-component is undefined by this specification.
The q-component is indicated by the first question mark ("?")
character and terminated by a double question mark ("??") indicating
an r-component, by a number sign ("#") character indicating an
f-component, or by the end of the URI. The characters slash ("/")
and question mark ("?") may represent data within the q-component.
Note that characters outside the ASCII range [RFC20] MUST be percent-
encoded using the method defined in Section 2.1 of the generic URI
specification [RFC3986].
As described under Section 4, the q-component SHALL NOT be taken into
account when determining URN equivalence.
Similarly, the q-component SHALL NOT be taken into account when
resolving a URN to a URL and MUST NOT be used to communicate
parameters to a resolution service.
Consider the hypothetical example of passing parameters to an
application that returns weather reports from different regions and/
or for different time periods. This could perhaps be accomplished by
specifying lat/long coordinates and datetimes in the URN's
q-component, resulting in URNs such as the following.
urn:example:weather?op=map&lat=39.56&lon=-104.85&datetime=1969-07-21T
02:56:15Z
However, this primary purpose is not intended to forestall other
potential uses for q-components for URNs that do not resolve to URLs.
3.3.2. r-component 3.3.1. r-component
The URN r-component has no syntactic equivalent in URIs. The URN r-component has no syntactic equivalent in URIs.
The r-component is indicated by a double question mark ("??") and The r-component is indicated by a first question mark ("?") and
terminated by a number sign ("#") character indicating an f-component terminated by a second question mark indicating a q-component, a
or by the end of the URI. The characters slash ("/") and question number sign ("#") character indicating an f-component, or by the end
mark ("?") may represent data within the r-component. Note that of the URI. The characters in the r-component have been carefully
chosen to eliminate ambiguity and to ease parsing. Note that
characters outside the ASCII range [RFC20] MUST be percent-encoded characters outside the ASCII range [RFC20] MUST be percent-encoded
using the method defined in Section 2.1 of the generic URI using the method defined in Section 2.1 of the generic URI
specification [RFC3986]. specification [RFC3986].
As described under Section 4, the r-component SHALL NOT be taken into As described under Section 4, the r-component SHALL NOT be taken into
account when determining URN equivalence. account when determining URN equivalence.
However, the r-component SHALL be supplied along with the URN when However, the r-component SHALL be supplied along with the URN when
presenting a request to a URN resolution service. presenting a request to a URN resolution service.
The r-component is entirely intended for passing information in The r-component is entirely intended for passing information in
requests to URN resolution services. The r-component is not intended requests to URN resolution services. The r-component is not intended
for passing information to the resources identified by a URN or to for passing information to the products of the resolution services,
applications that manage such resources, since that is the function to the resources identified by the URN, or to applications that
of the q-component. In addition, the r-component is not intended for manage such resources. In addition, the r-component is not intended
passing information to any underlying services that might exist for passing information to any underlying services that might exist
behind a resolver, only to the resolver itself. behind a resolver, only to the resolver itself.
This document defines only the syntax of the r-component and reserves To make URNs implementable, this specification provides a syntax and
it for future use. The exact semantics of the r-component and its semantics for r-components. An r-component contains a resolution
use in URN resolution protocols are a matter for potential operation (called a "rop", rhymes with "hop"), an authority, and a
standardization in separate specifications. set of parameters. When the r-component is present, the rop is
REQUIRED.
Consider the hypothetical example of passing parameters to resolution Consider the hypothetical example of passing parameters to resolution
service (say, an ISO alpha-2 country code [ISO3166-1] in order to service (say, an ISO alpha-2 country code [ISO3166-1] in order to
scope down the preferred country in which to search for a physical scope down the preferred country in which to search for a physical
copy of a book). This could perhaps be accomplished by specifying copy of a book). This could perhaps be accomplished by specifying
the country code in the r-component, resulting in URNs such as: the country code in the r-component, resulting in URNs such as:
urn:example:foo-bar-baz-qux??cc=uk urn:example:book3292323923?loc:cc=de
However, this primary purpose is not intended to forestall other However, this primary purpose is not intended to forestall other
potential uses for r-components. potential uses for r-components.
3.3.1.1. Resolution Operation (rop)
URNs that are not abstract designators are meant to be resolved. The
resolution operation or "rop" (formerly called a "facet" or "resolver
profile" during WG discussion) directs a resolver as to what services
to supply. A rop generically and universally applies to all URNs; it
is therefore orthogonal to the namespace identified by the NID
production in a urn: URI. For example, the urn:isbn namespace tends
to identify books, but a rop "bookinfo" should succeed for all
identifiers that correspond to books, not just to those with ISBNs.
Furthermore, there may be identifiers assigned by the International
ISBN Agency that fit in the urn:isbn namespace, but do not correspond
to books.
Since URNs are extremely generic, a syntax to identify resolution
operations should likewise be generic. Unlike the persistence (i.e.,
consistent and managed assignment) guarantees required of the URN
assigned-name portion, however, defining and implementing novel
resolution operations should be as frictionless as possible.
Removing such barriers will promote the development of resolution
services in a variety of communities and use cases.
This specification defines five types of rops: aop, oidop, roidop,
urnop, and nsop, along with an ABNF-compatible extension technique
for future specifications. For reasons that follow, this
specification RECOMMENDS that oidop be used as the primary technique
for specifying resolution operations.
3.3.1.1.1. Alpha rop
An Alpha rop (aop) is an identifier that starts with an alphabetic
character, ends with an alphanumeric character, and may contain
alphanumeric or hyphen characters. The aop production SHALL NOT
begin with the characters "urn". The aop production is case-
insensitive. An aop is globally unique. The bar to establish an aop
identifier is RFC Required [RFC5226].
[[NB: At this time, there is no IANA registry proposed for aops. If
the WG feels it is needed, it should probably be a sub-registry of
URN Namespaces. Just a suggestion.]]
As a stylistic suggestion, aops SHOULD be basic US-English words or
phrases. The terms should be simple or compound verbs that describe
the operation ("display", "buy", "pickfromwarehouse"), or if the verb
is related to retrieving a representation, aka "getting" ("get PDF",
"get price", "get scoreboard"), the terms should be simple or
compound nouns with the verb omitted ("pdf", "price", "scoreboard").
For exemplary purposes, this specification defines three aops "info",
"hinfo", and "minfo".
The "info" operation directs a resolver to return information about
the resource or class of resources identified by the assigned-name of
the urn: URI. (This definition contrasts with information about the
identifier, such as a written explanation of how the identifier is
composed or broken down. This definition also contrasts with
information that comprises the resource itself, such as a PDF copy of
a book.) The expectation is that the products of resolution will
eventually dereference to content (data with Internet media types)
that are human-readable or machine-readable.
The "hinfo" operation directs a resolver to return human-readable
information about the resource or class of resources identified by
the assigned-name of the urn: URI. For example, content would be
limited to media types such as text/plain, text/html, text/rtf, or
image/jpeg, where when the information is presented to a human being,
the human being would be able to understand it.
The "minfo" operation directs a resolver to return machine-readable
information about the resource or class of resources identified by
the assigned-name of the urn: URI. For example, content would be
limited to media types such as application/json or application/
rdf+xml, where when that information is fed into an automated
process, the automated process would be able to take concrete action
on it.
For purposes of simplicity, these aops MAY take arbitrary r-params
(Section 3.3.1.3) but this specification does not bother to define or
anticipate any in particular.
3.3.1.1.2. Object Identifier rop
An Object Identifier rop (oidop) is an Object Identifier [X.660].
The oidop production starts with a number 0, 1, or 2, followed by a
series of one or more dotted whole numbers. The bar to establish an
oidop is extremely low: just assign an OID and away you go. OIDs are
compared for exact equality, and there is no semantic hierarchy to
OID components other than those assigned by [X.660]. Furthermore,
implementations that parse and present URNs to humans MAY display the
OID with a human-readable equivalent, such as a localized string.
For these reasons, this specification RECOMMENDS that implementers
use oidop to define resolution operations.
3.3.1.1.3. Relative Object Identifier rop
A Relative Object Identifier rop (roidop) is a Relative Object
Identifier [X.680]. Syntactically the roidop production is a series
of one or more dotted whole numbers; therefore, roidop always starts
with a dot. Relative Object Identifiers are always defined relative
to some base Object Identifier. This specification does not define
any particular base OID. Therefore, this syntax is basically
reserved for future use. An implementation MAY use this rop type
internally, but it is not currently intended for interchange.
3.3.1.1.4. Uniform Resource Name rop
A Uniform Resource Name rop (urnop) is an operation defined by a URN
namespace authority, thus making it globally unique. An urnop
production SHALL begin with "urn*". The NID follows this mandatory
prefix. After the NID comes another "*", and an operation-specific
string (NSSop) [[NB: or possibly OSS?]]. The NSSop production has
the same syntax as reg-name but different semantics: it is an opaque
string assigned by the namespace authority for defining resolution
operations. The "urn*" and NID productions are case-insensitive, but
the NSSop production MAY be case-sensitive or have complex
equivalence algorithms, depending on the definition promulgated by
the namespace authority.
As stated above, resolution operations are (at least potentially)
universally applicable, rather than namespace-specific. This syntax
provides a convenient means for a namespace authority to construct a
globally unique string for operations that are internally relevant to
its identified resources, but that could apply more broadly to other
identifiers. The NSSop productions occupy an orthogonal namespace to
the NSS productions, so <urn:example:foobar2015> and
<urn*example*foobar2015> do not necessarily refer to the same thing.
[[NB: NSSop as a restricted character repertoire compared with NSS,
because characters such as : / and @ lead to ambiguity in the ABNF,
thus making parsing a lot more complicated. * was chosen because it
looks like a bullet or middle dot and therefore most closely
resembles a "generic operator".]]
Due to the potential complexity inherent in the equivalence question,
using urnop is NOT RECOMMENDED (an oidop can suffice).
3.3.1.1.5. Namespace rop
A Namespace rop (nsop) is an operation defined by the same URN
namespace authority as the NID production in the urn: URI, thus
making it globally unique. It has the same semantics as urnop above,
except that "*" is syntactic sugar for "urn*" NID "*". This syntax
basically recognizes that there will be appreciable use cases where
the namespace authority has some operations in mind, and it may be
most expedient for the namespace authority to promulgate these
operations itself.
Due to the potential complexity inherent in the equivalence question,
using nsop is NOT RECOMMENDED (an oidop can suffice).
3.3.1.1.6. Extension Technique
The ABNF above can be extended to include syntaxes for other kinds of
operations. The five rops defined in this specification are easily
distinguished by their first characters: ALPHA except "urn" (aop),
0-2 (oidop), "." (roidop), "urn*" (urnop), and "*" (nsop).
Therefore, future specifications MAY provide new operation syntaxes
that begin with the following characters:
-
_
~
$
&
'
+
=
"urn" (anything other than *)
(any number greater than 2)
However, the following characters SHALL NOT be used, because they
would make the subsequent components ambiguous:
# f-component
? q-component
@ r-authority
: r-params
[ ] only in IP literals
The following characters could be used, but are NOT RECOMMENDED for
the following reasons:
/ implies hierarchical thing going on
( ) implies matching with other parenthesis
, confused with separator, e.g., in r-params
; confused with separator, e.g., in r-params
3.3.1.2. Resolution Authority (r-authority)
The r-authority production specifies which resolver to use for URN
resolution. The reg-name production and semantics from [RFC3986] are
used for r-production in this draft. When r-authority is present,
the urn: URI SHALL be resolved by querying the named resolution
service instead of the resolution services typically relied upon by
an implementation. Specifically, this specification defines
r-authority to be a DNS name at which a resolver service may be
addressed. The manner of association between the DNS name and
specific resource records (e.g., NAPTR or SRV) is outside the scope
of this specification. The r-authority production MAY identify names
that are not DNS names, consistent with the reg-name discussion in
Section 3.2.2 of [RFC3986], but cannot and SHALL NOT identify hosts
by IP address. [[NB: The syntactic reason is because ":" delimits
r-authority from r-params but "[" and "]" are not permitted. (Tried
to use "!" but reg-name allows sub-delims. Alternative is to
restrict reg-name to RFC 1035 hostnames, but that excludes non-DNS
names, as well as technically valid DNS names that are not
hostnames.) The semantic reason is because DNS or other name-lookup
technologies are sort of implied by the various URN specifications
over the last 25 years.]]
3.3.1.3. Resolution Parameters (r-params)
A resolution service MAY accept additional parameters, the semantics
of which are defined by the rop. To promote uniformity, this
specification provides an overaching data model for these parameters.
The syntax is based on experience with a variety of other query and
fragment syntaxes, including those from http:, application/x-www-
form-urlencoded, and application/pdf.
[[NB: Experience over the last 25 years with the ambiguities and
parsing craziness of application/x-www-form-urlencoded suggests that
it is better for us to define how r-params work NOW, rather than
leave it up to some pie-in-the-sky free-for-all down the line.]]
Resolution parameters formally comprise a multimap (or map of lists).
Each (unordered) name has an (ordered) list of zero or more values.
The repertoire of names and values are the Unicode scalar values
[UNICODE], plus the characters "$" and "+", which MAY have further
reserved purposes. Names and values are case-sensitive and are not
subject to Unicode normalization or other normalizing techniques.
Values are separated by ",". Pairs of name-plus-optional-values are
separated by ";" or "&", which are equivalent to one another.
However, ";" is RECOMMENDED because it is meant to be visually
distinct from the q-component, which (in cases where HTTP is
involved) will likely have "&" in the analogous positions.
When encoded in r-params in a urn: URI, Unicode scalar values outside
of unreserved ! ' ( ) * SHALL be percent-encoded in UTF-8, with the
following special considerations. The gen-delim characters [ ] ? #
MUST be percent-encoded because they do not conform to the query
production of [RFC3986], or because they delimit the r-component from
the subsequent components. The gen-delim characters : / @ SHOULD be
percent-encoded (and the ABNF mandates this), but a generic receiver
SHALL accept unencoded : / @ characters. The sub-delim characters !
' ( ) * have no reserved purposes and therefore SHOULD NOT be
percent-encoded; a generic receiver SHALL accept them whether
percent-encoded or not. The rop MAY assign reserved purposes to the
sub-delim characters $ +. Therefore, a generic generator SHOULD
percent-encode $ + for generic inputs (particularly user-provided
inputs) unless the generator knows that it is invoking the reserved
purposes. These semantics exactly match the behavior of the
encodeURIComponent() function in [ECMA-262].
Pairs are unordered and names are unique, so generators SHALL NOT
generate pairs that have the same names. Generic receivers SHALL
concatenate the values of multiple pairs that have the same names in
the order in which they (both the pairs and the values) are received.
In the event that a canonical form is needed, a canonical generator
SHALL emit pairs in lexographical order (that is, [UNICODE] code
point order) according to their names, and SHALL use ";" as the pair
separator. A canonical generator SHALL percent-encode characters
maked as SHOULD above, and SHALL NOT percent-encode characters marked
as SHOULD NOT above. A canonical receiver MAY reject inputs that are
not in canonical generated form (i.e., that have pairs with duplicate
names, that use "&", or that do not percent-encode characters
properly).
3.3.2. q-component
The URN q-component has the same syntax as the URI query component.
If a URN resolves to a URL with a scheme that supports a query
component, the q-component from the URN is copied verbatim to the
query component of the URL. If the URN does not resolve to a URL
(i.e., is an abstract designator), the interpretation of the
q-component is undefined by this specification.
The characters slash ("/") and question mark ("?") may represent data
within the q-component. Note that characters outside the ASCII range
[RFC20] MUST be percent-encoded using the method defined in
Section 2.1 of the generic URI specification [RFC3986].
As described under Section 4, the q-component SHALL NOT be taken into
account when determining URN equivalence.
Similarly, the q-component SHALL NOT be taken into account when
resolving a URN to a URL and MUST NOT be used to communicate
parameters to a resolution service.
Consider the hypothetical example of passing parameters to an
application that returns weather reports from different regions or
for different time periods. This could perhaps be accomplished by
specifying latitude/longitude coordinates and datetimes in the URN's
q-component, resulting in URNs such as:
urn:example:weather?map?lat=39.56&lon=-104.85&
datetime=1969-07-21T02:56:15Z
However, this primary purpose is not intended to forestall other
potential uses for q-components for URNs that do not resolve to URLs.
3.3.3. f-component 3.3.3. f-component
The URN f-component has the same syntax as the URI fragment The URN f-component has the same syntax as the URI fragment
component. When a URN containing an f-component resolves to a URL, component. When a URN containing an f-component resolves to a URL,
the f-component from the URN is copied verbatim into the fragment of the f-component from the URN is copied verbatim into the fragment of
that URL. If the URN does not resolve to a URL (i.e., is an abstract that URL. If the URN does not resolve to a URL (i.e., is an abstract
designator), the interpretation of the f-component is undefined by designator), the interpretation of the f-component is undefined by
this specification. this specification.
The f-component is indicated by the presence of a number sign ("#") The f-component is indicated by the presence of a number sign ("#")
skipping to change at page 11, line 20 skipping to change at page 19, line 11
The f-component is primarily intended to distinguish the constituent The f-component is primarily intended to distinguish the constituent
parts of resources named by URNs. Thus, for URNs that resolve to parts of resources named by URNs. Thus, for URNs that resolve to
URLs, the semantics of an f-component are defined by the media type URLs, the semantics of an f-component are defined by the media type
of those resources, not by the namespace. of those resources, not by the namespace.
Consider the hypothetical example of obtaining resources that are Consider the hypothetical example of obtaining resources that are
part of a larger entity (say, the chapters of a book). Each part part of a larger entity (say, the chapters of a book). Each part
could be specified in the f-component, resulting in URNs such as: could be specified in the f-component, resulting in URNs such as:
urn:example:foo-bar-baz-qux#somepart urn:example:book2398292821#chapter2
However, this primary purpose is not intended to forestall other However, this primary purpose is not intended to forestall other
potential uses for f-components for URNs that do not resolve to URLs. potential uses for f-components for URNs that do not resolve to URLs.
4. Equivalence of URNs 4. Equivalence of URNs
4.1. Procedure 4.1. Procedure
For various purposes such as caching, often it is desirable to For various purposes such as caching, often it is desirable to
determine if two URNs are "the same". This is done by testing for determine if two URNs are "the same". This is done by testing for
skipping to change at page 19, line 38 skipping to change at page 27, line 36
7. Defining and Registering a URN Namespace 7. Defining and Registering a URN Namespace
7.1. Overview 7.1. Overview
Because the space of URN namespaces is itself managed, the definition Because the space of URN namespaces is itself managed, the definition
of a namespace SHOULD pay particular attention to: of a namespace SHOULD pay particular attention to:
1. The purpose of the namespace. 1. The purpose of the namespace.
2. The syntax of URNs assigned within the namespace, including 2. The syntax of URNs assigned within the namespace, including the
whether q-components, r-components, or f-components are allowed. anticipated effects of q-components, r-components, and
f-components.
3. The process for assigning URNs within the namespace. 3. The process for assigning URNs within the namespace.
4. The security implications of assigning URNs within the namespace 4. The security implications of assigning URNs within the namespace
and using the assigned URNs. and using the assigned URNs.
5. Any potential interoperability issues with URNs assigned within 5. Any potential interoperability issues with URNs assigned within
the namespace. the namespace.
6. Optionally, the process for resolving URNs issued within the 6. Optionally, the process for resolving URNs issued within the
skipping to change at page 25, line 22 skipping to change at page 33, line 22
If resolution is intended, then this section SHOULD specify whether If resolution is intended, then this section SHOULD specify whether
the organization that assigns URNs within the namespace intends to the organization that assigns URNs within the namespace intends to
operate or recommend any resolution services for URNs within that operate or recommend any resolution services for URNs within that
namespace. In addition, if the assigning organization intends to namespace. In addition, if the assigning organization intends to
implement registration for publicly advertised resolution services implement registration for publicly advertised resolution services
(for example using a system based on principles similar to those (for example using a system based on principles similar to those
described in [RFC2276] and [RFC2483]), then this section SHOULD list described in [RFC2276] and [RFC2483]), then this section SHOULD list
or reference the requirements for being publicly advertised by the or reference the requirements for being publicly advertised by the
assigning organization. assigning organization.
[[NB: This section should also be updated to allow definitions or
pointers to definitions of oidops (Section 3.3.1.1.2) and urnops
(Section 3.3.1.1.4).]]
8. IANA Considerations 8. IANA Considerations
8.1. URI Scheme 8.1. URI Scheme
This section updates the registration of the 'urn' URI scheme in the This section updates the registration of the 'urn' URI scheme in the
Permanent URI Registry [URI-Registry] . Permanent URI Registry [URI-Registry] .
[Note to RFC Editor: please replace "[ this document ]" with "RFC" [Note to RFC Editor: please replace "[ this document ]" with "RFC"
and the number assigned to this document upon publication.] and the number assigned to this document upon publication.]
skipping to change at page 26, line 20 skipping to change at page 34, line 25
References None. References None.
8.2. Registration of URN Namespaces 8.2. Registration of URN Namespaces
This document outlines the processes for registering URN namespaces, This document outlines the processes for registering URN namespaces,
and has implications for the IANA in terms of registries to be and has implications for the IANA in terms of registries to be
maintained (see especially Section 7). In all cases, the IANA ought maintained (see especially Section 7). In all cases, the IANA ought
to assign the appropriate NID (formal or informal) once the to assign the appropriate NID (formal or informal) once the
procedures outlined in this document have been completed. procedures outlined in this document have been completed.
8.3. Updated text/uri-list Media Type
IANA is to update the text/uri-list media type with the following
registration template:
Type name: text
Subtype name: uri-list
Required parameters:
charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. The
default value is US-ASCII. Implementations MUST support UTF-8;
however, since UTF-8 is not the default, UTF-8 MUST be specified
as a parameter when the content is encoded that way. Regardless
of the charset, the URI productions are still [RFC3986]-based,
not [RFC3987]-based (i.e., the URIs are not IRIs). Therefore,
the charset primarily affects the attribute syntax and
the comments rather than the URI productions.
Optional parameters:
[[NB: none currently but maybe attrfmt to define particular attribute
formats.]]
Encoding considerations:
Some transfer protocols, such as SMTP,
place limits on the length of lines. Very long URIs might exceed
those limits. Systems must therefore be prepared to use a suitable
content transfer encoding. This is anticipated to occur rarely
unless attributes are specified.
Security considerations:
Client software should be aware of the
security considerations of URIs. For example, accessing some URIs
can result in sending a death threat to a head of state, frequently
prompting a visit from the relevant protective service. Accessing
other URIs may result in financial obligations, or access to
resources considered inappropriate by one's employer.
While the legitimate provider of a uri-list could exploit these
properties for good or ill, it is more likely that uri-lists will be
falsified in order to exploit such characteristics of URIs.
Additionally, the lookup and reverse lookup potential of the uri-
list may be attractive to traffic analysts. URI lists may also
reveal confidential information, such as the location of sensitive
information.
Because of these considerations, external confidentiality measures
should be available to protect uri-list responses when appropriate.
As any URI is potentially valid in a uri-list, a malicious
condition may arise in which the URIs loop indefinitely when
dereferenced. For example, resolving urn:example:foo may return
a text/uri-list that contains urn:example:foo, possibly triggering
an infinite loop. A parser SHOULD implement cycle detection
algorithms and limits to prevent this type of condition.
Interoperability considerations: None known.
Published specification:
Uniform Resource Locators (URLs) and
Uniform Resource Names (URNs) are two instances of the more general
class of identifiers known as Uniform Resource Identifiers (URIs).
URN resolution methods frequently wish to return lists of URLs for a
resource so that fault-tolerance and load balancing can be achieved.
The text/uri-list format is intended to be a very simple format for
communicating such lists of URLs (and URNs) in a form suitable for
automatic processing.
The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
and are ignored during processing. (Note that URIs may contain
the '#' character, so it is only a comment character when it is
the first character on a line.)
2) The remaining non-comment lines SHALL be URIs (URNs or URLs),
encoded according to the [RFC3986] or [[NB: this document]].
Each URI shall appear on one and only one
line. Very long URIs are not broken in the text/uri-list format.
Content-transfer-encodings may be used to enforce line length
limitations.
A non-comment line MAY also include arbitrary attributes
associated with the URI. The attribute delimiter "|" is used
for this purpose, since it is not a valid URI character.
Everything following the first "|" up to the end of the line
comprises the attribute content.
A non-comment line MAY begin with "|", which indicates
arbitrary attributes that are not associated with any
particular URI. An implementation MAY use this syntax
to convey arbitrary metadata without designating a URI;
for example, the arbitrary metadata may be information
about the originally requested URI (URN specifically,
for URN resolvers).
[[NB: The syntax of attributes is not currently defined, but...
proposal:]]
Attribute syntax is defined by the attrfmt parameter.
When the attrfmt is "json":
Attribute syntax is comprised of name/value pairs; the pairs are
unordered. The format is <name ":" value> and pairs are delimited
by ",". Names that are not basic keywords/symbols MUST be quoted.
The value is a JSON value. Essentially the syntax looks like
a JavaScript object with the enclosing { } braces cut off.
When the attrfmt is "cbor-base64":
Attribute syntax is the base64 encoding of a CBOR-encoded item.
The CBOR item is a map where the keys are anything and the values
are anything.
Additional attrfmt values can be provided: the standard
for adding such values is RFC Required [RFC5226].
3) As for all text/* formats, lines are terminated with a CRLF pair.
In applications where one URI has been mapped to a list of URIs, the
first line of the text/uri-list response SHOULD be a comment giving
the original URI.
An example of the format is given below:
# urn:isbn:0-201-08372-8
http://www.huh.org/books/foo.html
http://www.huh.org/books/foo.pdf
ftp://ftp.foo.org/books/foo.txt|font="Inconsolata",ct="text/plain"
Applications that use this media type:
URN resolvers are the initial applications.
Web clients and proxies are applicaitons that are likely
to support this format in the future.
Fragment identifier considerations: None.
Additional information:
Magic number(s): None
File extension(s): .uris, .uri
Macintosh file type code(s):
URIs or TEXT. A uniform type identifier (UTI) of
"public.XXX", which conforms to "public.plain-text",
is RECOMMENDED.
Person & email address to contact for further information:
Sean Leonard <dev&ietf@seantek.com>
Restrictions on usage: None.
Author/Change controller: The IESG
Intended usage: LIMITED USE
The text/uri-list media type is intended for use in applications
that use URIs for replicated resources.
Provisional registration? No
[[NB: put other things here]]
[[andblahblahblah]]
9. Security and Privacy Considerations 9. Security and Privacy Considerations
The definition of a URN namespace needs to account for potential The definition of a URN namespace needs to account for potential
security and privacy issues related to assignment, use, and security and privacy issues related to assignment, use, and
resolution of identifiers within the namespace (e.g., some namespace resolution of identifiers within the namespace (e.g., some namespace
resolvers might assign special meaning to certain characters in the resolvers might assign special meaning to certain characters in the
Namespace Specific String); see Section 7.4.4 for further discussion. Namespace Specific String); see Section 7.4.4 for further discussion.
In most cases, URN namespaces provide a way to declare public In most cases, URN namespaces provide a way to declare public
information. Nominally, these declarations will have a relatively information. Nominally, these declarations will have a relatively
low security profile, however there is always the danger of low security profile, however there is always the danger of
"spoofing" and providing misinformation. Information in these "spoofing" and providing misinformation. Information in these
declarations ought to be taken as advisory. declarations ought to be taken as advisory.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ABNFMORE]
Leonard, S., "Comprehensive Core Rules and References for
ABNF", draft-seantek-abnf-more-core-rules-04 (work in
progress), October 2015.
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[X.660] International Telecommunications Union, "Information
Technology - Procedures for the operation of object
identifier registration authorities: General procedures
and top arcs of the international object identifier tree",
ITU-T Recommendation X.660, July 2011.
[X.680] International Telecommunications Union, "Information
Technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation", ITU-T Recommendation
X.680, August 2015.
10.2. Informative References 10.2. Informative References
[DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The
"doi" URI Scheme for the Digital Object Identifier (DOI)", "doi" URI Scheme for the Digital Object Identifier (DOI)",
June 2003, June 2003,
<http://tools.ietf.org/id/draft-paskin-doi-uri-04.txt>. <http://tools.ietf.org/id/draft-paskin-doi-uri-04.txt>.
[ECMA-262]
European Computer Manufacturers Association, "ECMAScript
2015 Language Specification", June 2015,
<http://www.ecma-international.org/ecma-262/6.0/>.
[I-D.ietf-urnbis-semantics-clarif] [I-D.ietf-urnbis-semantics-clarif]
Klensin, J., "URN Semantics Clarification", draft-ietf- Klensin, J., "URN Semantics Clarification", draft-ietf-
urnbis-semantics-clarif-02 (work in progress), August urnbis-semantics-clarif-02 (work in progress), August
2015. 2015.
[ISO3166-1] [ISO3166-1]
ISO, "Codes for the representation of names of countries ISO, "Codes for the representation of names of countries
and their subdivisions -- Part 1: Country codes", ISO and their subdivisions -- Part 1: Country codes", ISO
3166-1:2013, 2013. 3166-1:2013, 2013.
skipping to change at page 28, line 47 skipping to change at page 41, line 6
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC
7282, June 2014. 7282, June 2014.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC
7320, July 2014. 7320, July 2014.
[UNICODE] The Unicode Consortium, "The Unicode Standard", 2015-, [UNICODE] The Unicode Consortium, "The Unicode Standard", 2015-,
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
[URI-Registry] [URI-Registry]
IANA, "Permanent URI Schemes", <http://www.iana.org/ IANA, "Permanent URI Schemes",
assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1>. <http://www.iana.org/assignments/uri-schemes/
uri-schemes.xhtml#uri-schemes-1>.
[XML-BASE] [XML-BASE]
Marsh, J. and R. Tobin, "XML Base (Second Edition)", World Marsh, J. and R. Tobin, "XML Base (Second Edition)", World
Wide Web Consortium Recommendation REC-xmlbase-20090128, Wide Web Consortium Recommendation REC-xmlbase-20090128,
January 2009, January 2009,
<http://www.w3.org/TR/2009/REC-xmlbase-20090128>. <http://www.w3.org/TR/2009/REC-xmlbase-20090128>.
[XML-NAMES] [XML-NAMES]
Thompson, H., Hollander, D., Layman, A., Bray, T., and R. Thompson, H., Hollander, D., Layman, A., Bray, T., and R.
Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide
skipping to change at page 31, line 10 skipping to change at page 43, line 16
document, was authored by Leslie Daigle, Dirk-Willem van Gulik, document, was authored by Leslie Daigle, Dirk-Willem van Gulik,
Renato Iannella, and Patrik Faltstrom. Renato Iannella, and Patrik Faltstrom.
Their work is gratefully acknowledged. Their work is gratefully acknowledged.
Appendix E. Acknowledgements Appendix E. Acknowledgements
Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha
Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean
Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian
Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other
participants in the URNBIS WG for their input. Alfred Hoenes in participants in the URNBIS WG for their input. Alfred Hoenes in
particular edited an earlier version of this document and served as particular edited an earlier version of this document and served as
co-chair of the URNBIS WG. co-chair of the URNBIS WG.
Juha Hakala deserves special recognition for his dedication to Juha Hakala deserves special recognition for his dedication to
successfully completing this work, as do Andrew Newton and Melinda successfully completing this work, as do Andrew Newton and Melinda
Shore in their roles as working group co-chairs and Barry Leiba in Shore in their roles as working group co-chairs and Barry Leiba in
his role as area director. his role as area director.
Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn Appendix F. Change log for versions of draft-ietf-urnbis-rfc2141bis-urn
skipping to change at page 32, line 10 skipping to change at page 44, line 17
description to the template. description to the template.
o Many small editorial changes and adjustments including adding o Many small editorial changes and adjustments including adding
additional references and cross-references for clarification. additional references and cross-references for clarification.
o Inserted a placeholder for additional examples. o Inserted a placeholder for additional examples.
F.2. Changes from -09 to -10 F.2. Changes from -09 to -10
o Several clarifying editorial changes, most suggested by Ted Hardie o Several clarifying editorial changes, most suggested by Ted Hardie
and Henry S. Thompson (some of them off-list). and Henry S. Thompson (some of them off-list).
o Added a large number of placeholders that identify issues that o Added a large number of placeholders that identify issues that
require WG consideration and resolution (or WG delegation to the require WG consideration and resolution (or WG delegation to the
editors). editors).
F.3. Changes from -10 to -11 F.3. Changes from -10 to -11
o Removed most of the placeholders added in -10. Supplied new text o Removed most of the placeholders added in -10. Supplied new text
as required or suggested by on-list discussion of those issues. as required or suggested by on-list discussion of those issues.
 End of changes. 37 change blocks. 
144 lines changed or deleted 705 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail=_8F2B2ABD-90CF-4F2C-98EF-3527EAC94AF1-- --Apple-Mail=_D5351720-8BAC-4EA1-854C-17DA4C1CBE11 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTE2MjExMTEwWjAjBgkqhkiG9w0BCQQxFgQUnACXWvW4rBJ+d4LDofL2J0XfMPcwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAJljxf2SJqsO/gWuMCPnIHC47Tg4ZYXQiCAA7iMHNYNufQ2B7Otoeem8aNnu8J4vyBPe mG3YKVK7Jj7IGzaIEqCWAwHNvY+xqTZDKYz8iVxsLba9qApJvSWj3cGAxwM/SZ0/s9S9JKXaohnr vynLIROk8QigCTpMVvnQHNEc4M/7UakzQ068FJMQeBDybhrJnncpdl/3QKro9JHlWe/Dpqgd37kH YvAo9yTc9ko1tiPt46IExNyCxr7DzEPYz3Rp6yirYGLAK5f1oVPz3vuFAEJcgEe40sFswDE7DnxC bTt4yYHsUrH9eG3xqFR7CcVHwFTdcYWhGmMnXwuWk1sAt/wAAAAAAAA= --Apple-Mail=_D5351720-8BAC-4EA1-854C-17DA4C1CBE11-- From nobody Fri Nov 20 05:08:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792F11A0151 for ; Fri, 20 Nov 2015 05:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKYNHPutTsEa for ; Fri, 20 Nov 2015 05:08:31 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C861A0128 for ; Fri, 20 Nov 2015 05:08:30 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB017.eurprd07.prod.outlook.com (10.242.81.16) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 13:08:14 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Fri, 20 Nov 2015 13:08:13 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0331.019; Fri, 20 Nov 2015 13:08:13 +0000 From: "Hakala, Juha E" To: "urn@ietf.org" Thread-Topic: Suggested changes to rfc2141bis-14 Thread-Index: AdEjkVylORy7rhaTRz2w2Ey3YYKOow== Date: Fri, 20 Nov 2015 13:08:13 +0000 Message-ID: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 5:YO91pM4UOsT/indq32PvhAkYBSGzYRmJd2wrHH9Kjc10sJUqXhZzVD/4pW4obvk2MW4ZR+10RQjPjxK7lq0p5jq/Hd/1qOiSq6/gohg1WTE6B4BIKPh1x9huF+Rgi+MGp19uKqf9ZT+63KVPSf5F6Q==; 24:DYw19CBkgGAdG0F4hTy/vgyjfCcjyaCT6nEs3tdapld639a1R3TjJolfjGimD0l/o4zWoGH/5QU5XficF5ob1owAROZavClBiiHLss+2F0c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(252514010)(5008740100001)(40100003)(105586002)(87936001)(76576001)(77096005)(97736004)(101416001)(33656002)(5007970100001)(74316001)(5004730100002)(10400500002)(106356001)(54356999)(2501003)(86362001)(5001920100001)(66066001)(74482002)(110136002)(586003)(11100500001)(19580395003)(5002640100001)(50986999)(189998001)(2900100001)(19580405001)(102836003)(5003600100002)(229853001)(122556002)(92566002)(3846002)(6116002)(5001960100002)(81156007)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 13:08:13.3024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB017; 2:1G0nLpkIkFkZp7O7F83rJqhYm0SX31ZNP0toCfX4JDJZ/bHSTKt7OM7yHG++UjRSEPeFCzziej4cpQw+D5FaT+sjedkCuH1yN03wrd6ZxVzrVCPmeu9xNhw7e2URiMGI207P1hnPY2EkVJU09l5uj5scS9vxJi8kaJmMLGj4W6M=; 23:2sRCYlXWmRIqeB9tkX20XAJHMXTITMBCxo7SY1u8l59y18Li4UbmXDDgwFK/mTsfawaBbQKiSIIlLuBygcPkcBmvnhIVdhOxrSlNYZR0bR1PeAN7fAZ2XzQP9vUCuEDpHMea3F0tLoNd4EzpDS0cR+MWPHsLMsv7PShDLF/8cut/BGBo80iO0+/xaIajMG8I X-OriginatorOrg: helsinki.fi Archived-At: Cc: Tobias Weigel Subject: [urn] Suggested changes to rfc2141bis-14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 13:08:34 -0000 Hello, Four minor change requests to the latest URN syntax specification:=20 1. rfc2141bis-14 states in chapter 3.3.1 that "q-component SHALL NOT be tak= en into account when resolving a URN to a URL".=20 There are two problems with this:=20 First, a URN can be resolved to 1-n URLs. =20 Second, depending on what service is being requested, it may be necessary t= o resolve a URN to different URLs. For instance, if a user wants the identi= fied resource, the URL will be the one belonging to a digital asset managem= ent system holding the document. But if the just descriptive metadata about= the resource is requested, the most appropriate URL may be the one of the = national bibliography.=20 I suggest the following modification of 21421bis:=20 "As described under Section 4, the q-component SHALL NOT be taken into acco= unt when determining URN equivalence. Similarly, the q-component MUST NOT be used to communicate service related = requests and parameters to a resolution service. A resolution service MAY parse the q-component in order to determine an app= ropriate target system to supply the requested service. " 2. IMO there is a slight problem with this sentence from chapter 3.3.: "The q-component is intended for parameters to be transmitted to the named = resource and interpreted by that resource." It is not always the case that the result of the resolution is the named re= source. A more accurate wording might be the following:=20 The q-component is intended for parameters to be transmitted to either the = named resource or a system that can supply the requested service, and inter= preted by that resource or system. 3. In chapter 3.3.3, the draft currently says:=20 "When a URN containing an f-component resolves to a URL, the f-component fr= om the URN is copied verbatim into the fragment of that URL." and a bit later:=20 "Similarly, the f-component MUST NOT be passed to resolution servers when q= uerying them for resource locations or metadata." The problem with the former sentence is that the URN does not always resolv= e to the URL of the identified resource. If the result is an information pa= ge describing the resource or a metadata record, adding a fragment does not= make sense. And IMO the latter sentence is meaningless since resolution se= rvers should a priori ignore f-components no matter what service is being r= equested. Of course, web browsers usually do not send fragments at all to H= TTP servers, so at least in the case of HTTP it would be a bad idea to use = f-component in the resolution process.=20 We are better off saying for instance:=20 "If a URN containing an f-component resolves to a URL of the named resource= , the f-component from the URN can be applied (usually by the client) verba= tim as the fragment of that URL.=20 Clients SHOULD NOT pass f-components to resolution servers. If a URN contai= ning an f-component is received by a resolution server, the server SHOULD i= gnore the f-component when processing the URN. 4. A bit later in the same chapter, there is a sentence "Thus, for URNs that resolve to URLs, the semantics of an f-component are d= efined by the media type of those resources, not by the namespace." A more accurate version:=20 "Thus, for URNs that resolve to URLs of the named resources, the semantics = of an f-component are defined by the media type of those resources, not by = the namespace." Some URNs may resolve only to e.g. URLs of metadata records describing the = named resources, and in such case f-component is not applicable. Of course = it might be possible that the media type of the metadata record would allow= use of f-component / fragment, but in that case the appropriate f-componen= t can only be applied to the URN of the metadata record itself. Resolution = processes will become increasingly complex, and there is no way of knowing = the media type of the thing resolution process produces unless it is the na= med resource itself.=20 Apart from these minor glitches the draft looks fine to me.=20 I have not had time to consider Sean's revision of -14 yet; shall do that n= ext week.=20 Best,=20 Juha -- Juha Hakala Senior advisor =A0The National Library of Finland Library Network Services=20 =A0P.O.Box 26 (Kaikukatu 4) FIN-00014 Helsinki University Gsm: +358 50 3827678 email: juha.hakala@helsinki.fi=20 From nobody Fri Nov 20 13:54:12 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19141B3EB6 for ; Fri, 20 Nov 2015 13:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd31BS0BpIpE for ; Fri, 20 Nov 2015 13:54:08 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6437B1B3EB5 for ; Fri, 20 Nov 2015 13:54:08 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Zztd8-000AXi-VZ; Fri, 20 Nov 2015 16:54:06 -0500 Date: Fri, 20 Nov 2015 16:54:01 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 21:54:10 -0000 --On Monday, November 16, 2015 13:09 -0800 Sean Leonard wrote: > URNies: > > Please find a revision of urnbis-rfc2141bis attached (if these > attachments get accepted), which you can refer to as the > "14-seantek" (or "14s") revision. I used the XML > version posted directly on ietf.org and edited that. I am also > including the output of rfcdiff. > > This is what I want to see added to the draft, based on > discussions over the last ~4 to 6 months. People (notably the > chairs) have been asking to "send text" so here is the > text. >... Sean, Partially as an explanation of why you (and the WG) are going to see two or more responses from me to other notes before I respond in more detail or with changes to the draft related to this one, while I really appreciate your good intentions and willingness to supply text, please do not, in future, do so by posting an alternate document. It doesn't give me (or Peter, or the WG or its leadership) enough information about what problem you are trying to solve and why you believe the proposed new text helps and, because other changes have already been made to the working draft, it creates a more complex and time-consuming merge requirement than is really needed. This should probably be a private, off-list, note, but I think it may be helpful for the WG to see it to get a better sense of what is going on (and to more quickly tell me I'm out of line if I am). There are several of your changes that I really like even though I'm nervous about teasing out intent and unanticipated changes in some cases and have major issues in some others. Others are more difficult. As an example, your proposed ABNF is dependent on draft-seantek-abnf-more-core-rules-04. I really don't have an opinion about that document, but I have a very strong preference that we avoid normative references to I-Ds that are not under control of the WG because such references regularly turn into another block to timely publication. I can probably fix that for this case, but it implies more work and creates a new risk. Both Peter and I have said "I am not an ABNF expert" several times. I can't speak for Peter, but, to be completely candid, my problem with ABNF stems from a deep dislike of it that is, in turn, based on many years of work with metalanguage design and application to formal language definition and standardization. >From that point of view --which I will freely admit is partially about aesthetics and religious conviction rather than clear technology boundaries-- ABNF is reasonably good for descriptive purposes but fairly bad for definitional ones. It gets worse when people think "regular expression matching" and then try to write ABNF, with 3986 and its "will match one of the following" construction unfortunately being a poster child for that problem. It is almost independent, but, when I'm looking at that small bit of text, I completely agree with your "N.B." comment. But I think that, if we try to address it, or even get entangled with it, in 2141bis, we go straight down a rathole from which their may be no escape (if you are interested in the problem, try to have a look at the W3C i18n "encoding" draft -- I don't remember if there is a reasonably recent public version, but, if you can't find it, write me offlist and I'll try to track it down and work something out). In any event, if you provide the WG with variant ABNF that doesn't quite work with 5334 or that raises extra issues with 3986, it just about guarantees a slow response (and, unfortunately, my having "can't deal with that right now" reactions and finding something else to do). Your "exemplary model" approach is, IMO, elegant and provides one way to deal with the "metacomment" note I'll be posting shortly (to some small extent, it contributed to it). However, that approach is rarely taken in the IETF and I've seen documents shot down because they said "this is one example of how to do it but other examples are conforming as long as they produce similar or identical results". So I think it ill-advised to splice it into the document without a discussion with Andy and the WG and more or less explicit sign-off from Barry and maybe the other ARD ADs. I've got some similar concerns about, e.g., normative dependency on X.660. In other places, you've rewritten whole sections and taken the document into places, such as with your "rop" model, that the WG has not, IMO, discussed at all, much less agreed on. So I'm going to pull out what I can from the text for -15. I've already spent about six hours trying to go through it and separate the editorial changes from major new proposals and directions. That feels like a lot of time. Especially if no one else seems inclined to comment in detail on the new bits, I thing I need instructions from Andy as to how to proceed with the rest. Thanks again for the attempt and considerable useful text even if I think you want a bit off into areas that are unnecessary or inappropriate to the WG's scope. best, john From nobody Fri Nov 20 15:43:53 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112121B4011 for ; Fri, 20 Nov 2015 15:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX2_z-9X_fG9 for ; Fri, 20 Nov 2015 15:43:50 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A38D1B405E for ; Fri, 20 Nov 2015 15:43:50 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZzvLG-000AkR-08; Fri, 20 Nov 2015 18:43:46 -0500 Date: Fri, 20 Nov 2015 18:43:40 -0500 From: John C Klensin To: "Hakala, Juha E" , urn@ietf.org Message-ID: <137731ACF712EA751660E871@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Tobias Weigel Subject: Re: [urn] Suggested changes to rfc2141bis-14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 23:43:52 -0000 (Note: Editor hat on. I.e., as noted some of the comments below are headed directly to the -15 text unless I hear objections) --On Friday, November 20, 2015 13:08 +0000 "Hakala, Juha E" wrote: > Hello, > > Four minor change requests to the latest URN syntax > specification: > > 1. rfc2141bis-14 states in chapter 3.3.1 that "q-component > SHALL NOT be taken into account when resolving a URN to a > URL". > > There are two problems with this: > > First, a URN can be resolved to 1-n URLs. Or, more accurately, 0-n URLs. I had already picked this up, although I like your reasoning and suggestion better. > Second, depending on what service is being requested, it may > be necessary to resolve a URN to different URLs. For instance, > if a user wants the identified resource, the URL will be the > one belonging to a digital asset management system holding the > document. But if the just descriptive metadata about the > resource is requested, the most appropriate URL may be the one > of the national bibliography. > > I suggest the following modification of 21421bis: > > "As described under Section 4, the q-component SHALL NOT be > taken into account when determining URN equivalence. > > Similarly, the q-component MUST NOT be used to communicate > service related requests and parameters to a resolution > service. I'm a little reluctant to make that a MUST NOT, which is a very strong requirement. It might actually be appropriate when the URN can (and will) be resolved to exactly one URL (and not multiple URLs, selected URLs, or anything else), but, if that was the intended meaning, someone should speak up so I can try to make it a lot more clear. There is also the issue of whether a client "communicates" information to a resolution service that returns values so the client can then do something else versus communicating with a resolution service that retrieves objects (discussed at length a few weeks ago). Especially if we are not going to try to resolve that difference and create a requirement, I'd prefer "SHOULD NOT", perhaps restructuring the sentence to read "Namespaces and associated information placement in syntax SHOULD be designed to avoid any need for a resolution service to consider the q-component. Namespace-specific and more generic resolution systems MUST NOT require that q-component information be passed to them for processing." > A resolution service MAY parse the q-component in order to > determine an appropriate target system to supply the requested > service. " Here I get confused. I have assumed that determining an appropriate [target] system to supply a requested service falls well within the scope of r-components. Can you explain more about what you had in mind? > 2. IMO there is a slight problem with this sentence from > chapter 3.3.: > > "The q-component is intended for parameters to be transmitted > to the named resource and interpreted by that resource." > > It is not always the case that the result of the resolution is > the named resource. A more accurate wording might be the > following: > > The q-component is intended for parameters to be transmitted > to either the named resource or a system that can supply the > requested service, and interpreted by that resource or system. Wfm. Any objections? > 3. In chapter 3.3.3, the draft currently says: > > "When a URN containing an f-component resolves to a URL, the > f-component from the URN is copied verbatim into the fragment > of that URL." > > and a bit later: > > "Similarly, the f-component MUST NOT be passed to resolution > servers when querying them for resource locations or metadata." > > The problem with the former sentence is that the URN does not > always resolve to the URL of the identified resource. If the > result is an information page describing the resource or a > metadata record, adding a fragment does not make sense. And > IMO the latter sentence is meaningless since resolution > servers should a priori ignore f-components no matter what > service is being requested. Of course, web browsers usually do > not send fragments at all to HTTP servers, so at least in the > case of HTTP it would be a bad idea to use f-component in the > resolution process. > > We are better off saying for instance: > > "If a URN containing an f-component resolves to a URL of the > named resource, the f-component from the URN can be applied > (usually by the client) verbatim as the fragment of that URL. Ok. But see the comment below the next paragraph and the separate "metacomment" note. > Clients SHOULD NOT pass f-components to resolution servers. If > a URN containing an f-component is received by a resolution > server, the server SHOULD ignore the f-component when > processing the URN. I know that just about everyone who thinks about this has a particular processing model and even a style of API in mind, but I think we need to be very careful to not build those models into the text unless (i) that is a requirement we want to make and (ii) we have clear consensus about it. We have a convention (not always followed) that one should not say "SHOULD" (or "SHOULD NOT" without at least a general description of the exception case(s). The above could be improved considerably by saying something like "Clients SHOULD NOT pass f-components to resolution servers unless those servers also perform object retrieval and interpretation functions." and then either hope that "when processing the URN" is interpreted very narrowly or put in some further qualifying language. In that context, what do you (and others) think? > 4. A bit later in the same chapter, there is a sentence > > "Thus, for URNs that resolve to URLs, the semantics of an > f-component are defined by the media type of those resources, > not by the namespace." > > A more accurate version: > > "Thus, for URNs that resolve to URLs of the named resources, > the semantics of an f-component are defined by the media type > of those resources, not by the namespace." > > Some URNs may resolve only to e.g. URLs of metadata records > describing the named resources, and in such case f-component > is not applicable. I see where you are going, but... > Of course it might be possible that the > media type of the metadata record would allow use of > f-component / fragment, but in that case the appropriate > f-component can only be applied to the URN of the metadata > record itself. Resolution processes will become increasingly > complex, and there is no way of knowing the media type of the > thing resolution process produces unless it is the named > resource itself. However, I don't think one can tell. We've been thinking about things like (using the -14 r-component syntax): urn:isbn:xxx-yxx-...??something-that-specifies-metadata-not-book but one could equally well have (although I hope we don't) urn:isbn-metadata:xxx-yxx-... Now, it seems to me that, at least if the metadata are returned in a form that has a media type, it would be equally rational to put #author at the end of either of those URN-strings. But I think your language prohibits that for one case and not the other. Or maybe it prohibits the fragment for both. So I think I need more comments on this from you and others before changing text. > Apart from these minor glitches the draft looks fine to me. Encouraging. best, john From nobody Fri Nov 20 16:56:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C3D1B358C for ; Fri, 20 Nov 2015 16:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvVpA7-EhrKR for ; Fri, 20 Nov 2015 16:56:49 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069AC1B358B for ; Fri, 20 Nov 2015 16:56:49 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 96AF9509BF; Fri, 20 Nov 2015 19:56:47 -0500 (EST) To: John C Klensin , urn@ietf.org References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <564FC0E8.9090705@seantek.com> Date: Fri, 20 Nov 2015 16:55:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030700030500040507040207" Archived-At: Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 00:56:51 -0000 This is a cryptographically signed message in MIME format. --------------ms030700030500040507040207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/20/2015 1:54 PM, John C Klensin wrote: > --On Monday, November 16, 2015 13:09 -0800 Sean Leonard > wrote: > >> URNies: >> >> Please find a revision of urnbis-rfc2141bis attached (if these >> attachments get accepted), which you can refer to as the >> "14-seantek" (or "14s") revision. I used the XML >> version posted directly on ietf.org and edited that. I am also >> including the output of rfcdiff. >> >> This is what I want to see added to the draft, based on >> discussions over the last ~4 to 6 months. People (notably the >> chairs) have been asking to "send text" so here is the >> text. >> ... > Sean, > > Partially as an explanation of why you (and the WG) are going to > see two or more responses from me to other notes before I > respond in more detail or with changes to the draft related to > this one, while I really appreciate your good intentions and > willingness to supply text, Ok in that case I will hold off on any further responses until you are=20 finished with your e-mail batch. Thanks. Note however that the "problems trying to be solved" are=20 straightforward, as they are covered in the Key Points. As it stands, urnbis-14 is significantly unimplementable. (I have tried=20 to implement URNs before, and have a lot of experience with implementing = URI handlers and processing URIs in various contexts.) No matter what=20 the WG agrees or disagrees about things like "??" vs "?" or whatever, if = the spec is not implementable, nobody is going to use it (and in=20 particular, use it to build interoperable systems). The overriding goal=20 of this effort, therefore, has been to make the unimplementable parts of = the spec actually implementable. "Implementable" means not only=20 literally that a system can be implemented, but that systems can be=20 implemented to do something actually useful, and can interoperate. Here are the Key Points, with associated Problems: * (informative) resolution-to-resources model discussed, illustrating int= eraction of assigned-name, r-component, q-component, f-component > PROBLEM: people are talking about resolvers and resolution without an i= mplementable model of what is actually going on. Need an implementable mo= del, even if that is not the only model. * fixed the ambiguity between q-component and r-component > PROBLEM: can't see where q-component and r-component begin or end. Not = implementable. * r-component syntax and semantics defined > PROBLEM: Keith Moore, myself, and others (Juha Hakala perhaps 1/2? they= can speak for themselves), want to see the r-component actually **do som= ething**. The term "facet" has been used, along with "profile". An r-comp= onent with no structure or semantics is not implementable (see above). * updated text/uri-list registration > PROBLEM: In an effort to propose an implementable system, the system ne= eds a data model of how URNs turn into "final" resources. RFC 2483 provid= ed such a model. But text/uri-list is old. Some people (Keith Moore etc.)= want attributes. So we could create some new thing, or use our existing = thing and make it better. * fixed and improved ABNF > PROBLEM: Current ABNF too vague and not really implementable, certainly= not in an unambiguous way * a variety of small editorial fixes > PROBLEM: There are editorial problems. A specific list of editorial pro= blems: >> Changes to solve the above problems resulted in text that no longer ma= kes sense. For example: 2. The syntax of URNs assigned within the namespace, including whether q-components, r-components, or f-components are allowed. has been changed to: 2. The syntax of URNs assigned within the namespace, including the anticipated effects of q-components, r-components, and f-components. =2E..that is because: the namespace can't really *prohibit* things like f= -components--the discussion about all that is already in the -14 text. Fo= r example, the namespace may identify certain kinds of things such as "de= spotic leaders in history" that, since whoever is administering the names= pace never intended to resolve to Internet media type content, can't have= fragments and therefore is not expecting f-components for urn:despotic:s= talin. But someone actually implementing the URN can interpret it however= he/she/it wants, including going to some content that has chapters or wh= atever where fragments are meaningful. Another example: Removed "Note that" in "NIDs are case insensitive..." =2E..that is because: It's nice to note things, but it's not a note. Case= -sensitivity (or not) is a bedrock interoperability issue that affects th= e equivalence of urn: URIs. >> Example URNs such as "urn:example:foo-bar-baz-qux#somepart" are terrib= ly uninformative. > =20 > In other places, you've rewritten whole sections Nope. Only subsections. In particular I only reordered q-component and=20 r-component subsections (3.3.1 and 3.3.2). For that matter, the=20 q-component section is 95% the same. Section 8.3 was added (not=20 rewritten) for text/uri-list, but 95% of that is a copy-and-paste job=20 from RFC 2483. I suggest checking the rfcdiff HTML output on that one... > and taken the > document into places, such as with your "rop" model, that the WG > has not, IMO, discussed at all, much less agreed on. Oh, it's been discussed all right. See last 2-6 months of messages...the = syntax has some novelties/proposals, but the premise has been there for=20 awhile. (Actually the reason for any "novelties" is because people were=20 handwavy about implementability, so I needed to propose something that=20 is actually implementable.) The main thing is that the chairs kept on=20 saying, "Send Text, Send Text", so now it's sent. I acknowledge that=20 agreement is not clear: that is the reason why I sent text so that=20 people can see what such implementable systems would look like. Best regards, Sean --------------ms030700030500040507040207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjEwMDU1MDRaMC8GCSqGSIb3DQEJBDEiBCDYpoTlq9f3P+8h79njykcVB1E2h4QQQWQJVONQ 7R1TNDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQABnSMlv4hoEwTJR6MK ILRJKj6uex0bloUvhrtAiVHfh78srPHLwzYOtMU9Z60vjlrnirn7ZaEPRUXHNKFDFu09fAUv +k9zd+8sZQlhvWCWMnEcrNZAWK7MdA21s2phP/YMhXAdYUTLeY+ezGJ1pmLsco0InwV1yTBL hz7jl8ej5sKGey/4ohSULLTrsksJF9NQRfK0Kq8av3/VR2/jrydOHcL7kMCEmVd7876a+ZdA NdCCFLXiI+yMBbfQCh2VvjRLH1pplU4IFPJo8GaHCGyniH/xj9WchsCHqJf59Wzs4FnlaRFk 16aBwq8NsQNxOmppNc+l8nQ1UvxYbvjWss0RAAAAAAAA --------------ms030700030500040507040207-- From nobody Sat Nov 21 01:13:23 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BD71B4195 for ; Sat, 21 Nov 2015 01:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEHeyrDVT4ed for ; Sat, 21 Nov 2015 01:13:14 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824191B4193 for ; Sat, 21 Nov 2015 01:13:14 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a04EK-000C6y-UM for urn@ietf.org; Sat, 21 Nov 2015 04:13:12 -0500 Date: Sat, 21 Nov 2015 04:13:07 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] rfc2141bis-14/-15 metacomment about URN definitions X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 09:13:18 -0000 Hi. After reviewing Sean's and Juha's comments on -14 and thinking about a set of issues that have been bothering me (and, in different ways, I think others) for months, I want to take a half-step back, not about the nature of URNs but about the definition and documentation process. It seems to me that we have a pair of difficult problems. On the one hand, we are trying to define URNs independent of both the properties and capabilities of any particular namespace. We are also trying to define URNs broadly enough that different ones may resolve directly to digital objects, to URLs, to metadata, or not at all. Those "resolutions" may depend on the namespace (see "isbn" versus "isbn-metadata" in my response to Juha as well as the XMPP ones that we've sometimes called indicators). However, even "resolve to object" URN namespaces might be usable as indicators in other contexts so whether or not something resolves (or is always treated by resolving it) may not be a necessary property of a namespace. For example, if a namespace had a strict and predictable assignment rule (consider "urn:ietf:rfc:NNNN" as an example) but an assignment rule within the namespace that resolution is not possible until the RFC is actually published, then "urn:ietf:rfc:9999" is perfectly valid from a syntax standpoint while "urn:ietf:rfc:ABCD" is not. One would probably want a resolver that would somehow be able to report "syntax error in NSS for that sub-namespace" for one of those cases, "syntax valid but no such object", and "here is your object" (or a URL for it) for urn:ietf:rfc:3986 Even more obviously, one reason why it is important to have clear rules for determining equality of URNs involves non-resolution applications. I think we have agreed that, unlike some varieties of URLs, the ultimate arbiter of equality is not to retrieve and compare target objects. Each of us has different ideas about what types and applications of URNs are most important and about how to characterize them. Each of us has a different number of applications we can actually consider and remember at the same time. But, at least IMO, 2141bis must be written to include all of the applications or, at least, to not exclude any by focusing on or assuming others. I think relatively recent comments from Keith, Sean, and Juha (in earliest-first order) show examples in which 2141bis-14 fails at that. And that is the easier of the two difficult clusters of problems we face. When we start talking about what is done with URNs and how -- something we have been characterizing as the "resolver" or "resolution" problem-- we also encounter multiple models. If we were in the business of specifying an API, things would be easier (although consensus perhaps not). However, our job, at least as I understand it, it to specify things in a way that is not biased toward any particular implementation. The difficulty is that, while it is helpful (as Keith and others have pointed out) to think about applications and implementation scenarios, different of us have different scenarios and different ways of thinking about them. Sean's proposed substitute document and its "exemplar implementation" section is very helpful in illustrating the problem -- that example is great for some range of cases and at least one way of thinking about the issue. It appears to me to be inadequate or confusing for others. Maybe example implementation outlines like that are exactly the right way to show how things could work but, if we are going to do it that way, I suggest that we need at least one other (and preferably very different) parallel worked example. Noting that the posted version of -14 is already 33 pages long and that Sean's proposed substitute is 46 pages, that would make for a very long document, perhaps comparable to RFC 3986 if that is a benchmark for "too long for any but the most dedicated people to read". We can continue to try to fix those issues with more qualifying or alternative language (as parts of Juha's recent note suggest), or we can try to incorporate some of the explanation above into introductory material that advices people as to how to read and interpret the spec. Or we can do the latter but keep trying to apply patches along the lines of the former. Advice from the WG would be helpful. best, john From nobody Mon Nov 23 10:34:20 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8A31ACD53 for ; Mon, 23 Nov 2015 10:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB815l1KDtfZ for ; Mon, 23 Nov 2015 10:34:16 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DFD1ACD50 for ; Mon, 23 Nov 2015 10:34:15 -0800 (PST) Received: by wmuu63 with SMTP id u63so66376292wmu.0 for ; Mon, 23 Nov 2015 10:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=peuWt2D+pSll5YppL6VH/8GFwoBcvVBq9vgFENJJFIU=; b=sXygIy1OPgeztCB3x2AUNYz+GITGLqZVpkOpuBkEdwcQn2U5vGX5f2u4r8PvpdnI/P 0mF2MGGP0Qm03PXzmYqMDjYvqeTYmqctjbTia/6gJhEKB9xye1DtknprnFNElugmZlx6 htu6/jhrOT5RSDiActVer8Z4BQsMyq3tUTEdFn5Rq4ZkMNH5pRt+qfse5+8l0zrgd5/r eMW1oD6XxL11YVnemZiawTR8W6Qg/qbfj608uUrsmurCwMAyQAXragjhWYoAyRnwBALD LwlF6znCLQDQ8Fh2gfYurZ33iYdMQLYtPR2GLSLIvXUJskQhaEMSz9NyWHnXaXFeo0UY 3neA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=peuWt2D+pSll5YppL6VH/8GFwoBcvVBq9vgFENJJFIU=; b=SKprrvBVvID7zQxb3c4D9MWDXMez5+T1xTrRaB25j/SeH9tJ3ONEED2fscOmeA1UoO jj0Fe20rgpeH6QxnR+kqfzXd590ER5b+qCRNhgG3Tn0pnnVhIZ0CLyjl2tRVKgSrLUro or0gqNh/8bCMvHUQIMMYWl3BkAcR0tYLWisjtR861TRbAtnajPavUdac518Fi4KgXWXF rbx02PBsK+dgO21lldSmqtWDS32gFFvF9FgwWJPvU9Pvi1NAfexbBPDJaEPwrF6QtFSQ KZ1X00sOGHqQfzJ0CWFZXLbarxrU0toWl55dm/Pj4Psd2k9reapR99DcR0LQiTbhAD7i oxZQ== X-Gm-Message-State: ALoCoQl8694Nqrgfbs0U+ACd/Nq3XgI2104u2vbZzKFiwvNrCn2gMf/EDDMMYbZ75cGtEEF7AHGK MIME-Version: 1.0 X-Received: by 10.28.63.204 with SMTP id m195mr7612361wma.11.1448303654599; Mon, 23 Nov 2015 10:34:14 -0800 (PST) Received: by 10.194.91.203 with HTTP; Mon, 23 Nov 2015 10:34:14 -0800 (PST) X-Originating-IP: [192.149.252.137] In-Reply-To: <564FC0E8.9090705@seantek.com> References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> Date: Mon, 23 Nov 2015 13:34:14 -0500 Message-ID: From: Andrew Newton To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John C Klensin , "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 18:34:18 -0000 On Fri, Nov 20, 2015 at 7:55 PM, Sean Leonard wrote: > As it stands, urnbis-14 is significantly unimplementable. (I have tried to > implement URNs before, and have a lot of experience with implementing URI > handlers and processing URIs in various contexts.) No matter what the WG > agrees or disagrees about things like "??" vs "?" or whatever, if the spec > is not implementable, nobody is going to use it (and in particular, use it > to build interoperable systems). The overriding goal of this effort, > therefore, has been to make the unimplementable parts of the spec actually > implementable. "Implementable" means not only literally that a system can be > implemented, but that systems can be implemented to do something actually > useful, and can interoperate. In your opinion, is 2141 unimplementable as it stands today? Or is 2141bis making URNs unimplementable? Or is it that r-components are simply unimplementable? > Oh, it's been discussed all right. See last 2-6 months of messages...the > syntax has some novelties/proposals, but the premise has been there for > awhile. (Actually the reason for any "novelties" is because people were > handwavy about implementability, so I needed to propose something that is > actually implementable.) The main thing is that the chairs kept on saying, > "Send Text, Send Text", so now it's sent. I acknowledge that agreement is > not clear: that is the reason why I sent text so that people can see what > such implementable systems would look like. And thanks for sending text. I have a few questions. Do you believe your ROP proposal is necessary for 2141bis, or can standardization of ROP wait until later? -andy From nobody Mon Nov 23 23:40:39 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D801E1A0338 for ; Mon, 23 Nov 2015 23:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn9rzesP3FRY for ; Mon, 23 Nov 2015 23:40:36 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0095.outbound.protection.outlook.com [104.47.125.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501F91A0334 for ; Mon, 23 Nov 2015 23:40:35 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0142.jpnprd01.prod.outlook.com (10.161.134.14) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 07:40:31 +0000 To: Sean Leonard , References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56541468.3040103@it.aoyama.ac.jp> Date: Tue, 24 Nov 2015 16:40:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR0201CA0008.apcprd02.prod.outlook.com (25.164.90.146) To TY1PR01MB0142.jpnprd01.prod.outlook.com (25.161.134.14) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0142; 2:faUxJihG6AZXtnM4dEISMyBWtThNviY425vmIYe5srrL6hnTnL6jYmCV4KJIp/6p4oNBQigeCrrsktJ4O/ZMx7UJzMQvWG/UUyFG8WiXaB3D9HsDSMypq9nDxdN6GLVKlWO15ZvQdcKglj1bX6Phbg==; 3:DZKdtb7YlZxXxSyYs7+HzkaGcvtwJPvk8NQxOJR7BCXw+0by2IrEzVYDuzfzOnC3xhYbXHknPqIr7V8LdrIha3gwnhEvQaGenkwiqHudRTvHAKQJJbJ43AVkozqUQx0i; 25:ehrppPcZ/K8ILI1KudUCKEKG4BaYG301EosohFb4pFmKkKt0RBz4x8eOP44zGAAWgjozwICusVorkYpXepT+HXCxyEkl9c+zU64YB8zJrDtrX3o7tkLvcSdAWDi3gZPtB8/xUprmwXnTGy+6HCPC2EvhC8z4by1EXs01FZ5ER6sRAjFbFTVK9KE5pAZovNBs7KEfLz8mxXfygtrgQvCc21XcHavsT8uvHN5d39CCXPUMGV/3onyU67BJg4dEAg1EBWmWx4qhYNoZBg0dbhphUw==; 4:wgL8FSpv7qo+2Nhjs2yKavRLwBUJxBMfQpxnVDTBPRfpKkgc4kjfHwrsve9rDYWk3lANO5ooNf2k64/k7KOQ5cm7ui9s4q3qF2PxF4DA73/9FUsqXzUad2J8x9alqMLKOc8BvFHc/PWtitu9zaAhcaeoPHaapZ2rp4oEyzWHVN8K+Rnj626c1mEiNfff5vlYamOz4AKEhVpcJ6FtzpoiTj4NrlCusboJkUjOWfP1rgQIlUozSIj7t2VcZESlHkol+mTOcDlU3hyoGxbNMkvhT39ya1+TxWR9jlmFmkChqgLySXdoGeWJdovwc8aj8aWc63x6445Fir/brXyPCLrldBBNSnuoo0qO24ZvDhP3FjLJIx9OMAtLTXd9RxJCcnND X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0142; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:TY1PR01MB0142; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0142; X-Forefront-PRVS: 0770F75EA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(479174004)(71364002)(189002)(51414003)(24454002)(288314003)(42186005)(19580395003)(586003)(74482002)(65956001)(106356001)(50986999)(66066001)(47776003)(2950100001)(122386002)(5007970100001)(77096005)(40100003)(65806001)(87976001)(99136001)(15975445007)(6116002)(19580405001)(3846002)(5008740100001)(105586002)(65816999)(5001960100002)(83506001)(64126003)(5004730100002)(107886002)(23676002)(86362001)(97736004)(189998001)(5890100001)(4001350100001)(117636001)(87266999)(81156007)(5001770100001)(101416001)(54356999)(76176999)(50466002)(59896002)(92566002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0142; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQyOzIzOnNOQ3UyRkg3d2FpdEVhbEUzbkdrMCs2Sy9P?= =?utf-8?B?T3lONXhZekRIZ3ZUd1Z1MTdCQXhieUNXMTA4NHBjclAzK0hoYmtOeFpQZ0RI?= =?utf-8?B?cE5Mc3ltZnA3MmF5ZE5oUVBHYjZGMWFKYXg0eUlWNTFGRUdrNHlka3ZOMndI?= =?utf-8?B?UlB3NC9ZTEVId21rREVSMEZYdUZvaDM2R0ZFSEd1aVRLTTQ2MFRrdEdTeFM1?= =?utf-8?B?NGZWQisvaWdzYThCZEJsYU9pVHIrR3NSV0FPYnNWaENNeGhmZWl2T3Zod3dO?= =?utf-8?B?OGRLS0dKb0ROeHFyYmpDdUtNTDUrK0xsY0FHYytPTTVEOVBuN2laMk9BUEJ1?= =?utf-8?B?VmdIdktjb1NRM1VSZFU4dlpEU3FXSkRkcW91WXNHRFFPNHBLTmNZTmhLa3pt?= =?utf-8?B?SFVnUjNNRnZrRmNzd3YrcStoWHd1TVJxT3ZFc0tCUG1yd3VLeUNBVko1dHh2?= =?utf-8?B?dmJNY3VSQjNmUXA0OVVtbVlMUWxKZzZvQXpOdUlIaXZOTDMyOWEwQSsxTzlM?= =?utf-8?B?Q0RxMk42RHRENElBc3VKWG01VVJBbHlzOVlmWC9lS2pyWE9sM0RRakt3Z0tO?= =?utf-8?B?RFRWOUxjY2RFVDJmTTUxNzlVRmswQkpWYzlwK283QjhFa0o5cU5zdHNYSkox?= =?utf-8?B?cVVvcU9Tbm5oQ2tJS05UN0Zyc1cvOVlrcTdYU3dINUs5T25mS0FLMWZhdUFW?= =?utf-8?B?ekx0dm5ienJkbWZzMS9rQ0ZvVVZVY2duNXh6a004d1E1KzFvRjRQT2xXQmFj?= =?utf-8?B?Ym5MK1NsVG1SVWNrWTgvcjdlWVpUaWpybE9xVTN3S2lidnVPbmRaZ3gyVnNv?= =?utf-8?B?OHNOTi9xaTFkOTFTcGNlWTNaNkxvR0dJamlZeHNSa1YrWTdwcmU1TnJVS0lI?= =?utf-8?B?Qk1SMzhIMEdwLzFBT3FRNEE1Mk00RUJxbHRwN2svUnNnUVNMNHFNc2IxM1hI?= =?utf-8?B?NmxLaUZJTC94ekFXamRHWVpSR2hhTEhBMWZZVDk0NzFLMnRmelFUWVg4TFBE?= =?utf-8?B?K1NiZE9hdkk2akxoM0Z5TlpVUURhUVM2SElQK09lNnpXV25ibzJ1VHprdmtK?= =?utf-8?B?anVwdUJHSXB4eU5HNmtaVW9FYXoyWVNxVFVRV3lxSDNpQ0poSEVMOWN1a1Q1?= =?utf-8?B?aDBybWdIUm95S0pVNTJwYzJNLzVOTTBab2lMWXYwcTZ4OHpyVElFVkRhQ0g3?= =?utf-8?B?ZlpKOXh0ZG9adWUrZm9wNUdlb3BTZlRURWVlNzEyS1RCQ3NDYkgycWJhbUtO?= =?utf-8?B?MENwU2pIUjBKd3FpOWtDOWJjY01waE1TWmVzMllrMjJERXNZTDY4SDRhbFVP?= =?utf-8?B?a3JKVG1xakpDM1pBdUxncXkxYzgrQ1BCOFd2OVl1U2JRZUtVTG9sa3ZaalMv?= =?utf-8?B?K3BDZHQ0aWhxbmlOS3dKSVZ5RGxGNUxlZVIzTzhXNXFxcHRLVUFmN1daSkVK?= =?utf-8?B?ekx6dm5aa1owOUoyejBKSHNWWldicW0ya1VnL3JSOVNhM3VNZzBIY05FeXhR?= =?utf-8?B?RyszRURwSVhQb1drZUk0K0JlSnFvSEpFUFhIR2dWNGowMjlwYU4xd254R0U5?= =?utf-8?B?NnFTYlU0VVNOcVlpc21TZWsrOURGL3JrM2NyYmp6WEdxempaVkR6RlZjVmt2?= =?utf-8?B?NkppclFmL3A4UHYvc1BRRUZFeTg4Q3FPajFRVFJxK2VNRlNtUmdhdXNReUt0?= =?utf-8?B?OEcyb2p3Sm0xYnlDR280RmZHUjYzc2tGVWNNWVVOVk12Q01oeTdnZTVCMVdu?= =?utf-8?B?NFFRR2RwRFhUaGlVZnBESmhPcEpoUmU0MURNSHkvSVNsTlZJa1BmRFU0cUhx?= =?utf-8?B?dHE3YlNlODc3RXpYWnlSbHRaUzA4OGdlM1RZUTNVYmMwTXZtVHlvS3BYYk90?= =?utf-8?B?SGZDckxuSUpMNWd4cFNGNEdFcnFjSFUvVkpJK3ZqaTBaZG5xTWt3emI2MEVS?= =?utf-8?B?WjFDVW1LVUN3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0142; 5:ha8pPdvsuwxdQ0hWApsLLv+eiv7gba4YKGcoewVNpnSHRKmAS22pLyzCIfTh7HErhzL0R9Bj5GdOsPMSxH8bPyolF+a/a9sUluRutJ5zW/ton+htE8MTtNoKcynet+q8pgK1Tc29aUBPrFdBWS16LQ==; 24:3k3aS2xkSelp2yy6EpqcMNYBoi3U3DcbXWsw9BkBuYXFM9fP1rLZvQ48f1gA4v+dKNYwWYfyXTTA+JkD1/RaA8k+dR32iPjdmsPquG42nu0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2015 07:40:31.3645 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0142 Archived-At: Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 07:40:38 -0000 Hello Sean, I have not really been following the URN work very closely lately, but I strongly suggest that you follow general IETF practice and submit your modified draft as a real Internet Draft. Regards, Martin. On 2015/11/17 06:09, Sean Leonard wrote: > URNies: > > Please find a revision of urnbis-rfc2141bis attached (if these attachments get accepted), which you can refer to as the “14-seantek†(or “14sâ€) revision. I used the XML version posted directly on ietf.org and edited that. I am also including the output of rfcdiff. > > This is what I want to see added to the draft, based on discussions over the last ~4 to 6 months. People (notably the chairs) have been asking to “send text†so here is the text. > > Key points: > * (informative) resolution-to-resources model discussed, illustrating interaction of assigned-name, r-component, q-component, f-component > * fixed the ambiguity between q-component and r-component > * r-component syntax and semantics defined > * a variety of small editorial fixes > * updated text/uri-list registration > * fixed and improved ABNF > > Please: read the text before commenting on these points. If you don’t like the direction, take it up with the text, and *send different text*. > > Thank you and I look forward to productive discussion. > > Kind regards, > > Sean > > PS If you want to use rfcdiff , use this URL for the text source: > > https://dl.dropboxusercontent.com/content_link/mi4xwZzmQgkdmK94enMHvod9ptoSUPOpnRBgATxa9iYoAWNiB1TBoSZuWYy9NsgR/file > > PPS I also have a brainstorming scratch text file where I put extensive notes on why and how the syntax is derived to be as it is in the 14-seantek draft. If people want to see it I can send it or paste it in. Symbols were carefully chosen to eliminate ambiguity, ease parsing, maximize compatibility, and maintain compatibility with existing APIs. > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Mon Nov 23 23:55:03 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0221A037A for ; Mon, 23 Nov 2015 23:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MANGLED_OFF=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW8wF7Yo3nmH for ; Mon, 23 Nov 2015 23:54:54 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370E21A0378 for ; Mon, 23 Nov 2015 23:54:53 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 07:54:33 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0331.019; Tue, 24 Nov 2015 07:54:33 +0000 From: "Hakala, Juha E" To: John C Klensin , "urn@ietf.org" Thread-Topic: [urn] Suggested changes to rfc2141bis-14 Thread-Index: AdEjkVylORy7rhaTRz2w2Ey3YYKOowAW+vIAAKPT6aA= Date: Tue, 24 Nov 2015 07:54:32 +0000 Message-ID: References: <137731ACF712EA751660E871@JcK-HP8200.jck.com> In-Reply-To: <137731ACF712EA751660E871@JcK-HP8200.jck.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:5gilOLLVI60acIm8r5c5aYw6hxgyD9jzG7xL7aUvjoa+ClBJl5Ui72+njFNpDd2DY4bK2heBJz1+8OkzkNqQ0V4j0ctPQHPkwQXM4X0jKnKBjaYh5lDV8z7hvhZo/0aPMkkXUGqaY1uEhVNnLDVUZA==; 24:X4sJIE3xrzwgTHcZLrep2c/UtvboiILxDj9AGiv9M9UuJZrnLeaCVYdVPfMGQxCRlhW3Uby9dx7onjDvDdDZfAwdUA6HUgFRSsw/ACcTRos= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(279900001)(24454002)(13464003)(189002)(199003)(50986999)(76176999)(54356999)(5007970100001)(74482002)(10400500002)(97736004)(2501003)(189998001)(5003600100002)(6116002)(11100500001)(19625305001)(5001770100001)(122556002)(74316001)(19580405001)(101416001)(102836003)(76576001)(81156007)(33656002)(3846002)(92566002)(5004730100002)(19580395003)(66066001)(40100003)(5002640100001)(586003)(5001960100002)(86362001)(5008740100001)(15975445007)(105586002)(2950100001)(77096005)(106356001)(2900100001)(87936001)(21314002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2015 07:54:32.7409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 Archived-At: Cc: Tobias Weigel Subject: Re: [urn] Suggested changes to rfc2141bis-14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 07:55:01 -0000 Hello John, A few comments and answers below.=20 > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: 21. marraskuuta 2015 1:44 > To: Hakala, Juha E ; urn@ietf.org > Cc: Tobias Weigel > Subject: Re: [urn] Suggested changes to rfc2141bis-14 >=20 > (Note: Editor hat on. I.e., as noted some of the comments below are head= ed > directly to the -15 text unless I hear objections) Good.=20 > --On Friday, November 20, 2015 13:08 +0000 "Hakala, Juha E" > wrote: >=20 > > Hello, > > > > Four minor change requests to the latest URN syntax > > specification: > > > > 1. rfc2141bis-14 states in chapter 3.3.1 that "q-component SHALL NOT > > be taken into account when resolving a URN to a URL". > > > > There are two problems with this: > > > > First, a URN can be resolved to 1-n URLs. >=20 > Or, more accurately, 0-n URLs. I had already picked this up, although I = like > your reasoning and suggestion better. 0-n is fine with me. I was only thinking about URNs that are actionable.=20 >=20 > > Second, depending on what service is being requested, it may be > > necessary to resolve a URN to different URLs. For instance, if a user > > wants the identified resource, the URL will be the one belonging to a > > digital asset management system holding the document. But if the just > > descriptive metadata about the resource is requested, the most > > appropriate URL may be the one of the national bibliography. > > > > I suggest the following modification of 21421bis: > > > > "As described under Section 4, the q-component SHALL NOT be taken into > > account when determining URN equivalence. > > > > Similarly, the q-component MUST NOT be used to communicate service > > related requests and parameters to a resolution service. >=20 > I'm a little reluctant to make that a MUST NOT, which is a very strong > requirement. It might actually be appropriate when the URN can (and will= ) > be resolved to exactly one URL (and not multiple URLs, selected URLs, or > anything else), but, if that was the intended meaning, someone should spe= ak > up so I can try to make it a lot more clear. =20 I'm a little reluctant to make decisions based on an assumption that some U= RN can and will be resolved to one and only one URL. Even if at first there= is just one URL to resolve to, there may eventually be several if the docu= ment is preserved for long term. Documents are copied from institutional re= positories to digital archives, with accompanying metadata.=20 I used MUST NOT to underline the difference between r- and q-components. If= clients are allowed to send service related requests intended to the resol= vers in q-components, then resolvers must check q-components and determine = if they should do something with them (beyond just deciding the correct tar= get system to which the q-component can be sent un-altered). This would com= plicate resolver implementation a lot. =20 > There is also the issue of > whether a client "communicates" information to a resolution service that > returns values so the client can then do something else versus communicat= ing > with a resolution service that retrieves objects (discussed at length a f= ew > weeks ago). > Especially if we are not going to try to resolve that difference and crea= te a > requirement, I'd prefer "SHOULD NOT", perhaps restructuring the sentence = to > read >=20 > "Namespaces and associated information placement in > syntax SHOULD be designed to avoid any need for a > resolution service to consider the q-component. > Namespace-specific and more generic resolution systems > MUST NOT require that q-component information be passed > to them for processing." >=20 > > A resolution service MAY parse the q-component in order to determine > > an appropriate target system to supply the requested service. " >=20 > Here I get confused. I have assumed that determining an appropriate [tar= get] > system to supply a requested service falls > well within the scope of r-components. Can you explain more > about what you had in mind? Let us assume that a user wants descriptive metadata about the identified r= esource. This can be done either with r-component or with q-component, and = both of them may be constructed on the fly by the client the customer is us= ing.=20 If r-component is used, it is obligatory to specify the service and service= related parameters (if any); in this case the service is (in RFC 2483 synt= ax) I2C (URI to URC) and the parameter is the appropriate metadata format. = The client may also specify a target system (server) to which the request s= hould be sent. In plain text a typical URN resolution request could be some= thing like "retrieve from the Library of Congress online catalogue a MARC r= ecord describing the resource with ISBN XXX". It is up to the resolver to m= odify the r-component containing this request into something (such as SRU s= earch URI) that a server in the LoC application can support. Eventually som= e systems may be able to deal with "native" r-components, but at first this= will not be the case. =20 Note that "hard-coding" the target system in the r-component may be risky, = because the preferred target system may no longer exist or it may not be ac= cessible because of a paywall or technical issues. The resolver may be awar= e of 1-n other systems that can supply the requested service, so it must be= able to override the client's preference when necessary. If a client relies on q-component it may construct an SRU query, and pass i= t to the resolver which then sends it unaltered to an appropriate target sy= stem. The target server may be hardcoded in the URN, as in this example: urn:isbn:9789522222725?http://lx2.loc.gov:210/lcdb?version=3D1.1&operation= =3DsearchRetrieve&query=3D"urn:isbn:9789522222725" &startRecord=3D1&maximumRecords=3D1&recordSchema=3Ddc In this case, URN resolution does not provide much added value. Q-component= of the URN is just passed on to the SRU server in the Library of Congress = online catalogue in order to retrieve a Dublin Core record of the identifie= d book. Even in this case the resolver needs to pass the q-component on. Bu= t at least in principle the client could omit the server information and le= ave it to the resolver to use its own preference for SRU protocol. Or, if t= he server address is known to be invalid, the resolver can replace it with = something else. =20 =20 Current URN resolvers are not smart like this; none of them can deal with q= - or r-components yet. This "intelligence" needs to be built into them, and= we must be careful not to impose any artificial limitations to this, like = hardcoded server addresses which cannot be overridden. =20 >=20 >=20 > > 2. IMO there is a slight problem with this sentence from chapter 3.3.: > > > > "The q-component is intended for parameters to be transmitted to the > > named resource and interpreted by that resource." > > > > It is not always the case that the result of the resolution is the > > named resource. A more accurate wording might be the > > following: > > > > The q-component is intended for parameters to be transmitted to either > > the named resource or a system that can supply the requested service, > > and interpreted by that resource or system. >=20 > Wfm. Any objections? >=20 > > 3. In chapter 3.3.3, the draft currently says: > > > > "When a URN containing an f-component resolves to a URL, the > > f-component from the URN is copied verbatim into the fragment of that > > URL." > > > > and a bit later: > > > > "Similarly, the f-component MUST NOT be passed to resolution servers > > when querying them for resource locations or metadata." > > > > The problem with the former sentence is that the URN does not always > > resolve to the URL of the identified resource. If the result is an > > information page describing the resource or a metadata record, adding > > a fragment does not make sense. And IMO the latter sentence is > > meaningless since resolution servers should a priori ignore > > f-components no matter what service is being requested. Of course, web > > browsers usually do not send fragments at all to HTTP servers, so at > > least in the case of HTTP it would be a bad idea to use f-component in > > the resolution process. > > > > We are better off saying for instance: > > > > "If a URN containing an f-component resolves to a URL of the named > > resource, the f-component from the URN can be applied (usually by the > > client) verbatim as the fragment of that URL. >=20 > Ok. But see the comment below the next paragraph and the separate > "metacomment" note. >=20 > > Clients SHOULD NOT pass f-components to resolution servers. If a URN > > containing an f-component is received by a resolution server, the > > server SHOULD ignore the f-component when processing the URN. >=20 > I know that just about everyone who thinks about this has a particular > processing model and even a style of API in mind, but I think we need to = be > very careful to not build those models into the text unless (i) that is a > requirement we want to make and (ii) we have clear consensus about it. W= e > have a convention (not always followed) that one should not say "SHOULD" = (or > "SHOULD NOT" without at least a general description of the > exception case(s). The above could be improved considerably > by saying something like >=20 > "Clients SHOULD NOT pass f-components to resolution > servers unless those servers also perform object > retrieval and interpretation functions." >=20 > and then either hope that "when processing the URN" is interpreted very > narrowly or put in some further qualifying language. In that context, wh= at do > you (and others) think? There may be cases in which fragments have a more important or different ro= le from what RFC 3986 assigned for them. For complex objects such as resear= ch data sets fragments may be essential for retrieving what is needed. But = it is target systems which are aware of this. I don't know if there is no n= eed to extend this kind of knowledge about fragment usage to URN resolvers = as well. But your version of the text is OK, since it allows yet another po= ssibility to make resolvers smarter.=20 >=20 > > 4. A bit later in the same chapter, there is a sentence > > > > "Thus, for URNs that resolve to URLs, the semantics of an f-component > > are defined by the media type of those resources, not by the > > namespace." > > > > A more accurate version: > > > > "Thus, for URNs that resolve to URLs of the named resources, the > > semantics of an f-component are defined by the media type of those > > resources, not by the namespace." > > > > Some URNs may resolve only to e.g. URLs of metadata records describing > > the named resources, and in such case f-component is not applicable. >=20 > I see where you are going, but... >=20 > > Of course it might be possible that the media type of the metadata > > record would allow use of f-component / fragment, but in that case the > > appropriate f-component can only be applied to the URN of the metadata > > record itself. Resolution processes will become increasingly complex, > > and there is no way of knowing the media type of the thing resolution > > process produces unless it is the named resource itself. >=20 > However, I don't think one can tell. We've been thinking about > things like (using the -14 r-component syntax): >=20 >=20 > urn:isbn:xxx-yxx-...??something-that-specifies-metadata-not-book Yes, r-component is an obvious way of doing this. Q-component should be non= -problematic as well, especially if well-known protocols are used.=20 >=20 > but one could equally well have (although I hope we don't) >=20 > urn:isbn-metadata:xxx-yxx-... In practice, this namespace will not get registered, since having ISBN embe= dded in the NID would create confusion. Metadata record identifiers have no= thing to do with ISBNs; they tend to be database internal and if not, NBN m= ay be used. So URNs for metadata records may be something like urn:nbn:xxx= . =20 >=20 > Now, it seems to me that, at least if the metadata are returned in a form= that > has a media type, it would be equally rational to put > #author >=20 > at the end of either of those URN-strings. But I think your language pro= hibits > that for one case and not the other. Or maybe it prohibits the fragment = for > both. Resources and resource metadata tend to have different fragments, or same f= ragment would give different results. It is OK to do this: =20 urn:isbn:xxx#chapter2=20 if the e-book media type supports this. And it is OK to do this (if the met= adata format allows it):=20 urn:nbn:xxx#author to find out who the author of the book is. But usually you cannot use metad= ata related fragments for the resource itself, or resource related fragment= s for metadata, since that would either not make sense at all, or would yie= ld unpredictable results. There are no chapter 2's in metadata records.=20 Meaningful use of fragments is difficult if the user has no idea of what fr= agments are available in the identified resource. So it is possible that fr= agments will usually be applied when people cite publications. This is safe= r than using URL + fragment as long as the identifier is applied to single = manifestation of the resource only.=20 Best regards,=20 Juha >=20 > So I think I need more comments on this from you and others before changi= ng > text. >=20 >=20 > > Apart from these minor glitches the draft looks fine to me. >=20 > Encouraging. >=20 > best, > john >=20 From nobody Tue Nov 24 02:21:56 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1883A1B2F29 for ; Tue, 24 Nov 2015 02:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75sN3MucqGOI for ; Tue, 24 Nov 2015 02:21:53 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FDD1B2F2B for ; Tue, 24 Nov 2015 02:21:53 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8E397509BE; Tue, 24 Nov 2015 05:21:51 -0500 (EST) To: Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> From: Sean Leonard Message-ID: <565439C3.9020604@seantek.com> Date: Tue, 24 Nov 2015 02:19:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080405010802060900020502" Archived-At: Cc: John C Klensin , "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 10:21:55 -0000 This is a cryptographically signed message in MIME format. --------------ms080405010802060900020502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/23/2015 10:34 AM, Andrew Newton wrote: > On Fri, Nov 20, 2015 at 7:55 PM, Sean Leonard wr= ote: >> As it stands, urnbis-14 is significantly unimplementable. (I have trie= d to >> implement URNs before, and have a lot of experience with implementing = URI >> handlers and processing URIs in various contexts.) No matter what the = WG >> agrees or disagrees about things like "??" vs "?" or whatever, if the = spec >> is not implementable, nobody is going to use it (and in particular, us= e it >> to build interoperable systems). The overriding goal of this effort, >> therefore, has been to make the unimplementable parts of the spec actu= ally >> implementable. "Implementable" means not only literally that a system = can be >> implemented, but that systems can be implemented to do something actua= lly >> useful, and can interoperate. > In your opinion, is 2141 unimplementable as it stands today? 2141 is implementable (and many implementations exist) for the purpose=20 that it claims: universal durable identifiers. That do nothing. I.e., "resolution" in 2141 is not specified, so it's not part of the scop= e. > Or is > 2141bis making URNs unimplementable? As of 2141bis-14, the identification part is mostly fine. Stuff like "/" = got included in identification, while "?" and "#" and such got turned=20 into delimiters for other non-identification components, consistent with = RFC 3986. Progress. But the things that ? and # do, are not currently implementable.=20 2141bis-14 is now including "resolving" in its scope, in a way that 2141 = does not. So, we have to say, at a minimum, what the parts are going to d= o. > Or is it that r-components are > simply unimplementable? The WG has come to an agreement that r-components, q-components, and=20 f-components should be (and therefore are) distinct. Progress. But for them to be implementably distinct, we have to say what they do,=20 i.e., how they are different. If you say "ok these are q and r and f but = by the way q and r, you can't really distinguish them, I guess they have = ?? but sometimes ?? might just be part of q or r", that is not=20 implementable. Furthermore, what is the point of distinguishing q and r, = if you throw both q and r at the "Resolver" and have the Resolver look=20 at both of them? No point. May as well smush them back together. To distinguish them, we have to say what they do: specifically, what=20 *conformant implementations* SHALL do when they parse them out. If we=20 can't say what they do then we aren't really saying much of anything at a= ll. Make sense? > >> Oh, it's been discussed all right. See last 2-6 months of messages...t= he >> syntax has some novelties/proposals, but the premise has been there fo= r >> awhile. (Actually the reason for any "novelties" is because people wer= e >> handwavy about implementability, so I needed to propose something that= is >> actually implementable.) The main thing is that the chairs kept on say= ing, >> "Send Text, Send Text", so now it's sent. I acknowledge that agreement= is >> not clear: that is the reason why I sent text so that people can see w= hat >> such implementable systems would look like. > And thanks for sending text. > > I have a few questions. Do you believe your ROP proposal is necessary > for 2141bis, or can standardization of ROP wait until later? Yes, I believe "rop" is necessary. For my part, I do not find q-components to be implementable in -14 or in = -14-seantek. However, people really like the idea of q-components as this part of the = syntax that the resolver doesn't see, but some other component (which I=20 conceptualize as the URI handler on the client side) sees, and manages=20 to smush together with whatever comes back from the resolvers. (In=20 -14-seantek, I refer to this "whatever comes back" as "products of the=20 resolution services", which is handwavy, but gets the job done.) Therefore, I left q-components mostly alone, to "Die Another Day". I=20 mainly care that q-components stay out of r-components. We need to strive for interoperability when defining r-component. That=20 means that two different resolver implementations can look at a URN spec = (the portion in its purview), get the r-component, and do the same thing = with it. Leaving r-component as a blank canvas is not conducive to=20 interoperability. At a minimum, r-component needs to tell what the resolver to *do*. For=20 two implementations to interoperate (or provide interoperable=20 functionality), they both need to look at the r-component string and=20 isolate the part that says to do something, and to interpret that part=20 to do the same thing between the both of them. Hence, resolution operation, or "rop". Not complicated. The rest of the=20 details of "rop" boil down to identifier assignment choices. The other parts of r-component are r-authority and r-params. Some people = called for r-component to have name-value pairs (I believe Keith Moore=20 was a/the chief proponent). So that's r-params. The r-authority=20 production just seemed to flow out of syntax, and the desire to have=20 predictable (and therefore, interoperable) functionality. Best regards, Sean --------------ms080405010802060900020502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjQxMDE5NDdaMC8GCSqGSIb3DQEJBDEiBCBcQiqqO0NvPHclul0W/+tMAvd1EqPoo3aNe+Ae F6CFEjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQDLoR3H9mdhWw6/Uoqp SVKqb8dHQPE3O8f9XaHsQyKSCrdPXL1mqkzY1U2y8K1v5pWHMgjkWELB1s/N4cwQAaIPXDU5 DKfh+eS8wcLnRu/4xoiQIeJcfPrlok1OyvGKBzx4zNrk0iEulHi56fLe6PwMvk1PJyzC7OxL QEoppWtrnFm8F4y4xkrD+ZG1rRcx41l4wI4HwW9/rcScprDRkY0r+9/e2U5XjwtS2zsacx9c Idss70fGhFlsypOB4h3yj0sgE3wfkf72RZXDEjTKgerWPG2mHgAfUlQasoofBFctTZYMs0Cr MKVF/6/bx/phk7mFne3MN96+d973qeVnNArDAAAAAAAA --------------ms080405010802060900020502-- From nobody Tue Nov 24 11:05:11 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D441A87DB for ; Tue, 24 Nov 2015 11:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK8MUTmJPH-3 for ; Tue, 24 Nov 2015 11:05:08 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC6B1A87D1 for ; Tue, 24 Nov 2015 11:05:08 -0800 (PST) Received: by wmvv187 with SMTP id v187so224510355wmv.1 for ; Tue, 24 Nov 2015 11:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x6E05qCnYUC/Cxz84zCIY5F53a9LYy18VIV4F8HS2Q4=; b=gmxAgL1MVvWYLoLj4JEp+UJJKXD0m9WdJWO6KvEuIvKepp4x6c6j0Gui/a309jGVMC eELaGUerkS9CAOOb8AN6GKrQ6p5Dlllvxsc5jUgMbtlutlY1ImXxmfPsowrtHybIFxhH 53Lo1O2Gm430Xbygl8vcO6WjXhMUutEt3P83bFR8AHQycTUtZ6eS9kelmj3SzJoZ72ef +tSbwiBOSfl9tlht89t6wpfO9rvARRqCeOIb8326UDuyOn/uqtzH+M4mi2NGgJCQr3xz zn9xvVSJFDge6lDJw9b/XlC+Rkug9zSqMBC2V08ziaVCsVgNMhPpYeufk8StFnWd+GtQ iPjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x6E05qCnYUC/Cxz84zCIY5F53a9LYy18VIV4F8HS2Q4=; b=ITd8m0W9jkVvZtfq7gU9aPfyZMBNLs+pyQIS4hYtu4M2VXHB7MAnxbWDUVGwjW0rq/ u6IU0dNUANnN0+UKdTUhFsl+i68SJ6xoZf+y7ue/q4qSjCh/zMwi7cyxNbVB3aqTcz4c +Hv8Ngsdl4+V4lAf1hbGJLHYzo/NSynlcCdENfv/43Foik56hyBVgQqMo/664qSzIzeg ymFLaYuqTb7tX22IMY7+J+R1zmz3txhdZw7BXExbr6mGtUtVchxedrIxY9FvdKBS+G0H RYzIU+rWe5onbdaonGvHXdGUckWqMGOn1xEkAYZDpXVLNAXm/tfQ9pAJr+xYpVvD6gEM xRzw== X-Gm-Message-State: ALoCoQnRYdEsaWuAh2NZVqWmLlQM8w4UeEF9VFxCBXgkyrdvXq19c/KtDSA7a1Ep1GbciSXs7yYb MIME-Version: 1.0 X-Received: by 10.194.133.233 with SMTP id pf9mr38259823wjb.71.1448391906841; Tue, 24 Nov 2015 11:05:06 -0800 (PST) Received: by 10.194.91.203 with HTTP; Tue, 24 Nov 2015 11:05:06 -0800 (PST) X-Originating-IP: [192.149.252.137] In-Reply-To: <565439C3.9020604@seantek.com> References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> Date: Tue, 24 Nov 2015 14:05:06 -0500 Message-ID: From: Andrew Newton To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John C Klensin , "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 19:05:10 -0000 On Tue, Nov 24, 2015 at 5:19 AM, Sean Leonard wrote: > > 2141 is implementable (and many implementations exist) for the purpose that > it claims: universal durable identifiers. > > That do nothing. > > I.e., "resolution" in 2141 is not specified, so it's not part of the scope. > >> Or is >> 2141bis making URNs unimplementable? > > > As of 2141bis-14, the identification part is mostly fine. Stuff like "/" got > included in identification, while "?" and "#" and such got turned into > delimiters for other non-identification components, consistent with RFC > 3986. Progress. > > But the things that ? and # do, are not currently implementable. 2141bis-14 > is now including "resolving" in its scope, in a way that 2141 does not. So, > we have to say, at a minimum, what the parts are going to do. This is just my opinion, so feel free to disabuse me of any of it. With regards to resolution, I believe your assessment of 2141 is accurate. Resolution of URNs today requires software to key off of the NID with namespace-specific behavior (though a lot of namespaces will resolve with nearly identical behavior). In other words, there are a lot of things software can do with all URNs, but resolution is not one of them. What I fail to understand is how r-components change that assumption. That is, even with r-components the resolution of a URN requires namespace-specific behavior. And that leads me to this question: why do we need a set of standard r-components for all namespaces if resolution is still a namespace-specific operation? Why can't the r-components be namespace-specific since the resolution is also namespace-specific? -andy From nobody Tue Nov 24 11:24:48 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9373D1A883A for ; Tue, 24 Nov 2015 11:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FroelPuEHU1 for ; Tue, 24 Nov 2015 11:24:42 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52591A8837 for ; Tue, 24 Nov 2015 11:24:41 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a1JCg-000Kkt-SZ; Tue, 24 Nov 2015 14:24:38 -0500 Date: Tue, 24 Nov 2015 14:24:33 -0500 From: John C Klensin To: "Hakala, Juha E" , urn@ietf.org Message-ID: <1C9DCE198CCDA9BBDB85561E@JcK-HP8200.jck.com> In-Reply-To: References: <137731ACF712EA751660E871@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Tobias Weigel Subject: Re: [urn] Suggested changes to rfc2141bis-14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 19:24:46 -0000 --On Tuesday, November 24, 2015 07:54 +0000 "Hakala, Juha E" wrote: > Hello John, > > A few comments and answers below. >... >> > 1. rfc2141bis-14 states in chapter 3.3.1 that "q-component >> > SHALL NOT be taken into account when resolving a URN to a >> > URL". >> > >> > There are two problems with this: >> > >> > First, a URN can be resolved to 1-n URLs. >> >> Or, more accurately, 0-n URLs. I had already picked this up, >> although I like your reasoning and suggestion better. > > 0-n is fine with me. I was only thinking about URNs that are > actionable. And I was thinking about both those you would describe as non-actionable and those actionable ones that return things other than URLs. In any event, text has been adjusted. >> > Second, depending on what service is being requested, it >> > may be necessary to resolve a URN to different URLs. For >> > instance, if a user wants the identified resource, the URL >> > will be the one belonging to a digital asset management >> > system holding the document. But if the just descriptive >> > metadata about the resource is requested, the most >> > appropriate URL may be the one of the national bibliography. >> > >> > I suggest the following modification of 21421bis: >> > >> > "As described under Section 4, the q-component SHALL NOT be >> > taken into account when determining URN equivalence. >> > >> > Similarly, the q-component MUST NOT be used to communicate >> > service related requests and parameters to a resolution >> > service. >> >> I'm a little reluctant to make that a MUST NOT, which is a >> very strong requirement. It might actually be appropriate >> when the URN can (and will) be resolved to exactly one URL >> (and not multiple URLs, selected URLs, or anything else), >> but, if that was the intended meaning, someone should speak >> up so I can try to make it a lot more clear. > I'm a little reluctant to make decisions based on an > assumption that some URN can and will be resolved to one and > only one URL. Even if at first there is just one URL to > resolve to, there may eventually be several if the document is > preserved for long term. Documents are copied from > institutional repositories to digital archives, with > accompanying metadata. I think we may be agreeing but confusing each other with different wordings. Let me try this a different way; if you agree, I'll try to tune the text (I am not proposing what follows as text for 2141bis even if it sounds like it might be used that way... unless people believe that including it would provide significant and useful clarification): The "value" of a URN, also known as its result or the result of "resolving" it, may be: (1) Nothing at all, if the whole namespace or some NSS value within the namespace is intended as a pure identifier (also known as a URN that is not actionable), i.e., to be compared for equality only, not "resolved". (2) A single URL, identifying or pointing to a single instance of a function or retrievable object. An r-component might be used as a selector for that instance, e.g., to specify the difference between URLs identifying a data object and metadata. (3) One of a family of possible URLs. Each member of the family identifies or points to an instance of function or retrievable object. Each of those functions or objects are considered equivalent to all the others, using namespace-specific rules. Note that equivalence among objects or functions has nothing to do with whether two URNs are equivalent. The selection model for which URL from a family is chosen is far outside the scope of 2141bis but might include network distance, possible speed of retrieval, cost, or criteria specified as part of an r-component. (4) More than one URL, with each one being treated a member of the same family and hence equivalent to each of the others, as above. The difference between this case and (3) is that, in (3), the URN resolution or mapping mechanism determines which URL will be most appropriate for the user/client while, for this case, the determination is at least partially made by the client after receiving multiple URLs. As with (3), r-components and other information might be used to narrow the range of URLs that are returned. In some case, (3) is just a special case of this one in which exactly one URL is returned rather than one or more. (5) More than one URL, with the collection identifying the elements of a multi-part object, function, or a combination of objects and functions. "Multi-part" is a function of the namespace and objects in it and might include a file and separated metadata. Any of the URLs might either be unique to the URN (as in (2) or members of a family (as in (3)). An r-component might be used to select the elements for which URLs were desired as well as specifying URL criteria for a given element as in (3) or (4). (6) Either objects or identifier-like locators that are not URLs. Nothing I can find in 2141 or WG conclusions about 2141bis requires that URLs are the only possible actionable results of URNs. These objects or locators are otherwise similar to URL values in the categories above. r-components might be used to specify whether a URL or an object is returned as well as providing selection criteria for particular objects or functions within an equivalence set or determine which sets of objects are to be returned. Now, if we can agree that all of those uses of URNs are appropriate, then we have a basis for both fine-tuning 2141bis and evaluating standardized resolver specifications. If we can reach consensus that some of them are not appropriate uses of URNs, that moves us forward as well, but I continue to think that different of us are assuming some, but not other, cases and that is causing confusion about, e.g., "1 or more URLs", which could refer to any of cases (2) - (5). I _think_, but am not at all sure, that the case list above also provides a complete list of cases in which r-components are useable and appropriate. Anything else is presumably applied after the URN is mapped into something else according to one of those categories and is hence a q-component or f-component. Note also that Case (5) presents a challenge for f-components because it isn't clear from 3986 whether the f-component belongs to the first URL that is returned, each of the URLs in the set, or something else. For Cases (2) and (3), the answer is presumably obvious and, for Case (4), it would presumably be applied to all of them. > I used MUST NOT to underline the difference between r- and > q-components. If clients are allowed to send service related > requests intended to the resolvers in q-components, then > resolvers must check q-components and determine if they should > do something with them (beyond just deciding the correct > target system to which the q-component can be sent > un-altered). This would complicate resolver implementation a > lot. Indeed. But, because of the list of the cases above, I don't think the text you had adequately makes the distinction for all of them, or probably anything other than cases (2) and (3). >... >> > A resolution service MAY parse the q-component in order to >> > determine an appropriate target system to supply the >> > requested service. " >> >> Here I get confused. I have assumed that determining an >> appropriate [target] system to supply a requested service >> falls >> well within the scope of r-components. Can you explain more >> about what you had in mind? > > Let us assume that a user wants descriptive metadata about the > identified resource. This can be done either with r-component > or with q-component, and both of them may be constructed on > the fly by the client the customer is using. > > If r-component is used, it is obligatory to specify the > service and service related parameters (if any); I think that is true unless the service is intrinsic to the namespace definition. Do you agree or do you think it always needs to be explicit in the r-component? > in this case > the service is (in RFC 2483 syntax) I2C (URI to URC) and the > parameter is the appropriate metadata format. The client may > also specify a target system (server) to which the request > should be sent. In plain text a typical URN resolution request > could be something like "retrieve from the Library of Congress > online catalogue a MARC record describing the resource with > ISBN XXX". Just to be sure we are talking about the same thing, in terms of my case breakdown above, you are proposing to use the r-component to identify both the criteria for selection of a URL from a family (Case (3) for "Library of Congress online catalogue") and the particular URL (Case (2) for "the URL for the particular data or metadata to be returned", in this case the MARC record. Wfm, but I sense a slippery slope in which the Case (2) r-component element might not be compatible with different values for the retrieval location or system associated with Case (3). > It is up to the resolver to modify the r-component > containing this request into something (such as SRU search > URI) that a server in the LoC application can support. Yes, and this is an important point about the URN -> URL mapping not being a purely mechanical operation that can be carried out in the same way by every resolver and/or client. > Eventually some systems may be able to deal with "native" > r-components, but at first this will not be the case. > > Note that "hard-coding" the target system in the r-component > may be risky, because the preferred target system may no > longer exist or it may not be accessible because of a paywall > or technical issues. The resolver may be aware of 1-n other > systems that can supply the requested service, so it must be > able to override the client's preference when necessary. I'd hope that (even the idea of overrides) could be per-namespace because it seems to me that the alternative takes us back to a universal resolver-finder. Otherwise, if nothing else, we'd be creating a huge security hole, equivalent to the "right" of DNS servers to rewrite queries or responses to their convenience -- a right DNSSEC is intended to eliminate. > If a client relies on q-component it may construct an SRU > query, and pass it to the resolver which then sends it > unaltered to an appropriate target system. The target server > may be hardcoded in the URN, as in this example: > > urn:isbn:9789522222725?http://lx2.loc.gov:210/lcdb?version=1.1 > &operation=searchRetrieve&query="urn:isbn:9789522222725" > &startRecord=1&maximumRecords=1&recordSchema=dc > > In this case, URN resolution does not provide much added > value. Q-component of the URN is just passed on to the SRU > server in the Library of Congress online catalogue in order to > retrieve a Dublin Core record of the identified book. Even in > this case the resolver needs to pass the q-component on. But > at least in principle the client could omit the server > information and leave it to the resolver to use its own > preference for SRU protocol. Or, if the server address is > known to be invalid, the resolver can replace it with > something else. Yes. But it seems to me that your two examples could be used to prove that the distinction between the appropriate uses for q-components and r-components is not nearly as clear as we have been assuming or pretending. > Current URN resolvers are not smart like this; none of them > can deal with q- or r-components yet. This "intelligence" > needs to be built into them, and we must be careful not to > impose any artificial limitations to this, like hardcoded > server addresses which cannot be overridden. I think a distinction is important between what the standard requires and what some namespace might choose to allow. For the standard to require "hardcoded server addresses which cannot be overridden" would clearly be a disaster. However, I can imagine namespaces that are sufficiently tied to one set of servers that, while the URNs for that namespace are persistent, inability to access that server makes that namespace useless for anything but identifier purposes. I wouldn't want to encourage such cases, but I think it would be dangerous to forbid them. >... >> > 3. In chapter 3.3.3, the draft currently says: >> > >> > "When a URN containing an f-component resolves to a URL, the >> > f-component from the URN is copied verbatim into the >> > fragment of that URL." >> > >> > and a bit later: >> > >> > "Similarly, the f-component MUST NOT be passed to >> > resolution servers when querying them for resource >> > locations or metadata." >> > >> > The problem with the former sentence is that the URN does >> > not always resolve to the URL of the identified resource. >> > If the result is an information page describing the >> > resource or a metadata record, adding a fragment does not >> > make sense. And IMO the latter sentence is meaningless >> > since resolution servers should a priori ignore >> > f-components no matter what service is being requested. Of >> > course, web browsers usually do not send fragments at all >> > to HTTP servers, so at least in the case of HTTP it would >> > be a bad idea to use f-component in the resolution process. >> > >> > We are better off saying for instance: >> > >> > "If a URN containing an f-component resolves to a URL of >> > the named resource, the f-component from the URN can be >> > applied (usually by the client) verbatim as the fragment of >> > that URL. >> >> Ok. But see the comment below the next paragraph and the >> separate "metacomment" note. And the comment about fragments and Case (5) above. >> > Clients SHOULD NOT pass f-components to resolution servers. >> > If a URN containing an f-component is received by a >> > resolution server, the server SHOULD ignore the f-component >> > when processing the URN. >> >> I know that just about everyone who thinks about this has a >> particular processing model and even a style of API in mind, >> but I think we need to be very careful to not build those >> models into the text unless (i) that is a requirement we want >> to make and (ii) we have clear consensus about it. We have a >> convention (not always followed) that one should not say >> "SHOULD" (or "SHOULD NOT" without at least a general >> description of the exception case(s). The above could be >> improved considerably by saying something like >> >> "Clients SHOULD NOT pass f-components to resolution >> servers unless those servers also perform object >> retrieval and interpretation functions." >> >> and then either hope that "when processing the URN" is >> interpreted very narrowly or put in some further qualifying >> language. In that context, what do you (and others) think? > > There may be cases in which fragments have a more important or > different role from what RFC 3986 assigned for them. For > complex objects such as research data sets fragments may be > essential for retrieving what is needed. But it is target > systems which are aware of this. I don't know if there is no > need to extend this kind of knowledge about fragment usage to > URN resolvers as well. But your version of the text is OK, > since it allows yet another possibility to make resolvers > smarter. Good. FWIW, we have been beaten up very thoroughly about roles for fragments that are different from the RFC 3986 discussions. But, if we can move on without opening that issue up again, I think we should do so. >... >> but one could equally well have (although I hope we don't) >> >> urn:isbn-metadata:xxx-yxx-... > > In practice, this namespace will not get registered, since > having ISBN embedded in the NID would create confusion. > Metadata record identifiers have nothing to do with ISBNs; > they tend to be database internal and if not, NBN may be used. > So URNs for metadata records may be something like > urn:nbn:xxx. You hope it won't be registered. I hope it won't be registered (and agree with your reasoning). But the new registration procedure does nothing to prevent that if someone is determined to do so, no matter how misguided we think they are. >> Now, it seems to me that, at least if the metadata are >> returned in a form that has a media type, it would be equally >> rational to put >> # author >> >> at the end of either of those URN-strings. But I think your >> language prohibits that for one case and not the other. Or >> maybe it prohibits the fragment for both. > > Resources and resource metadata tend to have different > fragments, or same fragment would give different results. It > is OK to do this: > > urn:isbn:xxx#chapter2 > > if the e-book media type supports this. And it is OK to do > this (if the metadata format allows it): > > urn:nbn:xxx#author > > to find out who the author of the book is. But usually you > cannot use metadata related fragments for the resource itself, > or resource related fragments for metadata, since that would > either not make sense at all, or would yield unpredictable > results. There are no chapter 2's in metadata records. Understood. I think that there are two other examples (both odd cases) related to your examples above. First, if "xxx" is a compendium of some sort, then there might easily be separate metadata for each chapter. In that case the metadata for such a compendium might well be organized by chapter and either of the examples above (and, shudder, urn:nbn:xxx#Chapter2#author ) might all make perfectly good sense. I think the implication of this is that some fragments are going to be nonsense when applied to particular objects, even when those fragments are attached to / part of ordinary HTTP URLs. URNs might make that situation a little bit worse, but, IMO, no much. > Meaningful use of fragments is difficult if the user has no > idea of what fragments are available in the identified > resource. So it is possible that fragments will usually be > applied when people cite publications. This is safer than > using URL + fragment as long as the identifier is applied to > single manifestation of the resource only. Absolutely. But, again, not something I think we can restrict in 2141bis. best regards, john From nobody Tue Nov 24 12:26:16 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F241A896A for ; Tue, 24 Nov 2015 12:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEfMXphVScnk for ; Tue, 24 Nov 2015 12:26:12 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759B11A8972 for ; Tue, 24 Nov 2015 12:26:12 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a1KAD-000KtX-O4; Tue, 24 Nov 2015 15:26:09 -0500 Date: Tue, 24 Nov 2015 15:26:04 -0500 From: John C Klensin To: Sean Leonard , Andrew Newton Message-ID: <8AFFBCF5137C419306BCE006@JcK-HP8200.jck.com> In-Reply-To: <565439C3.9020604@seantek.com> References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 20:26:15 -0000 Sean, There are parts of this that I think I can respond to, more as a long-time participant in this effort than as co-editor. Other parts go more to WG operation and strategy; for those I need to defer to Andy. --On Tuesday, November 24, 2015 02:19 -0800 Sean Leonard wrote: > On 11/23/2015 10:34 AM, Andrew Newton wrote: >> On Fri, Nov 20, 2015 at 7:55 PM, Sean Leonard >> wrote: >>> As it stands, urnbis-14 is significantly unimplementable. (I >>> have tried to implement URNs before, and have a lot of >>> experience with implementing URI handlers and processing >>> URIs in various contexts.) No matter what the WG agrees or >... >> In your opinion, is 2141 unimplementable as it stands today? > > 2141 is implementable (and many implementations exist) for the > purpose that it claims: universal durable identifiers. > > That do nothing. > > I.e., "resolution" in 2141 is not specified, so it's not part > of the scope. But we have been trying very hard to not define "resolution" in 2141bis. To the extent to which we have been doing so, it is because attempts to define q-components and r-components (and maybe f-components) to everyone's satisfaction have ended up with statements about "resolvers" and "resolution functions". I'd like to think that is a difficulty with the way we have been constructing those definitions rather than trying to define resolution in a way that doesn't work. Suggestions welcome (but see below). >> Or is >> 2141bis making URNs unimplementable? > > As of 2141bis-14, the identification part is mostly fine. > Stuff like "/" got included in identification, while "?" and > "#" and such got turned into delimiters for other > non-identification components, consistent with RFC 3986. > Progress. > But the things that ? and # do, are not currently > implementable. 2141bis-14 is now including "resolving" in its > scope, in a way that 2141 does not. So, we have to say, at a > minimum, what the parts are going to do. Let me try to recast that a little differently and see if you (and others) can agree. Especially if q-components, like f-components, are to be treated as opaque strings, we need to specify what happens to them and/or where they go in the cases (NID-denoted namespaces) where they are relevant at all. That is, btw, consistent with RFC 3986, which makes general comments about what fragments and queries are and might be used for, but carefully avoids specifying internal syntax or semantics for either, much less "what they are going to do". IMO, this gets tied up with the fundamental nature of URLs and URNs. For URLs for most schemes, we've got a piece of syntax that is, more or less: Scheme:xxxxx?query-string@fragment-string The scheme and hier-part imply, for many schemes, some sort of object-finder and the information needed to find it. The query-string qualifies that operation, supplying additional information about what is to be found or returned (3986, as I read it, says less than that), and the fragment is applied to/ into the object itself. Three abstraction layers with a slightly-fuzzy boundary between the first two. Now URNs, at least the subset of URNs that yield a URL (see the case list in my recent response to Juha), add an extra layer to that model. For that extra layer, r-components have, in principle, exactly the same relationship to the URN-> URL process that queries have to the URL-> object process. We have been struggling to define that boundary better for a variety of reasons and have talked about "resolvers" in the process, but I'm not yet convinced that, in order to have URNs "work", we need to deeply define either resolver functions or r-component semantics... any more than 3986 defines query semantics. >> Or is it that r-components are >> simply unimplementable? > > The WG has come to an agreement that r-components, > q-components, and f-components should be (and therefore are) > distinct. Progress. > > But for them to be implementably distinct, we have to say what > they do, i.e., how they are different. If you say "ok these > are q and r and f but by the way q and r, you can't really > distinguish them, I guess they have ?? but sometimes ?? might > just be part of q or r", that is not implementable. Other than the issue of where they are applied and to what, how is that different from http://some-domain?chapter=5 versus http://some-domain#chapter5 > Furthermore, what is the point of distinguishing q and r, if > you throw both q and r at the "Resolver" and have the Resolver > look at both of them? No point. May as well smush them back > together. I agree with that, actually. But suppose you say to the "resolver": "Here is this r-component stuff and it is information for you to do with as you find appropriate (appropriateness possibly even depending on NID); here is this q-component stuff which you need to either treat as opaque and pass to something else or need to perform some well-described and only scheme-dependent lexical operations on and then pass the result to something else (note the resemblance between the latter and IRI processing)? " In that same vocabulary, f-component becomes a string that is completely opaque with not even that possible lexical transformation. > To distinguish them, we have to say what they do: > specifically, what *conformant implementations* SHALL do when > they parse them out. If we can't say what they do then we > aren't really saying much of anything at all. > > Make sense? Yes, but, again, I'm not sure that what we have been trying to do with them and specify about them is any different from what 3986 says about queries and fragments. I don't happen to think that is really implementable either, but it sets the norms and boundaries in which we need to operate. >>> Oh, it's been discussed all right. See last 2-6 months of >>> messages... I apologize but, while I saw a lot of comments, I didn't understand that you were suggesting a typology and protocol framework for what I've been describing as a universal resolver (or structured family of them). There is a lot about your suggestions that I like and the specifics were a huge help in the regard. But I'm resisting getting it into the critical path of this WG if only because of the purely pragmatic concern that requiring agreement on it in order to move 2141bis forward will doom both. That, however, falls into Andy's territory. >>> the syntax has some novelties/proposals, but the >>> premise has been there for awhile. (Actually the reason for >>> any "novelties" is because people were handwavy about >>> implementability, so I needed to propose something that is >>> actually implementable.) The main thing is that the chairs >>> kept on saying, "Send Text, Send Text", so now it's sent. I >>> acknowledge that agreement is not clear: that is the reason >>> why I sent text so that people can see what such >>> implementable systems would look like. >> And thanks for sending text. My thanks too, in case that hasn't been clear. >> I have a few questions. Do you believe your ROP proposal is >> necessary for 2141bis, or can standardization of ROP wait >> until later? > Yes, I believe "rop" is necessary. > > For my part, I do not find q-components to be implementable in > -14 or in -14-seantek. > > However, people really like the idea of q-components as this > part of the syntax that the resolver doesn't see, but some > other component (which I conceptualize as the URI handler on > the client side) sees, and manages to smush together with > whatever comes back from the resolvers. (In -14-seantek, I > refer to this "whatever comes back" as "products of the > resolution services", which is handwavy, but gets the job > done.) It does indeed, if we need to go down the path to defining a "resolution service" and it actions. FWIW, I think DDDS is more or a "resolution service finder" than a "resolution service", so it would be interesting to see how DDDS and ROP would mesh. > Therefore, I left q-components mostly alone, to "Die Another > Day". I mainly care that q-components stay out of r-components. I think we agree about that too. But see Juha's most recent note and my response. It may be _very_ hard to establish a universal boundary that works for all URNs without constraining URNs and their applications more than the WG has so far been willing to do. > We need to strive for interoperability when defining > r-component. That means that two different resolver > implementations can look at a URN spec (the portion in its > purview), get the r-component, and do the same thing with it. > Leaving r-component as a blank canvas is not conducive to > interoperability. I can perhaps agree... but that gets me back to both the critical path issue and to the definitions of queries (and fragments) in 3986. What is specified is where they are interpreted, not what they do, much less a requirement that they be interpreted in the same way for different resources. > At a minimum, r-component needs to tell what the resolver to > *do*. For two implementations to interoperate (or provide > interoperable functionality), they both need to look at the > r-component string and isolate the part that says to do > something, and to interpret that part to do the same thing > between the both of them. I think that is true iff one requires that it be possible to apply multiple, independently-developed, resolvers to the same namespace and expect to get the same result. That was not a requirement of 2141; if we have made it a requirement in 2141bis, I suggest that was a writing/editing error. > Hence, resolution operation, or "rop". Not complicated. The > rest of the details of "rop" boil down to identifier > assignment choices. > > The other parts of r-component are r-authority and r-params. > Some people called for r-component to have name-value pairs (I > believe Keith Moore was a/the chief proponent). I think I'm at least as much to blame as Keith is, but it was clear to me that the WG didn't like the idea, so I gave up. > So that's > r-params. The r-authority production just seemed to flow out > of syntax, and the desire to have predictable (and therefore, > interoperable) functionality. When you characterize ROP that way (I think there is more to it and I'm pleased about that) a different option (with some handwaving about quoting cnoventions) would be to define r-component = URI since a URI also involves a choice of identifier, an authority, and a set of things that can be thought of as parameters. The difficulty, as Juha pointed out in a slightly different context, is that specifying all of that information in or with a URN is bad for long-term stability (and maybe "persistence"). best, john From nobody Tue Nov 24 12:29:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C01A8974 for ; Tue, 24 Nov 2015 12:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq98NRqBz9qE for ; Tue, 24 Nov 2015 12:29:27 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9014C1A8977 for ; Tue, 24 Nov 2015 12:29:27 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a1KDO-000Ktm-00; Tue, 24 Nov 2015 15:29:26 -0500 Date: Tue, 24 Nov 2015 15:29:20 -0500 From: John C Klensin To: Andrew Newton , Sean Leonard Message-ID: In-Reply-To: References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 20:29:29 -0000 Andy (and Sean and WG), I wrote most of my note about this before this arrived and finished and sent it before seeing this. FWIW, I agree with Andy's analysis and conclusion even though, as my note should make clear, I come at the question from a somewhat different perspective. john --On Tuesday, November 24, 2015 14:05 -0500 Andrew Newton wrote: > On Tue, Nov 24, 2015 at 5:19 AM, Sean Leonard > wrote: >> >> 2141 is implementable (and many implementations exist) for >> the purpose that it claims: universal durable identifiers. >> >> That do nothing. >> >> I.e., "resolution" in 2141 is not specified, so it's not part >> of the scope. >> >>> Or is >>> 2141bis making URNs unimplementable? >> >> >> As of 2141bis-14, the identification part is mostly fine. >> Stuff like "/" got included in identification, while "?" and >> "#" and such got turned into delimiters for other >> non-identification components, consistent with RFC 3986. >> Progress. >> >> But the things that ? and # do, are not currently >> implementable. 2141bis-14 is now including "resolving" in its >> scope, in a way that 2141 does not. So, we have to say, at a >> minimum, what the parts are going to do. > > This is just my opinion, so feel free to disabuse me of any of > it. With regards to resolution, I believe your assessment of > 2141 is accurate. Resolution of URNs today requires software > to key off of the NID with namespace-specific behavior (though > a lot of namespaces will resolve with nearly identical > behavior). In other words, there are a lot of things software > can do with all URNs, but resolution is not one of them. > > What I fail to understand is how r-components change that > assumption. That is, even with r-components the resolution of > a URN requires namespace-specific behavior. And that leads me > to this question: why do we need a set of standard > r-components for all namespaces if resolution is still a > namespace-specific operation? Why can't the r-components be > namespace-specific since the resolution is also > namespace-specific? > > -andy From nobody Wed Nov 25 00:52:15 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127F01B2B0A for ; Wed, 25 Nov 2015 00:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-hRbki3UFuQ for ; Wed, 25 Nov 2015 00:52:06 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687B21B2B08 for ; Wed, 25 Nov 2015 00:52:05 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 08:51:59 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0331.019; Wed, 25 Nov 2015 08:51:59 +0000 From: "Hakala, Juha E" To: Andrew Newton , Sean Leonard Thread-Topic: [urn] urnbis 14-seantek text (incorporates discussions) Thread-Index: AQHRILNrHVLDo3jGhESGPpKOxqC3t56leoeAgAAylQCABEyYAIABCC+AgACSxQCAANrmEA== Date: Wed, 25 Nov 2015 08:51:59 +0000 Message-ID: References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 5:C07fn7QkDiqH2vfbBhmKyd8OStwmxo2fsd6AI+qu2bVyttEI3jlSuG0DGKEmwDVAsiEm0pJHMOPYZlSYlQcaW7PBYH/V7x1NipEmiQwLK2XymnXIzbL/TKVKOL1qPQMCJOUWpLqVPJ4YLjnI9TJ1DQ==; 24:xk7JwO25Legucq4ckxXrj/FCiZcuQFspiDkw/isR66jL5lekdNRVTuZjQnceCSxMhQqgLzf2UKDzqZRLhd9YRRiEjK+8EpkMOSILu+gr2pE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(57704003)(199003)(2900100001)(5007970100001)(5001770100001)(81156007)(101416001)(76576001)(76176999)(122556002)(19580395003)(86362001)(10400500002)(97736004)(586003)(54356999)(5001960100002)(74482002)(33656002)(6116002)(189998001)(19580405001)(102836003)(40100003)(87936001)(106116001)(5003600100002)(11100500001)(3846002)(74316001)(5002640100001)(2950100001)(15975445007)(106356001)(105586002)(66066001)(5004730100002)(93886004)(92566002)(50986999)(5008740100001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 08:51:59.4064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 Archived-At: Cc: John C Klensin , "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 08:52:14 -0000 Hello Andy,=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Andrew Newton > Sent: 24. marraskuuta 2015 21:05 > Resolution of URNs today requires software to key off of the NID with > namespace-specific behavior (though a lot of namespaces will resolve with > nearly identical behavior). In other words, there are a lot of things sof= tware > can do with all URNs, but resolution is not one of them. >=20 > What I fail to understand is how r-components change that assumption. > That is, even with r-components the resolution of a URN requires namespac= e- > specific behavior. And that leads me to this question: why do we need a s= et of > standard r-components for all namespaces if resolution is still a namespa= ce- > specific operation? Why can't the r-components be namespace-specific sinc= e > the resolution is also namespace-specific? If resolution (and services provided via resolution) were entirely namespac= e specific, applicability of RFC 2483 would have been very limited. =20 Sure, each namespace may have 1-n resolution services which are - at least = in the beginning - only supported by that namespace. But other namespaces m= ay develop support for those services later. And there are generic services= which may / will be supported in many if not most namespaces. Some of them= are included in RFC 2483, including retrieval of the identified resource; = retrieval of 1 or many URLs related to the resource, and retrieval of (desc= riptive and other kind of) metadata about the resource (admittedly RFC 2483= specifies this service in a way which is not really useful, since it is vi= tally important to specify the metadata format used). Since URNs are used i= n different technical environments the actual implementation of these gener= ic services may vary (retrieval of resource metadata means different things= for librarians and archivists), but different namespaces could still share= the same r-component syntax to request these services from resolvers. For = instance, a librarian might ask for metadata about the identified resource = and specify in a parameter that Dublin Core metadata record syntax is prefe= rred. An archivist could do the same, except that his preference would be E= AD record syntax. A NASA engineer would probably prefer yet another record = syntax, and so on. The service would still be the same, although details di= ffer. And whatever protocol is then used to retrieve metadata from the libr= ary / archive information system is not relevant for URNBIS / URN syntax; m= apping from URN + r-component to the URI(s) needed for supplying the servic= e is something the resolver developers will cope with. =20 URN implementers have already built resolvers which deal with multiple name= spaces (ISBN and NBN, for instance). There are also resolver networks in wh= ich resolution related data is harvested from participating systems to "uni= on resolvers". This kind of co-operation becomes more complicated than it n= eeds to be if each namespace has its own guidelines for constructing r-comp= onents. From technical point of view, co-ordination of r-component syntax a= nd semantics is both desirable and possible. But it is not necessary to spe= cify r-component in details in 2141bis; that can be done later. Or, more pr= ecisely, we need an RFC or other standard document which specifies how to m= aintain information (syntax, semantics and if needed, pragmatics) about URN= / persistent identifier resolution services. As long as applications with = which digital resources are managed are developing fast, also the resolutio= n services available (and their features) will change constantly, and the U= RN / PID community needs something more flexible than rfc2141bis or a mere = facelift of RFC 2483 to keep up.=20 Best regards, Juha =20 >=20 > -andy >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Nov 25 04:54:10 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479461A1F70 for ; Wed, 25 Nov 2015 04:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz6v5xjg0AmE for ; Wed, 25 Nov 2015 04:54:02 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0DB1A1B85 for ; Wed, 25 Nov 2015 04:54:01 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 12:53:44 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0331.019; Wed, 25 Nov 2015 12:53:44 +0000 From: "Hakala, Juha E" To: John C Klensin , "urn@ietf.org" Thread-Topic: [urn] Suggested changes to rfc2141bis-14 Thread-Index: AdEjkVylORy7rhaTRz2w2Ey3YYKOowAW+vIAAKPT6aAAHEnSgAAfslMw Date: Wed, 25 Nov 2015 12:53:43 +0000 Message-ID: References: <137731ACF712EA751660E871@JcK-HP8200.jck.com> <1C9DCE198CCDA9BBDB85561E@JcK-HP8200.jck.com> In-Reply-To: <1C9DCE198CCDA9BBDB85561E@JcK-HP8200.jck.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 5:X2MYPARv+MlY19sfm1VWTBqDq+zDJ9+w9EjkTgu/4qmSd1lkMC40ZjRa6fnB+EdQiLypiyG7Y59Qdbvxh23zhoH+NQK8soj66eRUMVqxAehtWp9UU6pMq9KyNehI55jyN057BbYcdpWRiBlFuOc3Rg==; 24:m3iCOaqfBiluOtzXUBgZTGHVoXDCEYncAh2hsPIdiXchw9fkskaZ7xmoGtvd30n4b+4llE0dYmfLemFeAQ98J6CP94xPbLJdrTCFbvdzg4I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(43544003)(199003)(189002)(13464003)(93886004)(101416001)(122556002)(2501003)(86362001)(105586002)(74482002)(189998001)(40100003)(33656002)(19580405001)(76576001)(76176999)(5890100001)(81156007)(97736004)(106356001)(50986999)(5003600100002)(5001960100002)(74316001)(10400500002)(66066001)(586003)(5008740100001)(5001770100001)(6116002)(19580395003)(11100500001)(87936001)(5004730100002)(54356999)(15975445007)(5007970100001)(2950100001)(92566002)(2900100001)(77096005)(5002640100001)(102836003)(3846002)(21314002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 12:53:43.9608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 Archived-At: Cc: Tobias Weigel Subject: Re: [urn] Suggested changes to rfc2141bis-14 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 12:54:08 -0000 Hi John, Comments below.=20 > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: 24. marraskuuta 2015 21:25 > To: Hakala, Juha E ; urn@ietf.org > Cc: Tobias Weigel > Subject: RE: [urn] Suggested changes to rfc2141bis-14 =20 > >> > First, a URN can be resolved to 1-n URLs. > >> > >> Or, more accurately, 0-n URLs. I had already picked this up, > >> although I like your reasoning and suggestion better. > > > > 0-n is fine with me. I was only thinking about URNs that are > > actionable. >=20 > And I was thinking about both those you would describe as non-actionable = and > those actionable ones that return things > other than URLs. In any event, text has been adjusted. OK.=20 =20 > > I'm a little reluctant to make decisions based on an assumption that > > some URN can and will be resolved to one and only one URL. Even if at > > first there is just one URL to resolve to, there may eventually be > > several if the document is preserved for long term. Documents are > > copied from institutional repositories to digital archives, with > > accompanying metadata. >=20 > I think we may be agreeing but confusing each other with different wordin= gs. There are times I wish English were my first language. But sometimes even n= ative speakers seem to be confusing each other ;-).=20 > Let me try this a different way; if you agree, I'll try to tune the text = (I am not > proposing what follows as text for 2141bis even if it sounds like it migh= t be > used that way... unless people believe that including it would provide > significant and useful clarification): >=20 > The "value" of a URN, also known as its result or the result of "resolvin= g" it, > may be: >=20 > (1) Nothing at all, if the whole namespace or some NSS > value within the namespace is intended as a pure > identifier (also known as a URN that is not actionable), > i.e., to be compared for equality only, not "resolved". OK. This is definitely a valid use case according to the earlier agreement = in URNBIS. =20 > (2) A single URL, identifying or pointing to a single > instance of a function or retrievable object. An > r-component might be used as a selector for that > instance, e.g., to specify the difference between > URLs identifying a data object and metadata. OK. This is one of RFC 2483 resolution services and has been around for a l= ong time. But I would not say that the URL is identifying a function / obje= ct. Pointing to is a better term; you might also consider "indicating a loc= ation of" or something else which does not grant URLs a role in identificat= ion which they cannot fulfill in the URN sense of the word. =20 In order to underline the difference between 2 and 3, one could say "the si= ngle instance", but there may be several copies of the resource although th= e resolver is only aware of one.=20 > (3) One of a family of possible URLs. Each member of > the family identifies or points to an instance of > function or retrievable object. Each of those functions > or objects are considered equivalent to all the others, > using namespace-specific rules. Note that equivalence > among objects or functions has nothing to do with > whether two URNs are equivalent. The selection model > for which URL from a family is chosen is far outside the > scope of 2141bis but might include network distance, > possible speed of retrieval, cost, or criteria specified > as part of an r-component. OK. Family could consist of for instance copies of a PDF version of a book,= or subsequent printings of a book which are so similar that they all share= the same ISBN, made available in PDF form. In this case anyone can accept = that the members of the former family are identical, but in the latter case= there may be tiny differences between the members (printing errors fixed, = etc.) so namespace specific knowledge is required for understanding that th= e files do form a family.=20 Selection models already available in Handle identifier community include c= ountry where the target system is located or weight which is based on load = balancing. See=20 https://www.handle.net/overviews/handle_type_10320_loc.html =20 > (4) More than one URL, with each one being treated a > member of the same family and hence equivalent to each > of the others, as above. The difference between this > case and (3) is that, in (3), the URN resolution or > mapping mechanism determines which URL will be most > appropriate for the user/client while, for this case, > the determination is at least partially made by the > client after receiving multiple URLs. As with (3), > r-components and other information might be used to > narrow the range of URLs that are returned. In some > case, (3) is just a special case of this one in which > exactly one URL is returned rather than one or more. OK.=20 >=20 > (5) More than one URL, with the collection identifying > the elements of a multi-part object, function, or a > combination of objects and functions. "Multi-part" is > a function of the namespace and objects in it and might > include a file and separated metadata. Any of the URLs > might either be unique to the URN (as in (2) or members > of a family (as in (3)). An r-component might be used > to select the elements for which URLs were desired as > well as specifying URL criteria for a given element as > in (3) or (4). OK. Identification of complex objects such as research data sets is still w= ork in progress. But if and when component parts of a resource have been id= entified with their own PIDs (in addition to the resource itself) then retr= ieving the whole thing inevitably results into retrieval of multiple URNs (= or other persistent identifiers), plus multiple URLs which in this context = are not regarded as identifiers.=20 > (6) Either objects or identifier-like locators that are > not URLs. Nothing I can find in 2141 or WG conclusions > about 2141bis requires that URLs are the only possible > actionable results of URNs. These objects or locators > are otherwise similar to URL values in the categories > above. r-components might be used to specify whether a > URL or an object is returned as well as providing > selection criteria for particular objects or functions > within an equivalence set or determine which sets of > objects are to be returned. I would rather say that URN can resolve to other URNs or PIDs. Let us assum= e that a user starts the process with an immaterial work such as Hamlet in = mind. If he (the user, not Hamlet) makes a very broad request (find me ever= ything about The tragedy of Hamlet, Prince of Denmark, a play written by Sh= akespeare between around year 1600, a smart search system will send him a w= ork level record with links to related works (translations, and variant wor= ks such as films based on the play) which will have their own URNs or other= persistent identifiers. Using this information, the search can be cascaded= further (Shakespeare in love -film is available in DVD, Blu-ray and via Ne= tflix, and these manifestations may have their own URNs). =20 > Now, if we can agree that all of those uses of URNs are appropriate, then= we > have a basis for both fine-tuning 2141bis and evaluating standardized res= olver > specifications. If we can reach consensus that some of them are not > appropriate uses of URNs, that moves us forward as well, but I continue t= o > think that different of us are assuming some, but not other, cases and th= at is > causing confusion about, e.g., "1 or more URLs", which could refer to any= of > cases (2) - (5). Sure, all the above cases and probably some more are relevant. For instance= , users might benefit from reverse resolution in which, starting by URL, a = user finds URN or other persistent identifiers, and may then find other loc= ations from which the resource can be found. This process cannot start from= resolvers but from production systems which take care of the initial URL -= URN mapping, and then contact the appropriate URN resolver to go from the = known URN to other PIDs and locations. =20 > I _think_, but am not at all sure, that the case list above also provides= a > complete list of cases in which r-components are useable and appropriate. > Anything else is presumably applied after the URN is mapped into somethin= g > else according to one of those categories and is hence a q-component or f= - > component. I would not dare to use the phrase "complete list". Whatever is regarded as= complete will depend on technical infrastructure in use. For instance, whe= n we have (several decades from now) a long tail of different manifestation= s of works created via migration, it will be important for the users to kno= w just how different the modern (migrated) versions of a document are from = the first edition. The user may think that look and feel of the document wi= ll not matter, but the intellectual content should be the same (and sometim= es the opposite may be true). Information systems of the future should supp= ort this kind of information needs, and interlinking of related resources u= sing e.g. URNs.=20 =20 > Note also that Case (5) presents a challenge for f-components because it = isn't > clear from 3986 whether the f-component belongs to the first URL that is > returned, each of the URLs in the set, or something else. For Cases (2) = and > (3), the answer is presumably obvious and, for Case (4), it would presuma= bly > be applied to all of them. >From URNBIS point of view f-component is IMO not a challenge. We know exact= ly when it makes sense to apply it, and when it does not. And when f-compon= ent can be used (URN identifies one and only one manifestation of a resourc= e, such as PDF version of a book, and the user asks the resolver for fetch = the document) using URN + f-component provides more reliable result than us= ing just URL + fragment. In case 5, f-component should not be used at all. =20 > > I used MUST NOT to underline the difference between r- and > > q-components. If clients are allowed to send service related requests > > intended to the resolvers in q-components, then resolvers must check > > q-components and determine if they should do something with them > > (beyond just deciding the correct target system to which the > > q-component can be sent un-altered). This would complicate resolver > > implementation a > > lot. >=20 > Indeed. But, because of the list of the cases above, I don't think the t= ext you > had adequately makes the distinction for all of them, or probably anythin= g > other than cases (2) and (3). OK.=20 >=20 > >... > >> > A resolution service MAY parse the q-component in order to > >> > determine an appropriate target system to supply the requested > >> > service. " > >> > >> Here I get confused. I have assumed that determining an appropriate > >> [target] system to supply a requested service falls > >> well within the scope of r-components. Can you explain more > >> about what you had in mind? > > > > Let us assume that a user wants descriptive metadata about the > > identified resource. This can be done either with r-component or with > > q-component, and both of them may be constructed on the fly by the > > client the customer is using. > > > > If r-component is used, it is obligatory to specify the service and > > service related parameters (if any); >=20 > I think that is true unless the service is intrinsic to the > namespace definition. Do you agree or do you think it always > needs to be explicit in the r-component? Depends on how you define "intrinsic to the namespace definition". If there= is just one resolution service available (currently many resolvers just ma= p URN to single URL, which is not smart enough) there is no need for r-comp= onent at all, with or without parameters. And if a service is available but= only in limited form (metadata can only be supplied in Dublin Core) it is = possible to carry on without using service related parameters. But when res= olvers get more versatile, r-component (or q-component) must be added to fa= cilitate this new born intelligence. So even if the resolver is a one trick= pony, it will be easier to extend it in the future if the components are u= sed properly from the very beginning. =20 >=20 > > in this case > > the service is (in RFC 2483 syntax) I2C (URI to URC) and the parameter > > is the appropriate metadata format. The client may also specify a > > target system (server) to which the request should be sent. In plain > > text a typical URN resolution request could be something like > > "retrieve from the Library of Congress online catalogue a MARC record > > describing the resource with ISBN XXX". >=20 > Just to be sure we are talking about the same thing, in terms of my case > breakdown above, you are proposing to use the r-component to identify bot= h > the criteria for selection of a URL from a family (Case (3) for "Library = of > Congress online > catalogue") and the particular URL (Case (2) for "the URL for the particu= lar > data or metadata to be returned", in this case > the MARC record. Wfm, but I sense a slippery slope in which > the Case (2) r-component element might not be compatible with different > values for the retrieval location or system associated with Case (3). True. For instance, the resolver might require a metadata record in e.g. UN= IMARC format from the Library of Congress online public access catalogue. T= he OPAC would not be able to send metadata in this format, but the problem = can be fixed simply by asking metadata in a format that is supported (Dubli= n Core, MODS, MARC 21, MARCXML). Mapping tables in URN resolvers can be see= n as metadata about target systems the resolvers communicate with. This met= adata must be maintained, and in the perfect world this information would e= xist in standardized format so that it can be easily shared. =20 > > It is up to the resolver to modify the r-component containing this > > request into something (such as SRU search > > URI) that a server in the LoC application can support. >=20 > Yes, and this is an important point about the URN -> URL mapping not bein= g a > purely mechanical operation that can be carried out in the same way by ev= ery > resolver and/or client. >=20 > > Eventually some systems may be able to deal with "native" > > r-components, but at first this will not be the case. > > > > Note that "hard-coding" the target system in the r-component may be > > risky, because the preferred target system may no longer exist or it > > may not be accessible because of a paywall or technical issues. The > > resolver may be aware of 1-n other systems that can supply the > > requested service, so it must be able to override the client's > > preference when necessary. >=20 > I'd hope that (even the idea of overrides) could be per-namespace because= it > seems to me that the alternative takes us back to a universal resolver-fi= nder. > Otherwise, if nothing else, we'd be creating a huge security hole, equiva= lent > to the "right" of DNS servers to rewrite queries or responses to their > convenience -- a right DNSSEC is intended to eliminate. This security issue needs to be investigated more closely. Resolvers are cu= rrently managed by trustworthy organizations such as national libraries, an= d there has never been any security related problems with faulty resolution= . But this does not mean that such problems will not occur in the future.=20 =20 > > Current URN resolvers are not smart like this; none of them can deal > > with q- or r-components yet. This "intelligence" > > needs to be built into them, and we must be careful not to impose any > > artificial limitations to this, like hardcoded server addresses which > > cannot be overridden. >=20 > I think a distinction is important between what the standard requires and > what some namespace might choose to allow. For the standard to require > "hardcoded server addresses which cannot be overridden" would clearly be = a > disaster. However, I can imagine namespaces that are sufficiently tied t= o one > set of servers that, while the URNs for that namespace are persistent, in= ability > to access that server makes that namespace useless for anything but > identifier purposes. I wouldn't want to encourage such cases, but I thin= k it > would be dangerous to forbid them. I agree that although the standard must be "liberal", namespaces may enforc= e or recommend different policies. Whether any of this needs to be incorpor= ated in 2141bis, or if these things (such as the possibility of specifying = resolver related things and in the r-component, and options namespaces have= in enforcing / recommending / not using them) can be left to later documen= ts which deal with resolution can be debated, but I would rather not includ= e this stuff in 2141bis.=20 > > There may be cases in which fragments have a more important or > > different role from what RFC 3986 assigned for them. For complex > > objects such as research data sets fragments may be essential for > > retrieving what is needed. But it is target systems which are aware of > > this. I don't know if there is no need to extend this kind of > > knowledge about fragment usage to URN resolvers as well. But your > > version of the text is OK, since it allows yet another possibility to > > make resolvers smarter. >=20 > Good. FWIW, we have been beaten up very thoroughly about roles > for fragments that are different from the RFC 3986 discussions. > But, if we can move on without opening that issue up again, I think we sh= ould > do so. Me too.=20 > > Resources and resource metadata tend to have different fragments, or > > same fragment would give different results. It is OK to do this: > > > > urn:isbn:xxx#chapter2 > > > > if the e-book media type supports this. And it is OK to do this (if > > the metadata format allows it): > > > > urn:nbn:xxx#author > > > > to find out who the author of the book is. But usually you cannot use > > metadata related fragments for the resource itself, or resource > > related fragments for metadata, since that would either not make sense > > at all, or would yield unpredictable results. There are no chapter 2's > > in metadata records. >=20 > Understood. I think that there are two other examples (both odd > cases) related to your examples above. First, if "xxx" is a > compendium of some sort, then there might easily be separate metadata for > each chapter. In that case the metadata for such a compendium might well > be organized by chapter and either of the examples above (and, shudder, >=20 > urn:nbn:xxx#Chapter2#author ) >=20 > might all make perfectly good sense.=20 Something like "urn:nbn:xxx#Chapter2-author might make even more sense ;-).= Some documents will have complex internal structure which will enable / en= courage people to use fragments for citing and referencing purposes, and we= may see things like the URN above in the future. =20 I think the implication of this is that > some fragments are going to be nonsense when applied to particular object= s, > even when those fragments are > attached to / part of ordinary HTTP URLs. URNs might make that > situation a little bit worse, but, IMO, no much. URN should improve persistence and therefore they are a good basis for f-co= mponents. The problem is that URN + fragment must be resolved to the resour= ce itself. The ideal combination for citing and referencing is therefore UR= N + r-component (or q-component) for requesting the resource itself + f-com= ponent (which is usually not sent to the resolver). If no resolution servic= e has been specified, things are fine as long as the resolver default servi= ce is the right one. If the default changes the user is out of luck. And wh= en URNs are embedded in references and citations it is close to impossible = to add r-component to them so that they start producing the correct result = after the resolver behaviour has changed. ISO standard for citing and referencing will be revised 2016. The working g= roup may need to consider carefully what to say about usage of persistent i= dentifiers. The current version of the standard says next to nothing about = PIDs, and far too little about citing of electronic resources in general. = =20 All the best,=20 Juha >=20 > > Meaningful use of fragments is difficult if the user has no idea of > > what fragments are available in the identified resource. So it is > > possible that fragments will usually be applied when people cite > > publications. This is safer than using URL + fragment as long as the > > identifier is applied to single manifestation of the resource only. >=20 > Absolutely. But, again, not something I think we can restrict > in 2141bis. >=20 > best regards, > john From nobody Wed Nov 25 07:08:59 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAC71B2DDA for ; Wed, 25 Nov 2015 07:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuzEf5CyiuU0 for ; Wed, 25 Nov 2015 07:08:55 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD8D1B2DBF for ; Wed, 25 Nov 2015 07:08:55 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A5E70509C5; Wed, 25 Nov 2015 10:08:51 -0500 (EST) To: Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> From: Sean Leonard Message-ID: <5655CE83.4090505@seantek.com> Date: Wed, 25 Nov 2015 07:06:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050603060704040403050708" Archived-At: Cc: John C Klensin , "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 15:08:57 -0000 This is a cryptographically signed message in MIME format. --------------ms050603060704040403050708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/24/2015 11:05 AM, Andrew Newton wrote: > On Tue, Nov 24, 2015 at 5:19 AM, Sean Leonard wr= ote: >> 2141 is implementable (and many implementations exist) for the purpose= that >> it claims: universal durable identifiers. >> >> That do nothing. >> >> I.e., "resolution" in 2141 is not specified, so it's not part of the s= cope. >> >>> Or is >>> 2141bis making URNs unimplementable? >> >> As of 2141bis-14, the identification part is mostly fine. Stuff like "= /" got >> included in identification, while "?" and "#" and such got turned into= >> delimiters for other non-identification components, consistent with RF= C >> 3986. Progress. >> >> But the things that ? and # do, are not currently implementable. 2141b= is-14 >> is now including "resolving" in its scope, in a way that 2141 does not= =2E So, >> we have to say, at a minimum, what the parts are going to do. > This is just my opinion, so feel free to disabuse me of any of it. > With regards to resolution, I believe your assessment of 2141 is > accurate. Resolution of URNs today requires software to key off of the > NID with namespace-specific behavior (though a lot of namespaces will > resolve with nearly identical behavior). In other words, there are a > lot of things software can do with all URNs, but resolution is not one > of them. > > What I fail to understand is how r-components change that assumption. > That is, even with r-components the resolution of a URN requires > namespace-specific behavior. And that leads me to this question: why > do we need a set of standard r-components for all namespaces if > resolution is still a namespace-specific operation? Why can't the > r-components be namespace-specific since the resolution is also > namespace-specific? r-components can be namespace-specific. r-components can also be=20 namespace-agnostic. As with all things, it depends on what the rough=20 consensus/trend is in this WG, which ought to be informed by real-world=20 experience. The trend is that resolvers (computing implementations that take in urn: = URI parts) take the assigned-name part and the r-component part, but=20 *not* the q-component or f-component parts. Resolvers return some=20 "products", which can be 0-n URLs (see Juha's statements) but could be=20 other types of metadata or whatever. An implementation that is not a "resolver" can look at the assigned-name = part and discard the rest, in order to extract information about the=20 assigned-name, and compare assigned-names (aka URNs) for equivalence.=20 This is obvious from Section 4. It follows that the r-component is "resolution-specific"--how it is=20 structured depends on what exactly we want resolution to *do*, and=20 whether we want to build resolvers OR interoperable resolver networks=20 that can resolve multiple/most/all assigned-names. What we ought to appreciate is that a resolver sucks in the=20 assigned-name portion as an input parameter, and then can do whatever it = wants with it, such like a search engine that takes input of "ieTf=20 rfc3986 site:ietf.org" and "IETF RFC 3986". They are different strings=20 but will likely (ultimately) return the same information. A resolver may = do the exact same thing (i.e., return the exact same results) with=20 "urn:ISSN:XXX", "urn:ietf:rfc:YYYY", and "urn:doi:.....", because the=20 resolver internally is smart enough to map all three of these to the=20 same object. Juha just wrote [I will respond to the rest of Juha's post later]: >> Sure, each namespace may have 1-n resolution services which are - at leas= t in the beginning - only supported by that namespace. But other namespac= es may develop support for those services later. And there are generic se= rvices which may / will be supported in many if not most namespaces. << and: >> Since URNs are used in different technical environments the actual implem= entation of these generic services may vary (retrieval of resource metada= ta means different things for librarians and archivists), but different n= amespaces could still share the same r-component syntax to request these = services from resolvers. << and: >> URN implementers have already built resolvers which deal with multiple na= mespaces (ISBN and NBN, for instance). There are also resolver networks i= n which resolution related data is harvested from participating systems t= o "union resolvers". This kind of co-operation becomes more complicated t= han it needs to be if each namespace has its own guidelines for construct= ing r-components. << Yay! Implementation experience! Making r-components *always* be namespace-specific makes them more=20 complicated. Syntactically, we already have a namespace-specific part:=20 the NSS. That should be enough. I hope we are clear now that there are=20 resolution behaviors (aka, operations) that cut across many--possibly=20 all--namespaces. It is more modular, and therefore more implementable (I would state more = plainly: implementable vs. unimplementable) when r-components are not=20 *always* namespace-specific. In the majority of cases, their semantics=20 should be orthogonal to the namespace in the assigned-name component. Even if r-components are "namespace-specific", it's important to=20 appreciate that a namespace that defines r-components (i.e., defines=20 resolution operations) is engaging in a different kind of=20 identifier-assignment process than its primary purpose, which is to=20 define the NSS part. If a "namespace" for books defines an operation=20 "getpdf", that is a different identifier and assignment than a namespace = for books that defines the book identifier 99992929212. (Syntactically, both can be accomplished with the same NID--this is=20 something that is developed in draft-14-seantek.) Sean --------------ms050603060704040403050708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjUxNTA2NDNaMC8GCSqGSIb3DQEJBDEiBCBFgTCRsHwbG+tozlMPFspwTbgeUGlwbR5A9zIP te0TADBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBpLTO14eJ8N07JKDva oANrkrgiMArNQT0k1YcjICk/48mgqMNHRXxAJveQqrTT0rh0xHjoQdoWkYC7itlh8Mfiz2Mv XZpglbBddjXh67sPzlUILFCzw8m0ILpGX701vdnAp8n7rMMYgbRXb9/kvfjSMV2owBBfyjUW 5b5TsH3DuB47sbm5Cq/oKGJpzT14I8U8u+4KFRotse85FA1xYSDy2/PNGtFJlbL6+fxkGPoJ mJUxzOWeNkW/sqOJrkGTLEIfHeox3eD6XLdOeHIsi/jSOgatw0XtNeOqugtCGZYK+8pzGsoF KBCVReBvTXIbN4zeeOSBFMmKu4YZ1k8xoXSpAAAAAAAA --------------ms050603060704040403050708-- From nobody Wed Nov 25 07:20:22 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857741B2DEA for ; Wed, 25 Nov 2015 07:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmG5stv1OFBC for ; Wed, 25 Nov 2015 07:20:17 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2001A7D83 for ; Wed, 25 Nov 2015 07:20:16 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BE39E509C1 for ; Wed, 25 Nov 2015 10:20:15 -0500 (EST) To: "urn@ietf.org" From: Sean Leonard Message-ID: <5655D134.9000600@seantek.com> Date: Wed, 25 Nov 2015 07:18:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090504010909070909090606" Archived-At: Subject: [urn] Consensus & terminology check: assigned-name (URN) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 15:20:21 -0000 This is a cryptographically signed message in MIME format. --------------ms090504010909070909090606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable This is a consensus check on our understanding of the NID : NSS productio= n. A urn: URI is parseable into the following components: "urn:" assigned-name "?" r-component q-component "#" f-component (Forget about the specific order for the time being. The list above is=20 unordered.) Have we been using the following terms with a clear consensus of their=20 meanings? URN assigned-name urn: URI When I think of "URN equivalence" (draft Section 4), it is only the=20 assigned-name production that is getting compared. q-component,=20 f-component, and r-component are not considered. I want to be sure in these discussions that, just as we are cleanly=20 separating q- and r-components from each other, we also cleanly separate = the NID : NSS portion from other parts. It seems to me that is the Uniform Resource *Name*, which we = can (and ought) to call one of: assigned-name, Name, or URN.=20 q-component, r-component, and f-component are not *Name* parts. (I=20 believe that at one point, it was called the p-component during WG=20 discussion. Not sure if we want to call it that anymore.) Furthermore, the complete urn: URI syntax, including NID NSS r-component = q-component and f-component, is what can be called "urn: URI". (But it=20 can be called something else.) The main thing I am trying to get at here, is that our use of the term=20 "URN" has not been precise enough, as our debates have pushed it around=20 to mean different parts of different things. If we expand the acronym,=20 Uniform Resource Name ought to refer to the "Name", which is the part=20 that occurs before the first "?" and "#". A complete urn: URI is no=20 longer "just a name" because q-component, r-component, and f-component=20 are more like appended instructions to "do things with the named thing=20 in a defined way (i.e., resolve them and process the resulting resources)= ". Sean PS In -14-seantek, I redefined the assigned-name production so that it=20 excludes the "urn:" prefix. Look at the ABNF for details. --------------ms090504010909070909090606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjUxNTE4MTJaMC8GCSqGSIb3DQEJBDEiBCC8xgJd9K82qMgUJfLsEv7LjGjeHLEcvYvQCrUn ze0gIDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBe7VlmAx5zwj8etS1v jReUaO+N+X6KC+l/W8Er5nYv0NVTCwmy/IlxHT5+JLNOJ4069dpH8X8+uGjTTJbqjL7nFHeo VyjXHfLI1tYHLPhZ6lVy0VPSFBBeCWJQ1+q36iHdy+8I4dEjGAt0+9QXYDKRuT5xqNtVN0RN IZ0a+6ljaX+sM3aSJwQ0Zq+/rZuimEyVFiRPAsGE0H9cMSsgnmWL3Es/V6M8jwUFrZ+/aVMW 3AaOCeayZy1Kre6V2h9cCiTprOjVX0c7vRkSp4tToR02uwBHi0nDzzqdy/oOMtTisMes+lNU Nqz7vkPp2ogFNM/8RKb1CjXfzYkc6JOz0aunAAAAAAAA --------------ms090504010909070909090606-- From nobody Wed Nov 25 07:45:45 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E991B2E56 for ; Wed, 25 Nov 2015 07:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoGyq60GGA9t for ; Wed, 25 Nov 2015 07:45:42 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8271B2E53 for ; Wed, 25 Nov 2015 07:45:41 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a1cGK-0001eX-Ki; Wed, 25 Nov 2015 10:45:40 -0500 Date: Wed, 25 Nov 2015 10:45:35 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <5655D134.9000600@seantek.com> References: <5655D134.9000600@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Consensus & terminology check: assigned-name (URN) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 15:45:44 -0000 --On Wednesday, November 25, 2015 07:18 -0800 Sean Leonard wrote: > This is a consensus check on our understanding of the NID : > NSS production. > > A urn: URI is parseable into the following components: > "urn:" > assigned-name > "?" > r-component > q-component > "#" > f-component > > (Forget about the specific order for the time being. The list > above is unordered.) Without making any assertions about consensus, that is the model I, and I believe Peter, have been following in editing 2141bis. > Have we been using the following terms with a clear consensus > of their meanings? > > URN > assigned-name > urn: URI At least in list discussions, I think "URN" has sometimes been used more loosely, sometimes for the entire string that I've referred to as a "urn-string" in some places (and for which 2141bis-14 uses "" and that you describe as a "urn: URI" above, and sometimes for the assigned-name only. I hope that bit of sloppiness does not appear in 2141bis; if people find instances of it, I'd appreciate pointers so they can be fixed. FWIW, if anyone believes that clarity in 2141bis would be improved by substituting "urn-string" for "namestring", as so. It occurs to me after having read your note that "namestring" might cause confusion with "Name" and hence the change might be helpful, but I won't make the change it unless others think it would help. > When I think of "URN equivalence" (draft Section 4), it is > only the assigned-name production that is getting compared. > q-component, f-component, and r-component are not considered. Again, I believe that is the intent of the text, although r-components are a difficult area because some of the examples various of us have given imply an opportunity for considerable differences in the results of URN (sic) evaluation. I think we are ok with that and, coming back to an example I used in my exchanges with Juha, it is another difference (other than "bad idea") between (using the 2141bis-14 syntax) urn:isbn:xxxx??metadata and urn:isbn-metadata:xxxx My sense (could be wrong) is that we understand the difference there and have a reasonable understanding the "urn:isbn:xxxx" and "urn:isbn:xxxx??metadata" are the same name and reference the same object even though the evaluation results are quiet different. Getting a clear, accurate, and succinct explanation into the text has not proven easy. > I want to be sure in these discussions that, just as we are > cleanly separating q- and r-components from each other, we > also cleanly separate the NID : NSS portion from other parts. Yes. > It seems to me that is the Uniform Resource > *Name*, which we can (and ought) to call one of: > assigned-name, Name, or URN. q-component, r-component, and > f-component are not *Name* parts. (I believe that at one > point, it was called the p-component during WG discussion. Not > sure if we want to call it that anymore.) The current intent of 2141bis has been to call it "assigned-name" and, at least when the distinction is important, to use that term consistently. "Name" and "URN" are best avoided because, independent of what the document says, they carry connotations that may confuse people. Again, while Peter caught a lot, probably most, of them in -14, it would not surprise me if there are places in 2141bis where things are not as precise as they could be. Again, specific pointers would be appreciated if people find those. > Furthermore, the complete urn: URI syntax, including NID NSS > r-component q-component and f-component, is what can be called > "urn: URI". (But it can be called something else.) See above. > The main thing I am trying to get at here, is that our use of > the term "URN" has not been precise enough, as our debates > have pushed it around to mean different parts of different > things. If we expand the acronym, Uniform Resource Name ought > to refer to the "Name", which is the part that occurs before > the first "?" and "#". A complete urn: URI is no longer "just > a name" because q-component, r-component, and f-component are > more like appended instructions to "do things with the named > thing in a defined way (i.e., resolve them and process the > resulting resources)". Yes. But I fear that pinning down "URN" at this point, especially given the added confusion of the language in 3986 that talks about URNs that are not part of the "urn:" scheme at all, is fairly hopeless at this point. > PS In -14-seantek, I redefined the assigned-name production so > that it excludes the "urn:" prefix. Look at the ABNF for > details. Yes, I noticed that. I no longer remember the details of the discussion, but I think some combination of Peter and I decided to include the prefix because it made discussions of equivalence easier and avoided trying to be precise about what a "URN" was (especially in the context of the other issues mentioned above). john From nobody Wed Nov 25 08:05:55 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B981B2F14 for ; Wed, 25 Nov 2015 08:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H6ogQc0QfUb for ; Wed, 25 Nov 2015 08:05:53 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501371B2EB5 for ; Wed, 25 Nov 2015 08:05:53 -0800 (PST) Received: by wmww144 with SMTP id w144so186208458wmw.1 for ; Wed, 25 Nov 2015 08:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fMbVRcCW9oJRIWUVidlsdsXPwB0wbqed8uH1kgrLmMU=; b=Wo2nPXWgsXkzL1N8IOR25aPIBI/5ExYkSgEvNQF4QwPFCbSvHhe1qq1RWH6M6DBa0a 6hHpAFGY8fstbC/IdF/5rjUSdx6nn0h0ofyvMgGebFxfk64KQsEVIatbnjYTQQxEr+fA hOjxYK7xGHCJnvHrapQr0ZqGrhV2+/f9zDUU/H5bQUyEc17yO1CfwJbZM4EJ5G4Fa9o5 7easEbu+HWqK/SawPgzcTb/G8+6Yu93D+NYZTndDaEqHH82xuIAk19AIkGTrRMIoQpqx KtP+kUr/I+WGGJL7qB8OcoPQ9m27A8gXCMGsHBZSDbKcy6dzp4rnrF2UKEja7LF+MC7C vN8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fMbVRcCW9oJRIWUVidlsdsXPwB0wbqed8uH1kgrLmMU=; b=W/RaTf9B69PeYACtGMvlO2wtKv3bSoxk6JO1xgxrWDpPFwdmjOypPAufOqGeaa2rFm kEnW9mRPTZz1Pzav/qd0iqxdY/XGxlf7FlnmZ8nVpmINGS+YZbEa5ahggRplsMLD+QQv VDggAVSLRDZiNFGRel7vqfCdgn1mtcTPFc/AIC4eZ0phxX06DT7YaMx7+MBVzNl/eZqw Ijp9ZJfr7q7h59oGJUdJa/rgcvQ+WGeMM/VCggnL/WS2DiYi8ohjd+qBuCZ9UvKpOGVL 0CknI37c/PEcr9yKEYD64SYHUpzsk0qe3xrgk/GCU0Te7tOnc3teqGy56r/EEEKeEUp1 RF5Q== X-Gm-Message-State: ALoCoQkE/fylTtfv0JufwhTPQwZYVgL28gjMcQ8qB4Bel3M5+e6z3kl9DoLaq2qa7+NSgGj4pxaX MIME-Version: 1.0 X-Received: by 10.194.133.233 with SMTP id pf9mr43522666wjb.71.1448467551836; Wed, 25 Nov 2015 08:05:51 -0800 (PST) Received: by 10.194.91.203 with HTTP; Wed, 25 Nov 2015 08:05:51 -0800 (PST) X-Originating-IP: [96.241.188.13] In-Reply-To: <5655CE83.4090505@seantek.com> References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> Date: Wed, 25 Nov 2015 11:05:51 -0500 Message-ID: From: Andrew Newton To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John C Klensin , "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 16:05:54 -0000 So to paraphrase both Sean and Juha, while resolution may still be namespace specific including the behavior of r-components, it is quite helpful to implementers of resolution services for multiple namespaces if the r-components had similar structure, etc... Where Sean and Juha seem to differ is that Sean wants the r-components standardized now and Juha sees that as something that can be done later. Let me know if I've misunderstood. Anybody else care to comment? -andy From nobody Wed Nov 25 08:40:15 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61F1A1B9E for ; Wed, 25 Nov 2015 08:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo-uTLXwHwdg for ; Wed, 25 Nov 2015 08:40:12 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31B71A1B96 for ; Wed, 25 Nov 2015 08:40:12 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 23C95509BB; Wed, 25 Nov 2015 11:40:10 -0500 (EST) To: Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> From: Sean Leonard Message-ID: <5655E3EF.8030204@seantek.com> Date: Wed, 25 Nov 2015 08:38:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010009030701000302030100" Archived-At: Cc: John C Klensin , "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 16:40:14 -0000 This is a cryptographically signed message in MIME format. --------------ms010009030701000302030100 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/25/2015 8:05 AM, Andrew Newton wrote: > So to paraphrase both Sean and Juha, while resolution may still be > namespace specific including the behavior of r-components, it is quite > helpful to implementers of resolution services for multiple namespaces > if the r-components had similar structure, etc... > > Where Sean and Juha seem to differ is that Sean wants the r-components > standardized now and Juha sees that as something that can be done > later. I guess that is a reasonable paraphrase, at least of my part. Consider the resolution operation "info", which I have defined in=20 -14-seantek to mean "get information about the thing identified by the=20 assigned-name component". Would we rather that urn:isbn:XXX?info,=20 urn:ietf:rfc:XXX?info, urn:ietf:params:XXX?info, and=20 urn:oid:0.1.2332?info return markedly different things? Use the=20 principle of least surprise..."info" should have a roughly equivalent=20 meaning across all different namespaces (or, as many different=20 namespaces as possible), even if for many things identified in the=20 namespaces, it's not applicable. I would much rather do the standardization now, because (among other=20 things) that way different resolvers can interoperate with each other as = well as with non-resolver components (clients, etc.). Also, we have a=20 proposed syntax and momentum to discuss it. If we don't get it done now, = I fear it will be another 4-20 years before it happens. Just looking at=20 the history on this thing... Sean > > Let me know if I've misunderstood. > > Anybody else care to comment? > > -andy --------------ms010009030701000302030100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjUxNjM4MDdaMC8GCSqGSIb3DQEJBDEiBCB9HBnm/wRJz56fGVvg6UJh6QdrAm9KT9Tzv7DC CsudFzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCoV/UQ6MQlR1WfERnI x4wTEWvBQhhwLI2k0dkH1EtgMBaScy3BvocXow9Rjq5AabiNn0S9akykoNrVUeifkndi9GUd SwfGuUy0HCV/SRAd3jxLfgAeBHcFkiXX0PDFLpEikZI0Oo3A0GAgfX6RHnUFOWK+DjEtqBJV 9l+yg4ERmumd6wH2iI0eShZgJiEbocsYsecghXsgADnBqvc1u10w0aaI24JgEK5P8j8Wk6wE 9XpLO3jK+ooQtt+lZhaImW17KD3xlMV7Lbh82KIORbeFz55Ov61V9Z8AoSUJwFY62Ur/5441 MqhOG8U1UzgqEEph9EpDE1Z+6tRpaHNuF0QoAAAAAAAA --------------ms010009030701000302030100-- From nobody Wed Nov 25 09:08:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BB71A6EF0 for ; Wed, 25 Nov 2015 09:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKCZU1ac2Bbg for ; Wed, 25 Nov 2015 09:08:23 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9D91A6EED for ; Wed, 25 Nov 2015 09:08:23 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a1dYL-0001q0-Ey; Wed, 25 Nov 2015 12:08:21 -0500 Date: Wed, 25 Nov 2015 12:08:16 -0500 From: John C Klensin To: Sean Leonard , Andrew Newton Message-ID: <511B2246A91C5D3CA4C83986@JcK-HP8200.jck.com> In-Reply-To: <5655CE83.4090505@seantek.com> References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:08:29 -0000 --On Wednesday, November 25, 2015 11:05 -0500 Andrew Newton wrote: > So to paraphrase both Sean and Juha, while resolution may > still be namespace specific including the behavior of > r-components, it is quite helpful to implementers of > resolution services for multiple namespaces if the > r-components had similar structure, etc... See the distinction between lexical standardization and various flavors of semantic standardization below and see if that helps. > Where Sean and Juha seem to differ is that Sean wants the > r-components standardized now and Juha sees that as something > that can be done later. I think there is a middle ground, which is to standardize, not all aspects of r-components, but enough of the syntax and structure to make sure that future standardization of specifics is possible. I'm not happy about going down that path, if only because I think we have been there before and backed away and because I think it will be hard to get agreement, but it is a possibility. > Let me know if I've misunderstood. I don't think so. See above and below. --On Wednesday, November 25, 2015 07:06 -0800 Sean Leonard wrote: Sean, It is going to take me a while to assimilate parts of this and I may not be able to do that until after the holiday, but a comment on a subset of it below (I reserve the right to change my mind after understanding the rest): >... >> What I fail to understand is how r-components change that >> assumption. That is, even with r-components the resolution of >> a URN requires namespace-specific behavior. And that leads me >> to this question: why do we need a set of standard >> r-components for all namespaces if resolution is still a >> namespace-specific operation? Why can't the r-components be >> namespace-specific since the resolution is also >> namespace-specific? > > r-components can be namespace-specific. r-components can also > be namespace-agnostic. As with all things, it depends on what > the rough consensus/trend is in this WG, which ought to be > informed by real-world experience. I'm going to switch terminology here because I'm not 100% sure I understand what you are saying and what I'm about to say may be at least partially orthogonal. I would consider an r-component to be "namespace-independent" if its interpretation is the same for all namespaces. That sameness can actually exist at any of three (or four) different levels: (i) Component Lexical: All r-components are structured the same way and can be parsed and elements identified in the same way for all namespaces. The elements themselves may differ from namespace to namespace. "Element" is used loosely to describe what r-components are parsed into; by definition, the term is a function of the lexical operations and independent of namespace as well. (ii) Element Lexical: In addition to the component-level lexical sameness, elements are reserved across namespaces s.t., for any given namespace, a particular element (and any keywords or structure) is either meaningless or has the same structure as it does for every other namespace for which it is meaningful. Different namespaces are, however, allowed to interpret the same element in different ways either across the namespace or for particular NID:NSS-identified content objects (iii) Semantic: In addition to the component-level and lexical-level sameness, elements are reserved across namespaces s.t., for any given namespace, a particular element (and any keywords or structure) is either meaningless or has the same interpretation as it does for every other namespace for which it is meaningful. There is no such thing as namespace-specific of object-specific interpretations: an element is expect to either be interpreted in the One True, Standardized, way or it must be treated as meaningless. (iv) There is a fourth level in which every element is expected to be meaningful for every assigned-name, but I think we figured out long ago that wasn't practical if only because it introduces nasty race conditions into registries and operations. I believe that even the third case implies a dynamic registry that every "resolver" can check in real time. I think the WG has considered that option in other contexts and concluded it is impractical. Given the wide range of content-objects and intermediary locators and objects, I also don't think it is plausible, but YMMD. (i) requires only that we define the internal syntax of r-components. That is not impossible, but something we have avoided so far. (ii) and (iii) imply that we need to standardize and create a keyword (or element) registry. Any elements or characteristics of r-component that don't conform to one of those levels of "sameness" makes r-components namespace-specific at that level and to at least some extent. Now, one can have a combination by adopting the criteria of (i) above and then either: (a) Reserving some set of elements (or element keywords or equivalent) and giving them standardized treatment and treating any unreserved element as namespace-specific. That is, one level further down, the "some reserved keywords" approach that drove us to the r-component/ q-component distinction and has the same disadvantages or either requiring a non-extensible list or a plan as to what happens with older implementations when more elements are added to the reserved list. (b) Making a lexical distinction, either between standardized and namespace-specific elements (while the latter would not be in any sense "experimental", a review of the IETF's experience with "X-" headers and keywords and/or the boundary between public and private port identifiers would probably be helpful in considering that option) or between two types of r-components, the ones that are expected to be generic and well-defined across all namespaces for which they are meaningful and the ones that are considered namespace-specific. Independent of the syntax chosen (including ordering), that takes us another step down the path from query to q-component, r-component to q-conponent, r1-component, r2-component and I have to wonder whether it ends there or there are still more divisions possible. Another variation would allow something else that might be interesting, which would be to structure either r-component (more or less as now defined in 2141bis-14) or r1-component (as above) so that a resolver standard or family could be identified in some way that could be standardized. If, instead of expecting all resolvers to be, or conform to the syntax and semantic assumptions of, ROP (or, for that matter, DDDSng) that would bind the resolution mechanisms and r-component interpretation to the URN-string rather than to the namespace definition without, in the process, requiring that the same mechanism be used for all namespaces (NIDs) or assigned-names. > The trend is that resolvers (computing implementations that > take in urn: URI parts) take the assigned-name part and the > r-component part, but *not* the q-component or f-component > parts. Resolvers return some "products", which can be 0-n URLs > (see Juha's statements) but could be other types of metadata > or whatever. While I think implementation experience is very valuable and important, I'm very concerned when one starts talking about "trends" at a pre-standardization phase, if only because it substitutes "we got here first and therefore you must standardize whatever we decided to do" for analysis and long-term and balanced thinking. More when I have time and energy. john From nobody Wed Nov 25 09:22:10 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475481A6F80 for ; Wed, 25 Nov 2015 09:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUC9oHcl98sk for ; Wed, 25 Nov 2015 09:22:08 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94BE1A6F83 for ; Wed, 25 Nov 2015 09:22:07 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a1dld-0001sH-3S; Wed, 25 Nov 2015 12:22:05 -0500 Date: Wed, 25 Nov 2015 12:22:00 -0500 From: John C Klensin To: Sean Leonard , Andrew Newton Message-ID: In-Reply-To: <5655E3EF.8030204@seantek.com> References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> <5655E3EF.8030204@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:22:09 -0000 --On Wednesday, November 25, 2015 08:38 -0800 Sean Leonard wrote: >... > Consider the resolution operation "info", which I have defined > in -14-seantek to mean "get information about the thing > identified by the assigned-name component". Would we rather > that urn:isbn:XXX?info, urn:ietf:rfc:XXX?info, > urn:ietf:params:XXX?info, and urn:oid:0.1.2332?info return > markedly different things? Use the principle of least > surprise..."info" should have a roughly equivalent meaning > across all different namespaces (or, as many different > namespaces as possible), even if for many things identified in > the namespaces, it's not applicable. > > I would much rather do the standardization now, because (among > other things) that way different resolvers can interoperate > with each other as well as with non-resolver components > (clients, etc.). Also, we have a proposed syntax and momentum > to discuss it. If we don't get it done now, I fear it will be > another 4-20 years before it happens. Just looking at the > history on this thing... Sean, I would _really_ like to see something like the above. But, unless you have far better ideas about how to create a comprehensive list of keywords that are appropriately treated that way than I do, I don't see how to get there. If the list is open-ended (at least to the extent of allowing additions over time), then assume, e.g., that we standardize "info" now and you build it into a resolver at version 1. Now suppose that resolver encounters urn:isbn:XXX?zork and urn:issn:xxxx?inf0 Are "zork" and/or "inf0" syntax errors? Bad keyword errors? A sign that it is time to update the resolver to version 2? Some race condition with mirrors of the registry? And note that, if the resolver is to recognize and process it, not just get itself into a "yes, I've see 'zork' before as an action keyword but have no clue how to process it" state, and do so by updating tables rather than changing code, it implies an executable description language, not just a keyword registration and definition pointer. I just don't think we understand the issues and the range of possible namespaces well enough to do that. best, john p.s. I'm probably now off until Sunday or Monday at least. From nobody Thu Nov 26 00:42:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A63F1B3722 for ; Thu, 26 Nov 2015 00:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R__8rlmMTL_v for ; Thu, 26 Nov 2015 00:42:25 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433C21B3721 for ; Thu, 26 Nov 2015 00:42:24 -0800 (PST) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 26 Nov 2015 08:42:00 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0331.019; Thu, 26 Nov 2015 08:42:00 +0000 From: "Hakala, Juha E" To: John C Klensin , Sean Leonard , Andrew Newton Thread-Topic: [urn] urnbis 14-seantek text (incorporates discussions) Thread-Index: AQHRILNrHVLDo3jGhESGPpKOxqC3t56leoeAgAAylQCABEyYAIABCC+AgACSxQCAAU+7gIAAIfUAgADgNYA= Date: Thu, 26 Nov 2015 08:42:00 +0000 Message-ID: References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> <511B2246A91C5D3CA4C83986@JcK-HP8200.jck.com> In-Reply-To: <511B2246A91C5D3CA4C83986@JcK-HP8200.jck.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.173.46] x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 5:Vamepl22XGYNQEUmgLtoGhxM61QcFtFxPoNcqkgW7J7hUHSflOtab1cSdlm6maROaB73gIAp5aC4akASbcLN197D/I6GPIp6rD3HzmXosnDOZoez3PFDu3BkdoZ9xVOYd6UDUoF1TsHfbAfE9WhZzw==; 24:+OnYfI4+jsZk+EX5muc3D7M5QaslxQr+PdTSsqGc5LoFZbWU3sN/fRK983++hDIOpCiJqF/6qqvylQ+e1n+C74e77FowM8RtczyYqOfG2Jc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0772E5DAD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(57704003)(199003)(189002)(13464003)(74316001)(97736004)(74482002)(5002640100001)(11100500001)(15975445007)(5003600100002)(3846002)(50986999)(5008740100001)(92566002)(5004730100002)(1220700001)(93886004)(77096005)(106116001)(106356001)(66066001)(105586002)(10400500002)(86362001)(33656002)(5001770100001)(5001960100002)(54356999)(122556002)(586003)(2900100001)(2950100001)(76576001)(76176999)(81156007)(101416001)(19580395003)(6116002)(40100003)(102836003)(19580405001)(189998001)(87936001)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2015 08:42:00.1911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 08:42:29 -0000 Hello,=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of John C Klensin > Sent: 25. marraskuuta 2015 19:08 > To: Sean Leonard ; Andrew Newton > Cc: urn@ietf.org > Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) >=20 > --On Wednesday, November 25, 2015 11:05 -0500 Andrew Newton > wrote: >=20 > > So to paraphrase both Sean and Juha, while resolution may still be > > namespace specific including the behavior of r-components, it is quite > > helpful to implementers of resolution services for multiple namespaces > > if the r-components had similar structure, etc... Correct.=20 > See the distinction between lexical standardization and various flavors o= f > semantic standardization below and see if that helps. >=20 > > Where Sean and Juha seem to differ is that Sean wants the r-components > > standardized now and Juha sees that as something that can be done > > later. Right. There isn't much that we can do about q-components. They may be eith= er standard based, like URIs based on SRU or other well-known search protoc= ols, or proprietary. Clients will find it difficult to maintain proprietar= y q-components even in the short term. As regards r-components we can and s= hould avoid the situation in which each namespace has its own semantics and= syntax for r-components. The challenge is that r-components can get quite = complex when the services available multiply.=20 Just to illustrate the problem: Sean has defined resolution service "info" = (without parameters) with which it would be possible to request metadata (t= hat is, information) about the identified thing.=20 This might work in an environment where there is just one system which hold= s relevant information about the thing. But for instance my library has fou= r systems: national bibliography for descriptive metadata, digital asset ma= nagement system for the documents themselves, license database for rights m= etadata and digital archive for long term preservation purposes (and admini= strative metadata). So it is essential to define what kind of information t= he user wants, since that has an impact on which system the resolver should= pass the request. So we would need both "info" and parameter or keyword sp= ecifying what kind of information is required. Several years ago Alfred Hoe= nes suggested on this list a syntax like=20 s=3D"service name"&p=3D"parameter" Each resolution service can have a of 0-n parameters specific to it. For in= fo (or, to maintain backwards compatibility with RFC 2483, I2C or I2CS) the= se parameters could be for instance acronyms of metadata formats or metadat= a types or just "all". Then we would get something like=20 s=3DI2C if the client/user is happy with what is the resolver / namespace default, s=3DI2C&p=3Ddc if the user wants descriptive metadata in Dublin Core,=20 s=3DI2C&p=3Dpremis if the user wants preservation metadata in PREMIS format from the digital a= rchive,=20 s=3DI2C&p=3Drights=20 if the user wants licensing information and other rights metadata from the = licensing system, and=20 s=3DI2CS&p=3Dall if the user wants all the metadata / information there is about the thing (= and there will be a lot). =20 So in the community I represent, just asking for "info" will not do. Our re= solvers must know more precisely what the client/user wants. Other communi= ties may have similar requirements for some other resolution services libra= ries, archives and museums regard as simple. For instance, just retrieving = the identified resource is a challenge if a user wants a dataset containing= hundreds of terabytes of data. =20 =20 > I think there is a middle ground, which is to standardize, not all aspect= s of r- > components, but enough of the syntax and structure to make sure that futu= re > standardization of specifics is possible. I'm not happy about going down= that > path, if only because I think we have been there before and backed away a= nd > because I think it will be hard to get agreement, but it is a possibility= . Like John, I am not happy if we choose this approach, because deciding exac= tly how much (and what) we need to say about r-components in rfc2141bis is = not going to be easy. One option is to specify syntax based on for instance= names of services and service related parameters as I have done above, and= then illustrate this approach using the resolution service names from RFC = 2483 (which does not know anything about service parameters). But the most = important thing is to tell how the list of services and service parameters = will be maintained. Trying to incorporate that too into 2141bis would delay= us a lot. Besides, it would be good if other persistent identifier systems= use the same resolution service names and parameters as URN when possible,= but it will be harder to convince them to do that if all r-component relat= ed information is "hidden" in 2141bis. =20 > --On Wednesday, November 25, 2015 07:06 -0800 Sean Leonard > wrote: >=20 > Sean, >=20 > It is going to take me a while to assimilate parts of this and I may not = be able > to do that until after the holiday, but a comment on a subset of it below= (I > reserve the right to change my mind after understanding the rest): >=20 > >... > >> What I fail to understand is how r-components change that assumption. > >> That is, even with r-components the resolution of a URN requires > >> namespace-specific behavior. And that leads me to this question: why > >> do we need a set of standard r-components for all namespaces if > >> resolution is still a namespace-specific operation? Why can't the > >> r-components be namespace-specific since the resolution is also > >> namespace-specific? > > > > r-components can be namespace-specific. r-components can also be > > namespace-agnostic. As with all things, it depends on what the rough > > consensus/trend is in this WG, which ought to be informed by > > real-world experience. >=20 > I'm going to switch terminology here because I'm not 100% sure I understa= nd > what you are saying and what I'm about to say may be > at least partially orthogonal. I would consider an r-component > to be "namespace-independent" if its interpretation is the same for all > namespaces. That sameness can actually exist at any of three (or four) > different levels: >=20 > (i) Component Lexical: All r-components are structured the same way and c= an > be parsed and elements identified in the same way for all namespaces. Th= e > elements themselves may differ from namespace to namespace. "Element" > is used loosely to describe what r-components are parsed into; by definit= ion, > the term is a function of the lexical operations and independent of names= pace > as well. This kind of syntactic interoperability would mean that if r-component cont= ains e.g. a service name and service parameter, any resolver should be able= to parse the string. But the resolver would not need to understand what is= being required.=20 >=20 > (ii) Element Lexical: In addition to the component-level lexical sameness= , > elements are reserved across namespaces s.t., for any given namespace, a > particular element (and any keywords or > structure) is either meaningless or has the same structure as it does for= every > other namespace for which it is meaningful. > Different namespaces are, however, allowed to interpret the same element = in > different ways either across the namespace or for particular NID:NSS- > identified content objects OK. We can use keyword "info" or "I2C" to enable clients to request informa= tion / metadata about the identified thing. But depending on the namespace = or target system, metadata retrieved may differ. Only after the parameter h= as been added, level (iii) is reached and the interpretation should be alwa= ys the same.=20 >=20 > (iii) Semantic: In addition to the component-level and lexical-level same= ness, > elements are reserved across namespaces s.t., for any given namespace, a > particular element (and any keywords or structure) is either meaningless = or > has the same interpretation as it does for every other namespace for whic= h it > is meaningful. There is no such thing as namespace-specific of object-sp= ecific > interpretations: an element is expect to either be interpreted in the One= True, > Standardized, way or it must be treated as meaningless. This level can be reached by r-components like "info&dc" or "s=3DI2C&p=3Ddc= " which specify exactly what is being requested. It is possible to add even= more details; for instance, r-component like "s=3DI2C&p=3DMARC21&level=3D5= " means that the client wants a complete MARC 21 record, not an abridged on= e. But only some namespaces or target systems will be able to deal with thi= s level of specificity. It will be up to resolvers to know what kind of r-c= omponent usage is OK for each target system, since resolvers will map the U= RN + r-component into 1-n requests which appropriate target(s) can deal wit= h. For instance, if client wants all metadata, multiple requests must be ge= nerated.=20 > (iv) There is a fourth level in which every element is expected to be > meaningful for every assigned-name, but I think we figured out long ago t= hat > wasn't practical if only because it introduces nasty race conditions into > registries and operations. Yes, we did.=20 >=20 > I believe that even the third case implies a dynamic registry > that every "resolver" can check in real time. I think the WG > has considered that option in other contexts and concluded it is impracti= cal. > Given the wide range of content-objects and intermediary locators and > objects, I also don't think it is plausible, but YMMD. A global dynamic registry will be too difficult to build. There are some l= imited areas where useful things can be done. For instance, we can harvest = configuration information from libraries' SRU servers, and map them to r-co= mponents in URN resolvers.=20 > (i) requires only that we define the internal syntax of r-components. Th= at is > not impossible, but something we have avoided so far. (ii) and (iii) imp= ly that > we need to standardize and create a keyword (or element) registry. >From rfc2141bis point of view, specifying internal syntax might be within s= cope. But I am not sure if we are ready yet to do that. Trying to specify = keywords (elements) and their parameters a'la RFC 2483 is not practical. Af= ter URN syntax has been modernized, we should outline a mechanism with whic= h the registry is maintained. =20 > Any elements or characteristics of r-component that don't conform to one = of > those levels of "sameness" makes r-components namespace-specific at that > level and to at least some extent. >=20 > Now, one can have a combination by adopting the criteria of (i) above and > then either: >=20 > (a) Reserving some set of elements (or element keywords or > equivalent) and giving them standardized treatment and treating any > unreserved element as namespace-specific. That is, one level further dow= n, > the "some reserved keywords" approach that drove us to the r-component/ q= - > component distinction and has the same disadvantages or either requiring = a > non-extensible list or a plan as to what happens with older implementatio= ns > when more elements are added to the reserved list. Service mnemonics from RFC 2483 could and should be a starting point for cr= eation of this set. In addition to that we need parameters, such as metadat= a formats for I2C and I2CS. =20 >=20 > (b) Making a lexical distinction, either between standardized and namespa= ce- > specific elements (while the latter would not be in any sense "experiment= al", > a review of the IETF's experience with "X-" headers and keywords and/or t= he > boundary between public and private port identifiers would probably be > helpful in considering that option) or between two types of r-components,= the > ones that are expected to be generic and well-defined across all namespac= es > for which they are meaningful and the ones that > are considered namespace-specific. Independent of the syntax > chosen (including ordering), that takes us another step down the path fro= m > query to > q-component, r-component to > q-conponent, r1-component, r2-component >=20 > and I have to wonder whether it ends there or there are still more divisi= ons > possible. Both services and service parameters can be experimental or internal. For i= nstance, requesting information about things is going to be one of the most= common services, but this information may be available only in a proprieta= ry or experimental format. Experimental services may eventually become commonplace, so we need a mecha= nism for upgrading the status of a service or a service parameter. =20 >=20 > Another variation would allow something else that might be interesting, > which would be to structure either r-component (more or less as now defin= ed > in 2141bis-14) or r1-component (as > above) so that a resolver standard or family could be identified in some = way > that could be standardized. If, instead of expecting all resolvers to be= , or > conform to the syntax and semantic assumptions of, ROP (or, for that matt= er, > DDDSng) that would bind the resolution mechanisms and r-component > interpretation to the URN-string rather than to the namespace definition > without, in the process, requiring that the same mechanism be used for al= l > namespaces (NIDs) or assigned-names. >=20 >=20 > > The trend is that resolvers (computing implementations that take in > > urn: URI parts) take the assigned-name part and the r-component part, > > but *not* the q-component or f-component parts. Resolvers return some > > "products", which can be 0-n URLs (see Juha's statements) but could be > > other types of metadata or whatever. >=20 > While I think implementation experience is very valuable and important, I= 'm > very concerned when one starts talking about "trends" at a pre- > standardization phase, if only because it substitutes "we got here first = and > therefore you must standardize whatever we decided to do" for analysis an= d > long-term and balanced thinking. When it comes to creation of smart URN resolvers in general and r-component= s in particular, nobody "has gotten there" yet. Other PIDs, most notably AR= K and Handle, do provide some resolution services, but they have been imple= mented in a manner which cannot be utilized with URNs. =20 There are no existing URN implementations with features discussed here. But= there is an increasingly sophisticated technical environment with which el= ectronic resources are managed, and URNs must fit into it. Libraries, archi= ves and museums develop and maintain some of these systems, and if there is= anything that makes us different from many other organizations active in t= his area it is probably the need to preserve digital resources for very lon= g term (decades or even centuries). Persistent identifiers & functionality = based on them will be essential in this work. All the best,=20 Juha=20 >=20 > More when I have time and energy. >=20 > john >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu Nov 26 04:09:01 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C871A1A60 for ; Thu, 26 Nov 2015 04:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GguczbVaa9H for ; Thu, 26 Nov 2015 04:08:58 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AE11A0398 for ; Thu, 26 Nov 2015 04:08:57 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9043F509BD; Thu, 26 Nov 2015 07:08:54 -0500 (EST) To: John C Klensin , Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> <5655E3EF.8030204@seantek.com> From: Sean Leonard Message-ID: <5656F5DB.3080100@seantek.com> Date: Thu, 26 Nov 2015 04:06:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010204090102020308070005" Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 12:09:00 -0000 This is a cryptographically signed message in MIME format. --------------ms010204090102020308070005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/25/2015 9:22 AM, John C Klensin wrote: > > --On Wednesday, November 25, 2015 08:38 -0800 Sean Leonard > wrote: > >> ... >> Consider the resolution operation "info", which I have defined >> in -14-seantek to mean "get information about the thing >> identified by the assigned-name component". Would we rather >> that urn:isbn:XXX?info, urn:ietf:rfc:XXX?info, >> urn:ietf:params:XXX?info, and urn:oid:0.1.2332?info return >> markedly different things? Use the principle of least >> surprise..."info" should have a roughly equivalent meaning >> across all different namespaces (or, as many different >> namespaces as possible), even if for many things identified in >> the namespaces, it's not applicable. >> >> I would much rather do the standardization now, because (among >> other things) that way different resolvers can interoperate >> with each other as well as with non-resolver components >> (clients, etc.). Also, we have a proposed syntax and momentum >> to discuss it. If we don't get it done now, I fear it will be >> another 4-20 years before it happens. Just looking at the >> history on this thing... > Sean, > > I would _really_ like to see something like the above. Great! > But, > unless you have far better ideas about how to create a > comprehensive list of keywords that are appropriately treated > that way than I do, [...] Already did that. See draft-14-seantek. Let's talk about that text, and in particular,=20 discuss the merits of the different types of "rops". Let me know. (Hint: = alpha-op, OID-op, URN-op, NS-op.) > If the list > is open-ended (at least to the extent of allowing additions over > time), then assume, e.g., that we standardize "info" now and you > build it into a resolver at version 1. > > Now suppose that resolver encounters > urn:isbn:XXX?zork and > urn:issn:xxxx?inf0 > > Are "zork" and/or "inf0" syntax errors? No > Bad keyword errors? Just unrecognized. > A > sign that it is time to update the resolver to version 2? Maybe, or just add support for the operations. (How would this be=20 different from asking an LDAP server implementation, to update its=20 tables of recognized objects or recognized operations? No different. Can = update the software or can update the configs that drive the software.) > Some > race condition with mirrors of the registry? Not a real issue. (Hint: compare alpha-op with OID-op.) > > And note that, if the resolver is to recognize and process it, > not just get itself into a "yes, I've see 'zork' before as an > action keyword but have no clue how to process it" state, and do > so by updating tables rather than changing code, it implies an > executable description language, not just a keyword registration > and definition pointer. If the output is going to be URIs/URLs, the "executable description=20 language" can just be: Regular Expressions SQL or SQL-like queries JavaScript Happy Thanksgiving, everybody! (for those who celebrate it/the US version= ) Sean --------------ms010204090102020308070005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjYxMjA2NTFaMC8GCSqGSIb3DQEJBDEiBCBZRREVtPORn4WPXeMrFul6LIN9mPsV4HeIIhHW psHpETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQA46IsJ6gfojODxEeG7 g/7iABGkOYROJcoX2Ocv6TQzrmZt7o2xn61+CD4bEUz1NoEK4GqYZEq3cMDv/xyfi6Ek5SmJ T90YIyUCZhtBsPgevCN6esBTdsEa9YCmKjS/ozX8HIP7IttFTWOsiIYq1QYXG5lB/xVnA+K+ jXOiI9lOxNCuLBipbGafiXv7ITX6RFGEqj4vK1j+Wu6+mf4FiB25vNzQ/DE7bwKnlbD60E1s Frr7kadNoeLcES4Vmb89pqLD+fzAt1BY+nrikwZnGgLEvv2WWWubQ0WBXtl6PQEow16eyRz/ yno39V68lUC4V2KSNFrgyuCF9vjWIpfjgQvKAAAAAAAA --------------ms010204090102020308070005-- From nobody Thu Nov 26 04:37:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C8D1A8ADA for ; Thu, 26 Nov 2015 04:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZIZJSFWNnRX for ; Thu, 26 Nov 2015 04:37:21 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DE61A90E6 for ; Thu, 26 Nov 2015 04:37:20 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 66C7D509C4; Thu, 26 Nov 2015 07:37:19 -0500 (EST) To: John C Klensin , Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> <511B2246A91C5D3CA4C83986@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <5656FC84.30906@seantek.com> Date: Thu, 26 Nov 2015 04:35:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <511B2246A91C5D3CA4C83986@JcK-HP8200.jck.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020608060102020706070004" Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 12:37:24 -0000 This is a cryptographically signed message in MIME format. --------------ms020608060102020706070004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/25/2015 9:08 AM, John C Klensin wrote: > --On Wednesday, November 25, 2015 11:05 -0500 Andrew Newton > wrote: > >> So to paraphrase both Sean and Juha, while resolution may >> still be namespace specific including the behavior of >> r-components, it is quite helpful to implementers of >> resolution services for multiple namespaces if the >> r-components had similar structure, etc... > See the distinction between lexical standardization and various > flavors of semantic standardization below and see if that helps. > >> Where Sean and Juha seem to differ is that Sean wants the >> r-components standardized now and Juha sees that as something >> that can be done later. > I think there is a middle ground, which is to standardize, not > all aspects of r-components, but enough of the syntax and > structure to make sure that future standardization of specifics > is possible. I'm not happy about going down that path, if only > because I think we have been there before and backed away and > because I think it will be hard to get agreement, but it is a > possibility. New year, new model, new participants, new thinking. > >> Let me know if I've misunderstood. > I don't think so. See above and below. > > > > --On Wednesday, November 25, 2015 07:06 -0800 Sean Leonard > wrote: > > Sean, > > It is going to take me a while to assimilate parts of this and I > may not be able to do that until after the holiday, but a > comment on a subset of it below (I reserve the right to change > my mind after understanding the rest): > >> ... >>> What I fail to understand is how r-components change that >>> assumption. That is, even with r-components the resolution of >>> a URN requires namespace-specific behavior. And that leads me >>> to this question: why do we need a set of standard >>> r-components for all namespaces if resolution is still a >>> namespace-specific operation? Why can't the r-components be >>> namespace-specific since the resolution is also >>> namespace-specific? >> r-components can be namespace-specific. r-components can also >> be namespace-agnostic. As with all things, it depends on what >> the rough consensus/trend is in this WG, which ought to be >> informed by real-world experience. > I'm going to switch terminology here because I'm not 100% sure I > understand what you are saying and what I'm about to say may be > at least partially orthogonal. I would consider an r-component > to be "namespace-independent" if its interpretation is the same > for all namespaces. I am okay with "namespace-independent". (Note: for the following text, I read Juha's response but I am going to=20 split my response into two responses: this response handles the generic=20 feedback, and the second will respond specifically to the interesting=20 nuances or points that Juha raised.) > That sameness can actually exist at any of > three (or four) different levels: > > (i) Component Lexical: [...] > > (ii) Element Lexical: [...] > > (iii) Semantic: [...] > [even the third case implies a dynamic registry that every "resolver" c= an check in real time] > > (iv) There is a fourth level in which every element is expected > to be meaningful for every assigned-name [...] > [Defining] (i) requires only that we define the internal syntax of > r-components. > > (a) Reserving [and standardizing] some set of elements (or element keyw= ords or > equivalent) > > (b) Making a lexical distinction, either between standardized > and namespace-specific elements (while the latter would not be > in any sense "experimental", [...] > query to > q-component, r-component to > q-conponent, r1-component, r2-component > > > [Another variation...ROP...] I am getting the sense that either the -14-seantek text was not read,=20 or, the text was not clear enough about how this r-component stuff works = (perhaps my fault). Juha mentioned Alfred Hoenes' suggestion, a syntax like: s=3D"service name"&p=3D"parameter" The problem with that is that you have to deal with the (i), (ii),=20 (iii), and (iv) stuff (and (a) and (b) sub-stuff) that John just wrote=20 up. Namely, you have to reserve or standardize some set of elements and=20 element keywords. On top of that, you have to reserve or standardize=20 service names. The proposal on the table with -14-seantek is: rop ["@" r-authority ] ":" r-params where r-params is comprised of *arbitrary* name/values parameters=20 defined by the rop. Therefore, no keywords for parameters need to be defined. There is no=20 special parameter named "contentType", "s", "p", or any such thing.=20 Therefore no registry for such keywords is necessary. They are all=20 defined by the rop. Yes, this is a lexical distinction (b). The rop is in a standardized=20 position, before ":", and the name/values parameters are after the ":". The question then is how to structure the production. In=20 -14-seantek, I have made specific proposals. That text discusses the=20 proposals; here I will only highlight advantages and disadvantages: alpha-op: + looks nice - only in US-English - new registry required - contentious assignment - bikeshedding oid-op: + based on a great, functioning standard + widely deployed + subject to friendly user interface substitution + not US-English-specific + non-contentious assignment + informal universal directory exists (oid-info.com) urn-op: + namespace-defined but doesn't make rops namespace-specific=20 ( can use operation) - new registries - registries may not be public - more hassle for namespace maintainers to maintain - not actually a URN. Looks like it but different and very restricted=20 semantics. Therefore, confusing ns-op: + syntactic sugar + see urn-op - see urn-op Sean --------------ms020608060102020706070004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjYxMjM1MTZaMC8GCSqGSIb3DQEJBDEiBCC07h70dH9b8mft8CAHdvn5Qd2rJYfG2SayOf4G 5vFHTDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCkjLvi0S9Nw6AiiZsD uENESnuxdCgp2y+AL+y0y6vtNqP0cdSSWpTAO984xVQN7y/U64IelfQOBgtlFwRC/GEdRlOE jin92wktLzQtyAyFavWNjuy6D9R+K97Ngs954NaRCMuvv+mEyycOrAqgsLMyki8u30EoL85L 6Qi0kL2bO/C2DQ26WNLE/t9fEUucH3Ix6BytQT6vvTZcw3i7Wz7AQo4zgiZm9wfgL7ZdfKI6 KamRIF/OAYEwIMt7xmhCap/XVyOJqJmgjvk8y7+9FFc3YPZ1C0oJoF1fmiJbnw5JwBWDOLTu sdBlQD8Smf9Ekzul83T9ISCT71iQz9wK2f3VAAAAAAAA --------------ms020608060102020706070004-- From nobody Thu Nov 26 05:12:21 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F191A1AB1 for ; Thu, 26 Nov 2015 05:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zggT3O83zlE2 for ; Thu, 26 Nov 2015 05:12:17 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811DB1A1A90 for ; Thu, 26 Nov 2015 05:12:17 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 16EBC509C4; Thu, 26 Nov 2015 08:12:15 -0500 (EST) To: John C Klensin , Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <8AFFBCF5137C419306BCE006@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <565704B4.6080604@seantek.com> Date: Thu, 26 Nov 2015 05:10:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8AFFBCF5137C419306BCE006@JcK-HP8200.jck.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030704060304090101030206" Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 13:12:19 -0000 This is a cryptographically signed message in MIME format. --------------ms030704060304090101030206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable I wanted to pull out, and respond to, a specific paragraph at the bottom = of this message: On 11/24/2015 12:26 PM, John C Klensin wrote: >> So that's >> r-params. The r-authority production just seemed to flow out >> of syntax, and the desire to have predictable (and therefore, >> interoperable) functionality. > When you characterize ROP that way (I think there is more to it > and I'm pleased about that) a different option (with some > handwaving about quoting cnoventions) would be to define > > r-component =3D URI > > since a URI also involves a choice of identifier, an authority, > and a set of things that can be thought of as parameters. The > difficulty, as Juha pointed out in a slightly different context, > is that specifying all of that information in or with a URN is > bad for long-term stability (and maybe "persistence"). In some ways, r-component functions like a URI. However, I tried going down that path when deriving the syntax in=20 -14-seantek, and it failed miserably. Syntactically, it is not elegant=20 to stuff a complete URI in an r-component (or in general, in the query=20 production of a URI). Restricting ourselves to absolute-URI (i.e., no=20 fragment): 1. It can contain "?". That needs to be escaped. So, "?" must turn into %= 3F. 2. %3F needs to be distinguished. So, percent-encoding for "?" has to be = double-encoded: %253F. 3. Now all % has to be distinguished. So all % must become %25xx. 4. Characters like [ ] (for IP literals) must also be percent-encoded. 5. You may as well percent-encode all of the non-reserved characters. By the time you do all those things, the URI looks extremely ugly.=20 Elegance lost. Furthermore, it significantly messes up the parsing since a parser now=20 has to recursively parse a URI. And what if the URI is a urn: URI?=20 Endless recursion. (Let's not even get into fragment identifiers.) At the end of the day, yes, a URI also involves a choice of identifier,=20 an authority, and a set of "parameters". That is where the similarity end= s. There is a good point, however: the URI's analogous identifier to the=20 is the scheme, such as http, mailto, magnet, ldap, file, etc. URIs = have benefited from, and have widely proliferated because, the=20 procedural cost to create a new URI scheme is extremely low. You just=20 write some URI handler software, and optionally register that string=20 ("svn", "callto", etc.) with your local operating system/operating=20 environment. The difficult hurdles that the IETF set up for permanent=20 URI scheme registrations? Forget about them: just define and go. That is = why the IETF transitioned to provisional registrations [BCP35]. We need that same agility ("generativity") with rop identifiers. I am sensitive to the need (as you + Juha pointed out) for long-term=20 stability. I believe that the proposal addresses those needs.=20 (Hint: OID-op...) Best, Sean --------------ms030704060304090101030206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjYxMzEwMTJaMC8GCSqGSIb3DQEJBDEiBCB5t6jVtNBZeFQ0Vy2SsPQSUNy1zRvUvJJc167c 6pqnczBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCSNUoZTH1yFrMHpL5V tIlhRQLwNLPXHQS8uYCClVgh6hk+lw8Hv1VqOaJpVFv+t+/aFI+bZJLxlnigdKmZVZRHcP+K ZWLgv2Ms0V4wLlixDMqCeZp8jonmMo+VGn60XslU+al9Bt5/cH25IZIPS1vvMg+ADK+sPu2z i0RaD/jTXt/P5tK3n1hj9hzx5DQ21FsycYwEIlIcZwJEvJpYA6xLVs0TBhv1DUYSa0qe/k9S VjDVXKyZwhOZJi9MN4oLb8b1mwxIGt6a/CHbsWzg9x16C1tOvPD0OW5pxKZe6kf8rGbxHh14 DYjFaQm5J2N57hUyrsBoO5uD+RttLq+ivTp4AAAAAAAA --------------ms030704060304090101030206-- From nobody Thu Nov 26 05:32:22 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887DE1B3997 for ; Thu, 26 Nov 2015 05:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixXpLoyhylRo for ; Thu, 26 Nov 2015 05:32:19 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B741B3996 for ; Thu, 26 Nov 2015 05:32:18 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 24225509BF; Thu, 26 Nov 2015 08:32:17 -0500 (EST) To: John C Klensin , Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <8AFFBCF5137C419306BCE006@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56570965.2080807@seantek.com> Date: Thu, 26 Nov 2015 05:30:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8AFFBCF5137C419306BCE006@JcK-HP8200.jck.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090401030304000401090005" Archived-At: Cc: urn@ietf.org Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 13:32:20 -0000 This is a cryptographically signed message in MIME format. --------------ms090401030304000401090005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable One other thing: On 11/24/2015 12:26 PM, John C Klensin wrote: > --On Tuesday, November 24, 2015 02:19 -0800 Sean Leonard > wrote: > >> We need to strive for interoperability when defining >> r-component. [...] > [...] What is specified is where they are > interpreted, not what they do, [...] > >> At a minimum, r-component needs to tell what the resolver to >> *do*. For two implementations to interoperate (or provide >> interoperable functionality), they both need to look at the >> r-component string and isolate the part that says to do >> something, and to interpret that part to do the same thing >> between the both of them. > I think that is true iff one requires that it be possible to > apply multiple, independently-developed, resolvers to the same > namespace and expect to get the same result. That was not a > requirement of 2141; if we have made it a requirement in > 2141bis, I suggest that was a writing/editing error. Maybe this is just my hard-nosed, pragmatic American utilitarianism=20 speaking. But I am a pragmatic American, and an engineer, so I like=20 making things that maximize utility. :) A standard can be phrased only to impose requirements on parsers. In=20 that case, parsers can interoperate. A standard can also be phrased to=20 impose requirements on resolvers (things that turn the parsed data items = into something else). In that case, the resolvers can interoperate, and=20 the things before (parsers) and after (URI-dereferencers, media type=20 handlers) the resolvers can interoperate with the resolvers, because=20 resolvers have at least some well-defined interfaces in and out of them. When we (and by "we", I mean, the text of the URNBIS draft/standard)=20 separate the query and fragment productions from the assigned-name,=20 syntactically, we are saying that they are different, semantically, and=20 are to be processed with different implementations (or parts of=20 implementations) that follow other standard conventions. By making f-component act like fragment, in at least some instances, we=20 are saying that at least some implementations are supposed to take the=20 other components, and return one or more instances of Internet content=20 (Internet content =3D Internet media type and data stream, aka=20 Content-Type: header with parameters). Because fragment is defined by=20 the media type. By making q-component act like query, in at least some instances, we are = saying that at least some implementations are supposed to take the other = components, and return one of more instances of URIs (URLs), so that the = q-component can be smushed into the URI (URL), so that the URI (URL) can = be dereferenced. Therefore, if we want to work,=20 interoperably, we need to make it so that, /regardless of the particular = resolver implementation/, ?loginid=3Dseantek and #section2 operate on the= =20 same results (or sufficiently similar results, given a similar state of=20 the network). I do not find imposing standards on resolvers to be outside of 2141bis'=20 scope. Maybe it is feature creep, but the motivation for imposing=20 resolver standards (i.e., interoperable resolver behavior) is implied by = how we are defining f-component and q-component actually to make some sen= se. Sean --------------ms090401030304000401090005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjYxMzMwMTNaMC8GCSqGSIb3DQEJBDEiBCBzNhvPzKkeBDsl+MBFRRUUbWNQonLnZ6BNRhCR 7/u/0jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQDATQZA5LE6Gq3yVSWu Tfb5B7shdsbOOoFWRcjlL1oWPiX03WqtAoVp4dr/e1BPyDJtGJO21z3eCrSXRof2vT1VQBVg 4F2GDGSEzPa5JHu6S25xUy/Q4JqUxakN17a/g9FokBxsQitv+im7DmNvaa/Fiww72b5EM0wL R0znJTI4N9rs09k7+veNPZNTnEOq8e4PYsejH00DgMQqsBgbRN89Y4GvcvFn2OW3vGXE8e5k Gk0WowQPB6PNTAQSzcUsp2XIYRSFgz6nACYNU4BSban1/quU6rGti3SyZc62T6wrayfpMpxG 5yg1O5Vm/nrGYFbD1oGaHt7X4weoqdkZj7U4AAAAAAAA --------------ms090401030304000401090005-- From nobody Thu Nov 26 05:49:14 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F461B39C5 for ; Thu, 26 Nov 2015 05:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm4cxoYSL2-m for ; Thu, 26 Nov 2015 05:49:12 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC2F1B39C4 for ; Thu, 26 Nov 2015 05:49:12 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0BD45509C0 for ; Thu, 26 Nov 2015 08:49:10 -0500 (EST) From: Sean Leonard To: "urn@ietf.org" Message-ID: <56570D5B.6030806@seantek.com> Date: Thu, 26 Nov 2015 05:47:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060308050407030504040402" Archived-At: Subject: [urn] Consensus check (novel): q-component is URI scheme-specific? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 13:49:13 -0000 This is a cryptographically signed message in MIME format. --------------ms060308050407030504040402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable This is a consensus check (possibly novel) on our understanding of=20 q-components. A urn: URI is parseable into the following components: "urn:" NID NSS "?" r-component q-component "#" f-component (Forget about the specific order for the time being. The list above is=20 unordered.) The q-component is a string that is transmitted to the "resource" that=20 is identified after "resolution" takes place with the "URN resolver". Thus far we have been very handwavy about how q-component gets smushed=20 into the products of the resolution services. Said products could be 0-n = URIs (URLs). So, some post-resolver component (likely, the client urn:=20 URI handler) gets to smush them together. Is it the case that the act of "smushing" is URI-scheme specific?=20 Consider a resolver that takes urn:isbn:9999... with a q-component of=20 "userid=3Dstudent@edu.edu". The ISBN URN gets resolved to an https:// URL= ,=20 and the point is that the userid q-component gets appended to the query=20 string with "&", consistent with current practice. But if the resolver returns things other than https: URIs, maybe the=20 handler should smush them together in different ways. For example in an=20 LDAP URL, the q-component should be sub-parsed into [attributes],=20 [scope], [filter], and [extensions], each of which is piecemeal appended = to the [attributes], [scope], [filter], and [extensions] of whatever=20 LDAP URLs that are returned by the resolver. The act of "smushing the q-components" might be categorized as: ignore replace append prepend sub-parse and distribute special Of these, ignore, replace, append, and prepend can be done without=20 scheme-specific knowledge. "Sub-parse and distribute" requires=20 scheme-specific knowledge that can be encoded in a limited-purpose or=20 regular grammar, for example, "parse the & characters, match the =3D=20 characters, and intersperse". "Special" is a generic catch-all that is=20 obviously scheme specific and would likely require an executable=20 language specification. I am not proposing any solution to this (although one solution, if you=20 want to have one, is to make q-component have a URI scheme parameter,=20 such as HTTPQUERYCHARACTERS MAGNETQUERYCHARACTERS=20 LDAPQUERYCHARACTERS). Just making an observation. Sean --------------ms060308050407030504040402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjYxMzQ3MDdaMC8GCSqGSIb3DQEJBDEiBCAX44jtSv3vLEV+CFBc263PLZrYymcA3jhW5ai8 ZfzOdjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQAvSJW7Gal+CcoYk8cp yMJ9peQGg7WjubYAsoB46VbthQTJ8/sT1KBcjLXzcum0/x10OTnxOlsO0iZ8GPQpMm5BVFFv 3tf+TCGaTLq83WGuL0XsI/xemovePizuKwghvXCewJlQYt0RvNTovl/P9eLWguiK2sf8ksUg oUBXlgOV/05OR6MifjYnLPFG2FvX09ds20sZRJygWTujrBxdL0f9gK4lVUyBP0MPwcoufcOt uM9+n0DwckQJEnDNz7l+zKsT6U/oLk75oK5qMVu1eTmlo15qJIEP+9JUv9r55lHNEluErzyr qIoYISNxLJh3KJQ8DfH8g9jQ1/Blv1yLQ+gFAAAAAAAA --------------ms060308050407030504040402-- From nobody Thu Nov 26 06:57:56 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5F21B3A95 for ; Thu, 26 Nov 2015 06:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgVEnIODIlOs for ; Thu, 26 Nov 2015 06:57:52 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728291B3A96 for ; Thu, 26 Nov 2015 06:57:52 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8B8C0509BE; Thu, 26 Nov 2015 09:57:50 -0500 (EST) To: "Hakala, Juha E" , John C Klensin , Andrew Newton References: <60B469D695E665471E54CE0C@JcK-HP8200.jck.com> <564FC0E8.9090705@seantek.com> <565439C3.9020604@seantek.com> <5655CE83.4090505@seantek.com> <511B2246A91C5D3CA4C83986@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56571D73.60706@seantek.com> Date: Thu, 26 Nov 2015 06:55:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020908070206010307080802" Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] urnbis 14-seantek text (incorporates discussions) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 14:57:55 -0000 This is a cryptographically signed message in MIME format. --------------ms020908070206010307080802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hello, On 11/26/2015 12:42 AM, Hakala, Juha E wrote: > [...] > > Just to illustrate the problem: Sean has defined resolution service "in= fo" (without parameters) with which it would be possible to request metad= ata (that is, information) about the identified thing. > > This might work in an environment where there is just one system which = holds relevant information about the thing. But for instance my library h= as four systems: national bibliography for descriptive metadata, digital = asset management system for the documents themselves, license database fo= r rights metadata and digital archive for long term preservation purposes= (and administrative metadata). So it is essential to define what kind of= information the user wants, [...] > [s & p discussion] > > So in the community I represent, just asking for "info" will not do. Ou= r resolvers must know more precisely what the client/user wants. This is a good illustration of the limitations of generic keywords such=20 as "info". Not only is "info" pretty generic, different constituencies=20 will vie for using the generic keyword "info" as their One True Keyword, = and will attempt to foist complexity into (industry-specific) params. The first-order solution (per -14-seantek) is to make rop registration=20 extremely easy, so that different groups can define different rop=20 identifiers that work for them. If you want the results from the=20 national bibliography for descriptive metadata, use a rop identifier=20 that specifically asks to get the national (presumably, Finnish)=20 bibliography for descriptive metadata! The second-order solution is to make rop identifiers non-contentious.=20 Everybody wants "info" (or "license" or "buy" or ...etc.) because it=20 looks nice. Just like domain names: everybody wants hotels.com because=20 it is mnemonic. (Almost) nobody is going to fight over=20 0.9.2342.19200300.100.1.5 (the OID for favouriteDrink), except, perhaps, = that they wish it were shorter. So use OIDs, and make the OIDs as short=20 as you can get away with. The third-order solution is to make rop definitions easy to implement. We need to avoid the "commonName" problem that plagued/plagues=20 X.509/PKIX. The nice thing is that 2.5.4.3 (the OID for commonName) is=20 that it is short and well-known. The bad thing is that defining new=20 attributes in X.509/PKIX implementations has been traditionally very=20 hard. Among other things, you have to define the ASN.1 attribute format, = and even the default DirectoryString was no walk in the park. So,=20 everybody shoves semantic junk into "commonName", such as the name of a=20 web server, or worse, "the only thing that a user ever sees", so if you=20 put in "Bill Gates" all of a sudden you enable spoofing attacks. In general, I am in favor of very basic regular expressions, and things=20 like HTTP redirects. For example, the rop for "national (Finnish)=20 bibliography for descriptive metadata" can be defined as: rewrite the=20 URN to http://bibliography.fi/urn/{URN-assigned-name}. The end. Basically this makes the URN resolver pretty dumb, requiring more smarts = during URI dereferencing (e.g., an HTTP server). Problem solved by=20 indirection! As long as it gets out of the URN resolver step, I am=20 happy, and the HTTP industry (which is huge and deals with this sort of=20 thing all the time) will be happy too. > [...] deciding exactly how much (and what) we need to say about r-compo= nents in rfc2141bis is not going to be easy. [...] Trying to incorporate = that too into 2141bis would delay us a lot. Besides, it would be good if = other persistent identifier systems use the same resolution service names= and parameters as URN when possible, but it will be harder to convince t= hem to do that if all r-component related information is "hidden" in 214= 1bis. We have a concrete proposal on the table: -14-seantek. So take a look at = that. If it says too much, we can trim. If it says too little, we can add= =2E In this feedback, I am hearing a call for URNs to reuse another=20 persistent identifier system. In a prior feedback, John K expressed=20 concern about "normative dependency on X.660"=20 . Let's get it out in the open: if you want to reuse another persistent=20 identifier system (with or without parameters), you're going to have a=20 normative dependency on it. So: "work it out." :-) Obviously my thumb is on the scale for Object Identifiers [X.660],=20 because they actually work, and are deployed. But I have proposed an=20 extensible syntax in -14-seantek that permits other schemes. (Note: In -14-seantek, the use of percent-encoding in alpha-op is=20 prohibited. I did not want to get into the hazards of UTF-8 encoding and = Unicode comparison. It's just not worth it. You already have to deal=20 with that stuff in the NID / NSS component anyway.) > [...] > > This level can be reached by r-components like "info&dc" or "s=3DI2C&p=3D= dc" which specify exactly what is being requested. It is possible to add = even more details; for instance, r-component like "s=3DI2C&p=3DMARC21&lev= el=3D5" means that the client wants a complete MARC 21 record, not an abr= idged one. Not much to say here beyond what I have already said...all that can be=20 encoded in r-params, or in different rops, or both. I did want to point out, however, that r-params (in -14-seantek)=20 specifies a very specific data model: unordered map of name/values pairs each name has an ordered list of 0 or more values each value is a well-formed Unicode string, plus possible $ or +=20 characters, with reserved purposes This data model can be represented straightforwardly in the common data=20 formats: JSON: object (key =3D name string) -> array of strings CBOR: map (key =3D name utf8 string) -> array of utf8 strings ASN.1: SET OF SEQUENCE {name UTF8String, SEQUENCE OF UTF8String} XML: fragment of=20 TEXTTEXT......... etc. > =20 >> I believe that even the third case implies a dynamic registry >> that every "resolver" can check in real time. [...] > A global dynamic registry will be too difficult to build. There are so= me limited areas where useful things can be done. For instance, we can ha= rvest configuration information from libraries' SRU servers, and map them= to r-components in URN resolvers. I do not think that a global dynamic registry is a goal of this spec.=20 But, I also do not think it is too difficult to build. If we have a global namespace of rops (whether OIDs, or alpha-ops, or=20 other things), then we can use the DNS: ._rop.urn.arpa which has a resource like a regular expression. For example, the rop for = "get the national (presumably, Finnish) bibliography for descriptive=20 metadata" can be 1.3.6.1.4.1.11.9999, in which case, a regular=20 expression would be stored at the DNS entry: "1.3.6.1.4.1.11.9999"._rop.urn.arpa that would rewrite the assigned-name part to=20 http://bibliography.fi/urn/{URN-assigned-name}. That is not proposed for all rops...but it will work for a significant=20 fraction of them, and is consistent with the overall philosophy of DDDS=20 [RFC3404]. Notably (unlike DDDS), it is namespace-independent, which is=20 (I think) what Keith Moore wants. For more complicated rops, an=20 implementation can do correspondingly more complicated things than DNS=20 lookups. > >> (i) requires only that we define the internal syntax of r-components. = That is >> not impossible, but something we have avoided so far. (ii) and (iii) = imply that >> we need to standardize and create a keyword (or element) registry. > From rfc2141bis point of view, specifying internal syntax might be wit= hin scope. But I am not sure if we are ready yet to do that. Trying to s= pecify keywords (elements) and their parameters a'la RFC 2483 is not prac= tical. As illustrated above. And hopefully solved too. > After URN syntax has been modernized, we should outline a mechanism w= ith which the registry is maintained. Maintaining registries is...something I am not in favor of. For reasons=20 outlined above. Mainly, it's too contentious. That is why in=20 -14-seantek, I proposed "RFC Required" (but not IETF Consensus) to be=20 the standard for new alpha-ops. Something to think about. (Obviously a=20 registry can still be maintained.) > Service mnemonics from RFC 2483 could and should be a starting point=20 > for creation of this set. In addition to that we need parameters, such = > as metadata formats for I2C and I2CS.=20 Good things to include in another RFC, hence RFC Required. >> (b) Making a lexical distinction, either between standardized and name= space- >> specific elements (while the latter would not be in any sense "experim= ental", >> a review of the IETF's experience with "X-" headers and keywords and/o= r the >> boundary between public and private port identifiers would probably be= >> helpful in considering that option) or between two types of r-componen= ts, the >> ones that are expected to be generic and well-defined across all names= paces >> for which they are meaningful and the ones that >> are considered namespace-specific. Independent of the syntax >> chosen (including ordering), that takes us another step down the path = from >> query to >> q-component, r-component to >> q-conponent, r1-component, r2-component >> >> and I have to wonder whether it ends there or there are still more div= isions >> possible. > Both services and service parameters can be experimental or internal. F= or instance, requesting information about things is going to be one of th= e most common services, but this information may be available only in a p= roprietary or experimental format. > > Experimental services may eventually become commonplace, so we need a m= echanism for upgrading the status of a service or a service parameter. An excellent set of reasons to use OIDs. Anybody can mint a OID, and if=20 a OID catches on, the OID gets baked into other=20 products/configurations/standards. > When it comes to creation of smart URN resolvers in general and r-compo= nents in particular, nobody "has gotten there" yet. Other PIDs, most nota= bly ARK and Handle, do provide some resolution services, but they have be= en implemented in a manner which cannot be utilized with URNs. Correct me if I am wrong, but -> -> resources seems to be a common trend in this space, no? I=20 am thinking of https://dx.doi.org in particular. > > There are no existing URN implementations with features discussed here.= But there is an increasingly sophisticated technical environment with wh= ich electronic resources are managed, and URNs must fit into it. Librarie= s, archives and museums develop and maintain some of these systems, and i= f there is anything that makes us different from many other organizations= active in this area it is probably the need to preserve digital resource= s for very long term (decades or even centuries). Persistent identifiers = & functionality based on them will be essential in this work. I think we are getting there. Best regards, Sean --------------ms020908070206010307080802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjYxNDU1NDdaMC8GCSqGSIb3DQEJBDEiBCCWpvjvFX4g4H4+kGCMppR7Owg9M6ToI7qcbx1H dbj4BTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCSUWeqb2hNwT5cv2z4 3TPEO8HkQQGTgqRVSSf6Q9EoyLjhX3YrvB/G2NzhtiX3OMG0p9JWkI2jtitnANWld68QAaxB DbKnRPO4TsRSc5424iS8wOZnS8LnCxPgNIpwCfZmPZk6+BDCbW4C3b7WIXAI+FkMQi1/Nsfm V8E7KzCHOHm5wTpFxpb9MPXOBCD6UtcW3LVKmV1/XDtclZWzLwlS7PQQg2L5tZul35yyTPj4 4kaFF9L7Z9Lg0k9Tqcn1oi3G6qMgRHzOqno5z9cITSCH6z0Zin7AVm/p9TC/MFhEKo6lvWm9 jdd+1XOgA2prlE+hS4RDV4IpbL4PLJAqYXizAAAAAAAA --------------ms020908070206010307080802-- From nobody Thu Nov 26 09:39:55 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BB91B2CCB for ; Thu, 26 Nov 2015 09:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXOa-srAxO1b for ; Thu, 26 Nov 2015 09:39:53 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E971B2C12 for ; Thu, 26 Nov 2015 09:39:53 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 60D46509BE for ; Thu, 26 Nov 2015 12:39:52 -0500 (EST) To: "urn@ietf.org" From: Sean Leonard Message-ID: <5657436C.6010305@seantek.com> Date: Thu, 26 Nov 2015 09:37:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000507050207020009060309" Archived-At: Subject: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 17:39:55 -0000 This is a cryptographically signed message in MIME format. --------------ms000507050207020009060309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello... According to: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-04= =2Etxt Sometime between Draft 4 (October 16, 2012) and Draft 5 (November 27,=20 2012), UTF-8 encoding got removed. I guess that means that now it's up=20 to the namespace to define what encoding is used, if any? (Unicode is=20 still mentioned, but the relationship to percent-encoding is absent.) What is up with that? Just want to know if that was a conscious choice=20 by this WG, or what happened. Regards, Sean --------------ms000507050207020009060309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjYxNzM3NDhaMC8GCSqGSIb3DQEJBDEiBCBf37dhsqDbhIR1IIvzSkgKGwKqhI/gqcdLX/2f vBX2pTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBYElPvFzdSPXws2qHl SI86Y/N6tLTdRGST2T2lutl5O00JYx8imi46wkGCVAgOXYQUR4pETT30nF071C2Hs93c4NdD evaY2x3TLfs0OdJlx9X+wdFjpTb1hiVEcATo6BeOfCBCif3aQ1HgYXXzfsFqTv4K5e27yqWl uEIBbc6Xl5qkbMFHbW1ibaLHUj2RrVYE2n5nG2ikkZ91wdlnXoUQuV5bCBwA7ga/0viJ6Qdz OQQQ/Khj5Yc0xPMVeMvXAKuM4Qy2GSNkxXAFfr4l9eg4xDHK7MJO4u+RAt/hKgFZNyTo/6nb DbyCXhDdTmEbaFLgiUQd8ksPqdtfFGoa5CIYAAAAAAAA --------------ms000507050207020009060309-- From nobody Thu Nov 26 10:40:53 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E1C1A6F01 for ; Thu, 26 Nov 2015 10:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYlEa6YFd28g for ; Thu, 26 Nov 2015 10:40:50 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A3A1A6EFE for ; Thu, 26 Nov 2015 10:40:50 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a21TN-000Aa3-8N for urn@ietf.org; Thu, 26 Nov 2015 13:40:49 -0500 Date: Thu, 26 Nov 2015 13:40:44 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <2F64E65B3323F1C14FB5DDE8@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] FWD: Last Call: (Changing the Registration Policy for the NETCONF Capability URNs Registry) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 18:40:51 -0000 Because this is about a change in a registration policy for a URN, I think participants in this WG might want to look at it. Or not, but those of you who don't follow IETF-announce have at least been warned. john ---------- Forwarded Message ---------- Date: Monday, November 23, 2015 06:00 -0800 From: The IESG To: IETF-Announce Cc: bclaise@cisco.com, draft-leiba-netmod-regpolicy-update@ietf.org Subject: Last Call: (Changing the Registration Policy for the NETCONF Capability URNs Registry) to Best Current Practice The IESG has received a request from an individual submitter to consider the following document: - 'Changing the Registration Policy for the NETCONF Capability URNs Registry' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The registration policy for the Network Configuration Protocol (NETCONF) Capability URNs registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well reviewed Experimental RFCs, in addition to Standards Track RFCs. The file can be obtained via https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-up date/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-up date/ballot/ No IPR declarations have been submitted directly on this I-D. ---------- End Forwarded Message ---------- From nobody Sat Nov 28 20:06:41 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDD11AD2F2 for ; Sat, 28 Nov 2015 20:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlItiDipQ4ua for ; Sat, 28 Nov 2015 20:06:38 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0094.outbound.protection.outlook.com [104.47.126.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9808A1AD082 for ; Sat, 28 Nov 2015 20:06:37 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [192.168.1.3] (60.42.129.117) by KAWPR01MB0130.jpnprd01.prod.outlook.com (10.161.27.11) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sun, 29 Nov 2015 04:06:33 +0000 To: Peter Saint-Andre References: <5657436C.6010305@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <565A79C5.3070405@it.aoyama.ac.jp> Date: Sun, 29 Nov 2015 13:06:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5657436C.6010305@seantek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [60.42.129.117] X-ClientProxiedBy: TY1PR0201CA0003.apcprd02.prod.outlook.com (25.164.90.141) To KAWPR01MB0130.jpnprd01.prod.outlook.com (25.161.27.11) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0130; 2:1+1aYAFCL5F4SD5UduyIwHuH7uxozxAkxJMUO4aFnHjL07sY+nztP1JFgUX/bb0bzIa3Vo4WbmEnzgVsuEMVHMQN0WUdI34iQZhkRhYh7lkos7vHFYY7O8hn3Ko2liSfJmR87pIRL6YxVAPpBy/u8w==; 3:im9CGuJB5JpYHezTtU3T+ToFy+2QbstPY9S/Xif6dF/u9P3m+R2weA4HyK5SlTFKkRXDOhbsbiyi0i7mcxbWFxgQyUsd3919KWcbL7BpOmRj5Y804GB8K28z4fN1Yl9D; 25:8WrAgQTua8ZBLOND8OVmYIbgrF5wfmi8u+17dfr76eMzhpyrsQ1JBFpuRQLGIGtQ7HkKE6yr5VRuVpB/Xnz2J8aJljZSq0D/6ix6w4ZlIHAOZSN9FEIbKELhGKKfSIygT+985SlxIcNCol9WF8FRrSh3N942ksEldCLPV13NPKfLKxpTgd4s5RYwgn8FnWyx/C1CKD5SNooWhDDtpStijGO+aDlILe+X+BtPLd4npKDdYtJqf/ptUTFYr77gJBZSRJfdDxSZ4UapJr2fgAzG5w==; 4:skueO2P4QSASuuurT6E8eTeWPupJhG2j1gUqd4WLrarrI+XU+IzWr6NbyrxqOic4stl5ryDNOEytEfHc8Ad3wE5j81eHmLmX/1Z1ABo3X6muVY5cH75Dq+942KM15LdmykyPHoztCU7OfkQ4YRk6FRDMxqQwahV5XgFOtz3q4aCEVUWJuHqF8KxuTs2CokiLAiYdpi/LcEEMWODGoT7eKQbOu5lmql6uZg1GigfYyplFAaPOJLnHVhrPAeImcI+77f2R7+RpUi7D8Z8ygDC6elCaxG+JaagnoXo8Aej/5JdXrnAr0oReePAasLOYQLuJK6QVOdGlVZcb3YuNEyrWcVBE3y4SgkS+mIFp0vcitjh9f+ZutYCdDMducGhPWDx5 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0130; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:KAWPR01MB0130; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0130; X-Forefront-PRVS: 0775716B9D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(24454002)(199003)(479174004)(23676002)(83506001)(50466002)(586003)(101416001)(15975445007)(50986999)(42186005)(54356999)(5004730100002)(81156007)(77096005)(87266999)(1096002)(76176999)(65816999)(87976001)(33656002)(2950100001)(189998001)(97736004)(40100003)(5008740100001)(3846002)(74482002)(64126003)(47776003)(92566002)(106356001)(4001350100001)(105586002)(6116002)(117156001)(59896002)(86362001)(110136002)(65806001)(80316001)(19580395003)(19580405001)(65956001)(5001960100002)(66066001)(122386002); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0130; H:[192.168.1.3]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTMwOzIzOnVWWDFDVEFpTEVqTDM0M1pRTDNWYWUxOHg3?= =?utf-8?B?VVhkaU1GeUdUSDB5cXFRQTdtYUl3STFQWnIyQk9LRGg1RmEzQjBqUUpFRVZT?= =?utf-8?B?Z0dpV3JhL2RNd2JNZDZKcE9EamxPMkN5Y3hVOS8xVjMveklkcGp4WUY3TnB6?= =?utf-8?B?Z2VsdWdxVlo2cFg2L2RFYldXdlFSSlZHWTRGNkQwV2dlRW9KMjNkc0YyNkNC?= =?utf-8?B?SWdDYk1WOEdBQXkvU1dTVFAxZ0Rxb0EwL1ZQVUFhdjV3RmtGUTBrYnlUM0Ry?= =?utf-8?B?cTMvT1dzWVN5OGU4LzB5cGJQdWVJWUFDZ0lkZ1RqOGt2TERXWmp2ampydkVG?= =?utf-8?B?SEV4MWNJUEFuaXc2cHRqOHc3a3U1T09tSHVaK2wwSHdtR1prL3BzK1dFeGEx?= =?utf-8?B?dnArRmFyaW9qTjl5Uk5mNUVIQ1BHSUZ3UW9ra1dtcEozeHo2aHBsWHJST3V4?= =?utf-8?B?UFlWQXV2alRhS3hWYkh6ZStyMUZaOVR6TjB0WHd2N2ZLVnZCdlJENUtsSVk0?= =?utf-8?B?Z0RqY3U0RVBUb09TWE5nT3NUc3Fid09qa24wTzUwMmQ4ZzVwNEgxb1pXTFA3?= =?utf-8?B?L3pLSFJkMGQzRUg4RUl5clBVcWZmbWEyeWhHOXZjRk1XdGtibGQ0NlR2eXNB?= =?utf-8?B?b0JvZS9FSEE2NWVBME9oZXFlMkhodFhhWWp0a3Yvbjl5alJWVndjc2FwZ1NV?= =?utf-8?B?RGZGazlBd2N1ZlhxTy9WbzBMSVFXTkwxOUp2eGpBczBaSjVHREhPeGtmNiti?= =?utf-8?B?SVgyTXNnbW0xMFhXMmUwR00zazNrWjYwSDUzSm1lQVJxYWlRQmJ2Q3pKT3Iy?= =?utf-8?B?OXpmck8vcDRCVDl2Z1ZNK3ZmTUh5YnRjaCsxK2xPZmVMNHBvcCs3VE0xRGpl?= =?utf-8?B?ZWFRY3RsUWtzb0RzeGVnc2I5OWxjOU9NUDlvVlppYzZyOTlrbjYvbWVlRyti?= =?utf-8?B?Y1RUTG1RNzhERzIwMC94ZHh3Tk93N1d3dU5WUWhxVVJOeUdJUXE5UEVVYU9k?= =?utf-8?B?NThTZVp1NzZIMDVrVmJEREhPWWlNeXlnK0hJRHp6WFA1SCtQVXUyKzJVdnB6?= =?utf-8?B?eUtBbzRxWVBCS0RiNHdKQVhKV3BBdWRqTFZPMytYa1VxeUg3Q1cvT0xYNDE3?= =?utf-8?B?a3JORk93NlhldlNKUi9WQnVYcWZ3MVV5TGVveStiQTBwWGlDN3pPOE1uTGVO?= =?utf-8?B?QXI3SExhYlY3SzN1UkQrMnFjQmpabTI0dXFzSFNHSUExTlZzcnZqa051eC9j?= =?utf-8?B?Ky95VndoLzYyTjgvOUVkYk8wZ1JBUzVJKzRkY1Q0QzQ1T2tmQ3dGUS9BQno1?= =?utf-8?B?bzk5V2pJWVJhWEJ5SC9jckcrWkVzTGFML1pTYUEzTm9ySWw3VGdGcTUzMzBs?= =?utf-8?B?bUlpYmJla0FLS2tmdEhQeG90UXIrVWM1dHZONHp3aXhZL3NEWHZkNHJHTklR?= =?utf-8?B?SVk4YjVTbUI3Z2N2Vm1JRUl2dWRiVjJ3SXZ1TDRaR3pCcmErN2tGcDhhRGYz?= =?utf-8?B?clBRbFlpbWF0S1RUeXVjZEV5MEFYbnRoaE02T0cwWUUvTzJCSDNkSk5kbFJS?= =?utf-8?B?b2ZUbXRhSCticzRnYXQ5aHBjamhWckZVZ0tNUEFYUW9lL2NabXM4eGRQdENy?= =?utf-8?B?WkdKaFVaRjdseGtCYTdrL21vaXBPWGpGSmRyVkF5ckFDVHBzakpCNDIwV0Ny?= =?utf-8?B?SnFDZDdrS2pGQzNYbkJwVFJKc3doUHJuTlQwZVVVQWNzdGtvZjFtWXN4ZWNq?= =?utf-8?B?YW5UK1JTK0U1VFVkcmJCQT09?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0130; 5:O/PvssN1WFpl/TArk+jSc459SR6v9EfBgbXEwqZdWT5icRgGKXqmCdfNUTbdpSsWlSkMpKa7j4kcq+76xI1O2q3MayAo1klZl/63z3aAtrBAt/9++jmr59z2QhIMGMKoMDe9smcsjf261Exzm6/wYg==; 24:EQU0Ii9ufQdaKMNkfJUVgYGRXP+oCVo1/b6dk//ngq3Q6UNSHPHMtXO0bGqJ/kBAxlyRrw2UBsxu/97W5++vDSJHKrlceZJyT8xGsqF8214= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2015 04:06:33.2732 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0130 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 04:06:41 -0000 Hello Sean, This is a very good catch. On 2015/11/27 02:37, Sean Leonard wrote: > Hello... > > According to: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-04.txt > > Sometime between Draft 4 (October 16, 2012) and Draft 5 (November 27, > 2012), The dates are correct, but it's draft 3 and draft 4, as the diff URI shows. The change happened with a change of author/editorship from Alfred Hönes to Peter Saint-Andre. Probably, Peter can explain best. > UTF-8 encoding got removed. I guess that means that now it's up > to the namespace to define what encoding is used, if any? That would be a very bad idea. UTF-8 was explicitly put into RFC 2141 to avoid useless/confusing variability for namespaces that originally contain non-ASCII characters and therefore need to be mapped to US-ASCII. This definitely should be fixed asap. Regards, Martin. > (Unicode is > still mentioned, but the relationship to percent-encoding is absent.) > > What is up with that? Just want to know if that was a conscious choice > by this WG, or what happened. > > Regards, > > Sean > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Sun Nov 29 08:53:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7E21A03A5 for ; Sun, 29 Nov 2015 08:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.101 X-Spam-Level: **** X-Spam-Status: No, score=4.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdcNLYskBHqH for ; Sun, 29 Nov 2015 08:53:14 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8C61A03A3 for ; Sun, 29 Nov 2015 08:53:14 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a35Dr-0002Mt-J0; Sun, 29 Nov 2015 11:53:11 -0500 Date: Sun, 29 Nov 2015 11:53:06 -0500 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Peter Saint-Andre Message-ID: <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> In-Reply-To: <565A79C5.3070405@it.aoyama.ac.jp> References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Cc: urn@ietf.org Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 16:53:16 -0000 Sean, Martin, and others... --On Sunday, November 29, 2015 1:06 PM +0900 "Martin J. = D=C3=BCrst" wrote: > Hello Sean, >=20 > This is a very good catch. >=20 > On 2015/11/27 02:37, Sean Leonard wrote: >> Hello... >>=20 >> According to: >> = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141 >> bis-urn-04.txt >>=20 >> Sometime between Draft 4 (October 16, 2012) and Draft 5 >> (November 27, 2012), >=20 > The dates are correct, but it's draft 3 and draft 4, as the > diff URI shows. >=20 > The change happened with a change of author/editorship from > Alfred H=C3=B6nes to Peter Saint-Andre. Probably, Peter can > explain best. Agreed. However, my vague recollection is that there was an explicit WG discussion on that matter, probably tied up with the observation that the 2141 text was a little too close to the now-discredited "just sand UTF-8 and all i18n issues will go away" position. >> UTF-8 encoding got removed. I guess that means that now it's >> up to the namespace to define what encoding is used, if any? >=20 > That would be a very bad idea. Yes, no question about that, at least IMO. If any non-ASCII encoding it to be used, it fairly clearly should be UTF-8. > UTF-8 was explicitly put into > RFC 2141 to avoid useless/confusing variability for namespaces > that originally contain non-ASCII characters and therefore > need to be mapped to US-ASCII. I believe that is correct too. > This definitely should be fixed asap. Unfortunately, the fix does not appear to be as obvious as a sentence that says "any non-ASCII octets MUST BE valid UTF-8" in some appropriate place in the text. As soon as we move away form ASCII, we reintroduce issues with string comparison, normalization, and case-folding. Those issues imply a choice between increased risk or false positives or false negatives, potentially involving us with all of the issues that have plagued PRECIS in recent months and a requirement to revisit our comparison rules. Or course. we could be draconian about things and say that two URNs are equal only if the NID and NSS strings are exactly identical at the octet level, but that implies that=20 urn:XXX:somestring-in-NFD-form=20 will, in general, not be treated as equal to=20 urn:XXX:somestring-in-NFC-form Maybe that is ok, but, if it what the WG wants, I'd like to be sure before altering text. And, if it isn't what the WG wants, we need a plan. So "asap" may not be quite as fast as one might think at first glance. Peter? Andy? john From nobody Sun Nov 29 09:19:17 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBC71A6FD0 for ; Sun, 29 Nov 2015 09:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lriOhBIRPHc1 for ; Sun, 29 Nov 2015 09:19:13 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A67C1A1A7E for ; Sun, 29 Nov 2015 09:19:13 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 26E2A509BD; Sun, 29 Nov 2015 12:19:10 -0500 (EST) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Peter Saint-Andre References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <565B3314.5010302@seantek.com> Date: Sun, 29 Nov 2015 09:17:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565A79C5.3070405@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020500050705080805080103" Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 17:19:15 -0000 This is a cryptographically signed message in MIME format. --------------ms020500050705080805080103 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/28/2015 8:06 PM, Martin J. D=C3=BCrst wrote: > Hello Sean, > > This is a very good catch. > > On 2015/11/27 02:37, Sean Leonard wrote: >> Hello... >> >> According to: >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn= -04.txt=20 >> >> >> Sometime between Draft 4 (October 16, 2012) and Draft 5 (November 27, >> 2012), > > The dates are correct, but it's draft 3 and draft 4, as the diff URI=20 > shows. Yes, thanks. I think I got confused with the ordinal version of the file = (4th version / 5th version), as opposed to the cardinal number. > > The change happened with a change of author/editorship from Alfred=20 > H=C3=B6nes to Peter Saint-Andre. Probably, Peter can explain best. > >> UTF-8 encoding got removed. I guess that means that now it's up >> to the namespace to define what encoding is used, if any? > > That would be a very bad idea. UTF-8 was explicitly put into RFC 2141 = > to avoid useless/confusing variability for namespaces that originally=20 > contain non-ASCII characters and therefore need to be mapped to US-ASCI= I. > > This definitely should be fixed asap. Yes I agree 100%. Sean --------------ms020500050705080805080103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjkxNzE3MDhaMC8GCSqGSIb3DQEJBDEiBCAUhpGrjUkDRvQv2qO8PXAozN6jPn7mrGKwA/kO cD8PNDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCgWU4HqWn440ZOTUVX BHutTCGiX1C2TikU+1AlfSClF2NeCBF6OsDfSaFNAQBeN6Fw9SRyELmGLHI8aLw3qAhDIyPi gs40gvCSAdkH2pQNrLUuyy9dSsgiaX9xEeKYWRoURv59wOe0WMIt9Q6yScERilwgzbxifaNy lsQxy3AbmDRaFXH8t//kKEVndxkOcfbOU5Qv3PcAuSL0HZ4MLBaDyaNrPJ8hIIOzoGroDGn4 KemukoCrN6SLHIk5psi7XqgJrK4cNVF8qNOg1Kk0OgzqklrbNzZLtLFuu22dq6WFRchf5Ble he52+eWXp3THHJ8fAOpTZWNSw4v/TK+2Fb6JAAAAAAAA --------------ms020500050705080805080103-- From nobody Sun Nov 29 09:27:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EB81A90E6 for ; Sun, 29 Nov 2015 09:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J_mEoCFgPyt for ; Sun, 29 Nov 2015 09:27:27 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECD61A909B for ; Sun, 29 Nov 2015 09:27:27 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7895B509BD; Sun, 29 Nov 2015 12:27:25 -0500 (EST) To: John C Klensin , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Peter Saint-Andre References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> From: Sean Leonard Message-ID: <565B3502.5070402@seantek.com> Date: Sun, 29 Nov 2015 09:25:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070809080408020109080308" Archived-At: Cc: urn@ietf.org Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 17:27:29 -0000 This is a cryptographically signed message in MIME format. --------------ms070809080408020109080308 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/29/2015 8:53 AM, John C Klensin wrote: > Sean, Martin, and others... > > --On Sunday, November 29, 2015 1:06 PM +0900 "Martin J. D=C3=BCrst" > wrote: > >> This definitely should be fixed asap. > Unfortunately, the fix does not appear to be as obvious as a > sentence that says "any non-ASCII octets MUST BE valid UTF-8" in > some appropriate place in the text. As soon as we move away > form ASCII, we reintroduce issues with string comparison, > normalization, and case-folding. Those issues imply a choice > between increased risk or false positives or false negatives, > potentially involving us with all of the issues that have > plagued PRECIS in recent months and a requirement to revisit our > comparison rules. > > Or course. we could be draconian about things and say that two > URNs are equal only if the NID and NSS strings are exactly > identical at the octet level [...] It's really not all that complicated. The original standard RFC 2141=20 says it's UTF-8. Therefore anything that is RFC 2141-compliant will be=20 RFC 2141bis-compliant, if we keep it the same way as it used to be. Comparison of the identifier (aka, what hopefully now we can start=20 calling "assigned-name" uniformly) was always specific to the namespace. = Therefore things like Unicode case folding track existing=20 namespace-specific issues, such as whether the NSS is case-sensitive. Note that q-components, f-components, and (possibly) r-components need=20 not be UTF-8. This introduces some subtleties in smushing problems=20 (e.g., smushing q-component into a query component of another URI=20 produced by resolution) but those are not more complicated than the=20 ill-defined "smushing" operation itself. Regarding r-component: in=20 -14-seantek I was very careful to define r-params as UTF-8, rop as=20 ASCII-only (no percent encoding), and r-authority as whatever-reg-name-is= =2E Sean --------------ms070809080408020109080308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjkxNzI1MjJaMC8GCSqGSIb3DQEJBDEiBCD0LnGwybj+AxYZ5/6IedRj2lPSThiAo233qmN9 Unx9nzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBAj9rdnYi8KYWZRRP8 OBQQil9HkqQpl2+CIQJQooazrjXOSIKL9iHBtk1cpnNirxFBfaOHr8TlcJa1Xm/5kf6qCxcZ IEjUW4c/uu9GGTQRorrdFhG+42jN/oiO0xJOOowECmPDocKWSNQ3clIkInSYyR1NZBdFszyf kpksZDJNQc1wntJrm0J9n8XBJWQlsRTTW8eicaHYFqn5zgk1jEMb3qhzcq2zB3jHt19i0wXm 2Gs3B/7Cp2RwKxidORTPhvUNxkagY/+DY8OxPLWVBwVmq5GvQmzK/rKRgPMImv0MMOU3fMxs uCxlYsYTkbaJe8zKZiS5JldvHausuyz8+D6pAAAAAAAA --------------ms070809080408020109080308-- From nobody Sun Nov 29 10:15:50 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB41B3025 for ; Sun, 29 Nov 2015 10:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS8-dFB84lpC for ; Sun, 29 Nov 2015 10:15:47 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9071B3023 for ; Sun, 29 Nov 2015 10:15:47 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1B92520495 for ; Sun, 29 Nov 2015 13:15:46 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 29 Nov 2015 13:15:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=CEmtbewt3YzQHyN 7720SdA0kzbs=; b=gUu6lfcXat4cM8LFNcLiyY7lV61rHX8PH/vAx3IDOLM4aRA qvAq8L3Uz73l7uGxxmvpa6xcb51rarfIOzcqXiDV99xr4TyTuVEAuwRFbsUBr0te E/5am7UOAGOmu3IG05iXiDYnhaJILnRCyPiCvY7b3aIHpc1oHIEc6Sa74jew= X-Sasl-enc: MbIwQYkxLiA8DCwe6EyjK2QIJf7gXYDQM/m4VupE9j4Z 1448820945 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id A445268010D; Sun, 29 Nov 2015 13:15:45 -0500 (EST) To: urn@ietf.org References: <56570D5B.6030806@seantek.com> From: Keith Moore Message-ID: <565B40C5.9000508@network-heretics.com> Date: Sun, 29 Nov 2015 13:15:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56570D5B.6030806@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Consensus check (novel): q-component is URI scheme-specific? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 18:15:49 -0000 On 11/26/2015 08:47 AM, Sean Leonard wrote: > This is a consensus check (possibly novel) on our understanding of > q-components. > > A urn: URI is parseable into the following components: > "urn:" > NID > NSS > "?" > r-component > q-component > "#" > f-component > > (Forget about the specific order for the time being. The list above is > unordered.) > > The q-component is a string that is transmitted to the "resource" that > is identified after "resolution" takes place with the "URN resolver". Yes. (at least, that's its purpose, and it will work that way in practice for any URL scheme that transmits the query portion of the URL to the resource.) > > Thus far we have been very handwavy about how q-component gets smushed > into the products of the resolution services. Said products could be > 0-n URIs (URLs). So, some post-resolver component (likely, the client > urn: URI handler) gets to smush them together. In all cases in which the path to a resource is obtained via a URL, the q-component should become the query component of the URL. (if the resource is accessed via some other means, the specific means by which the q-component is used should be undefined for now. This leaves open the possibility for the use of the q-component in other resolution scenarios.) > Is it the case that the act of "smushing" is URI-scheme specific? > Consider a resolver that takes urn:isbn:9999... with a q-component of > "userid=student@edu.edu". The ISBN URN gets resolved to an https:// > URL, and the point is that the userid q-component gets appended to the > query string with "&", consistent with current practice. No. The q-component must not get appended to the query string with "&", because that presumes (without justification) that the resource interprets queries as if they were HTTP form data. The q-component must _become_ the query string. If the resolution service returns a URL that already contains a query, that query must be discarded. (The alternative is to declare this an error from the resolution service, and thus, invalid output - the client could continue by consulting a different resolution service.) There are several reasons for this: 1. The resolution service should not be in the business of interpreting user requests. This is a privacy and security concern. An architecture that permits the resolution service to interpret user requests (including q-components / queries) is one in which the resolution service can record such requests and/or filter those which it does not like. The architecture should not permit the resolution service to play the role of Big Brother. 2. The user, or the author of the content, is in a better position to know what it wants from the resource and how to request it from the resource, than the resolution service is. Burdening the resolution service with the knowledge of every resource's protocol is bad layering. > But if the resolver returns things other than https: URIs, maybe the > handler should smush them together in different ways. For example in > an LDAP URL, the q-component should be sub-parsed into [attributes], > [scope], [filter], and [extensions], each of which is piecemeal > appended to the [attributes], [scope], [filter], and [extensions] of > whatever LDAP URLs that are returned by the resolver. This is another reason that "smushing" the components is a Bad Idea. The sole purpose of the q-component should be to allow the user or content-author to send a query to the resource. The means by which this is done should be to copy the q-component to the query portion of any URL resulting from resolution. But for the sake of consistency and simple layering, this should be the behavior even if that specific URL scheme interprets "query" differently. That's simple, easy to define, and doesn't require URN clients (or for that matter, resolution services) to have specific knowledge of URL schemes or the ways that resources interpret queries. Keith From nobody Sun Nov 29 13:58:27 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34E31B359E for ; Sun, 29 Nov 2015 13:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_wyAZD84aLs for ; Sun, 29 Nov 2015 13:58:24 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3451F1B359A for ; Sun, 29 Nov 2015 13:58:24 -0800 (PST) Received: by obbww6 with SMTP id ww6so113703447obb.0 for ; Sun, 29 Nov 2015 13:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=HYXG5Tr24LjImSjaIbuZR3rQQWWgxGirZkdP70n0wAQ=; b=EECC3qyLEIXPOp8IVaHsNO+KNasEgWb0YIL1sle5c2oB5TmcbDNSC3KuXYAA3PXEXR RXEzZ2OSVr2DAm3uOdFmY3UXyQ3aiXb3IUMX8+YM4Xsq5J+tmMJQ8k+cm+lwwbjcI1JQ htKoCqDK+dKsPQSwcfXZRPWF0VQFIsrhFRMg9/uQ3VvvsBiC+R0ctVZQN//EkFdo5NPn +Ev3pizpCShh2S3aJviRi7Rhm6wVC4piV3N8c3Gbp+VP7u7/cL9se94qDjCP1o7x6dez cCFQ3PdMnwtrzP9XinfrJe9nfAXmzEcdJHkHUgr9t8lnXRp23z9M1dcndCw6Eqcn9jqG vdDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=HYXG5Tr24LjImSjaIbuZR3rQQWWgxGirZkdP70n0wAQ=; b=Flg8sNASqxqLtIm6WOPB6BMqe4cUoQ0GmRsOjFhhTCA+RkfVGOzoDJtqY2CVaaaem8 zw/5j/ogovGPfr5NYdSbb9+Qnie77ldGBdIscv2C1lzjYPlrr6XTFslz+GksWQqMqzP9 1YNGLK/jJu5mAe2vbI4l7Tg3NdE6fZ7GoSNXY5OpNdf5GhfKsxdrNtcFh7VN32fFhwUx cPG5lE3ELIb+KAKmfzGXT2ZM2EOzP7PYVMSD1ysHHxDKR4vIugI2+ZRBWD/1H6aRp4zL H3DtFCbQ00bPTEG20UTiqDSPTCrex98twLwMfSTcstbxgWthO19G0wJs+zpuzsb3u0WB UFHw== X-Gm-Message-State: ALoCoQn8CwsAmIsrnGuugXuU+sPCOzaiGMzNu/gKMV777jjh1HYmN2W1El73ZZp/Y5K4aL1//dEs X-Received: by 10.182.49.170 with SMTP id v10mr41418627obn.64.1448834303542; Sun, 29 Nov 2015 13:58:23 -0800 (PST) Received: from aither.local ([2601:282:4201:ef5b:15ef:2570:b7a3:4a47]) by smtp.googlemail.com with ESMTPSA id m8sm20063964obn.27.2015.11.29.13.58.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 13:58:22 -0800 (PST) To: John C Klensin , =?UTF-8?Q?Martin_J._D=c3=bcrst?= References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> From: Peter Saint-Andre Message-ID: <565B74FC.6070400@andyet.net> Date: Sun, 29 Nov 2015 14:58:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 21:58:25 -0000 On 11/29/15 9:53 AM, John C Klensin wrote: > Sean, Martin, and others... > > --On Sunday, November 29, 2015 1:06 PM +0900 "Martin J. Dürst" > wrote: > >> Hello Sean, >> >> This is a very good catch. >> >> On 2015/11/27 02:37, Sean Leonard wrote: >>> Hello... >>> >>> According to: >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141 >>> bis-urn-04.txt >>> >>> Sometime between Draft 4 (October 16, 2012) and Draft 5 >>> (November 27, 2012), >> >> The dates are correct, but it's draft 3 and draft 4, as the >> diff URI shows. >> >> The change happened with a change of author/editorship from >> Alfred Hönes to Peter Saint-Andre. Probably, Peter can >> explain best. > > Agreed. However, my vague recollection is that there was an > explicit WG discussion on that matter, probably tied up with the > observation that the 2141 text was a little too close to the > now-discredited "just sand UTF-8 and all i18n issues will go > away" position. > >>> UTF-8 encoding got removed. I guess that means that now it's >>> up to the namespace to define what encoding is used, if any? >> >> That would be a very bad idea. > > Yes, no question about that, at least IMO. If any non-ASCII > encoding it to be used, it fairly clearly should be UTF-8. > >> UTF-8 was explicitly put into >> RFC 2141 to avoid useless/confusing variability for namespaces >> that originally contain non-ASCII characters and therefore >> need to be mapped to US-ASCII. > > I believe that is correct too. > >> This definitely should be fixed asap. > > Unfortunately, the fix does not appear to be as obvious as a > sentence that says "any non-ASCII octets MUST BE valid UTF-8" in > some appropriate place in the text. As soon as we move away > form ASCII, we reintroduce issues with string comparison, > normalization, and case-folding. Those issues imply a choice > between increased risk or false positives or false negatives, > potentially involving us with all of the issues that have > plagued PRECIS in recent months and a requirement to revisit our > comparison rules. > > Or course. we could be draconian about things and say that two > URNs are equal only if the NID and NSS strings are exactly > identical at the octet level, but that implies that > > urn:XXX:somestring-in-NFD-form > will, in general, not be treated as equal to > urn:XXX:somestring-in-NFC-form > > Maybe that is ok, but, if it what the WG wants, I'd like to be > sure before altering text. And, if it isn't what the WG wants, > we need a plan. > > So "asap" may not be quite as fast as one might think at first > glance. > > Peter? Andy? I agree that we need to discourage non-UTF-8 encodings, but I also agree that there can be devils lurking in the details. Thankfully we have enough i18n knowledge and experience here to get it right - well, as much as one can get things right when it comes to i18n... Peter From nobody Sun Nov 29 19:00:09 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37B81A3B9F for ; Sun, 29 Nov 2015 19:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.3 X-Spam-Level: *** X-Spam-Status: No, score=3.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N92tsUgixKy8 for ; Sun, 29 Nov 2015 19:00:07 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5331A3B9C for ; Sun, 29 Nov 2015 19:00:07 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1a3Eh9-0003Fz-GD; Sun, 29 Nov 2015 22:00:03 -0500 Date: Sun, 29 Nov 2015 21:59:58 -0500 From: John C Klensin To: Peter Saint-Andre , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Message-ID: <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> In-Reply-To: <565B74FC.6070400@andyet.net> References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: urn@ietf.org Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 03:00:08 -0000 --On Sunday, November 29, 2015 2:58 PM -0700 Peter Saint-Andre wrote: >... >>>> UTF-8 encoding got removed. I guess that means that now it's >>>> up to the namespace to define what encoding is used, if any? >>> >>> That would be a very bad idea. >> >> Yes, no question about that, at least IMO. If any non-ASCII >> encoding it to be used, it fairly clearly should be UTF-8. >> Unfortunately, the fix does not appear to be as obvious as a >> sentence that says "any non-ASCII octets MUST BE valid UTF-8" >> in some appropriate place in the text. As soon as we move >> away form ASCII, we reintroduce issues with string comparison, >> normalization, and case-folding. Those issues imply a choice >> between increased risk or false positives or false negatives, >> potentially involving us with all of the issues that have >> plagued PRECIS in recent months and a requirement to revisit >> our comparison rules. >> >> Or course. we could be draconian about things and say that two >> URNs are equal only if the NID and NSS strings are exactly >> identical at the octet level, but that implies that >> >> urn:XXX:somestring-in-NFD-form >> will, in general, not be treated as equal to >> urn:XXX:somestring-in-NFC-form >> >> Maybe that is ok, but, if it what the WG wants, I'd like to be >> sure before altering text. And, if it isn't what the WG >> wants, we need a plan. >> >> So "asap" may not be quite as fast as one might think at first >> glance. >> >> Peter? Andy? > I agree that we need to discourage non-UTF-8 encodings, but I > also agree that there can be devils lurking in the details. > Thankfully we have enough i18n knowledge and experience here > to get it right - well, as much as one can get things right > when it comes to i18n... Hi. I am really reluctant to open new cans of worms if we can avoid them. To that end, because the relevant text points to RFC 3986 for encoding discussions, I went back and looked at it. It seems to strongly recommend UTF-8 (and nothing else) in several places, but stops short of making that a requirement. How would people feel about our simply going a half-step further and saying something equivalent to "when characters outside the ASCII repertoire are needed UTF-8 MUST be used as a basis for coding and conversion, otherwise the rule are as specified in RFC 3986". I'd encourage everyone to recheck Section 4 of 2141bis to be sure it is comprehensive enough to avoid further problems (and to suggest text if it is not), but, if it is, this may be something we want to pass onto 3986 as much as possible. If that creates more pressure for 3986bis, so much the better. john From nobody Sun Nov 29 23:12:08 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7359F1AC41F for ; Sun, 29 Nov 2015 23:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFa57G_8xu0s for ; Sun, 29 Nov 2015 23:12:05 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F201AC410 for ; Sun, 29 Nov 2015 23:12:04 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 928A5509BD for ; Mon, 30 Nov 2015 02:12:03 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> From: Sean Leonard Message-ID: <565BF649.80507@seantek.com> Date: Sun, 29 Nov 2015 23:10:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060909060806040102060604" Archived-At: Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 07:12:06 -0000 This is a cryptographically signed message in MIME format. --------------ms060909060806040102060604 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/29/2015 6:59 PM, John C Klensin wrote: > --On Sunday, November 29, 2015 2:58 PM -0700 Peter Saint-Andre > wrote: > >> [...] >> I agree that we need to discourage non-UTF-8 encodings, but I >> also agree that there can be devils lurking in the details. >> Thankfully we have enough i18n knowledge and experience here >> to get it right - well, as much as one can get things right >> when it comes to i18n... > Hi. I am really reluctant to open new cans of worms if we can > avoid them. To that end, because the relevant text points to > RFC 3986 for encoding discussions, I went back and looked at it. > It seems to strongly recommend UTF-8 (and nothing else) in > several places, but stops short of making that a requirement. > How would people feel about our simply going a half-step further > and saying something equivalent to "when characters outside the > ASCII repertoire are needed UTF-8 MUST be used as a basis for > coding and conversion, otherwise the rule are as specified in > RFC 3986". Ok, but how is that different from RFC 2141, appropriately massaged to=20 reflect 2015: RFC 2141: Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated [...]. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding [5 ], and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. -Sean --------------ms060909060806040102060604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MzAwNzEwMDFaMC8GCSqGSIb3DQEJBDEiBCBL2eUfKCZCSv0d0C/Hbrkixgr2sIPC8uW8I3Q1 lZ2KSTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBLrqT+wD/cq1YEEV4p E0sNuMYiVgLXZNyMhR27w+8B+4thvqYL9iLkEcHdVMMYUIoP+OGZ5UYUTxwpMumvnmI0YQL7 TGRA1qxsTCypdl8WQodREcD27rLLaTLYAcUIpuPnFbgoV7zeBa0ar9XmwpZ9ui5Opi2E7xEO Onq95zQjAUiSJpvulbs6yCTUV2OHJxUt5g6WvjwTz9nxAbD1NeEx7VkROB/nDT2W74GYx9NH CgGlCZLZ8mt2w2Mt0PWo2SfIhku0lA9aSsf7OwDcx4K033d9NeHQmLhqofosbDjbrNDuRlZN QFr7F1XrUqgtepltNvvJG3bcG8O1h+6OAbeZAAAAAAAA --------------ms060909060806040102060604-- From nobody Sun Nov 29 23:28:39 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B9D1B2ABD for ; Sun, 29 Nov 2015 23:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqrDfIdS7jIC for ; Sun, 29 Nov 2015 23:28:35 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0095.outbound.protection.outlook.com [104.47.126.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9105F1B2AB5 for ; Sun, 29 Nov 2015 23:28:34 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0139.jpnprd01.prod.outlook.com (10.161.77.147) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 30 Nov 2015 07:28:29 +0000 To: Sean Leonard , References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <565BFA93.10707@it.aoyama.ac.jp> Date: Mon, 30 Nov 2015 16:28:19 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565BF649.80507@seantek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0017.apcprd06.prod.outlook.com (25.164.91.27) To OS2PR01MB0139.jpnprd01.prod.outlook.com (25.161.77.147) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0139; 2:E0NWQd8VsnSn0qqYFYY72k6KV9HxRDGyrsk8okpilw/yywcRBysspDbUBMPdUiIVmA2Hb/mMKBMHhC4nrGvbV/q3zactbQPGrElL2hb23hJih1jcXXr5IoI/WzNWEERh/GDjosbdXSttIRoup4SxMA==; 3:AZ2JUs/ON0jlL7/h5O4oYrfwZbTIJHrMtw/keVvZSVjZewRiymZRa0CS1HlDCdU2ze3Og3OWQfUxYYUq3BiO49cYx7wiiU7eUJEpFZhvxDl0fFL4buVJA3VS1635+VCg; 25:7RskI4vNPcCPBf7k1SrOxyrnktCnc2BSdjpnlsE6IviyybMKciTU7O3DIsNOWZYE5L/Oe238qZgkj07QMv1bD2p4bv/EVxXE1Me4qKTgQuPPCg4eAc6znJWfXLigesHkymT8UMixBRTq5mJWLRMFokNlP0JFI3H2lvEFsU1wvgfwNB9ZoFCWPy8d2e5hJEETFLkd/lqNBeHhfgK14cL0DEpxY6SmbN9Am+NNAu8bB4gw8zhWZWid+xYSr4ws/HXNlJJvKq8CTm1O3e4tp3cCFg==; 4:PvG3kaTlDBjY6fwA42089pLq0FP+2uCNuuPPF6GzkSoszFgUYpaVlKcyc+FazZHFNCSrKUayWAIP9LukiiKD5GPLyHEl+iNTsFfsvcx2du1dm+kXa/XavrvH1pORqHxvXQ0NYfirO+QZxKaDVV/JeUtzTeBl0Rc4Q87nPFOKyyuK2FcD5pxhDUuSun+N8v6n9RzCLFfA3kE0RMj8/TzQk090kuc8nvaGVnURahr259vuBKN9qzhhom6EBK1vbBcRk7uHjdGje83WfJqJvoaYIe4V5jq2vcN1K1rTGTW0F5n4U32OKPIArgKZF6Mgzc5K/pi7YDAmBeJRR30JTyuCBOKaznuPkAAqX2raDH7XwU/NUnhWwxVw7b1xyZKSa3Gc X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0139; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:OS2PR01MB0139; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0139; X-Forefront-PRVS: 0776C39A48 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(199003)(24454002)(479174004)(47776003)(74482002)(586003)(2950100001)(107886002)(5001770100001)(40100003)(19580395003)(5004730100002)(3846002)(65806001)(189998001)(97736004)(33656002)(50986999)(4001350100001)(81156007)(42186005)(65956001)(5008740100001)(106356001)(93886004)(92566002)(65816999)(105586002)(15975445007)(23676002)(230700001)(66066001)(101416001)(6116002)(77096005)(5001960100002)(50466002)(64126003)(1096002)(54356999)(76176999)(83506001)(122386002)(86362001)(87976001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0139; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMTM5OzIzOjQvV085RDNKRW1BS0g1WHVvMjBBVzZjd2Rj?= =?utf-8?B?S3d2SFNJcWtOQ2lhOHdKNkJWRkU3SFVScHNFR05CL0RZeWtxNkp3MjNqNkhS?= =?utf-8?B?ZThEeTdhQUk4eWJ1MlBHUXNFYnR6WkJ0NURMR0pUWEw3R1JIM0l6Qk9mWFRX?= =?utf-8?B?NUh0enR1OFRaSC9TY0hITFM4MmYyemhtY3hoWHlQeWx0MjIyRUkrZzRqL2pE?= =?utf-8?B?MytPcVZrbm5qaFJWZGovQlNPa3pvT3haVEdrUnFzQ0hhRks3NHdqOEVNSWt0?= =?utf-8?B?OENMN1dDMGRxaG1kOE12cGdPT1phcms1K2FOLzkrUkZUc3pva3RUbGhENWZK?= =?utf-8?B?THBYMTNyMWxRQ3FYY0ZVTURNMDRtcjV1V0o1bkpjY3M1UGw2NFBSYzhVMkpZ?= =?utf-8?B?Z1c3ZDNFVi9mL25CczdqakpEbVY0SkhvWE9oTGN5aVFSRCtSRHdybHBuKzl6?= =?utf-8?B?ek1ObjY0T29xTGgrYUpsdUtKM1FhRWtqSy82VzZEMHZuZlQ0Znh1UTVVbFpI?= =?utf-8?B?U3k3eldOekFtUkh2TitoU0RHd0pDdWJXWng0WC9rTXdZRlh1MFd4OG1LaXlP?= =?utf-8?B?bUhUUFV2dURoaS8wNUcyaThDOHpTQVVTRlRWbnQ2YTB4Mk9IVXFwVW1oeWRt?= =?utf-8?B?MGhUdE5SWmJOd0dVdEFCclpxVkJUOC83SzdBR1BPVHFudW5Rb3Rub3ZHa0FT?= =?utf-8?B?NkZGeEsybHJZVHp1aHN6cHgxS0lBL3F5VGRTOFUxTitYYTloVExXK2tBeUQ5?= =?utf-8?B?MFZHZGU4YVZJemtSbzh4SEVraWJVT0V3YTZTVi91Z3NiK3RBQ1RZSzl5c1Nh?= =?utf-8?B?QTNZUXE4MGhvN0JZRGRXcnd6YlFkRGN6aGY2ZmlFRzFJVWJhbUx1MFF2VHBy?= =?utf-8?B?Z20xOUFxdmo0SXV1UDdGNGlGZDVYYWV3Y1U0YXJXWkphZWxydzdRNTlKbmRx?= =?utf-8?B?ZndtT1haMUVtZDkrbmVMcy9MRjVzeUJOdXdnR1pzUy8xdWtaKzNqNGNBZ3pT?= =?utf-8?B?N0NENGZjOVZ3RVkza0hXUnkrTGp6bjN2M0xjMXJVMHZNWkZmUS9EMmVwbVBF?= =?utf-8?B?OVpuMjRsS0pGUUpVMWNZOTA5dEQyUHVoQXBqLzV0NGpKa29DTEwvS0dML09z?= =?utf-8?B?cVBGQW5uc3BPTkY1TWJNb21PeEVuamNyd3RFKzF2VitHcUR4Y1BMZjFOZGc5?= =?utf-8?B?MnJJUitub2Z5c1pkZzdCTy9sOEZYSDN2bW5zVHEvajZzRHQyZ1h4TjJ2Y2ts?= =?utf-8?B?WWdmWkpDM2F4aHh3NDl4Y3pVNStITWI3TzdVRGgvK2FQRmQ3bkk1Mkp6RWJL?= =?utf-8?B?STBvQkpxRGJOdC9UUHZ0alVCKzNGVzJXcVVyNjhzYTFma1hPa1pnREkrRXR4?= =?utf-8?B?UXBTdW9FcDJOakFWVi80cmlkcWl2K3orRWVlZkpKUmFiQ1BmMktIeEUvZDZy?= =?utf-8?B?ZWhJMHdWaHJrY3dRYWF5QS9ReEZBNTc2azUwSmJ4NzZYZ3dvQWNZZ3FEcG9t?= =?utf-8?B?WHJHakVVN2Z6aFkwK1cxd0pwUEl1OUtzV1RQQmZpR1lncXMvdTdseGsrdUpE?= =?utf-8?B?VkduTmp3MTExNFd0ank1Y005eTBPcjg0SlZMLzlKQkRRWkw5ajJqT3Uwa09V?= =?utf-8?B?S0VYa0pLZlAxZmlHUFdEeGJyWnRuWXpTRFJQalZGbkJTV1h4K0VIYVdxRFBz?= =?utf-8?Q?hy8K80AK4uFyPNRs5ms5w3KYGICujnhVx8MD017?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0139; 5:o5LM1SH3EQ1nbXKobtnTWVMl0/eE7xEDlNJbkl61RGcSluZ/cZIhd6hEI3wF0IIYg9Y9Z7TfAB+3q+gWotpzPIWm7gpc4QiaEE1+7fcmapvLTVjFOUlreqtz9zckEWZtGuLA17AgRCrA5Gs1/vHS7Q==; 24:Z5tzeza5OTdN7bsMFjwn1KgpbQIFgHHW9RzHgfXaa+nZfnfVC/zkbO4bqBRXkpqgZm3gUpqo2vfmYKbDOqKA+SS4dgzx89W+915psAQJxXE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2015 07:28:29.1327 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0139 Archived-At: Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 07:28:37 -0000 On 2015/11/30 16:10, Sean Leonard wrote: > Ok, but how is that different from RFC 2141, appropriately massaged to > reflect 2015: > > RFC 2141: > > Depending on the rules governing a namespace, valid identifiers in a > namespace might contain characters that are not members of the URN > character set above (). Such strings MUST be translated > [...]. Translation is done > by encoding each character outside the URN character set as a > sequence of one to six octets using UTF-8 encoding [5 > ], and the > encoding of each of those octets as "%" followed by two characters > from the character set above. The two characters give the > hexadecimal representation of that octet. If we care about 2015, then please change "one to six octets" to "one to four octets". Also, RFC 3986 says that for hex characters (A-F), upper case should be used. That convention wasn't fixed yet in the RFC 2141 time frame, but may lead to less false negatives when matching. Regards, Martin. From nobody Sun Nov 29 23:48:53 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A769A1AC423 for ; Sun, 29 Nov 2015 23:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4rFprXphd3g for ; Sun, 29 Nov 2015 23:48:50 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207101B2BBD for ; Sun, 29 Nov 2015 23:48:50 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 90A16509BF; Mon, 30 Nov 2015 02:48:48 -0500 (EST) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <565BFEE6.50602@seantek.com> Date: Sun, 29 Nov 2015 23:46:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565BFA93.10707@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030608030706060304080605" Archived-At: Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 07:48:51 -0000 This is a cryptographically signed message in MIME format. --------------ms030608030706060304080605 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/29/2015 11:28 PM, Martin J. D=FCrst wrote: > On 2015/11/30 16:10, Sean Leonard wrote: > >> Ok, but how is that different from RFC 2141, appropriately massaged to= >> reflect 2015: >> >> RFC 2141: >> >> Depending on the rules governing a namespace, valid identifiers in= a >> namespace might contain characters that are not members of the URN= >> character set above (). Such strings MUST be translate= d >> [...]. Translation is done >> by encoding each character outside the URN character set as a >> sequence of one to six octets using UTF-8 encoding [5 >> ], and the >> encoding of each of those octets as "%" followed by two characters= >> from the character set above. The two characters give the >> hexadecimal representation of that octet. > > If we care about 2015, then please change "one to six octets" to "one=20 > to four octets". Also, RFC 3986 says that for hex characters (A-F),=20 > upper case should be used. That convention wasn't fixed yet in the RFC = > 2141 time frame, but may lead to less false negatives when matching. Yes. +1. Except one thing: yes, URN producers and normalizers should use=20 uppercase hex. However, it should not lead to false negatives when=20 matching, because percent-encoded productions are case-insensitive.=20 I.e., the case-insensitivity a URI thing (and an ABNF thing)--a URN=20 comparison function that treats %7F as different from %7f is incorrect. Sean --------------ms030608030706060304080605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MzAwNzQ2NDZaMC8GCSqGSIb3DQEJBDEiBCCJjlHQgfh1AkXjfdmY3Erwa0CCFrRexIGNGByH SBKHqjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCzxYb0lc/gbRnES5aa GtHjkRbcmkHE6C7LOXswJp6XeUO4Pm7valhGkNKIefa7jDYqdsftw21k6a7HH1n6XUJ7Bs5D tDw6Pyg8IlNu/zmNxse0eaZmYGZW0OP2pHQo2PC/n5BgioH4Cpcib5oy870rijMdbgnfcglz rdExBTz9rroj5DlyYppGfmgI+O1H10rWLQ2R5fFkXVfDimCIoKRQaGe34F2VvKjj7C6ZDpfA 222ONG3jlErCeR2l8VTGCOahFHPH9xD12afj1jC3p2XPerMunjJS98db9ozzSvH0wxKc3ann mwaynH7BF66zCFIAZlTuhaPbEupEU7208ubYAAAAAAAA --------------ms030608030706060304080605-- From nobody Mon Nov 30 00:06:23 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3CE1B2C32 for ; Mon, 30 Nov 2015 00:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW7OIlov-bBC for ; Mon, 30 Nov 2015 00:06:20 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3576B1B2C2F for ; Mon, 30 Nov 2015 00:06:20 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1439C509BE for ; Mon, 30 Nov 2015 03:06:18 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <565C0300.3040005@seantek.com> Date: Mon, 30 Nov 2015 00:04:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565BFA93.10707@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020402070600060202080503" Archived-At: Subject: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 08:06:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020402070600060202080503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable While we are at it, allow me to provide the ABNF of UTF-8=20 percent-encoded octets: utf8-pct-encoded =3D utf8-1-pct-encoded / utf8-2-pct-encoded /=20 utf8-3-pct-encoded / utf8-4-pct-encoded utf8-1-pct-encoded =3D "%" %x30-37 HEXDIG utf8-2-pct-encoded =3D ("%C" (%x32-39 / %x41-46 / %x61-66) / "%D" HEXDIG= )=20 utf8-tail-pct-encoded utf8-3-pct-encoded =3D "%E0%" ("A" / "B") HEXDIG utf8-tail-pct-encoded / = "%E" (%x31-39 / "A" / "B" / "C") 2( utf8-tail-pct-encoded ) / "%ED%"=20 ("8" / "9") HEXDIG utf8-tail-pct-encoded / "%E" ("E" / "F") 2(=20 utf8-tail-pct-encoded ) utf8-4-pct-encoded =3D "%F0%" ("9" / "A" / "B") HEXDIG 2(=20 utf8-tail-pct-encoded ) / "%F" %x31-33 3( utf8-tail-pct-encoded ) /=20 "%F4%8" HEXDIG 2( utf8-tail-pct-encoded ) utf8-tail-pct-encoded =3D "%" ("8" / "9" / "A" / "B") HEXDIG Replace "pct-encoded" with "utf8-pct-encoded" for appropriate parts of=20 RFC2141bis. Sean PS This was straightforward to derive from RFC 3629. --------------ms020402070600060202080503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MzAwODA0MTZaMC8GCSqGSIb3DQEJBDEiBCAFnO4VtkCJCDYNT9xOfH2H4cT0To8+UpX05a/N SkeR+TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBGr3ZCYhDSva8kPkMG 8kkg77O9QkojOPxF+ce6Ykhj6Ibx+uaYOMJKvrHmnKnRRENR7POhNf1hJ5Pl757XXeJT9IMm 3Au+ACIn3TC8bwEYFvmp1z6Tg4XtaDb492YQXGHQq/nY92ITcySKdi9FEGfYHghNcG/eUvii 6LwZiJjoSwTEwL5rn34PuDwWillOAV1rHS4GCQFarsDEdP89i4ZrEET9l/A9JUSqve4EKPNl F6gMBM2hw9ejvjuVJKVg39iwQ31FGQv1vC5cnr+VV3Mmg80fvvky5IN4YK1KcjJXirwasWZ0 LCJjawPdyeybHTQA9xRsMOl4xz9R4ayqNOWGAAAAAAAA --------------ms020402070600060202080503-- From nobody Mon Nov 30 00:08:37 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E3E1B2C4B for ; Mon, 30 Nov 2015 00:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNt3n16iYl3n for ; Mon, 30 Nov 2015 00:08:36 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B174E1B2C4A for ; Mon, 30 Nov 2015 00:08:35 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 90CCA509C0 for ; Mon, 30 Nov 2015 03:08:34 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <565C0388.7030203@seantek.com> Date: Mon, 30 Nov 2015 00:06:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565BFA93.10707@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000206010805060803020902" Archived-At: Subject: [urn] EDITORIAL Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 08:08:37 -0000 This is a cryptographically signed message in MIME format. --------------ms000206010805060803020902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable EDITORIAL fix: Section 4.1: 3. any percent-encoded characters in the NSS (that is, all character= triplets that match the production found in Section 2.1=20 of the base URI specification [RFC3986 ]), by is wrong. It should read "". pct-encoding is not a thing in RFC 3986. But (somewhat less editorially), it should say , per=20 my immediately preceding message. We are restricting NSS to UTF-8 so it=20 is sloppy for the ABNF to permit all hex combinations in the =20 production. Sean --------------ms000206010805060803020902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MzAwODA2MzJaMC8GCSqGSIb3DQEJBDEiBCDmWOYVxGFpsfnsg7cJu95ax17/BWqOJUg3AJw+ czaAazBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCOiwPHooMij9aT5lBh /wSqYeM0yVE+0dktcEtanhvmpNwUBEd5AlOtvprb5mJGUvyP/jiKzZplKR9KtIq5gPMcHtL1 wHnCvLU2aowW0n7bd8WJGmcBdMoWUA0rOPJHW/zVHJHBR1x+ce1C1lQxtEez701rdGkzR8sw TKzcHDTtXzZSmrzrSa2dr6LZKiqHgnKJijnNw8Wsk5o+q5gcOTOQ7BNLi4gug51FAl5LPcES yzPeP30n+M+NiK6cN8ZMoUj0ECrBmx0rdaXRgeRQTvZjKicEmx9AQ/Sdc7LecvrJYFvleC8C BVJAhD4ioMMEs/aUJtcGVFFrUPfAT5wbz/VcAAAAAAAA --------------ms000206010805060803020902-- From nobody Mon Nov 30 00:43:59 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586D71AC3C3 for ; Mon, 30 Nov 2015 00:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPuMeRGh06KK for ; Mon, 30 Nov 2015 00:43:57 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6B61B2CE0 for ; Mon, 30 Nov 2015 00:43:56 -0800 (PST) Received: from [192.168.178.20] ([84.187.44.32]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LxgM7-1aOCPL0DRz-017HK0; Mon, 30 Nov 2015 09:43:52 +0100 To: Sean Leonard , urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> From: Julian Reschke Message-ID: <565C0C49.8060109@gmx.de> Date: Mon, 30 Nov 2015 09:43:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565C0300.3040005@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rtL4ZbR7PqgSBSJvYc6wZwPBzhY76ba6pdzo79FMPMctN1isLdB 1hEPx6ywjxZpzL0fYYSqxVx6MshyPnQb7XsT3zWXOlBKrnAegBrBg9cZCyYo6yNIAURwHKY B8ycJSG9R84gkPLEkuu8aFuCTZcY0Gsddq1ycPraGVG/JdUUd1zlLAO/osxeM92IJ9vwTpW U5DGbiiGM8ss/+Ft75aWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:S2T7KGwHhhQ=:56nVcooUifYQJ2CATWSe+B BZ4vOwdhAkw0KbbfjaAeBxPEsy1mTivE8VLBs3lmpmZpYj2YRr7WlVLZWKptZbh/PKEEjBoJr Olnnoi8unHO24G0nMOsR3pmoJ0T7zGpFu9eSfjbFuJfdSueZLYJN+Ense84wp51d9xak3X3eo RVUDE0WZcSnrszXbssvOwP+hdZDTdKhZpLpYNVDi86F89eq6a6X3W6DIIkiMd3dAaeWTzgqcE +udaewBOQq7RxXuUWml8jV8XvMkpre7KBXY8kuz8VGjCBoBW7hD8YzGOsjb93+Dv1dpM6CZG1 JvHqAURc9pagT55A5YSBZW8kE8wwX+Xwc6jx8EA3Ex3CCo29it/4G+x7DR8qI2sJOYjCMqSuQ 6Q7Jnd7Z9UbX+5Xh/Ekg8GfTaWr9r4bEgFV9OeqCxDpgcQrBs9RBlyDRiLFHLc/aFL3DPBOyC py0/mdjsTHfyFK0AwJ4qgpM+xvvooWXWnF9eZHVZ2YI7I+fG7G3vAt/3f+XF6K48TBjxQnBRp jI4aVGja4ZwhAeeuUCd/G0WFnk5icHjolcZbmbMRHd/rJ8fQNbLtA4dt6R0ozqb46uKS/hoEE 26TXHoZgXU/JcgX+CNLgZS66q8E0xxVMK4rftZlnsFL1YkSwzImocpI1Rg0NKr637ukdXH/5q hvGgbT9Ow7/HITqGGlj0WtN39JgnT74W3SEj7IstNirVfR4uEwNM56L4FeY1DiJNmwmsp8DoE EZTwXqnvjDjvI2qQUTfW5NKSRL3zTuNSJXmVsbbRie0TG31XyebK0D5MMXP6iKi84491LSYMm vs2BrI4 Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 08:43:58 -0000 On 2015-11-30 09:04, Sean Leonard wrote: > While we are at it, allow me to provide the ABNF of UTF-8 > percent-encoded octets: > > utf8-pct-encoded = utf8-1-pct-encoded / utf8-2-pct-encoded / > utf8-3-pct-encoded / utf8-4-pct-encoded > > utf8-1-pct-encoded = "%" %x30-37 HEXDIG > > utf8-2-pct-encoded = ("%C" (%x32-39 / %x41-46 / %x61-66) / "%D" HEXDIG) > utf8-tail-pct-encoded > > utf8-3-pct-encoded = "%E0%" ("A" / "B") HEXDIG utf8-tail-pct-encoded / > "%E" (%x31-39 / "A" / "B" / "C") 2( utf8-tail-pct-encoded ) / "%ED%" > ("8" / "9") HEXDIG utf8-tail-pct-encoded / "%E" ("E" / "F") 2( > utf8-tail-pct-encoded ) > > utf8-4-pct-encoded = "%F0%" ("9" / "A" / "B") HEXDIG 2( > utf8-tail-pct-encoded ) / "%F" %x31-33 3( utf8-tail-pct-encoded ) / > "%F4%8" HEXDIG 2( utf8-tail-pct-encoded ) > > utf8-tail-pct-encoded = "%" ("8" / "9" / "A" / "B") HEXDIG > > > Replace "pct-encoded" with "utf8-pct-encoded" for appropriate parts of > RFC2141bis. > > Sean > > PS This was straightforward to derive from RFC 3629. -1. The ABNF is the wrong place to enforce constraints like these. Best regards, Julian From nobody Mon Nov 30 07:54:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875BC1B2F50 for ; Mon, 30 Nov 2015 07:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4biCyspR7NK2 for ; Mon, 30 Nov 2015 07:54:28 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43441B2F42 for ; Mon, 30 Nov 2015 07:54:27 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3ECA0509C2; Mon, 30 Nov 2015 10:54:25 -0500 (EST) To: Julian Reschke , urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> From: Sean Leonard Message-ID: <565C70B7.5000709@seantek.com> Date: Mon, 30 Nov 2015 07:52:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565C0C49.8060109@gmx.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020007080000000007060709" Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 15:54:29 -0000 This is a cryptographically signed message in MIME format. --------------ms020007080000000007060709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/30/2015 12:43 AM, Julian Reschke wrote: > On 2015-11-30 09:04, Sean Leonard wrote: >> While we are at it, allow me to provide the ABNF of UTF-8 >> percent-encoded octets: >> >> utf8-pct-encoded =3D utf8-1-pct-encoded / utf8-2-pct-encoded / >> utf8-3-pct-encoded / utf8-4-pct-encoded >> >> utf8-1-pct-encoded =3D "%" %x30-37 HEXDIG >> >> utf8-2-pct-encoded =3D ("%C" (%x32-39 / %x41-46 / %x61-66) / "%D" HEX= DIG) >> utf8-tail-pct-encoded >> >> utf8-3-pct-encoded =3D "%E0%" ("A" / "B") HEXDIG utf8-tail-pct-encoded= / >> "%E" (%x31-39 / "A" / "B" / "C") 2( utf8-tail-pct-encoded ) / "%ED%" >> ("8" / "9") HEXDIG utf8-tail-pct-encoded / "%E" ("E" / "F") 2( >> utf8-tail-pct-encoded ) >> >> utf8-4-pct-encoded =3D "%F0%" ("9" / "A" / "B") HEXDIG 2( >> utf8-tail-pct-encoded ) / "%F" %x31-33 3( utf8-tail-pct-encoded ) / >> "%F4%8" HEXDIG 2( utf8-tail-pct-encoded ) >> >> utf8-tail-pct-encoded =3D "%" ("8" / "9" / "A" / "B") HEXDIG >> >> >> Replace "pct-encoded" with "utf8-pct-encoded" for appropriate parts of= >> RFC2141bis. >> >> Sean >> >> PS This was straightforward to derive from RFC 3629. > > -1. The ABNF is the wrong place to enforce constraints like these. Explain? "Wrong" is not a technical argument. The ABNF is not "enforcing constraints"; the standards document is (or=20 will). The ABNF accurately reflects the standard. Sean --------------ms020007080000000007060709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MzAxNTUyMjNaMC8GCSqGSIb3DQEJBDEiBCCohGXbAXs03f+Lpr5oQTyJ5d1VFfRMg1gArB6q 5Cl+wDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQC/LQWYe2rZz0KipsMt QOtqVdjk/MnKtV/rz5QoG3WpDcK8RserR2K1IKc3Q251/clCOnif/ezeNQ8EQT7wI56SSzhQ L79Brlx/v+J4ppJMq1u2ayPs8sEVwMMP6Zes76YOWSW3WxTf34Z0rQ5JiRjxI2Y/JpFzPzKx IaKe0Qy+WOGrr6DmUOHmQ2Y33K0MScnMly4xUt1fHS3VH+3sEM0HF/WnsDQ5mz/yOKxvHfe4 O8t26J8YJmE3O2USsTrN92SLoKzVravSyvcsQys3fCTGGZa4/TtLZl7ulqXMbU9rVX28hoQB ftEklE/EBmCM6oSJKu9R7AjY7fAObUJKumYZAAAAAAAA --------------ms020007080000000007060709-- From nobody Mon Nov 30 08:17:21 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F0D1ACE7D for ; Mon, 30 Nov 2015 08:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7UVQPOTLfNF for ; Mon, 30 Nov 2015 08:17:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074691ACE8A for ; Mon, 30 Nov 2015 08:17:12 -0800 (PST) Received: from [192.168.1.158] ([5.10.171.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MRCCJ-1Zs3xp0iRr-00UeWc; Mon, 30 Nov 2015 17:17:10 +0100 To: Sean Leonard , urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565BF649.80507@seantek.com> <565BFA93.10707@it.aoyama.ac.jp> <565C0300.3040005@seantek.com> <565C0C49.8060109@gmx.de> <565C70B7.5000709@seantek.com> From: Julian Reschke Message-ID: <565C7688.9020008@gmx.de> Date: Mon, 30 Nov 2015 17:17:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565C70B7.5000709@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:IKGpsGXmEr6WpVNmNHcPGDbjAgR8n2+8p/TW90gWDjGZ+VLc8bA GW/RVumJIiJPOX/OeLqo7PLIdee1+9mR95geSow7loAsp0zsXkD4qheFsMeuXJvP1/X/EgC Mu4B6QckIRlZrWefcbl2slA7MsZdEKryL4+XFgBkhYCIH+OBoABOGJ0v7uDiBlsrRhaKpJ0 INUjrRC480eU6pDW580vg== X-UI-Out-Filterresults: notjunk:1;V01:K0:nSrx7YTQYE4=:2bKbPzYxoWo5VcOA1nzGjH E6RfQUY7aAC9MxHcB9PtrrPmS7JzvKWXKasNnY2mqLElFY+r2NCCzxzpUaoOX1ccMHWfVt8e6 sQPFzvwk6pD2ODtAKyIPKUHGz3JFnEgaauk65B8JZywT71E5trb4iXGylCK8BD8IsmjRqJDFo MYaHxxtOQ4cFSu0pr7gi8Fwz8qRCCdaBy3dNNPIMKDbHqPeXQBg9cSqae4gmrFRadqUE2/X1w AIPKEyY2qT0iQfMKn63E7X6d70UghuXAeJ5HCMFTuW2t+nEWzWN1LKcLJl/Zn25ZYyE9Jg3El J0yuJZFNq5QhOvwVvX46AKCFw/zQaj7zQJezla8UJGZ+S3qHrEmo+20NrEpTiyXuoo0LQCfwz MZWrt4vh01I/ayt6Xgqy5Ftcd/UV1H8d1Q6ntzkyjR0bLgbdBrDutaEhttSb7H/2zwdKsEkVN tyQzzXkjqmO+3ANLk8v/Hd4sxF05chMQU0aKIZ1VXIWbYBKYBRTNeGTlC8v+gKZdHwRW7r0DJ N6s00BmAtzVcqWNGz9oMIgCTr81N9hyLJ7EVbgkSzriksTImHrI4A8NOatwK34isMTDfYZ1t5 836DOzywU7V6P4047M8K1kW2RokoCiuoL9HQpdRsZ8D6GTzxYImo6YepllV93oSaKOzqlpdLc AkSPXn+F905MazEioA/EC+q6dcCn2DRHnltkWIVJKBN/q9UOoHT4Arx5j8Jy/ugyBcn4EnBO5 8KzYMXiD3nc2UgCdAY4tI5FpRC//lSVMzQaRFIXm1zCbEvatQZ8YyL28ahF17XE1d0MoFuiMT Ps/jLxQ Archived-At: Subject: Re: [urn] UTF-8 ABNF Re: What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:17:18 -0000 On 2015-11-30 16:52, Sean Leonard wrote: > ... >> -1. The ABNF is the wrong place to enforce constraints like these. > > Explain? "Wrong" is not a technical argument. > > The ABNF is not "enforcing constraints"; the standards document is (or > will). The ABNF accurately reflects the standard. > ... But the *purpose* (IMHO) of the ABNF is not solely to "reflect the standard" but to also to assist people in writing conforming parsers. Do you expect *parsers* to reject invalid UTF-8 sequences? I don't; I'd rather expect the consumer of the parser to inspect the octet sequences (that's why a UTF-8 decoder does, no?) So, phrased differently, you're mixing multiple layers in the ABNF, which I believe wouldn't be helpful. Best regards, Julian From nobody Mon Nov 30 18:41:24 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDC01B3812 for ; Mon, 30 Nov 2015 18:41:22 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUiaretJ0hPo for ; Mon, 30 Nov 2015 18:41:20 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809E01B3811 for ; Mon, 30 Nov 2015 18:41:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DAB5D20931 for ; Mon, 30 Nov 2015 21:41:19 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 30 Nov 2015 21:41:19 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=CuqhxkgQg+BZAx/kazqyVsXSTcQ=; b=GYmx3 QVpyMe4P0nswlkf4cd7hHrDvlf4X9Zt7sFepZ/gwXuqdDrJMOtRkWr85en0kzOE4 RcYP22En6kAdeCVTQe1lofRGt3xGQzU4UfPqVv+Tnl6vXo8cf2PvJqhB+a1RnNj+ 5vJhPnqeZs95dFMsZx4UYVAIDhbX5L4J4tvyNo= X-Sasl-enc: ciSMUukCS5JWo18Ifl92J0iOk+uI/gt8ySp+N3LR7o4n 1448937679 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 56DDCC013FE; Mon, 30 Nov 2015 21:41:19 -0500 (EST) To: Sean Leonard , "urn@ietf.org" References: <5657436C.6010305@seantek.com> From: Keith Moore Message-ID: <565D08C0.7070208@network-heretics.com> Date: Mon, 30 Nov 2015 21:41:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5657436C.6010305@seantek.com> Content-Type: multipart/alternative; boundary="------------030405050900040705030202" Archived-At: Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 02:41:23 -0000 This is a multi-part message in MIME format. --------------030405050900040705030202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I don't immediately see how to reconcile the desire for UTF-8 in URNs, with some fundamental URN requirements from RFC 1737 section 3: o Single encoding: The encoding for presentation for people in clear text, electronic mail and the like is the same as the encoding in other transmissions. o Simple comparison: A comparison algorithm for URNs is simple, local, and deterministic. That is, there is a single algorithm for comparing two URNs that does not require contacting any external server, is well specified and simple. o Human transcribability: For URNs to be easily transcribable by humans without error, they should be short, use a minimum of special characters, and be case insensitive. (There is no strong requirement that it be easy for a human to generate or interpret a URN; explicit human-accessible semantics of the names is not a requirement.) For this reason, URN comparison is insensitive to case, and probably white space and some punctuation marks. o Transport friendliness: A URN can be transported unmodified in the common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., as well as printed paper. Also, to the extent that any existing URN-eligible namespaces use characters outside the ASCII repertoire, the "legacy support" requirement might conflict with a desire to coerce those non-ASCII characters into UTF-8. (I'm not saying that this couldn't be solved, it it sounds unnecessarily complex, with each namespace using non-ASCII characters in its NSS potentially having to describe how to map those characters unambiguously into UTF-8) o Legacy support: The scheme must permit the support of existing legacy naming systems, insofar as they satisfy the other requirements described here. For example, ISBN numbers, ISO public identifiers, and UPC product codes seem to satisfy the functional requirements, and allow an embedding that satisfies the syntactic requirements described here. In addition, if you're trying to encode a significant amount of human-readable text in a URN, you're likely to be harming that URN's persistence - i.e. its ability to be bound to a single resource forever, because the meanings of human-readable words change over time. So I seriously doubt that it's appropriate to try to impose UTF-8 on URNs. URNs aren't intended to encode human-meaningful text. This is not a requirement of URNs, and trying to make URNs be good for that impairs their intended function. Keith --------------030405050900040705030202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I don't immediately see how to reconcile the desire for UTF-8 in URNs, with some fundamental URN requirements from RFC 1737 section 3:

   o Single encoding: The encoding for presentation for people in clear
     text, electronic mail and the like is the same as the encoding in
     other transmissions.

   o Simple comparison: A comparison algorithm for URNs is simple,
     local, and deterministic. That is, there is a single algorithm for
     comparing two URNs that does not require contacting any external
     server, is well specified and simple.

   o Human transcribability: For URNs to be easily transcribable by
     humans without error, they should be short, use a minimum of
     special characters, and be case insensitive. (There is no strong
     requirement that it be easy for a human to generate or interpret a
     URN; explicit human-accessible semantics of the names is not a
     requirement.)  For this reason, URN comparison is insensitive to
     case, and probably white space and some punctuation marks.

   o Transport friendliness: A URN can be transported unmodified in the
     common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., as
     well as printed paper.

Also, to the extent that any existing URN-eligible namespaces use characters outside the ASCII repertoire, the "legacy support" requirement might conflict with a desire to coerce those non-ASCII characters into UTF-8.   (I'm not saying that this couldn't be solved, it it sounds unnecessarily complex, with each namespace using non-ASCII characters in its NSS potentially having to describe how to map those characters unambiguously into UTF-8)

   o Legacy support: The scheme must permit the support of existing
     legacy naming systems, insofar as they satisfy the other
     requirements described here. For example, ISBN numbers, ISO
     public identifiers, and UPC product codes seem to satisfy the
     functional requirements, and allow an embedding that satisfies
     the syntactic requirements described here.


In addition, if you're trying to encode a significant amount of human-readable text in a URN, you're likely to be harming that URN's persistence - i.e. its ability to be bound to a single resource forever, because the meanings of human-readable words change over time.

So I seriously doubt that it's appropriate to try to impose UTF-8 on URNs.    URNs aren't intended to encode human-meaningful text.   This is not a requirement of URNs, and trying to make URNs be good for that impairs their intended function.

Keith

--------------030405050900040705030202-- From nobody Mon Nov 30 18:42:34 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7091B3814 for ; Mon, 30 Nov 2015 18:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08-7HGGGLo8T for ; Mon, 30 Nov 2015 18:42:32 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1771B3811 for ; Mon, 30 Nov 2015 18:42:32 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A32FD202F7 for ; Mon, 30 Nov 2015 21:42:31 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 30 Nov 2015 21:42:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=3Ki1QnpVPTyLHwx iD+0ES5Fv5V0=; b=gEWPXS3is8t7nEqtk3OwmC6YfT6CTEFSRrFgkJP3q0sU29N 40v6AA2yRnz3QVg3G+ECizro5VdQXh+yrrI7j7WLhF/4ne7KnG6nw8pPVZtsU9iz joU++Uy2JeZBUeYLXmELrmu3dxzSMzCrP4e/2Yw1+8gdI9lH89HPk36HL0xc= X-Sasl-enc: J1kQZ47/azQ2Bo6tedRPfazOUWCT2mOZ7whr8tSEmdV/ 1448937751 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 4978FC016D5; Mon, 30 Nov 2015 21:42:31 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B3502.5070402@seantek.com> From: Keith Moore Message-ID: <565D0908.9000906@network-heretics.com> Date: Mon, 30 Nov 2015 21:42:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565B3502.5070402@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 02:42:33 -0000 On 11/29/2015 12:25 PM, Sean Leonard wrote: > Note that q-components, f-components, and (possibly) r-components need > not be UTF-8. This introduces some subtleties in smushing problems > (e.g., smushing q-component into a query component of another URI > produced by resolution) but those are not more complicated than the > ill-defined "smushing" operation itself. Since "smushing" is completely inappropriate, this isn't a problem. Keith From nobody Mon Nov 30 18:43:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512511B3819 for ; Mon, 30 Nov 2015 18:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXXl91ExZE6K for ; Mon, 30 Nov 2015 18:43:34 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6E31B3817 for ; Mon, 30 Nov 2015 18:43:34 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 895CC202DC for ; Mon, 30 Nov 2015 21:43:33 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 30 Nov 2015 21:43:33 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=IGMAlIE9Qx5zsKH 9qy7iTPglPzw=; b=sr6z/lSgCbdYOM5ikZNJjLRhJPFSq9BUC+4Wx2b1tboreoB HiE9HFdQKapfz1hzuAfVYn27Tn++JOuIQP1mp2gTIULxFqAcoYgXyXrOULl9qfFe K42B+50/wHMswi9/Gd4tAFIlXvq1fZJF2R+yA3yYA3SbXyvB5LGmJvIXm83E= X-Sasl-enc: a93G+sziSr93xHRHxhdLz2C3jrWTd+4RX2KHn5l5Uldw 1448937813 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 320C1680113; Mon, 30 Nov 2015 21:43:33 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> From: Keith Moore Message-ID: <565D0945.1010005@network-heretics.com> Date: Mon, 30 Nov 2015 21:43:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] What Happened to UTF-8? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 02:43:35 -0000 On 11/29/2015 09:59 PM, John C Klensin wrote: > How would people feel about our simply going a half-step further > and saying something equivalent to "when characters outside the > ASCII repertoire are needed UTF-8 MUST be used as a basis for > coding and conversion, otherwise the rule are as specified in > RFC 3986". strongly opposed. I have yet to see that this is a problem that needs solving, and which won't harm URNs if we try to solve it. Keith From nobody Mon Nov 30 18:56:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402E21B3847 for ; Mon, 30 Nov 2015 18:56:34 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEM3ELTj5WLa for ; Mon, 30 Nov 2015 18:56:32 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E1D1B3844 for ; Mon, 30 Nov 2015 18:56:32 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BA2C520959 for ; Mon, 30 Nov 2015 21:56:31 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 30 Nov 2015 21:56:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=YKaEmOvMNdlC7P1y/kJP5bNqd3o=; b=nQSU4 l/TdgcSZ4vAjEDeUY0S2QyuEnXRHbwu5Ec5N/crOArSKSMunzlpZrW7JZtd7YP/0 sJZ4TXufqfjUyTzK4wmqTYObSHPXRdzToHuMYYkWh0u5PYJ1c0k99gR/+uWu/Tss ssTMYTahxYwZXDOaGT0VvysHHucutpxVR3p+WQ= X-Sasl-enc: f7HXa9mInET52bUkqIsvljDqzhLkRuw6jA7bTfSCjsk1 1448938591 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 5BCA7C016F0; Mon, 30 Nov 2015 21:56:31 -0500 (EST) To: urn@ietf.org References: <5657436C.6010305@seantek.com> <565A79C5.3070405@it.aoyama.ac.jp> <1E05E4F31732434D1C78736B@JcK-HP5.jck.com> <565B74FC.6070400@andyet.net> <34744C7E83150D15D4405C1A@JcK-HP5.jck.com> <565D0945.1010005@network-heretics.com> From: Keith Moore Message-ID: <565D0C50.1040604@network-heretics.com> Date: Mon, 30 Nov 2015 21:56:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565D0945.1010005@network-heretics.com> Content-Type: multipart/alternative; boundary="------------060309080809030501010300" Archived-At: Subject: [urn] fixing utf-8 language from 2141 (was: What Happened to UTF-8?) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 02:56:34 -0000 This is a multi-part message in MIME format. --------------060309080809030501010300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Ok, I'm looking at 2141 text regarding use of UTF-8 in NSS. I think it was a mistake for 2141 to mention UTF-8 at all, but trying to fix that now would be an even greater mistake. So it seems to me that the right thing to do going forward is to clarify 2141's language to be less ambiguous while still being consistent with 2141 and with all names assigned using 2141 rules. Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. IMO this is fine up to this point and should not be changed. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding [5], and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. The problem I see with this is that it's ambiguous. For many character encoding schemes there's not a single way to translate them into UTF-8, and different namespaces may have used different conventions. So the best thing I know to do at this point is to require any legacy namespace that assigns NSSs containing non-ASCII characters to specify the algorithm by which those characters are translated into UTF-8. Really this should be part of a general specification for translating legacy names into NSSs, because there are also cases in which a NSS might use an ASCII character that's not permitted by 2141 or 3986 syntax. Keith --------------060309080809030501010300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Ok, I'm looking at 2141 text regarding use of UTF-8 in NSS.   I think it was a mistake for 2141 to mention UTF-8 at all, but trying to fix that now would be an even greater mistake.   So it seems to me that the right thing to do going forward is to clarify 2141's language to be less ambiguous while still being consistent with 2141 and with all names assigned using 2141 rules.

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are not members of the URN
   character set above (<URN chars>).  Such strings MUST be translated
   into canonical NSS format before using them as protocol elements or
   otherwise passing them on to other applications.
IMO this is fine up to this point and should not be changed.

   Translation is done
   by encoding each character outside the URN character set as a
   sequence of one to six octets using UTF-8 encoding [5], and the
   encoding of each of those octets as "%" followed by two characters
   from the <hex> character set above. The two characters give the
   hexadecimal representation of that octet.

The problem I see with this is that it's ambiguous.  For many character encoding schemes there's not a single way to translate them into UTF-8, and different namespaces may have used different conventions.   So the best thing I know to do at this point is to require any legacy namespace that assigns NSSs containing non-ASCII characters to specify the algorithm by which those characters are translated into UTF-8.   Really this should be part of a general specification for translating legacy names into NSSs, because there are also cases in which a NSS might use an ASCII character that's not permitted by 2141 or 3986 syntax.

Keith

--------------060309080809030501010300-- From nobody Mon Nov 30 19:09:23 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19D71B3871 for ; Mon, 30 Nov 2015 19:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK340jkep12C for ; Mon, 30 Nov 2015 19:09:18 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF001B3870 for ; Mon, 30 Nov 2015 19:09:18 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 71A5A2056E for ; Mon, 30 Nov 2015 22:09:17 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 30 Nov 2015 22:09:17 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=USdYnWPWbVGLJZj tOlMgOn5EEJM=; b=uGcHrRVaBMl0MXeqfl+hHj6lOrlyLp9N4sYva0V9Z3Y1MHi e3ad4d1AR8px8Watq30tf4DVDlkKzHI6D1k1uGKdNFlTgpW5B0OWmcbl8X+vaRFn wZBdoM87mPiK4k9UIpKSygekqI1aloTop+s2/LLdIs/D4hyIry3XFQkFA72Q= X-Sasl-enc: yLf7MhTzV1IpPa9OujTTfUUn1Vf80mamLV4UY8PQM8Kq 1448939357 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 08BAF6800B6; Mon, 30 Nov 2015 22:09:16 -0500 (EST) To: urn@ietf.org References: <5655D134.9000600@seantek.com> From: Keith Moore Message-ID: <565D0F4D.50708@network-heretics.com> Date: Mon, 30 Nov 2015 22:09:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5655D134.9000600@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Consensus & terminology check: assigned-name (URN) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:09:19 -0000 On 11/25/2015 10:18 AM, Sean Leonard wrote: > This is a consensus check on our understanding of the NID : NSS > production. > > A urn: URI is parseable into the following components: > "urn:" > assigned-name > "?" > r-component > q-component > "#" > f-component > > (Forget about the specific order for the time being. The list above is > unordered.) > > Have we been using the following terms with a clear consensus of their > meanings? > > URN > assigned-name > urn: URI preface: I'm resigned to "URN" referring to the entire string consisting of prefix, assigned-name, r-, q-, and/or f-components, for the simple reason that I strongly suspect that users will insist on calling anything that begins with "urn:" a URN. This bothers me, because as you point out, the "name" is only the assigned portion, and a URN with r-, q-, and/or f-components attached isn't a pure name any more. But I tried to craft more precise language, on multiple occasions I believe (e.g. "augmented URN" for a URN with one or more of those components attached), and I couldn't even get this group to buy into it. If this group can't agree on something like that, getting the entire user community to use terms consistent with whatever we define is hopeless. > > When I think of "URN equivalence" (draft Section 4), it is only the > assigned-name production that is getting compared. q-component, > f-component, and r-component are not considered. When I read this, I find myself asking "equivalence for what purpose?" If you want to know if two URNs refer to the same resource, compare their assigned-names for equivalence. If you want to know if two URNs are equivalent for other purposes, say for caching of results, you could compare the entirety of both URNs. This wouldn't ensure that you got the same result, as nothing constrains either the resolution service or the resource itself to produce consistent results from one access to the next, but it might still be useful for short-term caching. (It's probably no worse than caching the results from GETs on HTTP URLs.) > It seems to me that is the Uniform Resource *Name*, which > we can (and ought) to call one of: assigned-name, Name, or URN. > q-component, r-component, and f-component are not *Name* parts. (I > believe that at one point, it was called the p-component during WG > discussion. Not sure if we want to call it that anymore.) > > Furthermore, the complete urn: URI syntax, including NID NSS > r-component q-component and f-component, is what can be called "urn: > URI". (But it can be called something else.) I don't think it will fly, for the reasons listed above. We should of course try to make the language in our documents precise and consistent within those documents. But I think the meaning of URN is going to inevitably be "a URI that begins with urn:" no matter what we say. > PS In -14-seantek, I redefined the assigned-name production so that it > excludes the "urn:" prefix. Look at the ABNF for details. If we want to be able to reference assigned-name in protocol specifications, e.g. in resolution protocols, it probably makes more sense to include the 'urn:' prefix than not. Keith