draft-ietf-ldapbis-filter-09.txt   rfc4515.txt 
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2254 T. Howes
Expires: 16 May 2005 Opsware, Inc.
16 November 2004
LDAP: String Representation of Search Filters Network Working Group M. Smith, Ed.
<draft-ietf-ldapbis-filter-09.txt> Request for Comments: 4515 Pearl Crescent, LLC
Obsoletes: 2254 T. Howes
Status of this Memo Category: Standards Track Opsware, Inc.
June 2006
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she become
aware will be disclosed, in accordance with RFC 3668.
This document is intended to be published as a Standards Track RFC,
replacing RFC 2254. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF
LDAP (v3) Revision (ldapbis) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <mcs@pearlcrescent.com>.
Internet-Drafts are working documents of the Internet Engineering Lightweight Directory Access Protocol (LDAP):
Task Force (IETF), its areas, and its working groups. Note that String Representation of Search Filters
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/1id-abstracts.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2006).
Please see the Full Copyright section near the end of this document
for more information.
Abstract Abstract
LDAP search filters are transmitted in the LDAP protocol using a Lightweight Directory Access Protocol (LDAP) search filters are
binary representation that is appropriate for use on the network. transmitted in the LDAP protocol using a binary representation that
This document defines a human-readable string representation of LDAP is appropriate for use on the network. This document defines a
search filters that is appropriate for use in LDAP URLs [LDAPURL] and human-readable string representation of LDAP search filters that is
in other applications. appropriate for use in LDAP URLs (RFC 4516) and in other
applications.
Table of Contents Table of Contents
Status of this Memo............................................1 1. Introduction ....................................................2
Abstract.......................................................2 2. LDAP Search Filter Definition ...................................2
Table of Contents..............................................2 3. String Search Filter Definition .................................3
1. Introduction...................................................2 4. Examples ........................................................5
2. LDAP Search Filter Definition..................................3 5. Security Considerations .........................................7
3. String Search Filter Definition................................4 6. Normative References ............................................7
4. Examples.......................................................6 7. Informative References ..........................................8
5. Security Considerations........................................7 8. Acknowledgements ................................................8
6. IANA Considerations............................................7 Appendix A: Changes Since RFC 2254 .................................9
7. Normative References...........................................7 A.1. Technical Changes ..........................................9
8. Informative References.........................................8 A.2. Editorial Changes ..........................................9
9. Acknowledgments................................................8
10. Authors' Addresses.............................................9
11. Appendix A: Changes Since RFC 2254.............................9
11.1. Technical Changes...........................................9
11.2. Editorial Changes...........................................10
12. Appendix B: Changes Since Previous Document Revision...........11
12.1. Technical Changes...........................................11
12.2. Editorial Changes...........................................12
Intellectual Property Rights...................................12
Full Copyright.................................................13
1. Introduction 1. Introduction
The Lightweight Directory Access Protocol (LDAP) [Roadmap] defines a The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
network representation of a search filter transmitted to an LDAP network representation of a search filter transmitted to an LDAP
server. Some applications may find it useful to have a common way of server. Some applications may find it useful to have a common way of
representing these search filters in a human-readable form; LDAP URLs representing these search filters in a human-readable form; LDAP URLs
are an example of one such application. This document defines a [RFC4516] are an example of one such application. This document
human-readable string format for representing the full range of defines a human-readable string format for representing the full
possible LDAP version 3 search filters, including extended match range of possible LDAP version 3 search filters, including extended
filters. match filters.
This document is a integral part of the LDAP technical specification This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical [RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety. specification, RFC 3377, in its entirety.
This document replaces RFC 2254. Changes to RFC 2254 are summarized This document replaces RFC 2254. Changes to RFC 2254 are summarized
in Appendix A. in Appendix A.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
2. LDAP Search Filter Definition 2. LDAP Search Filter Definition
An LDAP search filter is defined in Section 4.5.1 of [Protocol] as An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
follows: follows:
Filter ::= CHOICE { Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter, and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter, or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter, not [2] Filter,
equalityMatch [3] AttributeValueAssertion, equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter, substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion, greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion,
skipping to change at page 3, line 49 skipping to change at page 3, line 17
assertionValue AssertionValue } assertionValue AssertionValue }
MatchingRuleAssertion ::= SEQUENCE { MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL, matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL, type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue, matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE } dnAttributes [4] BOOLEAN DEFAULT FALSE }
AttributeDescription ::= LDAPString AttributeDescription ::= LDAPString
-- Constrained to <attributedescription> -- Constrained to <attributedescription>
-- [Models] -- [RFC4512]
AttributeValue ::= OCTET STRING AttributeValue ::= OCTET STRING
MatchingRuleId ::= LDAPString MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING -- UTF-8 encoded, LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters -- [Unicode] characters
The AttributeDescription, as defined in [Protocol], is a string The AttributeDescription, as defined in [RFC4511], is a string
representation of the attribute description that is discussed in representation of the attribute description that is discussed in
[Models]. The AttributeValue and AssertionValue OCTET STRING have [RFC4512]. The AttributeValue and AssertionValue OCTET STRING have
the form defined in [Syntaxes]. The Filter is encoded for the form defined in [RFC4517]. The Filter is encoded for
transmission over a network using the Basic Encoding Rules (BER) transmission over a network using the Basic Encoding Rules (BER)
defined in [X.690], with simplifications described in [Protocol]. defined in [X.690], with simplifications described in [RFC4511].
3. String Search Filter Definition 3. String Search Filter Definition
The string representation of an LDAP search filter is a string of The string representation of an LDAP search filter is a string of
UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
by the following grammar, following the ABNF notation defined in by the following grammar, following the ABNF notation defined in
[RFC2234]. The productions used that are not defined here are [RFC4234]. The productions used that are not defined here are
defined in section 1.4 (Common ABNF Productions) of [Models] unless defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
otherwise noted. The filter format uses a prefix notation. otherwise noted. The filter format uses a prefix notation.
filter = LPAREN filtercomp RPAREN filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item filtercomp = and / or / not / item
and = AMPERSAND filterlist and = AMPERSAND filterlist
or = VERTBAR filterlist or = VERTBAR filterlist
not = EXCLAMATION filter not = EXCLAMATION filter
filterlist = 1*filter filterlist = 1*filter
item = simple / present / substring / extensible item = simple / present / substring / extensible
simple = attr filtertype assertionvalue simple = attr filtertype assertionvalue
skipping to change at page 4, line 51 skipping to change at page 4, line 19
[matchingrule] COLON EQUALS assertionvalue ) [matchingrule] COLON EQUALS assertionvalue )
/ ( [dnattrs] / ( [dnattrs]
matchingrule COLON EQUALS assertionvalue ) matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final] substring = attr EQUALS [initial] any [final]
initial = assertionvalue initial = assertionvalue
any = ASTERISK *(assertionvalue ASTERISK) any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue final = assertionvalue
attr = attributedescription attr = attributedescription
; The attributedescription rule is defined in ; The attributedescription rule is defined in
; Section 2.5 of [Models]. ; Section 2.5 of [RFC4512].
dnattrs = COLON "dn" dnattrs = COLON "dn"
matchingrule = COLON oid matchingrule = COLON oid
assertionvalue = valueencoding assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an <AssertionValue> ; The <valueencoding> rule is used to encode an <AssertionValue>
; from Section 4.1.6 of [Protocol]. ; from Section 4.1.6 of [RFC4511].
valueencoding = 0*(normal / escaped) valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN, ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
; RPAREN, ASTERISK, and ESC. ; RPAREN, ASTERISK, and ESC.
EXCLAMATION = %x21 ; exclamation mark ("!") EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERISK = %x2A ; asterisk ("*") ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":") COLON = %x3A ; colon (":")
skipping to change at page 5, line 36 skipping to change at page 5, line 7
The <valueencoding> rule ensures that the entire filter string is a The <valueencoding> rule ensures that the entire filter string is a
valid UTF-8 string and provides that the octets that represent the valid UTF-8 string and provides that the octets that represent the
ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
representing the value of the encoded octet. representing the value of the encoded octet.
This simple escaping mechanism eliminates filter-parsing ambiguities This simple escaping mechanism eliminates filter-parsing ambiguities
and allows any filter that can be represented in LDAP to be and allows any filter that can be represented in LDAP to be
represented as a NUL-terminated string. Other octets that are part of represented as a NUL-terminated string. Other octets that are part
the <normal> set may be escaped using this mechanism, for example, of the <normal> set may be escaped using this mechanism, for example,
non-printing ASCII characters. non-printing ASCII characters.
For AssertionValues that contain UTF-8 character data, each octet of For AssertionValues that contain UTF-8 character data, each octet of
the character to be escaped is replaced by a backslash and two hex the character to be escaped is replaced by a backslash and two hex
digits, which form a single octet in the code of the character. For digits, which form a single octet in the code of the character. For
example, the filter checking whether the "cn" attribute contained a example, the filter checking whether the "cn" attribute contained a
value with the character "*" anywhere in it would be represented as value with the character "*" anywhere in it would be represented as
"(cn=*\2a*)". "(cn=*\2a*)".
As indicated by the <valueencoding> rule, implementations MUST escape As indicated by the <valueencoding> rule, implementations MUST escape
all octets greater than 0x7F that are not part of a valid UTF-8 all octets greater than 0x7F that are not part of a valid UTF-8
encoding sequence when they generate a string representation of a encoding sequence when they generate a string representation of a
search filter. Implementations SHOULD accept as input strings that search filter. Implementations SHOULD accept as input strings that
are not valid UTF-8 strings. This is necessary because RFC 2254 did are not valid UTF-8 strings. This is necessary because RFC 2254 did
not clearly define the term "string representation" (and in not clearly define the term "string representation" (and in
particular did not mention that the string representation of an LDAP particular did not mention that the string representation of an LDAP
search filter is a string of UTF-8 encoded Unicode characters). search filter is a string of UTF-8-encoded Unicode characters).
4. Examples 4. Examples
This section gives a few examples of search filters written using This section gives a few examples of search filters written using
this notation. this notation.
(cn=Babs Jensen) (cn=Babs Jensen)
(!(cn=Tim Howes)) (!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*) (o=univ*of*mich*)
skipping to change at page 6, line 34 skipping to change at page 6, line 6
(o:dn:=Ace Industry) (o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone) (:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino) (:DN:2.4.6.8.10:=Dino)
The first example shows use of the matching rule "caseExactMatch." The first example shows use of the matching rule "caseExactMatch."
The second example demonstrates use of a MatchingRuleAssertion form The second example demonstrates use of a MatchingRuleAssertion form
without a matchingRule. without a matchingRule.
The third example illustrates the use of the ":oid" notation to The third example illustrates the use of the ":oid" notation to
indicate that matching rule identified by the OID "2.4.6.8.10" should indicate that the matching rule identified by the OID "2.4.6.8.10"
be used when making comparisons, and that the attributes of an should be used when making comparisons, and that the attributes of an
entry's distinguished name should be considered part of the entry entry's distinguished name should be considered part of the entry
when evaluating the match (indicated by the use of ":dn"). when evaluating the match (indicated by the use of ":dn").
The fourth example denotes an equality match, except that DN The fourth example denotes an equality match, except that DN
components should be considered part of the entry when doing the components should be considered part of the entry when doing the
match. match.
The fifth example is a filter that should be applied to any attribute The fifth example is a filter that should be applied to any attribute
supporting the matching rule given (since the <attr> has been supporting the matching rule given (since the <attr> has been
omitted). omitted).
skipping to change at page 7, line 15 skipping to change at page 6, line 34
The following examples illustrate the use of the escaping mechanism. The following examples illustrate the use of the escaping mechanism.
(o=Parens R Us \28for all your parenthetical needs\29) (o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*) (cn=*\2A*)
(filename=C:\5cMyFile) (filename=C:\5cMyFile)
(bin=\00\00\00\04) (bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87) (sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69) (1.3.6.1.4.1.1466.0=\04\02\48\69)
The first example shows the use of the escaping mechanism to The first example shows the use of the escaping mechanism to
represent parenthesis characters. The second shows how to represent a represent parenthesis characters. The second shows how to represent
"*" in an assertion value, preventing it from being interpreted as a a "*" in an assertion value, preventing it from being interpreted as
substring indicator. The third illustrates the escaping of the a substring indicator. The third illustrates the escaping of the
backslash character. backslash character.
The fourth example shows a filter searching for the four octet value The fourth example shows a filter searching for the four-octet value
00 00 00 04 (hex), illustrating the use of the escaping mechanism to 00 00 00 04 (hex), illustrating the use of the escaping mechanism to
represent arbitrary data, including NUL characters. represent arbitrary data, including NUL characters.
The fifth example illustrates the use of the escaping mechanism to The fifth example illustrates the use of the escaping mechanism to
represent various non-ASCII UTF-8 characters. Specifically, there are represent various non-ASCII UTF-8 characters. Specifically, there
5 characters in the <assertionvalue> portion of this example: LATIN are 5 characters in the <assertionvalue> portion of this example:
CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
LATIN SMALL LETTER C WITH ACUTE (U+0107). and LATIN SMALL LETTER C WITH ACUTE (U+0107).
The sixth and final example demonstrates assertion of a BER encoded The sixth and final example demonstrates assertion of a BER-encoded
value. value.
5. Security Considerations 5. Security Considerations
This memo describes a string representation of LDAP search filters. This memo describes a string representation of LDAP search filters.
While the representation itself has no known security implications, While the representation itself has no known security implications,
LDAP search filters do. They are interpreted by LDAP servers to LDAP search filters do. They are interpreted by LDAP servers to
select entries from which data is retrieved. LDAP servers should select entries from which data is retrieved. LDAP servers should
take care to protect the data they maintain from unauthorized access. take care to protect the data they maintain from unauthorized access.
Please refer to the Security Considerations sections of [Protocol] Please refer to the Security Considerations sections of [RFC4511] and
and [AuthMeth] for more information. [RFC4513] for more information.
6. IANA Considerations
This document has no actions for IANA.
7. Normative References 6. Normative References
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Connection Level Security Mechanisms", Requirement Levels", BCP 14, RFC 2119, March 1997.
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
draft-ietf-ldapbis-models-xx.txt, a work in progress. 10646", STD 63, RFC 3629, November 2003.
[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
Requirement Levels", BCP 14 (also RFC 2119), March 1997. (LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Specifications: ABNF", RFC 2234, November 1997. Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
RFC 3629, November 2003. (LDAP): Directory Information Models", RFC 4512, June
2006.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. (LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0" 3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
amended by the "Unicode Standard Annex #27: Unicode 3.1" as amended by the "Unicode Standard Annex #27: Unicode
(http://www.unicode.org/reports/tr27/) and by the "Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the
Standard Annex #28: Unicode 3.2." "Unicode Standard Annex #28: Unicode 3.2."
8. Informative References 7. Informative References
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
draft-ietf-ldapbis-url-xx.txt, a work in progress. Access Protocol (LDAP): Uniform Resource Locator", RFC
4516, June 2006.
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and [X.690] Specification of ASN.1 encoding rules: Basic, Canonical,
Distinguished Encoding Rules, ITU-T Recommendation X.690, and Distinguished Encoding Rules, ITU-T Recommendation
1994. X.690, 1994.
9. Acknowledgments 8. Acknowledgements
This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
of the IETF ASID Working Group. of the IETF ASID Working Group.
Changes included in this revised specification are based upon Changes included in this revised specification are based upon
discussions among the authors, discussions within the LDAP (v3) discussions among the authors, discussions within the LDAP (v3)
Revision Working Group (ldapbis), and discussions within other IETF Revision Working Group (ldapbis), and discussions within other IETF
Working Groups. The contributions of individuals in these working Working Groups. The contributions of individuals in these working
groups is gratefully acknowledged. groups is gratefully acknowledged.
10. Authors' Addresses Appendix A: Changes Since RFC 2254
Mark Smith, Editor
Pearl Crescent, LLC
447 Marlpool Dr.
Saline, MI 48176
USA
+1 734 944-2856
mcs@pearlcrescent.com
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
Sunnyvale, CA 94085
USA
+1 408 744-7509
howes@opsware.com
11. Appendix A: Changes Since RFC 2254
11.1. Technical Changes A.1. Technical Changes
Replaced [ISO 10646] reference with [Unicode]. Replaced [ISO 10646] reference with [Unicode].
The following technical changes were made to the contents of the The following technical changes were made to the contents of the
"String Search Filter Definition" section: "String Search Filter Definition" section:
Added statement that the string representation is a string of UTF-8 Added statement that the string representation is a string of UTF-8-
encoded Unicode characters. encoded Unicode characters.
Revised all of the ABNF to use common productions from [Models]. Revised all of the ABNF to use common productions from [RFC4512].
Replaced the "value" rule with a new "assertionvalue" rule within the Replaced the "value" rule with a new "assertionvalue" rule within the
"simple", "extensible", and "substring" ("initial", "any", and "simple", "extensible", and "substring" ("initial", "any", and
"final") rules. This matches a change made in [Syntaxes]. "final") rules. This matches a change made in [RFC4517].
Added "(" and ")" around the components of the <extensible> Added "(" and ")" around the components of the <extensible>
subproductions for clarity. subproductions for clarity.
Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
precisely reference productions from the [Models] and [Protocol] precisely reference productions from the [RFC4512] and [RFC4511]
documents. documents.
"String Search Filter Definition" section: replaced "greater" and "String Search Filter Definition" section: replaced "greater" and
"less" with "greaterorequal" and "lessorequal" to avoid confusion. "less" with "greaterorequal" and "lessorequal" to avoid confusion.
Introduced the "valueencoding" and associated "normal" and "escaped" Introduced the "valueencoding" and associated "normal" and "escaped"
rules to reduce the dependence on descriptive text. The "normal" rules to reduce the dependence on descriptive text. The "normal"
production restricts filter strings to valid UTF-8 sequences. production restricts filter strings to valid UTF-8 sequences.
Added a statement about expected behavior in light of RFC 2254's lack Added a statement about expected behavior in light of RFC 2254's lack
of a clear definition of "string representation." of a clear definition of "string representation."
11.2. Editorial Changes A.2. Editorial Changes
Changed document title to include "LDAP:" prefix. Changed document title to include "LDAP:" prefix.
IESG Note: removed note about lack of satisfactory mandatory IESG Note: removed note about lack of satisfactory mandatory
authentication mechanisms. authentication mechanisms.
Header and "Authors' Addresses" sections: added Mark Smith as the Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information. document editor and updated affiliation and contact information.
"Table of Contents", "IANA Considerations", and "Intellectual "Table of Contents" and "Intellectual Property" sections: added.
Property Rights" sections: added.
Copyright: updated per latest IETF guidelines. Copyright: updated per latest IETF guidelines.
"Abstract" section: separated from introductory material. "Abstract" section: separated from introductory material.
"Introduction" section: new section; separated from the Abstract. "Introduction" section: new section; separated from the Abstract.
Updated second paragraph to indicate that RFC 2254 is replaced by Updated second paragraph to indicate that RFC 2254 is replaced by
this document (instead of RFC 1960). Added reference to the [Roadmap] this document (instead of RFC 1960). Added reference to the
document. [RFC4510] document.
"LDAP Search Filter Definition" section: made corrections to the LDAP "LDAP Search Filter Definition" section: made corrections to the LDAP
search filter ABNF so it matches that used in [Protocol]. search filter ABNF so it matches that used in [RFC4511].
Clarified the definition of 'value' (now 'assertionvalue') to take Clarified the definition of 'value' (now 'assertionvalue') to take
into account the fact that it is not precisely an AttributeAssertion into account the fact that it is not precisely an AttributeAssertion
from [Protocol] section 4.1.6 (special handling is required for some from [RFC4511] Section 4.1.6 (special handling is required for some
characters). Added a note that each octet of a character to be characters). Added a note that each octet of a character to be
escaped is replaced by a backslash and two hex digits, which escaped is replaced by a backslash and two hex digits, which
represent a single octet. represent a single octet.
"Examples" section: added four additional examples: (seeAlso=), "Examples" section: added four additional examples: (seeAlso=),
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
(1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
value" with "an assertion value". Corrected the description of this value" with "an assertion value". Corrected the description of this
example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
in the first extensible match example with "caseExactMatch" to in the first extensible match example with "caseExactMatch" to
demonstrate use of the descriptive form. Used "DN" (uppercase) in demonstrate use of the descriptive form. Used "DN" (uppercase) in
the last extensible match example to remind the reader to treat the the last extensible match example to remind the reader to treat the
<dnattrs> production as case insensitive. Reworded the description <dnattrs> production as case insensitive. Reworded the description
of the fourth escaping mechanism example to avoid making assumptions of the fourth escaping mechanism example to avoid making assumptions
about byte order. Added text to the fifth escaping mechanism example about byte order. Added text to the fifth escaping mechanism example
to spell out what the non-ASCII characters are in Unicode terms. to spell out what the non-ASCII characters are in Unicode terms.
"Security Considerations" section: added references to [Protocol] and "Security Considerations" section: added references to [RFC4511] and
[AuthMeth]. [RFC4513].
"Normative References" section: renamed from "References" per new RFC "Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the guidelines. Changed from [1] style to [RFC4511] style throughout the
document. Added entries for [Unicode], [RFC2119], [AuthMeth], document. Added entries for [Unicode], [RFC2119], [RFC4513],
[Models], and [Roadmap] and updated the UTF-8 reference. Replaced [RFC4512], and [RFC4510] and updated the UTF-8 reference. Replaced
RFC 822 reference with a reference to RFC 2234. RFC 822 reference with a reference to RFC 4234.
"Informative References" section: (new section) moved [X.690] to this "Informative References" section: (new section) moved [X.690] to this
section. Added a reference to [LDAPURL]. section. Added a reference to [RFC4516].
"Acknowledgments" section: added. "Acknowledgements" section: added.
"Appendix A: Changes Since RFC 2254" section: added. "Appendix A: Changes Since RFC 2254" section: added.
"Appendix B: Changes Since Previous Document Revision" section:
added.
Surrounded the names of all ABNF productions with "<" and ">" where Surrounded the names of all ABNF productions with "<" and ">" where
they are used in descriptive text. they are used in descriptive text.
Replaced all occurrences of "LDAPv3" with "LDAP." Replaced all occurrences of "LDAPv3" with "LDAP."
12. Appendix B: Changes Since Previous Document Revision Authors' Addresses
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-filter-08.txt. Note that when
appropriate these changes are also included in Appendix A, but are
also included here for the benefit of the people who have already
reviewed draft-ietf-ldapbis-filter-08.txt. This section will be
removed before this document is published as an RFC.
12.1. Technical Changes
Removed the third option from the "extensible" production that
allowed creation of a MatchingRuleAssertion that only had a
matchValue (disallowed By [Protocol]). Added "(" and ")" around the
components of the <extensible> subproductions for clarity.
12.2. Editorial Changes
"Introduction" section: referenced [Roadmap] upon first use of LDAP Mark Smith, Editor
and expanded the paragraph that begins "This document is an integral Pearl Crescent, LLC
part of the LDAP technical specification..." to match the text used 447 Marlpool Dr.
in [Protocol]. Saline, MI 48176
USA
"LDAP Search Filter Definition" section: reworded the last paragraph Phone: +1 734 944-2856
for clarity. EMail: mcs@pearlcrescent.com
"Examples" section: Replaced the numeric OID in the first extensible Tim Howes
match example with "caseExactMatch" to demonstrate use of the Opsware, Inc.
descriptive form. Used "DN" (uppercase) in the last extensible match 599 N. Mathilda Ave.
example to remind the reader to treat the <dnattrs> production as Sunnyvale, CA 94085
case insensitive. Reworded the description of the fourth escaping USA
mechanism example to avoid making assumptions about byte order.
Added text to the fifth escaping mechanism example to spell out what
the non-ASCII characters are in Unicode terms.
References: added [LDAPURL] and moved [X.690] to "Informative Phone: +1 408 744-7509
References." EMail: howes@opsware.com
"Acknowledgements" section: added the sentence "RFC 2254 was a Full Copyright Statement
product of the IETF ASID Working Group."
Changed these two sections to unnumbered ones: "Intellectual Property Copyright (C) The Internet Society (2006).
Rights" and "Full Copyright."
Surrounded the names of all ABNF productions with "<" and ">" where This document is subject to the rights, licenses and restrictions
they are used in descriptive text. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Replaced all occurrences of "LDAPv3" with "LDAP." This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Rights Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 13, line 14 skipping to change at page 12, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Acknowledgement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet Draft expires on 16 May 2005. Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 74 change blocks. 
229 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/