idnits 2.17.00 (12 Aug 2021) /tmp/idnits30715/draft-ietf-geopriv-dhcp-civil-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 561), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 20, 2004) is 6636 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 470, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 473, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3066 (ref. '7') (Obsoleted by RFC 4646, RFC 4647) == Outdated reference: draft-ietf-impp-cpim-pidf has been published as RFC 3863 -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '12') (Obsoleted by RFC 5226) == Outdated reference: draft-ietf-geopriv-dhcp-lci-option has been published as RFC 3825 == Outdated reference: draft-ietf-simple-rpid has been published as RFC 4480 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: September 18, 2004 March 20, 2004 6 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for 7 Civic Addresses 8 draft-ietf-geopriv-dhcp-civil-02 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3667. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 18, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document specifies a Dynamic Host Configuration Protocol (DHCPv4 41 and DHCPv6) option for the civic (country, community and street) 42 location of the client or the DHCP server. 44 Table of Contents 46 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Format of the DHCP Civic Location Option . . . . . . . . . . . 6 49 3.1 Overall Format for DHCPv4 . . . . . . . . . . . . . . . . . . 6 50 3.2 Overall Format for DHCPv6 . . . . . . . . . . . . . . . . . . 6 51 3.3 Element Format . . . . . . . . . . . . . . . . . . . . . . . . 7 52 3.4 Civic Address Components . . . . . . . . . . . . . . . . . . . 7 53 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 56 Normative References . . . . . . . . . . . . . . . . . . . . . 14 57 Informative References . . . . . . . . . . . . . . . . . . . . 15 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 59 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 60 Intellectual Property and Copyright Statements . . . . . . . . 17 62 1. Terminology 64 In this document, the key words "MUST", "MUSTNOT", "REQUIRED", 65 "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and 66 "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 67 indicate requirement levels for compliant implementations. 69 2. Introduction 71 Many end system services can benefit by knowing the approximate 72 location of the end device. In particular, IP telephony devices need 73 to know their location to contact the appropriate emergency response 74 agency and to be found by emergency responders. 76 There are two common ways to identify the location of an object, 77 either through geospatial coordinates or by so-called civic address. 78 Geospatial coordinates indicate longitude, latitude and altitude, 79 while civic addresses indicate a street address. 81 A related draft [13] describes a DHCPv4 [2] option for conveying 82 geospatial information to a device. This draft describes how DHCPv4 83 and DHCPv6 [5] can be used to convey the civic location to devices. 84 Both can be used simultaneously, increasing the chance to deliver 85 accurate and timely location information to emergency responders. 87 End systems that obtain location information via the mechanism 88 described here then use other protocol mechanisms to communicate this 89 information to the emergency call center or to convey it as part of 90 presence information. 92 Civic information is useful since it often provides additional, 93 human-usable information particularly within buildings. Also, 94 compared to geospatial information, it is readily obtained for most 95 occupied structures and can often be interpreted even if incomplete. 96 For example, for many large university or corporate campuses, 97 geocoding information to building and room granularity may not be 98 readily available. 100 Unlike geospatial information, the format for civic information 101 differs from country to country. Thus, this draft establishes an 102 IANA registry for civic location data fields. The initial set of 103 data fields is derived from standards published by the United States 104 National Emergency Number Association (NENA) [15]. It is anticipated 105 that other countries can reuse many of the data elements. 107 The same civic address information can often be rendered in multiple 108 languages and scripts. For example, Korean addresses are often shown 109 in Hangul, Latin and Kanji, while some older cities have multiple 110 language variants (Munich, Muenchen and Monaco, for example). Since 111 DHCPv4 and DHCPv6 do not currently support a mechanism to query for a 112 specific script or language, the DHCP server SHOULD provide all 113 common renderings to the client and MUST provide at least the 114 rendering in the language and script appropriate to the location 115 indicated. For example, for use in presence information, the target 116 may be visiting from a foreign country and want to convey the 117 information in a format suitable for watchers in its home country. 118 For emergency services, the rendering in the local language is likely 119 to be most appropriate. To provide multiple renderings, the client 120 repeats sequences of address elements, prefixing each with 'language' 121 and/or 'script' element (see Section 3.3). The language and script 122 remain in effect for subsequent elements until overridden by another 123 language or script element. 125 The DHCP long-options mechanism described in RFC 3396 [8] MUST be 126 used if the civic address option exceeds the maximum DHCP option size 127 of 255 octets. 129 3. Format of the DHCP Civic Location Option 131 3.1 Overall Format for DHCPv4 133 0 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Code TBD | N | Countrycode | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | What | civic address elements ... 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Code TBD: The code for this DHCP option is TBD by IANA. 143 N: The length of this option is variable. 145 Countrycode: The two-letter ISO 3166 country code in capital ASCII 146 letters, e.g., DE or US. 148 What: The 'what' element describes which location the DHCP refers to. 149 Currently, three options are defined: the location of the DHCP 150 server (a value of 0), the location of the network element 151 believed to be closest to the client (1) or the location of the 152 client (2). Option (2) SHOULD be used, but may not be known. 153 Options (1) and (2) SHOULD NOT be used unless it is known that the 154 DHCP client is in close physical proximity to the server or 155 network element. 157 Civic address element: Zero or more elements comprising the civic 158 address, with the format described below (Section 3.3). 160 3.2 Overall Format for DHCPv6 162 The DHCPv6 [5] civic address option refers generally to the client as 163 a whole. 165 0 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | OPTION_CIVIC_ADDRESS | option-len | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Countrycode | what | elements ... 171 | civic address elements | 172 | ... | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 option-code: OPTION_CIVIC_ADDRESS (TBD) 176 option-len: Length of the Countrycode, 'what' and civic address 177 elements. 179 Countrycode: See above (Section 3.1). 181 What: See above (Section 3.1). 183 Civic address element: See above (Section 3.1). 185 3.3 Element Format 187 For both DHCPv4 and DHCPv6, each civic address element has the 188 following format: 190 0 1 2 3 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | CAtype | CAlength | CAvalue ... 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 CAtype: A one-octet descriptor of the data civic address value. 198 CAlength: The length, in octets, of the CAvalue, not including the 199 CAlength field itself. Data SHOULD be encoded in mixed case, 200 following the customary spelling. 202 CAvalue: The civic address value, encoded as UTF-8 [6], and written 203 in uppercase letters where applicable. The script indication is 204 written in mixed-case, with the first letter a capital letter. 206 Elements SHOULD be included in numeric order from lowest to highest 207 of their CAtype if the server only provides one language and script 208 rendition. In general, an element is labeled in its language and 209 script by the most recent 'language tag' (CAtype = 0) element 210 preceding it. Since not all elements depend on the script and 211 language, a client accumulates the elements by CAtype and then 212 selects the most desirable language and script rendition if there are 213 multiple elements for the same CAtype. 215 3.4 Civic Address Components 217 Since each country has different administrative hierarchies, with 218 often the same (English) names, this specification adopts a simple 219 hierarchical notation that is then instantiated for each country. We 220 assume that five levels are sufficient for sub-national divisions 221 above the street level. 223 All elements are OPTIONAL and can appear in any order. Abbreviations 224 do not need a trailing period. 226 +----------------------+----------------------+---------------------+ 227 | CAtype | label | description | 228 +----------------------+----------------------+---------------------+ 229 | 1 | A1 | national | 230 | | | subdivisions | 231 | | | (state, region, | 232 | | | province, | 233 | | | prefecture) | 234 | | | | 235 | 2 | A2 | county, parish, gun | 236 | | | (JP), district (IN) | 237 | | | | 238 | 3 | A3 | city, township, shi | 239 | | | (JP) | 240 | | | | 241 | 4 | A4 | city division, | 242 | | | borough, city | 243 | | | district, ward, | 244 | | | chou (JP) | 245 | | | | 246 | 5 | A5 | neighborhood, block | 247 | | | | 248 | 6 | A6 | street | 249 +----------------------+----------------------+---------------------+ 251 Table 1 253 For specific countries, the administrative sub-divisions are 254 described below. 256 CA (Canada): The mapping to NENA designations is shown in 257 parentheses. A1=province (STA); A2=county (CNA); A3=city or town 258 (MCN); A6=street (STN). 260 DE (Germany): A1=state (Bundesstaat); A2=county (Regierungsbezirk); 261 A3=city (Stadt, Gemeinde); A6=street (Strasse). Street suffixes 262 (STS) are used only for designations that are a separate word 263 (e.g., Marienthaler Strasse). 265 JP (Japan): A1=metropolis (To, Fu) or prefecture (Ken, Do); A2=city 266 (Shi) or rural area (Gun); A3=ward (Ku) or village (Mura); A4=town 267 (Chou or Machi); A5=city district (Choume); A6=block (Banchi or 268 Ban). 270 KR (Korea): A1=province (Do); A2=county (gun); A3=city or village 271 (ri); A4=urban district (gu); A5=neighborhood (dong); A6=street 272 (no, ro, ga or gil). 274 US (United States): The mapping to NENA designations is shown in 275 parentheses. A1=state (STA), using the the two-letter state and 276 possession abbreviations recommended by the United States Postal 277 Service Publication 28 [14], Appendix B; A2=county (CNA); A3=civic 278 community name (city or town) (MCN); A6=street (STN). A4 and A5 279 are not used. The civic community name (MCN) reflects the 280 political boundaries. These may differ from postal delivery 281 assignments for historical or practical reasons. 283 Additional CA types appear in many countries and are simply omitted 284 where they are not needed or known: 286 +----------------+----------------+----------------+----------------+ 287 | CAtype | NENA | Description | Examples | 288 +----------------+----------------+----------------+----------------+ 289 | 0 | | language | i-default [3] | 290 | | | | | 291 | 16 | PRD | leading street | N | 292 | | | direction | | 293 | | | | | 294 | 17 | POD | trailing | SW | 295 | | | street suffix | | 296 | | | | | 297 | 18 | STS | street suffix | AVE, PLATZ | 298 | | | | | 299 | 19 | HNO | house number | 123 | 300 | | | | | 301 | 20 | HNS | house number | A, 1/2 | 302 | | | suffix | | 303 | | | | | 304 | 21 | LMK | landmark or | SHADELAND | 305 | | | vanity address | CRESCENT APTS | 306 | | | | | 307 | 22 | LOC | additional | APT 17 | 308 | | | location | | 309 | | | information | | 310 | | | | | 311 | 23 | NAM | name | JOE'S | 312 | | | (residence and | BARBERSHOP | 313 | | | office | | 314 | | | occupant) | | 315 | | | | | 316 | 24 | ZIP | postal/zip | 10027-1234 | 317 | | | code | | 318 | | | | | 319 | 25 | | placetype | office | 320 | | | | | 321 | 26 | | floor | 4 | 322 | | | | | 323 | 27 | | room number | 450F | 324 | | | | | 325 | 128 | | script | Latn | 326 | | | | | 327 | 255 | | reserved | | 328 +----------------+----------------+----------------+----------------+ 330 The CA types labeled in the second column correspond to items from 331 the NENA "Recommended Formats & Protocols For ALI Data Exchange, ALI 332 Response & GIS Mapping" [15], but are applicable to most countries. 333 The "NENA" column refers to the data dictionary name in Exhibit 18 of 334 [15]. 336 The "language" item (CAtype 0) optionally identifies the language 337 used for presenting the address information, drawing from the tags 338 for identifying languages in [7]. If omitted, the default value for 339 this tag is "i-default" [3]. 341 The "script" item (CAtype 128) optionally identifies the script used 342 for presenting the address information, drawing from the tags for 343 identifying scripts in ISO 15924 [11]. If omitted, the default value 344 for this tag is "Latn". 346 The NAM object is used to aid user location ("Joe Miller" "Alice's 347 Dry Cleaning"). It does not identify the person using a 348 communications device, but rather the person or organization 349 associated with the address. 351 For POD and PRD, in English-speaking countries, the abbreviations N, 352 E, S, W, and NE, NW, SE, SW should be used. 354 STS designates a street suffix. In the United States (US), the 355 abbreviations recommended by the United States Postal Service 356 Publication 28 [14], Appendix C, SHOULD be used. 358 The "type of place" item (CAtype 25) describes the type of place 359 described by the civic coordinates. For example, it describes 360 whether it is a home, office, street or other public space. The 361 values are drawn from the items in the rich presence [16] document. 362 This information makes it easy, for example, for the DHCP client to 363 then populate the presence information. Since this is an 364 IANA-registered token, the language and script designations do not 365 apply for this element. 367 4. Example 369 Rather than showing the precise byte layout of a DHCP option, we show 370 a symbolic example below, representing the civic address of the 371 Munich city hall in Bavaria, Germany. The city and state name are 372 also conveyed in English and Italian in addition to German; the other 373 items are assumed to be common across all languages. All languages 374 use the latin script. 376 +--------+---------------+ 377 | CAtype | CAvalue | 378 +--------+---------------+ 379 | 0 | de | 380 | | | 381 | 128 | Latn | 382 | | | 383 | 1 | Bayern | 384 | | | 385 | 2 | Oberbayern | 386 | | | 387 | 3 | M=U+00FCnchen | 388 | | | 389 | 6 | Marienplatz | 390 | | | 391 | 19 | 8 | 392 | | | 393 | 21 | Rathaus | 394 | | | 395 | 24 | 80331 | 396 | | | 397 | 25 | public | 398 | | | 399 | 0 | en | 400 | | | 401 | 1 | Bavaria | 402 | | | 403 | 3 | Munich | 404 | | | 405 | 0 | it | 406 | | | 407 | 1 | Baviera | 408 | | | 409 | 3 | Monaco | 410 +--------+---------------+ 412 5. Security Considerations 414 The information in this option may be used for a variety of tasks. In 415 some cases, integrity of the information may be of great importance. 416 In such cases, DHCP authentication in RFC3118 [4] SHOULD be used to 417 protect the integrity of the DHCP options. 419 6. IANA Considerations 421 This document requests that IANA register a new DHCPv4 and DHCPv6 422 option code for the Civic Address . 424 This document establishes a new IANA registry for CAtypes designating 425 civic address components. According to RFC 2434 [12], this registry 426 operates under the "Specification Required" rules. The IANA 427 registration needs to include the following information: 429 CAType: Numeric identifier, assigned by IANA. 431 Brief description: Short description identifying the meaning of the 432 element. 434 Reference to published specification: A stable reference to an RFC or 435 other permanent and readily available reference, in sufficient 436 detail so that interoperability between independent 437 implementations is possible. 439 Country-specific considerations: If applicable, notes whether the 440 element is only applicable or defined for certain countries. 442 Normative References 444 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 445 Levels", BCP 14, RFC 2119, March 1997. 447 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 448 March 1997. 450 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 451 BCP 18, RFC 2277, January 1998. 453 [4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 454 RFC 3118, June 2001. 456 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 457 Carney, "Dynamic Host Configuration Protocol for IPv6 458 (DHCPv6)", RFC 3315, July 2003. 460 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 461 63, RFC 3629, November 2003. 463 [7] Alvestrand, H., "Tags for the Identification of Languages", BCP 464 47, RFC 3066, January 2001. 466 [8] Lemon, T. and S. Cheshire, "Encoding Long Options in the 467 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 468 November 2002. 470 [9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 471 January 2004. 473 [10] Sugano, H. and S. Fujimoto, "Presence Information Data Format 474 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 475 2003. 477 [11] International Organization for Standardization, ISO., 478 "Information and documentation - Codes for the representation 479 of names of scripts", February 2004. 481 Informative References 483 [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 484 Considerations Section in RFCs", BCP 26, RFC 2434, October 485 1998. 487 [13] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host 488 Configuration Protocol Option for Coordinate-based Location 489 Configuration Information", 490 draft-ietf-geopriv-dhcp-lci-option-03 (work in progress), 491 December 2003. 493 [14] United States Postal Service, "Postal Addressing Standards", 494 November 2000. 496 [15] National Emergency Number Assocation, "NENA Recommended Formats 497 and Protocols For ALI Data Exchange, ALI Response and GIS 498 Mapping", NENA NENA-02-010, January 2002. 500 [16] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, 501 "RPID: Rich Presence: Extensions to the Presence Information 502 Data Format (PIDF)", draft-ietf-simple-rpid-02 (work in 503 progress), March 2004. 505 Author's Address 507 Henning Schulzrinne 508 Columbia University 509 Department of Computer Science 510 450 Computer Science Building 511 New York, NY 10027 512 US 514 Phone: +1 212 939 7042 515 EMail: hgs+simple@cs.columbia.edu 516 URI: http://www.cs.columbia.edu 518 Appendix A. Acknowledgments 520 Harald Alvestrand, Stefan Berger and Rohan Mahy provided helpful 521 comments. 523 Intellectual Property Statement 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the IETF's procedures with respect to rights in IETF Documents can 532 be found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use of 537 such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository at 539 http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at 545 ietf-ipr@ietf.org. 547 Disclaimer of Validity 549 This document and the information contained herein are provided on an 550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 552 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 553 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 554 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Copyright Statement 559 Copyright (C) The Internet Society (2004). This document is subject 560 to the rights, licenses and restrictions contained in BCP 78, and 561 except as set forth therein, the authors retain all their rights. 563 Acknowledgment 565 Funding for the RFC Editor function is currently provided by the 566 Internet Society.