From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3915.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc3915.txt (limited to 'doc/rfc/rfc3915.txt') diff --git a/doc/rfc/rfc3915.txt b/doc/rfc/rfc3915.txt new file mode 100644 index 0000000..5892e1f --- /dev/null +++ b/doc/rfc/rfc3915.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group S. Hollenbeck +Request for Comments: 3915 VeriSign, Inc. +Category: Standards Track September 2004 + + + Domain Registry Grace Period Mapping for the + Extensible Provisioning Protocol (EPP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes an Extensible Provisioning Protocol (EPP) + extension mapping for the management of Domain Name System (DNS) + domain names subject to "grace period" policies defined by the + Internet Corporation for Assigned Names and Numbers (ICANN). Grace + period policies exist to allow protocol actions to be reversed or + otherwise revoked during a short period of time after the protocol + action has been performed. Specified in XML, this mapping extends + the EPP domain name mapping to provide additional features required + for grace period processing. + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 1] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions Used In This Document. . . . . . . . . . . . 4 + 2. Redemption Grace Period State Diagram . . . . . . . . . . . . 4 + 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Status Values . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Registration Data and Supporting Information . . . . . . 7 + 3.3. Dates and Times . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Client Statements . . . . . . . . . . . . . . . . . . . 8 + 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8 + 4.1 EPP Query Commands . . . . . . . . . . . . . . . . . . . 8 + 4.1.1. EPP Command . . . . . . . . . . . . . . 8 + 4.1.2. EPP Command . . . . . . . . . . . . . . . 8 + 4.1.3. EPP Command . . . . . . . . . . . . . 11 + 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11 + 4.2.1. EPP Command . . . . . . . . . . . . . . 12 + 4.2.2. EPP Command . . . . . . . . . . . . . . 12 + 4.2.3. EPP Command . . . . . . . . . . . . . . 12 + 4.2.4. EPP Command . . . . . . . . . . . . . 12 + 4.2.5. EPP Command . . . . . . . . . . . . . . 12 + 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Internationalization Considerations . . . . . . . . . . . . . 19 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 10.2. Informative References . . . . . . . . . . . . . . . . . 21 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23 + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 2] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +1. Introduction + + This document describes an extension mapping for version 1.0 of the + Extensible Provisioning Protocol (EPP) described in RFC 3730 [1]. + This mapping, an extension of the domain name mapping described in + RFC 3731 [2], is specified using the Extensible Markup Language (XML) + 1.0 [3] and XML Schema notation ([4], [5]). + + The EPP core protocol specification [1] provides a complete + description of EPP command and response structures. A thorough + understanding of the base protocol specification is necessary to + understand the mapping described in this document. + + Over the course of several months in 2002, The Internet Corporation + for Assigned Names and Numbers (ICANN) developed an implementation + proposal to provide a "grace period" for Domain Name System (DNS) + domain name recovery (or redemption) before a domain name is purged + from the repository of the authoritative registry for the domain + name. This mapping extends the EPP domain command to + initiate the redemption process for a domain name that has entered + the Redemption Grace Period (RGP) and it extends the EPP domain + response to identify the status of domains that have entered + various grace periods defined by ICANN policy. + + In March 2003, ICANN published a task force report describing other + domain registry grace periods related to EPP operations. This + mapping describes extension status values to note the grace periods + described in the report, including: + + o An "add grace period" after the initial registration of a domain + name. If the domain name is deleted by the registrar during this + period, the registry provides a credit to the registrar for the + cost of the registration. + + o An "auto-renew grace period" after a domain name registration + period expires and is extended (renewed) automatically by the + registry. If the domain name is deleted by the registrar during + this period, the registry provides a credit to the registrar for + the cost of the renewal. + + o A "renew grace period" after a domain name registration period is + explicitly extended (renewed) by the registrar. If the domain + name is deleted by the registrar during this period, the registry + provides a credit to the registrar for the cost of the renewal. + + + + + + + +Hollenbeck Standards Track [Page 3] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + o A "transfer grace period" after the successful transfer of domain + name registration sponsorship from one registrar to another + registrar. If the domain name is deleted by the new sponsoring + registrar during this period, the registry provides a credit to + the registrar for the cost of the transfer. + + Each grace period exists for a specific period of time that is + typically measured in days. The duration of each grace period is a + matter of registry operational policy that is not addressed in this + document. + +1.1. Conventions Used In This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [6]. + + In examples, "C:" represents lines sent by a protocol client and "S:" + represents lines returned by a protocol server. Indentation and + white space in examples is provided only to illustrate element + relationships and is not a REQUIRED feature of this specification. + + XML is case sensitive. Unless stated otherwise, XML specifications + and examples provided in this document MUST be interpreted in the + character case presented to develop a conforming implementation. + +2. Redemption Grace Period State Diagram + + The Redemption Grace Period (RGP) involves several domain state + transitions as a domain name moves through the redemption process: + + 1. A domain is initially in the EPP "ok" status, or some other + status that allows processing of the EPP command. + + 2. A command is received and processed for the domain name. + + 3. RGP begins once the command is processed successfully. + The EPP status changes to "pendingDelete", and the RGP status is + initialized to "redemptionPeriod". The domain remains in this + state until either a operation is requested or the + redemption period elapses. + + 4. A operation can be requested using the extended EPP + command. Go to step 8 if the redemption period elapses + before a request is received. + + + + + + +Hollenbeck Standards Track [Page 4] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + 5. If the is successful, the Registry waits to receive a + restore report from the registrar for a period of time defined by + the Registry. The EPP status remains "pendingDelete" and the RGP + status changes to "pendingRestore". While this extension defines + a method to deliver a restore report via EPP, an out-of-band + mechanism (such as a web site) can also be used to deliver + restore reports. + + 6. The domain name returns to the redemption period state (state 3) + if a restore report is not received. + + 7. If a restore report is received the EPP status returns to "ok" + (or whatever it was prior to processing the command), + and the RGP status is removed completely. + + 8. The redemption period elapses before a request is + received. + + 9. The EPP status remains "pendingDelete" and the RGP status changes + to "pendingDelete". The domain name remains in this state for a + period of time defined by the Registry. + + 10. The domain name is purged once the pending delete period elapses. + + 11. The domain name is available for re-registration. + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 5] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + Figure 1: RGP State Diagram + + | + v + +----------------------+ (2) +----------------------+ + |EPP: ok (1)| |EPP: pendingDelete (3)| + |RGP: N/A |--------->|RGP: redemptionPeriod | + +----------------------+ +----------------------+ + ^ (4) | ^ | + | | | No (8) | + | +-----------+ | | + | | | | + | v | v + | +----------------------+ | +----------------------+ + | |EPP: pendingDelete (5)| | |EPP: pendingDelete (9)| + | |RGP: pendingRestore |---------+ |RGP: pendingDelete | + | +----------------------+ Report +----------------------+ + | | not (6) | + | (7) | Received Purge (10) | + | Report Received | | + +--------------------+ v + +----------------------+ + | Purged (11)| + | | + +----------------------+ + +3. Object Attributes + + This extension adds additional elements to the EPP domain name + mapping [2]. Only new element descriptions are described here. + +3.1. Status Values + + This extension defines new status values to represent the different + states that a domain name can be in as a result of grace period + processing. These are: + + addPeriod: This grace period is provided after the initial + registration of a domain name. If the domain name is deleted by + the registrar during this period, the registry provides a credit + to the registrar for the cost of the registration. + + autoRenewPeriod: This grace period is provided after a domain + name registration period expires and is extended (renewed) + automatically by the registry. If the domain name is deleted by + the registrar during this period, the registry provides a credit + to the registrar for the cost of the renewal. + + + + +Hollenbeck Standards Track [Page 6] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + renewPeriod: This grace period is provided after a domain name + registration period is explicitly extended (renewed) by the + registrar. If the domain name is deleted by the registrar during + this period, the registry provides a credit to the registrar for + the cost of the renewal. + + transferPeriod: This grace period is provided after the + successful transfer of domain name registration sponsorship from + one registrar to another registrar. If the domain name is deleted + by the new sponsoring registrar during this period, the registry + provides a credit to the registrar for the cost of the transfer. + + redemptionPeriod: This status value is used to describe a + domain for which a command has been received, but the + domain has not yet been purged because an opportunity exists to + restore the domain and abort the deletion process. + + pendingRestore: This status value is used to describe a domain that + is in the process of being restored after being in the + redemptionPeriod state. + + pendingDelete: This status value is used to describe a domain that + has entered the purge processing state after completing the + redemptionPeriod state. A domain in this status MUST also be in + the pendingDelete status described in the EPP domain mapping [2]. + +3.2. Registration Data and Supporting Information + + This extension allows a client to provide copies of registration data + (whois [9] data, for example) and supporting information in a restore + report as required by the RGP process. No specific format is + required by this extension; both free text and XML markup MAY be + used. + + Operators of servers that provide registration data might find it + useful to provide grace period status values in their responses to + client queries. This information can be useful to people who want to + understand the operations that can be performed on a domain name at + any give time. + +3.3. Dates and Times + + Date and time attribute values MUST be represented in Universal + Coordinated Time (UTC) using the Gregorian calendar. The extended + date-time form using upper case "T" and "Z" characters defined in RFC + 3339 [7] MUST be used to represent date-time values as XML Schema + does not support truncated date-time forms or lower case "T" and "Z" + characters. + + + +Hollenbeck Standards Track [Page 7] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +3.4. Client Statements + + The RGP process requires a client to make two statements regarding + the data included in a restore report. No specific format is + required by this extension; both free text and XML markup MAY be + used. English is the default language used within the statements, + but other languages MAY be used. + +4. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in the EPP core protocol specification [1]. The command mappings + described here are specifically for use in implementing redemption + grace period processes via EPP. + +4.1. EPP Query Commands + + EPP provides three commands to retrieve object information: + to determine if an object is known to the server, to retrieve + detailed information associated with an object, and to + retrieve object transfer status information. + +4.1.1. EPP Command + + This extension does not add any elements to the EPP command + or response described in the EPP domain mapping [2]. + +4.1.2. EPP Command + + This extension does not add any elements to the EPP command + described in the EPP domain mapping [2]. Additional elements are + defined for the response. + + When an command has been processed successfully, the EPP + element MUST contain child elements as described in [2]. In + addition, the EPP element MUST contain a child + element that identifies the registry grace period + namespace and the location of the registry grace period schema. The + element contains a single element that + contains a single attribute "s" whose value describes the current + grace period status of the domain. Possible status values are + described in section Section 3.1. + + + + + + + + + +Hollenbeck Standards Track [Page 8] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + Example response for "addPeriod" status: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: example.com + S: EXAMPLE1-REP + S: + S: jd1234 + S: sh8013 + S: sh8013 + S: + S: ns1.example.com + S: ns1.example.net + S: + S: ns1.example.com + S: ns2.example.com + S: ClientX + S: ClientX + S: 2003-11-26T22:00:00.0Z + S: 2005-11-26T22:00:00.0Z + S: + S: 2fooBAR + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + + + +Hollenbeck Standards Track [Page 9] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + S: + S: + + Example response for "redemptionPeriod" status: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: example.com + S: EXAMPLE1-REP + S: + S: jd1234 + S: sh8013 + S: sh8013 + S: + S: ns1.example.com + S: ns1.example.net + S: + S: ns1.example.com + S: ns2.example.com + S: ClientX + S: ClientY + S: 1999-04-03T22:00:00.0Z + S: ClientX + S: 1999-12-03T09:00:00.0Z + S: 2005-04-03T22:00:00.0Z + S: 2000-04-08T09:00:00.0Z + S: + S: 2fooBAR + S: + S: + S: + S: + S: + S: + + + +Hollenbeck Standards Track [Page 10] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + Example response extension for "pendingRestore" status (note + that only the extension element changes from the first example): + + S: + S: + S: + S: + S: + + Example response extension for "pendingDelete" status (note + that only the extension element changes from the first example): + + S: + S: + S: + S: + S: + +4.1.3. EPP Command + + This extension does not add any elements to the EPP + command or response described in the EPP domain mapping + [2]. + +4.2. EPP Transform Commands + + EPP provides five commands to transform objects: to create + an instance of an object, to delete an instance of an + object, to extend the validity period of an object, + to manage object sponsorship changes, and to + change information associated with an object. + + + + + + + +Hollenbeck Standards Track [Page 11] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +4.2.1. EPP Command + + This extension does not add any elements to the EPP command + or response described in the EPP domain mapping [2]. + +4.2.2. EPP Command + + This extension does not add any elements to the EPP command + or response described in the EPP domain mapping [2]. + +4.2.3. EPP Command + + This extension does not add any elements to the EPP command + or response described in the EPP domain mapping [2]. + +4.2.4. EPP Command + + This extension does not add any elements to the EPP + command or response described in the EPP domain mapping + [2]. + +4.2.5. EPP Command + + This extension defines additional elements to extend the EPP + command and response described in the EPP domain mapping [2] for + redemption grace period processing. + + The EPP command provides a transform operation that allows a + client to change the state of a domain object. The registry grace + period extension modifies base update processing to support + redemption of domain names for which a command has been + processed, but the name has not yet been purged. + + Section 3.2.5 of the EPP domain mapping describes the elements that + have to be specified within an command. The requirement to + provide at least one , , or + element is updated by this extension such that at least one empty + , , or element MUST be present + if this extension is specified within an command. This + requirement is updated to disallow the possibility of modifying a + domain object as part of redemption grace period recovery processing. + + In addition to the EPP command elements described in the EPP domain + mapping [2], the command MUST contain an + element. The element MUST contain a child + element that identifies the registry grace period namespace and the + location of the registry grace period schema. The + + + + +Hollenbeck Standards Track [Page 12] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + element contains a single element that contains an + OPTIONAL element that MAY be used to deliver a + redemption grace period restore report. + + The element contains a REQUIRED "op" attribute that + describes the redemption grace period operation being requested. Two + values are defined: "request" is used to identify a restore request + that does not include a restore report, and "report" is used to + identify a restore request that contains a restore report. A report + MAY be submitted more than once if corrections are required. If the + value of the "op" attribute is "request" an element MUST + NOT be present. If the value of the "op" attribute is "report" an + element MUST be present. + + The element contains the following child elements: + + - An element that contains a copy of the registration + data that existed for the domain name prior to the domain name + being deleted. This element MAY contain both text and XML markup. + + - An element that contains a copy of the registration + data that exists for the domain name at the time the restore + report is submitted. This element MAY contain both text and XML + markup. + + - An element that contains the date and time when the + domain name delete request was sent to the server. + + - An element that contains the date and time when the + original command was sent to the server. + + - An element that contains a brief explanation of + the reason for restoring the domain name. + + - An element that contains a text statement that the + client has not restored the domain name in order to assume the + rights to use or sell the domain name for itself or for any third + party. Supporting information related to this statement MAY be + supplied in the element described below. An OPTIONAL + "lang" attribute MAY be present to identify the language if + English (value "en") is not used to represent the statement. + + - A second element that contains a text statement + that the information in the restore report is factual to the best + of the client's knowledge. An OPTIONAL "lang" attribute MAY be + present to identify the language if English (value "en") is not + used to represent the statement. + + + + +Hollenbeck Standards Track [Page 13] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + - An OPTIONAL element that contains any information + needed to support the statements provided by the client. This + element MAY contain both text and XML markup. + + More detailed information describing the information required to be + provided in a restore report is available from ICANN. + + Example command without a restore report: + + C: + C: + C: + C: + C: + C: example.com + C: + C: + C: + C: + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + Example command with a restore report: + + C: + C: + C: + C: + C: + + + +Hollenbeck Standards Track [Page 14] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + C: example.com + C: + C: + C: + C: + C: + C: + C: + C: Pre-delete registration data goes here. + C: Both XML and free text are allowed. + C: Post-restore registration data goes here. + C: Both XML and free text are allowed. + C: 2003-07-10T22:00:00.0Z + C: 2003-07-20T22:00:00.0Z + C: Registrant error. + C: This registrar has not restored the + C: Registered Name in order to assume the rights to use + C: or sell the Registered Name for itself or for any + C: third party. + C: The information in this report is + C: true to best of this registrar's knowledge, and this + C: registrar acknowledges that intentionally supplying + C: false information in this report shall constitute an + C: incurable material breach of the + C: Registry-Registrar Agreement. + C: Supporting information goes + C: here. + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + When an extended command without a restore report has been + processed successfully, the EPP response is as described in the EPP + domain mapping [2] except that an extension element is added to + describe grace period status as a result of processing the + command. The extension element contains a single child element + () that itself contains a single child element () + that contains a single attribute "s" whose value MUST be + "pendingRestore" if the request has been accepted. + + + + + + +Hollenbeck Standards Track [Page 15] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + Example "restore request" response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + When an extended command with a restore report has been + processed successfully, the EPP response is as described in the EPP + domain mapping [2] with no registry grace period extension. Registry + grace period extension is not required because acceptance of the + restore report completes redemption grace period processing. + +5. Formal Syntax + + An EPP object mapping is specified in XML Schema notation. The + formal syntax presented here is a complete schema representation of + the object mapping suitable for automated validation of EPP XML + instances. The BEGIN and END tags are not part of the schema; they + are used to note the beginning and ending of the schema for URI + registration purposes. + + BEGIN + + + + + + + +Hollenbeck Standards Track [Page 16] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + + + Extensible Provisioning Protocol v1.0 + domain name extension schema for registry grace period + processing. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 17] + +RFC 3915 EPP Grace Period Mapping September 2004 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + END + +6. Internationalization Considerations + + EPP is represented in XML, which provides native support for encoding + information using the Unicode character set and its more compact + representations including UTF-8 [10]. Conformant XML processors + recognize both UTF-8 and UTF-16 [11]. Though XML includes provisions + to identify and use other character encodings through use of an + "encoding" attribute in an declaration, use of UTF-8 is + RECOMMENDED in environments where parser encoding support + incompatibility exists. + + As an extension of the EPP domain mapping [2], the elements, element + content, attributes, and attribute values described in this document + MUST inherit the internationalization conventions used to represent + higher-layer domain and core protocol structures present in an XML + instance that includes this extension. + + + +Hollenbeck Standards Track [Page 19] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +7. IANA Considerations + + This document uses URNs to describe XML namespaces and XML schemas + conforming to a registry mechanism described in RFC 3688 [8]. Two + URI assignments were requested and have been registered by the IANA. + + Registration request for the registry grace period namespace: + + URI: urn:ietf:params:xml:ns:rgp-1.0 + + Registrant Contact: See the "Author's Address" section of this + document. + + XML: None. Namespace URIs do not represent an XML specification. + + Registration request for the registry grace period XML schema: + + URI: urn:ietf:params:xml:schema:rgp-1.0 + + Registrant Contact: See the "Author's Address" section of this + document. + + XML: See the "Formal Syntax" section of this document. + +8. Security Considerations + + The mapping extensions described in this document do not provide any + security services beyond those described by EPP [1], the EPP domain + name mapping [2], and protocol layers used by EPP. The security + considerations described in these other specifications apply to this + specification as well. + + As with other domain object updates, redemption of a deleted domain + object MUST be restricted to the sponsoring client as authenticated + using the mechanisms described in sections 2.9.1.1 and 7 of RFC 3730 + [1]. Any attempt to recover a deleted domain object by any client + other than the sponsoring client MUST be rejected with an appropriate + EPP authorization error. + +9. Acknowledgements + + The author would like to thank the following people who have provided + significant contributions to the development of this document: + + James Gould, Antony Perkov, and Janusz Sienkiewicz. + + + + + + +Hollenbeck Standards Track [Page 20] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +10. References + +10.1. Normative References + + [1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC + 3730, March 2004. + + [2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain + Name Mapping", RFC 3731, March 2004. + + [3] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, + "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, + October 2000, . + + [4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML + Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, + . + + [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C + REC-xmlschema-2, May 2001, . + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, July 2002. + + [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January + 2004. + +10.2. Informative References + + [9] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC + 954, October 1985. + + [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD + 63, RFC 3629, November 2003. + + [11] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", + RFC 2781, February 2000. + + + + + + + + + + + +Hollenbeck Standards Track [Page 21] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +Author's Address + + Scott Hollenbeck + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: shollenbeck@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 22] + +RFC 3915 EPP Grace Period Mapping September 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Hollenbeck Standards Track [Page 23] + -- cgit v1.2.3