idnits 2.17.1 draft-klensin-dns-search-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 539 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8191 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Madrid' is mentioned on line 168, but not defined == Missing Reference: 'RFC8222' is mentioned on line 211, but not defined == Unused Reference: 'MADRID' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC882' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC883' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC2822' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC3066' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'WAIS' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'Z39' is defined on line 495, but no explicit reference was found in the text -- No information found for draft-klensin-dns-role- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DNSROLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MADRID' -- Possible downref: Non-RFC (?) normative reference: ref. 'Netword' -- No information found for draft-klensin-i18n-newclass- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NEWCLASS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RealNames' ** Obsolete normative reference: RFC 822 (ref. 'RFC882') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 883 (Obsoleted by RFC 1034, RFC 1035) ** Downref: Normative reference to an Experimental RFC: RFC 2345 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Downref: Normative reference to an Informational RFC: RFC 2826 ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. 'THES' ** Downref: Normative reference to an Informational RFC: RFC 1625 (ref. 'WAIS') -- Possible downref: Non-RFC (?) normative reference: ref. 'Z39' Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John C. Klensin 2 May 28, 2001 3 Expires November 2001 5 A Search-based access model for the DNS 6 draft-klensin-dns-search-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This document supplements a companion document [DNSROLE] on the role 29 of the DNS relative to the uses to which it is being put and is 30 intended to start laying the groundwork for a specific proposal. 31 Both documents, their successors, and closely-related issues, can be 32 discussed on the mailing list at ietf-i18n-dns-directory@imc.org. 33 See http://www.imc.org/ietf-i18n-dns-directory/ for subscription and 34 archival information. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 0. Abstract 42 This memo discusses strategies for supporting "DNS searching" -- 43 finding of names in the DNS by a layered mechanism that permits fuzzy 44 matching, selection that uses attributes or facets, and use of 45 descriptive terms. Demand for these facilities appear to be 46 increasing with growth in the Internet (and especially the web) and 47 with requirements to move beyond the restricted subset of ASCII names 48 that have been the traditional contents of DNS "Class=IN". This 49 document proposes a three-level system for access to DNS names in 50 which the upper two levels involve search, rather than lookup, 51 functions. It also discusses some of the issues and challenges in 52 completing the design of, and deploying, such a system. 54 1. Introduction and Executive Summary 56 The notion of "DNS searching" is somewhat of an oxymoron: the DNS is 57 structured to only perform exact lookups of structured label strings. 58 But, as discussed elsewhere, there is considerable demand for 59 searching facilities -- partial and fuzzy matching, selection that 60 uses attributes or facets, and searching using descriptive terms-- 61 and that demand appears to be increasing with growth in the Internet 62 (and especially the web) and with requirements to move beyond the 63 restricted subset of ASCII names that have been the traditional 64 contents of DNS Class=IN. This document proposes a three-level 65 system for access to DNS names in which the upper two levels involve 66 search, rather than lookup, functions. It also discusses some of the 67 issues and challenges in completing the design of, and deploying, 68 such a system. 70 It has been suggested that introducing a "directory" or "keywords" 71 into, or above, the DNS could be used as a solution to the IDN 72 problem and, often, several others. Probing statements about 73 "directories" often quickly demonstrates that their advocates don't 74 agree on what they mean. This section outlines a three-layer 75 search/lookup model (adding two layers to the DNS, i.e., constructing 76 a three-layer model, rather than continuing with the single one we 77 have today). Those layers consist of the current DNS, a 78 search-capable layer using an extremely simple set of facets, and a 79 layer capable of broader search approaches in a localized context. It 80 is intended as a strawman for criticism and development, rather than 81 as a specific proposal. I.e., the details are left for WG efforts. 83 The document suggests that it is better to add two layers to the DNS 84 --constructing a three-layer model-- rather than just one. And I'm 85 going to try to avoid using the word "directory" as if it meant 86 anything, but I presume readers will insert that term when it matches 87 their perceptions. 89 This document is a preliminary proposal -- a framework and fodder for 90 a working group or design team-- rather than a complete specification 91 or even an approximation to one. 93 2. A three (or four) -layer environment. 95 The material below suggests three or more layers: 97 (1) The DNS, with the existing lookup mechanisms 99 (2) A restricted, facet-based, search system. 101 (3) Commercial, localized, and potentially topic-specific, search 102 environments. 104 (4) Something else? 106 2.1. Layer one: Identifiers -- a lookup system and the DNS. 108 In this model, the DNS remains largely as is (see section 3.3ff) or, 109 perhaps, a bit closer to its original purpose and assumption than the 110 direction in which it has evolved in recent years. I.e., it is a 111 distributed database, with precise lookups, whose lookup keys are 112 identifiers for Internet hosts and other objects. We give up the 113 notion that these identifiers should also serve as human-useful names 114 or at least try to do so. 116 As an aside, note that some people have suggested that we 117 should dehumanize DNS names entirely, e.g., prohibit the 118 registration and use of any name that can be found in any 119 dictionary for any language that can be represented in the 120 DNS-acceptable character set. This proposal doesn't 121 include that idea. But it is absent primarily because I 122 don't think the transition process is worth the time it 123 would take to explore rather than because it has no appeal. 125 The goal at this layer is relatively simple, unique, identifiers. It 126 is probably desirable that these identifiers be able to have some 127 human mneumonic value, but less important that they be tightly bound 128 to real-world names and descriptions. 130 The inputs and outputs at this layer are as they are in the DNS 131 today, although modifications to accomodate non-hosttable format 132 names there remain possible if that is deemed important. 134 2.2 Layer two: Names -- a faceted search system with a small number 135 of facets. 137 Much of the current burden borne by the DNS would appear to be better 138 localized in a search system that contains names and a small number 139 of facets/ attributes. This burden includes a whole range of 140 non-identifier goals and constraints: names that a user can 141 understand and find and that have significant mneumonic value, names 142 with trademark implications, a wide variety of naming systems and, in 143 general, helping people find the things for which they are looking. 144 It is critical that the number of attributes be constrained to a 145 minimal set --and that other attributes, especially those of special 146 interest, be deferred to the third layer. 148 It is probably most useful to think about this layer in terms of a 149 structured, multifacted, multihierarchical, thesaurus-like database 150 with search capability (Cf. ISO IS 5127-1 and IS 5127-6 [THES]), 151 rather than as a "directory" in the sense of X.500 and its 152 derivatives and antagonists. 154 The key question is what facets to use once the commercial product 155 requirements are removed (to layer three, see below). It appears to 156 me that, to satisfy to the critical name-uniqueness and real world 157 pressures on the DNS, candidates might be 159 name (IS 10646, see below) 160 language (presumably per RFC 3066) 161 geographical location (country, and/or for some federal 162 countries, country/province ("state"), granularity is 163 important; there may be a case for an additional facet 164 in a coordinate system) 165 network location (If we can figure out what that means 166 and how to express it in a canonical way.) 167 industry category code (For companies, presumably derived 168 from the Madrid Treaty [Madrid] list; the list would 169 need to be extended to deal with non-commercial 170 organizations and entities and for identifying 171 resources and services associated with people. 173 This typology gives the trademark view of the world somewhat more 174 precedence in looking at name conflict issues than one might like in 175 principle. But, in practice, one of the key issues we have 176 encountered in trying to store "names", rather than identifiers, in 177 the DNS is that the process unreasonably flattens the space. That 178 "Joe's Auto Repair" and "Joe's Pizza" can co-exist in the same 179 geographical area without conflict or confusion and that "Joe's 180 Pizza" in one area can co-exist with "Joe's Pizza" in another, again 181 without conflict or confusion, are the consequence of the way we name 182 and identify things in the real world. Most trademark rules ar the 183 consequence of those naming systems, not their cause. 185 It is not intended that this level act as a white pages service for 186 people. Doing so leads down several slippery slopes at once, 187 including heightened privacy concerns and a stronger requirement for 188 URL targets rather than DNS label ones (see below). 190 The names in this environment can reasonably be written in IS 10646 191 codes or some recoding of them. Since we would be starting more or 192 less from scratch, we could select lengths and codings for maximum 193 efficiency and utility, not to meet the constraints of existing 194 software. In such a context, this author has a slight bias for 195 direct UCS-4 coding, rather than ASCII-compatible ("ACE") codes; 196 compressed, null-octet- eliminating, systems such as UTF-8; or 197 surrogate introducers to hold things to 16 bits. The loss in 198 transport efficiency is likely to be more than compensated for by 199 gains in cleanliness and equal treatment of all scripts. But that 200 issue is separate from the main and important design arguments of 201 this document. 203 The work done for "nameprep" in the IDN WG is almost certainly 204 relevant to determining which names to actually store in the 205 database. But the stakes are lower here than the "get it right or 206 fail completely" constraint of the DNS lookup environment: one can 207 imagine search mechanisms that would apply a more liberal set of 208 matching rules (and/or localized and language-specific ones) than the 209 rules used to encode names (much like recent applications protocols 210 that explicitly distinguish between the formats one is permitted to 211 send and those one is expected to accept (Cf. [RFC8222])). 213 As is common with systems of this type, we would anticipate the 214 possibility of searching on any of the attributes and that searching 215 on free-text strings would not be exact (i.e., near-match responses 216 could be returned using any of several algorithms, with the user 217 making choices). As is equally common, we should think about user 218 interfaces that store both queries and response sets so that the 219 responses could be used offline and refreshed when the client systems 220 were attached to the Internet. 222 In summary, the goal at this layer is to provide unique tuples of 223 human-recognizable (not just mneumonic) names, but names that are 224 unique within a context, rather than a global system based on the 225 names alone. 227 The inputs at this layer are search values for one or more of the 228 facets. The outputs are still controversial, but would appear to 229 best be the full facet set of the matched tuple(s) and one or more 230 DNS names. One of many interesting questions is whether this layer 231 should pass through and return the DNS records themselves (labels, 232 class, type, and target) or whether it should return names (labels) 233 and let the applications do the DNS lookups. Another possibility is 234 to return one or more URLs (or more general URIs?) rather than DNS 235 names. Doing so increases flexibility but at the cost of greater 236 complexity and risk of recursion problems. 238 One possibility would be to create a URI for DNS record information 239 and use it to abstract this return information into something 240 applications can then specify or decode as appropriate. Use of this 241 would need to be carefully structured to avoid complex problems, but 242 might be a reasonable approach. 244 Experience with the DNS and other distributed databases also argues 245 persuasively that these records are not forever. Unless there are no 246 local copying and caching mechanisms (which seems unlikely and hard 247 to enforce), some type of time to live (TTL) or other expiration or 248 reverification mechanism will be needed. 250 2.3. Layer three: locality and/or content-domain-specific 251 lookup mechanisms. 253 The problem with the second-layer model is that there are a number of 254 usability and marketplace pressures for naming systems that offer 255 finer granularity and better match user needs. Interestingly, those 256 systems which have been included in experiments or partially deployed 257 (see, e.g., [RFC2345], [Netword], and [RealNames]) have demonstrated 258 that these systems require contextual localization, not a single 259 global environment. There are many causes for this, but need for 260 very specific searches that are geographic-area, topic-area, or 261 language or culturally specific tend to dominate the list. 263 The issue is perhaps illustrated by an example. Suppose the 264 granularity of an entry at the second level is 266 {"Joe's", "UK", Restaurant,... } 268 Now, I might want to create a business around a restaurant directory 269 for Bristol. I would probably want to construct a database that 270 contained exact locations, type of food, menu information, prices, 271 etc., and permit people to query it that way. That type of product 272 bears a strong relationship to traditional yellow pages services: the 273 right attributes to collect and the right way to organize them will 274 differ by topic (e.g., "menu" has no obvious analogy in an automobile 275 repair shop) and the business models are fairly established. 277 One can imagine many different types of keyword and (yellow 278 pages-like) directory services at this level, using different types 279 of protocol mechanisms as well as different types of database content 280 and schema. But those services are nearly ideal candidates for 281 competition: there is no requirement that either the providers or the 282 services be global or unique or even highly standardized. Having all 283 three layers bound to the same data sources --inheriting values from 284 them if one wants to think about it that way-- would provide a degree 285 of consistency that might be very attractive to users, so there are 286 clearly issues here that will need to be worked out in the 287 marketplace. 289 Inputs at the third layer will differ by service: one can imagine 290 free-text interfaces and menus (but see section 2.4) as well as 291 systems that more closely resemble faceted search terms. Outputs 292 will normally be layer-two names or strings to preserve name and 293 reference portability, or might be URIs containing such names. 295 Summary: Just as the monohierarchical identifier-lookup system at the 296 first (bottom) level should be supplemented by a multilingual, 297 multifaceted, multihierarchy search system at the second, that second 298 level system should be supplemented by a collection of localized, 299 subject- and topic- specific systems at the third. These third-level 300 systems need not be centrally coordinated in any way, although some 301 similarity of function and interface would almost certainly make them 302 more consistent for users and easier to market. 304 2.4. A layer above the third: free-text searching applications. 306 The approaches described above omit one set of techniques used today: 307 "web searches" on full text or its equivalent. These systems have an 308 important role (and, similar to the third level, there seems no 309 particular advantage to trying to standardize them worldwide). But 310 their disadvantage, if seen as a DNS surrogate or replacement, is 311 that they have difficulty distinguishing between the name of 312 something, a pointer to it, and a reference or discussion of it or 313 how it works. 315 If, for example, one is looking for a web site for a company, the 316 third level would presumably find that site. The second (or even the 317 DNS) might find it with some guessing, but this fourth level would 318 (as web search engines do today) probably not distinguish the 319 company's site from sites that reference the company or its products. 321 Layer three produces information that is explicitly bound to the 322 query, i.e., what one is looking for, while a search engine returns 323 values that also include sites where the subject of the query might 324 have been mentioned. 326 3 Context and directions 328 3.1 The data search and access model 330 It is interesting that recent IETF "directory" work has focused on 331 accessing mechanisms without worrying intensely about the underlying 332 database content, maintenance, and update issues. Those issues seem 333 to be the harder ones, i.e., the difference between LDAP and CNRP may 334 make less difference than how we structure, maintain, and distribute 335 the relevant data. 337 Of course, that does not suggest that the work is not 338 important or that it isn't required. And, to deploy the model 339 suggested above, we will need to deal with a pair of 340 uncomfortable problems: 342 * CNRP looks interesting, but has not been widely implemented or 343 deployed in production. 345 * LDAP is widely deployed, but primarily in implementations that 346 contain sufficient extensions and special features to be 347 non-interoperable. 349 If we are going to choose -- and layer two certainly implies a 350 choice-- we need to figure out how to do that. 352 3.2 Implications of uniqueness of name structures at the 353 second layer. 355 The IAB's discussion of DNS root uniqueness [RFC2826] argues that DNS 356 names must be unique, i.e., that there must not be alternate or 357 surrogate root structures if the Internet is to survive as a seamless 358 whole and be universally addressable and accessible. Even with 359 imprecise matching, similar arguments apply at level two, especially 360 if this is the first level at which names in natural languages (hence 361 including multilingual names), rather than constrained identifiers, 362 appear. 364 Because the name structures at the second level still must be unique, 365 some mechanism for registries or structuring of names will be 366 necessary to avoid conflicts. The problem is somewhat easier than 367 the ones encountered by ICANN and its associated groups because the 368 very structuring of the names and attributes creates opportunities 369 for dividing up responsibilities, but the registration problems exist 370 nonetheless and will need to be resolved. 372 3.3 Deployment against DNS base 374 As with the "new class" approach to DNS changes [NEWCLASS], the 375 approach outlined here does not require any changes to the 376 existing installed DNS base. But, like all solutions to the 377 multilingual name issues, it requires changes to all relevant 378 applications. The notion of moving from lookup to searching 379 does imply that we will need, not merely to change the code 380 that calls the name resolution system, but to rethink the UIs 381 of those applications. 383 3.4 Older applications 385 To fully realize internationalized naming requires changing all 386 applications to understand the new method, whatever it is. Older 387 applications will see distorted and unfriendly names under some 388 systems, and no names at all under others. The environment 389 contemplated here is a "no names" one -- applications that have not 390 been upgraded will not see internationalized names or other 391 natural-language phrases. The advantages of this are that it avoids 392 confusion and, as with the original host table to DNS conversion, 393 provides an incentive to convert old applications to make newer 394 naming styles visible. None of these transitions are ever easy, but 395 it may be worth going through this one to get things right, rather 396 than investing a large fraction of the pain to get a solution that 397 doesn't quite do the job. 399 3.5 Why not just a keyword system 401 As suggested above, the term "keyword system" is used to refer to 402 many different things. Many would fit nicely into the layer three 403 environment, but most of the existing proposals put them directly on 404 top of the DNS, or skip the DNS entirely and go directly to IP 405 addresses. The difficulty with these systems is that they either 406 must be localized (e.g., a different system or database for each 407 language, country, or smaller locality) or they don't scale well. In 408 particular, they eventually suffer from either the "all the good 409 names are taken" problem with which the DNS is frequently accused or 410 they yield to poor precision properties. 412 4 Summary 414 The solution to the "multilingual DNS" problem, and to a series of 415 other limitations of the DNS relative to today's expectations for 416 naming and searching, lies in solutions targeted to those problems, 417 rather than superimposing additional mechanisms on the DNS in ways 418 that, we hope, will not cause problems with older programs and 419 unconverted infrastructure. Inserting new layers avoids those risks 420 and permits a clean solution that is adapted to the problems, rather 421 than the limitations imposed by existing properties of the DNS. 423 5 IANA Considerations and related topics 425 At layer two, it is difficult to think about how the system might 426 function successfully without controlled vocabularies for each of the 427 non-name facets. As discussed in section 2.2, we have already 428 established one such registry (bound to an ISO standard), and 429 mechanisms for utilizing it, with RFC 3066. The Madrid agreement 430 provides classifications for types of businesses, but we would need 431 to extend the registry for names that are not business-related. The 432 two locational attributes are somewhat vague at this point, but 433 controlled vocabularies would presumably be needed, and should, if 434 possible, be drawn from stable, non-IETF, work (e.g., IS 3166-1 and 435 3166-2 might provide a foundation, and possibly a complete list, for 436 the location vocabulary). Curiously, there is no technical reason why 437 the names themselves must be unique: that is one of the attractions 438 of a model like this over attempting to overload the DNS. If 439 conflicts or confusion occur, those are standard civil (marketplace 440 or trademark) issues that can be resolved in their own environments, 441 rather than posing special Internet problems. 443 6 Security Considerations 445 Additional layers of naming, searching, and databases imply addition 446 of opportunities for compromising those databases and mechanisms. 447 Part of the challenge with the model implied here is to determine how 448 to secure and authenticate those databases and access (especially 449 modify access) to them. The good news is that, since the functions 450 are new, we should be able to design security mechanisms in, rather 451 than --as with the DNS-- have to try to graft them on to a structure 452 not designed for them. 454 7 References 456 [DNSROLE] Klensin, John. "Role of the Domain Name System", 457 work in progress, draft-klensin-dns-role-... 459 [MADRID] 461 [Netword] http://corp.netword.com/ -- real reference needed. 463 [NEWCLASS] Klensin, John, "Internationalizing the DNS -- A New 464 Class", work in progress, draft-klensin-i18n-newclass-... 466 [RealNames] http://www.realnames.com/ -- real reference needed. 468 [RFC882] Mockapetris, P.V., "Domain names: Concepts and facilities". 469 RFC 822. Nov-01-1983. 471 [RFC883] Mockapetris, P.V. "Domain names: Implementation 472 specification", RFC 883. Nov-01-1983. 474 [RFC1035] Mockapetris, P.V. "Domain names - implementation and 475 specification", RFC 1035. Nov-01-1987. 477 [RFC2345] Klensin, J, T. Wolf, G. Oglesby. "Domain Names and Company 478 Name Retrieval", RFC 2345. May 1998. 480 [RFC2822] Resnick, P., Editor. "Internet Message Format", RFC 2822. 481 April 2001. 483 [RFC2826] IAB. "IAB Technical Comment on the Unique DNS Root", RFC 484 2826. May 2000. 486 [RFC3066] Alvestrand, H. "Tags for the Identification of Languages", 487 RFC 3066. January 2001. 489 [THES] IS 5127-1, IS 5127-2. 491 [WAIS] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. 492 Kahle, J. Kunze, H. Morris, F. Schiettecatte. "WAIS over 493 Z39.50-1988", RFC 1625. June 1994. 495 [Z39] Z39.50, IS 23950. 497 8 Acknowledgements 499 This document, and the related notes, are the result of thinking that 500 has come together and evolved since before the issue of 501 internationalized access to domain names came onto the IETF's radar. 502 Discussions with a number of people have led to refinements in the 503 approach or the text, even though some of them might not recognize 504 their contributions or agree with the conclusions I have drawn from 505 them (indeed, some of those discussions were rooted in challenges to 506 the general ideas expressed here). Particularly important 507 suggestions have come from, or arisen out of conversations with, 508 Harald Alvestrand, Rob Austein, Fred Baker, Eric Brunner-Williams, 509 Randy Bush, Vint Cerf, Kilnam Chon, Dave Crocker, Leslie Daigle, 510 Patrik F�ltstr�m, Michael Froomkin, Francis Gurry, Paul Hoffman, 511 Kenny Huang, Mao Wei, Michael Mealing, Gary Oglesby, Qian Huilin, 512 James Seng, Theresa Swinehart, Len Tower, and Zita Wenzel as well as 513 some long-ago conversations with Jon Postel and J.C.R. Licklider. 515 9 Author's Address 517 John C Klensin 518 AT&T Labs 519 99 Bedford St, 4th floor 520 Boston, MA 02111 USA 521 +1 617 574 3076 522 klensin@att.com 524 Expires November 2001