idnits 2.17.1 draft-ietf-wnils-whois-mesh-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 288 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 34 has weird spacing: '...ing the respo...' == Line 198 has weird spacing: '...clients shoul...' -- 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 (20 October 1995) is 10413 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) -- Looks like a reference, but probably isn't: '1' on line 231 ** Downref: Normative reference to an Historic RFC: RFC 1835 (ref. 'Deutsch94') == Outdated reference: A later version (-06) exists of draft-ietf-wnils-whois-03 ** Downref: Normative reference to an Historic draft: draft-ietf-wnils-whois (ref. 'Weider94') Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 White Pages Requirements Working Group P. Faltstrom 2 draft-ietf-wnils-whois-mesh-02.txt BUNYIP INFORMATION SYSTEMS, inc 3 Expires: 12 April 1996 R. Schoultz 4 KTHNOC 5 C. Weider 6 BUNYIP INFORMATION SYSTEMS, inc 7 20 October 1995 9 How to interact with a Whois++ mesh 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), it areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 Overview 30 In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is 31 done by the client, since each server 'refers' the client to the next 32 appropriate server(s). The protocol is simple. The client opens a 33 connection to a server, sends a query, receives a reply, closes the 34 connection, and after parsing the response the client decides which 35 server to contact next, if necessary. 37 So, the client needs to have an algorithm to follow when it interacts 38 with the Whois++ mesh so that referral loops can be detected, cost is 39 minimised, and appropriate servers are rapidly and effectively 40 contacted. 42 Basic functionality 44 Each Whois++ client should be configured to automatically send queries 45 to a specific Whois++ server. The deault Whois++ server can vary 46 depending on which template is desired, and the location of the client 47 with respect to the WHOIS++ index mesh, but as a rule the server 48 should be as local as possible. 50 A 51 / \ 52 B C 53 / \ \ 54 Z -----> D E F 55 / \ 56 G H 58 Fig 1: The client Z is configured to first query server D 60 After getting responses from a server, the client can act in several 61 ways. If the number of hits is greater than zero, the response is just 62 presented to the user. If the client gets one or many servers-to-ask 63 answers, the client should be able to automatically resolve these 64 pointers, i.e. query these servers in turn. 66 A 67 / \ 68 B C 69 / \ \ 70 Z <----- D E F 71 \ / \ 72 --> G H 74 Fig 2: The client Z gets a "servers-to-ask G" response from D 75 and therefore may automatically queries server G. 77 Expansion of searches 79 If the number of hits is zero, or if the user in some way wants to 80 expand the search, it is recommended for the client to issue a 81 'polled-by' and 'polled-for' query to the server. The client can then 82 repeat the original query to the new servers indicated. 84 A 85 / \ 86 /-----> B C 87 / / \ \ 88 Z <----- D E F 89 / \ 90 G H 92 Fig 3: The client Z gets a "polled-by B" response from D 93 and therefore queries server B. 95 The client must always keep track of which servers it has queried 96 because it must itself detect loops in the mesh by not querying the 97 same server more than once. 99 A 100 / \ 101 /- B C 102 / / \ \ 103 Z <---/ D E F 104 / \ 105 G H 107 Fig 4: The client Z gets a "servers-to-ask D" response from B 108 but Z does not query D because the server D has already 109 been queried. 111 So, the default expansion of a query by a client causes increasingly 112 more comprenhensive index servers to be queried; the forward knowledge 113 contained in the index server mesh allows rapid pruning of these 114 larger trees. 116 All loop detection and elimination is done in the client, rather than 117 in the server mesh. This decision was made because loop detection and 118 elimination are quite difficult to build into the mesh if we are to 119 continue to allow each server to participate in multiple hierarchies 120 within the mesh. 122 Optimising the mesh 124 If organization A tends to use organization B's WHOIS++ server 125 frequently, for example if A is cooperating in a project with B, A may 126 wish to make B's server locally available by creating a local index 127 server which retrieves the centroid for both organizations. When A's 128 client then expands a query which is looking for someone at B, the 129 client can much more rapidly resolve the query, as it does not have to 130 find the top level servers for the tree to which A and B both belong. 132 A 133 / \ 134 B C 135 / \ \ 136 Z D --> F 137 / \ 138 G H 140 Fig 5: The server B gets a centroid from server F 142 A 143 / \ 144 B C 145 / \ \ 146 Z <----> D --- F 147 / \ 148 G H 150 Fig 6: The client queries server D, gets zero hits back, expands 151 the search and gets a "polled-by B" response back. 153 A 154 / \ 155 /--> B C 156 / / \ \ 157 Z <-/ D --- F 158 / \ 159 G H 161 Fig 7: The client Z queries server B and gets "servers-to-ask F" 162 response back. 164 A 165 / \ 166 B C 167 / \ \ 168 D --- F <-----> Z 169 / \ 170 G H 172 Fig 8: The client Z queries server F and gets the answer. 174 The example given in Fig 5-8 shows that the algorithm works even 175 though the Whois++ mesh is not a tree. There are many reasons why a 176 given index server mesh might be 'short-circuited'. For example, in 177 the case of a multinational company, the Swedish branch of Acme Inc., 178 is polled both by the national server in Sweden and the headquarters 179 server in the USA. By querying the Swedish server, one finds all 180 persons working at the Swedish branch of Acme Inc., but by querying 181 the Acme Inc. server in the USA, you will find all employees in the 182 company, including those in Sweden. 184 Note that the location of a server does not implicitly narrow the 185 search, i.e. you have to specify all information when sending a query 186 to a server. In the example above, one can see that by just querying a 187 server for companies in the USA, you will not implicitly only get hits 188 from records in the states, because the Acme Inc. server in the states 189 has polled a server in Sweden. So, in this case you have to explicitly 190 include "country=USA" in the query if you are only interested in those 191 records. 193 Although the WHOIS++ index service has been designed to make searches 194 at any location in the index mesh quite effective and efficient, 195 blindly expanding the query can incur an exponentially growing cost in 196 resources, and, as charging for responses is implemented in parts of 197 the WHOIS++ index service mesh, growing cost, automatic expansion is 198 not recommended. More sophisticated clients should also be 199 configurable to "cut off" some servers from a search, i.e. a blacklist 200 of servers. This might be needed when searching for records and one 201 server might have a very high cost (in dollars) so one might want to 202 explicitly forbid the client to send queries to that server. 204 The algorithm used by the server 206 By following this algorithm a client finds all records in a mesh which 207 the first Whois++ server queried belongs to. 209 The algorithm for the client follows: 211 Query := data to search for; 212 QueriedServers := {}; 213 AnswerList := {}; 214 OriginalServers := { known servers to this client }; 215 while OriginalServers is not empty do: 216 ServerList = OriginalServers; 217 while ServerList is not empty do: 218 Server := ServerList[1]; 219 if Server is not in QueriedServers then do: 220 send Query to Server; 221 Answer := answer from Server; 222 append ServersToAsk to ServerList; 223 remove Server from ServerList; 224 append Answers to AnswerList; 225 end; 226 done; 227 if query should be expanded then do: 228 ServerList := OriginalServers; 229 OriginalServers := {}; 230 while ServerList is not empty do: 231 Server := ServerList[1]; 232 send Polled-For-Query to Server; 233 Answer := answer from Server; 234 append Answer to OriginalServers; 235 remove Server from ServerList; 236 end; 237 done; 238 done; 239 display AnswerList to user; 241 The Directory of Servers 243 A second way of finding the correct server to query is to use a 244 separate service we call the Directory of Servers. 246 Authors Addresses 248 Patrik Faltstrom 249 BUNYIP INFORMATION SYSTEMS, inc 250 Suite 300 251 310 Ste Catherine Street West 252 Montreal, Quebec 253 CANADA H2X 2A1 254 256 Rickard Schoultz 257 KTHNOC, SUNET/NORDUnet/Ebone Operations Centre 258 S-100 44 STOCKHOLM 259 SWEDEN 260 262 Chris Weider 263 BUNYIP INFORMATION SYSTEMS, inc 264 Suite 300 265 310 Ste Catherine Street West 266 Montreal, Quebec 267 CANADA H2X 2A1 268 270 References 272 [Deutsch94] Deutsch P., Schoultz R., Faltstrom P., Weider C., 273 Architecture of the Whois++ service, August 1995. 274 RFC 1835 276 [Weider94] Weider C., Fullton J., Spero S., Architecture of the 277 WHOIS++ Index Service: Internet Draft, July 1994. 278 < URL:ftp://ds.internic.net/internet-drafts/ 279 draft-ietf-wnils-whois-03.txt >