From owner-urn-ietf@LISTS.INTERNIC.NET Tue May 9 13:35:44 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26054 for ; Tue, 9 May 2000 13:35:44 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA23647; Tue, 9 May 2000 13:01:37 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8682521 for URN-IETF@LISTS.INTERNIC.NET; Tue, 9 May 2000 13:01:33 -0400 Received: from www.telenet.ru ([212.23.74.138]) by lists.internic.net (8.9.3/8.9.3) with SMTP id MAA20441 for ; Tue, 9 May 2000 12:51:27 -0400 (EDT) Received: from alanjr (unverified [172.139.238.44]) by www.telenet.ru (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 09 May 2000 22:46:23 +0500 Message-ID: Date: Tue, 9 May 2000 22:46:23 +0500 Reply-To: zone13@BIGFOOT.COM From: zone13@BIGFOOT.COM Subject: The Contrarian - BUY ALERT . ~* To: URN-IETF@LISTS.INTERNIC.NET THE CONTRARIAN BUY ALERT: RecycleNet Corp. Symbol - GARM (OTCBB-pink sheets) Recent Price - $.35 52 Week Range - $.12 - .75 Estimated Float - 4 Million Shares Outstanding - 78 Million Now that Microsoft and other Internet stocks have fallen, it's time to sift through the wreckage and look for treasure. As Contrarian investors, we've been waiting for this dynamic group to fall out of favor temporarily, so we can buy at discounted prices. The following stock should be purchased for long-term capital gains: RecycleNet Corporation is hardly a new player in the dot.com game - they went electronic in May 1995, after many years in a print format. Their founder and current Chairman, Paul Roszel, has been in the recycling business for over 20 years, and has vast experience with every type of scrap commodity. Recyclenet is part of the booming "B2B" business to business portion of the Internet. It is estimated that B2B electronic commerce will soar from $17 Billion in sales in 1998 to $327 Billion by 2002. Electronic commerce gives GARM the ability to trade with other companies all over the world, at very low cost. They earn money from subscribers who pay a monthly fee to join their Recycler's Exchange. What is the reason to buy now? RecycleNet should be reporting excellent revenues and earnings in the next quarter, the floating supply of shares is small, and the financial community is just starting to discover GARM. They have filed their Form 10 to become a reporting company with the SEC, and they should be emerging from their pink sheet listing soon. Meanwhile, traffic at their web site is hitting record numbers (almost 2 Million page views per month), and is growing at over 20% monthly. With the stock trading at half of its February peak, The Contrarian believes that GARM can reach the $1.50 level near-term, with even higher prices further out. Take a position now while RecycleNet is on the bargain shelf. Disclaimer: The Contrarian has no affiliation with the issuer, and has received no fee from RecycleNet for this report. The Contrarian and/or its affiliates currently own shares of RecycleNet, and may buy or sell shares at any time after the dissemination of this report. Because the publisher owns this stock, there may be a conflict of interest in the Contrarian's statements and opinions. The Contrarian is not a registered investment advisor, broker or dealer. Purchase of this stock may be considered speculative, and may result in the loss of some or all of any investment made. To SUBSCRIBE to future announcements or request ADDTIONAL INFORMATION regarding the RecycleNet opportunity, please click on the appropriate link below and hit send. mailto:zone15@us.sina.com?subject=Subscribe mailto:zone15@us.sina.com?subject=Additional-Information ****************************************** If you wish to be deleted from inclusion any future mailing, please click on the link below and hit send. ****************************************** mailto:zone15@us.sina.com?subject=delete From owner-urn-ietf@LISTS.INTERNIC.NET Wed May 10 18:13:21 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04379 for ; Wed, 10 May 2000 18:13:21 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id RAA06929; Wed, 10 May 2000 17:48:29 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8685365 for URN-IETF@LISTS.INTERNIC.NET; Wed, 10 May 2000 17:48:26 -0400 Received: from kaproc.bud.polsl.gliwice.pl (kaproc.bud.polsl.gliwice.pl [157.158.25.4]) by lists.internic.net (8.9.3/8.9.3) with SMTP id RAA04585 for ; Wed, 10 May 2000 17:38:21 -0400 (EDT) Received: from (194.25.64.012]) (unverified [172.145.127.80]) by kaproc.bud.polsl.gliwice.pl (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 10 May 2000 23:33:14 +0200 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <0000684b0517$00003bcd$00006f78@(194.25.64.012])> Date: Mon, 8 May 2000 19:29:58 -0400 Reply-To: post10@21cn.com From: post80@BIGFOOT.COM Subject: The Contrarian - BUY ALERT: To: URN-IETF@LISTS.INTERNIC.NET THE CONTRARIAN BUY ALERT: RecycleNet Corp. Symbol - GARM (OTCBB-pink sheets) Recent Price - $.35 52 Week Range - $.12 - .75 Estimated Float - 4 Million Shares Outstanding - 78 Million Now that Microsoft and other Internet stocks have fallen, it's time to sift through the wreckage and look for treasure. As Contrarian investors, we've been waiting for this dynamic group to fall out of favor temporarily, so we can buy at discounted prices. The following stock should be purchased for long-term capital gains: RecycleNet Corporation is hardly a new player in the dot.com game - they went electronic in May 1995, after many years in a print format. Their founder and current Chairman, Paul Roszel, has been in the recycling business for over 20 years, and has vast experience with every type of scrap commodity. Recyclenet is part of the booming "B2B" business to business portion of the Internet. It is estimated that B2B electronic commerce will soar from $17 Billion in sales in 1998 to $327 Billion by 2002. Electronic commerce gives GARM the ability to trade with other companies all over the world, at very low cost. They earn money from subscribers who pay a monthly fee to join their Recycler's Exchange. What is the reason to buy now? RecycleNet should be reporting excellent revenues and earnings in the next quarter, the floating supply of shares is small, and the financial community is just starting to discover GARM. They have filed their Form 10 to become a reporting company with the SEC, and they should be emerging from their pink sheet listing soon. Meanwhile, traffic at their web site is hitting record numbers (almost 2 Million page views per month), and is growing at over 20% monthly. With the stock trading at half of its February peak, The Contrarian believes that GARM can reach the $1.50 level near-term, with even higher prices further out. Take a position now while RecycleNet is on the bargain shelf. Disclaimer: The Contrarian has no affiliation with the issuer, and has received no fee from RecycleNet for this report. The Contrarian and/or its affiliates currently own shares of RecycleNet, and may buy or sell shares at any time after the dissemination of this report. Because the publisher owns this stock, there may be a conflict of interest in the Contrarian's statements and opinions. The Contrarian is not a registered investment advisor, broker or dealer. Purchase of this stock may be considered speculative, and may result in the loss of some or all of any investment made. To SUBSCRIBE to future announcements or request ADDTIONAL INFORMATION regarding the RecycleNet opportunity, please click on the appropriate link below and hit send. mailto:post10@21cn.com?subject=Subscribe mailto:post10@21cn.com?subject=Additional-Information ****************************************** If you wish to be deleted from inclusion any future mailing, please click on the link below and hit send. ****************************************** mailto:post10@21cn.com?subject=delete THE CONTRARIAN From owner-urn-ietf@LISTS.INTERNIC.NET Sun May 14 16:12:49 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10933 for ; Sun, 14 May 2000 16:12:49 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA25344; Sun, 14 May 2000 16:01:18 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8690967 for URN-IETF@LISTS.INTERNIC.NET; Sun, 14 May 2000 16:01:16 -0400 Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA23762; Sun, 14 May 2000 15:51:10 -0400 (EDT) Received: from [192.168.111.25] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id VAA03690; Sun, 14 May 2000 21:45:21 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-ID: Date: Sun, 14 May 2000 20:52:56 +0200 Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Information about use of infrastructure domains To: URN-IETF@LISTS.INTERNIC.NET Dear URN WG: Over the last few months, the IAB has been discussing possible complications stemming from the use of the ".INT" TLD as a location for Internet infrastructure domains. The result of those discussions was a recommendation to the IESG that infrastructure domains be placed in ".ARPA" rather than in ".INT" where feasible. See http://www.iab.org/iab/statement-on-infrastructure-domains.txt for the full recommendation. Based on the IAB recommendation, the IESG requests that the WG make such a change. That is, The IESG recommends that the urn.net and uri.net be placed under the ".ARPA" TLD. For the IESG, Patrik P.S. CNRP wg is added as cc on this message, as URN resolution mechanisms are discussed on your mailing list From owner-urn-ietf@LISTS.INTERNIC.NET Mon May 15 00:43:33 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16715 for ; Mon, 15 May 2000 00:43:33 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id AAA17184; Mon, 15 May 2000 00:30:28 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8691389 for URN-IETF@LISTS.INTERNIC.NET; Mon, 15 May 2000 00:30:26 -0400 Received: from gacol.samba-warmia.com.pl (gacol.samba-warmia.com.pl [195.117.12.5]) by lists.internic.net (8.9.3/8.9.3) with SMTP id AAA15650 for ; Mon, 15 May 2000 00:20:24 -0400 (EDT) Received: from uiuiyu2 [209.206.4.5] by gacol.samba-warmia.com.pl with ESMTP (SMTPD32-4.06) id A9A61BA0122; Mon, 15 May 2000 06:14:30 +01d0 X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.internic.net id AAA15654 Message-ID: <200005150420.AAA15650@lists.internic.net> Date: Sun, 14 May 2000 22:30:17 -0500 Reply-To: Author Buli From: Author Buli Subject: One Day... #522D To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 8bit WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS ! INTERNET (Auction Vendors & Online Mall Stores Too!) STOREFRONT OR MAIL ORDER MERCHANTS WE SPECIALIZE IN APPROVING YOU! APPLY TODAY AND START FOR JUST $9.95! FREE APPLICATION!! FREE PROGRAMMING!! DON'T LOSE ANOTHER SALE! APPLY TO ACCEPT CREDIT CARDS AND CALL (888) 264-9272 DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!! ********************************************************************* If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:vbbm@movemail.com?subject=remove ********************************************************************** From owner-urn-ietf@LISTS.INTERNIC.NET Thu May 18 08:57:24 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04594 for ; Thu, 18 May 2000 08:57:24 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id IAA17981; Thu, 18 May 2000 08:37:53 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8695450 for URN-IETF@LISTS.INTERNIC.NET; Thu, 18 May 2000 08:37:50 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id IAA15759 for ; Thu, 18 May 2000 08:24:32 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id IAA25686 for urn-ietf@lists.internic.net; Thu, 18 May 2000 08:08:23 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Message-ID: <20000518080823.A25671@bailey.dscga.com> Date: Thu, 18 May 2000 08:08:23 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: test of anti-spam measures To: URN-IETF@LISTS.INTERNIC.NET Testing anti-spam measures. Ignore.... -- -------------------------------------------------------------------------------- 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.INTERNIC.NET Thu May 18 11:33:04 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08912 for ; Thu, 18 May 2000 11:33:04 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id LAA16776; Thu, 18 May 2000 11:22:36 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8695735 for URN-IETF@LISTS.INTERNIC.NET; Thu, 18 May 2000 11:22:33 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id LAA16744; Thu, 18 May 2000 11:22:30 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id LAA26062; Thu, 18 May 2000 11:06:22 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000518110622.D25965@bailey.dscga.com> Date: Thu, 18 May 2000 11:06:22 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: new spam measures To: URN-IETF@LISTS.INTERNIC.NET Administrivia: Due to a recent increase in the amount of spam on these two lists, I have specified that both lists are now moderated by me personally. The stated policy is that anything sent to the list that is not spam is immediately posted. I will not edit or comment on any piece of mail. The obvious downside is that posts to the list may take a few hours to be posted as I'm not always reading my mail. If this turns out to be a problem we can investigate other solutions. -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.INTERNIC.NET Thu May 18 14:28:18 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11672 for ; Thu, 18 May 2000 14:28:18 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA17319; Thu, 18 May 2000 14:09:54 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8696092 for URN-IETF@LISTS.INTERNIC.NET; Thu, 18 May 2000 14:09:52 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA17291 for ; Thu, 18 May 2000 14:09:48 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA26734 for urn-ietf@lists.internic.net; Thu, 18 May 2000 13:53:19 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000518135319.G26536@bailey.dscga.com> Date: Thu, 18 May 2000 13:53:19 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: A new URN namespace registration draft To: URN-IETF@LISTS.INTERNIC.NET (Administrivia discussions on hold. Now for some real work for a change.) Hi folx, I just submitted an Internet-Draft to the repository for requesting a new URN NamespaceID called "PIN" which stands for "Personal Internet Name". Since the urn-nid@apps.ietf.org list is only for approving the mechanics of the registration mechanism it seemed appropriate that any discussions of the actual draft should happen here. I've included the draft below. It will be Informational only... Network Working Group M.M. Mealling Internet-Draft Network Solutions, Inc. Expires: September 30, 2000 April 2000 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations draft-mealling-pin-urn-00.txt Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. 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." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 30, 2000. Abstract This document describes a URN namespace that is engineered by Network Solutions, Inc for naming people and organizations. 1. Introduction In many cases, Network Solutions' directory applications require some unique and persistent way to talk about an individual or organization. For example, white pages services need to determine if one user is distinct from another even if some of the data happens to be the same. Also, e-commerce authentication mechanisms need to identify a user uniquely and possibly over large spans of time. In many cases a customer relationship can last several decades. Such long term customer relationships can outlast any specific email address, Internet service provider, surname, or possibly even the DNS itself. URNs are a uniquely suited solution for this due to the requirement that they also be unique and permanent. In addition, the Mealling Expires September 30, 2000 [Page 1] Internet-Draft NSI PIN URN Namespace April 2000 availability of a standardized resolution mechanism makes it possible for vastly different systems to utilize the PIN URN without needing to utilize an application or protocol specific element. This namespace specification is for a formal namespace. 2. Specification Template Namespace ID: "pin" requested. Registration Information: Registration Version Number: 1 Registration Date: 2000-04-30 Declared registrant of the namespace: Michael Mealling michaelm@netsol.com Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 Declaration of structure: The structure of the NSS is a flat space of alphanumeric characters which have no knowable structure outside of the context of Network Solutions internal resolver. Relevant ancillary documentation: None Identifier uniqueness considerations: Identifiers are assigned by Network Solutions proprietary registration system in a way that guarantees uniqueness. Identifier persistence considerations: The assignment process guarantees that names are not reassigned and that the binding between the name and the entity named is permanent. Process of identifier assignment: Names are granted via Network Solutions proprietary registration procedures. Process of identifier resolution: PIN URNs are resolved via URN resolvers run by Network Solutions. The data and databases used by those resolvers is proprietary data and can only be accessed by the resolver. Rules for Lexical Equivalence: The entire URN is case-insensitive. Conformance with URN Syntax: There are no additional characters reserved. Validation mechanism: None additional to resolution specified Scope: Global Mealling Expires September 30, 2000 [Page 2] Internet-Draft NSI PIN URN Namespace April 2000 3. Examples The following examples are not guaranteed to be real. They are listed for pedagogical reasons only. URN:pin:bs4321234 URN:pin:324kj5hkj45 URN:pin:mm2136 4. Security Considerations Since the URNs in this namespace are opaque there are no additional security considerations other than those normally associated with the use and resolution of URNs in general. It is noted however that attempting to resolve a PIN URN through a resolver other than the one provided by Network Solution is prone to error and is not considered authoritative. References [1] Moats, R., "URN Syntax", RFC 2141, May 1997. Author's Address Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070 US Phone: +1 770 935 5492 EMail: michaelm@netsol.com URI: http://www.netsol.com Mealling Expires September 30, 2000 [Page 3] -- -------------------------------------------------------------------------------- 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.INTERNIC.NET Tue May 23 03:32:36 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28194 for ; Tue, 23 May 2000 03:32:35 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id DAA04662; Tue, 23 May 2000 03:22:25 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8701597 for URN-IETF@LISTS.INTERNIC.NET; Tue, 23 May 2000 03:22:21 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id DAA04630 for ; Tue, 23 May 2000 03:22:19 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id DAA03502; Tue, 23 May 2000 03:05:12 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000523030511.D3436@bailey.dscga.com> Date: Tue, 23 May 2000 03:05:11 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: PIN document? To: URN-IETF@LISTS.INTERNIC.NET Hi from Amsterdam, I've forwarded the draft to the URN list but so far there havn't been any comments from that list or this one. To clarify the process a little, when does the urn-nid lists two week comment period begin? On submission or only once the draft has become an RFC? (I'm assuming the latter). I'll wait another two weeks for some substantive suggestions for changes to the document and which time I'll be requesting it to be published as Informational.... -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.INTERNIC.NET Wed May 24 01:13:25 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18987 for ; Wed, 24 May 2000 01:13:25 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id AAA17377; Wed, 24 May 2000 00:58:09 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8702750 for URN-IETF@LISTS.INTERNIC.NET; Wed, 24 May 2000 00:58:07 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id JAA14663 for ; Tue, 23 May 2000 09:13:32 -0400 (EDT) Received: from thinkingcat.com ([207.253.111.58]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FV0007R0JBNAV@field.videotron.net> for urn-ietf@lists.internic.net; Tue, 23 May 2000 08:43:01 -0400 (EDT) MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20000523030511.D3436@bailey.dscga.com> Message-ID: <392A7C7E.7571C799@thinkingcat.com> Date: Tue, 23 May 2000 08:41:34 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: PIN document? To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, Michael Mealling wrote: > To clarify the process > a little, when does the urn-nid lists two week comment period begin? On > submission or only once the draft has become an RFC? (I'm assuming > the latter). The former -- when you submit it to the mailing urn-nid@apps.ietf.org. The idea is to get feedback (on structure & presentation) before putting it up for RFC consideration. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Wed May 24 10:02:34 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06308 for ; Wed, 24 May 2000 10:02:34 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id JAA09431; Wed, 24 May 2000 09:43:31 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8592804 for URN-IETF@LISTS.INTERNIC.NET; Wed, 24 May 2000 09:43:28 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id JAA05841 for ; Wed, 24 May 2000 09:27:14 -0400 (EDT) Received: from 207-172-77-137.s137.tnt1.lee.va.dialup.rcn.com ([207.172.77.137] helo=insta.com) by smtp01.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 12ub67-00037k-00; Wed, 24 May 2000 09:21:19 -0400 X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.13-2 i686) X-Accept-Language: en MIME-Version: 1.0 References: <20000518135319.G26536@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <392BD72B.67143EA2@insta.com> Date: Wed, 24 May 2000 09:20:44 -0400 Reply-To: "Stephen D. Williams" From: "Stephen D. Williams" Organization: Insta.com, Inc. Subject: Comments: Re: A new URN namespace registration draft To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Standardizing on a permanent ID system separate from email addresses, domain names, and other identification is a valuable goal. While I have had the same permanent email address (sdw@lig.net) just as long as my Internic handle (sdw11), both in 1992, it is only because I run my own email server, a rare luxury these days. Not only do people move between email addresses sometimes more often than they move physical addresses due to ISP changes, job changes, and school changes, but they may also be moving between registrars. The principle problems with this draft is that it proposes an apparent neutral URN space, URN:pin, but which is semi-private for read and private for write to Network Solutions. This is wholly unacceptable as an open standard. Even taken in the narrow application of domain registration it would be highly desirable for all registrars to be able to identify an entity consistantly. Similarly, registrants are faced with the pervasive problem of tracking multiple ID's over potentially several registrars' systems. I would suggest first that URN:networksolutions-pin be used for the existing 'Internic handles' and that URN:pin be reserved for an open, free, accessable, and comprehensively usable system of permanent identification of entities. Some thoughts on OpenPin: The Senior VP of Development from AOL, Larry Masinter (if I remember correctly), myself, and many others have voiced the obvious need for a long-term stable ID system that could be relied upon by various applications. These applications could include authentication (but not authorization) for applications including DNS registrars, email forwarding, directory links, presence, etc. Note that this namespace is intended for legal or quasi-legal entities (including individuals, distinct groups and clubs, corporations and companies) and not for arbitrary object or concept ids. Something like the unique field in White Pages, not an Internet keyword. Special consideration would have to be given to spam prevention, authentication security methods, updates, and distributed replication/access. An effort should be made to allow easy mapping of existing IDs, especially email IDs, into the space in a way that is resistant to time decay. A simple example would be: sdw@lig.net -> 92esdw_lig_net. The year could really be a base-36 month or quarter time-based 'salt' which would allow for ID reuse for entities like AOL which have a 6 month or less reuse gap. a1esdw_aol_com would be a different entity from a2esdw_aol_com. 'e' was a suggestion for denoting 'email' mapping. 'h' could denote 'Internic Handle' mapping. 'a' could be AOL mapping, but that might be a bit too preferential. The goal of the name space should be to avoid overly random IDs when possible by limiting name space and temporal collisions. Of course it would be helpful in some contexts for this to have email address form in which case a standard pseudo-domain could be used, such as: a1esdw_lig_net@pin.urn.net. In other contexts, the '@pin.urn.net' would be implied. With modern load balancing technology, resolution of these ID's and to a large extent authorization when needed could easily be distributed over vast numbers of servers. Each ISP and large entity could run a local, secure, ID translation server. Man-in-the-middle and other attacks could be minimized by strategies like frequenhtly distributing PK private keys to authorized servers or IP validation in reverse DNS periodically. Updates should be propagated via flood (a la Usenet). Collisions should be handled by time stamp comparison or crypto-time sequence comparison (i.e., if NTP cheating in servers is suspected, an encrypted NTP sequence could be used). Both direct and delegated authentication should be supported. Entities can be 'terminal', indicating that the entity does not exist, 'inherited' which means it doesn't exist but has become 'owned' by a new entity, or 'delegated'. OpenPin's should have privacy preferences determining what use is allowed and the system should keep a history of changes to this. Use of the Pins by both listed and using parties should require agreement with a terms of use which can be used to exclude certain conduct. Alternately this can be handled by appropriate laws in the future. This might be going to far, but it makes sense for this ID directory to allow certification information provided by certification authorities. Although I haven't been tracking progress of PKI projects lately, it would seem useful for an omni-PIN directory to contain public keys also. Arbitrary capabilities and preferences are another recurrent problem. For example, who prefers HTML email? It is debatable which of these services and information categories should be retained within the OpenPIN records and which should be delegated to other servers, but it's clear that there should be a permanent ID with which to find such information or services for a particular entity. An example heuristic might be: anything that changes more often than X (a day, week, month) on a normal basis must be delegated. sdw Michael Mealling wrote: > (Administrivia discussions on hold. Now for some real work for a change.) > > Hi folx, > I just submitted an Internet-Draft to the repository for requesting > a new URN NamespaceID called "PIN" which stands for "Personal Internet Name". > Since the urn-nid@apps.ietf.org list is only for approving the mechanics > of the registration mechanism it seemed appropriate that any discussions > of the actual draft should happen here. I've included the draft below. > It will be Informational only... > > Network Working Group M.M. Mealling > Internet-Draft Network Solutions, Inc. > Expires: September 30, 2000 April 2000 > > The Network Solutions Personal Internet Name (PIN): A URN Namespace > for People and Organizations > draft-mealling-pin-urn-00.txt > > Status of this Memo > > This document is an Internet-Draft and is NOT offered in accordance > with Section 10 of RFC2026, and the author does not provide the IETF > with any rights other than to publish as an Internet-Draft. > > 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." > > To view the entire list of Internet-Draft Shadow Directories, see > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on September 30, 2000. > > Abstract > > This document describes a URN namespace that is engineered by > Network Solutions, Inc for naming people and organizations. > > 1. Introduction > > In many cases, Network Solutions' directory applications require > some unique and persistent way to talk about an individual or > organization. For example, white pages services need to determine if > one user is distinct from another even if some of the data happens > to be the same. Also, e-commerce authentication mechanisms need to > identify a user uniquely and possibly over large spans of time. In > many cases a customer relationship can last several decades. Such > long term customer relationships can outlast any specific email > address, Internet service provider, surname, or possibly even the > DNS itself. > > URNs are a uniquely suited solution for this due to the requirement > that they also be unique and permanent. In addition, the > > Mealling Expires September 30, 2000 [Page 1] > > Internet-Draft NSI PIN URN Namespace April 2000 > > availability of a standardized resolution mechanism makes it > possible for vastly different systems to utilize the PIN URN without > needing to utilize an application or protocol specific element. > > This namespace specification is for a formal namespace. > > 2. Specification Template > > Namespace ID: > > "pin" requested. > > Registration Information: > > Registration Version Number: 1 > Registration Date: 2000-04-30 > > Declared registrant of the namespace: > > Michael Mealling > michaelm@netsol.com > Network Solutions > 505 Huntmar Park Drive > Herndon, VA 22070 > > Declaration of structure: > > The structure of the NSS is a flat space of alphanumeric > characters which have no knowable structure outside of the > context of Network Solutions internal resolver. > > Relevant ancillary documentation: > > None > > Identifier uniqueness considerations: > > Identifiers are assigned by Network Solutions proprietary > registration system in a way that guarantees uniqueness. > > Identifier persistence considerations: > > The assignment process guarantees that names are not reassigned > and that the binding between the name and the entity named is > permanent. > > Process of identifier assignment: > > Names are granted via Network Solutions proprietary registration > procedures. > > Process of identifier resolution: > > PIN URNs are resolved via URN resolvers run by Network > Solutions. The data and databases used by those resolvers is > proprietary data and can only be accessed by the resolver. > > Rules for Lexical Equivalence: > > The entire URN is case-insensitive. > > Conformance with URN Syntax: > > There are no additional characters reserved. > > Validation mechanism: > > None additional to resolution specified > > Scope: > > Global > > Mealling Expires September 30, 2000 [Page 2] > > Internet-Draft NSI PIN URN Namespace April 2000 > > 3. Examples > > The following examples are not guaranteed to be real. They are > listed for pedagogical reasons only. > > URN:pin:bs4321234 > URN:pin:324kj5hkj45 > URN:pin:mm2136 > > 4. Security Considerations > > Since the URNs in this namespace are opaque there are no additional > security considerations other than those normally associated with > the use and resolution of URNs in general. > > It is noted however that attempting to resolve a PIN URN through a > resolver other than the one provided by Network Solution is prone to > error and is not considered authoritative. > > References > > [1] Moats, R., "URN Syntax", RFC 2141, May 1997. > > Author's Address > > Michael Mealling > Network Solutions, Inc. > 505 Huntmar Park Drive > Herndon, VA 22070 > US > > Phone: +1 770 935 5492 > EMail: michaelm@netsol.com > URI: http://www.netsol.com > > Mealling Expires September 30, 2000 [Page 3] > > -- > -------------------------------------------------------------------------------- > 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 -- Insta.com - Revolutionary E-Business Communication sdw@insta.com Stephen D. Williams Senior Consultant/Architect http://sdw.st 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Jan2000 From owner-urn-ietf@LISTS.INTERNIC.NET Wed May 24 12:07:29 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08116 for ; Wed, 24 May 2000 12:07:28 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id LAA07014; Wed, 24 May 2000 11:52:28 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8592923 for URN-IETF@LISTS.INTERNIC.NET; Wed, 24 May 2000 11:52:25 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id LAA06987 for ; Wed, 24 May 2000 11:52:22 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id LAA05982; Wed, 24 May 2000 11:35:13 -0400 (EDT) References: <20000518135319.G26536@bailey.dscga.com> <392BD72B.67143EA2@insta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000524113513.A5940@bailey.dscga.com> Date: Wed, 24 May 2000 11:35:13 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: Comments: Re: A new URN namespace registration draft To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <392BD72B.67143EA2@insta.com>; from sdw@insta.com on Wed, May 24, 2000 at 09:20:44AM -0400 On Wed, May 24, 2000 at 09:20:44AM -0400, Stephen D. Williams wrote: > The principle problems with this draft is that it proposes an apparent > neutral URN space, URN:pin, but which is semi-private for read and > private for write to Network Solutions. This is wholly unacceptable as > an open standard. This is not meant as an open standard. In the same sense that ISBN is a semi-private for read and private for write, are you going to deny ISBN, ISSN, et al their NID as well? Every single one of them is run by a private organization who claim proprietary ownership of the namespace. > Even taken in the narrow application of domain > registration it would be highly desirable for all registrars to be > able to identify an entity consistantly. Similarly, registrants > are faced with the pervasive problem of tracking multiple ID's over > potentially several registrars' systems. This URN namespace will probably have nothing at all to do with the domain-name registration process.... > I would suggest first that URN:networksolutions-pin be used for the existing > 'Internic handles' and that URN:pin be reserved for an open, free, > accessable, and comprehensively usable system of permanent identification > of entities. This is not and has never been the policy of the IETF to make these social/political determinations. It is specifically not mentioned anywhere in RFC2611 process for NID registration.... Nothing in the process says that a new URN namespace has to be an open IETF standard. RFC 2611 specifically states that the required RFC can be Information or even Experimental. From RFC2611: "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." -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.INTERNIC.NET Wed May 24 13:11:51 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09290 for ; Wed, 24 May 2000 13:11:50 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id MAA20442; Wed, 24 May 2000 12:57:08 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8593017 for URN-IETF@LISTS.INTERNIC.NET; Wed, 24 May 2000 12:57:06 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id MAA17680 for ; Wed, 24 May 2000 12:43:44 -0400 (EDT) Received: from 207-172-77-137.s137.tnt1.lee.va.dialup.rcn.com ([207.172.77.137] helo=insta.com) by smtp01.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 12ueAL-0002S2-00; Wed, 24 May 2000 12:37:53 -0400 X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.13-2 i686) X-Accept-Language: en MIME-Version: 1.0 References: <20000518135319.G26536@bailey.dscga.com> <392BD72B.67143EA2@insta.com> <20000524113513.A5940@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <392C053A.6C5A9A61@insta.com> Date: Wed, 24 May 2000 12:37:14 -0400 Reply-To: "Stephen D. Williams" From: "Stephen D. Williams" Organization: Insta.com, Inc. Subject: Re: Comments: Re: A new URN namespace registration draft To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit I don't dispute your points. Let me summarize my comments more clearly: A) With regard to your URN:pin draft: URN:pin seems like an inappropriately generic namespace ID for a very narrow and closed use. I, personally, would prefer a more specific namespace. I have not studied the IETF politics and rules in detail regarding selection and registration of URN namespace ID's and cannot make a more specific complaint. It's not an overly important issue in any case. Why not use: URN:nichandle or URN:nshandle? B) The need for a generic and open URN:pin (or URN:personalid, or whatever) has come up before. I go on, in my previous message, to describe my requirements for such a namespace and postulated service informally but in some detail. sdw Michael Mealling wrote: > On Wed, May 24, 2000 at 09:20:44AM -0400, Stephen D. Williams wrote: > > The principle problems with this draft is that it proposes an apparent > > neutral URN space, URN:pin, but which is semi-private for read and > > private for write to Network Solutions. This is wholly unacceptable as > > an open standard. > > This is not meant as an open standard. In the same sense that > ISBN is a semi-private for read and private for write, are you > going to deny ISBN, ISSN, et al their NID as well? Every > single one of them is run by a private organization who claim > proprietary ownership of the namespace. > > > Even taken in the narrow application of domain > > registration it would be highly desirable for all registrars to be > > able to identify an entity consistantly. Similarly, registrants > > are faced with the pervasive problem of tracking multiple ID's over > > potentially several registrars' systems. > > This URN namespace will probably have nothing at all to do with > the domain-name registration process.... > > > I would suggest first that URN:networksolutions-pin be used for the existing > > 'Internic handles' and that URN:pin be reserved for an open, free, > > accessable, and comprehensively usable system of permanent identification > > of entities. > > This is not and has never been the policy of the IETF to make these > social/political determinations. It is specifically not mentioned anywhere > in RFC2611 process for NID registration.... > > Nothing in the process says that a new URN namespace has to be > an open IETF standard. RFC 2611 specifically states that the required > RFC can be Information or even Experimental. > > >From RFC2611: > > "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." > > -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 -- Insta.com - Revolutionary E-Business Communication sdw@insta.com Stephen D. Williams Senior Consultant/Architect http://sdw.st 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Jan2000 From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 13:34:31 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21016 for ; Fri, 26 May 2000 13:34:31 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA25989; Fri, 26 May 2000 13:22:32 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8596470 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 13:22:28 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA25851 for ; Fri, 26 May 2000 13:22:05 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA10099 for urn-ietf@lists.internic.net; Fri, 26 May 2000 13:05:35 -0400 (EDT) Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by bailey.dscga.com (8.9.1/) with ESMTP id MAA10049 for ; Fri, 26 May 2000 12:54:46 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA16371; Fri, 26 May 2000 13:05:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 26 May 2000 13:05:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA16350; Fri, 26 May 2000 13:04:58 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA16337; Fri, 26 May 2000 13:04:55 -0400 (EDT) Received: from bailey.dscga.com (198.78.9.11 -> bailey.dscga.com) by cs.utk.edu (smtpshim v1.0); Fri, 26 May 2000 13:04:56 -0400 Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id MAA10043; Fri, 26 May 2000 12:53:49 -0400 (EDT) References: <200005261646.JAA26904@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i List-Unsubscribe: Approved-By: michael@BAILEY.DSCGA.COM Message-ID: <20000526125349.C9881@bailey.dscga.com> Date: Fri, 26 May 2000 13:05:35 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005261646.JAA26904@sonic.net>; from tallen@sonic.net on Fri, May 26, 2000 at 09:46:38AM -0700 On Fri, May 26, 2000 at 09:46:38AM -0700, Terry Allen wrote: > I see nothing objectionable about the request for a PIN NID, > including the NID requested. However, there are two points > in the document that concern me: > > "Identifiers are assigned by Network Solutions proprietary > registration system in a way that guarantees uniqueness." > > If this is all that need be said, it's not a very useful part of > the template. It amounts to "trust us". I thought about this and I couldn't figure out how to say it any more succinctly. Essentially we're just assigning some alpha-numeric blob of characters that is gauranteed to be unique. We may change the exact algorithm over time but it'll still be unique. Any suggestions as to how I should say that without it essentially being another version of "just trust us"? > "PIN URNs are resolved via URN resolvers run by Network > Solutions. The data and databases used by those resolvers is > proprietary data and can only be accessed by the resolver." > > This is false in part: if I apply for a PIN URN and supply information > about myself, that data is not proprietary to Network Solutions. It also > isn't clear whether NS considers the URN itself to be proprietary data, > although the passage about resolving PIN URNs via other resolvers suggests > it doesn't consider it proprietary. Good point... I'll clarify this and resubmit.... > Finally, what does a PIN URN resolve to? Certainly not to the named > entity (that is, an I2R will fail) if the named entity is a person or > corporation, as envisioned. An I2C presumably returns something, but > what? Again, a good point. I guess it should be more like this: The PIN URN names a network resource that is an electronic proxy for an individual or organization. In that case I2R would return (given content negotiation if available) some electronic object that describes the entity that is bound to that electronic proxy. Is that a better way of stating it? -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.INTERNIC.NET Fri May 26 13:37:52 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21088 for ; Fri, 26 May 2000 13:37:51 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA26528; Fri, 26 May 2000 13:24:54 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8596481 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 13:24:51 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA26012 for ; Fri, 26 May 2000 13:22:36 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA10103 for urn-ietf@lists.internic.net; Fri, 26 May 2000 13:06:12 -0400 (EDT) Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by bailey.dscga.com (8.9.1/) with ESMTP id NAA10094 for ; Fri, 26 May 2000 13:04:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA17271; Fri, 26 May 2000 13:15:04 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 26 May 2000 13:15:03 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA17250; Fri, 26 May 2000 13:15:03 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA17224; Fri, 26 May 2000 13:14:54 -0400 (EDT) Received: from bailey.dscga.com (198.78.9.11 -> bailey.dscga.com) by cs.utk.edu (smtpshim v1.0); Fri, 26 May 2000 13:14:54 -0400 Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA10088; Fri, 26 May 2000 13:03:50 -0400 (EDT) References: <200005261646.JAA26904@sonic.net> <200005261652.MAA00569@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i List-Unsubscribe: Approved-By: michael@BAILEY.DSCGA.COM Message-ID: <20000526130350.D9881@bailey.dscga.com> Date: Fri, 26 May 2000 13:06:12 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005261652.MAA00569@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, May 26, 2000 at 12:52:58PM -0400 On Fri, May 26, 2000 at 12:52:58PM -0400, Keith Moore wrote: > > I see nothing objectionable about the request for a PIN NID, > > including the NID requested. However, there are two points > > in the document that concern me: > > > > "Identifiers are assigned by Network Solutions proprietary > > registration system in a way that guarantees uniqueness." > > > > If this is all that need be said, it's not a very useful part of > > the template. It amounts to "trust us". > > I agree with this; it needs to have sufficient detail to permit the > review group to understand whether their method of assuring uniqueness > is likely to succeed. See my response to Terry for questions on how I can word this better... > > "PIN URNs are resolved via URN resolvers run by Network > > Solutions. The data and databases used by those resolvers is > > proprietary data and can only be accessed by the resolver." > > there's something inherently wrong here. URNs are supposed to be > independent of any single resolution service, and the notion that > the resolution service owns the data (rather than the owner of > the URN) is contrary to the purpose of URNs. I do need to edit the part where we say we own the data. That's wrong. We are saying we own the URN and the binding between that and the data in the database. In the same way that ISBN owns the rights to the actual ISBN number and any database associated with it but not the book that it names. And what does this mean: "URNs are supposed to be independent of any single resolution service"? Yes you can use any resolution service that you want but you can't assume its authoritative unless you ask the one designated by the entity that registered the namespace. -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.INTERNIC.NET Fri May 26 13:48:05 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21329 for ; Fri, 26 May 2000 13:48:05 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA29030; Fri, 26 May 2000 13:34:55 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8596579 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 13:34:53 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA28998 for ; Fri, 26 May 2000 13:34:49 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA10153; Fri, 26 May 2000 13:17:25 -0400 (EDT) References: <20000526130350.D9881@bailey.dscga.com> <200005261719.NAA00956@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000526131724.E9881@bailey.dscga.com> Date: Fri, 26 May 2000 13:17:24 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005261719.NAA00956@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, May 26, 2000 at 01:19:44PM -0400 On Fri, May 26, 2000 at 01:19:44PM -0400, Keith Moore wrote: > > We are saying we own the URN and the binding between that and the data in > > the database. > > but you don't own the URN. nor do you own the binding. See below.... > > In the same way that ISBN owns the rights to the actual ISBN number > > and any database associated with it but not the book that it names. > > ISBN might claim to own the rights to the number, but they certainly > don't have the right to "any database associated with it". ISBNs are > used as keys to many different databases which are not owned by any > top-level agency. I'm afraid they'll disagree with you on that one... > > And what does this mean: "URNs are supposed to be independent of any > > single resolution service"? > > exactly what it says it means. > > > Yes you can use any resolution service > > that you want but you can't assume its authoritative unless you ask > > the one designated by the entity that registered the namespace. > > uh, no. the entity that registered the namespace isn't inherently > authoritative for resolution. namespaces have authority over name > assignment, they do not have authority over resolution. Sigh. This has never been stated before by anyone during the entire process of talking about URNs. This would be such a fundamental shift in what URNs are that, IMNSHO, it undermines the entire concept of URNs as designed. You are basically saying that no one owns anything and that is simply rediculous. I'm CC-ing this to the URN list because if this is the concensus of the Working Group then URNs are so completely and utterly flawed and out of touch with the way the world works as to make them completely useless.... -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.INTERNIC.NET Fri May 26 14:09:40 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21941 for ; Fri, 26 May 2000 14:09:39 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA05120; Fri, 26 May 2000 14:01:06 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8596797 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 14:01:04 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA05022 for ; Fri, 26 May 2000 14:00:45 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA10294; Fri, 26 May 2000 13:43:15 -0400 (EDT) References: <20000526131724.E9881@bailey.dscga.com> <200005261736.NAA01310@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000526134315.I9881@bailey.dscga.com> Date: Fri, 26 May 2000 13:43:15 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005261736.NAA01310@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, May 26, 2000 at 01:36:57PM -0400 On Fri, May 26, 2000 at 01:36:57PM -0400, Keith Moore wrote: > > I'm CC-ing this to the URN list because if this is the concensus of > > the Working Group then URNs are so completely and utterly flawed and > > out of touch with the way the world works as to make them completely > > useless.... > > URNs are not out of touch with the way the world works, but people > keep trying to use them for things for which they were not designed. Keith, I think there may be a real disconnect from what you think the design was and what it really is. I'm going to let the working group make this decision, not your personal assertions.... -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.INTERNIC.NET Fri May 26 14:11:08 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21971 for ; Fri, 26 May 2000 14:11:08 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA05047; Fri, 26 May 2000 14:00:49 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8596791 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 14:00:47 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA04921 for ; Fri, 26 May 2000 14:00:20 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA10302 for urn-ietf@lists.internic.net; Fri, 26 May 2000 13:43:56 -0400 (EDT) Received: from netsol.com (bipmx0.lb.netsol.com [216.168.225.2] (may be forged)) by bailey.dscga.com (8.9.1/) with ESMTP id NAA10214 for ; Fri, 26 May 2000 13:27:03 -0400 (EDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by netsol.com (8.9.3/8.9.3) with ESMTP id NAA17338 for ; Fri, 26 May 2000 13:36:57 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA01310; Fri, 26 May 2000 13:36:57 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ X-SUBJECT-MSG-FROM: Michael Mealling Approved-By: michael@BAILEY.DSCGA.COM Message-ID: <200005261736.NAA01310@astro.cs.utk.edu> Date: Fri, 26 May 2000 13:43:55 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 26 May 2000 13:17:24 EDT." <20000526131724.E9881@bailey.dscga.com> > I'm CC-ing this to the URN list because if this is the concensus of > the Working Group then URNs are so completely and utterly flawed and > out of touch with the way the world works as to make them completely > useless.... URNs are not out of touch with the way the world works, but people keep trying to use them for things for which they were not designed. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 14:14:27 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22068 for ; Fri, 26 May 2000 14:14:27 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA06232; Fri, 26 May 2000 14:05:41 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8596842 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 14:05:39 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA06209 for ; Fri, 26 May 2000 14:05:36 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA10336; Fri, 26 May 2000 13:48:02 -0400 (EDT) References: <20000526131724.E9881@bailey.dscga.com> <200005261735.NAA01259@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000526134802.J9881@bailey.dscga.com> Date: Fri, 26 May 2000 13:48:02 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005261735.NAA01259@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, May 26, 2000 at 01:35:23PM -0400 On Fri, May 26, 2000 at 01:35:23PM -0400, Keith Moore wrote: > no michael. the fundamental principle behind URNs is that resolution > services and name space assignement are disassociated. this is necessary > to ensure longevity of URNs. Assignment and resolution are disasociated but what constitutes AUTHORITATIVE resolution cannot violate the rules specified by the namespace. To do that would make URNs impossible to persist since any resolver can come along and assert that the URN names foo instead of bar. I.e. If ISBN can't say what is authoritative resolution and what isn't then ISBN numbers are no more persistent than asking someone's personal opinion on the matter.... -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.INTERNIC.NET Fri May 26 14:14:42 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22080 for ; Fri, 26 May 2000 14:14:42 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA06317; Fri, 26 May 2000 14:05:58 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8596739 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 14:05:56 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA00594 for ; Fri, 26 May 2000 13:41:22 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA01259; Fri, 26 May 2000 13:35:23 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ X-SUBJECT-MSG-FROM: Michael Mealling Message-ID: <200005261735.NAA01259@astro.cs.utk.edu> Date: Fri, 26 May 2000 13:35:23 -0400 Reply-To: moore@CS.UTK.EDU From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 26 May 2000 13:17:24 EDT." <20000526131724.E9881@bailey.dscga.com> no michael. the fundamental principle behind URNs is that resolution services and name space assignement are disassociated. this is necessary to ensure longevity of URNs. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 15:28:37 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23425 for ; Fri, 26 May 2000 15:28:37 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA15157; Fri, 26 May 2000 15:19:55 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597199 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 15:19:53 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA13344 for ; Fri, 26 May 2000 15:02:24 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA02343; Fri, 26 May 2000 14:56:28 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ X-SUBJECT-MSG-FROM: Michael Mealling Message-ID: <200005261856.OAA02343@astro.cs.utk.edu> Date: Fri, 26 May 2000 14:56:28 -0400 Reply-To: moore@CS.UTK.EDU From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 26 May 2000 13:48:02 EDT." <20000526134802.J9881@bailey.dscga.com> > > no michael. the fundamental principle behind URNs is that resolution > > services and name space assignement are disassociated. this is necessary > > to ensure longevity of URNs. > > Assignment and resolution are disasociated but what constitutes > AUTHORITATIVE resolution cannot violate the rules specified by > the namespace. To do that would make URNs impossible to persist since > any resolver can come along and assert that the URN names foo instead > of bar. at most, what is authoritative is determined by the owner of the URN, not by the owner of the namespace. if you try to tie the two kinds of authority together then you effectively limit the longevity of URNs to the longevity of the resolution service. > I.e. If ISBN can't say what is authoritative resolution and what isn't > then ISBN numbers are no more persistent than asking someone's personal > opinion on the matter.... the binding between the ISBN and the work is well established. but it would be difficult to even try to define the exact set of metadata associated with the work, much less to say who was the authoritative source of each piece of metadata. there is no one set of metadata that describes a work, and each piece of metadata can come from a variety of different sources. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 15:31:42 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23573 for ; Fri, 26 May 2000 15:31:42 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA15077; Fri, 26 May 2000 15:19:21 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597196 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 15:19:19 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA12977 for ; Fri, 26 May 2000 14:58:21 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA02291; Fri, 26 May 2000 14:52:28 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ X-SUBJECT-MSG-FROM: Michael Mealling Message-ID: <200005261852.OAA02291@astro.cs.utk.edu> Date: Fri, 26 May 2000 14:52:28 -0400 Reply-To: moore@CS.UTK.EDU From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 26 May 2000 13:43:15 EDT." <20000526134315.I9881@bailey.dscga.com> > Keith, I think there may be a real disconnect from what you think the > design was and what it really is. ``When I use a word,'' Humpty Dumpty said in a rather scornful tone, ``it means just what I choose it to mean--neither more nor less.'' ``The question is,'' said Alice, ``whether you _can_ make words mean so many different things.'' ``The question is,'' said Humpty Dumpty, ``which is to be master-- that's all.'' - from Through the Looking Glass by Lewis Carroll From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 15:35:11 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23659 for ; Fri, 26 May 2000 15:35:10 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA16008; Fri, 26 May 2000 15:25:11 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597297 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 15:25:09 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA14775 for ; Fri, 26 May 2000 15:16:15 -0400 (EDT) Received: from thinkingcat.com ([207.253.222.85]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FV60071OKYJLB@falla.videotron.net> for urn-ietf@lists.internic.net; Fri, 26 May 2000 15:03:57 -0400 (EDT) MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20000526131724.E9881@bailey.dscga.com> <200005261735.NAA01259@astro.cs.utk.edu> <20000526134802.J9881@bailey.dscga.com> Message-ID: <392ECA3A.6142D8DB@thinkingcat.com> Date: Fri, 26 May 2000 15:02:18 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: URN namespaces and control [was Re: re PIN URN request document] To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit First, as WG chair: I've trimmed the cc: list and modified the subject line because I think this touches on fundamental issues that the WG has to decide how to handle. An organization (and, truly, it doesn't matter what organization) has requested a URN namespace ID, and has stated that the assignment process and access to resolution databases will be proprietary (i.e., opaque to the rest of the world). Two separate issues are on the table: . do we have a problem with this (i.e., in terms of reasoned arguments, how it damages URNs/Internet infrastructure)? . do we take a stance on "who owns the name/registry" and act accordingly, or is that within our scope? Some opinions have been offered on both these points -- I would very much like to hear more, if others feel strongly moved by the issues. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 15:41:35 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23732 for ; Fri, 26 May 2000 15:41:34 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA15356; Fri, 26 May 2000 15:20:55 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597239 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 15:20:53 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA15341 for ; Fri, 26 May 2000 15:20:50 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA10604; Fri, 26 May 2000 15:02:50 -0400 (EDT) References: <20000526134802.J9881@bailey.dscga.com> <200005261856.OAA02343@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000526150249.Q9881@bailey.dscga.com> Date: Fri, 26 May 2000 15:02:49 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005261856.OAA02343@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, May 26, 2000 at 02:56:28PM -0400 On Fri, May 26, 2000 at 02:56:28PM -0400, Keith Moore wrote: > > > no michael. the fundamental principle behind URNs is that resolution > > > services and name space assignement are disassociated. this is necessary > > > to ensure longevity of URNs. > > > > Assignment and resolution are disasociated but what constitutes > > AUTHORITATIVE resolution cannot violate the rules specified by > > the namespace. To do that would make URNs impossible to persist since > > any resolver can come along and assert that the URN names foo instead > > of bar. > > at most, what is authoritative is determined by the owner of the URN, > not by the owner of the namespace. if you try to tie the two kinds > of authority together then you effectively limit the longevity of URNs > to the longevity of the resolution service. If the owner of the namespace refuses to assign anymore names in that space and refuses to resolve the names it means that no one can then come along and claim to be able to do that authoritatively, yes. E.g. if the ISBN space were to be deprecated by the ISBN organization in favor of something else it would mean that if I had an ISBN number I could no longer ask anyone with any authority what that ISBN number named. I can still use it. I can even use it to talk to others, but I can no longer ask someone if I'm using it in an authoritative way. For example, lets say the ISBN organization goes away and you've been using 2345-543-X to idenfity a copy of "Alice in Wonderland". Then the publisher puts out another copy and you attempt to keep using that same ISBN number to talk about that new copy of the book. Unless you are the ISBN organization (which you aren't), you don't have the authority to make that claim anymore. > > I.e. If ISBN can't say what is authoritative resolution and what isn't > > then ISBN numbers are no more persistent than asking someone's personal > > opinion on the matter.... > > the binding between the ISBN and the work is well established. > but it would be difficult to even try to define the exact set of > metadata associated with the work, much less to say who was the > authoritative source of each piece of metadata. there is no one > set of metadata that describes a work, and each piece of metadata > can come from a variety of different sources. Huh? The metadata surrounding the book is really irrelevant here. We're only talking about the binding of a name to the thing it names. I'm having some real trouble following how that last paragraph has any bearing on whether ISBN is authoritative for its own namespace... -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.INTERNIC.NET Fri May 26 16:11:44 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24482 for ; Fri, 26 May 2000 16:11:44 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA20333; Fri, 26 May 2000 15:59:22 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597553 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 15:59:19 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA18308 for ; Fri, 26 May 2000 15:42:15 -0400 (EDT) Received: from thinkingcat.com ([207.253.222.85]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FV600CO3M4ZK3@falla.videotron.net> for urn-ietf@lists.internic.net; Fri, 26 May 2000 15:29:25 -0400 (EDT) MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20000526131724.E9881@bailey.dscga.com> <200005261735.NAA01259@astro.cs.utk.edu> <20000526134802.J9881@bailey.dscga.com> <392ECA3A.6142D8DB@thinkingcat.com> Message-ID: <392ED031.FD2D4E2B@thinkingcat.com> Date: Fri, 26 May 2000 15:27:45 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: URN namespaces and control [was Re: re PIN URN request document] To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Now, setting aside my WG chair hat, here's my personal opinion as a WG participant: I believe that what we've created in this WG is an infrastructure much like any other protocol -- it can be used or abused, but the extent of our scope is to offer enough detail of how to use this infrastructure that people can, and hopefully will, build identifier systems that will have the desirable qualities of persistence and uniqueness. I don't think there's any reasonable way to _mandate_ well-behaved naming systems. Is the current proposal a use or abuse of the infrastructure? It doesn't prevent anyone else from doing their thing; it doesn't (appear to) overload the DNS or otherwise cause major Internet infrastructure issues. Will it be successful, and persistent? Can't say -- and not just because they don't expose their intentions. But I don't personally believe it's an abuse. I would be happier if the first externally-proposed namespace to make it through the registration process wasn't an opaque one like this -- but that's not NSI's fault, we've had years for people to step forward and propose more open ones (some are in process -- but are wending their way tranquilly towards registration). Leslie Daigle wrote: > . do we have a problem with this (i.e., in terms of > reasoned arguments, how it damages URNs/Internet > infrastructure)? I would be happier if there were other organization-specific URN NIDs that were on the table and less opaque, but I think this kind of namespace is inevitable and not altogether evil. I don't have a problem with it. (Frankly, I have spent some hours trying to figure out how to make a personal URN namespace useful and "monetizable", and only for the reason that I never figured out how to make it worth my while have I not proposed one. Maybe I am an evil capitalist. I think I'm just being pragmatic). > . do we take a stance on "who owns the name/registry" > and act accordingly, or is that within our scope? Let's not go there. If some organization wants to claim it owns the data or owns the name, let them get sued over it. URNs are strings. Anyone can make up a string and claim it's a URN:PIN: identifier. If NSI think that harms its business, let NSI sue the person who did it, but that's a business problem, not an identifier one. If someone writes software and claimes to do "local" resolution of a URN:PIN:, then this is hijacking, much like "transparent proxies" do. If it's done with the knowledge of the client, that's one thing; if not, it's wrong no matter how you slice it. And as for comparisons to ISBN -- if the ISBN agency decides to register a URN namespace, I doubt they'll do it if they don't feel they have control over how resolution goes -- i.e., to the services that they offer. The beauty of the URN infrastructure, as we've defined it, is that even though such control is possible, it is also possible to delegate authority, and/or offer an open system wherein ISBN agency runs some of the services offered through resolution, and encourages other-party services alongside those. That one particular namespace doesn't elect to take advantage of the openness is, I think, not our problem. /alterLeslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 16:19:49 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24638 for ; Fri, 26 May 2000 16:19:48 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA21810; Fri, 26 May 2000 16:08:52 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597550 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 16:08:49 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA17478 for ; Fri, 26 May 2000 15:35:35 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA02858; Fri, 26 May 2000 15:29:41 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ X-SUBJECT-MSG-FROM: Michael Mealling Message-ID: <200005261929.PAA02858@astro.cs.utk.edu> Date: Fri, 26 May 2000 15:29:41 -0400 Reply-To: moore@CS.UTK.EDU From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 26 May 2000 15:02:49 EDT." <20000526150249.Q9881@bailey.dscga.com> > > > > no michael. the fundamental principle behind URNs is that resolution > > > > services and name space assignement are disassociated. this is necessary > > > > to ensure longevity of URNs. > > > > > > Assignment and resolution are disasociated but what constitutes > > > AUTHORITATIVE resolution cannot violate the rules specified by > > > the namespace. To do that would make URNs impossible to persist since > > > any resolver can come along and assert that the URN names foo instead > > > of bar. > > > > at most, what is authoritative is determined by the owner of the URN, > > not by the owner of the namespace. if you try to tie the two kinds > > of authority together then you effectively limit the longevity of URNs > > to the longevity of the resolution service. > > If the owner of the namespace refuses to assign anymore names in that > space and refuses to resolve the names it means that no one can then > come along and claim to be able to do that authoritatively, yes. maybe there's a confusion between different kinds of authority here. once a URN is assigned to a work, the authoritative meaning of the URN is that work. this isn't supposed to change, ever. but that doesn't mean that there's a single authoritative set of data about that work. the publisher might have one set of data. the author might have another. OCLC might have another. amazon.com and bn.com might have others. what matters is that the URNs are used consistently from one resolution service to another - URN X is always used to refer to the same work. it's not important that there be a single authoritative source of data about that work, and even trying to insist that there be a single authoritative source of data would actually undermine the longevity of URNs because it would limit their utility. it's like saying that anyone can comment on, or criticize, a work and refer to that work by name. neither the owner of the work nor the owner of the name of the work have any say about that. and creating metadata for a work is the same as commenting on the work. (so for instance I could assign PICS codes to works. that's a form of criticism or comment) > E.g. if the ISBN space were to be deprecated by the ISBN organization > in favor of something else it would mean that if I had an ISBN > number I could no longer ask anyone with any authority what that > ISBN number named. you should be able to determine what work is associated with a URN. but nobody controls that in the sense that they have the right to change the binding between the URN and the work, or that they have the right to say what metadata are authoritative about that work and which ones are not. furthermore once a URN is assigned the binding between the URN and the work have to be in the public domain; otherwise, it prevents other people from using the URN to refer to the work without paying some tribute to the other of the namespace. and without this freedom, URNs are a lot less useful. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 17:04:30 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25857 for ; Fri, 26 May 2000 17:04:29 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA00932; Fri, 26 May 2000 16:50:30 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597828 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 16:50:27 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by lists.internic.net (8.9.3/8.9.3) with SMTP id QAA27616 for ; Fri, 26 May 2000 16:34:03 -0400 (EDT) Received: (qmail 20755 invoked from network); 26 May 2000 20:28:12 -0000 Received: from buzz.sonic.net (208.201.224.78) by marine.sonic.net with SMTP; 26 May 2000 20:28:12 -0000 Received: from sonic.net (bolt [208.201.224.36]) by buzz.sonic.net (8.8.8/8.8.5) with ESMTP id NAA07133 for ; Fri, 26 May 2000 13:32:47 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id NAA04934 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 13:28:08 -0700 Message-ID: <200005262028.NAA04934@sonic.net> Date: Fri, 26 May 2000 13:28:08 -0700 Reply-To: Terry Allen From: Terry Allen Subject: further on PIN To: URN-IETF@LISTS.INTERNIC.NET I don't have an opinion on the acceptability of proprietary methods, which Leslie asked for comment on; on her other request for comment, I think that who owns the name is a matter for agreement between the owner of the name space and the entity request a name within it (or constructing a name within it). It would be better if we stayed out of business models. To several of Michael's questions: | I thought about this and I couldn't figure out how to say it any | more succinctly. Essentially we're just assigning some alpha-numeric | blob of characters that is gauranteed to be unique. We may change | the exact algorithm over time but it'll still be unique. Any | suggestions as to how I should say that without it essentially | being another version of "just trust us"? You surely can say why you think the name will surely be unique, short of describing the whole algorithm. Or you could say to what degree you've tested the algorithm. | Again, a good point. I guess it should be more like this: | The PIN URN names a network resource that is an electronic proxy | for an individual or organization. In that case I2R would return | (given content negotiation if available) some electronic object | that describes the entity that is bound to that electronic proxy. | Is that a better way of stating it? Much better, but now, just what is that "electronic proxy"? Is it immutable? can it be updated? (that would be okay by me, but it's important to know whether the URN is for "Terry's proxy [certificate?] as of 26 May 00" or "the latest version of Terry's proxy" - which is also a legitimate use of URNs. | Assignment and resolution are disasociated but what constitutes | AUTHORITATIVE resolution cannot violate the rules specified by | the namespace. I think you'd do better to drop the language about authoritative resolution from the request - it seems like another business issue, and you haven't explained in email the business reasoning behind it. If you're concerned to avoid spoofing of the proxy, then I think you want to use either URLs instead of URNs or proxies that are somehow digitally signed by NS (and that's as far as my knowledge of digital signatures goes these days). regards, Terry From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 17:04:47 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25872 for ; Fri, 26 May 2000 17:04:46 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA00546; Fri, 26 May 2000 16:48:39 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597814 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 16:48:36 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA00524 for ; Fri, 26 May 2000 16:48:33 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id QAA10851; Fri, 26 May 2000 16:31:31 -0400 (EDT) References: <20000526150249.Q9881@bailey.dscga.com> <200005261929.PAA02858@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000526163131.W9881@bailey.dscga.com> Date: Fri, 26 May 2000 16:31:31 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005261929.PAA02858@astro.cs.utk.edu>; from moore@CS.UTK.EDU on Fri, May 26, 2000 at 03:29:41PM -0400 On Fri, May 26, 2000 at 03:29:41PM -0400, Keith Moore wrote: >>>>>no michael. the fundamental principle behind URNs is that resolution >>>>>services and name space assignement are disassociated. this is necessary >>>>>to ensure longevity of URNs. >>>> >>>>Assignment and resolution are disasociated but what constitutes >>>>AUTHORITATIVE resolution cannot violate the rules specified by >>>>the namespace. To do that would make URNs impossible to persist since >>>>any resolver can come along and assert that the URN names foo instead >>>>of bar. >>> >>>at most, what is authoritative is determined by the owner of the URN, >>>not by the owner of the namespace. if you try to tie the two kinds >>>of authority together then you effectively limit the longevity of URNs >>>to the longevity of the resolution service. >> >>If the owner of the namespace refuses to assign anymore names in that >>space and refuses to resolve the names it means that no one can then >>come along and claim to be able to do that authoritatively, yes. > >maybe there's a confusion between different kinds of authority here. Possibly... >once a URN is assigned to a work, the authoritative meaning of the >URN is that work. this isn't supposed to change, ever. Correct... >but that doesn't mean that there's a single authoritative set of data >about that work. the publisher might have one set of data. the >author might have another. OCLC might have another. amazon.com >and bn.com might have others. No one has ever suggested otherwise. To attempt to do so would require KGB agents with us at all times to forbid us from speaking about something. To suggest that is what my document is saying is also reading soemthing into that isn't there.... >what matters is that the URNs are used consistently from one resolution >service to another - URN X is always used to refer to the same work. >it's not important that there be a single authoritative source of data >about that work, and even trying to insist that there be a single >authoritative source of data would actually undermine the longevity of >URNs because it would limit their utility. Ok. You're assuming that since someone says they are authoritative for something that they are forbiding someone else from making other assertions. That's not the case. When we assign a PIN to some person or organization we are saying "we have a relationship with that entity that no one else has". By "authoritative for the PIN space" we are saying that "sure, you can attempt to use that URN in your service but unless you have access to our relationship with that entity, no one should trust your assertions as having the full blessing of the entity being named". >it's like saying that anyone can comment on, or criticize, a work >and refer to that work by name. neither the owner of the work nor >the owner of the name of the work have any say about that. >and creating metadata for a work is the same as commenting on the work. No one has ever suggested otherwise. Let's look at it this way: The URN for our example: urn:pin:mm2136 names me personally... You use that URN in your system and you say, "Hey, I'm going to say that this URN has the human name of Michael Mealling". You can say that all day long. But unless you ask me via the PIN URN resolution service, you don't know if its true according to me or not. I may have changed my name. You can assert all sorts of things about me in your database using that URN to uniquely and persistently talk about me. But its just _you_ talking _about_ me. You might be calling me names for all I know. The key here is that its you talking about me with no other authority than your just one of several billion people on the planet. Now, if you go through the PIN resolution service you are rest assured that the information there is what _I_ say it is. That's authoritative... >(so for instance I could assign PICS codes to works. that's a form >of criticism or comment) Sure... but criticism or comment has nothing to do with this.... >>E.g. if the ISBN space were to be deprecated by the ISBN organization >>in favor of something else it would mean that if I had an ISBN >>number I could no longer ask anyone with any authority what that >>ISBN number named. > >you should be able to determine what work is associated with a URN. >but nobody controls that in the sense that they have the right to change >the binding between the URN and the work, or that they have the right >to say what metadata are authoritative about that work and which >ones are not. Huh? So I can't tell you that since I own the book that it costs $25? You are essentially claiming that there is no such thing as truth... >furthermore once a URN is assigned the binding between the URN and the work >have to be in the public domain; otherwise, it prevents other people >from using the URN to refer to the work without paying some tribute >to the other of the namespace. and without this freedom, URNs are a >lot less useful. Nope.... That's a personal policy preference on your part... -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.INTERNIC.NET Fri May 26 17:35:03 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26562 for ; Fri, 26 May 2000 17:35:02 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id RAA07904; Fri, 26 May 2000 17:24:01 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8597976 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 17:23:59 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id RAA03299 for ; Fri, 26 May 2000 17:00:59 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA03792; Fri, 26 May 2000 16:55:06 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Message-ID: <200005262055.QAA03792@astro.cs.utk.edu> Date: Fri, 26 May 2000 16:55:06 -0400 Reply-To: moore@CS.UTK.EDU From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 26 May 2000 16:31:31 EDT." <20000526163131.W9881@bailey.dscga.com> > >what matters is that the URNs are used consistently from one resolution > >service to another - URN X is always used to refer to the same work. > >it's not important that there be a single authoritative source of data > >about that work, and even trying to insist that there be a single > >authoritative source of data would actually undermine the longevity of > >URNs because it would limit their utility. > > Ok. You're assuming that since someone says they are authoritative > for something that they are forbiding someone else from making > other assertions. not quite, but close - to me it looks like NSI is saying "since we are authoritative for PINs, our assertions about things named by PINs are better than others' assertions about those things". I don't buy that, and I don't think IETF should support such a statement. > The URN for our example: urn:pin:mm2136 names me personally... > > You use that URN in your system and you say, "Hey, I'm going to say > that this URN has the human name of Michael Mealling". You can say > that all day long. But unless you ask me via the PIN URN resolution > service, you don't know if its true according to me or not. I may > have changed my name. but you are saying that the owner of PIN space has the right to make authoritative assertions about PINs *after the binding has taken place*. and that doesn't work in the long run. you could just as easily decide to sever your relationship with NSI and want the authoritative information about you and your PIN to be maintained by someone else. > >(so for instance I could assign PICS codes to works. that's a form > >of criticism or comment) > > Sure... but criticism or comment has nothing to do with this.... any assignment of metadata is a kind of criticism or comment. > >>E.g. if the ISBN space were to be deprecated by the ISBN organization > >>in favor of something else it would mean that if I had an ISBN > >>number I could no longer ask anyone with any authority what that > >>ISBN number named. > > > >you should be able to determine what work is associated with a URN. > >but nobody controls that in the sense that they have the right to change > >the binding between the URN and the work, or that they have the right > >to say what metadata are authoritative about that work and which > >ones are not. > > Huh? So I can't tell you that since I own the book that it costs $25? the publisher can say it has a suggested price. other booksellers may quote other prices. > You are essentially claiming that there is no such thing as truth... whose truth? > > >furthermore once a URN is assigned the binding between the URN and the work > >have to be in the public domain; otherwise, it prevents other people > >from using the URN to refer to the work without paying some tribute > >to the other of the namespace. and without this freedom, URNs are a > >lot less useful. > > Nope.... That's a personal policy preference on your part... nope. URNs were not intended to work this way. to claim that the namespace owns a part of URN space and is able to control use of that portion of URN space, undermines the purpose of URNs. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 17:37:26 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26615 for ; Fri, 26 May 2000 17:37:25 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id RAA08359; Fri, 26 May 2000 17:26:16 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8598035 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 17:26:13 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id RAA08325 for ; Fri, 26 May 2000 17:26:10 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id RAA10937; Fri, 26 May 2000 17:08:52 -0400 (EDT) References: <20000526163131.W9881@bailey.dscga.com> <200005262055.QAA03792@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000526170852.Z9881@bailey.dscga.com> Date: Fri, 26 May 2000 17:08:52 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005262055.QAA03792@astro.cs.utk.edu>; from moore@cs.utk.edu on Fri, May 26, 2000 at 04:55:06PM -0400 On Fri, May 26, 2000 at 04:55:06PM -0400, Keith Moore wrote: > > >what matters is that the URNs are used consistently from one resolution > > >service to another - URN X is always used to refer to the same work. > > >it's not important that there be a single authoritative source of data > > >about that work, and even trying to insist that there be a single > > >authoritative source of data would actually undermine the longevity of > > >URNs because it would limit their utility. > > > > Ok. You're assuming that since someone says they are authoritative > > for something that they are forbiding someone else from making > > other assertions. > > not quite, but close - to me it looks like NSI is saying > "since we are authoritative for PINs, our assertions about things > named by PINs are better than others' assertions about those things". > I don't buy that, and I don't think IETF should support such > a statement. Yes. We are saying that our assertions are better than others since they are being made by the entity itself via our resolution service. I.e. our resolution service is acting as a proxy for me personally and since the URN is naming my electronix proxy, I am the one that is making those statements and thus they have more weight than yours. > > The URN for our example: urn:pin:mm2136 names me personally... > > > > You use that URN in your system and you say, "Hey, I'm going to say > > that this URN has the human name of Michael Mealling". You can say > > that all day long. But unless you ask me via the PIN URN resolution > > service, you don't know if its true according to me or not. I may > > have changed my name. > > but you are saying that the owner of PIN space has the right to make > authoritative assertions about PINs *after the binding has taken place*. Yes we are. The URN names an electronic version of myself that I use to make authoritative assertions about myself.... > and that doesn't work in the long run. Your assertion that I think is false.... > you could just as easily decide > to sever your relationship with NSI and want the authoritative > information about you and your PIN to be maintained by someone else. If that's the kind of service you want then don't buy it from us... > > >(so for instance I could assign PICS codes to works. that's a form > > >of criticism or comment) > > > > Sure... but criticism or comment has nothing to do with this.... > > any assignment of metadata is a kind of criticism or comment. Yep. But its by a third party... The metadata behind a PIN URN is authoritative because it is a set of assertions I make about myself. > > >>E.g. if the ISBN space were to be deprecated by the ISBN organization > > >>in favor of something else it would mean that if I had an ISBN > > >>number I could no longer ask anyone with any authority what that > > >>ISBN number named. > > > > > >you should be able to determine what work is associated with a URN. > > >but nobody controls that in the sense that they have the right to change > > >the binding between the URN and the work, or that they have the right > > >to say what metadata are authoritative about that work and which > > >ones are not. > > > > Huh? So I can't tell you that since I own the book that it costs $25? > > the publisher can say it has a suggested price. other booksellers > may quote other prices. Nope. The publisher has a price that the bookseller has to pay. They may choose to resell it at a different price which is there business. > > You are essentially claiming that there is no such thing as truth... > > whose truth? My truth about me. My name is Michael Mealling until I say differently... > > >furthermore once a URN is assigned the binding between the URN and the work > > >have to be in the public domain; otherwise, it prevents other people > > >from using the URN to refer to the work without paying some tribute > > >to the other of the namespace. and without this freedom, URNs are a > > >lot less useful. > > > > Nope.... That's a personal policy preference on your part... > > nope. URNs were not intended to work this way. to claim that > the namespace owns a part of URN space and is able to control use > of that portion of URN space, undermines the purpose of URNs. If that's what you are assuming then I think you are dangerously wrong. But I'll leave that to the working group to decide. If this group decides that it will accept your policy suggestions as how URNs will work then I'll take that as fact. But until then its just your assertion. I.e. the group is authoritative for this, your assertion database isn't.... -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.INTERNIC.NET Fri May 26 19:10:06 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27517 for ; Fri, 26 May 2000 19:10:06 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id SAA26517; Fri, 26 May 2000 18:56:08 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8598265 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 18:56:05 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by lists.internic.net (8.9.3/8.9.3) with SMTP id SAA24748 for ; Fri, 26 May 2000 18:47:45 -0400 (EDT) Received: (qmail 2962 invoked from network); 26 May 2000 22:41:53 -0000 Received: from prop.sonic.net (208.201.224.193) by marine.sonic.net with SMTP; 26 May 2000 22:41:53 -0000 Received: from sonic.net (bolt [208.201.224.36]) by prop.sonic.net (8.8.8/8.8.5) with ESMTP id PAA14762 for ; Fri, 26 May 2000 15:41:54 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id PAA09780 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 15:41:53 -0700 Message-ID: <200005262241.PAA09780@sonic.net> Date: Fri, 26 May 2000 15:41:53 -0700 Reply-To: Terry Allen From: Terry Allen Subject: re PIN To: URN-IETF@LISTS.INTERNIC.NET [using "mail" I don't seem to be able to respond to the list] Micheal re Keith: | | >what matters is that the URNs are used consistently from one resolution | >service to another - URN X is always used to refer to the same work. | >it's not important that there be a single authoritative source of data | >about that work, and even trying to insist that there be a single | >authoritative source of data would actually undermine the longevity of | >URNs because it would limit their utility. | | Ok. You're assuming that since someone says they are authoritative | for something that they are forbiding someone else from making | other assertions. That's not the case. When we assign a PIN to | some person or organization we are saying "we have a relationship | with that entity that no one else has". By "authoritative for | the PIN space" we are saying that "sure, you can attempt to use | that URN in your service but unless you have access to our relationship | with that entity, no one should trust your assertions as having | the full blessing of the entity being named". Having spent the last year and a half on ISO 11179, I think there may be a conflation here of URN name space and metadata registry - NSI wants to assign URNs *and* maintain a metadata registry for which the URNs are the unique IDs (required by 11179) for a set of metadata about the thing named by the URN (the "assertions"). At least, that's the impression I'm getting, without further explanation of what the proxy is. So I think the remarks about the relationship with the entity apply much more strongly to the metadata registry than to the URN name space. Once a PIN is assigned to me, the fact that NSI assigned it isn't important for its use in designating me (Keith's point), but for its use in *authenticating* me (NSI's apparent intent), NSI's control of the metadata registry containing the authentication info is important. Stop me if I'm reading in something NSI doesn't intend. | The URN for our example: urn:pin:mm2136 names me personally... | | You use that URN in your system and you say, "Hey, I'm going to say | that this URN has the human name of Michael Mealling". You can say | that all day long. But unless you ask me via the PIN URN resolution | service, you don't know if its true according to me or not. I may | have changed my name. You're digging yourself a hole; now I want your document to say what happens to the URN when Michael Mealling changes his name: does it apply to the same person, the same person throughout his life, the same person only after the name change, or does it become deprecated? | You can assert all sorts of things about me in your database using | that URN to uniquely and persistently talk about me. But its just | _you_ talking _about_ me. You might be calling me names for all I know. But this is the use of URNs for designating, and these assertions are no better or worse than NSI's. | The key here is that its you talking about me with no other authority | than your just one of several billion people on the planet. Now, | if you go through the PIN resolution service you are rest assured that | the information there is what _I_ say it is. That's authoritative... So the URN names not you but your information about yourself as supplied to NSI. | >furthermore once a URN is assigned the binding between the URN and the work | >have to be in the public domain; otherwise, it prevents other people | >from using the URN to refer to the work without paying some tribute | >to the other of the namespace. and without this freedom, URNs are a | >lot less useful. | | Nope.... That's a personal policy preference on your part... I have to agree with Michael; URNs are about naming, and there may be cases where the identity of that which is named is not made public. Those particular URNs may be less useful in some contexts than those with public bindings, but that may make them more useful in other contexts. Keith re Michael: | > You use that URN in your system and you say, "Hey, I'm going to say | > that this URN has the human name of Michael Mealling". You can say | > that all day long. But unless you ask me via the PIN URN resolution | > service, you don't know if its true according to me or not. I may | > have changed my name. | | but you are saying that the owner of PIN space has the right to make | authoritative assertions about PINs *after the binding has taken place*. | and that doesn't work in the long run. you could just as easily decide | to sever your relationship with NSI and want the authoritative | information about you and your PIN to be maintained by someone else. True, which is why I say the URN is intended to name the info supplied to NSI; you might also have a different set of info elsewhere identified by a different URN (and even according to Michael's explanation, you might have multiple PINs with different sets of info at NSI, which could be useful in several practical ways). | > >furthermore once a URN is assigned the binding between the URN and the work | > >have to be in the public domain; otherwise, it prevents other people | > >from using the URN to refer to the work without paying some tribute | > >to the other of the namespace. and without this freedom, URNs are a | > >lot less useful. | > | > Nope.... That's a personal policy preference on your part... | | nope. URNs were not intended to work this way. to claim that | the namespace owns a part of URN space and is able to control use | of that portion of URN space, undermines the purpose of URNs. I think you'd better cite chapter and verse for that, Keith, or give up the argument. But I also think Michael doesn't have to defend against it if he adopts the view I set forth at the outset about name space vs. metadata registry. Michael re Keith: | > not quite, but close - to me it looks like NSI is saying | > "since we are authoritative for PINs, our assertions about things | > named by PINs are better than others' assertions about those things". | > I don't buy that, and I don't think IETF should support such | > a statement. | | Yes. We are saying that our assertions are better than others since | they are being made by the entity itself via our resolution service. | I.e. our resolution service is acting as a proxy for me personally | and since the URN is naming my electronix proxy, I am the one | that is making those statements and thus they have more weight than | yours. I think this is not a useful description ... | > > The URN for our example: urn:pin:mm2136 names me personally... | > > | > > You use that URN in your system and you say, "Hey, I'm going to say | > > that this URN has the human name of Michael Mealling". You can say | > > that all day long. But unless you ask me via the PIN URN resolution | > > service, you don't know if its true according to me or not. I may | > > have changed my name. | > | > but you are saying that the owner of PIN space has the right to make | > authoritative assertions about PINs *after the binding has taken place*. | | Yes we are. The URN names an electronic version of myself that I use | to make authoritative assertions about myself.... There is no electronic version of yourself. There is the collection of assertions. | Your assertion that I think is false.... | | > you could just as easily decide | > to sever your relationship with NSI and want the authoritative | > information about you and your PIN to be maintained by someone else. | | If that's the kind of service you want then don't buy it from us... Um, if NSI is not going to resolve URNs if the person related to them doesn't continue to pay for, then it can have no objection if the person arranges for some other resolution - unless it wants to assert that it owns the URNs, which is fairly dangerous ground. I do recall we dealt with exactly this case (it was Ron's motorcycle poet). | > > >(so for instance I could assign PICS codes to works. that's a form | > > >of criticism or comment) | > > | > > Sure... but criticism or comment has nothing to do with this.... | > | > any assignment of metadata is a kind of criticism or comment. | | Yep. But its by a third party... The metadata behind a PIN URN is | authoritative because it is a set of assertions I make about myself. That implies strongly that what is named is the set of assertions; that is, NSI's I2C and I2R would return the same thing. But another registry's I2C might return something different (a rating of the reliability of the URN, for example). | > > >>E.g. if the ISBN space were to be deprecated by the ISBN organization ISBNs have always been bad examples ... regards, Terry From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 19:43:16 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28021 for ; Fri, 26 May 2000 19:43:16 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA03836; Fri, 26 May 2000 19:31:02 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8598370 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 19:31:00 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA03808 for ; Fri, 26 May 2000 19:30:54 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id TAA11137; Fri, 26 May 2000 19:13:57 -0400 (EDT) References: <200005262241.PAA09780@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000526191357.C11042@bailey.dscga.com> Date: Fri, 26 May 2000 19:13:57 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: re PIN To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005262241.PAA09780@sonic.net>; from tallen@SONIC.NET on Fri, May 26, 2000 at 03:41:53PM -0700 On Fri, May 26, 2000 at 03:41:53PM -0700, Terry Allen wrote: > [using "mail" I don't seem to be able to respond to the list] as in /usr/bin/mail? > Micheal re Keith: > | > | >what matters is that the URNs are used consistently from one resolution > | >service to another - URN X is always used to refer to the same work. > | >it's not important that there be a single authoritative source of data > | >about that work, and even trying to insist that there be a single > | >authoritative source of data would actually undermine the longevity of > | >URNs because it would limit their utility. > | > | Ok. You're assuming that since someone says they are authoritative > | for something that they are forbiding someone else from making > | other assertions. That's not the case. When we assign a PIN to > | some person or organization we are saying "we have a relationship > | with that entity that no one else has". By "authoritative for > | the PIN space" we are saying that "sure, you can attempt to use > | that URN in your service but unless you have access to our relationship > | with that entity, no one should trust your assertions as having > | the full blessing of the entity being named". > > Having spent the last year and a half on ISO 11179, I think there may be > a conflation here of URN name space and metadata registry - NSI > wants to assign URNs *and* maintain a metadata registry for which > the URNs are the unique IDs (required by 11179) for a set of > metadata about the thing named by the URN (the "assertions"). > At least, that's the impression I'm getting, without further > explanation of what the proxy is. Yes. You are essentially correct. We are running both the URN assignment and the metadata registry... The 'proxy' is that set of metadata maintained by the entity (person or organization) who registered for the PIN. > So I think the remarks about the relationship with the entity > apply much more strongly to the metadata registry than to the > URN name space. Once a PIN is assigned to me, the fact that > NSI assigned it isn't important for its use in designating me > (Keith's point), but for its use in *authenticating* me (NSI's > apparent intent), NSI's control of the metadata registry > containing the authentication info is important. Yep... > Stop me if I'm reading in something NSI doesn't intend. Nope. Your dead on so far... > > | The URN for our example: urn:pin:mm2136 names me personally... > | > | You use that URN in your system and you say, "Hey, I'm going to say > | that this URN has the human name of Michael Mealling". You can say > | that all day long. But unless you ask me via the PIN URN resolution > | service, you don't know if its true according to me or not. I may > | have changed my name. > > You're digging yourself a hole; now I want your document to say what > happens to the URN when Michael Mealling changes his name: does it > apply to the same person, the same person throughout his life, the > same person only after the name change, or does it become deprecated? By the name I meant the name my parents gave me. Not the URN name. I.e. I.e. if I change my name from Michael Mealling to Michael Duncan (which is my fiance's last name) then that is also some piece of metadata associated with me that is obtainable via the metadata service which is accessed via the PIN URN resolution service. In this case, since URNs are for all time, you (the physical human being) have the URN forever (even beyond your lifetime). > | You can assert all sorts of things about me in your database using > | that URN to uniquely and persistently talk about me. But its just > | _you_ talking _about_ me. You might be calling me names for all I know. > > But this is the use of URNs for designating, and these assertions are > no better or worse than NSI's. Correct.... Anyone can and should use the URN for designating something. But if they want to create some piece of metadata about it and have it be authoritative then they'd better ask the individual being named to make it available the authoritative metadata service... > | The key here is that its you talking about me with no other authority > | than your just one of several billion people on the planet. Now, > | if you go through the PIN resolution service you are rest assured that > | the information there is what _I_ say it is. That's authoritative... > > So the URN names not you but your information about yourself as > supplied to NSI. Hmm... I think that's splitting a hair we don't intend on splitting. The URN names you the individual, we just supply an authoritative way of accessing your metadata via the network. > | >furthermore once a URN is assigned the binding between the URN and the work > | >have to be in the public domain; otherwise, it prevents other people > | >from using the URN to refer to the work without paying some tribute > | >to the other of the namespace. and without this freedom, URNs are a > | >lot less useful. > | > | Nope.... That's a personal policy preference on your part... > > I have to agree with Michael; URNs are about naming, and there may > be cases where the identity of that which is named is not made > public. Those particular URNs may be less useful in some contexts > than those with public bindings, but that may make them more useful > in other contexts. Yep. In many cases the user is specifically after a very closely managed and held namespace. Consider the namespace of credit card numbers. That should be very much a closed and very private space... > Keith re Michael: > | > You use that URN in your system and you say, "Hey, I'm going to say > | > that this URN has the human name of Michael Mealling". You can say > | > that all day long. But unless you ask me via the PIN URN resolution > | > service, you don't know if its true according to me or not. I may > | > have changed my name. > | > | but you are saying that the owner of PIN space has the right to make > | authoritative assertions about PINs *after the binding has taken place*. > | and that doesn't work in the long run. you could just as easily decide > | to sever your relationship with NSI and want the authoritative > | information about you and your PIN to be maintained by someone else. > > True, which is why I say the URN is intended to name the info > supplied to NSI; you might also have a different set of info elsewhere > identified by a different URN (and even according to Michael's > explanation, you might have multiple PINs with different sets of > info at NSI, which could be useful in several practical ways). Sure. Although I think the fact that we're talking about naming physical objects on a virtual network is throwing a red herring in here. I guess until we can transport physical objects and/or lifeforms our two viewpoints have to be synonymous. One of the possible ideas is that you can have multiple PIN URNs in NSI's database allowing you to have multiple non-related proxies (I like the word avatar) available. By using one PIN URN to identify myself I can be known as "John Doe" with no other information for privacy reasons. Via another I can let all of my personal information hang out (if I so desire). > | > >furthermore once a URN is assigned the binding between the URN and the work > | > >have to be in the public domain; otherwise, it prevents other people > | > >from using the URN to refer to the work without paying some tribute > | > >to the other of the namespace. and without this freedom, URNs are a > | > >lot less useful. > | > > | > Nope.... That's a personal policy preference on your part... > | > | nope. URNs were not intended to work this way. to claim that > | the namespace owns a part of URN space and is able to control use > | of that portion of URN space, undermines the purpose of URNs. > > I think you'd better cite chapter and verse for that, Keith, or > give up the argument. But I also think Michael doesn't have to > defend against it if he adopts the view I set forth at the outset > about name space vs. metadata registry. Agreed... > Michael re Keith: > | > not quite, but close - to me it looks like NSI is saying > | > "since we are authoritative for PINs, our assertions about things > | > named by PINs are better than others' assertions about those things". > | > I don't buy that, and I don't think IETF should support such > | > a statement. > | > | Yes. We are saying that our assertions are better than others since > | they are being made by the entity itself via our resolution service. > | I.e. our resolution service is acting as a proxy for me personally > | and since the URN is naming my electronix proxy, I am the one > | that is making those statements and thus they have more weight than > | yours. > > I think this is not a useful description ... I guess what I'm getting at, using your metadata registry verbage, is that the data in our metadata registry originated from the entity being named and not some third party. Thus it has more weight since its assertions come directly from the entity that originated that particular piece of metadata... > | > > The URN for our example: urn:pin:mm2136 names me personally... > | > > > | > > You use that URN in your system and you say, "Hey, I'm going to say > | > > that this URN has the human name of Michael Mealling". You can say > | > > that all day long. But unless you ask me via the PIN URN resolution > | > > service, you don't know if its true according to me or not. I may > | > > have changed my name. > | > > | > but you are saying that the owner of PIN space has the right to make > | > authoritative assertions about PINs *after the binding has taken place*. > | > | Yes we are. The URN names an electronic version of myself that I use > | to make authoritative assertions about myself.... > > There is no electronic version of yourself. There is the collection of > assertions. Hmm... Ok. How's this: Yes we are. The URN names a set of assertions about myself that I, by contract, assert as being the only source of assertions that you can trust as being authored by me. > | Your assertion that I think is false.... > | > | > you could just as easily decide > | > to sever your relationship with NSI and want the authoritative > | > information about you and your PIN to be maintained by someone else. > | > | If that's the kind of service you want then don't buy it from us... > > Um, if NSI is not going to resolve URNs if the person related to them > doesn't continue to pay for, then it can have no objection if the > person arranges for some other resolution - unless it wants to assert > that it owns the URNs, which is fairly dangerous ground. I do recall > we dealt with exactly this case (it was Ron's motorcycle poet). Yep. Since we assign them permanently (as a good URN namespace should), the owner can always decide to take it to some other resolver service. But if you follow the URN Resolution algorithm, find the authoritative server for that URN, and ask it about the URN it won't return anything. > | > > >(so for instance I could assign PICS codes to works. that's a form > | > > >of criticism or comment) > | > > > | > > Sure... but criticism or comment has nothing to do with this.... > | > > | > any assignment of metadata is a kind of criticism or comment. > | > | Yep. But its by a third party... The metadata behind a PIN URN is > | authoritative because it is a set of assertions I make about myself. > > That implies strongly that what is named is the set of assertions; > that is, NSI's I2C and I2R would return the same thing. But another > registry's I2C might return something different (a rating of the > reliability of the URN, for example). Sure but if its via some other registry you won't be able to trust that the information in it was authored by the entity that the URN names. > | > > >>E.g. if the ISBN space were to be deprecated by the ISBN organization > > ISBNs have always been bad examples ... Ok.. s/ISBN/Handle/g I do like your verbage about the metadata registry. I'll definitly put that in the draft.... -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.INTERNIC.NET Fri May 26 21:21:54 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29082 for ; Fri, 26 May 2000 21:21:53 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id VAA25381; Fri, 26 May 2000 21:13:56 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8598623 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 21:13:53 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id VAA25310 for ; Fri, 26 May 2000 21:13:32 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id UAA11221 for urn-ietf@lists.internic.net; Fri, 26 May 2000 20:57:05 -0400 (EDT) Received: from netsol.com (bipmx1.lb.netsol.com [216.168.225.3] (may be forged)) by bailey.dscga.com (8.9.1/) with ESMTP id RAA11018 for ; Fri, 26 May 2000 17:55:04 -0400 (EDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by netsol.com (8.9.3/8.9.3) with ESMTP id SAA06359 for ; Fri, 26 May 2000 18:05:11 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA04412; Fri, 26 May 2000 18:05:10 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ X-SUBJECT-MSG-FROM: Michael Mealling Approved-By: michael@BAILEY.DSCGA.COM Message-ID: <200005262205.SAA04412@astro.cs.utk.edu> Date: Fri, 26 May 2000 20:57:05 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 26 May 2000 17:08:52 EDT." <20000526170852.Z9881@bailey.dscga.com> > On Fri, May 26, 2000 at 04:55:06PM -0400, Keith Moore wrote: > > > >what matters is that the URNs are used consistently from one resolution > > > >service to another - URN X is always used to refer to the same work. > > > >it's not important that there be a single authoritative source of data > > > >about that work, and even trying to insist that there be a single > > > >authoritative source of data would actually undermine the longevity of > > > >URNs because it would limit their utility. > > > > > > Ok. You're assuming that since someone says they are authoritative > > > for something that they are forbiding someone else from making > > > other assertions. > > > > not quite, but close - to me it looks like NSI is saying > > "since we are authoritative for PINs, our assertions about things > > named by PINs are better than others' assertions about those things". > > I don't buy that, and I don't think IETF should support such > > a statement. > > Yes. We are saying that our assertions are better than others since > they are being made by the entity itself via our resolution service. and I'm saying that just because you are delegated some namespace by IETF doesn't mean that IETF supports such an assertion. > I.e. our resolution service is acting as a proxy for me personally > and since the URN is naming my electronix proxy, I am the one > that is making those statements and thus they have more weight than > yours. this is not appropriate. just because I get a URN from you does not mean that I am authorizing you to speak for me in any manner whatsoever. > > but you are saying that the owner of PIN space has the right to make > > authoritative assertions about PINs *after the binding has taken place*. > > Yes we are. The URN names an electronic version of myself that I use > to make authoritative assertions about myself.... > > > and that doesn't work in the long run. > > Your assertion that I think is false.... whatever. I thought you did think, but perhaps I was wrong. :) > > you could just as easily decide > > to sever your relationship with NSI and want the authoritative > > information about you and your PIN to be maintained by someone else. > > If that's the kind of service you want then don't buy it from us... Hell, I don't even believe that so-called elected officials have the right to speak for me in matters of government even though I have some miniscule say in who they are... I surely don't believe that a completely independent agency that has no interest in me other than taking my money can speak for me...and any assertions by them I would descibe using words like libel, misrepresentation, or fraud. in certain very limited circumstances, I *might* let a lawyer speak on my behalf. but NSI is not a law firm. and personally I find the very idea that NSI (or anyone else) would claim to speak on my behalf just because I bought a name from them or because we had some random, unrelated business relationship, not only offensive but highly dangerous... so dangerous that if a company were to do this that it would be in the public interest to destroy that company utterly, by any available means. in the meantime, we shouldn't let IETF lend support to them. > > > >(so for instance I could assign PICS codes to works. that's a form > > > >of criticism or comment) > > > > > > Sure... but criticism or comment has nothing to do with this.... > > > > any assignment of metadata is a kind of criticism or comment. > > Yep. But its by a third party... The metadata behind a PIN URN is > authoritative because it is a set of assertions I make about myself. no, it's a set of assertions you're letting someone else make for you. because you claim that that someone else besides the owner of the PIN has the right to control those assertions. > > > You are essentially claiming that there is no such thing as truth... > > > > whose truth? > > My truth about me. My name is Michael Mealling until I say differently... we're not talking about your truth about you. we're talking about NSI's assertions about you...which might or might not correspond now or in the future to your assertions about you, much less the truth. > > > >furthermore once a URN is assigned the binding between the URN and the work > > > >have to be in the public domain; otherwise, it prevents other people > > > >from using the URN to refer to the work without paying some tribute > > > >to the other of the namespace. and without this freedom, URNs are a > > > >lot less useful. > > > > > > Nope.... That's a personal policy preference on your part... > > > > nope. URNs were not intended to work this way. to claim that > > the namespace owns a part of URN space and is able to control use > > of that portion of URN space, undermines the purpose of URNs. > > If that's what you are assuming then I think you are dangerously wrong. and I think it's even more dangerous for NSI to claim that it can speak on behalf of its customers. > But I'll leave that to the working group to decide. If this group > decides that it will accept your policy suggestions as how URNs will > work then I'll take that as fact. But until then its just your > assertion. I.e. the group is authoritative for this, your assertion > database isn't.... actually I think it's up to the IESG to decide. but they'd probably take the working group's opinion into account. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Fri May 26 21:24:10 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29098 for ; Fri, 26 May 2000 21:24:10 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id VAA25591; Fri, 26 May 2000 21:14:48 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8598642 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 21:14:46 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by lists.internic.net (8.9.3/8.9.3) with SMTP id UAA10956 for ; Fri, 26 May 2000 20:05:27 -0400 (EDT) Received: (qmail 12058 invoked from network); 26 May 2000 23:59:36 -0000 Received: from prop.sonic.net (208.201.224.193) by marine.sonic.net with SMTP; 26 May 2000 23:59:36 -0000 Received: from sonic.net (bolt [208.201.224.36]) by prop.sonic.net (8.8.8/8.8.5) with ESMTP id QAA03058 for ; Fri, 26 May 2000 16:59:36 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id QAA12894 for URN-IETF@LISTS.INTERNIC.NET; Fri, 26 May 2000 16:59:35 -0700 Message-ID: <200005262359.QAA12894@sonic.net> Date: Fri, 26 May 2000 16:59:35 -0700 Reply-To: Terry Allen From: Terry Allen Subject: re re PIN To: URN-IETF@LISTS.INTERNIC.NET Michael wrote: | On Fri, May 26, 2000 at 03:41:53PM -0700, Terry Allen wrote: | > [using "mail" I don't seem to be able to respond to the list] | | as in /usr/bin/mail? /bin/mail on my ISP, using Red Hat Linux. The problem is that Reply-To is set to the sender. Never mind. | > Stop me if I'm reading in something NSI doesn't intend. | | Nope. Your dead on so far... although I may have mixed two points of view. anyway ... | > | The URN for our example: urn:pin:mm2136 names me personally... | > | | > | You use that URN in your system and you say, "Hey, I'm going to say | > | that this URN has the human name of Michael Mealling". You can say | > | that all day long. But unless you ask me via the PIN URN resolution | > | service, you don't know if its true according to me or not. I may | > | have changed my name. | > | > You're digging yourself a hole; now I want your document to say what | > happens to the URN when Michael Mealling changes his name: does it | > apply to the same person, the same person throughout his life, the | > same person only after the name change, or does it become deprecated? | | By the name I meant the name my parents gave me. Not the URN name. I.e. | I.e. if I change my name from Michael Mealling to Michael Duncan (which | is my fiance's last name) then that is also some piece of metadata | associated with me that is obtainable via the metadata service which | is accessed via the PIN URN resolution service. In this case, since | URNs are for all time, you (the physical human being) have the URN | forever (even beyond your lifetime). That's what I had in mind, but it's specific set of info about you (which may change, and that's key) that's named. | > | You can assert all sorts of things about me in your database using | > | that URN to uniquely and persistently talk about me. But its just | > | _you_ talking _about_ me. You might be calling me names for all I know. | > | > But this is the use of URNs for designating, and these assertions are | > no better or worse than NSI's. | | Correct.... Anyone can and should use the URN for designating something. | But if they want to create some piece of metadata about it and have | it be authoritative then they'd better ask the individual being named | to make it available the authoritative metadata service... That's where I mixed points of view. I think, on reflection, that what's named isn't (in this context) metadata, but data. And you need it to be, as I'll explain. | > | The key here is that its you talking about me with no other authority | > | than your just one of several billion people on the planet. Now, | > | if you go through the PIN resolution service you are rest assured that | > | the information there is what _I_ say it is. That's authoritative... | > | > So the URN names not you but your information about yourself as | > supplied to NSI. | | Hmm... I think that's splitting a hair we don't intend on splitting. | The URN names you the individual, we just supply an authoritative | way of accessing your metadata via the network. There is no single set of "my metadata". What you want to say, I think, given your business motive, is that the PIN URN is for information about yourself *as supplied to NSI* (that gives you the hook you're looking for), and, separately (probably not in the URN NID document), that as this information is subject to change and URN resolution does not guard against spoofing of resources, anyone wanting to use this URN for very time-sensitive info, info that may be revised, or authentication, probably wants to use NSI to resolve the URN. That is, information that has no binding to a medium of dissemination (such as a physical book) is obtained more reliably from the publisher than from some other source (unless the obtainer has reason to trust the other source just as much as he trusts the publisher). ... | > | Yes. We are saying that our assertions are better than others since | > | they are being made by the entity itself via our resolution service. | > | I.e. our resolution service is acting as a proxy for me personally | > | and since the URN is naming my electronix proxy, I am the one | > | that is making those statements and thus they have more weight than | > | yours. | > | > I think this is not a useful description ... | | I guess what I'm getting at, using your metadata registry verbage, is that | the data in our metadata registry originated from the entity being named | and not some third party. Thus it has more weight since its assertions | come directly from the entity that originated that particular piece of | metadata... Well, no. Equifax is a more reliable source of info about my credit history than I am. And using your "John Doe" example, which I elided, the info in your registry isn't inherently reliable at all - you're not in fact named John Doe. That's why you need to argue from the bases that the info may be revised and that the info *is that provided to NSI* - otherwise I'd be able to get a PIN URN and then take it to a competing service for use. Or you need to argue that NSI owns the URN itself. | > | Yes we are. The URN names an electronic version of myself that I use | > | to make authoritative assertions about myself.... | > | > There is no electronic version of yourself. There is the collection of | > assertions. | | Hmm... Ok. How's this: | | Yes we are. The URN names a set of assertions about myself that I, by contract, | assert as being the only source of assertions that you can trust as | being authored by me. Better, but not quite on; it isn't the only source of self-assertions, and couldn't be - we make them all the time to various parties. My point is that it isn't the assignment of the URN that gives you a business case, it's the servicing of the assertion set. Your business would work equally well with ANY URN if that URN were disseminated with the information that the info is that provided to NSI and can be obtained there most reliably. | > Um, if NSI is not going to resolve URNs if the person related to them | > doesn't continue to pay for, then it can have no objection if the | > person arranges for some other resolution - unless it wants to assert | > that it owns the URNs, which is fairly dangerous ground. I do recall | > we dealt with exactly this case (it was Ron's motorcycle poet). | | Yep. Since we assign them permanently (as a good URN namespace should), | the owner can always decide to take it to some other resolver service. | But if you follow the URN Resolution algorithm, find the authoritative | server for that URN, and ask it about the URN it won't return anything. There is no "authoritative server". You mean "the NSI server that still (falsely) claims to resolve that URN" or "claims that it resolves that class of URNs but won't resolve this one", in which case it would be interesting to know what error listed in RFC 2483 section 4.3 you'd return. | > | Yep. But its by a third party... The metadata behind a PIN URN is | > | authoritative because it is a set of assertions I make about myself. | > | > That implies strongly that what is named is the set of assertions; | > that is, NSI's I2C and I2R would return the same thing. But another | > registry's I2C might return something different (a rating of the | > reliability of the URN, for example). | | Sure but if its via some other registry you won't be able to trust that | the information in it was authored by the entity that the URN names. Depends on how much I know about that registry and the entity, but anyway, that's why you have to say that the info is that provided to NSI (and assert that NSI doesn't get duped by its customers, ahem). ... | I do like your verbage about the metadata registry. I'll definitly put | that in the draft.... Thanks, but think about it as data in this context (metadata in some other context). regards, Terry regards, Terry From owner-urn-ietf@LISTS.INTERNIC.NET Sat May 27 20:16:59 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22212 for ; Sat, 27 May 2000 20:16:58 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA05200; Sat, 27 May 2000 19:59:46 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8599792 for URN-IETF@LISTS.INTERNIC.NET; Sat, 27 May 2000 19:59:43 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id LAA00866 for ; Sat, 27 May 2000 11:15:09 -0400 (EDT) Received: from carol (h00a0cc5364a4.ne.mediaone.net [24.128.116.234]) by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.20) with SMTP id LAA17603; Sat, 27 May 2000 11:08:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Sat, 27 May 2000 11:40:23 -0400 Reply-To: Phillip Hallam-Baker From: Phillip Hallam-Baker Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200005262055.QAA03792@astro.cs.utk.edu> Content-Transfer-Encoding: 7bit >> Nope.... That's a personal policy preference on your part... >nope. URNs were not intended to work this way. to claim that >the namespace owns a part of URN space and is able to control use >of that portion of URN space, undermines the purpose of URNs. Intended by whom? One of the things that has continually anoyed me about this group is that every time someone gives an opinion we get these categorical statements of authority. Michaels's interpretation of a URN is certainly compatible with interpretations I have discussed with Tim long before the origninal URN working group was formed. As a point of fact the workings of the ISBN, Barcode and Dun and Bradstreet number systems appear to be incompatible with Keith's idea of a URN. EVERY functioning, distributed registry system has the concept of delegated management of the namespace. Delegates effectively 'control' their subspaces within the namespace. The only purpose the IETF has any business with is writing specs that describe 'usefull stuff'. That is in my view the test of a naming scheme. If someone can define 'uniqueness' of a name then they are doing much better than the best minds in 20th century philosophy. The risk of non-uniqueness needs to be considered as just that - a risk, something that will always be present but that can in most practical circumstances be mitigated to any desired degree at the cost of increased resources. From a legal perspective the issue is that of a definitive authority. If a fraud is conducted by manipulation of URNs or some such the interest of the court will be to find an unambiguous authority to pronounce an opinion on the semantics attached to a name. Phill (who these days works for VRSN but has been saying the same thing for the past eight years). From owner-urn-ietf@LISTS.INTERNIC.NET Sat May 27 23:50:52 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25816 for ; Sat, 27 May 2000 23:50:52 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id XAA18446; Sat, 27 May 2000 23:34:07 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8599921 for URN-IETF@LISTS.INTERNIC.NET; Sat, 27 May 2000 23:34:05 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from oa1-server.dev.oclc.org (oa1-server.dev.oclc.org [132.174.19.60]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id WAA03726 for ; Sat, 27 May 2000 22:25:02 -0400 (EDT) Received: by oa1-server.dev.oclc.org with Internet Mail Service (5.5.2650.21) id ; Sat, 27 May 2000 22:19:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 27 May 2000 22:19:00 -0400 Reply-To: "Weibel,Stu" From: "Weibel,Stu" Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET P H-B opines: EVERY functioning, distributed registry system has the concept of delegated management of the namespace. Delegates effectively 'control' their subspaces within the namespace. I think he has a point there. stu From owner-urn-ietf@LISTS.INTERNIC.NET Sun May 28 16:27:42 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10127 for ; Sun, 28 May 2000 16:27:42 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA05409; Sun, 28 May 2000 16:18:38 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8600696 for URN-IETF@LISTS.INTERNIC.NET; Sun, 28 May 2000 16:18:35 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA04166 for ; Sun, 28 May 2000 16:12:38 -0400 (EDT) Received: from thinkingcat.com ([207.253.211.134]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FVA00A4QCV94P@field.videotron.net> for URN-IETF@LISTS.INTERNIC.NET; Sun, 28 May 2000 15:59:35 -0400 (EDT) MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200005262205.SAA04412@astro.cs.utk.edu> Message-ID: <39317A3D.7DB168B6@thinkingcat.com> Date: Sun, 28 May 2000 15:57:49 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit [Again, a personal contribution] The more I look over these messages, and think about the issues, the more convinced I become that 1. URN strings are just strings, and as far as we are concerned, no one owns them, can legislate what's done with them. 2. Insofar as a NID registrant is undertaking some responsibility to "make this work" (unique and persistent), and because the namespace probably represents some facet of work motivation of the registrant, it's quite reasonable that the registrant asserts its expectations of what services it offers/will recognize. Notes -- #1 means one can use assigned URNs in a way not pre-destined (or condoned) by the NID registrant. This may have consequences that lead to litigation -- but that's out of our scope. But #2 means that the registrant gets to define how the namespace is "meant to be used", including how the identifiers are assigned (even if it is a closed process). It may point to certain (resolution) services that it intends to associate with the URNs. That these services are "authoritative" is a contractual relationship between registrants/owners/applicants of individual URNs and the NID registrant. It sets up an expectation for users of the URN -- including those who are resolving it based on what the NID was established to do (i.e., per the registrant). It's a service issue, not a URN issue. But I don't think it's out of place for the URN NID registrant to assert/advertize what it recognizes as authoritative services for the NID. So, for example, if ORGX registers a FOO namespace, and says that they are offering resolution services for organizations electing to buy into the "foo" namespace, that's "authoritative". If a library elects to use documents' URN:foo identifiers in their library catalogue system, that's fair game, too. If the same library retrieves documents based on URN:foo and local copies of documents, that's not "authoritative" per ORGX (unless they have explicitly delegated that authority). It may be "authoritative" for some service within the library. It may be what the user expects. It's not wrong -- but I don't see how the library can legitimately claim to be a registry of URN:foo identifiers, because it hasn't gotten the nod from the organization that is managing the namespace. How can any organization create a managed namespace if anyone can claim to be "the" resolver of URNs in it, or if the namespace registrant can't claim some definition of what users of the identifiers can/should expect in the way of supported services? Keith Moore wrote: > > > not quite, but close - to me it looks like NSI is saying > > > "since we are authoritative for PINs, our assertions about things > > > named by PINs are better than others' assertions about those things". > > > I don't buy that, and I don't think IETF should support such > > > a statement. > > > > Yes. We are saying that our assertions are better than others since > > they are being made by the entity itself via our resolution service. > > and I'm saying that just because you are delegated some namespace > by IETF doesn't mean that IETF supports such an assertion. I've lost track of the levels of quoting, so I don't know who said "[...]are better tahn others' assertions", but I think that terminology is unnecessarily loaded, and definitely provokes expectations of monopolistic behaviour. I don't think the IETF mechanics should entrench monopolistic URN namespaces, but I don't think we can prevent it from happening _at_a_business_level_. I don't think we should try -- because we will badly warp what we are trying to build by trying to _guess_ what _might_ become of identifiers. > > I.e. our resolution service is acting as a proxy for me personally > > and since the URN is naming my electronix proxy, I am the one > > that is making those statements and thus they have more weight than > > yours. > > this is not appropriate. > > just because I get a URN from you does not mean that I am > authorizing you to speak for me in any manner whatsoever. I think this is off-track. NSI can offer an authoritative _service_ for whatever it wants. Someone else, per my arguments above, might offer information based on a URN:PIN identifier (although they aren't likely to be reached by the global RDS, because the registrant manages that -- appropriately, IMHO). That other service may become authoritative for credit history for particular individuals. > and personally I find the very idea that NSI (or anyone else) > would claim to speak on my behalf just because I bought a name > from them or because we had some random, unrelated business relationship, > not only offensive but highly dangerous... so dangerous > that if a company were to do this that it would be in the public > interest to destroy that company utterly, by any available means. > > in the meantime, we shouldn't let IETF lend support to them. This is getting tangential -- this is an argument that the PIN namespace shouldn't be allowed because it's going to point to personal information that you don't think NSI should be in a position to claim authority over. We don't know that, and even if we did, it's a privacy issue. We are NOT solving those in this working group, and I argue that trying to guess where they may be and stomp them out individually will cripple URN work immeasurably. If NSI elects do inappropriate things with personal information, it's not going to be any easier or harder with the URN namespace. If there are privacy issues that come up, we (the IETF) will deal with them as appropriate within our mandate. IMHO, of course. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Sun May 28 22:03:12 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13045 for ; Sun, 28 May 2000 22:03:11 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id VAA11488; Sun, 28 May 2000 21:52:01 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8600996 for URN-IETF@LISTS.INTERNIC.NET; Sun, 28 May 2000 21:51:59 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from rbuzz.com (rbuzz.techparkwa.org.au [203.103.99.144] (may be forged)) by lists.internic.net (8.9.3/8.9.3) with ESMTP id VAA06951 for ; Sun, 28 May 2000 21:27:14 -0400 (EDT) X-Envelope-To: Received: from rbuzz.com (IDENT:justin@phoenix.rbuzz.com [192.168.2.15]) by rbuzz.com (8.10.1/8.10.1) with ESMTP id e4T1NXO08006 for ; Mon, 29 May 2000 09:23:34 +0800 X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 References: <20000526131724.E9881@bailey.dscga.com> <200005261735.NAA01259@astro.cs.utk.edu> <20000526134802.J9881@bailey.dscga.com> <392ECA3A.6142D8DB@thinkingcat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3931C695.4EA8BCB1@rbuzz.com> Date: Mon, 29 May 2000 09:23:33 +0800 Reply-To: justin@RBUZZ.COM From: Justin Couch Organization: rBuzz Subject: Re: URN namespaces and control To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Leslie Daigle wrote: > Two separate issues are on the table: > > . do we have a problem with this (i.e., in terms of > reasoned arguments, how it damages URNs/Internet > infrastructure)? The assignment process and the format of the internal storage of the information should not be of concern to us. So long as there is enough information in the NSS definition of how to interpret the information and what each of the request type return (I2R, I2C etc) then there should not be a problem. That is, I should have enough information in the spec to build a new implementation should the owner fail to do so. In the same way HTTP and DNS define a protocol but not an implementation of that protocol. > . do we take a stance on "who owns the name/registry" > and act accordingly, or is that within our scope? I don't think we should. However I would like to see something along the lines of a recommended practice that says "if you are going to drop this namespace, then the information becomes part of the public domain so that others may continue to provide alternate resolution services". That is, I don't want to force the organisation to make their database tables etc PD, but that the resolution information and NSS parsing information does. -- Justin Couch Author, Java Hacker Snr Software Engineer justin@rbuzz.com rbuzz.net http://www.vlc.com.au/~justin/ Java3D FAQ http://www.j3d.org/faq/ ------------------------------------------------------------------- "Look through the lens, and the light breaks down into many lights. Turn it or move it, and a new set of arrangements appears... is it a single light or many lights, lights that one must know how to distinguish, recognise and appreciate? Is it one light with many frames or one frame for many lights?" -Subcomandante Marcos ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Mon May 29 10:56:32 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00843 for ; Mon, 29 May 2000 10:56:32 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id KAA08375; Mon, 29 May 2000 10:47:40 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8601555 for URN-IETF@LISTS.INTERNIC.NET; Mon, 29 May 2000 10:47:37 -0400 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id KAA08330 for ; Mon, 29 May 2000 10:47:29 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA13461 for urn-ietf@lists.internic.net; Mon, 29 May 2000 10:31:00 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000529103059.N11042@bailey.dscga.com> Date: Mon, 29 May 2000 10:30:59 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: sorry 'bout that.... To: URN-IETF@LISTS.INTERNIC.NET Oops.. With the discussion I accidently let some spam though. Won't happen again... -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.INTERNIC.NET Mon May 29 11:07:04 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00943 for ; Mon, 29 May 2000 11:07:04 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id KAA09753; Mon, 29 May 2000 10:54:59 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8601553 for URN-IETF@LISTS.INTERNIC.NET; Mon, 29 May 2000 10:54:56 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ns.raaseu.fi (root@ns.raaseu.fi [195.236.78.66]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id JAA20632 for ; Mon, 29 May 2000 09:14:20 -0400 (EDT) Received: from host (1Cust80.tnt1.providence.ri.da.uu.net [63.21.181.80]) by ns.raaseu.fi with ESMTP (8.8.6 (PHNE_17135)/8.7.1) id KAA14191; Mon, 29 May 2000 10:08:22 -0400 (EDT) X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.internic.net id JAA20639 Message-ID: <200005291408.KAA14191@ns.raaseu.fi> Date: Mon, 29 May 2000 07:32:47 -0500 Reply-To: Ian Franco From: Ian Franco Subject: Get Your Own #55B7 To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 8bit FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: Sign up for our E-Commerce Package and get a free merchant account + a $200 cash coupon. WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS LESS DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS. DON'T MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE! While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for your merchant account when you sign up for one of our e -commerce hosting plans. If you wish to stay with your current hosting company or have already a merchant account our offer is even better. We have 7 different E-Commerce plans to suit your individual needs. We have a solution for U.S. beased merchants and international merchants. Wherever you are on this planet, we get your online store up and running within a few days. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account, real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. In addition you get a FREE listing in our mall and FREE advertising to promote your store. We drive traffic to your site and help you to become a successful .com business. REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS SPECIAL OFFER IS ONLY GOOD FOR 7 DAYS! Please reply to: mailto:banyy@email.com?subject=INFO-PLEASE to receive our FREE e-mail information package without obligations. ********************************************************* Remove at mailto:mcim@dbzmail.com?subject=remove ********************************************************* From owner-urn-ietf@LISTS.INTERNIC.NET Mon May 29 15:22:12 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03113 for ; Mon, 29 May 2000 15:22:12 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA28995; Mon, 29 May 2000 15:08:59 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8601864 for URN-IETF@LISTS.INTERNIC.NET; Mon, 29 May 2000 15:08:57 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id OAA20257 for ; Mon, 29 May 2000 14:24:13 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA06863; Mon, 29 May 2000 14:18:18 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Message-ID: <200005291818.OAA06863@astro.cs.utk.edu> Date: Mon, 29 May 2000 14:18:18 -0400 Reply-To: moore@CS.UTK.EDU From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Sun, 28 May 2000 15:57:49 EDT." <39317A3D.7DB168B6@thinkingcat.com> > [Again, a personal contribution] > > The more I look over these messages, and think about the issues, > the more convinced I become that > > 1. URN strings are just strings, and as far as we are concerned, > no one owns them, can legislate what's done with them. in a sense that is true. however, if URNs aren't used in practice as long-term stable names, they won't have much value. > 2. Insofar as a NID registrant is undertaking some > responsibility to "make this work" (unique and persistent), > and because the namespace probably represents some facet of > work motivation of the registrant, it's quite reasonable > that the registrant asserts its expectations of what > services it offers/will recognize. I don't think this quite follows. the NID registrant has the responsibility of making sure that assignments are unique (i.e. once a URN under that NID is assigned it is never reassigned to a differnet work) and that the assignments are made in such a way as to facilitate long-term stability. and I would say that it's reasonable for the NID registrant to assert expectations of what services it offers or will recognize - simply because it's reasonable for anyone to say what services they will offer or will recognize. and if an NID registrant wants to provide a resolution service, I don't think we could stop them, nor that it would necessarily be a good idea to do so if we could. but the NID registrant doesn't have any special right to say what resolution services are authoritative for URNs under that NID. nor can they control which resolution services are available. there is an inherent conflict between having the NID be the authoritative source of information about a resource and the owner of the resource be the authoritative source of information about that resource. arguably even the owner of a resource doesn't always have the "correct" information about that resource. in reality, the notion of "authority" is dependent on context which has nothing to do with the NID. separation of assignment hierarchy and resolution hierarchy is a fundamental architectural principle of URNs, because we we want the names to be valid for many decades despite changes in the underlying technology. the kinds of underlying technology that are subject to change are not limited to resolution protocols but also include resolution services and their business models. if people get PINs from NSI and NSI's business practices change, those PINs still belong to the people to whom they were assigned. NSI is not allowed to assign those PINs to someone else - that violates the uniqueness principle. nor should NSI be able to return stale or bogus data in response to queries about those PINs and enjoy any special status as "authortative" for those PINs - if they misrepresent information about people or their resources then that is still wrong. bottom line is - if NSI is granted this NID, we have little power to stop them from abusing the NID. but this is no reason for IETF to grant its approval to such abuse. so even if IETF grants this NID to NSI (which I think would be a bad idea, but I realize it will be hard to find justification to deny that request under the current rules), the language about NSI being authoritative for PINs ought to be removed. to the extent people decide to trust NSI to resolve PINs, it needs to be because NSI earns a reputation for maintaining their service and the underlying data well, not because IETF said that NSI was authoritative. (which would be a lie in any case) > So, for example, if ORGX registers a FOO namespace, and says > that they are offering resolution services for organizations electing > to buy into the "foo" namespace, that's "authoritative". If > a library elects to use documents' URN:foo identifiers in their > library catalogue system, that's fair game, too. the problem with this scheme is that if FOO can't be trusted to respect the authortity of the owners of the resource (whether it be ORGX or someone else to whom ownership of that resource was assigned) then FOO's names become useless. meanwhile the names have already been assigned, and perhaps in use for many decades. the principle of caveat emptor doesn't work well for every case - and one such case is things that last longer than people's lives. for URNs to work the namespace registrants need to understand that they have responsibilities beyond making money for their stockholders. > for some service within the library. It may be what the user expects. > It's not wrong -- but I don't see how the library can legitimately > claim to be a registry of URN:foo identifiers, because it hasn't gotten > the nod from the organization that is managing the namespace. a registry is valid as long as it's using the URNs in a manner consistent with their definitions. the definitions are established by the assignees of the URNs, which is not in general the same thing as the namespace registrant. > How can any organization create a managed namespace if anyone can claim > to be "the" resolver of URNs in it, or if the namespace registrant > can't claim some definition of what users of the identifiers can/should > expect in the way of supported services? anyone can claim whatever they like, but there is no "the" resolver of any portion of URN-space in the sense that it is authortative over others. there might be one or more resolvers listed as NAPTR records under URN.NET, but even then, other resolvers are possible, and should be encouraged. the idea of URNs is that there should be a signle meaning of each URN, but not that there be a single resolution service for each URN. > I've lost track of the levels of quoting, so I don't know who > said "[...]are better tahn others' assertions", but I think that > terminology is unnecessarily loaded, and definitely provokes > expectations of monopolistic behaviour. I'll freely admit that the past (and as far as I can tell, current) behavior of the applicant for this namespace, have conditioned my expectations about what this applicant is likely to do with the namespace if it is granted to them. I am not blind like Justice and do not wish to pretend to be so. But folks shouldn't take my word for it. They should examine the past behavior of this applicant, form their own opinions, and decide for themselves whether this is a valid basis for denying the application. Personally, if I believed that this applicant would actually behave responsibly, I would support the application - I have worked hard on URNs over the course of many years and I do want to see people using them. > I don't think the IETF mechanics should entrench monopolistic > URN namespaces, but I don't think we can prevent it from happening > _at_a_business_level_. I don't think we should try -- because > we will badly warp what we are trying to build by trying to _guess_ > what _might_ become of identifiers. no, clearly IETF cannot prevent such, but neither should we endorse it. > > > I.e. our resolution service is acting as a proxy for me personally > > > and since the URN is naming my electronix proxy, I am the one > > > that is making those statements and thus they have more weight than > > > yours. > > > > this is not appropriate. > > > > just because I get a URN from you does not mean that I am > > authorizing you to speak for me in any manner whatsoever. > > I think this is off-track. NSI can offer an authoritative _service_ > for whatever it wants. and who says it's authoritative? my point is that IETF should not be making such statements. > Someone else, per my arguments above, might > offer information based on a URN:PIN identifier (although they > aren't likely to be reached by the global RDS, because the registrant > manages that -- appropriately, IMHO). I regard the notion that only some resolution services can be listed in the global RDS is a weakness, but a necessary one for deployment of URNs. in the short term at least, we are better off having a global RDS (with this limitation) than not having one. fortunately, other RDSs are possible, and in the long term, likely. > That other service may > become authoritative for credit history for particular individuals. > > > and personally I find the very idea that NSI (or anyone else) > > would claim to speak on my behalf just because I bought a name > > from them or because we had some random, unrelated business relationship, > > not only offensive but highly dangerous... so dangerous > > that if a company were to do this that it would be in the public > > interest to destroy that company utterly, by any available means. > > > > in the meantime, we shouldn't let IETF lend support to them. > > This is getting tangential -- this is an argument that the PIN > namespace shouldn't be allowed because it's going to point to > personal information that you don't think NSI should be in a position > to claim authority over. no, actually it's an argument that NSI shouldn't be labelled as authortative for a namespace simply because they are the NID registrant. (same is true for any other NID registrant). whether the application should be allowed at all is a separate issue. (and the argument against allowing registration is weaker) and it's not an argument about whether the PIN points to personal information or about what NSI claims, but whether IETF is supporting such claims by approving an NID application, and publishing an RFC, that makes those claims. > We don't know that, and even if we did, > it's a privacy issue. and I wasn't intending to make a privacy argument, though there probably are privacy arguments to be made if this is really intended to be a namespace of people. but rather, it was an argument about whether IETF should support the claim of an NID registrant that it is an authortative source of information for data about resources that it doesn't own. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Wed May 31 08:43:27 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06856 for ; Wed, 31 May 2000 08:43:26 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id IAA07652; Wed, 31 May 2000 08:29:16 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8593186 for URN-IETF@LISTS.INTERNIC.NET; Wed, 31 May 2000 08:29:12 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id XAA13839 for ; Tue, 30 May 2000 23:22:21 -0400 (EDT) Received: from thinkingcat.com ([207.253.220.227]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FVE00GC0MCG3O@field.videotron.net> for urn-ietf@lists.internic.net; Tue, 30 May 2000 23:14:41 -0400 (EDT) MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Message-ID: <39348330.36C27A6F@thinkingcat.com> Date: Tue, 30 May 2000 23:12:48 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: A word from the chair... To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Hi all, Putting my dusty WG chair hat back on... I think we've had some useful discussion airing perceptions of use of URNs/resolution. There may well be more issues to pursue here, so general discussion of the issues may continue. However, I'm not hearing a lot of people pushing back on/offering specific comments to the URN:PIN proposal. If there aren't yells from new quarters, I will declare the issue closed, and when the revised URN:PIN Internet-Draft comes out, comments should be limited to the changes in the text (i.e., new issues). So, if you have a strong opinion either way, not yet aired, please do so or forever hold... whatever you'd like to hold for a long time ;-) Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Wed May 31 08:44:41 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06894 for ; Wed, 31 May 2000 08:44:40 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id IAA09754; Wed, 31 May 2000 08:35:09 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8593210 for URN-IETF@LISTS.INTERNIC.NET; Wed, 31 May 2000 08:35:07 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id XAA11507 for ; Tue, 30 May 2000 23:10:14 -0400 (EDT) Received: from thinkingcat.com ([207.253.220.227]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FVE00GCNLJD3O@field.videotron.net> for URN-IETF@LISTS.INTERNIC.NET; Tue, 30 May 2000 22:57:15 -0400 (EDT) MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200005291818.OAA06863@astro.cs.utk.edu> Message-ID: <39347F19.3BD1DF9@thinkingcat.com> Date: Tue, 30 May 2000 22:55:21 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, I think one of the differences of opinion is whether URNs are strings that, once assigned, the assignee (whatever sort of entity) is free to determine the destiny of, or whether they are tokens assigned to participate in some service-oriented undertaken. One gets an e-mail address to direct e-mail, not to be identified personally; one gets a social insurance number (social security number in the states, whatever else elsewhere) to appear in government (tax) records, one gets an ISSN for a serial publication to identify it in the ISSN registry of information about serial publications... This ISP/enterprise is the authoritative service for routing my e-mail, the government is the authoritative source for declaring my income, the ISSN Agency is the authoritative source for finding out what information a given publisher wishes to elaborate re. its serial publication. This doesn't mean these identifiers can't be used in other contexts (except where prohibited -- e.g., social insurance numbers in Canada cannot be required, by law, for anything other than the declaration of income). It doesn't mean that other services can't be authoritative in their own way -- e.g., serials agencies index their offerings based on ISSNs, and it's the serials agency that is authoritative about the current price they are advertizing for a given publication. It doesn't mean that a given resource won't have more than one identifier -- we've known that for a long time. The assignee of the identifier wouldn't expect it any other way. So, I don't think it's wrong for a NID registrant to say: . we're offering the identifiers which will be carried by this URN NID. The method by which we associate an identifier to a resource is part of a service that is external to the URN. . as part of the reason people will pursue that external registration process, we're offering particular advertized services for global resolution, following the Global RDS. That being said, there are _classes_ of namespaces where it is the case that the purpose is _not_ to be that closed, but rather to provide the basis for just the kind of open relationship between object, identifier and service that you describe. These, too, will be valuable and important. Unfortunately, I don't see a rush of them being proposed -- I have thoughts, but no evidence, as to why this might be the case, so I'll leave it at: I hope someone does put one up soon. The point is: there are many different purposes for namespaces, and the criteria for evaluating persistence and longevity are not whether it's an open or closed system. I think PIN is valid. I don't think it's the model for all URN namespaces - the concept of URN is quite broad. Keith Moore wrote: > there is an inherent > conflict between having the NID be the authoritative source of > information about a resource and the owner of the resource be > the authoritative source of information about that resource. > arguably even the owner of a resource doesn't always have > the "correct" information about that resource. in reality, the > notion of "authority" is dependent on context which has nothing > to do with the NID. I don't think I'm saying anything that disagrees with that, except... I'm saying the _services_ offered can claim to be "authoritative" (for those services -- not for the IDs). > if people get PINs from NSI > and NSI's business practices change, those PINs still belong > to the people to whom they were assigned. Disagree -- the person doesn't "own" the PIN any more than I "own" the number on my credit card. But, yes, the PIN (credit card number) should not be reassigned. We agreed, long ago, that this is a declared principle, but that we cannot enforce it. > and enjoy any special status as "authortative" for those PINs - > if they misrepresent information about people or their resources > then that is still wrong. If they misrepresent information about people -- they are wrong, but not because they are using URNs to do it. > this NID to NSI (which I think would be a bad idea, but I realize > it will be hard to find justification to deny that request under > the current rules), the language about NSI being authoritative > for PINs ought to be removed. to the extent people decide to > trust NSI to resolve PINs, it needs to be because NSI earns > a reputation for maintaining their service and the underlying > data well, not because IETF said that NSI was authoritative. > (which would be a lie in any case) Well, I re-read the draft, hopefully somewhat the wiser after this past week's discussion. I note that the word "authoritative" appears far less frequently than phrases supporting the desirable characteristics of URNs including the words "persistent", and "unique". In fact, the word "authoritative" appears only once, under the (IESG-required) Security Considerations section: " It is noted however that attempting to resolve a PIN URN through a resolver other than the one provided by Network Solution is prone to error and is not considered authoritative." I think it would be appropriate to modify this section to read something like: "Network Solutions' intent is to be the source of reliable resolution services for PIN URNs. It can make no assertions or guarantees as to the outcome of using other resolution services for them." Which is nothing more than being clear. I think it's very fair. > a registry is valid as long as it's using the URNs in a manner > consistent with their definitions. the definitions are established > by the assignees of the URNs, which is not in general the same > thing as the namespace registrant. I disagree that it is always the assignees of the URNs that are in control of their destiny -- see earlier comments. > there might be one or more resolvers listed as NAPTR records under > URN.NET, but even then, other resolvers are possible, and should be > encouraged. the idea of URNs is that there should be a signle meaning > of each URN, but not that there be a single resolution service for each URN. I agree that multiple resolution services are possible. But I don't believe that the public is well-served by having a free-for-all of services claiming to offer "resolution" for a given namespace. Maybe for some. But not for all. To take this discussion any further -- we would need a more detailed definition of what we mean by "resolution" -- I2R? I2L? which L? I personally suspect that other services, about the URN, will be quite useful, but that's another topic altogether. > > I think this is off-track. NSI can offer an authoritative _service_ > > for whatever it wants. > > and who says it's authoritative? my point is that IETF should not > be making such statements. The IETF isn't. It's allowing that NSI says it is, nothing more. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Wed May 31 15:57:30 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22687 for ; Wed, 31 May 2000 15:57:29 -0400 (EDT) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA11866; Wed, 31 May 2000 15:45:24 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8593607 for URN-IETF@LISTS.INTERNIC.NET; Wed, 31 May 2000 15:45:20 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA08427 for ; Wed, 31 May 2000 15:31:45 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA14616; Wed, 31 May 2000 15:25:49 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ Message-ID: <200005311925.PAA14616@astro.cs.utk.edu> Date: Wed, 31 May 2000 15:25:48 -0400 Reply-To: moore@CS.UTK.EDU From: Keith Moore Subject: Re: re PIN URN request document To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Tue, 30 May 2000 22:55:21 EDT." <39347F19.3BD1DF9@thinkingcat.com> > Howdy, > > I think one of the differences of opinion is whether URNs > are strings that, once assigned, the assignee (whatever sort of > entity) is free to determine the destiny of, or whether they are > tokens assigned to participate in some service-oriented undertaken. We've always had the notion that a resource named by a URN might change/evolve over time, but that the URN should never be reassigned to a completely different resource. To me it seems clear that the assignee of the URN, rather than the namespace registrant, specifies the "current" instantiation of the resource. (and for that matter "past" instantiations that are still valid) So for I2L and I2R resolutions the URN assignee should be the authoritative source of information. (the assumption is that "assignee" == "maintainer" originally, and that the original assignee can delegate maintenance of both the resource, and the binding between the URN and the resource, to another party. this is not perfect but is much better than insisting that the maintainer of the URN->resource binding be different than the maintainer of the resource itself.) This begs the question of I2C resolutions, since there can easily be multiple authoritative sources of I2C data. But since some of the metadata about a resource will need to be consistent with the characteristics of the current instantiation, if there's going to be be any single authoritative source of that metadata, it must be the same as the authoritative source of I2L/I2R data. So again, this is the assignee. > One gets an e-mail address to direct e-mail, not to be identified > personally; one gets a social insurance number (social security > number in the states, whatever else elsewhere) to appear in > government (tax) records, one gets an ISSN for a serial publication > to identify it in the ISSN registry of information about serial > publications... > > This ISP/enterprise is the authoritative service for routing > my e-mail, the government is the authoritative source for > declaring my income, the ISSN Agency is the authoritative source > for finding out what information a given publisher wishes > to elaborate re. its serial publication. it's not clear that the first is a valid analogy. email addresses are a form of URL, and URNs were specifically intended to work differently than URLs, to solve a different set of problems than URLs. in particular, email addresses were never designed to serve as long-term stable identifiers, and the mechanisms needed to make them long-term stable are not present. if you wanted to make email addresses long-term stable in the current system you would have to give everyone his own domain name, and then that the owner of the domain name could change ISPs at any time. but currently the domain name is (typically) associated with the ISP, and that creates a problem for long-term stability. with URNs we dispensed with domain names entirely for pretty much this reason. the NID was not supposed to be a replacement for the domain name in a URL, it was supposed to be a mechanism for distributing assignment of URNs among several parties and for grandfathering existing (suitable) namespaces into URN-space. at least in the US, SSNs act a fair amount like URNs. the authoritative source of most kinds of information associated with an SSN is in fact the person to whom the SSN was assigned. perhaps unfortunately, SSNs are used in a large number of contexts other than reporting taxes, and except for its own purposes, the government doesn't act as any kind of clearinghouse for SSN lookups. a number of commercial agencies use SSNs because they're convenient, but they don't go through the government to look them up. as I understand ISSNs the global space is delegated to various national agencies who then assign them to various publications, but again, there is no single ISSN agency that tries to be authortative for all lookups of ISSN information. they maintain the "master lists" of which ISSNs are assigned to which serials but don't try to claim that they have the official bibliography information for those serials. > This doesn't mean these identifiers can't be used in other contexts > (except where prohibited -- e.g., social insurance numbers in > Canada cannot be required, by law, for anything other than the > declaration of income). nice that *somebody* thinks about privacy implications... > So, I don't think it's wrong for a NID registrant to say: > > . we're offering the identifiers which will be carried > by this URN NID. The method by which we associate > an identifier to a resource is part of a service that > is external to the URN. > > . as part of the reason people will pursue that external > registration process, we're offering particular advertized > services for global resolution, following the Global RDS. I think this is more-or-less reasonable, but somewhat less than what NSI's application is claiming. > That being said, there are _classes_ of namespaces where it > is the case that the purpose is _not_ to be that closed, but rather > to provide the basis for just the kind of open relationship between > object, identifier and service that you describe. These, too, > will be valuable and important. Unfortunately, I don't see a rush > of them being proposed -- I have thoughts, but no evidence, as to > why this might be the case, so I'll leave it at: I hope someone > does put one up soon. > > The point is: there are many different purposes for namespaces, > and the criteria for evaluating persistence and longevity are > not whether it's an open or closed system. I think PIN is valid. > I don't think it's the model for all URN namespaces - the concept > of URN is quite broad. well, to me it seems like if you want names to be usable in the long term, you cannot constrain the assignee to maintain a relationship with the namespace registrant. times change, and needs change, and the needs or the assignee and the needs of the namespace registrant are bound to differ over time. or to put it another way: if NSI is going to claim that they are now and forever the authoritative source of information for PINs, why should they bother with URNs? why not just set up a separate DNS name for PIN-space (as OCLC did with PURLs) and use URL or email address syntax to define names in that space? > Keith Moore wrote: > > there is an inherent > > conflict between having the NID be the authoritative source of > > information about a resource and the owner of the resource be > > the authoritative source of information about that resource. > > arguably even the owner of a resource doesn't always have > > the "correct" information about that resource. in reality, the > > notion of "authority" is dependent on context which has nothing > > to do with the NID. > > I don't think I'm saying anything that disagrees with that, except... > I'm saying the _services_ offered can claim to be "authoritative" > (for those services -- not for the IDs). granted that a service is (probably) authoritative for itself, but it seems meaningless and confusing to state that. > > if people get PINs from NSI > > and NSI's business practices change, those PINs still belong > > to the people to whom they were assigned. > > Disagree -- the person doesn't "own" the PIN any more than I "own" > the number on my credit card. it seems that we do disagree on this. and credit cards aren't intended to be long-term identifiers either - though there are good reasons for not reassigning them, they are (by design of the namespace) bound to a credit card company and a billing institution. if we had credit cards that we could keep for life, changing billing institutions from time to time as needed, then those would be like URNs. or to use another analogy - phone numbers were originally tied to a particular communications company. but now (in some areas) I can get a phone number that can travel with me from one communications company to another, and which works from anywhere in the world (though it might cost more to use it in some places than others). so it's becoming feasible for me to use the same phone number for my entire life, should I want to do that. so the phone number is starting to act more like a URN. > > and enjoy any special status as "authortative" for those PINs - > > if they misrepresent information about people or their resources > > then that is still wrong. > > If they misrepresent information about people -- they are wrong, but > not because they are using URNs to do it. there are two subtly different issues here: a) whether IETF supports the PIN namespace registrant's claims to be the authoritative source of information about people (or whatever it is that PINs refer to; I'm not specifically arguing about identifiers that refer to people) b) whether the information supplied by the PIN namespace registrant is accurate we cannot address the second problem; we can address the first problem. > > this NID to NSI (which I think would be a bad idea, but I realize > > it will be hard to find justification to deny that request under > > the current rules), the language about NSI being authoritative > > for PINs ought to be removed. to the extent people decide to > > trust NSI to resolve PINs, it needs to be because NSI earns > > a reputation for maintaining their service and the underlying > > data well, not because IETF said that NSI was authoritative. > > (which would be a lie in any case) > > Well, I re-read the draft, hopefully somewhat the wiser after this > past week's discussion. I note that the word "authoritative" appears > far less frequently than phrases supporting the desirable > characteristics of URNs including the words "persistent", and "unique". > In fact, the word "authoritative" appears only once, under the > (IESG-required) Security Considerations section: > > " It is noted however that attempting to resolve a PIN URN through a > resolver other than the one provided by Network Solution is prone to > error and is not considered authoritative." > > I think it would be appropriate to modify this section to read > something like: > > "Network Solutions' intent is to be the source of reliable resolution > services for PIN URNs. It can make no assertions or guarantees as to > the outcome of using other resolution services for them." > > Which is nothing more than being clear. I think it's very fair. I think even this is a stretch. perhaps "a source" rather than "the source" would be better. "the source of reliable resolution information" implies that there is only one such source. I thought I saw one or two additional over-reaching claims by the applicant; I'll need to reread the draft again to be sure. > > a registry is valid as long as it's using the URNs in a manner > > consistent with their definitions. the definitions are established > > by the assignees of the URNs, which is not in general the same > > thing as the namespace registrant. > > I disagree that it is always the assignees of the URNs that are > in control of their destiny -- see earlier comments. responded to these above. > > there might be one or more resolvers listed as NAPTR records under > > URN.NET, but even then, other resolvers are possible, and should be > > encouraged. the idea of URNs is that there should be a signle meaning > > of each URN, but not that there be a single resolution service for each URN. > > I agree that multiple resolution services are possible. But I don't > believe that the public is well-served by having a free-for-all > of services claiming to offer "resolution" for a given namespace. nor do I. but neither do I believe that the public is well-served by having only one resolution service for a given namespace. > > > I think this is off-track. NSI can offer an authoritative _service_ > > > for whatever it wants. > > > > and who says it's authoritative? my point is that IETF should not > > be making such statements. > > The IETF isn't. It's allowing that NSI says it is, nothing more. it's a fine line. people take RFCs as if they were statements from IETF even if IETF puts a disclaimer in them. and IETF does exercise editorial control over (most) RFCs so it's reasonable for people to believe that IETF consents to the language within RFCs. Keith