[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: I-D ACTION:draft-ietf-ldapbis-filter-08.txt
I have completed my review of the I-D. While it's my personal
opinion that the revisions made are consistent with WG
consensus, I did find a few minor problems which likely should
be address prior to progression. Most significantly, a few
aspects of the I-D need updated to be consistent with the
ASN.1 and ABNF definitions of [Protocol] and [Models] (as
possibly revised per recent discussions). I suggest the
<extensible> rule be clarified and examples changed
slightly to demonstrate case-insensitive. I also make a
few editorial suggestions to improve clarity and/or to
remove nits. See attachment for details.
Kurt
At 01:35 PM 10/25/2004, Kurt D. Zeilenga wrote:
>Please review this I-D to ensure the changes made (or not made)
>in this revision are consistent with WG consensus, as reflected
>in the summary of the WG Last Call and follow-up discussions.
>The chairs intend to progress this revision to the AD within
>the next week.
>
>-- Kurt, LDAPBIS co-chair
>
>At 01:03 PM 10/25/2004, Internet-Drafts@ietf.org wrote:
>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>This draft is a work item of the LDAP (v3) Revision Working Group of the IETF.
>>
>> Title : LDAP: String Representation of Search Filters
>> Author(s) : M. Smith, T. Howes
>> Filename : draft-ietf-ldapbis-filter-08.txt
>> Pages : 12
>> Date : 2004-10-25
>>
>>LDAP search filters are transmitted in the LDAP protocol using a
>>binary representation that is appropriate for use on the network.
>>This document defines a human-readable string representation of LDAP
>>search filters that is appropriate for use in LDAP URLs and in other
>>applications.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-filter-08.txt
>>
>>To remove yourself from the I-D Announcement list, send a message to
>>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the username
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>> "get draft-ietf-ldapbis-filter-08.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>> mailserv@ietf.org.
>>In the body type:
>> "FILE /internet-drafts/draft-ietf-ldapbis-filter-08.txt".
>>
>>NOTE: The mail server at ietf.org can return the document in
>> MIME-encoded form by using the "mpack" utility. To use this
>> feature, insert the command "ENCODING mime" before the "FILE"
>> command. To decode the response(s), you will need "munpack" or
>> a MIME-compliant mail reader. Different MIME-compliant mail readers
>> exhibit different behavior, especially when dealing with
>> "multipart" MIME messages (i.e. documents which have been split
>> up into multiple messages), so check your local documentation on
>> how to manipulate these messages.
>>
>>
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>Content-Type: text/plain
>>Content-ID: <2004-10-25162118.I-D@ietf.org>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-ldapbis-filter-08.txt
>>
>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapbis-filter-08.txt>
>
>
>Network Working Group M. Smith, Editor
>Request for Comments: DRAFT Pearl Crescent, LLC
>Obsoletes: RFC 2254 T. Howes
>Expires: 24 April 2005 Opsware, Inc.
> 24 October 2004
>
>
> LDAP: String Representation of Search Filters
> <draft-ietf-ldapbis-filter-08.txt>
>
>
>
>Status of this Memo
>
> 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
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as
> Internet-Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> 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
> http://www.ietf.org/1id-abstracts.html
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html
>
> Copyright (C) The Internet Society (2004). All Rights Reserved.
> Please see the Full Copyright section near the end of this document
> for more information.
>
>
>
>
>
>
>
>
>Abstract
>
> LDAP search filters are transmitted in the LDAP protocol using a
> binary representation that is appropriate for use on the network.
> This document defines a human-readable string representation of LDAP
> search filters that is appropriate for use in LDAP URLs and in other
> applications.
>
>Table of Contents
>
> Status of this Memo............................................1
> Abstract.......................................................2
> Table of Contents..............................................2
>1. Introduction...................................................2
>2. LDAP Search Filter Definition..................................3
>3. String Search Filter Definition................................4
>4. Examples.......................................................6
>5. Security Considerations........................................7
>6. IANA Considerations............................................7
>7. Normative References...........................................7
>8. Informative References.........................................8
>9. Acknowledgments................................................8
>10. Authors' Addresses.............................................8
>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. Editorial Changes...........................................11
>13. Intellectual Property Rights...................................11
>14. Full Copyright.................................................12
Last two sections should be unnumbered sections.
>
>1. Introduction
I would like to see a reference to [Roadmap] on first use of LDAP
(as [Roadmap] is the (LDAP TS). Maybe a slight rewording would
facilitate that.
> The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a
> network representation of a search filter transmitted to an LDAP
> server. Some applications may find it useful to have a common way of
> representing these search filters in a human-readable form; LDAP URLs
cite [LDAPURL].
> are an example of one such application. This document defines a
> human-readable string format for representing the full range of
> possible LDAP version 3 search filters, including extended match
> filters.
>
> This document is an integral part of the LDAP Technical Specification
> [Roadmap].
>
> This document replaces RFC 2254. Changes to RFC 2254 are summarized
> in Appendix A.
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in BCP 14 [RFC2119].
>
>2. LDAP Search Filter Definition
>
> An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
> follows:
>
> Filter ::= CHOICE {
> and [0] SET SIZE (1..MAX) OF filter Filter,
> or [1] SET SIZE (1..MAX) OF filter Filter,
> not [2] Filter,
> equalityMatch [3] AttributeValueAssertion,
> substrings [4] SubstringFilter,
> greaterOrEqual [5] AttributeValueAssertion,
> lessOrEqual [6] AttributeValueAssertion,
> present [7] AttributeDescription,
> approxMatch [8] AttributeValueAssertion,
> extensibleMatch [9] MatchingRuleAssertion }
>
> SubstringFilter ::= SEQUENCE {
> type AttributeDescription,
> -- initial and final can occur at most once
> substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
> initial [0] AssertionValue,
> any [1] AssertionValue,
> final [2] AssertionValue } }
>
> AttributeValueAssertion ::= SEQUENCE {
> attributeDesc AttributeDescription,
> assertionValue AssertionValue }
>
> MatchingRuleAssertion ::= SEQUENCE {
> matchingRule [1] MatchingRuleId OPTIONAL,
> type [2] AttributeDescription OPTIONAL,
> matchValue [3] AssertionValue,
> dnAttributes [4] BOOLEAN DEFAULT FALSE }
>
> AttributeDescription ::= LDAPString
> -- Constrained to <attributedescription>
> -- [Models]
>
> AttributeValue ::= OCTET STRING
>
> MatchingRuleId ::= LDAPString
>
> AssertionValue ::= OCTET STRING
>
> LDAPString ::= OCTET STRING -- UTF-8 encoded,
> -- [Unicode] characters
>
> The AttributeDescription is a string representation of the attribute
> description and is defined in [Protocol].
This might be better worded:
The AttributeDescription, as defined in [Protocol], is a string
representation of the attribute description [Models].
to clarify that attribute descriptions are discussed in [Models].
The AttributeValue and
> AssertionValue OCTET STRING have the form defined in [Syntaxes]. The
> Filter is encoded for transmission over a network using the Basic
> Encoding Rules (BER) defined in [X.690], with simplifications
> described in [Protocol].
>
>3. String Search Filter Definition
>
> The string representation of an LDAP search filter is a string of
> UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
> by the following grammar, following the ABNF notation defined in
> [RFC2234]. The productions used that are not defined here are
> defined in section 1.4 (Common ABNF Productions) of [Models] unless
> otherwise noted. The filter format uses a prefix notation.
>
> filter = LPAREN filtercomp RPAREN
> filtercomp = and / or / not / item
> and = AMPERSAND filterlist
> or = VERTBAR filterlist
> not = EXCLAMATION filter
> filterlist = 1*filter
> item = simple / present / substring / extensible
> simple = attr filtertype assertionvalue
> filtertype = equal / approx / greaterorequal / lessorequal
> equal = EQUALS
> approx = TILDE EQUALS
> greaterorequal = RANGLE EQUALS
> lessorequal = LANGLE EQUALS
> extensible = attr [dnattrs]
> [matchingrule] COLON EQUALS assertionvalue
> / [dnattrs]
> matchingrule COLON EQUALS assertionvalue
> / COLON EQUALS assertionvalue
The grouping notation should be used here to improve clarity.
That is, ( ... ) / ( ... ) / ( ... ). As presented, it
appears that ":=value" would be a valid extensible production.
> present = attr EQUALS ASTERISK
> substring = attr EQUALS [initial] any [final]
> initial = assertionvalue
> any = ASTERISK *(assertionvalue ASTERISK)
> final = assertionvalue
> attr = attributedescription
> ; The attributedescription rule is defined in
> ; Section 2.5 of [Models].
> dnattrs = COLON "dn"
> matchingrule = COLON oid
> assertionvalue = valueencoding
>
> ; The <valueencoding> rule is used to encode an <AssertionValue>
> ; from Section 4.1.6 of [Protocol].
> valueencoding = 0*(normal / escaped)
> normal = UTF1SUBSET / UTFMB
> escaped = ESC HEX HEX
> UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
> ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
> ; RPAREN, ASTERISK, and ESC.
> EXCLAMATION = %x21 ; exclamation mark ("!")
> AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
> ASTERISK = %x2A ; asterisk ("*")
> COLON = %x3A ; colon (":")
> VERTBAR = %x7C ; vertical bar (or pipe) ("|")
> TILDE = %x7E ; tilde ("~")
>
>
> Note that although both the <substring> and <present> productions in
> the grammar above can produce the "attr=*" construct, this construct
> is used only to denote a presence filter.
>
> The <valueencoding> rule ensures that the entire filter string is a
> valid UTF-8 string and provides that the octets that represent the
> ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
> 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
> backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
> representing the value of the encoded octet.
>
> This simple escaping mechanism eliminates filter-parsing ambiguities
> and allows any filter that can be represented in LDAP to be
> represented as a NUL-terminated string. Other octets that are part of
> the <normal> set may be escaped using this mechanism, for example,
> non-printing ASCII characters.
>
> For AssertionValues that contain UTF-8 character data, 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.
>
Delete this blank line (see below)
> For example, the filter checking whether the "cn" attribute contained
> a value with the character "*" anywhere in it would be represented as
> "(cn=*\2a*)".
>
> As indicated by the valueencoding rule, implementations MUST escape
wrap valueencoding in <>, as done for other rule appearance in
the prose.
> all octets greater than 0x7F that are not part of a valid UTF-8
> encoding sequence when they generate a string representation of a
> search filter. Implementations SHOULD accept as input strings that
> are not valid UTF-8 strings. This is necessary because RFC 2254 did
> not clearly define the term "string representation" (and in
> particular did not mention that the string representation of an LDAP
> search filter is a string of UTF-8 encoded Unicode characters).
>
>4. Examples
>
> This section gives a few examples of search filters written using
> this notation.
>
> (cn=Babs Jensen)
> (!(cn=Tim Howes))
> (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
> (o=univ*of*mich*)
> (seeAlso=)
>
> The following examples illustrate the use of extensible matching.
>
> (cn:1.2.3.4.5:=Fred Flintstone)
> (cn:=Betty Rubble)
> (sn:dn:2.4.6.8.10:=Barney Rubble)
> (o:dn:=Ace Industry)
> (:1.2.3:=Wilma Flintstone)
> (:dn:2.4.6.8.10:=Dino)
Please change one of the :dn examples to uses :DN to remind folks
that its case insensitive, e.g.,
(:DN:2.4.6.8.10:=Dino)
Please change one of the :oid examples to use the descr form, e.g.
(cn:caseExactMatch:=Fred Flintstone)
> The first example shows use of the matching rule "1.2.3.4.5".
>
> The second example demonstrates use of a MatchingRuleAssertion form
> without a matchingRule.
>
> The third example illustrates the use of the ":oid" notation to
> indicate that matching rule "2.4.6.8.10" should be used when making
> comparisons, and that the attributes of an entry's distinguished name
> should be considered part of the entry when evaluating the match
> (indicated by the use of ":dn").
>
> The fourth example denotes an equality match, except that DN
> components should be considered part of the entry when doing the
> match.
>
> The fifth example is a filter that should be applied to any attribute
> supporting the matching rule given (since the attr has been omitted).
>
> The sixth and final example is also a filter that should be applied
> to any attribute supporting the matching rule given. Attributes
> supporting the matching rule contained in the DN should also be
> considered.
>
> The following examples illustrate the use of the escaping mechanism.
>
> (o=Parens R Us \28for all your parenthetical needs\29)
> (cn=*\2A*)
> (filename=C:\5cMyFile)
> (bin=\00\00\00\04)
> (sn=Lu\c4\8di\c4\87)
> (1.3.6.1.4.1.1466.0=\04\02\48\69)
>
> The first example shows the use of the escaping mechanism to
> represent parenthesis characters. The second shows how to represent a
> "*" in an assertion value, preventing it from being interpreted as a
> substring indicator. The third illustrates the escaping of the
> backslash character.
>
> The fourth example shows a filter searching for the four-byte value
> 0x00000004, illustrating the use of the escaping mechanism to
> represent arbitrary data, including NUL characters.
Without knowing the byte order of 0x00000004, one cannot say
that the \00\00\00\04 is the proper value encoding. Suggest
you instead use:
the four octet value 00 00 00 04 (hex).
or:
0x00000004 (big-endian, hex).
> The fifth example illustrates the use of the escaping mechanism to
> represent various non-ASCII UTF-8 characters.
Would be good to say what those characters are.
> The sixth and final example demonstrates assertion of a BER encoded
> value.
>
>5. Security Considerations
>
> This memo describes a string representation of LDAP search filters.
> While the representation itself has no known security implications,
> LDAP search filters do. They are interpreted by LDAP servers to
> select entries from which data is retrieved. LDAP servers should
> take care to protect the data they maintain from unauthorized access.
>
> Please refer to the Security Considerations sections of [Protocol]
> and [AuthMeth] for more information.
>
>6. IANA Considerations
>
> This document has no actions for IANA.
>
>7. Normative References
>
>[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
> Connection Level Security Mechanisms",
> draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
>
>[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
> draft-ietf-ldapbis-models-xx.txt, a work in progress.
>
>[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
>
>[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14 (also RFC 2119), March 1997.
>
>[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
> Specifications: ABNF", RFC 2234, November 1997.
>
>[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
> RFC 3629, November 2003.
>
>[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
> Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
>
>[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes",
> draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
>
>[Unicode] The Unicode Consortium, "The Unicode Standard, Version
> 3.2.0" is defined by "The Unicode Standard, Version 3.0"
> (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
> amended by the "Unicode Standard Annex #27: Unicode 3.1"
> (http://www.unicode.org/reports/tr27/) and by the "Unicode
> Standard Annex #28: Unicode 3.2."
>
>[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
> Distinguished Encoding Rules, ITU-T Recommendation X.690,
> 1994.
As understanding of BER is not required to properly implement
Filter string representation specification, this reference can
be viewed as Informative.
>8. Informative References
>
> None.
Add [LDAPURL].
>
>9. Acknowledgments
>
> This document replaces RFC 2254 by Tim Howes.
Please add:
RFC 2254 was a product of the IETF ASID Working Group.
and insert paragraph break here.
> Changes included in
> this revised specification are based upon discussions among the
> authors, discussions within the LDAP (v3) Revision Working Group
> (ldapbis), and discussions within other IETF Working Groups. The
> contributions of individuals in these working groups is gratefully
> acknowledged.
>
>
>10. Authors' Addresses
>
> 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
>
> Replaced [ISO 10646] reference with [Unicode].
>
> The following technical changes were made to the contents of the
> "String Search Filter Definition" section:
>
> Added statement that the string representation is a string of UTF-8
> encoded Unicode characters.
>
> Revised all of the ABNF to use common productions from [Models].
>
> Replaced the "value" rule with a new "assertionvalue" rule within the
> "simple", "extensible", and "substring" ("initial", "any", and
> "final") rules. This matches a change made in [Syntaxes].
>
> Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
> precisely reference productions from the [Models] and [Protocol]
> documents.
>
> "String Search Filter Definition" section: replaced "greater" and
> "less" with "greaterorequal" and "lessorequal" to avoid confusion.
>
> Introduced the "valueencoding" and associated "normal" and "escaped"
> rules to reduce the dependence on descriptive text. The "normal"
> production restricts filter strings to valid UTF-8 sequences.
>
> Added a third option to the "extensible" production to allow creation
> of a MatchingRuleAssertion that only has a matchValue.
>
> Added a statement about expected behavior in light of RFC 2254's lack
> of a clear definition of "string representation."
>
>
>
>11.2. Editorial Changes
>
> Changed document title to include "LDAP:" prefix.
>
> IESG Note: removed note about lack of satisfactory mandatory
> authentication mechanisms.
>
> Header and "Authors' Addresses" sections: added Mark Smith as the
> document editor and updated affiliation and contact information.
>
> "Table of Contents", "IANA Considerations", and "Intellectual
> Property Rights" sections: added.
>
> Copyright: updated per latest IETF guidelines.
>
> "Abstract" section: separated from introductory material.
>
> "Introduction" section: new section; separated from the Abstract.
> Updated second paragraph to indicate that RFC 2254 is replaced by
> this document (instead of RFC 1960). Added reference to the [Roadmap]
> document.
>
> "LDAP Search Filter Definition" section: made corrections to the
> LDAPv3 search filter ABNF so it matches that used in [Protocol].
>
> Clarified the definition of 'value' (now 'assertionvalue') to take
> into account the fact that it is not precisely an AttributeAssertion
> from [Protocol] 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
> represent a single octet.
>
> "Examples" section: added four additional examples: (seeAlso=),
> (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
> value" with "an assertion value". Corrected the description of this
> example: (sn:dn:2.4.6.8.10:=Barney Rubble).
>
> "Security Considerations" section: added references to [Protocol] and
> [AuthMeth].
>
> "Normative References" section: renamed from "References" per new RFC
> guidelines. Changed from [1] style to [Protocol] style throughout the
> document. Added entries for [Unicode], [RFC2119], [AuthMeth],
> [Models], and [Roadmap] and updated the UTF-8 reference. Replaced
> RFC 822 reference with a reference to RFC 2234.
>
> "Informative References" section: added for clarity.
>
> "Acknowledgments" section: added.
>
> "Appendix A: Changes Since RFC 2254" section: added.
>
> "Appendix B: Changes Since Previous Document Revision" section:
> added.
>
>12. Appendix B: Changes Since Previous Document Revision
>
> This appendix lists all changes relative to the previously published
> revision, draft-ietf-ldapbis-filter-07.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-07.txt. This section will be
> removed before this document is published as an RFC.
>
>
>12.1. Editorial Changes
>
> "Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
> paragraph with the version that says "each author" instead of "I."
>
> "Status of this Memo" section: added 2 paragraphs that were
> accidently removed from the -07 revision (one begins with "The list
> of current Internet-Drafts..." and the other begins with "The list of
> Internet-Draft Shadow Directories...."
>
>
>13. Intellectual Property Rights
>
> The IETF takes no position regarding the validity or scope of any
> Intellectual Property Rights or other rights that might be claimed to
> pertain to the implementation or use of the technology described in
> 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
> made any independent effort to identify any such rights. Information
> on the procedures with respect to rights in RFC documents can be
> found in BCP 78 and BCP 79.
>
> Copies of IPR disclosures made to the IETF Secretariat and any
> assurances of licenses to be made available, or the result of an
> attempt made to obtain a general license or permission for the use of
> such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository at
> http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention any
> copyrights, patents or patent applications, or other proprietary
> rights that may cover technology that may be required to implement
> this standard. Please address the information to the IETF at
> ietf-ipr@ietf.org.
>
>14. Full Copyright
>
> 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 24 April 2005.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>