idnits 2.17.1 draft-hollenbeck-epp-rgp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 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 (July 30, 2003) is 7575 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 817, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 954 (ref. '10') (Obsoleted by RFC 3912) -- Obsolete informational reference (is this intentional?): RFC 2279 (ref. '11') (Obsoleted by RFC 3629) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 Expires: January 28, 2004 July 30, 2003 6 Redemption Grace Period Mapping for the Extensible Provisioning 7 Protocol 8 draft-hollenbeck-epp-rgp-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 28, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes an Extensible Provisioning Protocol (EPP) 39 extension mapping for the management of Domain Name System (DNS) 40 domain names subject to the Redemption Grace Period (RGP) policies 41 defined by the Internet Corporation for Assigned Names and Numbers 42 (ICANN). Specified in XML, this mapping extends the EPP domain name 43 mapping to provide additional features required for RGP processing. 45 Conventions Used In This Document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [1]. 51 In examples, "C:" represents lines sent by a protocol client and "S:" 52 represents lines returned by a protocol server. Indentation and 53 white space in examples is provided only to illustrate element 54 relationships and is not a REQUIRED feature of this specification. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Changes from Previous Version . . . . . . . . . . . . . . . 3 60 2. Redemption Grace Period State Diagram . . . . . . . . . . . 4 61 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . 6 62 3.1 Status Values . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2 Whois Data and Supporting Information . . . . . . . . . . . 6 64 3.3 Dates and Times . . . . . . . . . . . . . . . . . . . . . . 6 65 3.4 Client Statements . . . . . . . . . . . . . . . . . . . . . 7 66 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . 8 67 4.1 EPP Query Commands . . . . . . . . . . . . . . . . . . . . . 8 68 4.1.1 EPP Command . . . . . . . . . . . . . . . . . . . . 8 69 4.1.2 EPP Command . . . . . . . . . . . . . . . . . . . . . 8 70 4.1.3 EPP Command . . . . . . . . . . . . . . . . . . . 10 71 4.2 EPP Transform Commands . . . . . . . . . . . . . . . . . . . 10 72 4.2.1 EPP Command . . . . . . . . . . . . . . . . . . . . 10 73 4.2.2 EPP Command . . . . . . . . . . . . . . . . . . . . 10 74 4.2.3 EPP Command . . . . . . . . . . . . . . . . . . . . 10 75 4.2.4 EPP Command . . . . . . . . . . . . . . . . . . . 14 76 4.2.5 EPP Command . . . . . . . . . . . . . . . . . . . . 15 77 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 16 78 6. Internationalization Considerations . . . . . . . . . . . . 19 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 80 8. Security Considerations . . . . . . . . . . . . . . . . . . 21 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 82 Normative References . . . . . . . . . . . . . . . . . . . . 23 83 Informative References . . . . . . . . . . . . . . . . . . . 24 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . 25 85 Intellectual Property and Copyright Statements . . . . . . . 26 87 1. Introduction 89 This document describes an extension mapping for version 1.0 of the 90 Extensible Provisioning Protocol (EPP). This mapping, an extension 91 of the domain name mapping described in [2], is specified using the 92 Extensible Markup Language (XML) 1.0 as described in [3] and XML 93 Schema notation as described in [4] and [5]. 95 The EPP core protocol specification [6] provides a complete 96 description of EPP command and response structures. A thorough 97 understanding of the base protocol specification is necessary to 98 understand the mapping described in this document. 100 Over the course of several months in 2002, The Internet Corporation 101 for Assigned Names and Numbers [13] (ICANN) developed an 102 implementation proposal [14] to provide a "grace period" for Domain 103 Name System (DNS) domain name recovery (or redemption) before a 104 domain name is purged from the repository of the authoritative 105 registry for the domain name. This mapping extends the EPP domain 106 command to initiate the redemption process for a domain name 107 that has entered the Redemption Grace Period (RGP) and it extends the 108 EPP domain response to identify the status of domains that 109 have entered the RGP. 111 XML is case sensitive. Unless stated otherwise, XML specifications 112 and examples provided in this document MUST be interpreted in the 113 character case presented to develop a conforming implementation. 115 1.1 Changes from Previous Version 117 (Note to RFC editor: please remove this section completely before 118 publication as an RFC.) 120 Changed URIs used to identify the RGP namespace and updated the IANA 121 Considerations section to be consistent with the URIs used. 123 Added support for protocol-based RGP report delivery. 125 2. Redemption Grace Period State Diagram 127 The Redemption Grace Period (RGP) involves several domain state 128 transitions as a domain name moves through the redemption process: 130 1. A domain is initially in the EPP "ok" status, or some other 131 status that allows processing of the EPP command. 133 2. A command is received and processed for the domain 134 name. 136 3. RGP begins once the command is processed successfully. 137 The EPP status changes to "pendingDelete", and the RGP status is 138 initialized to "redemptionPeriod". The domain remains in this 139 state until either a operation is requested or the 140 redemption period elapses. 142 4. A operation can be requested using the extended EPP 143 command. Go to step 8 if the redemption period elapses 144 before a request is received. 146 5. If the is successful, the Registry waits to receive a 147 restore report from the registrar for a period of time defined 148 by the Registry. The EPP status remains "pendingDelete" and the 149 RGP status changes to "pendingRestore". While this extension 150 defines a method to deliver a restore report via EPP, an 151 out-of-band mechanism (such as a web site) can also be used to 152 deliver restore reports. 154 6. The domain name returns to the redemption period state (state 3) 155 if a restore report is not received. 157 7. If a restore report is received the EPP status returns to "ok" 158 (or whatever it was prior to processing the command), 159 and the RGP status is removed completely. 161 8. The redemption period elapses before a request is 162 received. 164 9. The EPP status remains "pendingDelete" and the RGP status 165 changes to "pendingDelete". The domain name remains in this 166 state for a period of time defined by the Registry. 168 10. The domain name is purged once the pending delete period 169 elapses. 171 11. The domain name is available for re-registration. 173 | 174 | 175 v 176 +----------------------+ (2) +----------------------+ 177 |EPP: ok (1)| |EPP: pendingDelete (3)| 178 |RGP: N/A |--------->|RGP: redemptionPeriod | 179 +----------------------+ +----------------------+ 180 ^ (4) | ^ | 181 | | | No (8) | 182 | +-----------+ | | 183 | | | | 184 | v | v 185 | +----------------------+ | +----------------------+ 186 | |EPP: pendingDelete (5)| | |EPP: pendingDelete (9)| 187 | |RGP: pendingRestore |---------+ |RGP: pendingDelete | 188 | +----------------------+ Report +----------------------+ 189 | | not (6) | 190 | (7) | Received Purge (10) | 191 | Report Received | | 192 +--------------------+ v 193 +----------------------+ 194 | Purged (11)| 195 | | 196 +----------------------+ 198 Figure 1: RGP State Diagram 200 3. Object Attributes 202 This extension adds additional elements to the domain name mapping 203 described in the EPP domain mapping [2]. Only new element 204 descriptions are described here. 206 3.1 Status Values 208 This extension defines three new status values to represent the 209 different states that a domain can be in as a result of redemption 210 grace period processing. These are: 212 redemptionPeriod: This status value is used to describe a domain 213 for which a command has been received, but the domain has 214 not yet been purged because an opportunity exists to restore the 215 domain and abort the deletion process. The amount of time that a 216 domain can stay in this status before being entering purge 217 processing is a matter of registry policy. 219 pendingRestore: This status value is used to describe a domain 220 that is in the process of being restored after being in the 221 redemptionPeriod state. The amount of time that a domain can stay 222 in this status before being returned to the redemptionPeriod state 223 is a matter of registry policy. 225 pendingDelete: This status value is used to describe a domain that 226 has entered the purge processing state after completing the 227 redemptionPeriod state. The amount of time that a domain can stay 228 in this status before being being purged is a matter of registry 229 policy. A domain in this status MUST also be in the pendingDelete 230 status described in the EPP domain mapping [2]. 232 3.2 Whois Data and Supporting Information 234 This extension allows a client to provide copies of whois [10] data 235 and supporting information in a restore report as required by the RGP 236 process. No specific format is required by this extension; both free 237 text and XML markup MAY be used. 239 3.3 Dates and Times 241 Date and time attribute values MUST be represented in Universal 242 Coordinated Time (UTC) using the Gregorian calendar. The extended 243 date-time form using upper case "T" and "Z" characters defined in RFC 244 3339 [7] MUST be used to represent date-time values as XML Schema 245 does not support truncated date-time forms or lower case "T" and "Z" 246 characters. 248 3.4 Client Statements 250 The RGP process requires a client to make two statements regarding 251 the data included in a restore report. No specific format is 252 required by this extension; both free text and XML markup MAY be 253 used. English is the default language used within the statements, 254 but other languages MAY be used. 256 4. EPP Command Mapping 258 A detailed description of the EPP syntax and semantics can be found 259 in the EPP core protocol specification [6]. The command mappings 260 described here are specifically for use in implementing redemption 261 grace period processes via EPP. 263 4.1 EPP Query Commands 265 EPP provides three commands to retrieve object information: 266 to determine if an object is known to the server, to retrieve 267 detailed information associated with an object, and to 268 retrieve object transfer status information. 270 4.1.1 EPP Command 272 This extension does not add any elements to the EPP command 273 or response described in the EPP domain mapping [2]. 275 4.1.2 EPP Command 277 This extension does not add any elements to the EPP command 278 described in the EPP domain mapping [2]. Additional elements are 279 defined for the response. 281 When an command has been processed successfully, the EPP 282 element MUST contain child elements as described in [2]. 283 In addition, the EPP element MUST contain a child 284 element that identifies the RGP namespace and the 285 location of the RGP schema. The element contains a 286 single element that contains a single attribute "s" 287 whose value describes the current RGP status of the domain. Possible 288 status values are described in section Section 3.1. 290 Example response for "redemptionPeriod" status: 292 S: 293 S: 297 S: 298 S: 299 S: Command completed successfully 300 S: 301 S: 302 S: 306 S: example.com 307 S: EXAMPLE1-REP 308 S: 309 S: jd1234 310 S: sh8013 311 S: sh8013 312 S: 313 S: ns1.example.com 314 S: ns1.example.net 315 S: 316 S: ns1.example.com 317 S: ns2.example.com 318 S: ClientX 319 S: ClientY 320 S: 1999-04-03T22:00:00.0Z 321 S: ClientX 322 S: 1999-12-03T09:00:00.0Z 323 S: 2005-04-03T22:00:00.0Z 324 S: 2000-04-08T09:00:00.0Z 325 S: 326 S: 2fooBAR 327 S: 328 S: 329 S: 330 S: 331 S: 334 S: 335 S: 336 S: 337 S: 338 S: ABC-12345 339 S: 54322-XYZ 340 S: 341 S: 342 S: 344 Example response extension for "pendingRestore" status (note 345 that only the extension element changes from the first example): 347 S: 348 S: 351 S: 352 S: 353 S: 355 Example response extension for "pendingDelete" status (note 356 that only the extension element changes from the first example): 358 S: 359 S: 362 S: 363 S: 364 S: 366 4.1.3 EPP Command 368 This extension does not add any elements to the EPP 369 command or response described in the EPP domain mapping 370 [2]. 372 4.2 EPP Transform Commands 374 EPP provides five commands to transform objects: to create 375 an instance of an object, to delete an instance of an 376 object, to extend the validity period of an object, 377 to manage object sponsorship changes, and to 378 change information associated with an object. 380 4.2.1 EPP Command 382 This extension does not add any elements to the EPP command 383 or response described in the EPP domain mapping [2]. 385 4.2.2 EPP Command 387 This extension does not add any elements to the EPP command 388 or response described in the EPP domain mapping [2]. 390 4.2.3 EPP Command 392 This extension defines additional elements for the EPP 393 command and response described in the EPP domain mapping [2]. 395 The EPP command provides a transform operation that allows a 396 client to extend the registration period a domain object. In 397 addition to the EPP command elements described in the EPP domain 398 mapping [2], the command MUST contain an element. The 399 element MUST contain a child element that 400 identifies the RGP namespace and the location of the RGP schema. The 401 element contains a single element that 402 contains an OPTIONAL element that MAY be used to deliver 403 an RGP restore report. 405 The element contains a REQUIRED "op" attribute that 406 describes the RGP operation being requested. Two values are defined: 407 "request" is used to identify a restore request that does not include 408 a restore report, and "report" is used to identify a restore request 409 that contains a restore report. A report MAY be submitted more than 410 once if corrections are required. If the value of the "op" attribute 411 is "request" an element MUST NOT be present. If the 412 value of the "op" attribute is "report" an element MUST 413 be present. 415 The element contains the following child elements: 417 - An element that contains a copy of the whois [10] 418 data that existed for the domain name prior to the domain name 419 being deleted. This element MAY contain both text and XML markup. 421 - An element that contains a copy of the whois [10] 422 data that exists for the domain name at the time the restore 423 report is submitted. This element MAY contain both text and XML 424 markup. 426 - An element that contains the date and time when the 427 domain name delete request was sent to the server. 429 - An element that contains the date and time when the 430 original command was sent to the server. 432 - An element that contains a brief explanation of 433 the reason for restoring the domain name. 435 - An element that contains a text statement that the 436 client has not restored the domain name in order to assume the 437 rights to use or sell the domain name for itself or for any third 438 party. Supporting information related to this statement MAY be 439 supplied in the element described below. An OPTIONAL 440 "lang" attribute MAY be present to identify the language if 441 English (value "en") is not used to represent the statement. 443 - A second element that contains a text statement 444 that the information in the restore report is factual to the best 445 of the client's knowledge. An OPTIONAL "lang" attribute MAY be 446 present to identify the language if English (value "en") is not 447 used to represent the statement. 449 - An OPTIONAL element that contains any information 450 needed to support the statements provided by the client. This 451 element MAY contain both text and XML markup. 453 More detailed information describing the information required to be 454 provided in a restore report is available from ICANN. 456 Example command without a restore report: 458 C: 459 C: 463 C: 464 C: 465 C: 469 C: example.com 470 C: 2003-05-18 471 C: 1 472 C: 473 C: 474 C: 475 C: 478 C: 479 C: 480 C: 481 C: ABC-12345 482 C: 483 C: 485 Example command with a restore report: 487 C: 488 C: 492 C: 493 C: 494 C: 498 C: example.com 499 C: 2003-05-18 500 C: 1 501 C: 502 C: 503 C: 504 C: 507 C: 508 C: 509 C: Pre-delete whois data goes here. 510 C: Both XML and free text are allowed. 511 C: Post-restore whois data goes here. 512 C: Both XML and free text are allowed. 513 C: 2003-07-10T22:00:00.0Z 514 C: 2003-07-20T22:00:00.0Z 515 C: Registrant error. 516 C: This registrar has not restored the 517 C: Registered Name in order to assume the rights to use 518 C: or sell the Registered Name for itself or for any 519 C: third party. 520 C: The information in this report is 521 C: true to best of this registrar's knowledge, and this 522 C: registrar acknowledges that intentionally supplying 523 C: false information in this report shall constitute an 524 C: incurable material breach of the 525 C: Registry-Registrar Agreement. 526 C: Supporting information goes 527 C: here. 528 C: 529 C: 530 C: 531 C: 532 C: ABC-12345 533 C: 534 C: 536 When an extended command without a restore report has been 537 processed successfully, the EPP response is as described in the EPP 538 domain mapping [2] except that an extension element is added to 539 describe RGP status as a result of processing the command. 540 The extension element contains a single child element () 541 that itself contains a single child element () that 542 contains a single attribute "s" whose value MUST be "pendingRestore" 543 if the request has been accepted. 545 When an extended command with a restore report has been 546 processed successfully, the EPP response is as described in the EPP 547 domain mapping [2] with no RGP extension. RGP extension is not 548 required because acceptance of the restore report completes RGP 549 processing. 551 Example "no report" response: 553 S: 554 S: 558 S: 559 S: 560 S: Command completed successfully 561 S: 562 S: 563 S: 567 S: example.com 568 S: 2004-05-18T22:00:00.0Z 569 S: 570 S: 571 S: 572 S: 575 S: 576 S: 577 S: 578 S: 579 S: ABC-12345 580 S: 54322-XYZ 581 S: 582 S: 583 S: 585 4.2.4 EPP Command 587 This extension does not add any elements to the EPP 588 command or response described in the EPP domain mapping 589 [2]. 591 4.2.5 EPP Command 593 This extension does not add any elements to the EPP command 594 or response described in the EPP domain mapping [2]. 596 5. Formal Syntax 598 An EPP object mapping is specified in XML Schema notation. The 599 formal syntax presented here is a complete schema representation of 600 the object mapping suitable for automated validation of EPP XML 601 instances. The BEGIN and END tags are not part of the schema; they 602 are used to note the beginning and ending of the schema for URI 603 registration purposes. 605 BEGIN 606 608 613 614 615 Extensible Provisioning Protocol v1.0 616 domain name extension schema for redemption grace period (RGP) 617 processing. 618 619 621 624 626 629 630 631 632 633 635 636 637 639 640 641 643 646 647 648 649 650 651 653 654 655 656 657 658 659 660 662 664 665 667 668 669 670 671 672 673 674 675 677 678 679 680 681 682 683 684 685 686 688 691 692 694 697 698 699 700 701 703 707 708 709 710 712 713 714 715 717 718 719 720 721 722 723 725 728 729 END 731 6. Internationalization Considerations 733 EPP is represented in XML, which provides native support for encoding 734 information using the Unicode character set and its more compact 735 representations including UTF-8 [11]. Conformant XML processors 736 recognize both UTF-8 and UTF-16 [12]. Though XML includes provisions 737 to identify and use other character encodings through use of an 738 "encoding" attribute in an declaration, use of UTF-8 is 739 RECOMMENDED in environments where parser encoding support 740 incompatibility exists. 742 As an extension of the EPP domain mapping [2], the elements, element 743 content, attributes, and attribute values described in this document 744 MUST inherit the internationalization conventions used to represent 745 higher-layer domain and core protocol structures present in an XML 746 instance that includes this extension. 748 7. IANA Considerations 750 This document uses URNs to describe XML namespaces and XML schemas 751 conforming to a registry mechanism described in [8]. Two URI 752 assignments are requested. 754 Registration request for the RGP namespace: 756 URI: urn:ietf:params:xml:ns:rgp-1.0 758 Registrant Contact: See the "Author's Address" section of this 759 document. 761 XML: None. Namespace URIs do not represent an XML specification. 763 Registration request for the RGP XML schema: 765 URI: urn:ietf:params:xml:schema:rgp-1.0 767 Registrant Contact: See the "Author's Address" section of this 768 document. 770 XML: See the "Formal Syntax" section of this document. 772 8. Security Considerations 774 The mapping extensions described in this document do not provide any 775 security services beyond those described by EPP [6], the EPP domain 776 name mapping [2], and protocol layers used by EPP. The security 777 considerations described in these other specifications apply to this 778 specification as well. 780 9. Acknowledgements 782 The author would like to thank the following people who have provided 783 significant contributions to the development of this document: 785 Janusz Sienkiewicz 787 Normative References 789 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 790 Levels", BCP 14, RFC 2119, March 1997. 792 [2] Hollenbeck, S., "Extensible Provisioning Protocol Domain Name 793 Mapping", draft-ietf-provreg-epp-domain-07 (work in progress), 794 April 2003. 796 [3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 797 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 798 October 2000, . 800 [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 801 Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, 802 . 804 [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C 805 REC-xmlschema-2, May 2001, . 807 [6] Hollenbeck, S., "Extensible Provisioning Protocol", 808 draft-ietf-provreg-epp-09 (work in progress), March 2003. 810 [7] Klyne, G. and C. Newman, "Date and Time on the Internet: 811 Timestamps", RFC 3339, July 2002. 813 [8] Mealling, M., "The IETF XML Registry", 814 draft-mealling-iana-xmlns-registry-05 (work in progress), June 815 2003. 817 [9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C 818 REC-xml-names, January 1999, . 821 Informative References 823 [10] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 824 954, October 1985. 826 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 827 2279, January 1998. 829 [12] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 830 RFC 2781, February 2000. 832 URIs 834 [13] 836 [14] 838 Author's Address 840 Scott Hollenbeck 841 VeriSign, Inc. 842 21345 Ridgetop Circle 843 Dulles, VA 20166-6503 844 US 846 EMail: shollenbeck@verisign.com 848 Intellectual Property Statement 850 The IETF takes no position regarding the validity or scope of any 851 intellectual property or other rights that might be claimed to 852 pertain to the implementation or use of the technology described in 853 this document or the extent to which any license under such rights 854 might or might not be available; neither does it represent that it 855 has made any effort to identify any such rights. Information on the 856 IETF's procedures with respect to rights in standards-track and 857 standards-related documentation can be found in BCP-11. Copies of 858 claims of rights made available for publication and any assurances of 859 licenses to be made available, or the result of an attempt made to 860 obtain a general license or permission for the use of such 861 proprietary rights by implementors or users of this specification can 862 be obtained from the IETF Secretariat. 864 The IETF invites any interested party to bring to its attention any 865 copyrights, patents or patent applications, or other proprietary 866 rights which may cover technology that may be required to practice 867 this standard. Please address the information to the IETF Executive 868 Director. 870 Full Copyright Statement 872 Copyright (C) The Internet Society (2003). All Rights Reserved. 874 This document and translations of it may be copied and furnished to 875 others, and derivative works that comment on or otherwise explain it 876 or assist in its implementation may be prepared, copied, published 877 and distributed, in whole or in part, without restriction of any 878 kind, provided that the above copyright notice and this paragraph are 879 included on all such copies and derivative works. However, this 880 document itself may not be modified in any way, such as by removing 881 the copyright notice or references to the Internet Society or other 882 Internet organizations, except as needed for the purpose of 883 developing Internet standards in which case the procedures for 884 copyrights defined in the Internet Standards process must be 885 followed, or as required to translate it into languages other than 886 English. 888 The limited permissions granted above are perpetual and will not be 889 revoked by the Internet Society or its successors or assignees. 891 This document and the information contained herein is provided on an 892 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 893 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 894 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 895 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 896 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 898 Acknowledgement 900 Funding for the RFC Editor function is currently provided by the 901 Internet Society.