From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 07:48:52 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04711 for ; Thu, 2 Nov 2000 07:48:52 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA22759; Thu, 2 Nov 2000 07:47:46 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8622964 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 07:45:50 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA22261 for ; Thu, 2 Nov 2000 06:42:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16393; Thu, 2 Nov 2000 06:36:12 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200011021136.GAA16393@ietf.org> Date: Thu, 2 Nov 2000 06:36:12 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-dns-ddds-database-02.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : A DDDS Database Using The Domain Name System Author(s) : M. Mealling Filename : draft-ietf-urn-dns-ddds-database-02.txt Pages : 20 Date : 01-Nov-00 This document describes a Dynamic Delegation Discovery System Database using the Domain Name System as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the NAPTR Resource Record. Since this document officially obsoletes RFC 2168, it is the official specification for the NAPTR DNS Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-dns-ddds-database-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-dns-ddds-database-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143747.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 07:52:09 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05494 for ; Thu, 2 Nov 2000 07:52:09 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA22797; Thu, 2 Nov 2000 07:51:34 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8622967 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 07:50:10 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA22273 for ; Thu, 2 Nov 2000 06:42:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16421; Thu, 2 Nov 2000 06:36:16 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200011021136.GAA16421@ietf.org> Date: Thu, 2 Nov 2000 06:36:16 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-net-procedures-06.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Assignment Procedures for the URI Resolution using DNS Author(s) : M. Mealling Filename : draft-ietf-urn-net-procedures-06.txt Pages : 9 Date : 01-Nov-00 RFCYYYY defines a how DNS is used as a DDDS database that contains URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving 'http://foo.com/' would be to look up a NAPTR record for the domain 'http.URI.ARPA'. URN resolution also follows a similar procedure but uses the 'URN.ARPA' zone as its root. This document describes the procedures for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-net-procedures-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-net-procedures-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-net-procedures-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-net-procedures-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 07:54:59 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06177 for ; Thu, 2 Nov 2000 07:54:58 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA22857; Thu, 2 Nov 2000 07:54:23 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8622970 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 07:53:00 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA22285 for ; Thu, 2 Nov 2000 06:42:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16473; Thu, 2 Nov 2000 06:36:21 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200011021136.GAA16473@ietf.org> Date: Thu, 2 Nov 2000 06:36:21 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-ddds-03.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Dynamic Delegation Discovery System (DDDS) Author(s) : M. Mealling Filename : draft-ietf-urn-ddds-03.txt Pages : 17 Date : 01-Nov-00 This document describes the Dynamic Delegation Discovery System (DDDS). The DDDS defines an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This memo does not specify any application or database, although it does define the requirements for doing so. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-ddds-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-ddds-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-ddds-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-ddds-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143806.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 07:57:53 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06831 for ; Thu, 2 Nov 2000 07:57:52 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA22944; Thu, 2 Nov 2000 07:57:13 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8622973 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 07:55:50 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA22297 for ; Thu, 2 Nov 2000 06:42:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16592; Thu, 2 Nov 2000 06:36:40 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200011021136.GAA16592@ietf.org> Date: Thu, 2 Nov 2000 06:36:40 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-uri-res-ddds-02.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URI Resolution using the Dynamic Delegation Discovery System Author(s) : M. Mealling Filename : draft-ietf-urn-uri-res-ddds-02.txt Pages : 24 Date : 01-Nov-00 A specification for taking a URI and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document, along with RFC YYYY[10] and RFC ZZZZ[9], obsoletes RFC 2168[12], RFC 2915[16] and updates RFC 2276[8]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-uri-res-ddds-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-uri-res-ddds-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143817.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 09:25:56 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00875 for ; Thu, 2 Nov 2000 09:25:56 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA24799; Thu, 2 Nov 2000 09:25:02 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8623424 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 09:23:24 -0500 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA24790 for ; Thu, 2 Nov 2000 09:23:22 -0500 (EST) Received: from thinkingcat.com ([64.229.192.102]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001102141645.KSSK20301.tomts7-srv.bellnexxia.net@thinkingcat.com> for ; Thu, 2 Nov 2000 09:16:45 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A0176E8.C0934267@thinkingcat.com> Date: Thu, 2 Nov 2000 09:15:04 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Status of documents To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Hi all, The DDDS documents just published by the I-D editor reflect the changes from our last call (which closed Oct 6). I'm told that all the comments received were editorial, not substantive, so I will now forward the documents to the IESG for publication as RFCs. That leaves one remaining issue -- the proposed revision of RFC2611. At this point, we're waiting on me to incorporate the earlier remarks into a new version of the document -- I intend to get that circulated by the end of next week. Leslie. -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 15:15:47 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08297 for ; Thu, 2 Nov 2000 15:15:47 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA28216; Thu, 2 Nov 2000 15:14:57 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8624001 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 15:11:58 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from nl-imail01.cmg.nl (nl-mail-dmz.cmg-gecis.nl [195.109.155.100]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id OAA28105 for ; Thu, 2 Nov 2000 14:58:32 -0500 (EST) Received: FROM nl-iscan.cmg.nl BY nl-imail01.cmg.nl ; Thu Nov 02 20:44:29 2000 +0100 Received: FROM nl-amv-route01.cmg.nl BY nl-iscan.cmg.nl ; Thu Nov 02 20:37:25 2000 +0100 Received: from nl-irelay.cmg.nl (NL-IRELAY [10.16.67.60]) by nl-amv-route01.cmg.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WD5NSTR9; Thu, 2 Nov 2000 20:36:19 +0100 Received: from mail pickup service by nl-irelay.cmg.nl with Microsoft SMTPSVC; Thu, 2 Nov 2000 20:31:37 +0100 Received: from loki.ietf.org ([132.151.1.177]) by nl-irelay.cmg.nl with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 16:01:44 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA27033 for ietf-123-outbound.09@ietf.org; Thu, 2 Nov 2000 08:55:02 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26122 for ; Thu, 2 Nov 2000 06:36:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16393; Thu, 2 Nov 2000 06:36:12 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-OriginalArrivalTime: 02 Nov 2000 15:01:45.0323 (UTC) FILETIME=[D11DDBB0:01C044DD] Message-ID: <200011021136.GAA16393@ietf.org> Date: Thu, 2 Nov 2000 06:36:12 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-dns-ddds-database-02.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : A DDDS Database Using The Domain Name System Author(s) : M. Mealling Filename : draft-ietf-urn-dns-ddds-database-02.txt Pages : 20 Date : 01-Nov-00 This document describes a Dynamic Delegation Discovery System Database using the Domain Name System as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the NAPTR Resource Record. Since this document officially obsoletes RFC 2168, it is the official specification for the NAPTR DNS Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-dns-ddds-database-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-dns-ddds-database-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143747.I-D@ietf.org> --OtherAccess-- --NextPart-- --9B095B5ADSN=_01C044DC88685DA000000246nl?irelay.cmg.nl-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 16:17:05 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22771 for ; Thu, 2 Nov 2000 16:17:04 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA29425; Thu, 2 Nov 2000 16:16:13 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8624158 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 16:14:34 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from nl-imail01.cmg.nl (nl-mail-dmz.cmg-gecis.nl [195.109.155.100]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id QAA29114 for ; Thu, 2 Nov 2000 16:01:51 -0500 (EST) Received: FROM nl-iscan.cmg.nl BY nl-imail01.cmg.nl ; Thu Nov 02 21:24:44 2000 +0100 Received: FROM nl-amv-route01.cmg.nl BY nl-iscan.cmg.nl ; Thu Nov 02 21:01:03 2000 +0100 Received: from nl-irelay.cmg.nl (NL-IRELAY [10.16.67.60]) by nl-amv-route01.cmg.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WD5NS5MF; Thu, 2 Nov 2000 20:58:02 +0100 Received: from mail pickup service by nl-irelay.cmg.nl with Microsoft SMTPSVC; Thu, 2 Nov 2000 20:43:33 +0100 Received: from loki.ietf.org ([132.151.1.177]) by nl-irelay.cmg.nl with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 16:24:10 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA27187 for ietf-123-outbound.09@ietf.org; Thu, 2 Nov 2000 09:15:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26136 for ; Thu, 2 Nov 2000 06:36:22 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16473; Thu, 2 Nov 2000 06:36:21 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-OriginalArrivalTime: 02 Nov 2000 15:24:10.0858 (UTC) FILETIME=[F31E34A0:01C044E0] Message-ID: <200011021136.GAA16473@ietf.org> Date: Thu, 2 Nov 2000 06:36:21 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-ddds-03.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Dynamic Delegation Discovery System (DDDS) Author(s) : M. Mealling Filename : draft-ietf-urn-ddds-03.txt Pages : 17 Date : 01-Nov-00 This document describes the Dynamic Delegation Discovery System (DDDS). The DDDS defines an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This memo does not specify any application or database, although it does define the requirements for doing so. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-ddds-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-ddds-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-ddds-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-ddds-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143806.I-D@ietf.org> --OtherAccess-- --NextPart-- --9B095B5ADSN=_01C044DC88685DA000000A47nl?irelay.cmg.nl-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Nov 2 16:21:10 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23691 for ; Thu, 2 Nov 2000 16:21:09 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA29477; Thu, 2 Nov 2000 16:20:35 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8624161 for URN-IETF@LISTS.NETSOL.COM; Thu, 2 Nov 2000 16:19:08 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from nl-imail01.cmg.nl (nl-mail-dmz.cmg-gecis.nl [195.109.155.100]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id QAA29103 for ; Thu, 2 Nov 2000 16:01:46 -0500 (EST) Received: FROM nl-iscan.cmg.nl BY nl-imail01.cmg.nl ; Thu Nov 02 21:24:42 2000 +0100 Received: FROM nl-amv-route01.cmg.nl BY nl-iscan.cmg.nl ; Thu Nov 02 21:00:58 2000 +0100 Received: from nl-irelay.cmg.nl (NL-IRELAY [10.16.67.60]) by nl-amv-route01.cmg.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WD5NS5LS; Thu, 2 Nov 2000 20:58:00 +0100 Received: from mail pickup service by nl-irelay.cmg.nl with Microsoft SMTPSVC; Thu, 2 Nov 2000 20:40:14 +0100 Received: from loki.ietf.org ([132.151.1.177]) by nl-irelay.cmg.nl with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Nov 2000 17:00:36 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA27344 for ietf-123-outbound.09@ietf.org; Thu, 2 Nov 2000 09:35:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26150 for ; Thu, 2 Nov 2000 06:36:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16592; Thu, 2 Nov 2000 06:36:40 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-OriginalArrivalTime: 02 Nov 2000 16:00:36.0751 (UTC) FILETIME=[0A0301F0:01C044E6] Message-ID: <200011021136.GAA16592@ietf.org> Date: Thu, 2 Nov 2000 06:36:40 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-uri-res-ddds-02.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URI Resolution using the Dynamic Delegation Discovery System Author(s) : M. Mealling Filename : draft-ietf-urn-uri-res-ddds-02.txt Pages : 24 Date : 01-Nov-00 A specification for taking a URI and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document, along with RFC YYYY[10] and RFC ZZZZ[9], obsoletes RFC 2168[12], RFC 2915[16] and updates RFC 2276[8]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-uri-res-ddds-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001101143817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-uri-res-ddds-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001101143817.I-D@ietf.org> --OtherAccess-- --NextPart-- --9B095B5ADSN=_01C044DC88685DA0000014ACnl?irelay.cmg.nl-- From owner-urn-ietf@LISTS.NETSOL.COM Fri Nov 10 20:02:34 2000 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06491 for ; Fri, 10 Nov 2000 20:02:33 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id UAA09620; Fri, 10 Nov 2000 20:00:22 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8630532 for URN-IETF@LISTS.NETSOL.COM; Fri, 10 Nov 2000 19:59:28 -0500 Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA09587 for ; Fri, 10 Nov 2000 19:59:26 -0500 (EST) Received: from thinkingcat.com ([64.229.203.108]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001111005246.BNAP18376.tomts5-srv.bellnexxia.net@thinkingcat.com> for ; Fri, 10 Nov 2000 19:52:46 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------CE67F5452483290D3D497C13" Approved-By: Leslie Daigle Message-ID: <3A0C97DC.546CC338@thinkingcat.com> Date: Fri, 10 Nov 2000 19:50:36 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Revised RFC2611 To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. --------------CE67F5452483290D3D497C13 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Howdy, I've submitted a revised version of RFC2611 as an Internet-Draft; = I've attached a copy here, as it's going to take a few days to hit the repository. I've incorporated comments on the draft text, circulated earlier, as follows: Martin D=FCrst offered: > The text only speaks about an RFC, not about an I-D. Also, > it's not clear whether IESG approval or submission to > urn-nid@apps.ietf.org should be first, and in what form. Added Section 5.2, an illustration of the process. > >associated have openly-published APIs. > = > I'm a little bit confused by the word API here. Changed it to "access protocol". Let me know if you think it still needs work. Larry Masinter offered: > There are two components to your proposed revision that are > currently intermixed, that might be usefully separated out. Have pushed the "registration template" to the Appendix; Section 3.0 is now "registration types", and Section 4.0 is "registration process", with an attempt to make the delineation you suggested needed clarification. Keith Moore offered: > In general, URNs are not intended to have exposed structure beyond the > NID. This is because the structure by which URNs under a particular NI= D > are assigned, or resolved (the two are different) may change over time.= = I didn't see altogether where the document advocated inappropriate exposure of structure. Perhaps there needs to be clarification about what kinds of things might usefully be exposed to the public without compromising the name/structure dissociation? Or, see if it still seems to be a problem when you look at the document as a whole. As always -- comments welcome. I'm sure there are some editorial nits & 'roff-isms... Sigh. Leslie. -- = ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... = ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- --------------CE67F5452483290D3D497C13 Content-Type: text/plain; charset=iso-8859-1; name="rfc2611bis.out" Content-Disposition: inline; filename="rfc2611bis.out" Content-Transfer-Encoding: quoted-printable Internet-Draft L. Daigle URN WG Thinking Cat Enterprises Expires May 11, 2001 D. van Gulik Category: Best Current Practice WebWeaving draft-ietf-urn-rfc2611bis-00.txt R. Iannella DSTC Pty Ltd P. Faltstrom Cisco November 10, 2000 URN Namespace Definition Mechanisms Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt Abstract The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces". This document obsoletes RFC2611. Discussion of this document should be directed to urn-ietf@ietf.org Daigle [Page 1] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 Table of Contents Abstract ........................................................ 1 Table of Contents ............................................... 2 1.0 Introduction ................................................ 2 2.0 What is a URN Namespace? .................................... 3 3.0 URN Namespace (Registration) Types .......................... 3 3.1 Experimental Namespaces .................................... 4 3.2 Informal Namespaces ......................................... 4 3.3 Formal Namespaces ........................................... 4 4.0 URN Namespace Registration, Update, and NID Assignment Process ..................................................... 5 4.1 Experimental ................................................ 5 4.2 Informal .................................................... 6 4.3 Formal ...................................................... 6 5.0 Illustration ................................................ 8 5.1 Example Template ............................................ 8 5.1 Registration steps in practice .............................. 10 6.0 Security Considerations ..................................... 11 7.0 IANA Considerations ......................................... 11 8.0 References .................................................. 11 9.0 Authors' Addresses .......................................... 12 10.0 Appendix -- URN Namespace Definition Template .............. 13 1.0 Introduction Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. There are 2 assumptions that are key to this document: Assumption #1: Assignment of a URN is a managed process. I.e., not all strings that conform to URN syntax are necessarily valid URNs. A URN is assigned according to the rules of a particular namespace (in terms of syntax, semantics, and process). Assumption #2: The space of URN namespaces is managed. I.e., not all syntactically correct URN namespaces (per the URN syntax definition) are valid URN namespaces. A URN namespace must have a recognized definition in order to be valid. The purpose of this document is to outline a mechanism and provide a template for explicit namespace definition, along with the mechanism Daigle [Page 2] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 for associating an identifier (called a "Namespace ID", or NID) which is registered with the Internet Assigned Numbers Authority, IANA. Note that this document restricts itself to the description of processes for the creation of URN namespaces. If "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by the DDDS system [RFCXXXX], is necessary. See [RFCYYYY] for information on obtaining registration in the DDDS global NID directory. 2.0 What is a URN Namespace? For the purposes of URNs, a "namespace" is a collection of uniquely- assigned identifiers. A URN namespace itself has an identifier in order to - ensure global uniqueness of URNs - (where desired) provide a cue for the structure of the identifier For example, ISBNs and ISSNs are both collections of identifiers used in the traditional publishing world; while there may be some number (or numbers) that is both a valid ISBN identifier and ISSN identifier, using different designators for the two collections ensures that no two URNs will be the same for different resources. The development of an identifier structure, and thereby a collection of identifiers, is a process that is inherently dependent on the requirements of the community defining the identifier, how they will be assigned, and the uses to which they will be put. All of these issues are specific to the individual community seeking to define a namespace (e.g., publishing community, association of booksellers, protocol developers, etc); they are beyond the scope of the IETF URN work. This document outlines the processes by which a collection of identifiers satisfying certain constraints (uniqueness of assignment, etc) can become a bona fide URN namespace by obtaining a NID. In a nutshell, a template for the definition of the namespace is completed for deposit with IANA, and a NID is assigned. The details of the process and possibilities for NID strings are outlined below; first, a template for the definition is provided. 3.0 URN Namespace (Registration) Types There are 3 categories of URN namespaces defined here, Daigle [Page 3] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 distinguished by expected level of service and required procedures for registration. Registration processes for each of these namespace types are given in Section 4.0. 3.1 Experimental Namespaces These are not explicitly registered with IANA. They take the form X- No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. 3.2 Informal Namespaces These are fully fledged URN namespaces, with all the rights and requirements associated thereto. Informal namespaces can be registered in global registration services. They are required to uphold the general principles of a well-managed URN namespace -- providing persistent, unique identification of resources. Informal and formal namespaces (described below) differ in the NID assignment. IANA will assign an alphanumeric NID to registered informal namespaces, per the process outlined in Section 4.0. 3.3 Formal Namespaces A formal namespace may be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to an open and broad base of the Internet community. That is, as in any open standards outcome, publication of the NID proposal would allow persons not immediately associated with the proposer to create new software, or services, or otherwise better carry out their own activities than if the NID publication had not been made. Benefits are expected to be in the form of open accessibility, interoperability, etc. It is expected that Formal NIDs may be applied to namespaces where some aspects are not fully open. For example, a namespace may make use of an externally managed (proprietary) registry (as, e.g., ISBN does), for assignment of URNs in the namespace, but it may still provide broad community benefit if the services associated have openly-published access protocols. In addition to the basic registration information defined in the registration template (in the Appendix), a formal namespace request Daigle [Page 4] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 must be accompanied by documented considerations of the need for a new namespace and the community benefit of formally establishing the proposed URN namespace. Additionally, since the goal of URNs is to provide persistent identification, some consideration as to the longevity and maintainability of the namespace must be given. The URN WG discussed at length the issue of finding objective measures for predicting (a priori) the continued success of a namespace. No conclusion was reached -- much depends on factors that are completely beyond the technical scope of the namespace. However, the collective experience of the IETF community does contain a wealth of information on technical factors that will prevent longevity of identification. The IESG may elect not to publish a proposed namespace RFC if the IETF community consensus is that it contains technical flaws that will prevent (or seriously impair the possibility of) persistent identification. 4.0 URN Namespace Registration, Update, and NID Assignment Process Different levels of disclosure are expected/defined for namespaces. According to the level of open-forum discussion surrounding the disclosure, a URN namespace may be assigned or may request a particular identifier. The "IANA Considerations" document [RFC2434] suggests the need to specify update mechanisms for registrations -- who is given the authority to do so, from time to time, and what are the processes. Since URNs are meant to be persistently useful, few (if any) changes should be made to the structural interpretation of URN strings (e.g., adding or removing rules for lexical equivalence that might affect the interpretation of URN IDs already assigned). However, it may be important to introduce clarifications, expand the list of authorized URN assigners, etc, over the natural course of a namespace's lifetime. Specific processes are outlined below. URN namespace registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN- namespaces/". The registration and maintenance procedures vary slightly from one namespace type (as defined in Section 3.0) to another. 4.1 Experimental These are not explicitly registered with IANA. They take the form Daigle [Page 5] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 X- No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. As there is no registration, no registration maintenance procedures are needed. 4.2 Informal These are registered with IANA and are assigned a number sequence as an identifier, in the format: "urn-" where is chosen by the IANA on a First Come First Served basis (see [RFC2434]). Registrants should send a copy of the registration template (see the Appendix), duly completed, to the urn-nid@apps.ietf.org mailing and allow for a 2 week discussion period for clarifying the expression of the registration information and suggestions for improvements to the namespace proposal. After suggestions for clarification of the registration information have been incorporated, the template may be submitted to: iana@iana.org for assignment of a NID. The only restrictions on are that it consist strictly of digits and that it not cause the NID to exceed length limitations outlined in the URN syntax ([RFC2141]). Registrations may be updated by the original registrant, or an entity designated by the registrant, by updating the registration template, submitting it to the discussion list for a further 2 week discussion period, and finally resubmitting it to IANA, as described above. 4.3 Formal Daigle [Page 6] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]: "IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists)." Thus, the Formal NID application is made via publication of an RFC through standard IETF processes. The RFC need not be standards- track, but it will be subject to IESG review and acceptance pursuant to the guidelines written here (as well as standard RFC publication guidelines). The template defined in the Appendix may be included as part of an RFC defining some other aspect of the namespace, or it may be put forward as an RFC in its own right. The proposed template should be sent to the urn-nid@apps.ietf.org mailing list to allow for a 2 week discussion period for clarifying the expression of the registration information, before the IESG reviews the document. The RFC must include a "Namespace Considerations" section, which outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements). Considerations might include: - URN assignment procedures - URN resolution/delegation - type of resources to be identified - type of services to be supported NOTE: It is expected that more than one namespace may serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the IESG's consideration. The RFC must also include a "Community Considerations" section, which indicates the dimensions upon which the proposer expects the Internet community to be able to benefit by publication of this namespace. Potential considerations include: - open assignment and use of identifiers within the namespace - open operation of resolution servers for the namespace (server) - creation of software that can meaningfully resolve and access services for the namespace (client) Daigle [Page 7] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 A particular NID string is requested, and is assigned by IETF consensus (as defined in [RFC2434]), with the additional constraints that the NID string must - not be an already-registered NID - not start with "x-" (see Type I above) - not start with "urn-" (see Type II above) - not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below) - be more than 2 letters long NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters, are reserved for potential use as countrycode- based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such namespaces is beyond the scope of this document. Registrations may be revised by updating the RFC through standard IETF RFC update mechanisms. Thus, proposals for updates may be made by the original authors, other IETF participants, or the IESG. In any case, the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period. 5.0 Illustration 5.1 Example Template The following example is provided for the purposes of illustration of the URN NID template described in the Appendix. Although it is based on a hypothetical "generic Internet namespace" that has been discussed informally within the URN WG, there are still technical and infrastructural issues that would have to be resolved before such a namespace could be properly and completely described. Namespace ID: To be assigned Registration Information: Version 1 Date: Declared registrant of the namespace: Required: Name and e-mail address. Recommended: Affiliation, address, etc. Daigle [Page 8] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 Declared registrant of the namespace: Name: T. Cat E-mail: leslie@thinkingcat.com Affiliation: Thinking Cat Enterprises Address: 1 ThinkingCat Way Trupville, NewCountry Declaration of structure: The identifier structure is as follows: URN::: where FQDN is a fully-qualified domain name, and the assigned string is conformant to URN syntax requirements. Relevant ancillary documentation: Definition of domain names, found in: P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC1035, November 1987. Identifier uniqueness considerations: Uniqueness is guaranteed as long as the assigned string is never reassigned for a given FQDN, and that the FQDN is never reassigned. N.B.: operationally, there is nothing that prevents a domain name from being reassigned; indeed, it is not an uncommon occurrence. This is one of the reasons that this example makes a poor URN namespace in practice, and is therefore not seriously being proposed as it stands. Identifier persistence considerations: Persistence of identifiers is dependent upon suitable delegation of resolution at the level of "FQDN"s, and persistence of FQDN assignment. Same note as above. Process of identifier assignment: Assignment of these URNs delegated to individual domain name holders (for FQDNs). The holder of the FQDN registration is Daigle [Page 9] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 required to maintain an entry (or delegate it) in the DDDS. Within each of these delegated name partitions, the string may be assigned per local requirements. e.g. urn::thinkingcat.com:001203 Process for identifier resolution: Domain name holders are responsible for operating or delegating resolution servers for the FQDN in which they have assigned URNs. Rules for Lexical Equivalence: FQDNs are case-insensitive. Thus, the portion of the URN urn::: is case-insenstive for matches. The remainder of the identifier must be considered case-sensitve. Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. Scope: Global. 5.1 Registration steps in practice The key steps for registration of informal or formal namespaces typically play out as follows: Informal NID: 1. Complete the registration template. This may be done as part of an Internet-Draft. 2. Communicate the registration template to urn-nid@apps.ietf.org for technical review -- as a published I-D, or text e-mail message containing the template. 3. Update the registration template as necessary from comments, and Daigle [Page 10] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 repeat steps 2 and 3 as necessary. 4. Once comments have been addressed (and the review period has expired) end a request to IANA with the revised registration template. Formal NID: 1. Write an Internet-Draft describing the namespace and including the registration template, duly completed. 2. Send the Internet-Draft to the I-D editor, and send a copy to urn-nid@apps.ietf.org for technical review. 3. Update the Internet-Draft as necessary from comments, and repeat steps 2 and 3 as needed. 4. Send a request to the IESG to publish the I-D as an RFC. The IESG may request further changes (published as I-D revisions) and/or direct discussion to designated working groups, area experts, etc. 5. If the IESG approves the document for publication as an RFC, send a request to IANA to register the requested NID. 6.0 Security Considerations This document largely focuses on providing mechanisms for the declaration of public information. Nominally, these declarations should be of relatively low security profile, however there is always the danger of "spoofing" and providing mis-information. Information in these declarations should be taken as advisory. 7.0 IANA Considerations This document outlines the processes for registering URN namespaces, and has implications for the IANA in terms of registries to be maintained. In all cases, the IANA should assign the appropriate NID (informal or formal), as described above, once an IESG-designated expert has confirmed that the requisite registration process steps have been completed. 8.0 References Daigle [Page 11] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times" [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing Bibliographic Identifiers as Uniform Resource Names", RFC 2288, February 1998. [RFCXXXX] Mealling, M., "URI Resolution using the Dynamic Delegation Discovery System", RFCXXXX. [RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution Using DNS", RFCYYYY. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994. [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. 9.0 Authors' Addresses Leslie L. Daigle Thinking Cat Enterprises EMail: leslie@thinkingcat.com Dirk-Willem van Gulik WebWeaving Plein 1813 - 5a 8545 HX Arnhem The Netherlands Phone: +39 0332 78 0014 (Phone and Fax) EMail: Dirkx@webweaving.org Renato Iannella DSTC Pty Ltd Gehrmann Labs, The Uni of Queensland Daigle [Page 12] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 AUSTRALIA, 4072 Phone: +61 7 3365 4310 Fax: +61 7 3365 4311 EMail: renato@dstc.edu.au Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose CA 95134 USA EMail: paf@cisco.com URL: http://www.cisco.com 10.0 Appendix -- URN Namespace Definition Template Definition of a URN namespace is accomplished by completing the following information template. Apart from providing a mechanism for disclosing structure of the URN namespace, this information is designed to be useful for - entities seeking to have a URN assigned in a namespace (if applicable) - entities seeking to provide URN resolvers for a namespace (if applicable) This is particularly important for communities evaluating the possibility of using a portion of an existing URN namespace rather than creating their own. Information in the template is as follows: Namespace ID: Assigned by IANA. In some contexts, a particular one may be requested (see below). Registration Information: This is information to identify the particular version of registration information: - registration version number: starting with 1, incrementing by 1 with each new version - registration date: date submitted to the IANA, using the format Daigle [Page 13] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 YYYY-MM-DD as outlined in [ISO8601]. Declared registrant of the namespace: Required: Name and e-mail address. Recommended: Affiliation, address, etc. Declaration of syntactic structure: This section should outline any structural features of identifiers in this namespace. At the very least, this description may be used to introduce terminology used in other sections. This structure may also be used for determining realistic caching/shortcuts approaches; suitable caveats should be provided. If there are any specific character encoding rules (e.g., which character should always be used for single-quotes), these should be listed here. Answers might include, but are not limited to: - the structure is opaque (no exposition) - a regular expression for parsing the identifier into components, including naming authorities Relevant ancillary documentation: This section should list any RFCs, standards, or other published documentation that defines or explains all or part of the namespace structure. Answers might include, but are not limited to: - RFCs outlining syntax of the namespace - Other of the defining community's (e.g., ISO) documents outlining syntax of the identifiers in the namespace - Explanatory material introducing the namespace Identifier uniqueness considerations: This section should address the requirement that URN identifiers be assigned uniquely -- they are assigned to at most one resource, and are not reassigned. (Note that the definition of "resource" is fairly broad; for example, information on "Today's Weather" might be considered a single resource, although the content is dynamic.) Possible answers include, but are not limited to: Daigle [Page 14] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 - exposition of the structure of the identifiers, and partitioning of the space of identifiers amongst assignment authorities which are individually responsible for respecting uniqueness rules - identifiers are assigned sequentially - information is withheld; the namespace is opaque Identifier persistence considerations: Although non-reassignment of URN identifiers ensures that a URN will persist in identifying a particular resource even after the "lifetime of the resource", some consideration should be given to the persistence of the usability of the URN. This is particularly important in the case of URN namespaces providing global resolution. Possible answers include, but are not limited to: - quality of service considerations Process of identifier assignment: This section should detail the mechanisms and/or authorities for assigning URNs to resources. It should make clear whether assignment is completely open, or if limited, how to become an assigner of identifiers, and/or get one assigned by existing assignment authorities. Answers could include, but are not limited to: - assignment is completely open, following a particular algorithm - assignment is delegated to authorities recognized by a particular organization (e.g., the Digital Object Identifier Foundation controls the DOI assignment space and its delegation) - assignment is completely closed (e.g., for a private organization) Process for identifier resolution: If a namespace is intended to be accessible for global resolution, it must be registerd in an RDS (Resolution Discovery System, see [RFC2276]) such as DDDS. Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RDS. What this section should outline is the requirements for becoming a recognized resolver of URNs in this namespace (and being so- listed in the RDS registry). Answers may include, but are not limited to: - the namespace is not listed with an RDS; this is not relevant Daigle [Page 15] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 - resolution mirroring is completely open, with a mechanism for updating an appropriate RDS - resolution is controlled by entities to which assignment has been delegated Rules for Lexical Equivalence: If there are particular algorithms for determining equivalence between two identifiers in the underlying namespace (hence, in the URN string itself), rules can be provided here. Some examples include: - equivalence between hyphenated and non-hyphenated groupings in the identifier string - equivalence between single-quotes and double-quotes - Namespace-defined equivalences between specific characters, such as "character X with or without diacritic marks". Note that these are not normative statements for any kind of best practice for handling equivalences between characters; they are statements limited to reflecting the namespace's own rules. Conformance with URN Syntax: This section should outline any special considerations required for conforming with the URN syntax. This is particularly applicable in the case of legacy naming systems that are used in the context of URNs. For example, if a namespace is used in contexts other than URNs, it may make use of characters that are reserved in the URN syntax. This section should flag any such characters, and outline necessary mappings to conform to URN syntax. Normally, this will be handled by hex encoding the symbol. For example, see the section on SICIs in [RFC2288]. Validation mechanism: Apart from attempting resolution of a URN, a URN namespace may provide mechanism for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. For example, even if an ISBN URN namespace is created, it is not clear that all ISBNs will translate directly into "assigned URNs". A validation mechanims might be: Daigle [Page 16] =0C Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 - a syntax grammar - an on-line service - an off-line service Scope: This section should outline the scope of the use of the identifiers in this namespace. Apart from considerations of private vs. public namespaces, this section is critical in evaluating the applicability of a requested NID. For example, a namespace claiming to deal in "social security numbers" should have a global scope and address all social security number structures (unlikely). On the other hand, at a national level, it is reasonable to propose a URN namespace for "this nation's social security numbers". Daigle [Page 17] =0C --------------CE67F5452483290D3D497C13-- From owner-urn-ietf@LISTS.NETSOL.COM Tue Nov 14 08:42:03 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19385 for ; Tue, 14 Nov 2000 08:42:02 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA12564; Tue, 14 Nov 2000 08:40:24 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8634354 for URN-IETF@LISTS.NETSOL.COM; Tue, 14 Nov 2000 08:39:04 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA11999 for ; Tue, 14 Nov 2000 06:51:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10039; Tue, 14 Nov 2000 06:45:07 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200011141145.GAA10039@ietf.org> Date: Tue, 14 Nov 2000 06:45:07 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-rfc2611bis-00.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Namespace Definition Mechanisms Author(s) : L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom Filename : draft-ietf-urn-rfc2611bis-00.txt Pages : 17 Date : 13-Nov-00 The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole rests on the concept of individual 'namespaces' within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN 'namespaces'. This document obsoletes RFC2611. Discussion of this document should be directed to urn-ietf@ietf.org A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-rfc2611bis-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-rfc2611bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-rfc2611bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001113134848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-rfc2611bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-rfc2611bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001113134848.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Fri Nov 17 17:56:44 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14177 for ; Fri, 17 Nov 2000 17:56:44 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA20910; Fri, 17 Nov 2000 17:55:26 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8639989 for URN-IETF@LISTS.NETSOL.COM; Fri, 17 Nov 2000 17:53:38 -0500 Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA20900 for ; Fri, 17 Nov 2000 17:53:37 -0500 (EST) Received: from thinkingcat.com ([64.229.192.73]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001117224701.LWRM625.tomts8-srv.bellnexxia.net@thinkingcat.com> for ; Fri, 17 Nov 2000 17:47:01 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A0C97DC.546CC338@thinkingcat.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by lists.netsol.com id RAA20901 Approved-By: Leslie Daigle Message-ID: <3A15B4CD.D98053E1@thinkingcat.com> Date: Fri, 17 Nov 2000 17:44:29 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Re: Revised RFC2611 To: URN-IETF@LISTS.NETSOL.COM X-MIME-Autoconverted: from 8bit to quoted-printable by lists.netsol.com id RAA20910 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA14177 So, the draft has in fact hit the repository, as draft-ietf-urn-rfc2611bis-00.txt I realize that we're getting into the hectic holiday/pre-IETF timeframe, but I'd like some feedback from people to determine consensus on which of the following is (most) true: . "this is in line with what we discussed, we're done" . "started to read it, had some comments, but couldn't possibly get to it all this week, give us two more weeks (to Dec 1) to read and comment" I don't want to rush people, and I'd like to know if people believe that alotting more time would produce a better result. Otherwise, or if people are ambivalent, we can last call the document now and have it to the IESG before the end of the year. Thanks, Leslie. Leslie Daigle wrote: > > Howdy, > > I've submitted a revised version of RFC2611 as an Internet-Draft; > I've attached a copy here, as it's going to take a few days to > hit the repository. > > I've incorporated comments on the draft text, circulated earlier, > as follows: > > Martin Dürst offered: > > The text only speaks about an RFC, not about an I-D. Also, > > it's not clear whether IESG approval or submission to > > urn-nid@apps.ietf.org should be first, and in what form. > > Added Section 5.2, an illustration of the process. > > > >associated have openly-published APIs. > > > > I'm a little bit confused by the word API here. > > Changed it to "access protocol". Let me know if you think it still > needs work. > > Larry Masinter offered: > > There are two components to your proposed revision that are > > currently intermixed, that might be usefully separated out. > > Have pushed the "registration template" to the Appendix; Section 3.0 > is now "registration types", and Section 4.0 is "registration process", > with an attempt to make the delineation you suggested needed > clarification. > > Keith Moore offered: > > In general, URNs are not intended to have exposed structure beyond the > > NID. This is because the structure by which URNs under a particular NID > > are assigned, or resolved (the two are different) may change over time. > > I didn't see altogether where the document advocated inappropriate > exposure of structure. Perhaps there needs to be clarification about > what kinds of things might usefully be exposed to the public > without compromising the name/structure dissociation? Or, see if > it still seems to be a problem when you look at the document > as a whole. > > As always -- comments welcome. I'm sure there are some editorial > nits & 'roff-isms... Sigh. > > Leslie. > > -- > > ------------------------------------------------------------------- > "Reality with a delicate splash of the imaginary... > ... or was that the other way around?" > -- ThinkingCat > > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- -- ------------------------------------------------------------------- "Logic can hold only a certain amount of sway over the rational mind." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Fri Nov 17 17:59:28 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14281 for ; Fri, 17 Nov 2000 17:59:28 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA21015; Fri, 17 Nov 2000 17:58:48 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8640004 for URN-IETF@LISTS.NETSOL.COM; Fri, 17 Nov 2000 17:57:25 -0500 Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA20966 for ; Fri, 17 Nov 2000 17:57:24 -0500 (EST) Received: from thinkingcat.com ([64.229.192.73]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001117225047.LXLZ625.tomts8-srv.bellnexxia.net@thinkingcat.com> for ; Fri, 17 Nov 2000 17:50:47 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A15B5B0.8BF705F3@thinkingcat.com> Date: Fri, 17 Nov 2000 17:48:16 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Related BoFs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, FYI, I draw your attention to the various content/caching/resolution bofs to be held in San Diego on Tuesday afternoon. In particular, this one tackles something of the converse of URN (global) resolution, and is currently scheduled for Tuesday, 5pm-6pm. Leslie. -----------8<----------------8<----------------8<-------------- Contextualization of Resolution BOF (c15n) Day, Date at Time ============================== CHAIR: Michael Mealling DESCRIPTION: The URN WG's Dynamic Delegation Discovery System (DDDS) describes a generalized architecture for 'top down' resolution of identifiers such as URIs. This works well when a (software) client wants or needs to dynamically determine the explicit authoritative delegation of resolution. However, there are times when it is desirable to incorporate other elements of contextual control information in determining, for example, the "appropriate copy" of a resource -- preferrentially finding a "local" copy of a journal rather than (re)purchasing one from the authoritative publisher. This is generally applicable to all URI resolution, but it is more specific than "web caching". Software systems being built to solve this in today's deployed systems are using specialized, non-interoperable, non- scalable approaches. Some current experimentation and a straw proposal are described below. This BoF is chartered to determine if there is interest/wherewithal to determine a standard vehicle to process contextualized resolution that a) is not application- or protocol-specific and b) ties in with global resolution systems (such as DDDS) in order to preserve authoritative resolution chains, where applicable Beyond the "appropriate copy" scenario, this should equally be applicable in non-document contexts -- e.g., IP-telephony (enterprise dialing schemes taking precedence over, but linked to, global numbering). While the focus of this BoF is on standardized resolution steps/mechanisms, not "metadata" or "knowledge transactions", discussion must reflect that "context" generalizes beyond location/area (e.g., to "who's paying for this", etc). AGENDA: . Agenda bashing [2 min] . Introduction/Overview of C15N [10min] . Discussion of Straw Proposal (below) [20min] . Relationship to other work -- at IETF, W3C, etc [5min] . Discussion of proposed charter [20min] . Yes/no All of the above should be considered in relation to the web-caching, proxying, and content-delivery BoFs also occurring this week (OPES, CDNP, WEBI). Sample current implementation ----------------------------- Some experiments have been carried out elsewhere -- e.g., the SFX project described at: http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html and in http://www.doi.org/workshop_19sep00/doi_wkshp_0900_llversion.ppt Today, this work uses HTTP cookies -- so that the (web) client asks the global resolution for an identifier (from a reference), and sends a cookie which is a key for the appropriate context. The global system uses this key to redirect the query to the appcopriate local knowledge server (address), which makes the judgement about where an appropriate copy of the resource shall be obtained. Straw proposal -------------- As the starting point for discussion of how to solve this problem, we propose the following optional additional steps for resolving URIs in a contextualized fashion: There are 3 primary elements: . context object -- the identifier and some description of context . local knowledge server [_not_ defined by us, or even by application; rather, we define the abstract operations for interacting with it] . application linkage to a global resolution authority (e.g., DDDS for URNs, http resolution standard, etc) In order to ground the discussion in some semi-concrete proposal a strawman proposal based on XLink for link typing and RDF for context object expression will be used. In this case, the extended XLink would relate three resources - the local resource, the desired remote resource, and the RDF info containing the context. Each locator will have a typed arc that determines the types of traversals available. Additional discussion may include how this context object may be passed to various proxies/caches for resolution based on that context -- strictly as a tie-in with other replication, caching and content delivery work under discussion at the IETF. Xlink is described at http://www.w3.org/XML/Linking RDF is described at http://www.w3.org/RDF/ Open questions -------------- These currently include: . Can/should this be transparent to the client software, or must/should it be an external negotiation in a separate protocol? . Is this configured or dynamically controlled? . Is this "get appropriate copy", or "get appropriate transformation" (i.e., to a new identifier, appropriately contextualized) . Can this support multiple, overlapping contexts (e.g., location and "who's paying for this") -- ------------------------------------------------------------------- "Logic can hold only a certain amount of sway over the rational mind." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Fri Nov 17 18:18:31 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14574 for ; Fri, 17 Nov 2000 18:18:30 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA21584; Fri, 17 Nov 2000 18:17:47 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8640128 for URN-IETF@LISTS.NETSOL.COM; Fri, 17 Nov 2000 18:16:24 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA21563 for ; Fri, 17 Nov 2000 18:16:22 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id SAA01684; Fri, 17 Nov 2000 18:00:11 -0500 (EST) References: <3A0C97DC.546CC338@thinkingcat.com> <3A15B4CD.D98053E1@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20001117180011.B1601@bailey.dscga.com> Date: Fri, 17 Nov 2000 18:00:11 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Revised RFC2611 To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3A15B4CD.D98053E1@thinkingcat.com>; from leslie@thinkingcat.com on Fri, Nov 17, 2000 at 05:44:29PM -0500 On Fri, Nov 17, 2000 at 05:44:29PM -0500, Leslie Daigle wrote: > draft-ietf-urn-rfc2611bis-00.txt > I realize that we're getting into the hectic holiday/pre-IETF > timeframe, but I'd like some feedback from people to determine > consensus on which of the following is (most) true: > > . "this is in line with what we discussed, we're done" > > . "started to read it, had some comments, but couldn't > possibly get to it all this week, give us two > more weeks (to Dec 1) to read and comment" I think its pretty much in line. I need to add a "Community Considerations" section to my outstanding documents but that's no big issue... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Sat Nov 18 21:14:12 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17876 for ; Sat, 18 Nov 2000 21:14:12 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id VAA02277; Sat, 18 Nov 2000 21:12:39 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8641316 for URN-IETF@LISTS.NETSOL.COM; Sat, 18 Nov 2000 21:10:47 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from nienie.mobile.webweaving.org (w149.z064000151.sjc-ca.dsl.cnc.net [64.0.151.149]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA01576 for ; Sat, 18 Nov 2000 19:14:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nienie.mobile.webweaving.org (8.11.1/8.11.1) with ESMTP id eAJ07fv19598; Sat, 18 Nov 2000 16:07:41 -0800 (PST) (envelope-from dirkx@covalent.net) X-Sender: dirkx@localhost MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Message-ID: Date: Sat, 18 Nov 2000 16:07:41 -0800 Reply-To: Dirk-Willem van Gulik From: Dirk-Willem van Gulik Subject: Re: Revised RFC2611 To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3A15B4CD.D98053E1@thinkingcat.com> X-MIME-Autoconverted: from 8bit to quoted-printable by lists.netsol.com id VAA02277 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA17876 Looks good. I am wondering if I should propose adding a small blurp about i18n and why the URN very intentionally is a URN::: and that very intentionally UTF8 or anything like that is not possible. And why that is a 'good' thing. Secondly - we could tighten up the assigned-US-ASCII-string a bit -as obviously the URI rules do not permit just any US-ASCII char. Nor would I want this. Dw On Fri, 17 Nov 2000, Leslie Daigle wrote: > So, the draft has in fact hit the repository, as > > draft-ietf-urn-rfc2611bis-00.txt > > I realize that we're getting into the hectic holiday/pre-IETF > timeframe, but I'd like some feedback from people to determine > consensus on which of the following is (most) true: > > . "this is in line with what we discussed, we're done" > > . "started to read it, had some comments, but couldn't > possibly get to it all this week, give us two > more weeks (to Dec 1) to read and comment" > > I don't want to rush people, and I'd like to know if people believe > that alotting more time would produce a better result. Otherwise, > or if people are ambivalent, we can last call the document now and > have it to the IESG before the end of the year. > > > Thanks, > Leslie. > > > Leslie Daigle wrote: > > > > Howdy, > > > > I've submitted a revised version of RFC2611 as an Internet-Draft; > > I've attached a copy here, as it's going to take a few days to > > hit the repository. > > > > I've incorporated comments on the draft text, circulated earlier, > > as follows: > > > > Martin Dürst offered: > > > The text only speaks about an RFC, not about an I-D. Also, > > > it's not clear whether IESG approval or submission to > > > urn-nid@apps.ietf.org should be first, and in what form. > > > > Added Section 5.2, an illustration of the process. > > > > > >associated have openly-published APIs. > > > > > > I'm a little bit confused by the word API here. > > > > Changed it to "access protocol". Let me know if you think it still > > needs work. > > > > Larry Masinter offered: > > > There are two components to your proposed revision that are > > > currently intermixed, that might be usefully separated out. > > > > Have pushed the "registration template" to the Appendix; Section 3.0 > > is now "registration types", and Section 4.0 is "registration process", > > with an attempt to make the delineation you suggested needed > > clarification. > > > > Keith Moore offered: > > > In general, URNs are not intended to have exposed structure beyond the > > > NID. This is because the structure by which URNs under a particular NID > > > are assigned, or resolved (the two are different) may change over time. > > > > I didn't see altogether where the document advocated inappropriate > > exposure of structure. Perhaps there needs to be clarification about > > what kinds of things might usefully be exposed to the public > > without compromising the name/structure dissociation? Or, see if > > it still seems to be a problem when you look at the document > > as a whole. > > > > As always -- comments welcome. I'm sure there are some editorial > > nits & 'roff-isms... Sigh. > > > > Leslie. > > > > -- > > > > ------------------------------------------------------------------- > > "Reality with a delicate splash of the imaginary... > > ... or was that the other way around?" > > -- ThinkingCat > > > > Leslie Daigle > > leslie@thinkingcat.com > > ------------------------------------------------------------------- > > -- > > ------------------------------------------------------------------- > "Logic can hold only a certain amount of sway over the rational > mind." > -- ThinkingCat > > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > From owner-urn-ietf@LISTS.NETSOL.COM Fri Nov 24 21:08:58 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19986 for ; Fri, 24 Nov 2000 21:08:58 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id VAA12912; Fri, 24 Nov 2000 21:04:30 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8652048 for URN-IETF@LISTS.NETSOL.COM; Fri, 24 Nov 2000 21:03:31 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id UAA12409 for ; Fri, 24 Nov 2000 20:01:25 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08926; Fri, 24 Nov 2000 19:55:16 -0500 (EST) Message-ID: <200011250055.TAA08926@ietf.org> Date: Fri, 24 Nov 2000 19:55:16 -0500 Reply-To: iesg@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: Dynamic Delegation Discovery System (DDDS) to Proposed Standard To: URN-IETF@LISTS.NETSOL.COM The IESG has received a request from the Uniform Resource Names Working Group to consider the following Internet-Drafts as Proposed Standards: o Dynamic Delegation Discovery System (DDDS) o A DDDS Database Using The Domain Name System o URI Resolution using the Dynamic Delegation Discovery System Together, they will obsolete RFC2915 and RFC2168. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-03.txt http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt From owner-urn-ietf@LISTS.NETSOL.COM Fri Nov 24 21:21:01 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23011 for ; Fri, 24 Nov 2000 21:21:01 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id VAA13275; Fri, 24 Nov 2000 21:18:35 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8652068 for URN-IETF@LISTS.NETSOL.COM; Fri, 24 Nov 2000 21:18:24 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id UAA12844 for ; Fri, 24 Nov 2000 20:54:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16209; Fri, 24 Nov 2000 20:47:56 -0500 (EST) Message-ID: <200011250147.UAA16209@ietf.org> Date: Fri, 24 Nov 2000 20:47:56 -0500 Reply-To: iesg@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: Assignment Procedures for the URI Resolution using DNS to BCP To: URN-IETF@LISTS.NETSOL.COM The IESG has received a request from the Uniform Resource Names Working Group to consider Assignment Procedures for the URI Resolution using DNS as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-06.txt From owner-urn-ietf@LISTS.NETSOL.COM Sat Nov 25 23:02:40 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08383 for ; Sat, 25 Nov 2000 23:02:40 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id XAA22342; Sat, 25 Nov 2000 23:01:09 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8653099 for URN-IETF@LISTS.NETSOL.COM; Sat, 25 Nov 2000 22:59:21 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA22235 for ; Sat, 25 Nov 2000 22:41:37 -0500 (EST) Received: from enoshima (nmd.rsh.bos.wayport.net [64.134.0.2]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id MAA01178; Sun, 26 Nov 2000 12:35:38 +0900 (JST) X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J References: <3A15B4CD.D98053E1@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4.2.0.58.J.20001126122639.0373f8c0@sh.w3.mag.keio.ac.jp> Date: Sun, 26 Nov 2000 12:30:17 +0900 Reply-To: "Martin J. Duerst" From: "Martin J. Duerst" Subject: Re: Revised RFC2611 To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Content-Transfer-Encoding: 7bit I'm a bit confused here. The only place I found is as part of an example. I don't think we need such explanations for just an example. The URN syntax draft defines exactly how non-ASCII characters get encoded into URN syntax if that has to be done. Anyway, there is still some inconsistency in that area of the draft: >>>> 5.0 Illustration 5.1 Example Template The following example is provided for the purposes of illustration of the URN NID template described in the Appendix. Although it is based on a hypothetical "generic Internet namespace" that has been discussed informally within the URN WG, there are still technical and infrastructural issues that would have to be resolved before such a namespace could be properly and completely described. Namespace ID: To be assigned Registration Information: Version 1 Date: Declared registrant of the namespace: Required: Name and e-mail address. Recommended: Affiliation, address, etc. Daigle [Page 8] Internet-Draft draft-ietf-urn-rfc2611bis-00.txt November 2000 Declared registrant of the namespace: Name: T. Cat E-mail: leslie@thinkingcat.com Affiliation: Thinking Cat Enterprises Address: 1 ThinkingCat Way Trupville, NewCountry <<<< "Declared registrant of the namespace:" appears twice, and there is an unmotivated change from a template to an example. Regards, Martin. At 00/11/18 16:07 -0800, Dirk-Willem van Gulik wrote: >Looks good. I am wondering if I should propose adding a small blurp >about i18n and why the URN very intentionally is a > > URN::: > >and that very intentionally UTF8 or anything like that is not >possible. And why that is a 'good' thing. > >Secondly - we could tighten up the assigned-US-ASCII-string a bit -as >obviously the URI rules do not permit just any US-ASCII char. Nor would I >want this. > >Dw > >On Fri, 17 Nov 2000, Leslie Daigle wrote: > > > So, the draft has in fact hit the repository, as > > > > draft-ietf-urn-rfc2611bis-00.txt > > > > I realize that we're getting into the hectic holiday/pre-IETF > > timeframe, but I'd like some feedback from people to determine > > consensus on which of the following is (most) true: > > > > . "this is in line with what we discussed, we're done" > > > > . "started to read it, had some comments, but couldn't > > possibly get to it all this week, give us two > > more weeks (to Dec 1) to read and comment" > > > > I don't want to rush people, and I'd like to know if people believe > > that alotting more time would produce a better result. Otherwise, > > or if people are ambivalent, we can last call the document now and > > have it to the IESG before the end of the year. > > > > > > Thanks, > > Leslie. > > > > > > Leslie Daigle wrote: > > > > > > Howdy, > > > > > > I've submitted a revised version of RFC2611 as an Internet-Draft; > > > I've attached a copy here, as it's going to take a few days to > > > hit the repository. > > > > > > I've incorporated comments on the draft text, circulated earlier, > > > as follows: > > > > > > Martin D $B|r (Bst offered: > > > > The text only speaks about an RFC, not about an I-D. Also, > > > > it's not clear whether IESG approval or submission to > > > > urn-nid@apps.ietf.org should be first, and in what form. > > > > > > Added Section 5.2, an illustration of the process. > > > > > > > >associated have openly-published APIs. > > > > > > > > I'm a little bit confused by the word API here. > > > > > > Changed it to "access protocol". Let me know if you think it still > > > needs work. > > > > > > Larry Masinter offered: > > > > There are two components to your proposed revision that are > > > > currently intermixed, that might be usefully separated out. > > > > > > Have pushed the "registration template" to the Appendix; Section 3.0 > > > is now "registration types", and Section 4.0 is "registration process", > > > with an attempt to make the delineation you suggested needed > > > clarification. > > > > > > Keith Moore offered: > > > > In general, URNs are not intended to have exposed structure beyond the > > > > NID. This is because the structure by which URNs under a > particular NID > > > > are assigned, or resolved (the two are different) may change over time. > > > > > > I didn't see altogether where the document advocated inappropriate > > > exposure of structure. Perhaps there needs to be clarification about > > > what kinds of things might usefully be exposed to the public > > > without compromising the name/structure dissociation? Or, see if > > > it still seems to be a problem when you look at the document > > > as a whole. > > > > > > As always -- comments welcome. I'm sure there are some editorial > > > nits & 'roff-isms... Sigh. > > > > > > Leslie. > > > > > > -- > > > > > > ------------------------------------------------------------------- > > > "Reality with a delicate splash of the imaginary... > > > ... or was that the other way around?" > > > -- ThinkingCat > > > > > > Leslie Daigle > > > leslie@thinkingcat.com > > > ------------------------------------------------------------------- > > > > -- > > > > ------------------------------------------------------------------- > > "Logic can hold only a certain amount of sway over the rational > > mind." > > -- ThinkingCat > > > > Leslie Daigle > > leslie@thinkingcat.com > > ------------------------------------------------------------------- > > From owner-urn-ietf@LISTS.NETSOL.COM Sun Nov 26 20:21:16 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19492 for ; Sun, 26 Nov 2000 20:21:16 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id UAA01293; Sun, 26 Nov 2000 20:18:35 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8654232 for URN-IETF@LISTS.NETSOL.COM; Sun, 26 Nov 2000 20:16:38 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA00956 for ; Sun, 26 Nov 2000 19:22:15 -0500 (EST) Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA10341; Mon, 27 Nov 2000 09:08:54 +0859 X-Mailer: ELM [version 2.4ME+ PL68 (25)] Message-ID: <200011270009.JAA10341@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Nov 2000 09:08:51 +0859 Reply-To: Masataka Ohta From: Masataka Ohta Subject: Re: Last Call: Dynamic Delegation Discovery System (DDDS) to Proposed Standard To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200011250055.TAA08926@ietf.org> from The IESG at "Nov 24, 2000 07:55:16 pm" > The IESG has received a request from the Uniform Resource Names Working > Group to consider the following Internet-Drafts as Proposed Standards: > > o Dynamic Delegation Discovery System (DDDS) > > > o A DDDS Database Using The Domain Name System > > > o URI Resolution using the Dynamic Delegation Discovery System > It seems to me that the proposal uses DNS to resolve URN. However, it involves locations of nameservers of related domainnames that URNs are now URLs. One may argue that domainnames are location independent. Then, all the URLs (without raw IP addresses) are URNs. For URLs, HTTP has far more flexible redirection mechanism than the regexp based proposal. More flexibility than regexp is essential for highly semantical entities like URNs. Masataka Ohta From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 07:32:09 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21633 for ; Mon, 27 Nov 2000 07:32:09 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA04933; Mon, 27 Nov 2000 07:30:04 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8654584 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 07:29:27 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id CAA03552 for ; Mon, 27 Nov 2000 02:23:41 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id XAA22963; Sun, 26 Nov 2000 23:16:31 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAR7GeN29845; Sun, 26 Nov 2000 23:16:40 -0800 (PST) Received: from [212.247.3.17] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id XAA10899; Sun, 26 Nov 2000 23:16:20 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 References: <200011270009.JAA10341@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-ID: Date: Mon, 27 Nov 2000 07:38:18 +0100 Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Last Call: Dynamic Delegation Discovery System (DDDS) to Proposed Standard To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200011270009.JAA10341@necom830.hpcl.titech.ac.jp> At 09.08 +0859 00-11-27, Masataka Ohta wrote: >It seems to me that the proposal uses DNS to resolve URN. It is _one_ proposed algorithm to use to resolve URN's. The persistence of URN's are given by allowing other algorithms aswell -- which do not have anything to do with DNS. paf -- From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 11:43:23 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07106 for ; Mon, 27 Nov 2000 11:43:22 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA06361; Mon, 27 Nov 2000 11:42:25 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8654708 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 11:42:13 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA06354 for ; Mon, 27 Nov 2000 11:42:10 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id LAA19740; Mon, 27 Nov 2000 11:26:05 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20001127112604.J19471@bailey.dscga.com> Date: Mon, 27 Nov 2000 11:26:04 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: OIDs as URI/URNs.... To: URN-IETF@LISTS.NETSOL.COM Hi everyone, I'm crossposting this between the URN Working Group and the XMLDSIG Working group. The issue is whether or not the OID URN namespace document that is the process of being published should be ammended to include the textual representation of the node in the OID tree. the issue is whether the OID URN NID should look like this: urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) (note, the slashes would have to be changed or encoded since slashes are deprecated in URNs due to hierarchy semantics in RFC 2396) or like this: urn:oid:0.4.0.1733.1.4.1 XMLDSIG apparently has some requirements for readability that is considered dangerous for the persistence requirements for URNs. Should I update the pending RFC 3001 and resubmit or should it go forward as is? -MM ----- Forwarded message from Karl Scheibelhofer ----- From: "Karl Scheibelhofer" To: Subject: RE: OIDs as URIs Date: Mon, 27 Nov 2000 16:58:28 +0100 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001127085139.D9334@bailey.dscga.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Hmm...interesting. URNs have the soft requirement of not being > human readable. > Where is the expection coming from for a user seeing and needing to > understand an OID? the main purpose for use to use OIDs in URIs is in XML signatures. there we will need to use OIDs in form of URIs to refer to policies, other documents, ... that are already present and hav an OID. because XML has the great advantage that it is plain text, it can be read (debugged) by humans by just viewing it with any text editor. URIs are normally in form that you can roughly get an idea what's behind it. if we just use the pure number presentation of OIDs, i think (and others share this opinion) we are going to lose one advantage. however, i am aware of the fact that it is not absolutely required to work. but it was a requirement in designing XML "XML documents should be human-legible and reasonably clear". i think a pure number presentation of OIDs does not meet this requirements. best regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 ----- End forwarded message ----- -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 12:48:25 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00266 for ; Mon, 27 Nov 2000 12:48:24 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA07084; Mon, 27 Nov 2000 12:47:18 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8654806 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 12:47:09 -0500 Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA07072 for ; Mon, 27 Nov 2000 12:47:08 -0500 (EST) Received: from thinkingcat.com ([64.229.192.73]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001127174032.JDIC28285.tomts6-srv.bellnexxia.net@thinkingcat.com>; Mon, 27 Nov 2000 12:40:32 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200011270009.JAA10341@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A229C8A.CE83143E@thinkingcat.com> Date: Mon, 27 Nov 2000 12:40:26 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Re: Last Call: Dynamic Delegation Discovery System (DDDS) to ProposedStandard To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Comments in-line: Masataka Ohta wrote: > It seems to me that the proposal uses DNS to resolve URN. As Patrik has pointed out -- this is one proposal. > > However, it involves locations of nameservers of related domainnames > that URNs are now URLs. No -- the domain name is not part of the URN identifier string. Any relationship between a URN and a domain name is made with information that is current at the time the URN is resolved, not the time the identifier is assigned. Thus, such a relationship can be adjusted by namespace management without perturbing assigned URNs. > One may argue that domainnames are location independent. Then, all the > URLs (without raw IP addresses) are URNs. No, URNs are defined (syntactically) in RFC2141. That URLs may benefit from this approach to resolution is indeed outlined in o URI Resolution using the Dynamic Delegation Discovery System > > For URLs, HTTP has far more flexible redirection mechanism than the > regexp based proposal. More flexibility than regexp is essential > for highly semantical entities like URNs. Yes -- once you find the server that knows about the resource; which will often fail if the domain in the HTTP url goes away -- try to find where the resource http://www.bunyip.com/research/index.html is today... I hope this clarifies things. If not, there are 4.5 years of working group archives that might contain more specific detail. Thanks, Leslie. -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 12:52:53 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02253 for ; Mon, 27 Nov 2000 12:52:53 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA07269; Mon, 27 Nov 2000 12:52:02 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8654854 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 12:51:59 -0500 Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA07260 for ; Mon, 27 Nov 2000 12:51:57 -0500 (EST) Received: from thinkingcat.com ([64.229.192.73]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001127174522.JFRK28285.tomts6-srv.bellnexxia.net@thinkingcat.com>; Mon, 27 Nov 2000 12:45:22 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <20001127112604.J19471@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A229DAC.A80C30ED@thinkingcat.com> Date: Mon, 27 Nov 2000 12:45:16 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Re: OIDs as URI/URNs.... To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit (I'm not cross-posting, 'cause listserv stripped the XMLDSIG list address cc: off your posting, and I don't know what it is :-) I'd have some concern about: what happens when there is discrepancy between the digit and textual representations (i.e., it's an error). I'm not entirely sure that the XML problem couldn't be solved by a convention of a comment line that accompanies any identifier, to spell out what they need. But, that's fairly top-of-my-head. Leslie. Michael Mealling wrote: > > Hi everyone, > I'm crossposting this between the URN Working Group and the XMLDSIG > Working group. The issue is whether or not the OID URN namespace > document that is the process of being published should be ammended > to include the textual representation of the node in the OID tree. > > the issue is whether the OID URN NID should look like this: > urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta > ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) > > (note, the slashes would have to be changed or encoded since slashes > are deprecated in URNs due to hierarchy semantics in RFC 2396) > > or like this: > > urn:oid:0.4.0.1733.1.4.1 > > XMLDSIG apparently has some requirements for readability that is considered > dangerous for the persistence requirements for URNs. Should I update > the pending RFC 3001 and resubmit or should it go forward as is? > > -MM > > ----- Forwarded message from Karl Scheibelhofer ----- > > From: "Karl Scheibelhofer" > To: > Subject: RE: OIDs as URIs > Date: Mon, 27 Nov 2000 16:58:28 +0100 > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) > In-Reply-To: <20001127085139.D9334@bailey.dscga.com> > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > > Hmm...interesting. URNs have the soft requirement of not being > > human readable. > > Where is the expection coming from for a user seeing and needing to > > understand an OID? > > the main purpose for use to use OIDs in URIs is in XML signatures. there we > will need to use OIDs in form of URIs to refer to policies, other documents, > ... that are already present and hav an OID. because XML has the great > advantage that it is plain text, it can be read (debugged) by humans by just > viewing it with any text editor. URIs are normally in form that you can > roughly get an idea what's behind it. if we just use the pure number > presentation of OIDs, i think (and others share this opinion) we are going > to lose one advantage. > however, i am aware of the fact that it is not absolutely required to work. > but it was a requirement in designing XML "XML documents should be > human-legible and reasonably clear". i think a pure number presentation of > OIDs does not meet this requirements. > > best regards > > Karl Scheibelhofer > > -- > > Karl Scheibelhofer, > Institute for Applied Information Processing and Communications (IAIK) > at Technical University of Graz, Austria, http://www.iaik.at > Phone: (+43) (316) 873-5540 > > ----- End forwarded message ----- > > -- > -------------------------------------------------------------------------------- > Michael Mealling | Vote Libertarian! | www.rwhois.net/michael > Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 > Network Solutions | www.lp.org | michaelm@netsol.com -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 13:48:58 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25056 for ; Mon, 27 Nov 2000 13:48:57 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA08160; Mon, 27 Nov 2000 13:47:57 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8655025 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 13:47:44 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id NAA08089 for ; Mon, 27 Nov 2000 13:34:39 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 19:27:01 +0100 Received: from francetelecom.fr (lsun607.lannion.cnet.fr [161.104.14.41]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XWRMYXDP; Mon, 27 Nov 2000 19:25:09 +0100 X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: fr-FR, en MIME-Version: 1.0 References: <20001127124240.L19471@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A22A777.9CDF6DCA@francetelecom.fr> Date: Mon, 27 Nov 2000 19:27:03 +0100 Reply-To: Olivier DUBUISSON From: Olivier DUBUISSON Organization: France Telecom R&D Subject: Re: [leslie@thinkingcat.com: Re: OIDs as URI/URNs....] To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit > ----- Forwarded message from Leslie Daigle ----- > > I'd have some concern about: what happens when there is discrepancy > between the digit and textual representations (i.e., it's an > error). ITU-T Rec. X.660 series states that the number form of an OID is mandatory, but not the name form. Hence the number form takes precedence. -- Olivier DUBUISSON france telecom R&D _ DTL/MSV - 22307 Lannion Cedex - France ( ) tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45 /.\/ -------------------------------------- \_/\ Site ASN.1 : http://asn1.elibel.tm.fr/ From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 14:41:17 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13375 for ; Mon, 27 Nov 2000 14:41:17 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA09299; Mon, 27 Nov 2000 14:40:19 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8655255 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 14:40:10 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from nienie.mobile.webweaving.org (sfo-gw.covalent.net [207.44.198.62]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA08950 for ; Mon, 27 Nov 2000 14:20:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nienie.mobile.webweaving.org (8.11.1/8.11.1) with ESMTP id eARIDfY01811; Mon, 27 Nov 2000 10:13:41 -0800 (PST) (envelope-from dirkx@covalent.net) X-Sender: dirkx@localhost MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 27 Nov 2000 10:13:41 -0800 Reply-To: Dirk-Willem van Gulik From: Dirk-Willem van Gulik Subject: Re: OIDs as URI/URNs.... To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3A229DAC.A80C30ED@thinkingcat.com> On Mon, 27 Nov 2000, Leslie Daigle wrote: > I'd have some concern about: what happens when there is discrepancy > between the digit and textual representations (i.e., it's an > error). For normal OID's this is well defined- the numbered form takes precendence, always (and is usually mandatory to show). Dw From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 14:49:21 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16046 for ; Mon, 27 Nov 2000 14:49:21 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA09512; Mon, 27 Nov 2000 14:48:32 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8655311 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 14:48:28 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA09505 for ; Mon, 27 Nov 2000 14:48:26 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id OAA20291; Mon, 27 Nov 2000 14:32:13 -0500 (EST) References: <3A229DAC.A80C30ED@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20001127143212.P19471@bailey.dscga.com> Date: Mon, 27 Nov 2000 14:32:13 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: OIDs as URI/URNs.... To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: ; from dirkx@COVALENT.NET on Mon, Nov 27, 2000 at 10:13:41AM -0800 On Mon, Nov 27, 2000 at 10:13:41AM -0800, Dirk-Willem van Gulik wrote: > On Mon, 27 Nov 2000, Leslie Daigle wrote: > > > I'd have some concern about: what happens when there is discrepancy > > between the digit and textual representations (i.e., it's an > > error). > > For normal OID's this is well defined- the numbered form takes > precendence, always (and is usually mandatory to show). So what should the OID URN contain? Should it contain all of it and just have the syntactic equivalence rule in the NID spec say that only the number counts? While that's technically possible it just seems like it would create no end of problems and confusion for when someone decides to use 'em or not or they get the text part wrong. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Nov 27 18:13:30 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14304 for ; Mon, 27 Nov 2000 18:13:29 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA12746; Mon, 27 Nov 2000 18:12:21 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8655887 for URN-IETF@LISTS.NETSOL.COM; Mon, 27 Nov 2000 18:11:58 -0500 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA12731 for ; Mon, 27 Nov 2000 18:11:57 -0500 (EST) Received: from Phillsps (h00a0cc5364a4.ne.mediaone.net [24.128.120.97]) by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) with SMTP id SAA27574; Mon, 27 Nov 2000 18:05:11 -0500 (EST) References: <20001127112604.J19471@bailey.dscga.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: Phillip Hallam-Baker Message-ID: <004101c058c6$676030e0$4000a8c0@ne.mediaone.net> Date: Mon, 27 Nov 2000 18:04:31 -0500 Reply-To: Phillip Hallam-Baker From: Phillip Hallam-Baker Subject: Re: OIDs as URI/URNs.... To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit I deeply dislike the verbose form. If is is supported it should be a separate option for use in cases where verbosity is required. As a practical matter it is highly undesirable to require the verbose form. In many cases an application will not know what the text tags are for the OID segments in any case. Applications are very likely to end up with different text tags. I am not aware of any particular care being taken to ensure that the OID arcs are consistently named. I have certainly submitted draft RFCs that have renamed arc segments in all manner of devious ways. In ASN.1 the match is performed on the bits on the wire. The URN should not include additional information. My interpretation of the XML approach to verbosity is that it does not attempt to reduce verbosity but it does not insist upon unnecessary verbosity either. In most cases the OID will be followed by a large blob of BASE64 encoded CDATA. The proposal will do nothing for readability and introduce nummerous new sources of error. Phill ----- Original Message ----- From: "Michael Mealling" To: Sent: Monday, November 27, 2000 11:26 AM Subject: OIDs as URI/URNs.... > Hi everyone, > I'm crossposting this between the URN Working Group and the XMLDSIG > Working group. The issue is whether or not the OID URN namespace > document that is the process of being published should be ammended > to include the textual representation of the node in the OID tree. > > the issue is whether the OID URN NID should look like this: > urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta > ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) > > (note, the slashes would have to be changed or encoded since slashes > are deprecated in URNs due to hierarchy semantics in RFC 2396) > > or like this: > > urn:oid:0.4.0.1733.1.4.1 > > XMLDSIG apparently has some requirements for readability that is considered > dangerous for the persistence requirements for URNs. Should I update > the pending RFC 3001 and resubmit or should it go forward as is? > > -MM > > > ----- Forwarded message from Karl Scheibelhofer ----- > > From: "Karl Scheibelhofer" > To: > Subject: RE: OIDs as URIs > Date: Mon, 27 Nov 2000 16:58:28 +0100 > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) > In-Reply-To: <20001127085139.D9334@bailey.dscga.com> > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > > Hmm...interesting. URNs have the soft requirement of not being > > human readable. > > Where is the expection coming from for a user seeing and needing to > > understand an OID? > > the main purpose for use to use OIDs in URIs is in XML signatures. there we > will need to use OIDs in form of URIs to refer to policies, other documents, > ... that are already present and hav an OID. because XML has the great > advantage that it is plain text, it can be read (debugged) by humans by just > viewing it with any text editor. URIs are normally in form that you can > roughly get an idea what's behind it. if we just use the pure number > presentation of OIDs, i think (and others share this opinion) we are going > to lose one advantage. > however, i am aware of the fact that it is not absolutely required to work. > but it was a requirement in designing XML "XML documents should be > human-legible and reasonably clear". i think a pure number presentation of > OIDs does not meet this requirements. > > best regards > > Karl Scheibelhofer > > -- > > Karl Scheibelhofer, > Institute for Applied Information Processing and Communications (IAIK) > at Technical University of Graz, Austria, http://www.iaik.at > Phone: (+43) (316) 873-5540 > > ----- End forwarded message ----- > > -- > -------------------------------------------------------------------------- ------ > Michael Mealling | Vote Libertarian! | www.rwhois.net/michael > Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 > Network Solutions | www.lp.org | michaelm@netsol.com > From owner-urn-ietf@LISTS.NETSOL.COM Wed Nov 29 19:46:12 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21538 for ; Wed, 29 Nov 2000 19:46:11 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id TAA07064; Wed, 29 Nov 2000 19:44:36 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8659124 for URN-IETF@LISTS.NETSOL.COM; Wed, 29 Nov 2000 19:43:43 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA05409 for ; Wed, 29 Nov 2000 16:20:20 -0500 (EST) Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA28263; Wed, 29 Nov 2000 13:09:43 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 13:13:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002C_01C05A1F.91095D90" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C712@vhqpostal.verisign.com> Date: Wed, 29 Nov 2000 13:13:42 -0800 Reply-To: Philip Hallam-Baker From: Philip Hallam-Baker Subject: Re: [leslie@thinkingcat.com: Re: OIDs as URI/URNs....] To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C05A1F.91095D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > > ----- Forwarded message from Leslie Daigle > ----- > > > > I'd have some concern about: what happens when there is discrepancy > > between the digit and textual representations (i.e., it's an > > error). > > ITU-T Rec. X.660 series states that the number form of an OID > is mandatory, > but not the name form. Hence the number form takes precedence. It is important to recognize that the Name 'form' of an ASN.1 OID is not normative and is not transmitted in the ASN.1 encoding. As a result working groups defining OIDS do not in general take particular care or even any care whatsoever to ensure that the name form of the OID is unique and unambiguous. As with any spec half the discussion on any given ASN.1 schema is quite likely to involve discussion on the naming of variables and identifiers. I have participated in working groups where OIDs have been renamed from one draft to another on several occasions. I have done the same thing myself. The number form is generaly treaded with considerable respect and care however. I am absolutely opposed to attempts to provide 'clarity' that introduce ambiguity and are almost certain to introduce errors and complexity into programs. Using the name form of an OID for a purpose that was not intended falls into that category in my opinion. The name form is unnecessary and will introduce confusion complexity and error into applications. It should be rejected. Michael's original proposal is fine as is. Phill ------=_NextPart_000_002C_01C05A1F.91095D90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf /wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH 9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDExMjkyMTE1MTla MCMGCSqGSIb3DQEJBDEWBBToJUh88shSqkOezitLToNszCmU2TBYBgkqhkiG9w0BCQ8xSzBJMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN BgkqhkiG9w0BAQEFAASBgFhiz2sYhXCDbIOxouNy57WIZMOnZUyMAIvgMVSjY1/8jQG0sqkUo7RK purn2OgKaVNXBFHiqGwxzBHzL9J6dLdHVrnd10SVWVHJSS07A0wN+CVwx9ivWD5aTY83k3heS92p 6K23fNXXi6XlCBpTnmJ4k8dGclXfYOHQ5o5oJi+cAAAAAAAA ------=_NextPart_000_002C_01C05A1F.91095D90--