idnits 2.17.1 draft-ietf-find-ldapc-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-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 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 184 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '...listing conta...' -- 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 (8 February 1997) is 9936 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 section? 'CIP' on line 704 looks like a reference -- Missing reference section? 'LDAP' on line 706 looks like a reference -- Missing reference section? 'LDIF' on line 708 looks like a reference -- Missing reference section? 'Fortezza' on line 710 looks like a reference -- Missing reference section? 'UTF8' on line 712 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT Critical Angle Inc. 3 Expires in six months from 8 February 1997 5 A CIP-based Centroid Exchange for LDAP 6 draft-ietf-find-ldapc-00.txt 8 Status of this Memo 10 This document is an Internet Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 Please note that this document reflects experimental software, and is 26 incomplete. The underlying specification is likely to change slightly. 28 Abstract 30 This document describes how an LDAP server (the supplier) may transmit, 31 through an out-of-band email, index information or attributes of its 32 naming context to another LDAP server (the consumer). The consumer 33 server will make use of this information when determining whether the 34 supplier server is likely to have entries in that naming context which 35 match a particular search filter. This assists the consumer in 36 processing subtree searches in distributed directories. 38 1. Goals 40 The primary goal of this specification is to allow an LDAP-capable 41 server with a large number of subordinate references to more efficiently 42 perform a subtree search operation, without having to chain or refer 43 sub-operations for each subordinate reference. 45 Secondary goals of this specification are: 47 - allow servers to efficiently handle all shapes of search filters in 48 common use, even distressful searches like 50 (|(cn=joe bloggs)(sn=joe bloggs)(uid=joe bloggs) 51 (cn=*joe bloggs*)(sn=*joe bloggs*)(uid=*joe bloggs*) 52 (cn~=joe bloggs)(sn~=joe bloggs)(uid~=joe bloggs)) 54 - not require any modifications to the internals of servers holding 55 subordinate contexts; 56 - allow the organizations which maintain these contexts to control bulk 57 retrieval of the data, and to schedule when it may be retrieved; 59 - ensure that it is possible to protect against unauthorized disclosure of 60 bulk directory data while in transit, and provide some protection 61 against spoofing attacks. 63 The following are NON-goals of this version of the specification: 65 - exchange of index information without prior agreement (e.g. trawling); 67 - negotiation of agreements (separate document for this); 69 - updates of non-complete naming contexts; 71 - allowing the consumer to poll for updates; 73 - alias entries and/or non-hierarchical models; 75 - representation of access control or transfer of 76 non-publically-accessible attributes. 78 2. Introduction 80 This document defines a centroid-based index for a subtree of the 81 directory. It is carried by an update MIME object. 83 The supplier server is an LDAP server which masters or shadows a naming 84 context. In this protocol it acts as a "simple CIP leaf server". 86 The supplier server will at intervals mail the update to the consumer 87 server. The consumer server is a different LDAP server with a subordinate 88 or cross reference to the supplier server, which makes use of this update 89 to determine how to route queries. 91 The centroid-based index consists of processed attribute values from 92 entries. The supplier may send the complete attribute values, or if this 93 would violate data protection laws, only approximate match codes of values, 94 which are nonreversible. As more processing is performed on values, the 95 size of the index is reduced, as is its usefulness to the consumer. 97 The specification allows for both total and incremental updates to be sent. 99 This specification is intended for "push" environments, where there are many 100 (tens of thousands) of naming contexts, and a small number (dozens) of 101 index consumers. The naming contexts are as a whole static, however it is 102 desirable or changes to take effect rapidly. 104 (If the consumer were instead to start one poll per second to cover 100,000 105 suppliers, then if a person moved from one naming context to another, in 106 the worst case the index information would be out of date for more than a 107 day, making that person unlocatable.) 108 Thus it is not intended to represent index information in the directory 109 itself. The index information is expected to be of interest to only a 110 very small portion of users of the directory, and for legal reasons should 111 only be visible to authorized servers. Furthermore the size of the index 112 information is often proportional to the size of the rest of the DIT. 114 3. Agreement 116 An agreement is established between the organization which administers the 117 supplier and the organization which administers the consumer, which 118 specifies how the servers will communicate. The agreement contains the 119 following: 121 - "version": The version of the agreement and the index type. This 122 specification describes the index type "x-ldap-centroid-1". 124 - "baseobject": The Distinguished Name of the prefix entry of the 125 supplier's subtree. 127 - "scope": The subset of information in the supplier's subtree for 128 which the update information will index. For this version of the 129 specification, the scope is always "subtree": the base object and all 130 entries down to the leaves of the tree, including any subordinate naming 131 contexts. 133 - "dsi": An OID which uniquely identifies the subtree and scope. 135 - "supplier": The hostname and listening LDAP port number of the 136 supplier server, as well as any alternative servers holding that same 137 naming contexts, in case the supplier is unavailable. 139 - "consumeraddr": This is a URI of the "mailto:" form, with the RFC 140 822 email address of the consumer server. Subsequent versions of the 141 specification may allow other forms of URI, so that the consumer may 142 retrieve the update via the WWW, FTP or a Common Indexing Protocol. 144 - "updateinterval": The maximum duration in seconds between occurances of 145 the supplier server generating an update. If the consumer server has 146 not received an update from the supplier server after waiting this 147 long since the previous update, it is likely that the index 148 information is now out of date. 150 A typical value for a server with frequent updates would be 604800 151 seconds, or every week. Servers whose DITs are only modified annually 152 could have a much longer update interval. 154 - "securityoption": Whether and how the supplier server should sign and 155 encrypt the update before sending it to the consumer server. Options 156 for this version of the specification are 158 "none": the update is sent in plaintext 159 "PGP/MIME": the update is digitally signed and encrypted using PGP 160 "Fortezza": the update is digitally signed and encrypted using Fortezza 161 It is recommended that the "PGP/MIME" option be used when exchanging 162 sensitive information across public networks, and both the supplier and 163 consumer have PGP keys. The "Fortezza" option is intended for use in 164 environments where security protocols are based on Fortezza-compatible 165 devices. 167 - Security Credentials: The long-term cryptographic credentials used for 168 key exchange and authentication of the consumer and supplier servers, if 169 a security option was selected. For "PGP/MIME", this will be the trusted 170 public keys of both servers. For "Fortezza", this will be the 171 certificate paths of both servers to a common point of trust. 173 4. Content Type 175 The update consists of a MIME object of type application/cip-index-object. 177 The parameters are: 178 - "type": this has value "x-ldap-centroid-1". 180 - "dsi": the DSI from the agreement. 182 - "base-uri". A set of URIs, each of the "ldap:" form, separated by spaces. 183 In each URI, the hostname/portno must be distinct, and based on the 184 "supplier" part of the agreement. Each URI must have on the RHS the 185 base object distinguished name. 187 The payload is mostly textual data but may include bytes with the high bit 188 set. The quoted-printable content-transfer-encoding is recommend to be 189 used if there are any bytes with the high bit set, otherwise no transfer 190 encoding is needed. 192 This object may be encapsulated in a wrapper content (such as 193 multipart/signed) or be encrypted as part of the security procedures. 194 The resulting content will in this version of the specification be emailed. 196 For example, an email without any security transformations may resemble: 198 From: supplier@sup.com 199 Date: Thu, 16 Jan 1997 13:50:37 -0500 200 Message-Id: <199701161850.NAA29295@sup.com> 201 To: consumer@consumer.com <<-- from consumer server address 202 Reply-To: supplier-admin@sup.com 203 MIME-Version: 1.0 204 Content-Type: application/cip-index-object; type=x-ldap-centroid-1; 205 dsi=1.3.6.1.4.1.1466.85.85.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16; 206 base-uri="ldap://sup.com/dc=sup,dc=com ldap://alt.com/dc=sup,dc=com" 208 ...payload here... 210 The payload is series of CRLF-terminated lines. Each line is in the UTF-8 211 encoding of the Unicode (ISO-10646 BMP) character set. No other character 212 sets are permitted by this version of the specification. Some supplier 213 servers may only be able to generate the printable US-ASCII subset, 214 but all consumer servers must be able to handle the full range of Unicode 215 characters. 217 The "x-ldap-centroid-1" index payload begins with a header section, which 218 is followed by one or more attribute sections. Each section is separated 219 from the others by a blank line. Multiple blank lines together are 220 treated the same as a single blank line. 222 Lines which begin with a '#' character are ignored. 224 4.1. Header Section 226 The header section consists of one or more lines in "type:value" format. 228 The following types are defined: 230 - "version": This line must always be present, and have the value "1" for 231 this version of the specification. 233 - "updatetype": This line must always be present. It takes as the value 234 either "total" or "incremental". The first update sent by 235 a supplier server to a consumer server for a DSI must be a "total" 236 update. 238 - "thisupdate": This line must always be present. The value is an ASN.1 239 GeneralizedTime in UTC (Z suffix) of the time at which the supplier 240 constructed this update. 242 - "lastupdate": This line must be present if the "updatetype" list has the 243 value "incremental". It is an ASN.1 GeneralizedTime in UTC (Zulu), 244 which is the value of the "thisupdate" of previous update sent to the 245 consumer. 247 - "contextsize": This line may be present at the supplier's option. The 248 value is a number, which is the approximate total number of entries in 249 the subtree. This information is provided for statistical purposes only. 251 - "attributetypes": This line may be present any number of times with 252 distinct values at the supplier's option. The value is the string 253 encoding of an LDAP AttributeTypeDescription. This allows the supplier 254 to include privately defined or nonstandard attributes in the update. 256 The supplier generally should not include in the header 258 - descriptions of attribute types defined in X.500 or RFC 1274, 260 - descriptions of attribute types for which it will not be including 261 index information (other than presence), 263 - descriptions of attribute types with privately-defined syntaxes, 265 - descriptions of attribute types whose syntax is "DirectoryString" or 266 "IA5String" and matching rule is "caseIgnoreMatch" or 267 "caseIgnoreIA5Match". 269 For each attribute description the supplier provides, the syntax and 270 equality rule names must be included. 272 The consumer may wish to make use of the oid, name, syntax and equality 273 fields when processing queries using the information from the update. 274 If the consumer does not recognize an attribute type in the update, and 275 it is not defined in this header, the consumer must treat it as having 276 an unknown oid, DirectoryString syntax, and caseIgnoreMatch equality 277 matching. 279 - "chopbefore": This line may be present any number of times with distinct 280 values at the supplier's option. The value is a Distinguished Name in 281 LDAP format. The entry with this name and all its subordinates have 282 been excluded from the generation of the index information. Typically 283 the entry will be a context prefix or an administrative point. 285 Note: It is assumed that either the consumer will establish a separate 286 agreement to cover each excluded area, or these areas are to be ignored 287 during searching. 289 - "chopafter": Similar to the "chopbefore" option, except that the index 290 information does include the attributes of this entry, but not its 291 subordinates. (E.g. the subordinate entries are held in a QUIPU DSA.) 293 An example header would be: 295 version: 1 296 updatetype: total 297 thisupdate: 199701121341Z 299 4.2. Attribute Sections 301 This section is present any number of times following the header in an 302 x-ldap-centroid-1 index object. Each section is separated from the others 303 by a blank line. 305 Each section corresponds to one attribute type. 307 The first line of the section consists of three parts separated by colons: 308 the attribute type name, the match form, and the tokenization rule. 310 The match form is one of the following: 311 - equality: the tokens correspond to values of that attribute present in 312 entries in the subtree. 314 - approx: the tokens correspond to approximate match codes of all values of 315 that attribute present in entries in the subtree. The attribute 316 must be of the DirectoryString or IA5String syntax. 318 - presence: the token indicates whether there is at least one value of that 319 attribute present in any entry in the subtree. 321 The supplier should use the equality match form for attributes whose values 322 are DirectoryString, IA5String or OID, are useful for filtering, and the 323 supplier is willing to disclose to the consumer. If the supplier is not 324 willing to disclose the values, the supplier should use the approx match 325 form. For all other attributes on which the supplier permits 326 searching, but would not be useful to include in a centroid (because they 327 are large, binary or do not compress well), the presence match form should 328 be used. 330 Tokenization rules define the transformation from attribute values to 331 tokens. 333 The "flat" tokenization rule is always applied. First, the attribute value 334 is converted to an LDAP string. Non-string values (e.g. photo and audio) 335 are discarded. Leading and trailing spaces are removed. Multiple 336 consecutive spaces and non-printing characters are replaced by a single 337 space. Lower case ASCII letters are converted to upper case. ASCII 338 characters 0-31 and 127 are removed. 340 If the match form is "approx", the "soundex" rule is also applied. Each 341 word (separated by spaces) is replaced by its SOUNDEX code and becomes its 342 own token. 344 If the match form is "presence", the "presence" rule is applied. It 345 generates only one token: "*" if there is any value. 347 If a character "#", "-", "+", ";" or "\" occurs in the token, each is 348 preceded by a "\" character. 350 The supplier may append modifiers to each token. Modifiers are separated 351 from the tokens (and each other) by a semicolon. 353 One modifier is described here: 355 ;ec=: An approximate count of the number of entries in which 356 this token occurs. 358 Modifiers are optional and consumers may choose to ignore them. 360 If the "updatetype" is "total", each of the lines in the section after the 361 first is one token. The order of lines is unimportant. 363 If the "updatetype" is "incremental", each of the lines starts with either a 364 "+" or a "-" character, indicating that the token should be added or removed 365 from the tokens of this attribute. Lines must be processed in the order 366 they occur. Modifiers on a "-" token are ignored. 368 For example, if the subtree contained: 370 dn:dc=sup,dc=com 371 objectclass:top 372 objectclass:domain 373 dc:sup 375 dn:cn=Joe Bloggs,dc=sup,dc=com 376 objectclass:top 377 objectclass:person 378 objectclass:strongAuthenticationUser 379 cn:Joe Bloggs 380 cn:Joseph Bloggs 381 sn:Bloggs 382 userCertificate;binary::0281... 384 dn:cn=Mary Bloggs,dc=sup,dc=com 385 objectclass:top 386 objectclass:person 387 cn:Mary Bloggs 388 sn:Bloggs 390 And the supplier generated equality match form for "sn", "objectclass" and 391 "description", approximate match form with soundex for "cn", and presence 392 match form for "userCertificate;binary", the payload might resemble: 394 version:1 395 updatetype: total 396 thisupdate: 199701121341Z 398 sn:equality:flat 399 BLOGGS;ec=2 401 objectclass:equality:flat 402 TOP;ec=3 403 DOMAIN;ec=1 404 PERSON;ec=2 405 STRONGAUTHENTICATIONUSER;ec=1 407 description:equality:flat 409 cn:approx:soundex 410 J2;ec=1 411 J3;ec=1 -- these are not the right codes 412 B256;ec=1 414 userCertificate;binary:presence:presence 415 *;ec=1 417 If the subtree was subsequently modified to add a value to an entry 418 description: seldom seen 419 Then the next update might resemble 421 version:1 422 updatetype: incremental 423 thisupdate: 199701131339Z 424 lastupdate: 199701121341Z 426 description:equality:flat 427 +SELDOM SEEN;ec=1 429 5. Aggregation 431 Aggregation may be performed to combine a index of a naming context with 432 indices of ALL subordinate naming contexts. It cannot be usefully 433 performed if there is missing index information for one or more 434 subordinates. 436 When combining centroids, if an attribute centroid is provided by one index 437 but not by any others, the attribute may be replaced by a presence index. 439 Chopafter and chopbefore lists are merged. 441 The base URIs are changed to point to the aggregating server and its 442 alternatives. 444 The DSI is distinct from that of any subordinate naming context's DSIs. 446 If all subordinate indexes included a contextsize header, then the 447 aggregate may also have a contextsize header. 449 For example, suppose a server holds a naming context C=US with the 450 following entry: 452 dn:c=US 453 objectclass: top 454 objectclass: country 455 c: US 457 It has two subordinate references "o=Foo,c=US" and "o=Bar,c=US". 459 It consumes an x-ldap-centroid-1 from the Foo supplier: 461 version: 1 462 updatetype: total 463 thisupdate: 199701131339Z 465 objectclass:equality:flat 466 TOP;ec=2 467 ORGANIZATION;ec=1 468 PERSON;ec=1 470 o:equality:flat 471 FOO;ec=1 473 cn:equality:flat 474 SHARON META;ec=1 476 sn:equality:flat 477 META;ec=1 479 And an x-ldap-centroid-1 from the Bar supplier: 481 version: 1 482 updatetype: total 483 thisupdate: 199701131339Z 485 o:equality:flat 486 BAR;ec=1 488 cn:equality:flat 489 JEFF RUSSELL;ec=1 490 JEFFREY RUSSELL;ec=1 491 PENELOPE JONES;ec=1 493 sn:equality:flat 494 RUSSELL;ec=1 495 JONES;ec=1 497 uid:approx:soundex 498 J311;ec=1 499 J12;ec=1 501 objectclass:equality:flat 502 TOP;ec=3 503 ORGANIZATION;ec=1 504 PERSON;ec=2 505 BARSPECIFICPERSON;ec=2 507 To aggregate, it first converts its own entry into a centroid. 509 Since the server can determine that it is the only centroid without an 510 o attribute, it can create an "o:equality:flat" section for itself with no 511 values. This will prevent the o attribute information from being lost. 513 Only the Bar server sent the uid attribute. Since the Foo server did not 514 include a "uid" attribute, the server derives that are no uid values for 515 the Foo server. 517 It then merges the o,cn,sn,uid and objectclass sections, to build the 518 resulting centroid. 520 version: 1 521 completeness: index 523 o:equality:flat 524 FOO;ec=1 525 BAR;ec=1 527 cn:equality:flat 528 SHARON META;ec=1 529 JEFF RUSSELL;ec=1 530 JEFFREY RUSSELL;ec=1 531 PENELOPE JONES;ec=1 533 sn:equality:flat 534 META;ec=1 535 RUSSELL;ec=1 536 JONES;ec=1 538 uid:approx:soundex 539 J311;ec=1 540 J12;ec=1 542 objectclass:equality:flat 543 TOP;ec=6 544 ORGANIZATION;ec=2 545 PERSON;ec=3 546 BARSPECIFICPERSON;ec=2 547 COUNTRY;ec=1 549 Finally, the server generates a new DSI. It can transfer this object to 550 other servers as the index for C=US and all subordinates. 552 6. Use of Index Objects in the Consumer 554 This procedure is followed for each data set held by the consumer LDAP 555 server, when a search operation is to be performed that includes the subtree 556 in its scope. 558 Index information is not used during bind password validation or comparison 559 operations. 561 If the target object of the search is below the subtree prefix, 562 then the operation is chained or referred to the supplier (or processed 563 with a shadow copy), regardless of the contents of the index information. 565 7. Filter Evaluation 567 If the base object of a search is superior to the subtree prefix, the index 568 information is used as to make a routing decision. 570 The consumer will evaluate the client's search filter. The result will be 571 one of the following outcomes: 573 - LIKELY: there is a good possibility that there is at least one matching 574 entry in the naming context. 576 - POSSIBLE: there may or may not be any matching entries in the naming 577 context. 579 - UNLIKELY: the only matching entries would be those which were modified or 580 added to the naming context subsequently to the index information being 581 generated. 583 - UNINDEXED: the supplying server will likely not have any matching entries 584 as it does not allow searching on one or more attribute types referenced 585 in the filter. This occurs if any of the attributes in the search filter 586 are not represented in the centroid. 588 The consumer server should first chain or return referrals for subordinate 589 naming contexts in which the evaluation returned LIKELY. If the time and 590 size limits permit, the server should then chain or return referrals for 591 subordinate naming contexts in which the evaluation returned POSSIBLE. The 592 server should ignore subordinate contexts which were UNLIKELY or UNINDEXED. 594 Generated referrals will be URIs of the LDAP form, in which the base object 595 is the name of the naming context and the scope is subtree. There may be 596 mulitple URIs in a referral, if there are alternate servers for this 597 naming context. 599 7.1. "and" filter 601 Evaluate each of the component filters. 602 If any filter returned "UNLIKELY", return "UNLIKELY". 603 If any filter returned "POSSIBLE", return "POSSIBLE". 604 Otherwise all filters returned "LIKELY", so return "LIKELY". 606 7.2. "or" filter 608 Evaluate each of the component filters. 609 If all filters returned "UNLIKELY", return "UNLIKELY". 610 If all filters returned "LIKELY", return "LIKELY". 611 Otherwise return "POSSIBLE". 613 7.3. "equalityMatch" filter 615 If there is an attribute section for the presented attribute type of the 616 equality match form, then tokenize the presented value and compare. If the 617 presented value matches, return "LIKELY", otherwise return "UNLIKELY". 619 If there is an attribute section for the presented attribute type of the 620 approx match form, then tokenize the presented value and compare. If the 621 approximated presented value matches, return "POSSIBLE", otherwise 622 return "UNLIKELY". 624 If there is an attribute section for the presented attribute type of the 625 presence match form, then if the "*" token is present, return "POSSIBLE", 626 otherwise return "UNLIKELY". 628 7.4. "substrings" filter 630 If there is an attribute section for the presented attribute type of the 631 equality match form, then tokenize the filter values and apply the filter 632 against each token. If there is a match, return "LIKELY", otherwise 633 return "UNLIKELY". 635 If there is an attribute section for the presented attribute type of the 636 approx match form, then tokenize the filter values and compare each 637 against each token. If there is a match, return "LIKELY", otherwise 638 return "POSSIBLE". 640 If there is an attribute section for the presented attribute type of the 641 presence match form, then if the "*" token is present, return "POSSIBLE", 642 otherwise return "UNLIKELY". 644 7.5. "approxMatch" filter 646 If there is an attribute section for the presented attribute type of the 647 equality match form, then apply the filter against each token. If there 648 is a match, return "LIKELY", otherwise return "UNLIKELY". 650 If there is an attribute section for the presented attribute type of the 651 approx match form, then compare each tokenized word in the presented value 652 against the tokens. If there is at least one matching word, return 653 "LIKELY", otherwise return "UNLIKELY". 655 If there is an attribute section for the presented attribute type of the 656 presence match form, then if the "*" token is present, return "POSSIBLE", 657 otherwise return "UNLIKELY". 659 7.6. "present" filter 661 If there are any values or tokens of the presented attribute type in the 662 index object, return "POSSIBLE", otherwise return "UNLIKELY". 664 7.7. "not", "greaterOrEqual", "lessOrEqual" and "extensibleMatch" filters 666 Return "UNLIKELY". 668 8. Recommendations 670 To be written. 672 9. Security Considerations 674 This specification provides a way to transfer directory information from 675 one server to another. This may consist of white pages data, which is 676 protected by privacy laws in many countries. 678 Depending on the requirements of the data suppliers, a number of index 679 encoding options are available, which provide a range of non-reversibility, 680 at a cost of usefulness for the consumer. 682 The specification recommends that a digital signature be applied and the 683 data be encrypted before being transferred to the consumer. This will allow 684 the consumer to verify the source of the data, and to ensure that 685 unauthorized parties are not able to access the data while in transit. 687 The specification is designed to work in environments where there is an 688 agreement between the index supplier and consumer. This may be based on 689 a legal or contractual agreement between the two parties, which defines the 690 protections the consumer must provide to the index information. 692 10. Author's Address 694 Mark Wahl 695 Critical Angle Inc. 696 4815 W Braker Lane #502-385 697 Austin, TX 78759 698 USA 700 EMail: M.Wahl@critical-angle.com 702 Bibliography 704 [CIP] 706 [LDAP] 708 [LDIF] 710 [Fortezza] 712 [UTF8] RFC 2044