source4/ldap_server/devdocs/rfc4515.txt

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