draft-ietf-ldapbis-filter-00.txt   draft-ietf-ldapbis-filter-01.txt 
Network Working Group M. Smith, Editor Network Working Group M. Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp. Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2254 T. Howes Obsoletes: RFC 2254 T. Howes
Expires: 20 August 2001 Loudcloud, Inc. Expires: 7 November 2001 Loudcloud, Inc.
20 February 2001 7 May 2001
The String Representation of LDAP Search Filters The String Representation of LDAP Search Filters
<draft-ietf-ldapbis-filter-00.txt> <draft-ietf-ldapbis-filter-01.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 43 skipping to change at page 1, line 43
ldapbis@openldap.org>. After appropriate review and discussion, this ldapbis@openldap.org>. After appropriate review and discussion, this
document will be submitted as a Standards Track replacement for RFC document will be submitted as a Standards Track replacement for RFC
2254. 2254.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
2. Abstract 2. Abstract
The Lightweight Directory Access Protocol (LDAP) [RFC2251] defines a The Lightweight Directory Access Protocol (LDAP) [RFC2251bis] defines
network representation of a search filter transmitted to an LDAP a 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. This representing these search filters in a human-readable form. This
document defines a human-readable string format for representing the document defines a human-readable string format for representing the
full range of possible LDAP version 3 search filters, including full range of possible LDAP version 3 search filters, including
extended match filters. extended match filters.
This document replaces RFC 2254. See Appendix A for a list of This document replaces RFC 2254. See Appendix A for a list of
changes relative to RFC 2254. changes relative to RFC 2254.
3. LDAP Search Filter Definition 3. LDAP Search Filter Definition
An LDAPv3 search filter is defined in Sections 4.5.1 of [RFC2251] as An LDAPv3 search filter is defined in Sections 4.5.1 of [RFC2251bis]
follows: as follows:
Filter ::= CHOICE { Filter ::= CHOICE {
and [0] SET OF Filter, and [0] SET OF Filter,
or [1] SET OF Filter, or [1] SET OF 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,
present [7] AttributeDescription, present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion, approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion extensibleMatch [9] MatchingRuleAssertion
} }
SubstringFilter ::= SEQUENCE { SubstringFilter ::= SEQUENCE {
type AttributeDescription, type AttributeDescription,
-- at least one must be present -- at least one must be present
substrings SEQUENCE OF CHOICE { substrings SEQUENCE OF CHOICE {
initial [0] LDAPString, initial [0] AssertionValue,
any [1] LDAPString, any [1] AssertionValue,
final [2] LDAPString final [2] AssertionValue
} }
} }
AttributeValueAssertion ::= SEQUENCE { AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription, attributeDesc AttributeDescription,
assertionValue AssertionValue assertionValue AssertionValue
} }
MatchingRuleAssertion ::= SEQUENCE { MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleID OPTIONAL, matchingRule [1] MatchingRuleID OPTIONAL,
skipping to change at page 3, line 15 skipping to change at page 3, line 15
MatchingRuleID ::= LDAPString MatchingRuleID ::= LDAPString
AssertionValue ::= OCTET STRING AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING LDAPString ::= OCTET STRING
where the LDAPString above is limited to the UTF-8 encoding of the where the LDAPString above is limited to the UTF-8 encoding of the
ISO 10646 character set [RFC2279]. The AttributeDescription is a ISO 10646 character set [RFC2279]. The AttributeDescription is a
string representation of the attribute description and is defined in string representation of the attribute description and is defined in
[RFC2251]. The AttributeValue and AssertionValue OCTET STRING have [RFC2251bis]. The AttributeValue and AssertionValue OCTET STRING
the form defined in [RFC2252]. The Filter is encoded for have the form defined in [RFC2252bis]. The Filter is encoded for
transmission over a network using the Basic Encoding Rules defined in transmission over a network using the Basic Encoding Rules defined in
[ASN.1], with simplifications described in [RFC2251]. [ASN.1], with simplifications described in [RFC2251bis].
4. String Search Filter Definition 4. String Search Filter Definition
The string representation of an LDAP search filter is defined by the The string representation of an LDAP search filter is defined by the
following grammar, following the ABNF notation defined in [RFC2234]. following grammar, following the ABNF notation defined in [RFC2234].
The filter format uses a prefix notation. The filter format uses a prefix notation.
filter = "(" filtercomp ")" filter = "(" filtercomp ")"
filtercomp = and / or / not / item filtercomp = and / or / not / item
and = "&" filterlist and = "&" filterlist
skipping to change at page 3, line 43 skipping to change at page 3, line 43
simple = attr filtertype assertionvalue simple = attr filtertype assertionvalue
filtertype = equal / approx / greater / less filtertype = equal / approx / greater / less
equal = "=" equal = "="
approx = "~=" approx = "~="
greater = ">=" greater = ">="
less = "<=" less = "<="
extensible = attr [":dn"] [":" matchingrule] ":=" assertionvalue extensible = attr [":dn"] [":" matchingrule] ":=" assertionvalue
/ [":dn"] ":" matchingrule ":=" assertionvalue / [":dn"] ":" matchingrule ":=" assertionvalue
present = attr "=*" present = attr "=*"
substring = attr "=" [initial] any [final] substring = attr "=" [initial] any [final]
initial = value initial = assertionvalue
any = "*" *(value "*") any = "*" *(assertionvalue "*")
final = value final = assertionvalue
attr = <AttributeDescription from Section 4.1.5 of [RFC2251]> attr = <AttributeDescription from Section 4.1.5 of [RFC2251bis]>
matchingrule = <MatchingRuleId from Section 4.1.9 of [RFC2251]> matchingrule = <MatchingRuleId from Section 4.1.9 of [RFC2251bis]>
value = <AttributeValue from Section 4.1.6 of [RFC2251] assertionvalue = <AssertionValue from Section 4.1.7 of [RFC2251bis]
encoded using the valueencoding rule>
assertionvalue = <AssertionValue from Section 4.1.7 of [RFC2251]
encoded using the valueencoding rule> encoded using the valueencoding rule>
valueencoding = 0*(normal / escaped) valueencoding = 0*(normal / escaped)
normal = %x01-27 / %x2b-5b / %x5d-7f normal = %x01-27 / %x2b-5b / %x5d-7f
escaped = " 0" / "2" ( "8" / "9" / "a" ) / "5c" escaped = "\" hex hex
hex = %x30-39 / %x41-46 / %x61-66
The attr and matchingrule constructs are as described in the The attr and matchingrule constructs are as described in the
corresponding section of [RFC2251] given above. corresponding section of [RFC2251bis] given above.
The valueencoding rule provides that the characters "*" (ASCII 0x2a), The valueencoding rule provides that the characters "*" (ASCII 0x2a),
"(" (ASCII 0x28), ")" (ASCII 0x29), " 0x00) are represented as the "(" (ASCII 0x28), ")" (ASCII 0x29), "\" (ASCII 0x5c), and NUL (ASCII
backslash " followed by the two hexadecimal digits representing the 0x00) are represented as the backslash "\" character (ASCII 0x5c)
ASCII value of the encoded character. followed by the two hexadecimal digits representing the ASCII value
of the encoded character.
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 characters besides the represented as a NUL-terminated string. Other characters besides the
ones listed above may be escaped using this mechanism, for example, ones listed above may be escaped using this mechanism, for example,
non-printing characters. non-printing characters. Each octet of 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 example, the filter checking whether the "cn" attribute contained For example, the filter checking whether the "cn" attribute contained
a value with the character "*" anywhere in it would be represented as a value with the character "*" anywhere in it would be represented as
"(cn=*\2a*)". "(cn=*\2a*)".
Note that although both the substring and present productions in the Note that although both the substring and present productions in the
grammar above can produce the "attr=*" construct, this construct is grammar above can produce the "attr=*" construct, this construct is
used only to denote a presence filter. used only to denote a presence filter.
5. Examples 5. Examples
skipping to change at page 6, line 28 skipping to change at page 6, line 31
(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;binary=\04\02\48\69) (1.3.6.1.4.1.1466.0;binary=\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 a
"*" in a value, preventing it from being interpreted as a substring "*" in an assertion value, preventing it from being interpreted as a
indicator. The third illustrates the escaping of the backslash substring indicator. The third illustrates the escaping of the
character. backslash character.
The fourth example shows a filter searching for the four-byte value The fourth example shows a filter searching for the four-byte value
0x00000004, illustrating the use of the escaping mechanism to 0x00000004, 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. represent various non-ASCII UTF-8 characters.
The sixth and final example demonstrates assertion of a BER encoded The sixth and final example demonstrates assertion of a BER encoded
value. value.
6. Security Considerations 6. 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 RFC 2251 Please refer to the Security Considerations sections of [RFC2251bis],
[RFC2251], RFC 2829 [RFC2829], and RFC 2830 [RFC2830] for more [RFC2829bis], and [RFC2830bis] for more information.
information.
7. References 7. References
[ASN.1] Specification of ASN.1 encoding rules: Basic, Canonical, and [ASN.1] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994. Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory [RFC2251bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
Access Protocol (v3)", RFC 2251, December 1997. (v3)", a work in progress.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, [RFC2252bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
"Lightweight Directory Access Protocol (v3): Attribute Syntax (v3): Attribute Syntax Definitions", a work in progress.
Definitions", RFC 2252, December 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998. RFC 2279, January 1998.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, [RFC2829bis] IETF LDAPBis WG, "Authentication Methods for LDAP", a
"Authentication Methods for LDAP", RFC 2829, May 2000. work in progress.
[RFC2830] Hodges, J., Morgan, R., Wahl, M., "Lightweight Directory [RFC2830bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
Access Protocol (v3): Extension for Transport Layer Security", RFC (v3): Extension for Transport Layer Security", a work in progress.
2830, May 2000.
8. Acknowledgments 8. Acknowledgments
This document is an update to RFC 2254 by Tim Howes. Changes This document is an update to RFC 2254 by Tim Howes. Changes
included in this revised specification are based upon discussions included in this revised specification are based upon discussions
among the authors, discussions within the LDAP (v3) Revision Working among the authors, discussions within the LDAP (v3) Revision Working
Group (ldapbis), and discussions within other IETF Working Groups. Group (ldapbis), and discussions within other IETF Working Groups.
The contributions of individuals in these working groups is The contributions of individuals in these working groups is
gratefully acknowledged. gratefully acknowledged.
skipping to change at page 8, line 44 skipping to change at page 8, line 45
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Appendix A: Changes Since RFC 2254 11. Appendix A: Changes Since RFC 2254
11.1. Technical Changes 11.1. Technical Changes
"String Search Filter Definition" section: replaced the "value" rule "String Search Filter Definition" section: replaced the "value" rule
with a new "assertionvalue" rule within the "simple" and "extensible" with a new "assertionvalue" rule within the "simple", "extensible",
rules. Added angle brackets around free-form prose in the "attr", and "substring" ("initial", "any", and "final") rules. This matches
"matchingrule", and "value" rules. Introduced the "valueencoding" a change made in [RFC22521bis]. Added angle brackets around free-
and associated "normal" and "escaped" rules to reduce the dependence form prose in the "attr", "matchingrule", and "value" rules.
on descriptive text. Introduced the "valueencoding" and associated "normal" and "escaped"
rules to reduce the dependence on descriptive text.
11.2. Editorial Changes 11.2. Editorial Changes
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 Tim's affiliation and contact document editor and updated Tim's affiliation and contact
information. information.
Copyright: changed the year to 2001. Copyright: changed the year to 2001.
"Abstract" section: updated second paragraph to indicate that RFC "Abstract" section: updated second paragraph to indicate that RFC
2254 is replaced by this document (instead of RFC 1960). 2254 is replaced by this document (instead of RFC 1960).
"LDAP Search Filter Definition" section: made corrections to the "LDAP Search Filter Definition" section: made corrections to the
LDAPv3 search filter ABNF so it matches RFC 2251. In particular, the LDAPv3 search filter ABNF so it matches that used in [RFC2251bis].
"at least one must be present" comment and the "substrings" label In particular, the "at least one must be present" comment and the
were added to the SubstringFilter initial/any/final sequence and the "substrings" label were added to the SubstringFilter
second element of the AttributeValueAssertion was changed from initial/any/final sequence, the second element of the
"attributeValue AttributeValue" to "assertionValue AssertionValue." AttributeValueAssertion was changed from "attributeValue
AttributeValue" to "assertionValue AssertionValue", and the
occurrences of "LDAPString" were replaced with "AssertionValue"
within the initial, any, and final elements of the substrings choice.
"Search Filter Definition" section: clarified the definition of "String Search Filter Definition" section: clarified the definition
AttributeValue from RFC 2251 section 4.1.6 (special handling is of 'value' (now 'assertionvalue') to take into account the fact that
required for some characters). it is not precisely an AttributeAssertion from [RFC2251bis] section
4.1.6 (special handling is required for some characters). Added a
note that each octet of a character to be escaped is replaced by a
backslash and two hex digits, which form a single octet in the code
of the character (text taken from the [RFC2253bis] document).
"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;binary=\04\02\48\69). (1.3.6.1.4.1.1466.0;binary=\04\02\48\69). Replaced one occurrence of
"a value" with "an assertion value".
"Security Considerations" section: added references to RFC 2251, RFC "Security Considerations" section: added references to [RFC2251bis],
2829, and RFC 2830. [RFC2829bis], and [RFC2830bis].
"References" section: changed from [1] style to [RFC2251] style "References" section: changed from [1] style to [RFC2251bis] style
throughout the document. Added entries for RFC 2829 and RFC 2830 and throughout the document. Added entries for [RFC2829bis] and
updated UTF-8 reference to RFC 2279. Replaced RFC 822 reference with [RFC2830bis] and updated UTF-8 reference to RFC 2279. Replaced RFC
a RFC 2234. 822 reference with a reference to RFC 2234.
"Acknowledgments" section: added. "Acknowledgments" 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: "Appendix B: Changes Since Previous Document Revision" section:
added. added.
"Appendix C: Loose Ends" section: added.
"Table of Contents" section: added. "Table of Contents" section: added.
12. Appendix B: Changes Since Previous Document Revision 12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the last published revision, This appendix lists all changes relative to the last published
draft-smith-ldapv3-filter-update-01.txt. Note that these changes are revision, draft-ietf-ldapbis-filter-00.txt. Note that these changes
also included in Appendix A, but are included here for those who have are also included in Appendix A, but are included here for those who
already reviewed draft-smith-ldapv3-filter-update-01.txt. have already reviewed draft-ietf-ldapbis-filter-00.txt. This section
will be removed before this document is published as an RFC.
12.1. Technical Changes 12.1. Technical Changes
"String Search Filter Definition" section: replaced the "value" rule "String Search Filter Definition" section: replaced all occurrences
with a new "assertionvalue" rule within the "simple" and "extensible" of the "value" rule with "assertionvalue" within the "initial",
rules. Added angle brackets around free-form prose in the "attr", "any", and "final" rules. This was done to reflect changes made to
"matchingrule", and "value" rules. Introduced the "valueencoding" the ASN.1 definition of the Filter in [RFC2251bis]. Also, the
and associated "normal" and "escaped" rules to reduce the dependence "escaped" rule was revised and a "hex" rule was added to allow any
on descriptive text. character to be escaped.
12.2. Editorial Changes 12.2. Editorial Changes
Header: changed document from an individual submission to an ldapbis "LDAP Search Filter Definition" section: updated the ASN.1 definition
working group submission. Discussion referred to the ietf- of the Filter to match that used in [RFC2251bis]. Specifically, the
ldapbis@openldap.org mailing list. occurrences of LDAPString within the initial, any, and final elements
of the substrings element were replaced with AssertionValue.
Header and "Authors' Addresses" sections: added "editor" next to Mark
Smith's name.
Copyright: changed the year to 2001.
"LDAP Search Filter Definition" section: made corrections to the
LDAPv3 search filter ABNF so it matches RFC 2251. In particular, the
"at least one must be present" comment and the "substrings" label
were added to the SubstringFilter initial/any/final sequence and the
second element of the AttributeValueAssertion was changed from
"attributeValue AttributeValue" to "assertionValue AssertionValue."
"Examples" section: added the "(seeAlso=)" example to demonstrate
assertion of a zero-length value.
References: changed from [1] style to [RFC2251] style throughout the
document. Replaced reference to RFC 822 with a reference to RFC
2234.
"Acknowledgments" section: added. "String Search Filter Definition" section: corrected truncated text
that described the valueencoding rule (the text was truncated after
(ASCII 0x29)). Added a note that each octet of a character to be
escaped is replaced by a backslash and two hex digits, which form a
single octet in the code of the character (text taken from the
[RFC2253bis] document).
"Appendix C: Loose Ends": removed RFC 2234 ABNF item and added a new "Examples" section: replaced one occurrence of "a value" with "an
item about possible changes to the LDAPv3 protocol document that may assertion value".
result in changes to this document.
13. Appendix C: Loose Ends References: updated references to refer to LDAPBis WG documents.
There has been some discussion on the LDAPBIS working group "Appendix C: Loose Ends": removed this section entirely.
discussion list about how to modify the LDAPv3 protocol specification
to support use of substring filters within an extensible match
filter, which led to further discussion about whether the definition
of the SubstringFilter should be changed from LDAPString to
AssertionValue. Once that issue is resolved, this filter
specification will likely need to be revised to accommodate the
group's decision.
This Internet Draft expires on 20 August 2001. This Internet Draft expires on 7 November 2001.
1. Status of this Memo............................................1 1. Status of this Memo............................................1
2. Abstract.......................................................1 2. Abstract.......................................................1
3. LDAP Search Filter Definition..................................2 3. LDAP Search Filter Definition..................................2
4. String Search Filter Definition................................3 4. String Search Filter Definition................................3
5. Examples.......................................................5 5. Examples.......................................................5
6. Security Considerations........................................6 6. Security Considerations........................................6
7. References.....................................................7 7. References.....................................................7
8. Acknowledgments................................................7 8. Acknowledgments................................................7
9. Authors' Address...............................................7 9. Authors' Address...............................................7
10. Full Copyright Statement.......................................8 10. Full Copyright Statement.......................................8
11. Appendix A: Changes Since RFC 2254.............................8 11. Appendix A: Changes Since RFC 2254.............................8
11.1. Technical Changes...........................................8 11.1. Technical Changes...........................................8
11.2. Editorial Changes...........................................9 11.2. Editorial Changes...........................................9
12. Appendix B: Changes Since Previous Document Revision...........10 12. Appendix B: Changes Since Previous Document Revision...........10
12.1. Technical Changes...........................................10 12.1. Technical Changes...........................................10
12.2. Editorial Changes...........................................10 12.2. Editorial Changes...........................................10
13. Appendix C: Loose Ends.........................................11
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/