git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldapbis-filter-xx.txt

   1
   2 Network Working Group                                 M. Smith, Editor
   3 Request for Comments: DRAFT                        Pearl Crescent, LLC
   4 Obsoletes: RFC 2254                                           T. Howes
   5 Expires: 13 August 2004                                  Opsware, Inc.
   6                                                       13 February 2004
   7
   8
   9              LDAP: String Representation of Search Filters
  10                    <draft-ietf-ldapbis-filter-06.txt>
  11
  12
  13
  14 1.  Status of this Memo
  15
  16    This document is an Internet-Draft and is subject to all provisions
  17    of Section 10 of RFC2026.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups.  Note that
  21    other groups may also distribute working documents as Internet-
  22    Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six months
  25    and may be updated, replaced, or obsoleted by other documents at any
  26    time.  It is inappropriate to use Internet- Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    The list of current Internet-Drafts can be accessed at
  30    http://www.ietf.org/1id-abstracts.html
  31
  32    The list of Internet-Draft Shadow Directories can be accessed at
  33    http://www.ietf.org/shadow.html
  34
  35    Discussion of this document should take place on the LDAP (v3)
  36    Revision (ldapbis) Working Group mailing list <ietf-
  37    ldapbis@openldap.org>.
  38
  39    Copyright (C) The Internet Society (2004).  All Rights Reserved.
  40
  41 2.  Abstract
  42
  43    LDAP search filters are transmitted in the LDAP protocol using a
  44    binary representation that is appropriate for use on the network.
  45    This document defines a human-readable string representation of LDAP
  46    search filters that is appropriate for use in LDAP URLs and in other
  47    applications.
  48
  49
  50
  51
  52
  53 Smith & Howes      Intended Category: Standards Track           [Page 1]
  54 \f
  55 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
  56
  57
  58 3.  Table of Contents
  59
  60 1.     Status of this Memo............................................1
  61 2.     Abstract.......................................................1
  62 3.     Table of Contents..............................................2
  63 4.     Introduction...................................................2
  64 5.     LDAP Search Filter Definition..................................2
  65 6.     String Search Filter Definition................................4
  66 7.     Examples.......................................................5
  67 8.     Security Considerations........................................7
  68 9.     Normative References...........................................7
  69 10.    Informative References.........................................8
  70 11.    Intellectual Property Rights...................................8
  71 12.    Acknowledgments................................................8
  72 13.    Authors' Addresses.............................................9
  73 14.    Full Copyright Statement.......................................9
  74 15.    Appendix A: Changes Since RFC 2254.............................10
  75 15.1.     Technical Changes...........................................10
  76 15.2.     Editorial Changes...........................................10
  77 16.    Appendix B: Changes Since Previous Document Revision...........11
  78 16.1.     Technical Changes...........................................12
  79 16.2.     Editorial Changes...........................................12
  80
  81 4.  Introduction
  82
  83    The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a
  84    network representation of a search filter transmitted to an LDAP
  85    server.  Some applications may find it useful to have a common way of
  86    representing these search filters in a human-readable form; LDAP URLs
  87    are an example of one such application.  This document defines a
  88    human-readable string format for representing the full range of
  89    possible LDAP version 3 search filters, including extended match
  90    filters.
  91
  92     This document is an integral part of the LDAP Technical
  93    Specification [Roadmap].
  94
  95    This document replaces RFC 2254.  Changes to RFC 2254 are summarized
  96    in Appendix A.
  97
  98    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  99    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 100    document are to be interpreted as described in BCP 14 [RFC2119].
 101
 102 5.  LDAP Search Filter Definition
 103
 104    An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
 105    follows:
 106
 107
 108
 109 Smith & Howes      Intended Category: Standards Track           [Page 2]
 110 \f
 111 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 112
 113
 114         Filter ::= CHOICE {
 115                 and                [0] SET SIZE (1..MAX) OF filter Filter,
 116                 or                 [1] SET SIZE (1..MAX) OF filter Filter,
 117                 not                [2] Filter,
 118                 equalityMatch      [3] AttributeValueAssertion,
 119                 substrings         [4] SubstringFilter,
 120                 greaterOrEqual     [5] AttributeValueAssertion,
 121                 lessOrEqual        [6] AttributeValueAssertion,
 122                 present            [7] AttributeDescription,
 123                 approxMatch        [8] AttributeValueAssertion,
 124                 extensibleMatch    [9] MatchingRuleAssertion }
 125
 126         SubstringFilter ::= SEQUENCE {
 127                 type    AttributeDescription,
 128                 -- initial and final can occur at most once
 129                 substrings    SEQUENCE SIZE (1..MAX) OF substring CHOICE {
 130                         initial        [0] AssertionValue,
 131                         any            [1] AssertionValue,
 132                         final          [2] AssertionValue } }
 133
 134         AttributeValueAssertion ::= SEQUENCE {
 135                 attributeDesc   AttributeDescription,
 136                 assertionValue  AssertionValue }
 137
 138         MatchingRuleAssertion ::= SEQUENCE {
 139                 matchingRule    [1] MatchingRuleId OPTIONAL,
 140                 type            [2] AttributeDescription OPTIONAL,
 141                 matchValue      [3] AssertionValue,
 142                 dnAttributes    [4] BOOLEAN DEFAULT FALSE }
 143
 144         AttributeDescription ::= LDAPString
 145                                  -- Constrained to <attributedescription>
 146                                  -- [Models]
 147
 148         AttributeValue ::= OCTET STRING
 149
 150         MatchingRuleId ::= LDAPString
 151
 152         AssertionValue ::= OCTET STRING
 153
 154         LDAPString ::= OCTET STRING -- UTF-8 encoded,
 155                                     -- [ISO10646] characters
 156
 157    The AttributeDescription is a string representation of the attribute
 158    description and is defined in [Protocol].  The AttributeValue and
 159    AssertionValue OCTET STRING have the form defined in [Syntaxes].  The
 160    Filter is encoded for transmission over a network using the Basic
 161    Encoding Rules defined in [X.690], with simplifications described in
 162
 163
 164
 165 Smith & Howes      Intended Category: Standards Track           [Page 3]
 166 \f
 167 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 168
 169
 170    [Protocol].
 171
 172 6.  String Search Filter Definition
 173
 174    The string representation of an LDAP search filter is a string of
 175    UTF-8[RFC3629] encoded ISO 10646-1 characters that is defined by the
 176    following grammar, following the ABNF notation defined in [RFC2234].
 177    The productions used that are not defined here are defined in section
 178    1.4 (Common ABNF Productions) of [Models] unless otherwise noted.
 179    The filter format uses a prefix notation.
 180
 181       filter         = LPAREN filtercomp RPAREN
 182       filtercomp     = and / or / not / item
 183       and            = AMPERSAND filterlist
 184       or             = VERTBAR filterlist
 185       not            = EXCLAMATION filter
 186       filterlist     = 1*filter
 187       item           = simple / present / substring / extensible
 188       simple         = attr filtertype assertionvalue
 189       filtertype     = equal / approx / greater / less
 190       equal          = EQUALS
 191       approx         = TILDE EQUALS
 192       greater        = RANGLE EQUALS
 193       less           = LANGLE EQUALS
 194       extensible     = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue
 195                        / [dnattrs] matchingrule COLON EQUALS assertionvalue
 196                        / COLON EQUALS assertionvalue
 197       present        = attr EQUALS ASTERISK
 198       substring      = attr EQUALS [initial] any [final]
 199       initial        = assertionvalue
 200       any            = ASTERISK *(assertionvalue ASTERISK)
 201       final          = assertionvalue
 202       attr           = attributedescription
 203                          ; The attributedescription rule is defined in
 204                          ; Section 2.5 of [Models].
 205       dnattrs        = COLON "dn"
 206       matchingrule   = COLON oid
 207       assertionvalue = valueencoding
 208                          ; The <valueencoding> rule is used to encode an
 209                          ; <AssertionValue> from Section 4.1.6 of [Protocol].
 210       valueencoding  = 0*(normal / escaped)
 211       normal         = UTF1SUBSET / UTFMB
 212       escaped        = ESC HEX HEX
 213       UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F
 214                           ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
 215                           ; RPAREN, ASTERISK, and ESC.
 216       EXCLAMATION    = %x21 ; exclamation mark ("!")
 217       AMPERSAND      = %x26 ; ampersand (or AND symbol) ("&")
 218
 219
 220
 221 Smith & Howes      Intended Category: Standards Track           [Page 4]
 222 \f
 223 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 224
 225
 226       ASTERISK       = %x2A ; asterisk ("*")
 227       COLON          = %x3A ; colon (":")
 228       VERTBAR        = %x7C ; vertical bar (or pipe) ("|")
 229       TILDE          = %x7E ; tilde ("~")
 230
 231
 232    Note that although both the <substring> and <present> productions in
 233    the grammar above can produce the "attr=*" construct, this construct
 234    is used only to denote a presence filter.
 235
 236    The <valueencoding> rule ensures that the entire filter string is a
 237    valid UTF-8 string and provides that the octets that represent the
 238    ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
 239    0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
 240    backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
 241    representing the value of the encoded octet.
 242
 243    This simple escaping mechanism eliminates filter-parsing ambiguities
 244    and allows any filter that can be represented in LDAP to be
 245    represented as a NUL-terminated string. Other octets that are part of
 246    the <normal> set may be escaped using this mechanism, for example,
 247    non-printing ASCII characters.
 248
 249    For AssertionValues that contain UTF-8 character data, each octet of
 250    the character to be escaped is replaced by a backslash and two hex
 251    digits, which form a single octet in the code of the character.
 252
 253    For example, the filter checking whether the "cn" attribute contained
 254    a value with the character "*" anywhere in it would be represented as
 255    "(cn=*\2a*)".
 256
 257    As indicated by the valueencoding rule, implementations MUST escape
 258    all octets greater than 0x7F that are not part of a valid UTF-8
 259    encoding sequence when they generate a string representation of a
 260    search filter.  Implementations SHOULD accept as input strings that
 261    are not valid UTF-8 strings. This is necessary because RFC 2254 did
 262    not clearly define the term "string representation" (and in
 263    particular did not mention that the string representation of an LDAP
 264    search filter is a string of UTF-8 encoded ISO 10646-1 characters).
 265
 266 7.  Examples
 267
 268    This section gives a few examples of search filters written using
 269    this notation.
 270
 271         (cn=Babs Jensen)
 272         (!(cn=Tim Howes))
 273         (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
 274
 275
 276
 277 Smith & Howes      Intended Category: Standards Track           [Page 5]
 278 \f
 279 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 280
 281
 282         (o=univ*of*mich*)
 283         (seeAlso=)
 284
 285    The following examples illustrate the use of extensible matching.
 286
 287         (cn:1.2.3.4.5:=Fred Flintstone)
 288         (cn:=Betty Rubble)
 289         (sn:dn:2.4.6.8.10:=Barney Rubble)
 290         (o:dn:=Ace Industry)
 291         (:1.2.3:=Wilma Flintstone)
 292         (:dn:2.4.6.8.10:=Dino)
 293
 294    The first example shows use of the matching rule "1.2.3.4.5".
 295
 296    The second example demonstrates use of a MatchingRuleAssertion form
 297    without a matchingRule.
 298
 299    The third example illustrates the use of the ":oid" notation to
 300    indicate that matching rule "2.4.6.8.10" should be used when making
 301    comparisons, and that the attributes of an entry's distinguished name
 302    should be considered part of the entry when evaluating the match
 303    (indicated by the use of ":dn").
 304
 305    The fourth example denotes an equality match, except that DN
 306    components should be considered part of the entry when doing the
 307    match.
 308
 309    The fifth example is a filter that should be applied to any attribute
 310    supporting the matching rule given (since the attr has been omitted).
 311
 312    The sixth and final example is also a filter that should be applied
 313    to any attribute supporting the matching rule given.  Attributes
 314    supporting the matching rule contained in the DN should also be
 315    considered.
 316
 317    The following examples illustrate the use of the escaping mechanism.
 318
 319         (o=Parens R Us \28for all your parenthetical needs\29)
 320         (cn=*\2A*)
 321         (filename=C:\5cMyFile)
 322         (bin=\00\00\00\04)
 323         (sn=Lu\c4\8di\c4\87)
 324         (1.3.6.1.4.1.1466.0=\04\02\48\69)
 325
 326    The first example shows the use of the escaping mechanism to
 327    represent parenthesis characters. The second shows how to represent a
 328    "*" in an assertion value, preventing it from being interpreted as a
 329    substring indicator. The third illustrates the escaping of the
 330
 331
 332
 333 Smith & Howes      Intended Category: Standards Track           [Page 6]
 334 \f
 335 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 336
 337
 338    backslash character.
 339
 340    The fourth example shows a filter searching for the four-byte value
 341    0x00000004, illustrating the use of the escaping mechanism to
 342    represent arbitrary data, including NUL characters.
 343
 344    The fifth example illustrates the use of the escaping mechanism to
 345    represent various non-ASCII UTF-8 characters.
 346
 347    The sixth and final example demonstrates assertion of a BER encoded
 348    value.
 349
 350 8.  Security Considerations
 351
 352    This memo describes a string representation of LDAP search filters.
 353    While the representation itself has no known security implications,
 354    LDAP search filters do. They are interpreted by LDAP servers to
 355    select entries from which data is retrieved.  LDAP servers should
 356    take care to protect the data they maintain from unauthorized access.
 357
 358    Please refer to the Security Considerations sections of [Protocol]
 359    and [AuthMeth] for more information.
 360
 361 9.  Normative References
 362
 363 [AuthMeth]  Harrison, R. (editor), "LDAP: Authentication Methods and
 364             Connection Level Security Mechanisms", draft-ietf-ldapbis-
 365             authmeth-xx.txt, a work in progress.
 366
 367 [ISO10646]  Universal Multiple-Octet Coded Character Set (UCS) -
 368             Architecture and Basic Multilingual Plane, ISO/IEC 10646-1,
 369             1993.
 370
 371 [Models]    Zeilenga, K. (editor), "LDAP: Directory Information Models",
 372             draft-ietf-ldapbis-models-xx.txt, a work in progress.
 373
 374 [Protocol]  draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
 375
 376 [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
 377             Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 378
 379 [RFC2234]   Crocker, D., Overell, P., "Augmented BNF for Syntax
 380             Specifications: ABNF", RFC 2234, November 1997.
 381
 382 [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
 383             RFC 3629, November 2003.
 384
 385
 386
 387
 388
 389 Smith & Howes      Intended Category: Standards Track           [Page 7]
 390 \f
 391 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 392
 393
 394 [Roadmap]   Zeilenga, K. (editor), "LDAP: Technical Specification Road
 395             Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
 396
 397 [Syntaxes]  Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
 398             syntaxes-xx.txt, a work in progress.
 399
 400 [X.690]     Specification of ASN.1 encoding rules: Basic, Canonical, and
 401             Distinguished Encoding Rules, ITU-T Recommendation X.690,
 402             1994.
 403
 404 10.  Informative References
 405
 406    None.
 407
 408 11.  Intellectual Property Rights
 409
 410    The IETF takes no position regarding the validity or scope of any
 411    intellectual property or other rights that might be claimed to
 412    pertain to the implementation or use of the technology described in
 413    this document or the extent to which any license under such rights
 414    might or might not be available; neither does it represent that it
 415    has made any effort to identify any such rights.  Information on the
 416    IETF's procedures with respect to rights in standards-track and
 417    standards-related documentation can be found in BCP-11.  Copies of
 418    claims of rights made available for publication and any assurances of
 419    licenses to be made available, or the result of an attempt made to
 420    obtain a general license or permission for the use of such
 421    proprietary rights by implementors or users of this specification can
 422    be obtained from the IETF Secretariat.
 423
 424    The IETF invites any interested party to bring to its attention any
 425    copyrights, patents or patent applications, or other proprietary
 426    rights which may cover technology that may be required to practice
 427    this standard.  Please address the information to the IETF Executive
 428    Director.
 429
 430 12.  Acknowledgments
 431
 432    This document replaces RFC 2254 by Tim Howes.  Changes included in
 433    this revised specification are based upon discussions among the
 434    authors, discussions within the LDAP (v3) Revision Working Group
 435    (ldapbis), and discussions within other IETF Working Groups.  The
 436    contributions of individuals in these working groups is gratefully
 437    acknowledged.
 438
 439
 440
 441
 442
 443
 444
 445 Smith & Howes      Intended Category: Standards Track           [Page 8]
 446 \f
 447 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 448
 449
 450 13.  Authors' Addresses
 451
 452    Mark Smith, Editor
 453    Pearl Crescent, LLC
 454    447 Marlpool Dr.
 455    Saline, MI 48176
 456    USA
 457    +1 734 944-2856
 458    mcs@pearlcrescent.com
 459
 460    Tim Howes
 461    Opsware, Inc.
 462    599 N. Mathilda Ave.
 463    Sunnyvale, CA 94085
 464    USA
 465    +1 408 744-7509
 466    howes@opsware.com
 467
 468 14.  Full Copyright Statement
 469
 470    Copyright (C) The Internet Society (2004). All Rights Reserved.
 471
 472    This document and translations of it may be copied and furnished to
 473    others, and derivative works that comment on or otherwise explain it
 474    or assist in its implementation may be prepared, copied, published
 475    and distributed, in whole or in part, without restriction of any
 476    kind, provided that the above copyright notice and this paragraph are
 477    included on all such copies and derivative works.  However, this
 478    document itself may not be modified in any way, such as by removing
 479    the copyright notice or references to the Internet Society or other
 480    Internet organizations, except as needed for the purpose of
 481    developing Internet standards in which case the procedures for
 482    copyrights defined in the Internet Standards process must be
 483    followed, or as required to translate it into languages other than
 484    English.
 485
 486    The limited permissions granted above are perpetual and will not be
 487    revoked by the Internet Society or its successors or assigns.
 488
 489    This document and the information contained herein is provided on an
 490    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 491    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 492    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 493    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 494    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 495
 496
 497
 498
 499
 500
 501 Smith & Howes      Intended Category: Standards Track           [Page 9]
 502 \f
 503 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 504
 505
 506 15.  Appendix A: Changes Since RFC 2254
 507
 508 15.1.  Technical Changes
 509
 510    The following technical changes were made to the contents of the
 511    "String Search Filter Definition" section:
 512
 513    Added statement that the string representation is a string of UTF-8
 514    encoded ISO 10646-1 characters.
 515
 516    Revised all of the ABNF to use common productions from [Models].
 517
 518    Replaced the "value" rule with a new "assertionvalue" rule within the
 519    "simple", "extensible", and "substring" ("initial", "any", and
 520    "final") rules.  This matches a change made in [Syntaxes].
 521
 522    Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
 523    precisely reference productions from the [Models] and [Protocol]
 524    documents.
 525
 526    Introduced the "valueencoding" and associated "normal" and "escaped"
 527    rules to reduce the dependence on descriptive text. The "normal"
 528    production restricts filter strings to valid UTF-8 sequences.
 529
 530    Added a third option to the "extensible" production to allow creation
 531    of a MatchingRuleAssertion that only has a matchValue.
 532
 533    Added a statement about expected behavior in light of RFC 2254's lack
 534    of a clear definition of "string representation."
 535
 536
 537 15.2.  Editorial Changes
 538
 539    Changed document title to include "LDAP:" prefix.
 540
 541    IESG Note: removed note about lack of satisfactory mandatory
 542    authentication mechanisms.
 543
 544    Header and "Authors' Addresses" sections: added Mark Smith as the
 545    document editor and updated affiliation and contact information.
 546
 547    "Table of Contents" and "Intellectual Property Rights" sections:
 548    added.
 549
 550    Copyright: updated per latest IETF guidelines.
 551
 552    "Abstract" section: separated from introductory material.
 553
 554
 555
 556
 557 Smith & Howes      Intended Category: Standards Track          [Page 10]
 558 \f
 559 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 560
 561
 562    "Introduction" section: new section; separated from the Abstract.
 563    Updated second paragraph to indicate that RFC 2254 is replaced by
 564    this document (instead of RFC 1960). Added reference to the [Roadmap]
 565    document.
 566
 567    "LDAP Search Filter Definition" section: made corrections to the
 568    LDAPv3 search filter ABNF so it matches that used in [Protocol].
 569
 570    Clarified the definition of 'value' (now 'assertionvalue') to take
 571    into account the fact that it is not precisely an AttributeAssertion
 572    from [Protocol] section 4.1.6 (special handling is required for some
 573    characters).  Added a note that each octet of a character to be
 574    escaped is replaced by a backslash and two hex digits, which
 575    represent a single octet.
 576
 577    "Examples" section: added four additional examples: (seeAlso=),
 578    (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
 579    (1.3.6.1.4.1.1466.0=\04\02\48\69).  Replaced one occurrence of "a
 580    value" with "an assertion value".  Corrected the description of this
 581    example: (sn:dn:2.4.6.8.10:=Barney Rubble).
 582
 583    "Security Considerations" section: added references to [Protocol] and
 584    [AuthMeth].
 585
 586    "Normative References" section: renamed from "References" per new RFC
 587    guidelines. Changed from [1] style to [Protocol] style throughout the
 588    document.  Added entries for [ISO10646], [RFC2119], [AuthMeth],
 589    [Models], and [Roadmap] and updated the UTF-8 reference.  Replaced
 590    RFC 822 reference with a reference to RFC 2234.
 591
 592    "Informative References" section: added for clarity.
 593
 594    "Acknowledgments" section: added.
 595
 596    "Appendix A: Changes Since RFC 2254" section: added.
 597
 598    "Appendix B: Changes Since Previous Document Revision" section:
 599    added.
 600
 601
 602 16.  Appendix B: Changes Since Previous Document Revision
 603
 604    This appendix lists all changes relative to the previously published
 605    revision, draft-ietf-ldapbis-filter-05.txt.  Note that when
 606    appropriate these changes are also included in Appendix A, but are
 607    also included here for the benefit of the people who have already
 608    reviewed draft-ietf-ldapbis-filter-05.txt.  This section will be
 609    removed before this document is published as an RFC.
 610
 611
 612
 613 Smith & Howes      Intended Category: Standards Track          [Page 11]
 614 \f
 615 INTERNET-DRAFT   LDAP: String Repres. of Search Filters 13 February 2004
 616
 617
 618 16.1.  Technical Changes
 619
 620    None.
 621
 622
 623 16.2.  Editorial Changes
 624
 625    "LDAP Search Filter Definition" section: changed the LDAPv3 search
 626    filter ABNF so it matches that used in the latest revision of
 627    [Protocol] and removed the following redundant descriptive text:
 628    "where the LDAPString above is limited to the UTF-8 encoding [UTF-8]
 629    of the ISO 10646 character set [ISO10646]."
 630
 631    "String Search Filter Definition" section: Corrected section
 632    reference to [Models] and replaced this sentence: "Implementations
 633    SHOULD accept as input a string that includes invalid UTF-8 octet
 634    sequences." with the following: "Implementations SHOULD accept as
 635    input strings that are not valid UTF-8 strings."
 636
 637    "Examples" section: Corrected the description of this example:
 638    (sn:dn:2.4.6.8.10:=Barney Rubble).
 639
 640    "Normative References" section: changed UTF-8 reference to point to
 641    RFC 3629, replaced [ASN.1] with [X.690] for consistency, and indented
 642    the reference descriptions to enhance readability.
 643
 644    Authors' Addresses section: New contact information for Mark Smith.
 645
 646    Updated the copyright year to 2004.
 647
 648
 649 This Internet Draft expires on 13 August 2004.
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669 Smith & Howes      Intended Category: Standards Track          [Page 12]
 670 \f
 671