From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 14 13:16: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 NAA06111 for ; Fri, 14 Jul 2000 13:16: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 MAA03106; Fri, 14 Jul 2000 12:59:34 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8605439 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 12:59:29 -0400 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 MAA03068 for ; Fri, 14 Jul 2000 12:59:27 -0400 (EDT) Received: from thinkingcat.com ([207.253.208.208]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXP00HHN5JDNR@field.videotron.net> for urn-ietf@lists.internic.net; Fri, 14 Jul 2000 12:52:27 -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 Approved-By: Leslie Daigle Message-ID: <396F444C.2981AB70@thinkingcat.com> Date: Fri, 14 Jul 2000 12:48:12 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Working Group -- work! To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, So, here we are looking to wrap up our last documents and finish the working group. To refresh people's memory of where we're at, just over a year ago, we submitted Assignment Procedures for the URI Resolution using DNS (RFC2168) Resolution of Uniform Resource Identifiers using the Domain Name System The Naming Authority Pointer (NAPTR) DNS Resource Record to the IESG to be put forward as RFCs (as BCP, Standard, and Standard, respectively). Such being the nature of IESG overload, it took quite a few months before they got the necessary scrutiny, which produced some useful suggested improvements. Such being the nature of the universe at large, in the meantime other groups started using bits of it (e.g., NAPTR) in very appropriate, but non-UR{N|I} ways (e.g., ENUM). This lead to a thought that the latter 2 documents, which are meant to update and replace RFC2168, could be better expressed as 3 documents, separating out the generically-useful stuff from the UR{N|I}-specific stuff so that it will be clearer how other apps can use NAPTR in a consistent fashion. (The first will be republished as a revised document, should hit the I-D editor today). Ultimately, it should also make it clearer how URN resolution can move beyond DNS-based resolution, which is something we've maintained was interesting/useful/necessary in the medium-to-long term. Michael Mealling has put together some proposed documents, based on that split. They will soon hit the I-D archives (titles below), and the split is encapsulated as follows: draft-ietf-urn-ddds-00.txt = the generic concept of a delegated hierarchy for resolution draft-ietf-urn-dns-ddds-database-00.txt = NAPTR -- i.e., how to use DNS to implement an instance of the above draft-ietf-urn-uri-res-ddds-00.txt = using the NAPTR-based "DDDS" for URN and URI resolution Michael will be forwarding the documents to the list with his own remarks, but there is a larger question that I need answered as WG chair. Essentially, our goal as a WG is to fulfill our charter and wind up. The argument can be made that this goes beyond our mandate. The counterargument can be made that it will allow us to finish our work in a more complete fashion. I'd like to hear people's thoughts once they've read the documents in that light. Consequences: . if we take it on, I'll be pushing for a tight timeline, so that this WG does wind up . if we don't take it on, we can consider pushing forward with simple revisions to the existing drafts My personal opinion is that this is work in the right direction, that it should move forward anyway, that it's close enough to what we've done that it shouldn't be too much of a stretch, and that it will benefit from the input of the whole WG (i.e., why I'd rather this didn't get put to Michael to pursue as a personal effort). But, YMMV, and I'd like to hear either way. Over to you, Michael... Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 14 13:25: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 NAA08940 for ; Fri, 14 Jul 2000 13:25:47 -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 NAA08051; Fri, 14 Jul 2000 13:20:54 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8605512 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 13:20: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 NAA08021 for ; Fri, 14 Jul 2000 13:20:48 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA06943; Fri, 14 Jul 2000 13:04:15 -0400 (EDT) References: <396F444C.2981AB70@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000714130415.U6129@bailey.dscga.com> Date: Fri, 14 Jul 2000 13:04:15 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: Working Group -- work! To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <396F444C.2981AB70@thinkingcat.com>; from leslie@thinkingcat.com on Fri, Jul 14, 2000 at 12:48:12PM -0400 On Fri, Jul 14, 2000 at 12:48:12PM -0400, Leslie Daigle wrote: > Over to you, Michael... Thanks! (I get the feeling I'm announcing a football game...) Anyway, one very important point is that nothing technical changes with these documents (other than using the urn.arpa and uri.arpa domains). The only differences have to do with the requirements for what information you need in order to come up with your own rule database or application. One subtle point is that these documents make it clear that if you use the NAPTR record then you must adhere to the delegation systems rules. There have been attempts at using NAPTR for things with no relation at all delegation rules. This change makes it clear that you can't use NAPTR as a RR just to carry around three strings and a domain-name. I'll be forwarding these documents to the list separately. As Leslie has said, I expect that since there are no technical changes that at most we might have some word smithing to do around some sections. Thus we should be able to have these done in a very short timeframe (weeks?). -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 Jul 14 13:46: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 NAA17266 for ; Fri, 14 Jul 2000 13:46: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 NAA08669; Fri, 14 Jul 2000 13:23:19 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8605562 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 13:23:15 -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 NAA08605 for ; Fri, 14 Jul 2000 13:23:07 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA06982 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 13:06:40 -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: <20000714130639.X6129@bailey.dscga.com> Date: Fri, 14 Jul 2000 13:06:40 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: draft-ietf-urn-dns-ddds-database-00.txt To: URN-IETF@LISTS.INTERNIC.NET Network Working Group M.M. Mealling Internet-Draft Network Solutions, Inc. Expires: January 12, 2001 July 14, 2000 A DDDS Database Using The Domain Name System draft-ietf-urn-dns-ddds-database-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a Dynamic Delegation Discovery System Database using the Domain Name System as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the NAPTR Resource Record. Since this document officially obsoletes RFC 2168, it is the official specification for the NAPTR DNS Resource Record. Mealling Expires January 12, 2001 [Page 1] Internet-Draft DDDS DNS Database July 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DDDS Database Specification . . . . . . . . . . . . . . . . . 5 4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Master File Format . . . . . . . . . . . . . . . . . . . . . . 7 5. Application Specifications . . . . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Advice for DNS Administrators . . . . . . . . . . . . . . . . 13 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 Mealling Expires January 12, 2001 [Page 2] Internet-Draft DDDS DNS Database July 2000 1. Introduction The NAPTR DNS Resource Record was originally produced by the URN Working Group as a way to encode rule-sets in DNS so that the delegated sections of a URI could be decomposed in such a way that they could be changed and re-delegated over time. The result was a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name. Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to be encoded in a rather small DNS packet. Over time this process was generalized for other Applications and Rule Databases. This document defines a Rules Database absent any particular Application as there may be several Applications all taking advantage of this particular Rules Database. As a result of this generalization, this document, along with [11] and [12], obsoletes RFC 2168[13] and updates RFC 2276[10]. Mealling Expires January 12, 2001 [Page 3] Internet-Draft DDDS DNS Database July 2000 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. All other terminology, especially capitalized terms, is taken from [11]. Mealling Expires January 12, 2001 [Page 4] Internet-Draft DDDS DNS Database July 2000 3. DDDS Database Specification General Description: This database uses the Domain Name System (DNS) as specified in [3] and [2]. Key Format: A Key is a DNS valid domain-name. Lookup Request: In order to request a set of rules for a given Key, the client issues a request, following standard DNS rules, for NAPTR Resource Records for the given domain-name. Lookup Response: The response to a request for a given Key (domain-name) will be a series of NAPTR records. The format of a NAPTR Resource Record can be found in Section 4. Rule Insertion Procedure: Rules are inserted by adding new records to the appropriate zone. If a Rule produces a Key that exists in a particular zone then only the entity that has administrative control of that zone can specify the Rule associated with that Key. Mealling Expires January 12, 2001 [Page 5] Internet-Draft DDDS DNS Database July 2000 4. NAPTR RR Format 4.1 Packet Format The packet format of the NAPTR RR is given below. The DNS type code for NAPTR is 35. The packet format for the NAPTR record is as follows 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ORDER | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / FLAGS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / SERVICES / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REGEXP / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REPLACEMENT / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ and as used here are defined in RFC1035[1]. ORDER A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately represent the ordered list of Rules. The ordering is from lowest to highest. If two records have the same order value then they are considered to be the same rule and should be selected randomly unless the Preference numbers are different which means the randomization is weighted according to the ratio of the Preference values. PREFERENCE A 16-bit unsigned integer that specifies the order in which NAPTR records with equal Order values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. A client MAY look at records with higher preference values if it has a good reason to do so such as not understanding some protocol or service. Mealling Expires January 12, 2001 [Page 6] Internet-Draft DDDS DNS Database July 2000 The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. I.e. Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint. FLAGS A containing flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant. It is up to the Application specifying how it is using this Database to define the Flags in this field. It must define which ones are terminal and which ones are not. SERVICES A that specifies the Service Parameters applicable to this this delegation path. It is up to the Application Specification to specify the values found in this field. REGEXP A containing a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. See the DDDS Algorithm specification for the syntax of this field. As stated in the DDDS algorithm, The regular expressions MUST NOT be used in a cumulative fashion, that is, they should only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite. The latter is tempting in some applications but experience has shown such use to be extremely fault sensitive, very error prone, and extremely difficult to debug. REPLACEMENT A which specifies the The next domain-name to query for depending on the potential values found in the flags field. This field is used when the regular expression is a simple replacement operation. Any value in this field MUST be a fully qualified domain-name. Unless and until permitted by future standards action, name compression is not to be used for this field. 4.2 Master File Format The master file format follows the standard rules in RFC-1035[1]. Order and preference, being 16-bit unsigned integers, shall be an integer between 0 and 65535. The Flags and Services and Regexp Mealling Expires January 12, 2001 [Page 7] Internet-Draft DDDS DNS Database July 2000 fields are all quoted s. Since the Regexp field can contain numerous backslashes and thus should be treated with care. See Section 10 for how to correctly enter and escape the regular expression. Mealling Expires January 12, 2001 [Page 8] Internet-Draft DDDS DNS Database July 2000 5. Application Specifications This DDDS Database is usable by any application that makes use of the DDDS algorithm. In addition to the items required to specify a DDDS Application, an application wishing to use this Database must also define the following values: o What DNS zone the Key that is produced by the First Well Known Rule belongs to. Any application must ensure that its rules do not collide with rules used by another application making use of this Database. For example, the 'foo' application might have all of its First Well Known Keys be found in the 'foo.net' zone. o What the allowed values for the Services and Protocols fields are. o What the expected output is of the terminal rewrite rule Mealling Expires January 12, 2001 [Page 9] Internet-Draft DDDS DNS Database July 2000 6. Examples 6.1 URN Example The NAPTR record was originally specified for use with the a Uniform Resource Name Resolver Discovery System. This example details how a particular URN would use the NAPTR record to find a resolver service that can answer questions about the URN. See [12] for the definitive specification for this Application. Consider a URN namespace based on MIME Content-Ids (this is very hypothetical so do not rely on this) . The URN might look like this: This Application's First Well Known Rule is to extract the characters between the first and second colon. For this URN that would be 'cid'. The Application also specifies that, in order to build a Database-valid Key, the string 'urn.arpa' should be appended to the result of the First Well Known Rule. The result is 'cid.urn.arpa'. Next, the client queries the DNS for NAPTR records for the domain-name 'cid.urn.arpa'. The result is a single record: cid.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . Since there is only one record, ordering the responses is not a problem. The replacement field is empty, so the pattern provided in the regexp field is used . We apply that regexp to the entire URN to see if it matches, which it does. The \2 part of the substitution expression returns the string "foo.com". Since the flags field is empty, the lookup is not terminal and our next probe to DNS is for more NAPTR records where the new domain is 'foo.com'. Note that the rule does not extract the full domain name from the CID, instead it assumes the CID comes from a host and extracts its domain. While all hosts, such as 'bar', could have their very own NAPTR, maintaining those records for all the machines at a site could be an intolerable burden. Wildcards are not appropriate here since they only return results when there is no exactly matching names already in the system. The record returned from the query on "foo.com" might look like: Mealling Expires January 12, 2001 [Page 10] Internet-Draft DDDS DNS Database July 2000 gatech.edu. ;; order pref flags service regexp replacement IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.foo.com. IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.foo.com. IN NAPTR 100 50 "a" "http+N2L+N2C+N2R" "" www.foo.com. Continuing with the example, note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The Application defines the flag 'a' to mean a terminal lookup and that the output of the rewrite will be a domain-name for which an A record should be queried. Once the client has done that, it has the following information: the host, its IP address, the protocol, and the services available via that protocol. Given these bits of information the client has enough to be able to contact that server and ask it questions about the URN. Recall that the regular expression used \2 to extract a domain name from the CID, and \. for matching the literal '.' characters separating the domain name components. Since '\' is the escape character, literal occurances of a backslash must be escaped by another backslash. For the case of the cid.urn.arpa record above, the regular expression entered into the master file should be "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually receives the record, the pattern will have been converted to "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i". 6.2 E164 Example The ENUM Working Group in the IETF has specified a service that allows a telephone number to be mapped to a URI. The Application Unique String for the ENUM Application is the E.164 telephone number with the dashes removed. The First Well Known Rule is to remove all characters from the the telephone number and then use the entire number as the first Key. For example, the phone number "770-555-1212" represented as an E.164 number would be "+1-770-555-1212". Converted to the Key it would be "17705551212". The ENUM Application at present only uses this Database. It specifies that, in order to convert the first Key into a form valid for this Database, periods are inserted between each digit, the entire Key is inverted and then append "e164.arpa" to the end. The above telephone number would then read "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to retrieve Rewrite Rules as NAPTR records. For this example telephone number we might get back the following NAPTR records: $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. Mealling Expires January 12, 2001 [Page 11] Internet-Draft DDDS DNS Database July 2000 IN NAPTR 100 10 "u" "sip+N2R" "!^.*$!sip:information@tele2.se!" . IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@tele2.se!" . ENUM uses the same 'u' flag as the URI Resolution Application. This flag states that the Rule is terminal and that the output is a URL which contains the information needed to contact that telephone service. ENUM also uses the same format for its Service Parameters. These state that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail. Mealling Expires January 12, 2001 [Page 12] Internet-Draft DDDS DNS Database July 2000 7. Advice for DNS Administrators Beware of regular expressions. Not only are they difficult to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. In order to mitigate zone file problems, administrators should encourage those writing rewrite rules to utilize the 'default delimiter' feature of the regular expression. In the DDDS specification the regular expression starts with the character that is to be the delimiter. Hence if the first character of the regular expression is an exclamation mark ('!') for example then the regular expression can usually be written without any backslashes. Mealling Expires January 12, 2001 [Page 13] Internet-Draft DDDS DNS Database July 2000 8. Notes A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known Service Parameter combination. When multiple RRs have the same "order" and all other criteria being equal, the client should use the value of the preference field to select the next NAPTR to consider. However, because it will often be the case where preferred protocols or services exist, clients may use this additional criteria to sort the records. If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. Mealling Expires January 12, 2001 [Page 14] Internet-Draft DDDS DNS Database July 2000 9. IANA Considerations The values for the Services and Flags fields will be determined by the Application that makes use of this DDDS Database. Those values may require a registration mechanism and thus may need some IANA resources. This specification by itself does not. Mealling Expires January 12, 2001 [Page 15] Internet-Draft DDDS DNS Database July 2000 10. Security Considerations The NAPTR record, like any other DNS record, can be signed and validated according to the procedures specified in DNSSEC. This Database makes identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. Mealling Expires January 12, 2001 [Page 16] Internet-Draft DDDS DNS Database July 2000 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Mockapetris, P.V., "Domain names - implementation and specification", RFC 1035, STD 13, Nov 1987. [3] Mockapetris, P.V., "Domain names - concepts and facilities", RFC 1034, STD 13, Nov 1987. [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [6] Danie1, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997. [7] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. [8] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [9] Moats, R., "URN Syntax", RFC 2141, May 1997. [10] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. [11] Mealling, M.M., "Dynamic Delegation Discovery System (DDDS)", Internet-Draft draft-ietf-urn-ddds-00.txt, May 2000. [12] Mealling, M.M., "URI Resolution using the Dynamic Delegation Discovery System", Internet-Draft draft-ietf-urn-uri-res-ddds-00.txt, July 2000. [13] Danie1, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997. Mealling Expires January 12, 2001 [Page 17] Internet-Draft DDDS DNS Database July 2000 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 January 12, 2001 [Page 18] Internet-Draft DDDS DNS Database July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Mealling Expires January 12, 2001 [Page 19] From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 14 14:02: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 OAA22312 for ; Fri, 14 Jul 2000 14:02: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 NAA08462; Fri, 14 Jul 2000 13:22:39 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8605537 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 13:22:34 -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 NAA08380 for ; Fri, 14 Jul 2000 13:22:17 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA06971 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 13:06:01 -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: <20000714130601.W6129@bailey.dscga.com> Date: Fri, 14 Jul 2000 13:06:01 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: draft-ietf-urn-uri-res-ddds-00.txt To: URN-IETF@LISTS.INTERNIC.NET Network Working Group M.M. Mealling Internet-Draft Network Solutions, Inc. Expires: January 12, 2001 July 14, 2000 URI Resolution using the Dynamic Delegation Discovery System draft-ietf-urn-uri-res-ddds-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract A specification for taking a URI and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document, along with [10] and [9], obsoletes RFC 2168[12] and updates RFC 2276[8]. Mealling Expires January 12, 2001 [Page 1] Internet-Draft DDDS Based URI Resolution July 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Distinction between URNs and URLs . . . . . . . . . . . 5 4. The URI and URN Resolution Application Specifications . . . 6 4.1 Application Unique String . . . . . . . . . . . . . . . . . 6 4.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 6 4.3 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4 Services Parameters . . . . . . . . . . . . . . . . . . . . 7 4.4.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4.2 protocols . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 An example using a URN . . . . . . . . . . . . . . . . . . . 9 5.2 CID URI Scheme Example . . . . . . . . . . . . . . . . . . . 10 5.3 Resolving an HTTP URI Scheme . . . . . . . . . . . . . . . . 12 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 A. Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 Mealling Expires January 12, 2001 [Page 2] Internet-Draft DDDS Based URI Resolution July 2000 1. Introduction Uniform Resource Locators have been a significant advance in retrieving Internet-accessible resources. However, their brittle nature over time has been recognized for several years. The Uniform Resource Identifier working group proposed the development of Uniform Resource Names[3] to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC 1737[1] sets forth requirements on URNs. During the lifetime of the URI-WG, a number of URN proposals were generated. The developers of several of those proposals met in a series of meetings, resulting in a compromise known as the Knoxville framework. The major principle behind the Knoxville framework is that the resolution system must be separate from the way names are assigned. This is in marked contrast to most URLs, which identify the host to contact and the protocol to use. Readers are referred to [2]for background on the Knoxville framework and for additional information on the context and purpose of this proposal. Separating the way names are resolved from the way they are constructed provides several benefits. It allows multiple naming approaches and resolution approaches to compete, as it allows different protocols and resolvers to be used. There is just one problem with such a separation - how do we resolve a name when it can't give us directions to its resolver? For the short term, DNS is the obvious candidate for the resolution framework, since it is widely deployed and understood. However, it is not appropriate to use DNS to maintain information on a per-resource basis. First of all, DNS was never intended to handle that many records. Second, the limited record size is inappropriate for catalog information. Third, domain names are not appropriate as URNs. Therefore our approach is to use the DDDS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a Key following the rules found in the Dynamic Delegation Discovery System (DDDS). This document describes URI Resolution as an application of the DDDS and specifies the use of at least one Database based on DNS. This document, along with [10] and [9], obsoletes RFC 2168[12] and updates RFC 2276[8]. Mealling Expires January 12, 2001 [Page 3] Internet-Draft DDDS Based URI Resolution July 2000 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. All capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in [9]. Mealling Expires January 12, 2001 [Page 4] Internet-Draft DDDS Based URI Resolution July 2000 3. The Distinction between URNs and URLs From the point of view of this system, there is no theoretical difference between resolving URIs in the general case and URNs in the specific case. Operationally however, there is a difference that stems from URI resolution possibly not becoming of widespread use. If URN resolution is collapsed into generic URI resolution, URNs may suffer by the lack of adoption of URI resolution. The solution is to allow for shortcutting for URN resolution. In the following specification generic URI resolution starts by inserting rules for known URI schemes into the 'uri.arpa' registry. For the 'URN:' URI scheme, one of the rules found in 'uri.arpa' would be for the 'urn' URI scheme. This rule would simply delegate to the 'urn.arpa' zone for additional NAPTRs based on the URN namespace. Essentially, the URI Resolution Rewrite Rule for 'URN:' is the URN Resolution Application's First Well Known Rule. Therefore, this document specifies two DDDS Applications. One is for URI Resolution and the other is for URN Resolution. Both are technically identical but by separating the two URN Resolution can still proceed without the dependency. Mealling Expires January 12, 2001 [Page 5] Internet-Draft DDDS Based URI Resolution July 2000 4. The URI and URN Resolution Application Specifications 4.1 Application Unique String The Application Unique String is the Uniform Resource Identifier or Uniform Resource Name for which an authoritative server is being located. This URI or URN MUST be canonicalized and hex encoded according to the "absolute-uri" production found in the Collected ABNF from RFC 2396[13]. 4.2 First Well Known Rule In the URI case, the first known key is created by taking the URI scheme. In the URN case, the first known key is the Namespace Identifier. For example, the URI 'http://www.foo.com/' would have a 'http' as its Key. The URN 'urn:foo:foospace' would have 'foo' as its first Key. 4.3 Flags At this time only four flags, "S", "A", "U", and "P", are defined. The "S", "A" and "U" flags are for a terminal lookup. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a domain-name for which one or more SRV[4] records exist. See Section 5 for additional information on how URI and URN Resolution use the SRV record type. "A" means that the output of the Rule is a domain-name and should be used to lookup A records for that domain. The "U" flag means that the output of the Rule is a URL[13]. The "P" flag says that the remainder of the DDDS Algorithm is ignored and that the rest of the process is application specific and outside the scope of this document. An application can use the Protocol part found in the Services field to identify which Application specific set of rules that should be followed next. The record that contains the 'P' flag is the last record that is interpreted by the rules in this document. The remaining alphabetic flags are reserved for future versions of this specification. The numeric flags may be used for local experimentation. The S, A, U and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assisting in the creation of Rewrite Rules would be more likely to signal such an error than a client such as a browser). It is anticipated that multiple flags will be allowed in the future, so implementers MUST NOT assume that the flags field can only contain 0 or 1 characters. Finally, if a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on Mealling Expires January 12, 2001 [Page 6] Internet-Draft DDDS Based URI Resolution July 2000 fields. A novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target. The "S", "A", and "U" flags are called 'terminal' flags since they halt the looping rewrite algorithm. If those flags are not present, clients may assume that another Rule exists at the Key produced by the current Rewrite Rule. 4.4 Services Parameters Service Parameters for this Application take the form of a string of characters that follow this ABNF: service_field = [ [protocol] *("+" rs)] protocol = ALPHA *31ALPHANUM rs = ALPHA *31ALPHANUM ; The protocol and rs fields are limited to 32 ; characters and must start with an alphabetic. In other words, an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. The empty string is also valid. This will typically be seen at the beginning of a series of Rules, when it is impossible to know what services and protocols will be offered at the end of a particular delegation path. 4.4.1 Services The service identifiers that make up the 'rs' production are generic for both URI and URN resolution since the input value types itself based on the URI scheme. The list of valid services are defined in [6]. Examples of some of these services are: I2L: given a URI return one URL that identifies a location where the original URI can be found I2Ls: given a URI return one or more URLs that identify multiple locations where the original URI can be found I2R: given a URI return one instance of the resource identified by that URI. I2Rs: given a URI return one or more instances of the resources identified by that URI. Mealling Expires January 12, 2001 [Page 7] Internet-Draft DDDS Based URI Resolution July 2000 I2C: given a URI return one instance of a description of that resource. I2N: given a URI return one URN that names the resource (Caution: equality with respect to URNs is non-trivial. See [1]for examples of why.) 4.4.2 protocols The protocol identifiers that are valid for the 'protocol' production are defined by the protocol specifications themselves. At present the THTTP[5] protocol is the only such specification. Simply specifying any protocol in the services field is insufficient since there are additional semantics surrounding URI resolution that are not defined within the protocols. For example, if Z39.50 were to be specified as a valid protocol it would have to define how it would encode requests for specific services, how the URI is encoded, and what information is returned. 4.5 Valid Databases At present only one DDDS Database is specified for this Application. "A DDDS Database Using The Domain Name System"[10] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names. The output of the First Well Known Rule for the URI Resolution Application is the URI's scheme. In order to convert this to a unique key in this Database the string 'uri.arpa.' is appended to the end. This domain-name is used to request NAPTR records which produces new keys in the form of domain-names. The output of the First Well Known Rule of the URN Resolution Application is the URN's namespace id. In order to convert this to a unique key in this Database the string 'urn.arpa.' is appended to the end. This domain-name is used to request NAPTR records which produces new keys in the form of domain-names. DNS servers MAY interpret Flag values and use that information to include appropriate SRV and A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. Mealling Expires January 12, 2001 [Page 8] Internet-Draft DDDS Based URI Resolution July 2000 5. Examples 5.1 An example using a URN Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier[3], "duns", is extracted from the URN and prepended to 'urn.arpa', producing 'duns.urn.arpa'. The DNS is queried for NAPTR records for this domain which produces the following results: duns.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "dunslink+I2L+I2C" "" dunslink.udp.dandb.com. IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.dandb.com. IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.dandb.com. The order field contains equal values, indicating that no order has to be followed. The preference field indicates that the provider would like clients to use the special 'dunslink' protocol, followed by the RCDS protocol, and that THTTP is offered as a last resort. All the records specify the "s" flag which means that the record is terminal and that the next step is to retrieve an SRV record from DNS for the given domain-name. The service fields say that if we speak dunslink, we will be able to issue either the I2L or I2C requests to obtain a URL or ask some complicated questions about the resource. The Resource Cataloging and Distribution Service (RCDS)[7] could be used to get some metadata for the resource, while THTTP could be used to get a URL for the current location of the resource. Assuming our client does not know the dunslink protocol but does know the RCDS protocol, our next action is to lookup SRV RRs for rcds.udp.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: Mealling Expires January 12, 2001 [Page 9] Internet-Draft DDDS Based URI Resolution July 2000 ;; Pref Weight Port Target rcds.udp.dandb.com IN SRV 0 0 1000 defduns.dandb.com. IN SRV 0 0 1000 dbmirror.com.au. IN SRV 0 0 1000 ukmirror.com.uk. telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV specification[4] for the interpretation of the fields above). There is opportunity for significant optimization here. We can return the SRV records as additional information for terminal NAPTRs (and the A records as additional information for those SRVs). While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it. This is a significant optimization. In conjunction with a long TTL for *.urn.arpa records, the average number of probes to DNS for resolving DUNS URNs would approach one. Therefore, DNS server implementors SHOULD provide additional information with NAPTR responses. The additional information will be either SRV or A records. If SRV records are available, their A records should be provided as recursive additional information. Note that the example NAPTR records above are intended to represent the reply the client will see. They are not quite identical to what the domain administrator would put into the zone files. Also note that there could have been an additional first step where the URN was resolved as a generic URI by looking up urn.uri.arpa. The resulting rule would have specified that the NID be extracted from the URN and 'urn.arpa' appended to it resulting in the new key 'duns.urn.arpa' which is the first step from above. 5.2 CID URI Scheme Example Consider a URI scheme based on MIME Content-Ids. The URI might look like this: cid:199606121851.1@mordred.gatech.edu (Note that this example is chosen for pedagogical purposes, and does not conform to the CID URL scheme.) The first step in the resolution process is to find out about the CID scheme. The schem is extracted from the URI, prepended to 'uri.arpa', and the NAPTR for 'cid.uri.arpa' looked up in the DNS. Mealling Expires January 12, 2001 [Page 10] Internet-Draft DDDS Based URI Resolution July 2000 It might return records of the form: cid.uri.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "!cid:.+@([^\.]+\.)(.*)$!\2!i" . We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URI to see if it matches, which it does. The \2 part of the substitution expression returns the string "gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records at the domain-name 'gatech.edu'. Note that the rule does not extract the full domain name from the CID, instead it assumes the CID comes from a host and extracts its domain. While all hosts, such as 'mordred', could have their very own NAPTR, maintaining those records for all the machines at a site that large would be an intolerable burden. Wildcards are not appropriate here since they only return results when there is no exactly matching names already in the system. The record returned from the query on "gatech.edu" might look like: gatech.edu. ;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" z3950.tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+I2C" "" rcds.udp.gatech.edu. IN NAPTR 100 50 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.gatech.edu. Continuing with our example, we note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: Mealling Expires January 12, 2001 [Page 11] Internet-Draft DDDS Based URI Resolution July 2000 ;; Pref Weight Port Target z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu. IN SRV 0 0 1000 z3950.cc.gatech.edu. IN SRV 0 0 1000 z3950.uga.edu. telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. 5.3 Resolving an HTTP URI Scheme Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URI resolution system that can also provide location independence for those URLs. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for 'http.uri.arpa'. This might return a record of the form: http.uri.arpa. IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "!http://([^/:]+)!\1!i" . This expression returns everything after the first double slash and before the next slash or colon. (We use the '!' character to delimit the parts of the substitution expression. Otherwise we would have to use backslashes to escape the forward slashes, and would have a regexp in the zone file that looked like this: "/http:\\/\\/([^\\/:]+)/\\1/i"). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com. ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "thttp+L2R" "" thttp._tcp.foo.com. IN NAPTR 100 100 "s" "ftp+L2R" "" ftp._tcp.foo.com. Mealling Expires January 12, 2001 [Page 12] Internet-Draft DDDS Based URI Resolution July 2000 Looking up SRV records for thttp.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. Mealling Expires January 12, 2001 [Page 13] Internet-Draft DDDS Based URI Resolution July 2000 6. Notes o Registration procedures for the 'urn.arpa' and 'uri.arpa' DNS zones are specified in "Assignment Procedures for URI Resolution using DNS"[11]. o If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necessary to make delegation of portions of the namespace work. The order field is what lets site administrators say "all requests for URIs matching pattern x go to server 1, all others go to server 2". A match is defined as: 1. The NAPTR provides a replacement domain name 2. or the regular expression matches the URI o When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. o If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. o When a namespace is to be delegated among a set of resolvers, regexps must be used. Each regexp appears in a separate NAPTR RR. Administrators should do as little delegation as possible, because of limitations on the size of DNS responses. o Note that SRV RRs impose additional requirements on clients. Mealling Expires January 12, 2001 [Page 14] Internet-Draft DDDS Based URI Resolution July 2000 7. IANA Considerations The use of the "urn.arpa" and "uri.arpa" zones requires registration policies and procedures to be followed and for the operation of those DNS zones to be maintained. These policies and procedures are spelled out in a "Assignment Procedures for the URI Resolution using DNS"[11]. The operation of those zones imposes operational and administrative responsibilities on the IANA. The registration methods used for specifying values for the Services (both protocols and services) and Flags fields that are specific to URI resolution is for a specification to be published as an RFC and approved by the IESG. The registration policies for URLs and URNs are also specified elsewhere and thus those impacts on the IANA are spelled out there. Mealling Expires January 12, 2001 [Page 15] Internet-Draft DDDS Based URI Resolution July 2000 8. Security Considerations The use of "urn.arpa" and "uri.arpa" as the registry for namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. This document has discussed a way of locating a resolver, but has not discussed any detail of how the communication with the resolver takes place. There are significant security considerations attached to the communication with a resolver. Those considerations are outside the scope of this document, and must be addressed by the specifications for particular resolver communication protocols. Mealling Expires January 12, 2001 [Page 16] Internet-Draft DDDS Based URI Resolution July 2000 9. Acknowledgments The editors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. Finally, we would like to acknowledge our enormous intellectual debt to the participants in the Knoxville series of meetings, as well as to the participants in the URI and URN working groups. Specific recognition is given to Ron Daniel who was co-author on the original versions of these documents. His early implementations and clarity of thinking was invaluable in clearing up many of the potential boundary cases. Mealling Expires January 12, 2001 [Page 17] Internet-Draft DDDS Based URI Resolution July 2000 References [1] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994. [2] Arms, B., "The URN Implementors, Uniform Resource Names: A Progress Report", D-Lib Magazine, February 1996. [3] Moats, R., "URN Syntax", RFC 2141, May 1997. [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [5] Danie1, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997. [6] Mealling, M., "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999. [7] Moore, K., Browne, S., Cox, J. and J. Gettler, "Resource Cataloging and Distribution System", Technical Report CS-97-346, December 1996. [8] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. [9] Mealling, M.M., "Dynamic Delegation Discovery System (DDDS)", , May 2000. [10] Mealling, M.M., "A DDDS Database Using The Domain Name System", Internet-Draft draft-ietf-urn-dns-ddds-database-00.txt, May 2000. [11] Mealling, M., "Assignment Procedures for DDDS Rules in URI.ARPA and URN.ARPA", Internet-Draft draft-ietf-uri.arpa-procedures-03.txt, February 2000. [12] Danie1, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997. [13] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Mealling Expires January 12, 2001 [Page 18] Internet-Draft DDDS Based URI Resolution July 2000 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 January 12, 2001 [Page 19] Internet-Draft DDDS Based URI Resolution July 2000 Appendix A. Pseudo Code For the edification of implementers, pseudocode for a client routine using NAPTRs is given below. This code is provided merely as a convenience, it does not have any weight as a standard way to process NAPTR records. Also, as is the case with pseudocode, it has never been executed and may contain logical errors. You have been warned. // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { // prepend prefix to urn.arpa sprintf(key, "%s.urn.arpa", extractNS(URN)); do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' discard any records with an unknown value in the "flags" field. sort NAPTR records by "order" field and "preference" field (with "order" being more significant than "preference"). n_naptrs = number of NAPTR records in response. curr_order = records[0].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { if (unknown_flag) // skip this record and go to next one continue; newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } Mealling Expires January 12, 2001 [Page 20] Internet-Draft DDDS Based URI Resolution July 2000 if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a successful rewrite and we will // know how to speak the protocol and request a known // resolution service. Before we do the next lookup, check // some optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); // Did we not find our way to a resolver? if (!rewrite_flag) { report an error return NULL; } // Leave rest to another protocol? if (strcasecmp(flags, "P")) { return key as host to talk to; } // If not, keep plugging if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; Mealling Expires January 12, 2001 [Page 21] Internet-Draft DDDS Based URI Resolution July 2000 } Mealling Expires January 12, 2001 [Page 22] Internet-Draft DDDS Based URI Resolution July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Mealling Expires January 12, 2001 [Page 23] From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 14 14:17: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 OAA26804 for ; Fri, 14 Jul 2000 14:17: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 NAA08249; Fri, 14 Jul 2000 13:21:42 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8605526 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 13:21: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 NAA08198 for ; Fri, 14 Jul 2000 13:21:30 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id NAA06956 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 13:05:14 -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: <20000714130513.V6129@bailey.dscga.com> Date: Fri, 14 Jul 2000 13:05:13 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: draft-ietf-urn-ddds-00.txt To: URN-IETF@LISTS.INTERNIC.NET Network Working Group M.M. Mealling Internet-Draft Network Solutions, Inc. Expires: January 12, 2001 July 14, 2000 Dynamic Delegation Discovery System (DDDS) draft-ietf-urn-ddds-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a the Dynamic Delegation Discovery System or DDDS which, when applied to a unique string will produce a series of rules that describe the various delegations that may exist based on the syntax of that string. Since the DDDS is an abstract algorithm, this specification does not define either an application or a rule database. Mealling Expires January 12, 2001 [Page 1] Internet-Draft DDDS July 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 5 3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 5 3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 7 4. Specifying An Application . . . . . . . . . . . . . . . . . . 8 5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1 An Automobile Parts Identification System . . . . . . . . . . 10 6.2 A Document Identification Service . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 Mealling Expires January 12, 2001 [Page 2] Internet-Draft DDDS July 2000 1. Introduction The Dynamic Delegation Discovery System is used to map some unique string to data stored within the DDDS by iteratively applying string transformation rules until a terminal condition is reached. This document describes the general algorithm, not any particular application or usage scenario. It is up to other documents to describe how they use the DDDS algorithms. The DDDS's history is an evolution from work done by the Uniform Resource Name Working Group. When Uniform Resource Names[1] were originally formulated there was the desire to locate an authoritative server for a URN which by design contained no information about network locations. A system was formulated that could use a database of rules that could be applied to a URN to find out information about specific chunks of syntax. This system was originally called the Resolver Discovery System[2] and only applied to URNs. Over time other systems began to apply this same algorithm and infrastructure to other, non-URN related, systems. This caused some of the underlying assumptions to change and need clarification. This document, which is one of a series, is an update of those original URN specifications in order to allow new applications and rule databases to be developed in a standardized manner. A direct result of these clarifications and generalizations is that this document, along with [4] and [5], obsoletes RFC 2168[6] and updates RFC 2276[2]. Mealling Expires January 12, 2001 [Page 3] Internet-Draft DDDS July 2000 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Application Unique String A string that is the target of the rewrite rules. Each possible value of the string must be unique within the space for which it is valid in order for the rewrite rules to apply. Rewrite Rule An object containing several pieces of data that, when combined and applied to an Application Unique String, produces a new key that exists in the Rule Database. Also simply known as a Rule. First Well Known Rule This is a rewrite rule that is defined by the application and not actually in the Rule Database. It is used to produce the first valid key. Terminal Rule This Rule is one where the Flags specify that the iterative process is over and that the output of applying this Rule to the Application Unique String will be the intended output of the entire process. Application A set of protocols and specifications that specify actual values for the various generalized parts of the DDDS algorithm. An Application must define the syntax and semantics of the Application Unique String, the First Well Known Rule, and which Databases are valid for the Application. Database Any store of Rules such that a unique key can identify a set of Rules that specify the delegation step used when that particular Key is used. Mealling Expires January 12, 2001 [Page 4] Internet-Draft DDDS July 2000 3. The Algorithm The DDDS algorithm is based on the concept of Rewrite Rules. These rules are given unique Keys that are collected into a database that is known as a DDDS Rule Database. A given Rule, when applied to an Application Unique String, transforms that String into new Key that can be used to retrieve a new Rule from the Rule Database. This new rule is then re-applied to the original Application Unique String and the cycle repeats itself until a terminating condition is reached. 3.1 Components of a Rule A Rule is made up of 4 pieces of information: A Priority Simply a number used to show which of two otherwise equal rules may have precedence. This allows the database to express rules that are equivalent but weighted for load balancing reasons. A set of Flags Flags are used to specify attributes of the rule that determine if this rule is the last one to be applied. The last rule is called the terminal rule and its output should be the intended result for the application. A description of Services Services are used to specify attributes of a particular delegation branch. For example, two rules may equally apply to a specific delegation decision for a string. One rule can lead to a terminal rule that produces information for use in high availability environments while another may lead to an archival service that may be slower but is more stable over long periods of time. A Substitution Expression This is the actual string modification part of the rule. It is a combination of a POSIX Extended Regular Expression[3] and a replacement string similar to SED search-replace function. See Section 3.2. 3.2 Substitution Expression Syntax The syntax of the Substitution Expression part of the rule is a sed-style substitution expression. True sed(1) substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow this grammar: Mealling Expires January 12, 2001 [Page 5] Internet-Draft DDDS July 2000 subst_expr = delim-char ere delim-char repl delim-char *flags delim-char = "/" / "!" / ... (Any non-digit or non-flag character. All ocurances of a delim_char in a subst_expr must be the same character.) ere = POSIX Extended Regular Expression repl = string / backref / repl string / repl backref string = anychar escapeddelim / escapeddelim anychar anychar = ; any character other than delim-char escapeddelim = "\" delim-char backref = "\" POS_DIGIT flags = "i" POS_DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" The result of applying the substitution expression to the String MUST result in a key which obeys the rules of the Database. Since it is possible for the regular expression to be improperly specified, such that a non-conforming key can be constructed, client software SHOULD verify that the result is a legal database key before using it. Backref expressions in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution Mealling Expires January 12, 2001 [Page 6] Internet-Draft DDDS July 2000 expression, the delimiter character must not also be a flag character. 3.3 The Complete Algorithm The following is the exact DDDS algorithm: 1. The First Well Known Rule is applied to the Application Unique String which produces a Key 2. That Application asks the Database for the ordered set of Rules that are bound to that Key 3. The Substitution Expression of each Rule in the list of Rules is applied to the String in the order in which they were received. In some applications and/or databases the result set can express the case where two or more Rules are considered equal. These Rules are treated as the same Rule, each one possibly having a Priority which is used to weight a random selection among the equivalent Rules (this allows for Rules to 'load balance' themselves). 4. The first/next Rule with a Substitution Expression that produces anything other than the empty string is examined to see if the parameters in the Services part of the Rule meet the requirements of the Application. 5. If the parameters in the Service part of the Rule do not match those required by the Application then go back to Step 4. 6. If the Flags part of the Rule designate that this Rule is Terminal, then apply the Substitution Expression to the String and then go to Step 8. 7. Apply the Substitution Expression to the String. The output of this rewrite becomes the new Key. To begin the next iteration, return to Step 2 and use this new Key as the Key in that step. 8. Notify the Application that the process has finished and provide the Application with the Flags and Services part of the Rule along with the output of the last Substitution Expression. Mealling Expires January 12, 2001 [Page 7] Internet-Draft DDDS July 2000 4. Specifying An Application In order for this algorithm to have any usefulness, a specification must be written describing an application and one or more databases. In order to specify an application the following pieces of information are required: Application Unique String: This is the original string that the rewrite rules will apply to. The string must have some regular structure and be unique within the application such that anyone applying Rules taken from the same Database will end up with the same Keys. For example, the URI Resolution application would define the Application Unique String to be a URI. No application is allowed to define an Application Unique String such that the Key obtained by a rewrite rule is treated as the Application Unique String for input to a new rule. This leads to sendmail style rewrite rules which are fragile and error prone. First Well Known Rule: This is the first rule that, when applied to the Application Unique String, produces the first valid Key. It can be expressed in the same form as a Rule or it can be something more complex. For example, the URI Resolution application might specify that the rule is that the sequence of characters in the URI up to but not including the first colon (the URI scheme) is the first Key. Valid Databases: The application can define which Databases are valid. For each Database the Application must define how the First Well Known Rule's output (the first Key) is turned into something that is valid for that Database. For example, the URI Resolution application could use the Domain Name System (DNS) as a Database. The operation for turning this first Key into something that was valid for the database would be to to turn it into some DNS-valid domain-name. Expected Output: The Application must define what the expected output of the Terminal Rule should be. For example, the URI Resolution application is concerned with finding servers that contain authoritative data about a given URI. Thus the output of the terminal rule would be information (hosts, ports, protocols, etc) that would be used to contact that authoritative server. Mealling Expires January 12, 2001 [Page 8] Internet-Draft DDDS July 2000 5. Specifying A Database Additionally, any Application must have at least one corresponding Database from which to retrieve the Rules. A Database specification must include the following pieces of information: General Specification: The Database must have a general specification. This can reference other standards (SQL, DNS, etc) or it can fully specify a novel database system. Lookup Procedure: This specifies how a query is formulated and submitted to the database. In the case of databases that are used for other purposes (such as DNS), the specification must be clear as to how a query is formulated specifically for the database to be a DDDS database. For example, a DNS based Database must specify which Resource Records or Query Types are used. Key Format: If any operations are needed in order to turn a Key into something that is valid for the database then these must be clearly defined. For example, in the case of a DNS database, the Keys must be constructed as valid domain-names. Rule Format: The specification for the output format of a rule. Rule Insertion Procedure: A specification for how a Rule is inserted into the database. This can include policy statements about whether or not a Rule is allowed to be added. Mealling Expires January 12, 2001 [Page 9] Internet-Draft DDDS July 2000 6. Examples The examples given here are for pedagogical purposes only. They are specifically taken from fictious applications that have not been specified in any published document. 6.1 An Automobile Parts Identification System In this example imagine a system setup where by all automobile manufacturers come together and create a standardized part numbering system for the various parts (nuts, bolts, frames, instruments, etc) that make up the automobile manufacturing and repair process. The problem with such a system is that the auto industry is a very distributed system where parts are built by various third parties distributed around the world. In order to find information about a given part a system must be able to find out who makes that part and contact them about it. To facilitate this distributed system the identification number assigned to a part is assigned hierarchically such that the first 5 digits make up a parts manufacturer ID number. The next 3 digits are an auto line identifier (Ford, Toyota, etc). The rest of the digits are assigned by the parts manufacturer according to rules that the manufacturer decides. The auto industry decides to use the DDDS to create a distributed information retrieval system that routes queries to the actual owner of the data. The industry specifies a database and a query syntax for retrieving rewrite rules (the APIDA Network) and then specifies the Auto Parts Identification DDDS Application (APIDA). The APIDA specification would define the following: o Application Unique String: the part number o First Well Known Rule: take the first 5 digits (the manufacturers ID number) and use that as the Key o Valid Databases: The APIDA Network o Expected Output: EDIFAC information about the part The APIDA Network Database specification would define the following: o General Specification: a network of EDI enabled databases and services that, when given a subcomponent of a part number will return an XML encoded rewrite rule o Lookup Procedure: following normal APIDA Network protocols, ask Mealling Expires January 12, 2001 [Page 10] Internet-Draft DDDS July 2000 the network for a rewrite rule for the Key. o Key Format: no conversion is required o Rule Format: see APIDA Network documentation for the XML DTD o Rule Insertion Procedure: determined by the authority that has control over each section of the part number. I.e. in order to get a manufacturer ID you must be a member of the Auto Parts Manufacturers Association In order to illustrate how the system would work, imagine the part number "4747301AB7D". The system would take the first 5 digits, '47473' and ask the network for that Rewrite Rule. This Rule would be provided by the parts manufacturers database and would allow the manufacturer to either further sub-delegate the space or point the querier directly at the EDIFAC information in the system. In this example lets suppose that the manufacturer returns a Rule that states that the next 3 digits should be used as part of a query to their service in order to find a new Rule. This new Rule would allow the parts manufacturer to further delegate the query to their parts factories for each auto line. In our example part number the number '01A' denotes the Toyota line of cars. The Rule that the manufacturer returns further delegates the query to a supply house in Japan. This rule also denotes that this Rule is terminal and thus the result of this last query will be the actual information about the part. 6.2 A Document Identification Service This example is very similar to the last since the documents in this system can simply be thought of as the auto part in the last example. The difference here is that the information about the document is kept very close to the author (usually on their desktop). Thus there is the probability that the number of delegations can be very deep. Also, in order to keep from having a large flat space of authors, the authors are organized by organizations and departments. Let's suppose that the Application Unique String in this example looks like the following: The Application specification would look like this: o Application Unique String: the Document ID string given above o First Well Known Rule: the characters up to but not including the first '-' is treated as the first Key. Mealling Expires January 12, 2001 [Page 11] Internet-Draft DDDS July 2000 o Valid Databases: the DIS LDAP Directory o Expected Output: a record from an LDAP server containing bibliographic information about the document in XML The Database specification for the DIS LDAP Directory would look like this: o General Specification: the Database uses the LDAP directory service. Each LDAP server has a record that contains the Rewrite Rule. Rules refer to other LDAP servers using the LDAP URL scheme. o Lookup Procedure: using standard LDAP queries, the client asks the LDAP server for information about the Key. o Key Format: no conversion is necessary. o Rule Format: See the LDAP Rewrite Rule specification o Rule Insertion Procedure: See the procedures published by the entity that has authority over that section of the DIS tree. The first section, the organization, is owned by the DIS Agency. In this example, the first lookup is for the organization's Rule. At that point the organization may point the client directly at some large, organization wide database that contains the expected output. Other organizations may decentralize this process so that Rules end up delegating the query all the way down to the authors document management environment of choice. Mealling Expires January 12, 2001 [Page 12] Internet-Draft DDDS July 2000 References [1] Moats, R., "URN Syntax", RFC 2141, May 1997. [2] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. [3] The Institute of Electrical and Electronics Engineers, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937-255-9, January 1993. [4] Mealling, M.M., "A DDDS Database Using The Domain Name System", Internet-Draft draft-ietf-urn-dns-ddds-database-00.txt, May 2000. [5] Mealling, M.M., "URI Resolution using the Dynamic Delegation Discovery System", Internet-Draft draft-ietf-urn-uri-res-ddds-00.txt, July 2000. [6] Danie1, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 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 January 12, 2001 [Page 13] Internet-Draft DDDS July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Mealling Expires January 12, 2001 [Page 14] From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 14 14:37:50 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 OAA02761 for ; Fri, 14 Jul 2000 14:37: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 OAA21493; Fri, 14 Jul 2000 14:19:15 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8605876 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 14:19:12 -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 OAA21455 for ; Fri, 14 Jul 2000 14:19:06 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id OAA07207 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 14:02:21 -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: <20000714140220.F7073@bailey.dscga.com> Date: Fri, 14 Jul 2000 14:02:20 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: draft-ietf-urn.arpa-procedures-04.txt To: URN-IETF@LISTS.INTERNIC.NET Network Working Group M. Mealling Internet-Draft Network Solutions, Inc. Expires: August 1, 2000 R.D. Daniel Metacode, Inc. February 2000 Assignment Procedures for URI Resolution Using DNS draft-ietf-urn.arpa-procedures-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 1, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract RFCXXXX defines a how DNS is used as a DDDS database that contains URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving "http://foo.com/" would be to look up a NAPTR record for the domain "http.URI.ARPA". URN resolution also follows a similar procedure but uses the 'URN.ARPA' zone as its root. This document describes the procedures for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones. Mealling & Daniel Expires August 1, 2000 [Page 1] Internet-Draft URI.ARPA Registration Procedures February 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. URI Resolution vs URN Resolution . . . . . . . . . . . . . . 3 3. Registration Policies . . . . . . . . . . . . . . . . . . . 3 3.1 URI.ARPA Registration . . . . . . . . . . . . . . . . . . . 3 3.1.1 Only Schemes in the IETF Tree Allowed . . . . . . . . . . . 3 3.1.2 Scheme Registration Takes Precedence . . . . . . . . . . . . 3 3.1.3 NAPTR Registration May Accompany Scheme Registration . . . . 4 3.1.4 Registration or Changes after Scheme Registration . . . . . 4 3.2 URN.ARPA Registration . . . . . . . . . . . . . . . . . . . 4 3.2.1 NID Registration Takes Precedence . . . . . . . . . . . . . 4 3.2.2 NAPTR Registration May Accompany NID Registration . . . . . 4 3.2.3 Registration or Changes after Scheme Registration . . . . . 4 4. Requirements on hints . . . . . . . . . . . . . . . . . . . 5 5. Submission Procedure . . . . . . . . . . . . . . . . . . . . 6 6. Registration Template . . . . . . . . . . . . . . . . . . . 6 6.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Example Template . . . . . . . . . . . . . . . . . . . . . . 7 8. The URN Registration in the URI.ARPA zone . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 Mealling & Daniel Expires August 1, 2000 [Page 2] Internet-Draft URI.ARPA Registration Procedures February 2000 1. Introduction This document defines the policies and procedures for inserting NAPTR records into the 'URI.ARPA' and 'URN.ARPA' zones for the purpose of resolving URIs according to "URI Resolution using the Dynamic Delegation Discovery System" (RFCXXXX)[9], which is an Application that uses the DNS based DDDS Database defined in RFCXXXX[8]. The algorithm expressed by these Rules is specified in "Dynamic Delegation Discovery System (DDDS) (RFCXXXX)[10]. 2. URI Resolution vs URN Resolution RFCXXXX[9] defines how both URI[4] resolution and URN[3] resolution work when DNS is used as the delegation rule (or hint) database. Specifically it says that the initial instructions ('hints') for DNS-based resolution of URIs are stored as resource records in the 'URI.ARPA' DNS zone. Since a URN is a kind of URI, a hint for resolution of the URI prefix 'urn:' will also be stored in the 'URI.ARPA' zone. This rule states that the namespace id[3] is extracted, 'URN.ARPA' is appended to the end of the namespace id, and the result is used as the key for retrieval of a subsequent NAPTR record[2]. 3. Registration Policies The creation of a given URI scheme or URN namespace id (NID) follows the appropriate registration documents for those spaces. URI schemes follow "Registration Procedures for URL Scheme Names" (RFC 2717)[7]. URN namespace ids follow "URN Namespace Definition Mechanisms" (RFC 2611)[6]. 3.1 URI.ARPA Registration 3.1.1 Only Schemes in the IETF Tree Allowed In order to be inserted into the URI.ARPA zone, the subsequent URI scheme MUST be registered under the IETF URI tree. The requirements for this tree are specified in [7]. 3.1.2 Scheme Registration Takes Precedence The registration of a NAPTR record for a URI scheme MUST NOT precede proper registration of that scheme and publication of a stable specification in accordance with [7]. The IESG or its designated expert will review the request for 1. correctness and technical soundness 2. consistency with the published URI specification, and 3. to ensure that the NAPTR record for a DNS-based URI does not Mealling & Daniel Expires August 1, 2000 [Page 3] Internet-Draft URI.ARPA Registration Procedures February 2000 delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain. 3.1.3 NAPTR Registration May Accompany Scheme Registration A request for a URI.ARPA registration MAY accompany a request for a URI scheme (in accordance with [7]), in which case both requests will be reviewed simultaneously by IESG or its designated experts. 3.1.4 Registration or Changes after Scheme Registration A request for a NAPTR record (or an request to change an existing NAPTR record) MAY be submitted after the URI prefix has been registered. If the specification for the URI prefix is controlled by some other party than IETF, IESG will require approval from the owner/maintainer of that specification before the registration will be accepted. This is in addition to any technical review of the NAPTR registration done by IESG or its designated experts. 3.2 URN.ARPA Registration 3.2.1 NID Registration Takes Precedence The registration of a NAPTR record for a URN NID MUST NOT precede proper registration of that NID and publication of a stable specification in accordance with [6]. This is to prevent the registration of a NAPTR record in URN.ARPA from circumventing the NID registration process. 3.2.2 NAPTR Registration May Accompany NID Registration A request for a URN.ARPA registration MAY accompany a request for a NID (in accordance with [6]), in which case both requests will be reviewed at the same time. 3.2.3 Registration or Changes after Scheme Registration A request for a NAPTR record (or an request to change an existing NAPTR record) MAY be submitted after the NID has been registered. If the specification for the NID is controlled by some other party than IETF, IESG will require approval from the owner/maintainer of that specification before the registration will be accepted. This is in addition to any technical review of the NAPTR registration done by IESG or its designated experts. Note that this applies to all NAPTR records for a particular NID, even though a NAPTR record might affect only part of the URN space Mealling & Daniel Expires August 1, 2000 [Page 4] Internet-Draft URI.ARPA Registration Procedures February 2000 assigned to an NID 4. Requirements on hints Delegation of a namespace can happen in two ways. In the case of most URIs, the key being delegated to is hard-coded into the identifier itself (i.e. a hostname in an HTTP URL). The syntax of where this new key is located is predetermined by the syntax of the scheme. In other cases, the new key can be part of the hint itself. This is the functional equivalent of saying, "if this rule matches then this is always the key." In order to minimize the query load on the URI.ARPA and URN.ARPA zones, it is anticipated that the resource records in those zones will have extremely long "times to live" (TTLs), perhaps measured in years. Thus, for any URI prefix or URN namespace for which the resolution hints are likely to change, the actual rule should be stored in some other (less stable) DNS zone, and within URI.ARPA or URN.ARPA a stable NAPTR record should be used to delegate queries to that less stable zone. For example, the 'foo' URN namespace has flexible rules for how delegation takes place. Instead of putting those rules in the URN.ARPA zone, the entry instead punts those rules off to a nameserver that has a shorter time to live. The record in URN.ARPA would look like this: foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com. Thus, when the client starts out in the resolution process, the first step will be to query foo.URN.ARPA to find the above record, the second step is to begin asking 'urn-resolver.foo.com' for the NAPTR records that contain the resolution rules. The TTL at the root is very long. The TTL at the 'urn-resolver.foo.com' is much shorter. Conversely, the 'http' URL scheme adheres to a particular syntax that specifies that the host to ask is specified in the URL in question. Since this syntax does not change, that rule can be specified in the URI.ARPA zone. The record would look like this: http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" . Thus, the second step of resolution is to use the domain-name found in the URL as the next key in the cycle. If, for example, that NAPTR was terminal and contains some hostname in the replacement field, then the client could contact that host in order to ask questions about this particular URI. Mealling & Daniel Expires August 1, 2000 [Page 5] Internet-Draft URI.ARPA Registration Procedures February 2000 5. Submission Procedure Using the MIME Content-Type registration mechanism[5]as a model for a successful registration mechanism, the 'URI.ARPA' and 'URN.ARPA' procedures consist of a request template submitted to an open mailing list made up of interested parties. If no objections are made within a two week period, a representative of the registration authority considers the submission to be accepted and enters that submission into the nameserver. o Registrations for the 'URI.ARPA' zone are sent to 'register@URI.ARPA'. o Registrations for the 'URN.ARPA' zone are sent to 'register@URN.ARPA'. At this time the registration authority is expected to be the IANA. Objections are restricted to those that point out impacts on the zone itself or to DNS in general. Objections to the URL scheme or to the URN namespace-id are not allowed, as these should be raised in their respective forums. The logical conclusion of this is that ANY sanctioned URL scheme or URN namespace MUST be allowed to be registered if it meets the requirements specified in this document as regards times to live and general impact to the DNS. 6. Registration Template The template to be sent to the appropriate list MUST contain the following values: 6.1 Key This is the URN NID or URL scheme, which is used as the domain portion of the DNS entry. It must be valid according to the procedures specified in the URN namespace-id assignment document and any future standards for registering new URL schemes. 6.2 Authority This is the authority doing the registration of the record. It must be an authority recognized as either the IESG or any authority defined in the URN NID[6] or URL scheme registration[7] documents. 6.3 Records The actual DNS records representing the rule set for the key. The required values are Preference, Order, Flags, Services, Regex, and Replacement as defined by RFCXXXX[2]. Mealling & Daniel Expires August 1, 2000 [Page 6] Internet-Draft URI.ARPA Registration Procedures February 2000 7. Example Template To: register@URN.ARPA From: joe@foo.com Key: foo Authority: Foo Technology, Inc as specified in RFCFOO Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com. 8. The URN Registration in the URI.ARPA zone Since this document discusses the URI.ARPA and URN.ARPA zones and the URN rule that exists in the URI.ARPA zone, it makes sense for the registration template for the URN URI rule to be specified here: To: register@URI.ARPA From: The IETF URN Working Group Key: urn Authority: RFC2141 Record: urn IN NAPTR 0 0 "" "" "/urn:([^:]+)/\\2/i" . 9. IANA Considerations This document describes a mechanism for registering representations of protocol items that have already been registered with some IETF sanctioned agency (probably the IANA as well). This means that the IANA need not determine appropriateness of the underlying namespaces, since that is determined by another process. The only real impact on the IANA will be o to create and maintain (or designate some other entity to maintain) a primary nameserver for the URI.ARPA and URN.ARPA zones; o to maintain the mailing lists "register@URI.ARPA" and "register@URN.ARPA" as the forum for discussions of submissions; and o to act as the party that determines if all objections have been noted and accommodated. References [1] Mealling, M. and R. Daniel, "Resolution of Uniform Resource Identifiers using the Domain Name System", November 1998. [2] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", November 1998. Mealling & Daniel Expires August 1, 2000 [Page 7] Internet-Draft URI.ARPA Registration Procedures February 2000 [3] Moats, R., "URN Syntax", RFC 2141, November 1998. [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [5] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [6] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN Namespace Definition Mechanisms", RFC 2611, October 1998. [7] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, January 1999. [8] Mealling, M.M., "A DDDS Database Using The Domain Name System", Internet-Draft draft-ietf-urn-dns-ddds-database-00.txt, May 2000. [9] Mealling, M.M., "URI Resolution using the Dynamic Delegation Discovery System", Internet-Draft draft-ietf-urn-uri-res-ddds-00.txt, July 2000. [10] Mealling, M.M., "Dynamic Delegation Discovery System (DDDS)", Internet-Draft draft-ietf-urn-ddds-00.txt, May 2000. Authors' Addresses Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070 US Phone: (703) 742-0400 EMail: michaelm@netsol.com Ron Metacode, Inc. 139 Townsend Street, Ste. 100 San Francisco, CA 94107 US Phone: +1 415 222 0100 EMail: rdaniel@metacode.com URI: http://www.metacode.com Mealling & Daniel Expires August 1, 2000 [Page 8] Internet-Draft URI.ARPA Registration Procedures February 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Mealling & Daniel Expires August 1, 2000 [Page 9] -- -------------------------------------------------------------------------------- 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 Jul 14 15:07: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 PAA14121 for ; Fri, 14 Jul 2000 15:07: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 PAA00464; Fri, 14 Jul 2000 15:01:19 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8605971 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 15:01:16 -0400 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 PAA00435 for ; Fri, 14 Jul 2000 15:01:14 -0400 (EDT) Received: from thinkingcat.com ([207.253.211.163]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXP00D2ZB3SGB@field.videotron.net> for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 14:52:42 -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: <20000714140220.F7073@bailey.dscga.com> Approved-By: Leslie Daigle Message-ID: <396F607A.7383DA86@thinkingcat.com> Date: Fri, 14 Jul 2000 14:48:26 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: draft-ietf-urn.arpa-procedures-04.txt To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, I suspect, given the draft-*** change, this is going to come out as an -00 document, not an -04 of the old one. While I'm on the subject -- I'll remind everyone that the change from .net to .arpa is an IETF policy thing, not a technical change because of how we've restructured things. Leslie. P.S.: Michael -- you forgot to change the dates in this... it's probably worth re-submitting, 'cause it's going to be confusing in the archives. Michael Mealling wrote: > > Network Working Group M. Mealling > Internet-Draft Network Solutions, Inc. > Expires: August 1, 2000 R.D. Daniel > Metacode, Inc. > February 2000 > > Assignment Procedures for URI Resolution Using DNS > draft-ietf-urn.arpa-procedures-04 [...] -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 14 15:13:23 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 PAA16483 for ; Fri, 14 Jul 2000 15:13:23 -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 PAA01901; Fri, 14 Jul 2000 15:08:17 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8606005 for URN-IETF@LISTS.INTERNIC.NET; Fri, 14 Jul 2000 15:08:14 -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 PAA01871 for ; Fri, 14 Jul 2000 15:08:11 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id OAA07427; Fri, 14 Jul 2000 14:51:44 -0400 (EDT) References: <20000714140220.F7073@bailey.dscga.com> <396F607A.7383DA86@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000714145143.M7073@bailey.dscga.com> Date: Fri, 14 Jul 2000 14:51:44 -0400 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: draft-ietf-urn.arpa-procedures-04.txt To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <396F607A.7383DA86@thinkingcat.com>; from leslie@thinkingcat.com on Fri, Jul 14, 2000 at 02:48:26PM -0400 Doh! Resubmitting..... -MM On Fri, Jul 14, 2000 at 02:48:26PM -0400, Leslie Daigle wrote: > Howdy, > > I suspect, given the draft-*** change, this is going to come out > as an -00 document, not an -04 of the old one. > > While I'm on the subject -- I'll remind everyone that the change > from .net to .arpa is an IETF policy thing, not a technical change > because of how we've restructured things. > > Leslie. > > P.S.: Michael -- you forgot to change the dates in this... it's > probably worth re-submitting, 'cause it's going to be confusing in > the archives. > > Michael Mealling wrote: > > > > Network Working Group M. Mealling > > Internet-Draft Network Solutions, Inc. > > Expires: August 1, 2000 R.D. Daniel > > Metacode, Inc. > > February 2000 > > > > Assignment Procedures for URI Resolution Using DNS > > draft-ietf-urn.arpa-procedures-04 > [...] > -- > > ------------------------------------------------------------------- > "My body obeys Aristotelian laws of physics." > -- ThinkingCat > > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- -- -------------------------------------------------------------------------------- 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 Sat Jul 15 17:03:09 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 RAA02275 for ; Sat, 15 Jul 2000 17:03: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 QAA02391; Sat, 15 Jul 2000 16:58:16 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8606790 for URN-IETF@LISTS.INTERNIC.NET; Sat, 15 Jul 2000 16:58:12 -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 QAA02365 for ; Sat, 15 Jul 2000 16:58:10 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id QAA09292; Sat, 15 Jul 2000 16:41:50 -0400 (EDT) References: <20000714130601.W6129@bailey.dscga.com> <200007151248.OAA01324@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20000715164150.C8296@bailey.dscga.com> Date: Sat, 15 Jul 2000 16:41:50 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: draft-ietf-urn-uri-res-ddds-00.txt To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200007151248.OAA01324@grimsvotn.TechFak.Uni-Bielefeld.DE>; from pk@TechFak.Uni-Bielefeld.DE on Sat, Jul 15, 2000 at 02:48:53PM +0200 On Sat, Jul 15, 2000 at 02:48:53PM +0200, Peter Koch wrote: > > duns.urn.arpa. > > ;; order pref flags service regexp replacement > > IN NAPTR 100 10 "s" "dunslink+I2L+I2C" "" dunslink.udp.dandb.com. > > IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.dandb.com. > > IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.dandb.com. > > > http://www.foo.com/software/latest-beta.exe > > The domain "dandb.com" is actually registered to somebody unrelated to this > example (DeLeon & Boggins, P.C., TX), and the use of "foo.com" has lead to > trouble in the past. I'd like to suggest that all fictitious domain names and > domain name parts of URLs in this and the "urn.arpa-procedures" document be > changed to follow the recommendations in RFC 2606/BCP 32. Good point! 2606 wasn't out in the first run. I'll make the changes and resubmit. Since we're after the deadline though no one will see it in the repository until a week or so after Pittsburgh... -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 Sat Jul 15 17:11:14 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 RAA03989 for ; Sat, 15 Jul 2000 17:11:14 -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 RAA04198; Sat, 15 Jul 2000 17:07:45 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8606788 for URN-IETF@LISTS.INTERNIC.NET; Sat, 15 Jul 2000 17:07:43 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from gemma.TechFak.Uni-Bielefeld.DE (gemma.TechFak.Uni-Bielefeld.DE [129.70.136.103]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id IAA03793 for ; Sat, 15 Jul 2000 08:54:56 -0400 (EDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.136.13]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20000427) with SMTP id OAA12743; Sat, 15 Jul 2000 14:48:53 +0200 (MET DST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id OAA01324; Sat, 15 Jul 2000 14:48:53 +0200 X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Message-ID: <200007151248.OAA01324@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sat, 15 Jul 2000 14:48:53 +0200 Reply-To: Peter Koch From: Peter Koch Subject: Re: draft-ietf-urn-uri-res-ddds-00.txt To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Fri, 14 Jul 2000 13:06:01 EDT." <20000714130601.W6129@bailey.dscga.com> > duns.urn.arpa. > ;; order pref flags service regexp replacement > IN NAPTR 100 10 "s" "dunslink+I2L+I2C" "" dunslink.udp.dandb.com. > IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.dandb.com. > IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.dandb.com. > http://www.foo.com/software/latest-beta.exe The domain "dandb.com" is actually registered to somebody unrelated to this example (DeLeon & Boggins, P.C., TX), and the use of "foo.com" has lead to trouble in the past. I'd like to suggest that all fictitious domain names and domain name parts of URLs in this and the "urn.arpa-procedures" document be changed to follow the recommendations in RFC 2606/BCP 32. -Peter From owner-urn-ietf@LISTS.INTERNIC.NET Tue Jul 18 20:19:13 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 UAA04042 for ; Tue, 18 Jul 2000 20:19: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 UAA20977; Tue, 18 Jul 2000 20:01:13 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8610201 for URN-IETF@LISTS.INTERNIC.NET; Tue, 18 Jul 2000 20:01:08 -0400 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 UAA20944 for ; Tue, 18 Jul 2000 20:01:06 -0400 (EDT) Received: (qmail 840 invoked from network); 18 Jul 2000 23:55:02 -0000 Received: from buzz.sonic.net (208.201.224.78) by marine.sonic.net with SMTP; 18 Jul 2000 23:55:02 -0000 Received: from sonic.net (bolt [208.201.224.36]) by buzz.sonic.net (8.8.8/8.8.5) with ESMTP id QAA26921; Tue, 18 Jul 2000 16:58:10 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id QAA24714; Tue, 18 Jul 2000 16:55:02 -0700 Approved-By: Terry Allen Message-ID: <200007182355.QAA24714@sonic.net> Date: Tue, 18 Jul 2000 16:55:02 -0700 Reply-To: Terry Allen From: Terry Allen Subject: re a NID-for-XML request To: URN-IETF@LISTS.INTERNIC.NET At Michael Mealling's request I'm forwarding this message, which may appear to subscribers to be out of context, to this list. The NID request was for "ndw" by Norm Walsh for a name space for his XML DTDs and similar material. There has been response to this message, which I'll reply to in the next couple days, from the original recipients. The wider issue is, where does policy re NID assignment get set, and who sets it. regards, Terry Allen From owner-urn-nid@apps.ietf.org Mon Jul 17 16:26:59 2000 Return-Path: owner-urn-nid@apps.ietf.org Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by prop.sonic.net (8.8.8/8.8.5) with ESMTP id QAA23475 for ; Mon, 17 Jul 2000 16:26:58 -0700 Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA19382; Mon, 17 Jul 2000 19:26:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 17 Jul 2000 19:26:13 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA19361; Mon, 17 Jul 2000 19:26:12 -0400 (EDT) Received: from marine.sonic.net (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA19348; Mon, 17 Jul 2000 19:26:09 -0400 (EDT) Received: from marine.sonic.net (208.201.224.37 -> marine.sonic.net) by cs.utk.edu (smtpshim v1.0); Mon, 17 Jul 2000 19:26:09 -0400 Received: (qmail 20751 invoked from network); 17 Jul 2000 23:26:02 -0000 Received: from buzz.sonic.net (208.201.224.78) by marine.sonic.net with SMTP; 17 Jul 2000 23:26:02 -0000 Received: from sonic.net (bolt [208.201.224.36]) by buzz.sonic.net (8.8.8/8.8.5) with ESMTP id QAA23864 for ; Mon, 17 Jul 2000 16:29:05 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id QAA04804 for urn-nid@apps.ietf.org; Mon, 17 Jul 2000 16:26:02 -0700 Date: Mon, 17 Jul 2000 16:26:02 -0700 From: Terry Allen Message-Id: <200007172326.QAA04804@sonic.net> To: urn-nid@apps.ietf.org Subject: re general solution for URNs for XML List-Unsubscribe: Status: RO I have been dismayed by the reaction to Norm's well intended proposal for a NID. I would like everyone who sees policy problems with it to write up the policy issues involved, so that 1) future applicants can be forewarned of the attitudes of subscribers to this list, 2) we can ensure that all applications are tested against the same policy issues, and 3) we can keep track of just what the arguments are so they don't morph over time. In short, let's have no more ad hoc objections. As for Leslie's desire for a more general solution for Norm's need for URNs, there are two considerations. - There is no particular reason to think that URNs for XML instances, DTDs, or schemas should be assigned in the same name space. And indeed, the cat is already out of the bag: Microsoft's Biztalk uses URNs, and Commerce One is using (experimental) URNs; there will be a tidal wave of new URNs washing ashore shortly. I cannot see that forcing these all to be experimental improves service one whit. - The institutions that are plausible candidates for supplying such a name space are ISO, the W3C, and OASIS. - ISO specified FPIs (the unique IDs we used to use for SGML, which were ruled out by the W3C in favor of URIs) in ISO 8879 et seq., but never did anything to establish a registry of them. Eventually it granted the GCA (Graphic Communications Asso.) license to act as US registrar, but the GCA never did anything useful with that power. The GCA is also a dubiously competent organization with murky governance. - The W3C created the requirement that URIs be used as PUBLIC identifiers in XML instances, but has not developed a name space for URNs for XML. I understand the W3C to have attitude problems with URNs, so I don't expect anything on this front. The W3C is also an organization with serious governance problems. - OASIS is well known to be unreliable in its technical services. It too has serious governance problems, some of which may be in the course of rectification. But the technical work that OASIS does (and well) is done by volunteers - such as Norm - and OASIS would have to rely on volunteers to keep a URN name space running. Failure to keep it running would have critical impacts on many users of the name space. Nobody I know would trust the job to OASIS. So Norm is left without a choice of name space to use a piece of. He is not acting from vanity, and it is incidental that he is acting as an individual (individuals do the work for organizations, and Norm would not be more reliable if he worked for an organization; he's very reliable as it is). There may be technical objections to his I-D that require revision, but blocking his application is only going to bring this group into disrepute and leave the rest of use to conclude that there is no point in requesting formal or informal NIDs - we might as well just use experimental ones. Is that what we want? regards, Terry Allen From owner-urn-ietf@LISTS.INTERNIC.NET Tue Jul 18 21:47: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 VAA02486 for ; Tue, 18 Jul 2000 21:47:07 -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 VAA15490; Tue, 18 Jul 2000 21:39:24 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8610341 for URN-IETF@LISTS.INTERNIC.NET; Tue, 18 Jul 2000 21:39:22 -0400 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 VAA15471 for ; Tue, 18 Jul 2000 21:39:20 -0400 (EDT) Received: from thinkingcat.com ([207.253.220.142]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXX00JJ08ASN1@field.videotron.net> for URN-IETF@LISTS.INTERNIC.NET; Tue, 18 Jul 2000 21:32:54 -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: <200007182355.QAA24714@sonic.net> Approved-By: Leslie Daigle Message-ID: <39750438.9AAC7AE9@thinkingcat.com> Date: Tue, 18 Jul 2000 21:28:24 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: re a NID-for-XML request To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Terry, all, Terry Allen wrote: > The wider issue is, where does > policy re NID assignment get set, and who sets it. In fact, this is not an issue at all. Policy is not set on the urn-nid@apps.ietf.org mailing list -- per RFC2611, the purpose of that mailing list is strictly and uniquely for input towards: "clarifying the expression of the registration information and suggestions for improvements to the namespace proposal." As I have tried to point out: although people on that list tend to have opinions about proposals (myself included) nothing changes policy until the IESG changes it. That may happen with input from this working group. And I believe the right way to determine if there is need for a policy (change) is to give this WG the opportunity to see the namespace proposal in question, not perceptions on a piece of a thread taken out of context from another mailing list. I've been waiting for the namespace proposal document to hit the I-D archives (it was submitted in the last hours' rush on Friday); at this point I'll dig an unnofficial copy out of my mail archives if we're going to start the discussion now now. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Tue Jul 18 22:16:13 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 WAA10529 for ; Tue, 18 Jul 2000 22:16:13 -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 WAA21540; Tue, 18 Jul 2000 22:09:11 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8610445 for URN-IETF@LISTS.INTERNIC.NET; Tue, 18 Jul 2000 22:09:08 -0400 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 WAA21511 for ; Tue, 18 Jul 2000 22:09:06 -0400 (EDT) Received: from thinkingcat.com ([207.253.220.142]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXX000V99P1I1@field.videotron.net> for urn-ietf@lists.internic.net; Tue, 18 Jul 2000 22:03:03 -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 Approved-By: Leslie Daigle Message-ID: <39750B49.C6C0F3DC@thinkingcat.com> Date: Tue, 18 Jul 2000 21:58:33 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: URN NID assignment -- policy To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit As it stands today, the only document/policy that governs URN namespace ID (NID) assignment is RFC2611. To paraphrase it, anyone can use URN NID's that are "x-", anyone willing to ship in a particular request template to IANA can get Informal "IANA-"-style NIDs assigned, and entities that publish an RFC (of any category) can request and have a Formal NID of a chosen set of characters/strings assigned. I _really_don't_ want us to go down the rathole of discussion that we had prior to publishing RFC2611, so I'm not going to re-summarize the different issues that were thought of then. Given the specific namespace proposals that have come in, and the fact that there has been discussion about whether they were what we really hoped would happen, there is room to reflect as a group as to whether we still think the open policy of RFC2611 is the best plan to stick with, or whether there are additional objectively measurable criteria that can be applied in the assessment of applications for Formal NIDs. Either way -- we (the URN WG) will probably have to provide input to the IESG, which may have its own take on things. To refresh your memories, recent namespace proposals have included: . PIN -- put forward by Michael Mealling in May (originally draft-mealling-pin-urn-00.txt, but the author said he had revisions to incorporate from the discussion) . OID -- put forward by Michael Mealling in May, soon to be updated in draft-mealling-oid-urn-01.txt (also waiting in the I-D queue) . ndw -- put forward by Norman Walsh, to appear as draft-nwalsh-urn-ndw-00.txt or -01.txt, depending on how the I-D editor handles a small glitch in the process, waiting in the I-D queue, but I'll forward an unofficial copy in a moment. So, the wider question is not where does policy happen -- it's "is there policy that needs to happen here, or do we take a stand and say there isn't?". Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Tue Jul 18 22:16: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 WAA10621 for ; Tue, 18 Jul 2000 22:16: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 WAA21989; Tue, 18 Jul 2000 22:11:13 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8610461 for URN-IETF@LISTS.INTERNIC.NET; Tue, 18 Jul 2000 22:11:11 -0400 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 WAA21756 for ; Tue, 18 Jul 2000 22:10:18 -0400 (EDT) Received: from thinkingcat.com ([207.253.220.142]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXX000F39QZ7G@field.videotron.net> for urn-ietf@lists.internic.net; Tue, 18 Jul 2000 22:04:14 -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 Approved-By: Leslie Daigle Message-ID: <39750B8F.81ECF1A9@thinkingcat.com> Date: Tue, 18 Jul 2000 21:59:43 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: unofficial copy of ndw NID draft To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Network Working Group N. Walsh Internet-Draft No organization Expires: January 12, 2001 July 14, 2000 A URN Namespace for Norman Walsh draft-nwalsh-urn-ndw-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a URN namespace that is engineered by Norman Walsh for naming personal resources such as XML Schema Namespaces, Schemas, Stylesheets, and other documents. 1. Introduction For some years, the author has been producing internet resources: documents, schemas, stylesheets, etc. In addition to providing URLs for these resources, the author wishes to provide location-independent names. In the past, this has been accomplised with Formal Public Identifiers (FPIs). FPIs provided the author with a mechanism for assigning unique, permanent location-independent names to resources. Walsh Expires January 12, 2001 [Page 1] Internet-Draft A URN Namespace for Norman Walsh July 2000 The Extensible Markup Language (XML) requires that all resources provide a system identifier which must be a URI and XML Namespaces require authors to identify namespaces by URI alone (it is not possible to provide an FPI for an XML Namespace identifier). Motivated by these observations, the author would like to assign URNs to some resources in order to retain unique, permanent location-independent names for them. This namespace specification is for a formal namespace. 2. Specification Template Namespace ID: "ndw" requested. Registration Information: Registration Version Number: 1 Registration Date: 2000-07-14 Declared registrant of the namespace: Norman Walsh ndw@nwalsh.com Declaration of structure: Opaque. The URNs assigned by the author will have internal structure, but the structure is not expected to be manifestly obvious to an outside observer. Relevant ancillary documentation: None Identifier uniqueness considerations: The versioned and distinct nature of the resources themselves makes duplication unlikely, but in the interest of providing concrete assurances, the owner agrees to maintain a table of assigned URNs and to absolutely avoid duplication by consulting that table before each new URN is published. Identifier persistence considerations: To the best of the namespace owner's ability, the usability of URNs will last as long as the resources they identify are Walsh Expires January 12, 2001 [Page 2] Internet-Draft A URN Namespace for Norman Walsh July 2000 reasonably useful. Process of identifier assignment: Assignment is limited to the owner and those authorities that are specifically designated by the owner. Process of identifier resolution: The owner will distribute catalogs (e.g., OASIS Open TR9401 Catalogs) that map the subset of URNs considered useful to resource identifiers (e.g., URLs). In addition, the owner will provide an online resolution service based on RFC2483. The owner will authorize additional resolution services as appropriate. Rules for Lexical Equivalence: URNs are lexically equivalent if they are lexically identical. Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. The owner will publish the table of assigned URNs online. Scope: Global 3. Examples The following examples are not guaranteed to be real. They are listed for pedagogical reasons only. urn:ndw:stylesheets:xsl:docbook:1.15 urn:ndw:doctypes:slides:1.25 urn:ndw:xsl:documentation:1.0 4. Security Considerations There are no additional security considerations other than those normally associated with the use and resolution of URNs in general. References Walsh Expires January 12, 2001 [Page 3] Internet-Draft A URN Namespace for Norman Walsh July 2000 [1] Goldfarb, C. F., "ISO (International Organization for Standardization) ISO 8879:1986(E) Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)", 1986. [2] W3C, XML WG, "Extensible Markup Language (XML) 1.0", February 1998, . [3] W3C, Namespaces WG, "Namespaces in XML", January 1999, . [4] OASIS, Entity Mgmt. TC, "Entity Management: OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401)", January 1994, . [5] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999. Author's Address Norman Walsh No organization EMail: ndw@nwalsh.com URI: http://nwalsh.com/~ndw/ Walsh Expires January 12, 2001 [Page 4] Internet-Draft A URN Namespace for Norman Walsh July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Walsh Expires January 12, 2001 [Page 5] From owner-urn-ietf@LISTS.INTERNIC.NET Wed Jul 19 08:23:13 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 IAA04849 for ; Wed, 19 Jul 2000 08:23: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 IAA22026; Wed, 19 Jul 2000 08:13:16 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8611602 for URN-IETF@LISTS.INTERNIC.NET; Wed, 19 Jul 2000 08:13:13 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id FAA16912 for ; Wed, 19 Jul 2000 05:06:45 -0400 (EDT) Received: from enoshima (dhcp-194-232.mag.keio.ac.jp [133.27.194.232]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id SAA04998; Wed, 19 Jul 2000 18:00:11 +0900 (JST) X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20000719174447.02f7fbe0@sh.w3.mag.keio.ac.jp> Date: Wed, 19 Jul 2000 18:04:20 +0900 Reply-To: "Martin J. Duerst" From: "Martin J. Duerst" Subject: Re: re a NID-for-XML request To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200007182355.QAA24714@sonic.net> >I have been dismayed by the reaction to Norm's well intended >proposal for a NID. I would like everyone who sees policy >problems with it to write up the policy issues involved, so >that 1) future applicants can be forewarned of the attitudes >of subscribers to this list, 2) we can ensure that all >applications are tested against the same policy issues, and 3) >we can keep track of just what the arguments are so they don't >morph over time. I haven't seen these objections, and so I can't say much about them. My main purely personal objection would be that it might make sense to have a lower length limit for namespace proposals that are not grandfathering existing well-known namespaces (such as e.g. isbn). >In short, let's have no more ad hoc objections. Please take the above as generic. >As for Leslie's desire for a more general solution for >Norm's need for URNs, there are two considerations. > > - There is no particular reason to think that URNs for > XML instances, DTDs, or schemas should be assigned > in the same name space. Agreed. > - The institutions that are plausible candidates for supplying > such a name space are ISO, the W3C, and OASIS. > > - ISO specified FPIs (the unique IDs we used to use for > SGML, which were ruled out by the W3C in favor of URIs) > in ISO 8879 et seq., but never did anything to establish > a registry of them. This matches what I have heard on this issue, which is not really that much. >Eventually it granted the GCA > (Graphic Communications Asso.) license to act as US > registrar, but the GCA never did anything useful with > that power. The GCA is also a dubiously competent > organization with murky governance. Could you mention an organization that you think does not have 'governance problems'? It seems every single organization you mention has them. > - The W3C created the requirement that URIs be used as > PUBLIC identifiers in XML instances, No. XML requires that external entities are identified either with the keyword PUBLIC, followed by both an FPI and an URI, or with the keyword SYSTEM, followed by an URI. In other words, the PubidLiteral is still an FPI, but it cannot appear alone. Please see http://www.w3.org/TR/REC-xml#sec-external-ent. >but has not > developed a name space for URNs for XML. As you say above, that's not necessarily something that makes sense. >I understand > the W3C to have attitude problems with URNs, so I don't > expect anything on this front. Let's put it that way: We think that many (if not most or all) of the things you want to do with URNs for XML you could do with (well designed and well managed, of course) URIs such as http:. Also, we never excluded URNs from being able to be used for XML, not at all. >The W3C is also an > organization with serious governance problems. If you could be more specific, maybe in personal mail, that might be more productive. >So Norm is left without a choice of name space to use a piece of. >He is not acting from vanity, and it is incidental that he is >acting as an individual (individuals do the work for organizations, >and Norm would not be more reliable if he worked for an organization; >he's very reliable as it is). There may be technical objections >to his I-D that require revision, but blocking his application >is only going to bring this group into disrepute and leave the >rest of use to conclude that there is no point in requesting >formal or informal NIDs - we might as well just use experimental >ones. Is that what we want? Agreed. Regards, Martin. From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 21 19:28: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 TAA22719 for ; Fri, 21 Jul 2000 19:28: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 TAA04145; Fri, 21 Jul 2000 19:23:27 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8615255 for URN-IETF@LISTS.INTERNIC.NET; Fri, 21 Jul 2000 19:23:23 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id JAA09215 for ; Fri, 21 Jul 2000 09:13:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07777; Fri, 21 Jul 2000 09:07:18 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007211307.JAA07777@ietf.org> Date: Fri, 21 Jul 2000 09:07:18 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nwalsh-urn-ndw-00.txt To: URN-IETF@LISTS.INTERNIC.NET --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A URN Namespace for Norman Walsh Author(s) : N. Walsh Filename : draft-nwalsh-urn-ndw-00.txt Pages : 4 Date : 20-Jul-00 This document describes a URN namespace that is engineered by Norman Walsh for naming personal resources such as XML Schema Namespaces, Schemas, Stylesheets, and other documents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nwalsh-urn-ndw-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nwalsh-urn-ndw-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nwalsh-urn-ndw-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000720141430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nwalsh-urn-ndw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nwalsh-urn-ndw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141430.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 21 19:28: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 TAA22735 for ; Fri, 21 Jul 2000 19:28: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 TAA03699; Fri, 21 Jul 2000 19:21:09 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8615252 for URN-IETF@LISTS.INTERNIC.NET; Fri, 21 Jul 2000 19:21:06 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id JAA16424 for ; Fri, 21 Jul 2000 09:47:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12952; Fri, 21 Jul 2000 09:41:14 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007211341.JAA12952@ietf.org> Date: Fri, 21 Jul 2000 09:41:14 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-net-procedures-04.txt To: URN-IETF@LISTS.INTERNIC.NET --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Assignment Procedures for the URI Resolution using DNS Author(s) : M. Mealling, R. Daniel Filename : draft-ietf-urn-net-procedures-04.txt Pages : 9 Date : 20-Jul-00 RFCXXXX defines a how DNS is used as a DDDS database that contains URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving 'http://foo.com/' would be to look up a NAPTR record for the domain 'http.URI.ARPA'. URN resolution also follows a similar procedure but uses the 'URN.ARPA' zone as its root. This document describes the procedures for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-net-procedures-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-net-procedures-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000720142057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-net-procedures-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-net-procedures-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720142057.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 21 19:38: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 TAA26268 for ; Fri, 21 Jul 2000 19:38: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 TAA05401; Fri, 21 Jul 2000 19:29:23 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8615260 for URN-IETF@LISTS.INTERNIC.NET; Fri, 21 Jul 2000 19:29:20 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id GAA15996 for ; Thu, 20 Jul 2000 06:53:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12600; Thu, 20 Jul 2000 06:47:46 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007201047.GAA12600@ietf.org> Date: Thu, 20 Jul 2000 06:47:46 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-uri-res-ddds-00.txt To: URN-IETF@LISTS.INTERNIC.NET --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URI Resolution using the Dynamic Delegation Discovery System Author(s) : M. Mealling Filename : draft-ietf-urn-uri-res-ddds-00.txt Pages : 23 Date : 19-Jul-00 A specification for taking a URI and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document, along with [10] and [9], obsoletes RFC 2168[12] and updates RFC 2276[8]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-uri-res-ddds-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719141735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-uri-res-ddds-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719141735.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 21 19:40:13 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 TAA27188 for ; Fri, 21 Jul 2000 19:40:13 -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 TAA06358; Fri, 21 Jul 2000 19:34:03 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8615289 for URN-IETF@LISTS.INTERNIC.NET; Fri, 21 Jul 2000 19:33:59 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id GAA15942 for ; Thu, 20 Jul 2000 06:53:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12497; Thu, 20 Jul 2000 06:47:37 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007201047.GAA12497@ietf.org> Date: Thu, 20 Jul 2000 06:47:37 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-dns-ddds-database-00.txt To: URN-IETF@LISTS.INTERNIC.NET --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : A DDDS Database Using The Domain Name System Author(s) : M. Mealling Filename : draft-ietf-urn-dns-ddds-database-00.txt Pages : 19 Date : 19-Jul-00 This document describes a Dynamic Delegation Discovery System Database using the Domain Name System as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the NAPTR Resource Record. Since this document officially obsoletes RFC 2168, it is the official specification for the NAPTR DNS Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-dns-ddds-database-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719141715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-dns-ddds-database-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719141715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.INTERNIC.NET Fri Jul 21 19:42: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 TAA28330 for ; Fri, 21 Jul 2000 19:42: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 TAA05761; Fri, 21 Jul 2000 19:31:00 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8615271 for URN-IETF@LISTS.INTERNIC.NET; Fri, 21 Jul 2000 19:30:57 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id GAA15964 for ; Thu, 20 Jul 2000 06:53:46 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12548; Thu, 20 Jul 2000 06:47:41 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007201047.GAA12548@ietf.org> Date: Thu, 20 Jul 2000 06:47:41 -0400 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-ddds-00.txt To: URN-IETF@LISTS.INTERNIC.NET --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Dynamic Delegation Discovery System (DDDS) Author(s) : M. Mealling Filename : draft-ietf-urn-ddds-00.txt Pages : 14 Date : 19-Jul-00 This document describes a the Dynamic Delegation Discovery System or DDDS which, when applied to a unique string will produce a series of rules that describe the various delegations that may exist based on the syntax of that string. Since the DDDS is an abstract algorithm, this specification does not define either an application or a rule database. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-ddds-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-ddds-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719141725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-ddds-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-ddds-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719141725.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.INTERNIC.NET Mon Jul 24 10:21:39 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 KAA05234 for ; Mon, 24 Jul 2000 10:21: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 KAA15563; Mon, 24 Jul 2000 10:05:29 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8617219 for URN-IETF@LISTS.INTERNIC.NET; Mon, 24 Jul 2000 10:05:25 -0400 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 KAA15537 for ; Mon, 24 Jul 2000 10:05:23 -0400 (EDT) Received: from thinkingcat.com ([207.253.207.189]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FY700CQGG56AY@field.videotron.net> for urn-ietf@lists.internic.net; Mon, 24 Jul 2000 09:58:19 -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 Approved-By: Leslie Daigle Message-ID: <397C4A5C.921FB6F3@thinkingcat.com> Date: Mon, 24 Jul 2000 09:53:32 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: WG decision item: nid procedures To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, To make things absolutely clear, pursuant to last week's mail re. the various proposed URN NID registrations of late, I'm putting the following question to the working group: Does the WG have consensus that: 1) (specific) changes are needed to the NID registration process (RFC2611), 2) we don't want to make changes to the process (RFC2611) at this time, or 3) we have no opinion either way, at this time ? Thanks, Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Mon Jul 24 10:35:20 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 KAA07802 for ; Mon, 24 Jul 2000 10:35:19 -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 KAA16491; Mon, 24 Jul 2000 10:09:15 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8617242 for URN-IETF@LISTS.INTERNIC.NET; Mon, 24 Jul 2000 10:09:12 -0400 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 KAA16461 for ; Mon, 24 Jul 2000 10:09:10 -0400 (EDT) Received: from thinkingcat.com ([207.253.207.189]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FY700DOKGBXHY@field.videotron.net> for urn-ietf@lists.internic.net; Mon, 24 Jul 2000 10:02:22 -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 Approved-By: Leslie Daigle Message-ID: <397C4B4F.46936076@thinkingcat.com> Date: Mon, 24 Jul 2000 09:57:35 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: WG decision item: DDDS as work item To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, I assume that people have had a chance to look over the various DDDS drafts, and I haven't heard any particularly strong opinions. Unless there are strong objections, I will consider that a WG decision to go with these documents, and look to putting them to WG last call next week. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Mon Jul 24 12:05:02 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 MAA05604 for ; Mon, 24 Jul 2000 12:05:01 -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 LAA07856; Mon, 24 Jul 2000 11:53:02 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8617448 for URN-IETF@LISTS.INTERNIC.NET; Mon, 24 Jul 2000 11:52:59 -0400 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 LAA07833 for ; Mon, 24 Jul 2000 11:52: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 LAA29749; Mon, 24 Jul 2000 11:46:51 -0400 (EDT) X-URI: http://www.cs.utk.edu/~moore/ X-SUBJECT-MSG-FROM: Leslie Daigle Approved-By: moore@CS.UTK.EDU Message-ID: <200007241546.LAA29749@astro.cs.utk.edu> Date: Mon, 24 Jul 2000 11:46:51 -0400 Reply-To: Keith Moore From: Keith Moore Subject: Re: WG decision item: DDDS as work item To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Your message of "Mon, 24 Jul 2000 09:57:35 EDT." <397C4B4F.46936076@thinkingcat.com> Leslie, right before an IETF meeting is not a good time to apply the "silence = consent" rule - people are often too busy trying to prepare for the meeting or tie up loose ends at home to pay proper attention to a new proposal. I know that I'm personally too busy to read these documents right now. so I recommend waiting until a couple of weeks after the IETF meeting before trying to evaluate DDDS. Keith From owner-urn-ietf@LISTS.INTERNIC.NET Mon Jul 24 12:51: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 MAA21442 for ; Mon, 24 Jul 2000 12:51:15 -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 MAA16729; Mon, 24 Jul 2000 12:37:25 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8617561 for URN-IETF@LISTS.INTERNIC.NET; Mon, 24 Jul 2000 12:37:23 -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 MAA16714 for ; Mon, 24 Jul 2000 12:37:21 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id MAA00850; Mon, 24 Jul 2000 12:21:03 -0400 (EDT) References: <397C4B4F.46936076@thinkingcat.com> <200007241546.LAA29749@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: <20000724122102.E769@bailey.dscga.com> Date: Mon, 24 Jul 2000 12:21:02 -0400 Reply-To: michaelm@netsol.com From: Michael Mealling Subject: Re: WG decision item: DDDS as work item To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200007241546.LAA29749@astro.cs.utk.edu>; from moore@cs.utk.edu on Mon, Jul 24, 2000 at 11:46:51AM -0400 On Mon, Jul 24, 2000 at 11:46:51AM -0400, Keith Moore wrote: > so I recommend waiting until a couple of weeks after the IETF > meeting before trying to evaluate DDDS. Same here. Especially since one document needs its examples tweaked which means a new rev... -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 Jul 24 14:01:20 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 OAA12478 for ; Mon, 24 Jul 2000 14:01:19 -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 NAA28535; Mon, 24 Jul 2000 13:35:25 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8617761 for URN-IETF@LISTS.INTERNIC.NET; Mon, 24 Jul 2000 13:35:23 -0400 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 NAA28513 for ; Mon, 24 Jul 2000 13:35:21 -0400 (EDT) Received: from thinkingcat.com ([207.253.207.189]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FY700G5NPQLU9@field.videotron.net> for URN-IETF@LISTS.INTERNIC.NET; Mon, 24 Jul 2000 13:25:34 -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: <397C4B4F.46936076@thinkingcat.com> <200007241546.LAA29749@astro.cs.utk.edu> <20000724122102.E769@bailey.dscga.com> Approved-By: Leslie Daigle Message-ID: <397C7AEF.837A8034@thinkingcat.com> Date: Mon, 24 Jul 2000 13:20:47 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: WG decision item: DDDS as work item To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit To clarify: . I'm not suggesting the WG should accept/finalize these versions of the documents in the next couple weeks, I'm asking if there are strong objections to taking on the work (per my message of 10 days ago on the subject). Per these requests to extend the period of consideration of the question, then, this is a call to those people who find the weeks before the IETF very focusing (i.e., their best shot at clearing their schedule for IETF work). I will post a gentle reminder after the IETF for those who focus better after the meetings are over, taking us to August 18 for closure on the decision of whether to pursue the DDDS documentation or to roll back. Leslie. Michael Mealling wrote: > > On Mon, Jul 24, 2000 at 11:46:51AM -0400, Keith Moore wrote: > > so I recommend waiting until a couple of weeks after the IETF > > meeting before trying to evaluate DDDS. > > Same here. Especially since one document needs its examples tweaked > which means a new rev... > > -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 -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Mon Jul 24 16:09:07 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 QAA20411 for ; Mon, 24 Jul 2000 16:09: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 PAA22854; Mon, 24 Jul 2000 15:34:41 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8617952 for URN-IETF@LISTS.INTERNIC.NET; Mon, 24 Jul 2000 15:34:39 -0400 Received: from case.vlc.com.au (case.vlc.com.au [203.27.111.4]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA22829 for ; Mon, 24 Jul 2000 15:34:35 -0400 (EDT) Received: from localhost (justin@localhost) by case.vlc.com.au (8.9.3/8.9.3) with ESMTP id DAA28525; Tue, 25 Jul 2000 03:25:42 +0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Justin Couch Message-ID: Date: Tue, 25 Jul 2000 03:25:42 +0800 Reply-To: Justin Couch From: Justin Couch Subject: Re: WG decision item: DDDS as work item To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: <200007241546.LAA29749@astro.cs.utk.edu> On Mon, 24 Jul 2000, Keith Moore wrote: > Leslie, > > right before an IETF meeting is not a good time to apply the > "silence = consent" rule - people are often too busy trying > to prepare for the meeting or tie up loose ends at home to > pay proper attention to a new proposal. I know that I'm > personally too busy to read these documents right now. That and quite afew of the people are at Siggraph atthe moment. (Yes, URNs have ahuge following overherewith the web3d folks). (bloody shittyspacebar doesn't work. grrr) Justin Couch Author, Java Hacker Software Architect justin@vlc.com.au J3D.org 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 Tue Jul 25 17:21:48 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 RAA10914 for ; Tue, 25 Jul 2000 17:21: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 RAA28057; Tue, 25 Jul 2000 17:09:06 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8618979 for URN-IETF@LISTS.INTERNIC.NET; Tue, 25 Jul 2000 17:09:03 -0400 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 RAA28027 for ; Tue, 25 Jul 2000 17:09:00 -0400 (EDT) Received: (qmail 30797 invoked from network); 25 Jul 2000 21:02:55 -0000 Received: from buzz.sonic.net (208.201.224.78) by marine.sonic.net with SMTP; 25 Jul 2000 21:02:55 -0000 Received: from sonic.net (bolt [208.201.224.36]) by buzz.sonic.net (8.8.8/8.8.5) with ESMTP id OAA18618; Tue, 25 Jul 2000 14:06:40 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id OAA02457; Tue, 25 Jul 2000 14:02:55 -0700 Approved-By: Terry Allen Message-ID: <200007252102.OAA02457@sonic.net> Date: Tue, 25 Jul 2000 14:02:55 -0700 Reply-To: Terry Allen From: Terry Allen Subject: re WG decision on nid procedures To: URN-IETF@LISTS.INTERNIC.NET [my apologies for delay in responding. And I'm posting only to urn-ietf, with a copy to Norm Walsh, as I believe all readers of urn-nid are readers of urn-ietf.] Keith wrote (to urn-nid): | > In short, let's have no more ad hoc objections. | | I agree that we need to develop a uniform policy, but such a policy | cannot spring out of thin air - we need to discuss pros and cons first. That's fine, but as Leslie points out, urn-nid isn't the place for it, and we should try to find some other place to do it in. | > - There is no particular reason to think that URNs for | XML instances, DTDs, or schemas should be assigned | in the same name space. | | I'm not sure what you mean by this. If you mean that the URN NID | shouldn't be coupled to the application in which the URN is used, | I'm absolutely in agreement. if you mean something else, please | elaborate. What I mean is that there is no reason that the URN for one DTD should be in the same name space as the URN for another DTD. | > - The institutions that are plausible candidates for supplying | such a name space are ISO, the W3C, and OASIS. | | huh? surely there are a lot more institutions which could support | URN namespaces. Those are the institutions and vendor consortia that are either directly responsible for XML (ISO and W3C) or are concerned with its development (OASIS). | > So Norm is left without a choice of name space to use a piece of. | | no decision has yet been made, and we've only been discussing it | a few days. | | I for one would be quite willing to see Norm be assigned an NID | consisting of three or more digits, if that is indeed suitable | for his purposes. what I don't want is for NIDs to be used | in such a way that it is detrimental to URNs, and I especially | don't want them to be used as human-readable service identifiers | like domain names have. I understand your position, although I disagree that human-readability makes URNs less useful. As I belive you've lost that argument I don't want to continue it. You should be aware of the case of Microsoft, which is using (or proposing to use, I haven't kept track) "schemas-microsoft-com" in BizTalk and hasn't applied for a formal NID. Leslie wrote (to urn-nid): | This list is not currently blocking Norman's application -- | I made that point on Friday, when I urged the discussion to the | urn-ietf@lists.internic.net mailing list for policy discussions. I don't have Larry's mail saved, so I'm not sure what list he sent it to, but he vowed to oppose publication of Norm's I-D as an RFC, which appears to be required by RFC 2611, section 4.0 (III) for a formal NID. His grounds, though not formally state, were, as I recall, something to do with either uniqueness or persistence (and I'll remark again that "persistence" has never been clarified sufficiently - a URN persists so long as it's in use by anyone; if something else is meant, we should say so). | This list is not a cabal for annointing or trashing NID requests. I surely would like to see it operate in such a fashion that it does not appear to be so. | When Norman's I-D surfaces in the I-D publication queue, I intend | to take it up on the URN WG list, at least at the level of discussing | what, if any, policy requirements people feel are missing in RFC2611. | | Terry Allen wrote: | > he's very reliable as it is). There may be technical objections | > to his I-D that require revision, but blocking his application | > is only going to bring this group into disrepute and leave the | > rest of use to conclude that there is no point in requesting | > formal or informal NIDs - we might as well just use experimental | > ones. Is that what we want? | | You're leaping to conclusion re. informal NIDs. Larry's objection would apply to informal NIDs, too. Leslie wrote (to urn-ietf): | Terry Allen wrote: | > The wider issue is, where does | > policy re NID assignment get set, and who sets it. | | In fact, this is not an issue at all. | | Policy is not set on the urn-nid@apps.ietf.org mailing list -- per | RFC2611, the purpose of that mailing list is strictly and uniquely for | input towards: | | "clarifying the expression of the registration information and | suggestions for improvements to the namespace proposal." | | As I have tried to point out: although people on that list tend to | have opinions about proposals (myself included) nothing changes policy | until the IESG changes it. That may happen with input from this | working group [TA: that would be the URN WG, whose list is urn-ietf]. Well, you just muddied the water with that last sentence. What I want is to have a clear and public statement of *all* the policy that exists, so that applicants can read it before applying, to have urn-nid operate as its supposed to, AND to have a place for those concerned with policy (including those such as Keith) to debate it. Whether that place would be a further work item for this WG or (probably better) a new WG I don't really care. | And I believe the right way to determine if there is need for a | policy (change) is to give this WG the opportunity to see the | namespace proposal in question, not perceptions on a piece of a thread | taken out of context from another mailing list. I think the WG [the URN WG, whose list is urn-ietf] would have to see the thread, not just the proposal, to understand what policy is being proposed. Leslie also wrote (to urn-ietf): | As it stands today, the only document/policy that governs URN namespace | ID (NID) assignment is RFC2611. | | To paraphrase it, anyone can use URN NID's that are "x-", | anyone willing to ship in a particular request template to IANA | can get Informal "IANA-"-style NIDs assigned, and entities | that publish an RFC (of any category) can request and have | a Formal NID of a chosen set of characters/strings assigned. | | I _really_don't_ want us to go down the rathole of discussion that | we had prior to publishing RFC2611, so I'm not going to re-summarize | the different issues that were thought of then. But there is nothing in 2611 about the very issues raised wrt Norm's I-D, which you wrote that you wanted the URN WG to examine. I too don't want to rehash old issues, but somewhere there needs to be an explicit public resolution of them. | Given the specific namespace proposals that have come in, and the | fact that there has been discussion about whether they were what | we really hoped would happen, there is room to reflect as a group | as to whether we still think the open policy of RFC2611 is the best | plan to stick with, or whether there are additional objectively | measurable criteria that can be applied in the assessment of | applications for Formal NIDs. | | Either way -- we (the URN WG) will probably have to provide input | to the IESG, which may have its own take on things. Fair enough; is that the way the IESG sees it? Should this be a new work item? or should this WG stay in existence indefinitely to consider policy as new proposal arise or arrive? ... | So, the wider question is not where does policy happen -- it's "is | there policy that needs to happen here, or do we take a stand and | say there isn't?". Um, also, "does the IESG have policy, even if only the policy that it expects the URN WG to refer policy issues to it"? Martin Duerst wrote (to urn-ietf): ... | >Eventually it granted the GCA | > (Graphic Communications Asso.) license to act as US | > registrar, but the GCA never did anything useful with | > that power. The GCA is also a dubiously competent | > organization with murky governance. | | Could you mention an organization that you think does not have | 'governance problems'? It seems every single organization you | mention has them. No, I mentioned four: ISO, the GCA, the W3C, and OASIS. I am not aware of governance problems with ISO. Nor for that matter with the IESG, the IETF, or ANSI. | > - The W3C created the requirement that URIs be used as | > PUBLIC identifiers in XML instances, | | No. XML requires that external entities | are identified either with the keyword PUBLIC, followed by | both an FPI and an URI, or with the keyword SYSTEM, followed | by an URI. In other words, the PubidLiteral is still an FPI, | but it cannot appear alone. Please see | http://www.w3.org/TR/REC-xml#sec-external-ent. My typo: I meant SYSTEM, which must be a URI. Leslie wrote most recently: | To make things absolutely clear, pursuant to last week's mail re. | the various proposed URN NID registrations of late, I'm putting the | following question to the working group: | | Does the WG have consensus that: | 1) (specific) changes are needed to the NID | registration process (RFC2611), | 2) we don't want to make changes to the process | (RFC2611) at this time, or | 3) we have no opinion either way, at this time | ? And my response would be 4) we have no work item to consider this. But maybe I'm wrong. Do we? regards, Terry From owner-urn-ietf@LISTS.INTERNIC.NET Tue Jul 25 20:39: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 UAA07726 for ; Tue, 25 Jul 2000 20:39: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 UAA06203; Tue, 25 Jul 2000 20:29:32 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8619121 for URN-IETF@LISTS.INTERNIC.NET; Tue, 25 Jul 2000 20:29:29 -0400 Approved-By: michael@BAILEY.DSCGA.COM Received: from nexus.berkshire.net (nexus.berkshire.net [206.72.196.10]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA22122 for ; Tue, 25 Jul 2000 19:12:54 -0400 (EDT) Received: from hermes (hermes.nwalsh.com [140.186.114.234]) by nexus.berkshire.net (8.9.2/8.9.2) with ESMTP id TAA16692; Tue, 25 Jul 2000 19:06:37 -0400 (EDT) Received: from ndw by hermes with local (Exim 3.12 #1 (Debian)) id 13HDmO-0000B0-00; Tue, 25 Jul 2000 19:06:28 -0400 References: <200007252102.OAA02457@sonic.net> X-URL: http://nwalsh.com/ X-Millennium: T-minus 22 weeks, 5 days, 6 hours, 9 minutes Lines: 72 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <87em4h95e6.fsf@nwalsh.com> Date: Tue, 25 Jul 2000 19:06:25 -0400 Reply-To: Norman Walsh From: Norman Walsh Subject: Re: re WG decision on nid procedures To: URN-IETF@LISTS.INTERNIC.NET In-Reply-To: Terry Allen's message of "Tue, 25 Jul 2000 14:02:55 -0700" / Terry Allen was heard to say: | [my apologies for delay in responding. And I'm posting only to | urn-ietf, with a copy to Norm Walsh, as I believe all readers of | urn-nid are readers of urn-ietf.] Selected interjections; I have feeling there has been a lot more discussion of the issues my application raises that I haven't seen. | | > - The institutions that are plausible candidates for supplying | | such a name space are ISO, the W3C, and OASIS. | | | | huh? surely there are a lot more institutions which could support | | URN namespaces. I would like to know what objective criteria these organizations meet that I do not. I assume that simple incorporation in the state of Massachusetts (or some other state :-) would not satisfy you. Or would it? The subjective assertion that I am less reliable than, say, the W3C or OASIS does not move me. | | Terry Allen wrote: | | > he's very reliable as it is). There may be technical objections | | > to his I-D that require revision, but blocking his application | | > is only going to bring this group into disrepute and leave the | | > rest of use to conclude that there is no point in requesting | | > formal or informal NIDs - we might as well just use experimental | | > ones. Is that what we want? | | | | You're leaping to conclusion re. informal NIDs. | | Larry's objection would apply to informal NIDs, too. And Larry asserted as much. And I think Terry's statement above follows logically from that assertion. | Well, you just muddied the water with that last sentence. What I | want is to have a clear and public statement of *all* the policy | that exists, so that applicants can read it before applying, to Yes, please. I did my best to follow the published policy as I understood it. | | > - The W3C created the requirement that URIs be used as | | > PUBLIC identifiers in XML instances, | | | | No. XML requires that external entities | | are identified either with the keyword PUBLIC, followed by | | both an FPI and an URI, or with the keyword SYSTEM, followed | | by an URI. In other words, the PubidLiteral is still an FPI, | | but it cannot appear alone. Please see | | http://www.w3.org/TR/REC-xml#sec-external-ent. | | My typo: I meant SYSTEM, which must be a URI. And in case the point was lost, there are now places where URIs can be used to name things where public identifiers *cannot* be used. Namely in the declaration of XML Namespaces[1]. Be seeing you, norm [1] http://www.w3.org/TR/REC-xml-names -- Norman Walsh | Man is an intellectual animal, and http://nwalsh.com/ | therefore an everlasting contradiction | to himself. His senses centre in | himself, his ideas reach to the ends of | the universe; so that he is torn to | pieces between the two, without a | possibility of its ever being | otherwise.--Hazlitt From owner-urn-ietf@LISTS.INTERNIC.NET Wed Jul 26 22:21: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 WAA22467 for ; Wed, 26 Jul 2000 22:21: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 WAA01985; Wed, 26 Jul 2000 22:14:40 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8620416 for URN-IETF@LISTS.INTERNIC.NET; Wed, 26 Jul 2000 22:14:36 -0400 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 WAA01961 for ; Wed, 26 Jul 2000 22:14:34 -0400 (EDT) Received: from thinkingcat.com ([207.253.108.85]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FYC00JPT37WX2@field.videotron.net> for URN-IETF@LISTS.INTERNIC.NET; Wed, 26 Jul 2000 22:07:09 -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: <200007252102.OAA02457@sonic.net> Approved-By: Leslie Daigle Message-ID: <397F9824.EB14925D@thinkingcat.com> Date: Wed, 26 Jul 2000 22:02:13 -0400 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: re WG decision on nid procedures To: URN-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit I'm not cc:'ing Norman Walsh on this, because this is WG stuff, not addressing his/anyone's issues with his proposed NID. Terry Allen wrote: > | As I have tried to point out: although people on that list tend to > | have opinions about proposals (myself included) nothing changes policy > | until the IESG changes it. That may happen with input from this > | working group [TA: that would be the URN WG, whose list is urn-ietf]. > > Well, you just muddied the water with that last sentence. What I > want is to have a clear and public statement of *all* the policy > that exists, so that applicants can read it before applying, to Point 1: As it stands today: Policy = RFC2611 Per policy, there is nothing that stands between any of the NID requests we've seen so far and being granted the NIDs but RFC publication (which typically includes IESG perusal/acceptance, even for Informational). Point 2: There have been a lot of comments on recently-proposed NIDs. As this WG is the creator of RFC2611, I have proposed it as the venue to air proposed changes to it, to become revised policy. > | I _really_don't_ want us to go down the rathole of discussion that > | we had prior to publishing RFC2611, so I'm not going to re-summarize > | the different issues that were thought of then. > > But there is nothing in 2611 about the very issues raised wrt Norm's > I-D, which you wrote that you wanted the URN WG to examine. And I'm saying that: if the issues are not raised here in the context of updating policy with new insights, they are not issues that are germane to this WG, nor will they stop the NIDs that have been or will be proposed. > | Either way -- we (the URN WG) will probably have to provide input > | to the IESG, which may have its own take on things. > > Fair enough; is that the way the IESG sees it? Should this be a new > work item? or should this WG stay in existence indefinitely to > consider policy as new proposal arise or arrive? You'd have to ask the IESG that, but I will note that indefinite WG's tend to be frowned upon. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.INTERNIC.NET Thu Jul 27 15:14: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 PAA03901 for ; Thu, 27 Jul 2000 15:14: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 PAA08661; Thu, 27 Jul 2000 15:05:14 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8620988 for URN-IETF@LISTS.INTERNIC.NET; Thu, 27 Jul 2000 15:05:11 -0400 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 PAA08638 for ; Thu, 27 Jul 2000 15:05:09 -0400 (EDT) Received: (qmail 21541 invoked from network); 27 Jul 2000 18:58:59 -0000 Received: from buzz.sonic.net (208.201.224.78) by marine.sonic.net with SMTP; 27 Jul 2000 18:58:59 -0000 Received: from sonic.net (bolt [208.201.224.36]) by buzz.sonic.net (8.8.8/8.8.5) with ESMTP id MAA01185 for ; Thu, 27 Jul 2000 12:02:54 -0700 X-envelope-info: Received: (from tallen@localhost) by sonic.net (8.8.8/8.7.3) id LAA09709 for URN-IETF@LISTS.INTERNIC.NET; Thu, 27 Jul 2000 11:58:59 -0700 Approved-By: Terry Allen Message-ID: <200007271858.LAA09709@sonic.net> Date: Thu, 27 Jul 2000 11:58:59 -0700 Reply-To: Terry Allen From: Terry Allen Subject: re NID policy To: URN-IETF@LISTS.INTERNIC.NET Leslie wrote: ... | There have been a lot of comments on recently-proposed NIDs. As | this WG is the creator of RFC2611, I have proposed it as the venue | to air proposed changes to it, to become revised policy. ... | > work item? or should this WG stay in existence indefinitely to | > consider policy as new proposal arise or arrive? | | You'd have to ask the IESG that, but I will note that indefinite | WG's tend to be frowned upon. It seems to me you are proposing an indefinite project. regards, Terry