| 1 |
|
|---|
| 2 |
|
|---|
| 3 |
|
|---|
| 4 |
|
|---|
| 5 |
|
|---|
| 6 |
|
|---|
| 7 | Network Working Group S. Legg
|
|---|
| 8 | Request for Comments: 4522 eB2Bcom
|
|---|
| 9 | Category: Standards Track June 2006
|
|---|
| 10 |
|
|---|
| 11 |
|
|---|
| 12 | Lightweight Directory Access Protocol (LDAP):
|
|---|
| 13 | The Binary Encoding Option
|
|---|
| 14 |
|
|---|
| 15 | Status of This Memo
|
|---|
| 16 |
|
|---|
| 17 | This document specifies an Internet standards track protocol for the
|
|---|
| 18 | Internet community, and requests discussion and suggestions for
|
|---|
| 19 | improvements. Please refer to the current edition of the "Internet
|
|---|
| 20 | Official Protocol Standards" (STD 1) for the standardization state
|
|---|
| 21 | and status of this protocol. Distribution of this memo is unlimited.
|
|---|
| 22 |
|
|---|
| 23 | Copyright Notice
|
|---|
| 24 |
|
|---|
| 25 | Copyright (C) The Internet Society (2006).
|
|---|
| 26 |
|
|---|
| 27 | Abstract
|
|---|
| 28 |
|
|---|
| 29 | Each attribute stored in a Lightweight Directory Access Protocol
|
|---|
| 30 | (LDAP) directory has a defined syntax (i.e., data type). A syntax
|
|---|
| 31 | definition specifies how attribute values conforming to the syntax
|
|---|
| 32 | are normally represented when transferred in LDAP operations. This
|
|---|
| 33 | representation is referred to as the LDAP-specific encoding to
|
|---|
| 34 | distinguish it from other methods of encoding attribute values. This
|
|---|
| 35 | document defines an attribute option, the binary option, that can be
|
|---|
| 36 | used to specify that the associated attribute values are instead
|
|---|
| 37 | encoded according to the Basic Encoding Rules (BER) used by X.500
|
|---|
| 38 | directories.
|
|---|
| 39 |
|
|---|
| 40 | Table of Contents
|
|---|
| 41 |
|
|---|
| 42 | 1. Introduction ....................................................2
|
|---|
| 43 | 2. Conventions .....................................................2
|
|---|
| 44 | 3. The Binary Option ...............................................2
|
|---|
| 45 | 4. Syntaxes Requiring Binary Transfer ..............................3
|
|---|
| 46 | 5. Attributes Returned in a Search .................................4
|
|---|
| 47 | 6. All User Attributes .............................................4
|
|---|
| 48 | 7. Conflicting Requests ............................................5
|
|---|
| 49 | 8. Security Considerations .........................................5
|
|---|
| 50 | 9. IANA Considerations .............................................5
|
|---|
| 51 | 10. References .....................................................5
|
|---|
| 52 | 10.1. Normative References ......................................5
|
|---|
| 53 | 10.2. Informative References ....................................6
|
|---|
| 54 |
|
|---|
| 55 |
|
|---|
| 56 |
|
|---|
| 57 |
|
|---|
| 58 | Legg Standards Track [Page 1]
|
|---|
| 59 | |
|---|
| 60 |
|
|---|
| 61 | RFC 4522 LDAP: The Binary Encoding Option June 2006
|
|---|
| 62 |
|
|---|
| 63 |
|
|---|
| 64 | 1. Introduction
|
|---|
| 65 |
|
|---|
| 66 | Each attribute stored in a Lightweight Directory Access Protocol
|
|---|
| 67 | (LDAP) directory [RFC4510] has a defined syntax (i.e., data type)
|
|---|
| 68 | which constrains the structure and format of its values.
|
|---|
| 69 |
|
|---|
| 70 | The description of each syntax [RFC4517] specifies how attribute or
|
|---|
| 71 | assertion values [RFC4512] conforming to the syntax are normally
|
|---|
| 72 | represented when transferred in LDAP operations [RFC4511]. This
|
|---|
| 73 | representation is referred to as the LDAP-specific encoding to
|
|---|
| 74 | distinguish it from other methods of encoding attribute values.
|
|---|
| 75 |
|
|---|
| 76 | This document defines an attribute option, the binary option, which
|
|---|
| 77 | can be used in an attribute description [RFC4512] in an LDAP
|
|---|
| 78 | operation to specify that the associated attribute values or
|
|---|
| 79 | assertion values are, or are requested to be, encoded according to
|
|---|
| 80 | the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500]
|
|---|
| 81 | directories, instead of the usual LDAP-specific encoding.
|
|---|
| 82 |
|
|---|
| 83 | The binary option was originally defined in RFC 2251 [RFC2251]. The
|
|---|
| 84 | LDAP technical specification [RFC4510] has obsoleted the previously
|
|---|
| 85 | defined LDAP technical specification [RFC3377], which included RFC
|
|---|
| 86 | 2251. The binary option was not included in the revised LDAP
|
|---|
| 87 | technical specification for a variety of reasons including
|
|---|
| 88 | implementation inconsistencies. No attempt is made here to resolve
|
|---|
| 89 | the known inconsistencies.
|
|---|
| 90 |
|
|---|
| 91 | This document reintroduces the binary option for use with certain
|
|---|
| 92 | attribute syntaxes, such as certificate syntax [RFC4523], that
|
|---|
| 93 | specifically require it. No attempt has been made to address use of
|
|---|
| 94 | the binary option with attributes of syntaxes that do not require its
|
|---|
| 95 | use. Unless addressed in a future specification, this use is to be
|
|---|
| 96 | avoided.
|
|---|
| 97 |
|
|---|
| 98 | 2. Conventions
|
|---|
| 99 |
|
|---|
| 100 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|---|
| 101 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|---|
| 102 | document are to be interpreted as described in BCP 14, RFC 2119
|
|---|
| 103 | [BCP14].
|
|---|
| 104 |
|
|---|
| 105 | 3. The Binary Option
|
|---|
| 106 |
|
|---|
| 107 | The binary option is indicated with the attribute option string
|
|---|
| 108 | "binary" in an attribute description. Note that, like all attribute
|
|---|
| 109 | options, the string representing the binary option is case
|
|---|
| 110 | insensitive.
|
|---|
| 111 |
|
|---|
| 112 |
|
|---|
| 113 |
|
|---|
| 114 |
|
|---|
| 115 | Legg Standards Track [Page 2]
|
|---|
| 116 | |
|---|
| 117 |
|
|---|
| 118 | RFC 4522 LDAP: The Binary Encoding Option June 2006
|
|---|
| 119 |
|
|---|
| 120 |
|
|---|
| 121 | Where the binary option is present in an attribute description, the
|
|---|
| 122 | associated attribute values or assertion values MUST be BER encoded
|
|---|
| 123 | (otherwise the values are encoded according to the LDAP-specific
|
|---|
| 124 | encoding [RFC4517] for the attribute's syntax). Note that it is
|
|---|
| 125 | possible for a syntax to be defined such that its LDAP-specific
|
|---|
| 126 | encoding is exactly the same as its BER encoding.
|
|---|
| 127 |
|
|---|
| 128 | In terms of the protocol [RFC4511], the binary option specifies that
|
|---|
| 129 | the contents octets of the associated AttributeValue or
|
|---|
| 130 | AssertionValue OCTET STRING are a complete BER encoding of the
|
|---|
| 131 | relevant value.
|
|---|
| 132 |
|
|---|
| 133 | The binary option is not a tagging option [RFC4512], so the presence
|
|---|
| 134 | of the binary option does not specify an attribute subtype. An
|
|---|
| 135 | attribute description containing the binary option references exactly
|
|---|
| 136 | the same attribute as the attribute description without the binary
|
|---|
| 137 | option. The supertype/subtype relationships of attributes with
|
|---|
| 138 | tagging options are not altered in any way by the presence or absence
|
|---|
| 139 | of the binary option.
|
|---|
| 140 |
|
|---|
| 141 | An attribute description SHALL be treated as unrecognized if it
|
|---|
| 142 | contains the binary option and the syntax of the attribute does not
|
|---|
| 143 | have an associated ASN.1 type [RFC4517], or the BER encoding of
|
|---|
| 144 | values of that type is not supported.
|
|---|
| 145 |
|
|---|
| 146 | The presence or absence of the binary option only affects the
|
|---|
| 147 | transfer of attribute and assertion values in the protocol; servers
|
|---|
| 148 | store any particular attribute value in a format of their choosing.
|
|---|
| 149 |
|
|---|
| 150 | 4. Syntaxes Requiring Binary Transfer
|
|---|
| 151 |
|
|---|
| 152 | The attribute values of certain attribute syntaxes are defined
|
|---|
| 153 | without an LDAP-specific encoding and are required to be transferred
|
|---|
| 154 | in the BER-encoded form. For the purposes of this document, these
|
|---|
| 155 | syntaxes are said to have a binary transfer requirement. The
|
|---|
| 156 | certificate, certificate list, certificate pair, and supported
|
|---|
| 157 | algorithm syntaxes [RFC4523] are examples of syntaxes with a binary
|
|---|
| 158 | transfer requirement. These syntaxes also have an additional
|
|---|
| 159 | requirement that the exact BER encoding must be preserved. Note that
|
|---|
| 160 | this is a property of the syntaxes themselves, and not a property of
|
|---|
| 161 | the binary option. In the absence of this requirement, LDAP clients
|
|---|
| 162 | would need to re-encode values using the Distinguished Encoding Rules
|
|---|
| 163 | (DER).
|
|---|
| 164 |
|
|---|
| 165 |
|
|---|
| 166 |
|
|---|
| 167 |
|
|---|
| 168 |
|
|---|
| 169 |
|
|---|
| 170 |
|
|---|
| 171 |
|
|---|
| 172 | Legg Standards Track [Page 3]
|
|---|
| 173 | |
|---|
| 174 |
|
|---|
| 175 | RFC 4522 LDAP: The Binary Encoding Option June 2006
|
|---|
| 176 |
|
|---|
| 177 |
|
|---|
| 178 | 5. Attributes Returned in a Search
|
|---|
| 179 |
|
|---|
| 180 | An LDAP search request [RFC4511] contains a list of the attributes
|
|---|
| 181 | (the requested attributes list) to be returned from each entry
|
|---|
| 182 | matching the search filter. An attribute description in the
|
|---|
| 183 | requested attributes list also implicitly requests all subtypes of
|
|---|
| 184 | the attribute type in the attribute description, whether through
|
|---|
| 185 | attribute subtyping or attribute tagging option subtyping [RFC4512].
|
|---|
| 186 |
|
|---|
| 187 | The requested attributes list MAY contain attribute descriptions with
|
|---|
| 188 | the binary option, but MUST NOT contain two attribute descriptions
|
|---|
| 189 | with the same attribute type and the same tagging options (even if
|
|---|
| 190 | only one of them has the binary option). The binary option in an
|
|---|
| 191 | attribute description in the requested attributes list implicitly
|
|---|
| 192 | applies to all the subtypes of the attribute type in the attribute
|
|---|
| 193 | description (however, see Section 7).
|
|---|
| 194 |
|
|---|
| 195 | Attributes of a syntax with the binary transfer requirement, if
|
|---|
| 196 | returned, SHALL be returned in the binary form (i.e., with the binary
|
|---|
| 197 | option in the attribute description and the associated attribute
|
|---|
| 198 | values BER encoded) regardless of whether the binary option was
|
|---|
| 199 | present in the request (for the attribute or for one of its
|
|---|
| 200 | supertypes).
|
|---|
| 201 |
|
|---|
| 202 | Attributes of a syntax without the binary transfer requirement, if
|
|---|
| 203 | returned, SHOULD be returned in the form explicitly requested. That
|
|---|
| 204 | is, if the attribute description in the requested attributes list
|
|---|
| 205 | contains the binary option, then the corresponding attribute in the
|
|---|
| 206 | result SHOULD be in the binary form. If the attribute description in
|
|---|
| 207 | the request does not contain the binary option, then the
|
|---|
| 208 | corresponding attribute in the result SHOULD NOT be in the binary
|
|---|
| 209 | form. A server MAY omit an attribute from the result if it does not
|
|---|
| 210 | support the requested encoding.
|
|---|
| 211 |
|
|---|
| 212 | Regardless of the encoding chosen, a particular attribute value is
|
|---|
| 213 | returned at most once.
|
|---|
| 214 |
|
|---|
| 215 | 6. All User Attributes
|
|---|
| 216 |
|
|---|
| 217 | If the list of attributes in a search request is empty or contains
|
|---|
| 218 | the special attribute description string "*", then all user
|
|---|
| 219 | attributes are requested to be returned.
|
|---|
| 220 |
|
|---|
| 221 | Attributes of a syntax with the binary transfer requirement, if
|
|---|
| 222 | returned, SHALL be returned in the binary form.
|
|---|
| 223 |
|
|---|
| 224 |
|
|---|
| 225 |
|
|---|
| 226 |
|
|---|
| 227 |
|
|---|
| 228 |
|
|---|
| 229 | Legg Standards Track [Page 4]
|
|---|
| 230 | |
|---|
| 231 |
|
|---|
| 232 | RFC 4522 LDAP: The Binary Encoding Option June 2006
|
|---|
| 233 |
|
|---|
| 234 |
|
|---|
| 235 | Attributes of a syntax without the binary transfer requirement and
|
|---|
| 236 | having a defined LDAP-specific encoding SHOULD NOT be returned in the
|
|---|
| 237 | binary form.
|
|---|
| 238 |
|
|---|
| 239 | Attributes of a syntax without the binary transfer requirement and
|
|---|
| 240 | without a defined LDAP-specific encoding may be returned in the
|
|---|
| 241 | binary form or omitted from the result.
|
|---|
| 242 |
|
|---|
| 243 | 7. Conflicting Requests
|
|---|
| 244 |
|
|---|
| 245 | A particular attribute could be explicitly requested by an attribute
|
|---|
| 246 | description and/or implicitly requested by the attribute descriptions
|
|---|
| 247 | of one or more of its supertypes, or by the special attribute
|
|---|
| 248 | description string "*". If the binary option is present in at least
|
|---|
| 249 | one, but not all, of these attribute descriptions then the effect of
|
|---|
| 250 | the request with respect to binary transfer is implementation
|
|---|
| 251 | defined.
|
|---|
| 252 |
|
|---|
| 253 | 8. Security Considerations
|
|---|
| 254 |
|
|---|
| 255 | When interpreting security-sensitive fields, and in particular fields
|
|---|
| 256 | used to grant or deny access, implementations MUST ensure that any
|
|---|
| 257 | matching rule comparisons are done on the underlying abstract value,
|
|---|
| 258 | regardless of the particular encoding used.
|
|---|
| 259 |
|
|---|
| 260 | 9. IANA Considerations
|
|---|
| 261 |
|
|---|
| 262 | The Internet Assigned Numbers Authority (IANA) has updated the LDAP
|
|---|
| 263 | attribute description option registry [BCP64] as indicated by the
|
|---|
| 264 | following template:
|
|---|
| 265 |
|
|---|
| 266 | Subject:
|
|---|
| 267 | Request for LDAP Attribute Description Option Registration
|
|---|
| 268 | Option Name: binary
|
|---|
| 269 | Family of Options: NO
|
|---|
| 270 | Person & email address to contact for further information:
|
|---|
| 271 | Steven Legg <steven.legg@eb2bcom.com>
|
|---|
| 272 | Specification: RFC 4522
|
|---|
| 273 | Author/Change Controller: IESG
|
|---|
| 274 |
|
|---|
| 275 | 10. References
|
|---|
| 276 |
|
|---|
| 277 | 10.1. Normative References
|
|---|
| 278 |
|
|---|
| 279 | [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
|
|---|
| 280 | Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|---|
| 281 |
|
|---|
| 282 |
|
|---|
| 283 |
|
|---|
| 284 |
|
|---|
| 285 |
|
|---|
| 286 | Legg Standards Track [Page 5]
|
|---|
| 287 | |
|---|
| 288 |
|
|---|
| 289 | RFC 4522 LDAP: The Binary Encoding Option June 2006
|
|---|
| 290 |
|
|---|
| 291 |
|
|---|
| 292 | [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
|
|---|
| 293 | Considerations for the Lightweight Directory Access
|
|---|
| 294 | Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
|---|
| 295 |
|
|---|
| 296 | [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
|---|
| 297 | (LDAP): Technical Specification Road Map", RFC RFC 4510,
|
|---|
| 298 | June 2006.
|
|---|
| 299 |
|
|---|
| 300 | [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
|
|---|
| 301 | (LDAP): The Protocol", RFC 4511, June 2006.
|
|---|
| 302 |
|
|---|
| 303 | [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
|
|---|
| 304 | (LDAP): Directory Information Models", RFC 4512, June
|
|---|
| 305 | 2006.
|
|---|
| 306 |
|
|---|
| 307 | [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
|---|
| 308 | (LDAP): Syntaxes and Matching Rules", RFC 4517, June
|
|---|
| 309 | 2006.
|
|---|
| 310 |
|
|---|
| 311 | [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
|
|---|
| 312 | (LDAP) Schema Definitions for X.509 Certificates", RFC
|
|---|
| 313 | 4523, June 2006.
|
|---|
| 314 |
|
|---|
| 315 | [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
|
|---|
| 316 | Information Technology - ASN.1 encoding rules:
|
|---|
| 317 | Specification of Basic Encoding Rules (BER), Canonical
|
|---|
| 318 | Encoding Rules (CER) and Distinguished Encoding Rules
|
|---|
| 319 | (DER).
|
|---|
| 320 |
|
|---|
| 321 | 10.2. Informative References
|
|---|
| 322 |
|
|---|
| 323 | [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
|
|---|
| 324 | Access Protocol (v3)", RFC 2251, December 1997.
|
|---|
| 325 |
|
|---|
| 326 | [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
|
|---|
| 327 | Protocol (v3): Technical Specification", RFC 3377,
|
|---|
| 328 | September 2002.
|
|---|
| 329 |
|
|---|
| 330 | [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
|
|---|
| 331 | Information technology - Open Systems Interconnection -
|
|---|
| 332 | The Directory: Overview of concepts, models and services
|
|---|
| 333 |
|
|---|
| 334 |
|
|---|
| 335 |
|
|---|
| 336 |
|
|---|
| 337 |
|
|---|
| 338 |
|
|---|
| 339 |
|
|---|
| 340 |
|
|---|
| 341 |
|
|---|
| 342 |
|
|---|
| 343 | Legg Standards Track [Page 6]
|
|---|
| 344 | |
|---|
| 345 |
|
|---|
| 346 | RFC 4522 LDAP: The Binary Encoding Option June 2006
|
|---|
| 347 |
|
|---|
| 348 |
|
|---|
| 349 | Author's Address
|
|---|
| 350 |
|
|---|
| 351 | Dr. Steven Legg
|
|---|
| 352 | eB2Bcom
|
|---|
| 353 | Suite 3, Woodhouse Corporate Centre
|
|---|
| 354 | 935 Station Street
|
|---|
| 355 | Box Hill North, Victoria 3129
|
|---|
| 356 | AUSTRALIA
|
|---|
| 357 |
|
|---|
| 358 | Phone: +61 3 9896 7830
|
|---|
| 359 | Fax: +61 3 9896 7801
|
|---|
| 360 | EMail: steven.legg@eb2bcom.com
|
|---|
| 361 |
|
|---|
| 362 |
|
|---|
| 363 |
|
|---|
| 364 |
|
|---|
| 365 |
|
|---|
| 366 |
|
|---|
| 367 |
|
|---|
| 368 |
|
|---|
| 369 |
|
|---|
| 370 |
|
|---|
| 371 |
|
|---|
| 372 |
|
|---|
| 373 |
|
|---|
| 374 |
|
|---|
| 375 |
|
|---|
| 376 |
|
|---|
| 377 |
|
|---|
| 378 |
|
|---|
| 379 |
|
|---|
| 380 |
|
|---|
| 381 |
|
|---|
| 382 |
|
|---|
| 383 |
|
|---|
| 384 |
|
|---|
| 385 |
|
|---|
| 386 |
|
|---|
| 387 |
|
|---|
| 388 |
|
|---|
| 389 |
|
|---|
| 390 |
|
|---|
| 391 |
|
|---|
| 392 |
|
|---|
| 393 |
|
|---|
| 394 |
|
|---|
| 395 |
|
|---|
| 396 |
|
|---|
| 397 |
|
|---|
| 398 |
|
|---|
| 399 |
|
|---|
| 400 | Legg Standards Track [Page 7]
|
|---|
| 401 | |
|---|
| 402 |
|
|---|
| 403 | RFC 4522 LDAP: The Binary Encoding Option June 2006
|
|---|
| 404 |
|
|---|
| 405 |
|
|---|
| 406 | Full Copyright Statement
|
|---|
| 407 |
|
|---|
| 408 | Copyright (C) The Internet Society (2006).
|
|---|
| 409 |
|
|---|
| 410 | This document is subject to the rights, licenses and restrictions
|
|---|
| 411 | contained in BCP 78, and except as set forth therein, the authors
|
|---|
| 412 | retain all their rights.
|
|---|
| 413 |
|
|---|
| 414 | This document and the information contained herein are provided on an
|
|---|
| 415 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|---|
| 416 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|---|
| 417 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|---|
| 418 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|---|
| 419 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|---|
| 420 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|---|
| 421 |
|
|---|
| 422 | Intellectual Property
|
|---|
| 423 |
|
|---|
| 424 | The IETF takes no position regarding the validity or scope of any
|
|---|
| 425 | Intellectual Property Rights or other rights that might be claimed to
|
|---|
| 426 | pertain to the implementation or use of the technology described in
|
|---|
| 427 | this document or the extent to which any license under such rights
|
|---|
| 428 | might or might not be available; nor does it represent that it has
|
|---|
| 429 | made any independent effort to identify any such rights. Information
|
|---|
| 430 | on the procedures with respect to rights in RFC documents can be
|
|---|
| 431 | found in BCP 78 and BCP 79.
|
|---|
| 432 |
|
|---|
| 433 | Copies of IPR disclosures made to the IETF Secretariat and any
|
|---|
| 434 | assurances of licenses to be made available, or the result of an
|
|---|
| 435 | attempt made to obtain a general license or permission for the use of
|
|---|
| 436 | such proprietary rights by implementers or users of this
|
|---|
| 437 | specification can be obtained from the IETF on-line IPR repository at
|
|---|
| 438 | http://www.ietf.org/ipr.
|
|---|
| 439 |
|
|---|
| 440 | The IETF invites any interested party to bring to its attention any
|
|---|
| 441 | copyrights, patents or patent applications, or other proprietary
|
|---|
| 442 | rights that may cover technology that may be required to implement
|
|---|
| 443 | this standard. Please address the information to the IETF at
|
|---|
| 444 | ietf-ipr@ietf.org.
|
|---|
| 445 |
|
|---|
| 446 | Acknowledgement
|
|---|
| 447 |
|
|---|
| 448 | Funding for the RFC Editor function is provided by the IETF
|
|---|
| 449 | Administrative Support Activity (IASA).
|
|---|
| 450 |
|
|---|
| 451 |
|
|---|
| 452 |
|
|---|
| 453 |
|
|---|
| 454 |
|
|---|
| 455 |
|
|---|
| 456 |
|
|---|
| 457 | Legg Standards Track [Page 8]
|
|---|
| 458 | |
|---|
| 459 |
|
|---|
