idnits 2.17.1 draft-huitema-solo-00.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-27) 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 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 6 months document validity. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 933 has weird spacing: '... groups and t...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Huitema/INRIA 2 Internet Draft P-A. Pays/INRIA 3 December 1993 A. Zahm/TS-E3X 4 Expiration Date: June 1994 A. Woermann/TS-E3X 6 Simple Object Look-up protocol (SOLO) 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "work- 20 ing draft" or "work in progress." Please check the 1id-abstracts.txt 21 listing contained in the internet-drafts Shadow Directories on 22 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or 23 munnari.oz.au to learn the current status of any Internet Draft. 25 Abstract 27 We present here a simple access protocol to a "white page" service. This 28 protocol is based on the experience acquired in several X.500 based 29 "white page" pilots, and builds upon such developments as the "user 30 friendly naming" notation or the "centroids" concept developped in the 31 "whois++" project. 33 Although largely inspired by the X.500 protocol, SOLO does not try fol- 34 low the X.500 model. Designing a SOLO front-end to an X.500 server is 35 very easy, but the SOLO internetworking is not based on X.500 -- the 36 navigation part is based on the WHOIS++ centroids. In fact, one can as 37 well design a SOLO front-end to a WHOIS server, and only minor efforts 38 are needed for redesigning a "finger" daemon to provide the SOLO ser- 39 vice. Conversely, the SOLO service is powerful enough to make gatewaying 40 between X.500 access protocols and SOLO easy. 42 The first section of this memo present the basic SOLO protocol. The 43 second section presents the methods which are used for "networking" SOLO 44 servers. The third section is a formal definition of the SOLO protocol. 45 Section 4 list the various SOLO information messages. Section 5 46 addresses the security implications of providing a SOLO service. 48 1. Presentation of the SOLO protocol: 50 The SOLO protocol consists of two main operations: a simple look-up 51 operation that enables clients to request information on a name 52 object, and a "zone transfer" operation used by index handlers. 53 These operations are carried upon TCP-IP connections; the requests 54 and results use a simple text format. Three additional commands are 55 defined, i.e. a "signal" to notify the need to poll a server, a 56 "reset" to abort an ongoing operation, and a "quit" to close the 57 connection. 59 1.1. A basic example: 61 In order to request information on an object, a client will set 62 up a TCP-IP connection towards the server. Servers will be 63 awaiting requests on port . After establishing the 64 connection, the client will send a request of the form: 66 SOLO ? CN, O, OU, Phone, Email; 68 In this line, SOLO is the command name (other commands are for 69 example QUIT or POLL). It is followed by the "name" of the 70 object, which is expressed using the "user friendly name" con- 71 ventions, by a question mark, and by a list of "attribute 72 names", using the acronyms defined for the white page pilot. 74 If the server was able to find the information, it will send a 75 "matched" reply, followed by the values of the attributes, end- 76 ing by a dot on a line by itself, e.g.: 78 500 Matches: 79 CN: Christian Huitema 80 OU: Sophia, Sophia-Antipolis, 81 "Unite de recherche de Sophia Antipolis" 82 O: INRIA, "INSTITUT NATIONAL DE RECHERCHE EN 83 INFORMATIQUE ET AUTOMATIQUE" 84 Phone: +33 93 65 77 77 85 Email: Christian.Huitema@sophia.inria.fr 86 . 88 Indeed, several errors could have occured, for example if the 89 name was ambiguous or non existent, or if the server did not 90 hold the information locally. 92 After receiving the response, the client has the choice to send 93 another command, e.g. to get information on another object, or 94 to close the connection. 96 1.2. Name errors 98 SOLO servers distinguish three kinds of name errors, ambiguous 99 specifications, incorrect specifications and over specifica- 100 tions. They reply to these errors by an appropriate error mes- 101 sage, optionally followed by one or several "hints", i.e. sug- 102 gested references. The following dialogue is an example of 103 ambiguous reference: 105 SOLO ? Phone, Email; 106 201-Ambiguous name: 107 301-Partial Match: 108 400-Suggestion: 109 400 Suggestion: 111 There were several "Martin" at INRIA, and the server just pro- 112 vide the names of all entries that matched the request. The next 113 dialogue is an example of incorrect reference: 115 SOLO ? Email; 116 202-No such name: 117 301-Partial Match : 118 400-Suggestion: 119 400 Suggestion: 121 Note that the server applied here a local strategy to derive 122 possible matches -- it tried a "phonetic" match on the name 123 token "Huttema". Also note the presence in both examples of a 124 "partial match" information line: it signals that the upper com- 125 ponents of the name assertion, in this case , 126 were exactly matched by the server and correspond to the dis- 127 tinguished name . 129 Note that there could be examples where intermediate components 130 are ambiguous, for example: 132 SOLO ? Email; 133 201-Ambiguous name: 134 400-Suggestion: 135 400-Suggestion: 136 400 Suggestion: 138 In that case, the suggestion contains potential candidates for 139 "continuation" queries. The server can use two methods to con- 140 struct the "suggested name", i.e.: 142 (1) replace the "upper part" components of the initial query by 143 a "distinguished" value, 145 (2) provide the "distinguished name" of candidate entries. 147 In the first case, the suggested name is not necessarily a "dis- 148 tinguished" name, but merely a hint that can be used in a 149 further query. 151 Over specification occurs when a requestor present a set of nam- 152 ing attributes, some of which cannot be matched: 154 SOLO ? Email; 155 203-Over specified name: 156 301-Partial Match: 157 400 Suggestion: 159 1.3. Partial name matches and redirections 161 A SOLO server may not always be able to fully match a query. 162 There will be cases however where the local server can provide 163 some "hint" on the resolution of some of the "name parts". For 164 example, a server that knows that the company E3X has recently 165 changed names may be able to respond to a query by a partial 166 match indication: 168 SOLO ? Email; 169 301-Partial Match: 170 400 Suggestion: 172 In the previous exchange, the SOLO server did not provide an 173 indication of where to submit the next query. It could indeed 174 have provided such information through a "suggested server" mes- 175 sage: 177 SOLO ? Email; 178 301-Partial-Match: 179 302-Suggested-server: mitsou.inria.fr 180 302-Suggested-server: osi.e3x.fr 181 400 Suggestion: 182 Note that we have suggested here two different servers. The 183 client will presumably chose one based on local information. 185 1.4. Absolute matches: 187 There are some cases where the SOLO user wants to completely 188 specify the name of the requested object, without leaving any 189 interpretation possibility to the server. This is specified by a 190 particular format of the SOLO request: 192 SOLO ! Email; 194 The differences between this format and a standard request are 195 the following: 197 (1) The name should be fully specified. The separator between 198 the name and the list of attributes is an exclamation mark 199 (!) instead of a question mark (?). 201 The SOLO server can only respond positively to this query if it 202 finds an entry that exactly matches the purported name. 204 1.5. Attributes and Universal Resource Locators (URL) 206 It is often impractical for a server to provide a complete 207 attribute value: some objects like photographies or voice seg- 208 ments are too bulky to be transmitted easily. Others may not be 209 available on the SOLO server itself. In these cases, the SOLO 210 server may elect to return a pointer to the value, in the form 211 of an "Universal Resource Locator", instead of the value itself. 212 The presence of an URL in the value field is signalled by a 213 placing an hyphen in front of the attribute type, as in: 215 SOLO ? Photo, Email; 216 500 Matches: 217 -Photo: "http://zenon.inria.fr:2220/peoples/huitema/photo" 218 Email: Christian.Huitema@sophia.inria.fr 219 . 221 In fact, some clients may want to force this facility, in order 222 to be able to locate an attribute without having to actually 223 receive the data. They can achieve this by prepending an hyphen 224 in front of the attribute type in their request, as in: 226 SOLO ? -Email, -Photo; 227 500 Matches: 228 -Photo: "httl://zenon.inria.fr:2220/peoples/huitema/photo" 229 -Email: "solo://mitsou.inria.fr:8888/!Email" 230 . 232 Note the special form of universal resource locator used for the 233 "Email" attribute: this is the normal way to designate a 234 resource reachable through within a SOLO server. 236 Clients cannot force SOLO servers to return a value instead of 237 the URL: this could be outside of the server's capabilities. 238 However, servers should always return the full attribute value 239 when this is available. 241 1.6. Aliases and alternate values: 243 Some SOLO servers will be implemented as access points to an 244 X.500 service. It is important that the SOLO clients recognize 245 some oddities which can result from the X.500 support of aliases 246 and alternate values, e.g.: 248 SOLO ?Email; 249 500 Name matches: 250 Email: "bolot@mitsou.inria.fr" 251 SOLO ?Email; 252 500 Name matches: 253 Email: "s.mendes@osi.e3x.fr" 254 . 256 In the first case, the first name specification "Jean" was 257 matched by one of the multiple values declared for the first 258 name attribute, although the common name refers to the dis- 259 tinguished value "Jean-Chrysostome". In the second case, the 260 entry for "Suzan Mendes" was an alias, pointing to her real 261 entry in the X.500 server of TS-E3X. 263 In fact, X.500 is probably not the only name service that pro- 264 vides aliasing or alternate names. We are likely to observe the 265 same "oddities" with many data bases. 267 1.7. Filters and substrings: 269 There are cases where the clients will not be able to completely 270 specify the name of the object they are searching. The SOLO pro- 271 tocol allow these clients to enter "loose" specifications by 272 means of substrings or filter. 274 Any name part can be replaced by a substring specification, 275 using the special character "*", as in for example: 277 SOLO ? Email; 278 500 Matches: 279 Email: huitema@sophia.inria.fr 280 . 282 As implied by well established conventions, the "*" can be 283 matched by any sequence of characters. 285 The "User Friendly Name" syntax allows users to combine several 286 "attribute assertions" in a name part, using the "+" character 287 as a delimiter, e.g.: 289 SOLO ? Email; 291 The "+" character is in fact equivalent to an "AND" operator. 292 The SOLO syntax extends this possibility by also allowing the 293 character "|" as an OR operator, e.g.: 295 SOLO ? Email; 297 Which can be matched by either value. Indeed, the "+" and "|" 298 can be combined, in which case "natural" precedence rules apply, 299 i.e. the AND operation takes precedence over the OR. For exam- 300 ple, the previous specification is equivalent to: 302 SOLO ?Email; 304 Experts will note that this notation is more restrictive than 305 the full set of boolean combinations allowed by X.500 filters. 306 This restriction is based on the desire to keep SOLO simple, and 307 also supported by the substantial experience acquired by the 308 authors when deploying X.500 systems. We believe that the pro- 309 posed compromize is just right. 311 Experts will also remember that the "User Friendly Name" specif- 312 ication imposes a restriction on the use of the "+" delimiter: 313 when multiple assertions are stated in a name part, then they 314 should be explicitely typed. This restriction does not apply in 315 SOLO. The following command: 317 SOLO ? Email; 319 is explicitely allowed. 321 1.8. Limiting the size of the output: 323 The filters, the substring notation, or even the use of partial 324 matches, may enable the user to specify extremely fuzzy names. 325 Such fuzzy names can potentially be matched by a very large 326 number of entries. 328 Sending very long lists of "suggested" names is inadequate for 329 several reasons: 331 o it may be a very inefficient use of network resources, 333 o it may impose unexpected constraints to the user interface 334 which is not necessarily rigged to handle long lists, 336 o it may also be a privacy violation, as it would allow 337 intruders to easily obtain complete listings of an 338 organization's personal. 340 SOLO servers are allowed to limit the number of names which can 341 be returned by a single command. A limited set of result will be 342 signaled by a specific error report: 344 SOLO ? Email; 345 201-Ambiguous name: 346 400-Suggestion: 347 400-Suggestion: 348 204 Too many names to list them all. 350 In fact, the privacy argument is so compelling that SOLO servers 351 are encouraged to impose a relatively low limit, e.g. not larger 352 than 8. The precise value of this limit should be set by the 353 local administrator, as well as a policy choice to display a 354 random set of suggested names first and then the error message, 355 or to not display any name at all if the command is too fuzzy. 357 2. Networking white page informations: 359 The SOLO server may want to maintain "indexing" information. This is 360 done according to the "centroid" model. The informations held by a 361 given server are summarized in a centroid, i.e. a gigantic entry 362 that contain for all indexed attribute types the list of attribute 363 values found in any of the data base entries. 365 2.1. Using the index request: 367 In order to obtain the indexing information belonging to a 368 server, a client or another server may set up a TCP connection 369 to the server using the port, then send the index com- 370 mand: 372 POLL S, OU, O, L, C; 374 Where POLL is the command, <> an empty name specification, and 375 where the rest of the command just lists the attributes for 376 which indexing information is required. A typical response will 377 be: 379 501 Sending indexes. 380 S: Name1, Name2, Name3, Name4, 381 name5 382 OU: Unit1, Unit2 383 O: The local org name 384 C: XX 385 . 387 Errors can indeed occur, e.g. if the server is unwilling to send 388 the requested information. 390 A special form of the command allows the clients to obtain the 391 list of attributes managed by the server, i.e. by specifying an 392 empty list of attributes. 394 POLL ; 395 502 Providing attribute list 396 C, L, O, OU, S, G 397 . 399 Indexing servers will keep this information and organize it in 400 tables in order to manage navigation. 402 In some cases, the server may be unwilling to provide a full 403 listing: for example, providing the names of all the employees 404 of a company may be perceived as a serious security violation. 405 In this case, the server may elect to replace the attribute 406 values by a simple "star": 408 POLL S, OU, O, L, C; 409 501 Sending indexes. 410 S: * 411 OU: Unit1, Unit2 412 O: The local org name 413 C: XX 414 . 416 This procedure may also be used when listing all values would be 417 unpractical. 419 2.2. Signalling secondary servers 421 In order to set up or maintain the network of SOLO servers, a 422 POLL command is not sufficient: the index servers have no way to 423 guess that a new server has becomed operational, or that a 424 remote data base has been updated. 426 The SGNL command allows remote servers to "signal" their 427 existence. More precisely, it allows administrators to notify 428 the presence of remote servers, as in: 429 SGNL mitsou.inria.fr 430 403 Will poll: mitsou.inria.fr 432 Where an administrator signalled the need to poll the server 433 "mitsou.inria.fr", and where the index server responded that he 434 scheduled the emission of a POLL command. There can indeed be 435 cases where the server will not schedule this emission, such as: 436 SGNL matso.inrja.fr 437 111 No such host: matso.inrja.fr 439 SGNL felix.inria.fr 440 112 No SOLO server on host: matso.inrja.fr 442 SGNL tom.inria.fr 443 113 Unwilling to poll: matso.inrja.fr 445 Note that this simple "announce message" was prefered to a more 446 radical transaction where the remote server will take the ini- 447 tiative to download its indexing data in the local server for 448 the following reasons: 450 o we want to allow administrators to use a client interface to 451 signal the need to poll. 453 o polling the servers and fetching the data is simpler to 454 organize, as the data are naturally available. 456 o pushing the data to an unprepared index server would be 457 distateful, as the recipient is not necessarily ready to 458 receive. 460 A similar problem was analyzed in the WHOIS++ effort. 462 2.3. Relaying of queries 464 SOLO servers which cannot fully solve a query have two choices. 465 They may simply send back the "partial matches" and/or "sug- 466 gested servers" informations described in section 1. But they 467 may also decide to immediately relay the query towards one or 468 several of the suggested servers. 470 When doing so, the server will forward the query using the SOLO 471 protocol, then send the result back to the user. 473 The server which takes the decision to relay a query may chose 474 one of the possible servers, or try several of them and con- 475 struct a response by merging the various results. Whether one or 476 several server are tested, whether they are tested in parallel 477 or in sequence, and how the answer is constructed is fully a 478 local decision: we do not believe that we have acquired enough 479 experience to write down a mandatory recommendation. However, it 480 is obvious that some indication of the decision, and in particu- 481 lar some indication of the source of the data, should be given 482 back to the user. This is done through a specific information 483 message, indicating the decision to relay, as in the following 484 example: 486 SOLO ? Email; 487 301-Partial-Match: 488 302-Suggested-server: mitsou.inria.fr 489 302-Suggested-server: osi.e3x.fr 490 402-Relaying: mitsou.inria.fr 491 500 Matches: 492 Email: woermann@osi.e3x.fr 493 . 495 The "relaying" information shows the request that was deduced 496 from the original query, as well as the name of the server to 497 which this request was relayed. It is followed by the messages 498 received from the this server. 500 As relayed commands can be further relayed, it is important to 501 include some protection against loops in the protocol. This is 502 achieved by inserting an optional "count of relays" between the 503 SOLO request code and the request itself, as in: 505 SOLO 1 ? Email; 507 SOLO servers should increment the count of relay when relaying a 508 request. They should never relay a request where the count as 509 already reached a value equal to 8, or larger. An absent count 510 is equivalent to a count of zero. 512 2.4. Use of caches: 514 The experience has showed that name queries tend to be repeti- 515 tive, and that a "working set" effect can be efficiently 516 exploited. It is thus highly desirable that servers exploit this 517 working set effect by keeping a cache of the "most frequent" 518 requests. 520 There are three types of information that can be cached by the 521 SOLO: the full or partial name matches, the binding between 522 names and servers, and the attribute values. 524 Full matches are obtained through the "Matches" information 525 lines (code 500). Partial matches are obtained by the similarly 526 named information lines (code 301). In both cases, the cache 527 entry will associate a name request to the matched value. 529 Server suggestions are obtained through the "Suggested-server" 530 lines (code 302). The cache entry will associate a name to one 531 or several suggested servers. 533 Attribute values are obtained as a result of successfull 534 queries. 536 Servers should be careful to time out cache entries after a rea- 537 sonable duration, so as to avoid keeping aged information alive. 538 It is suggested to avoid keeping any cache entry more than a 539 day. 541 2.5. Networking with other technologies: 543 In some cases, SOLO server will be able to determine that the 544 requested object cannot be accessed through the SOLO service, 545 but could be obtained using another technology, e.g. whois, 546 finger or X.500. They can pass this information through the 547 "suggested service" command, e.g.: 549 SOLO ? Phone; 550 301-Partial match: 551 401-S-service: x500://cs.ucl.ac.uk:107/ 552 401 S-service: finger://cs.ucl.ac.uk:79/Baker 554 The end of the code 401 line carries an "universal resource 555 locator". How this information is acquired is outside the scope 556 of this memo. 558 2.6. Stacking multiple requests: 560 The SOLO protocol follows a very simple client/server model. 561 Clients ask questions, and servers reply by a list of informa- 562 tions. In some cases, clients may want to send several requests 563 in one session. They normally do so by sending one question at a 564 time, waiting for an answer, then proceeding to the next ques- 565 tion. 567 Clients may however send further commands on the TCP connection 568 without waiting for the answer to the previous one. 570 3. Protocol specification: 572 3.1. The format of a request: 574 All requests of the SOLO protocol start by a four letter request 575 code, e.g. SOLO, POLL, SGNL, RSET, QUIT. The codes can be 576 expressed in upper or lower cases, or a combination of both. 578 In the case of the SOLO request, the command includes: 580 (1) a variable number of spacing characters (spaces or tabs). 582 (2) an optional "count of relays" indicator, encoded using one 583 decimal digit, followed if present by a variable number of 584 spacing characters. 586 (3) the name of the requested object, enclosed within angle 587 brackets. 589 (4) a variable number of spacing characters (spaces or tabs). 591 (5) a precision specifier, which can be either a question mark 592 (?) or an exclamation mark (!). 594 (6) a list of attributes, terminated by a semicolon (;). 596 In the case of the POLL request, the command includes: 598 (1) a variable number of spacing characters (spaces or tabs). 600 (2) a list of attributes, terminated by a semicolon (;). lp In 601 the case of the SGNL request, the command includes: 603 (3) a variable number of spacing characters (spaces or tabs). 605 (4) the domain name of the server that should be polled. 607 The RSET and QUIT request don't contain any information after 608 the command code. 610 All commands are terminated by an "end of line" mark, composed 611 of the two characters "carriage return" and "line feed". 613 3.2. The format of the replies: 615 The replies sent by the SOLO servers are always composed of one 616 of several information lines, followed in some cases by a data 617 line. 619 The information lines are always composed of: 621 (1) A three digit information code, 623 (2) A continuation character, i.e. a space character if this is 624 the last information line or an hyphen otherwise, 626 (3) A free form text composed of letters, white spaces and 627 digits. 629 If the line does not contain additional information, the free 630 form text is terminated by a dot(.). If it contains additional 631 information, the free text is followed by a semi-colon (:) and 632 the information. This information is composed of a name specifi- 633 cation enclosed in angle brackets, optionally followed by 634 another name enclosed in angle brackets, for partial match 635 reports, or the domain name of a suggested server. In one case 636 (code 401), the information is composed of an "universal 637 resource locator"; in a few other (111, 112, 113, 403), the 638 information consists solely of a "domain name". 640 All information lines are terminated by an "end of line" mark, 641 composed of the two characters "carriage return" and "line 642 feed". 644 When the first digit of the last information line has the value 645 "5", this line is followed by a list of attribute values. 647 3.3. Format of name specifications: 649 Name specifications occur in the SOLO request and in several 650 error messages. Names are formatted according to the rules 651 specified in RFC-1485 (string representation of distinguished 652 names)... 654 3.4. Format of attribute lists: 656 Attribute lists are present in the SOLO and POLL requests. 657 Attribute lists are composed of attribute names separated by 658 commas (,). An arbitrary number of spacing characters (space, 659 tab) can be inserted around the attribute names. The attribute 660 list is always terminated by a semi-colon. An attribute list may 661 be empty. 663 The attribute type can be preceded by an hyphen to indicate, 664 within the POLL command, that pointers (URL) are requested 665 instead of values. 667 3.5. List of attribute values: 669 A list of attribute values is composed of several attribute 670 values. Each attribute value is encoded of one or several lines 671 of texts; all lines of text are terminated by a carriage return 672 and a line feed. The list is terminated by a line containing a 673 single dot character. The list may be empty, i.e. it may be the 674 case that the dot line is the only line in it. 676 The first line of an attribute value starts by the encoding of 677 the attribute type, followed by a colon. All other lines should 678 start by one or several spacing characters (space or tab). Each 679 line contains one or several values, encoded according to the 680 rules specified in RFC-1488 (String representation of standard 681 attribute syntaxes), and separated from the following value by a 682 comma and an arbitrary number of linear spaces. 684 Within the values returned by the POLL command, the attribute 685 type can be optionally preceded by an hyphen. In this case, the 686 values returned are universal resource locators, instead of 687 actual values. 689 3.6. Attribute names: 691 Attribute names are encountered in name specifications, in 692 attribute lists and in attribute values. 694 The attribute names can be: 696 o simple keywords, as defined in RFC-1488 (String representa- 697 tion of standard attribute syntaxes) or in the Whois++ 698 lookup service. 700 o text renditions of object identifiers. 702 Official keywords should be prefered whenever possible. The fol- 703 lowing table list a set of key words which are expected to be 704 recognized by SOLO servers, as well as their WHOIS and "User 705 Friendly Name" equivalents: 707 ________________________________________________ 708 | Whois (RFC-1274) | RFC-1485 | SOLO | 709 |_______________________|____________|__________| 710 | Name (CommonName) | CN | CN | 711 | (Surname) | S | S | 712 | (First name) | | First | 713 | (Country) | C | C | 714 | (StateOrProvinceName) | ST | ST | 715 | (LocalityName) | L | L | 716 | Organization | O | O | 717 | Department | OU | O | 718 | Title | | Title | 719 | Work-telephone | | Phone | 720 | Fax-telephone | | Fax | 721 | Work-address | | Address| 722 | Email-address (RFC822)| | Email | 723 |_______________________|____________|__________| 725 The "First" keyword is derived from the "first" command line 726 argument to "whois"; the "Phone", "Fax" and "Email" 727 simplications come from the wide usage of these arguments and 728 the desire to focus on "business" attribute by default (see the 729 "security" section for a rationale). The corresponding "object 730 identifiers" can be found in RFC-1274 (X.500 directory schema). 732 3.7. Values: 734 Values are encoutered in name specifications and in value lists. 736 There are three possible encodings for a value: 738 o a set of printable characters, excluding any occurence of 739 the special characters comma(,), colon(:), equal(=), semi- 740 colon(;) question mark (?) and of the angle brackets (< and 741 >). In this syntax, multiple occurence of white spaces can 742 be replaced by a single white space. 744 o a quoted string, optionally preceded by an alphabet nota- 745 tion, and delimited by double quotes. In this case, the MIME 746 "quoted text" format is used. 748 o a binary string, encoded as defined in the "base64" nota- 749 tion, and delimited by simple quotes. 751 Only the first two formats can be used within the command line. 752 When the value is an universal resource locator, use of the 753 quoted text notation is encouraged. 755 4. A list of information codes: 757 Information codes fall within 5 categories: 759 (1) System errors are numbered from 100 to 199. 761 (2) Name errors are numbered from 200 to 299. 763 (3) Intermediate informations are numbered from 300 to 399. 765 (4) User informations are numbered from 400 to 499. 767 (5) Completion reports are numbered from 500 to 599. 769 4.1. System errors 771 System errors indicate that the query could not be further pro- 772 cessed. The following errors have been defined: 774 ________________________________________________________ 775 | 100| Unrecognized command | | 776 | 101| Incorrect name specification | | 777 | 102| Incorrect attribute list | | 778 | 103| Incorrect command parameters | | 779 | 104| Momentary congestion, try later | | 780 | 105| Server problem | | 781 | 106| Data base problem | | 782 | 107| Timing out after relaying | | 783 | 108| Abandoning the request | | 784 | 110| Too many relays, probably looping| | 785 | 111| No such host | domain-name| 786 | 112| No SOLO server on host | domain-name| 787 | 113| Unwilling to poll | domain-name| 788 |____|___________________________________|______________| 790 4.2. Name errors 792 Name errors occurs when the name specification is invalid. The 793 following errors have been defined: 795 _________________________________________________ 796 | 201| Ambiguous name | | 797 | 202| No such name | | 798 | 203| Over specified name | | 799 | 204| Too many names to list them all| | 800 |____|_________________________________|_________| 802 4.3. Intermediate informations 804 Intermediate informations are informations that can be "cached" 805 by the server. The following codes are defined: 807 ______________________________________________ 808 | 301| Partial Match | | 809 | 302| Suggested-server| domain-name| 810 |____|__________________|_____________________| 812 4.4. User informations 814 User informations are suggestions that can be passed to the 815 user. The following codes have been defined: 817 ________________________________________ 818 | 400| Suggestion| | 819 | 401| S-service | URL | 820 | 402| Relaying | domain-name| 821 | 403| Will poll | domain-name | 822 |____|____________|_____________________| 824 4.5. Completion reports 826 Completion reports precede a list of attribute values. Two 827 reports are defined: 829 ________________________________ 830 | 500| Matches | | 831 | 501| Sending indexes| | 832 |____|_________________|________| 834 5. Security considerations: 836 The SOLO protocol is designed to widely publicize information about 837 people, e.g. telephone numbers or electronic mail addresses. As 838 such, the most important considerations relate to the protection of 839 personal privacy: notification and filtering, listing and browsing. 840 Then, one finds the classical problem of "name server" attacks. The 841 attention of the administrators is also drawn onto the particular 842 problem of embedding login information into mail addresses. 844 5.1. Notification and removal 846 In several countries, the privacy protection laws require that 847 users be notified of their listing in any data base containing 848 personal information; in some countries, one has to sollicit 849 their explicit agreement before listing their informations. The 850 matter is only made worse by the international nature of the 851 Internet: information placed in a connected data base should be 852 considered as publicized on a world wide basis. 854 Even when the local laws do not require it, it is good practice 855 to observe the following guidelines: 857 o Notify people listed in the SOLO server that you are pub- 858 lishing their personal information, 860 o Be ready to remove some people from their data bases. There 861 are a number of people who may have good reasons not to be 862 listed at all. 864 o Don't publish more data than necessary. We clearly need to 865 list identification data such as first names or surnames, 866 and there are very good reasons for listing an email 867 address, a fax number or an office phone number. But one 868 should clearly think twice before listing a home address or 869 the list of ongoing projects... 871 Local regulations may impose stronger protections. These regula- 872 tions should indeed be followed. 874 5.2. Listing and browsing 876 Practicians of the "privacy laws" are adamant against the risks 877 posed by "remote listing" procedures. When available without 878 restriction, services such as the X.500 "LIST" operation allow 879 complete foreigners to copy a data base and use it for "innova- 880 tive" purposes, e.g. correlate it with another base, or use it 881 as the start of a "mailing" operation. 883 We have seen in the section on "limiting the size of the output" 884 the need to limit the number of names returned by the "SOLO" 885 command. A similar risk is posed by the "POLL" command, as: 886 POLL CN; 888 would allow to list the names of all the person present in the 889 data base. In the absence of secure communications, if the 890 remote party cannot be precisely identified, administrators of 891 the SOLO service would be well inspired to limit the set of 892 attributes returned by the POLL command to only those that iden- 893 tify the organization, e.g. Organization name, Unit name, Coun- 894 try, Region and City. The "CN=*" facility should be used instead 895 of returning a full listing of names. 897 5.3. The name server attacks 899 The SOLO service will be used to store communication data, e.g. 900 phone numbers or electronic mail addresses. There is a classic 901 attack against this service, in which an intruder "emulates" a 902 server and return forged addresses, so that he or an accumplice 903 receives the information that was meant to be sent to a third 904 party. 906 X.500 protects clients against this attack by "strongly authen- 907 ticating" request and responses, so that there is no way to emu- 908 late a server or to alter the information. SOLO does not include 909 strong authentication. Two alternate methods could be used: 911 (1) Run SOLO on top of a secure network, e.g. using IP security. 913 (2) Protect the data themselves, e.g. have them signed and 914 scealed, as e.g. PEM certificates. 916 One should note that the second alternative is the only one that 917 maintain the protection even when caches are used. 919 5.4. Logins and addresses 921 Email addresses are often build as a combination of a host name 922 and a login name or account number. It is well known that expos- 923 ing these combinations facilitates the task of intruders -- they 924 only have to "guess a password" instead of having to guess both 925 an account number and a password. This problem is however not 926 specific to SOLO. Any other white page service or any message 927 sent to a wide distribution list would also publicize the infor- 928 mation. 930 6. Acknowledgments: 932 We would like to thank the members of the IETF "directory service" 933 working groups and the participant to OPAX, PARADISE and various 934 other white page pilots for their encouragements. The use of URLs 935 was suggested by Marshall Rose in a discussion on the "future of 936 X.500", and was also discussed in the RARE "WG-NAP" working group. 937 The members of the RARE WG-NAP initiated the analysis of the privacy 938 requirements which is reported in the "security" section. Several 939 members of the INRIA and TS-E3X teams reviewed the draft. Also, we 940 would like to pay tribute to the member of the WNILS working group, 941 as we shamelessly copied the "centroid" concept which was developped 942 for the WHOIS++ service. 944 7. References: 946 (1) Gargano, Joan, Weiss, Ken. Whois and Network Information Lookup 947 Service, Whois++. RFC in preparation. 949 (2) Weider, Chris, Fulton, Jim, Spero, Simon. Architecture of the 950 Whois++ Index Service. RFC in preparation. 952 (3) Howes, T. , Kille, S., Yeong, W., Robbins, C. The X.500 String 953 Representation of Standard Attribute Syntaxes. RFC-1488. 955 (4) Kille, Steve, Using the OSI Directory to achieve User Friendly 956 Naming. RFC-1484. July 1993. 958 (5) Kille, Steve, A String Representation of Distinguished Names. 959 RFC-1485. July 1993. 961 (6) CCITT. X.500 series of recommendations. 1988. 963 (7) Barker, Paul, Kille, Steve, The COSINE and Internet X.500 964 Schema. RFC-1274. November 1991. 966 8. Authors' Addresses 968 Comments should be sent to: 970 Christian Huitema 971 INRIA 972 2004 Route des Lucioles 973 BP 93 974 06902 Sophia-Antipolis Cedex 975 France 977 Email: Christian.Huitema@sophia.inria.fr 979 Paul-Andre Pays 980 INRIA 981 BP105 982 78153 Le Chesnay Cedex 983 France 985 Email: Paul-Andre.Pays@faugeres.inria.fr 987 Alain Zahm, Ascan Woermann 988 TS-E3X Groupe France Telecom, 989 Les Algorithmes, 990 Route des Lucioles, 991 Bat. Pythagore A 992 06560 Valbonne France 994 Email: zahm@osi.e3x.fr, Woermann@osi.e3x.fr 996 Table of Contents 998 Status of this Memo .............................................. 1 999 Abstract ......................................................... 2 1000 1 Presentation of the SOLO protocol: .............................. 2 1001 1.1 A basic example: .............................................. 2 1002 1.2 Name errors ................................................... 3 1003 1.3 Partial name matches and redirections ......................... 5 1004 1.4 Absolute matches: ............................................. 6 1005 1.5 Attributes and Universal Resource Locators (URL) .............. 6 1006 1.6 Aliases and alternate values: ................................. 7 1007 1.7 Filters and substrings: ....................................... 8 1008 1.8 Limiting the size of the output: .............................. 9 1009 2 Networking white page informations: ............................. 10 1010 2.1 Using the index request: ...................................... 10 1011 2.2 Signalling secondary servers .................................. 12 1012 2.3 Relaying of queries ........................................... 13 1013 2.4 Use of caches: ................................................ 14 1014 2.5 Networking with other technologies: ........................... 15 1015 2.6 Stacking multiple requests: ................................... 15 1016 3 Protocol specification: ......................................... 15 1017 3.1 The format of a request: ...................................... 15 1018 3.2 The format of the replies: .................................... 17 1019 3.3 Format of name specifications: ................................ 17 1020 3.4 Format of attribute lists: .................................... 18 1021 3.5 List of attribute values: ..................................... 18 1022 3.6 Attribute names: .............................................. 19 1023 3.7 Values: ....................................................... 20 1024 4 A list of information codes: .................................... 20 1025 4.1 System errors ................................................. 21 1026 4.2 Name errors ................................................... 22 1027 4.3 Intermediate informations ..................................... 22 1028 4.4 User informations ............................................. 22 1029 4.5 Completion reports ............................................ 23 1030 5 Security considerations: ........................................ 23 1031 5.1 Notification and removal ...................................... 23 1032 5.2 Listing and browsing .......................................... 24 1033 5.3 The name server attacks ....................................... 25 1034 5.4 Logins and addresses .......................................... 25 1035 6 Acknowledgments: ................................................ 25 1036 7 References: ..................................................... 26 1037 8 Authors' Addresses .............................................. 27