epp-client-rgp 0.11.0

data/ChangeLog

@@ -0,0 +1,5 @@
+2010-05-14 mat
+	* first release
+
+2010-05-04 mat
+	* Initial commit

data/Gemfile

@@ -0,0 +1,6 @@
+source 'http://rubygems.org'
+
+# Specify your gem's dependencies in epp-client.gemspec
+Dir['*.gemspec'].each do |i|
+  gemspec :name => i.sub(/\.gemspec$/, '')
+end

data/MIT-LICENSE

@@ -0,0 +1,19 @@
+Copyright (C) 2010 Mathieu Arnold, Absolight
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal in
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
+of the Software, and to permit persons to whom the Software is furnished to do
+so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

data/README

@@ -0,0 +1,5 @@
+An extensible EPP client library
+
+When possible, the objects that are received via EPP are translated to their
+equivalent in ruby, that is, dates in Date object, timestamps in DateTime
+objects.

data/Rakefile

@@ -0,0 +1,37 @@
+#!/usr/bin/env rake
+require 'rake'
+require 'rdoc/task'
+require 'rubygems/package_task'
+require "bundler/gem_helper"
+
+MY_GEMS = Dir['*.gemspec'].map {|g| g.sub(/.*-(.*)\.gemspec/, '\1')}
+
+MY_GEMS.each do |g|
+  namespace g do
+    Bundler::GemHelper.new(Dir.pwd, "epp-client-#{g}").install
+  end
+end
+
+namespace :all do
+  task :build   => MY_GEMS.map { |f| "#{f}:build"   }
+  task :install => MY_GEMS.map { |f| "#{f}:install" }
+  task :release => MY_GEMS.map { |f| "#{f}:release" }
+end
+
+task :build   => 'all:build'
+task :install => 'all:install'
+task :release => 'all:release'
+
+desc "Generate documentation for the Rails framework"
+Rake::RDocTask.new do |rdoc|
+  rdoc.rdoc_dir = 'doc/rdoc'
+  rdoc.title    = "Documentation"
+
+  rdoc.options << '--line-numbers' << '--inline-source'
+  rdoc.options << '--charset' << 'utf-8'
+
+  rdoc.rdoc_files.include('README')
+  rdoc.rdoc_files.include('ChangeLog')
+  rdoc.rdoc_files.include('lib/**/*.rb')
+end
+

data/epp-client-rgp.gemspec

@@ -0,0 +1,35 @@
+# -*- encoding: utf-8 -*-
+require File.expand_path('../lib/epp-client/version', __FILE__)
+
+Gem::Specification.new do |gem|
+  gem.name          = 'epp-client-rgp'
+  gem.version       = EPPClient::VERSION
+  gem.date          = '2010-05-14'
+  gem.authors       = ['Mathieu Arnold']
+  gem.email         = ['m@absolight.fr']
+  gem.description   = 'RGP EPP client library.'
+  gem.summary       = 'RGP EPP client library'
+  gem.homepage       = "https://github.com/Absolight/epp-client"
+
+  gem.required_ruby_version = '>= 1.8.7'
+  gem.required_rubygems_version = ">= 1.3.6"
+
+  gem.files         = [
+    'ChangeLog',
+    'Gemfile',
+    'MIT-LICENSE',
+    'README',
+    'Rakefile',
+    'epp-client-rgp.gemspec',
+    'lib/epp-client/rgp.rb',
+    'vendor/ietf/rfc3915.txt',
+    'vendor/ietf/rgp-1.0.xsd',
+  ]
+
+  gem.test_files    = `git ls-files -- {test,spec,features}/*`.split("\n")
+  gem.require_paths = ['lib']
+
+  gem.add_development_dependency "bundler", ">= 1.0.0"
+  gem.add_dependency('nokogiri', '~> 1.4')
+  gem.add_dependency('builder',  '>= 2.1.2')
+end

data/lib/epp-client/rgp.rb

@@ -0,0 +1,105 @@
+# RFC3915[http://tools.ietf.org/html/rfc3915]
+#
+# Domain Registry Grace Period Mapping for the
+# Extensible Provisioning Protocol (EPP)
+#
+# Has to be included after the initialize, domain_info and domain_update
+# definitions.
+module EPPClient
+  module RGP
+    def self.included(base) # :nodoc:
+      base.class_eval do
+	alias_method :initialize_without_rgp, :initialize
+	alias_method :initialize, :initialize_with_rgp
+	alias_method :domain_info_process_without_rgp, :domain_info_process
+	alias_method :domain_info_process, :domain_info_process_with_rgp
+      end
+    end
+
+    def initialize_with_rgp(args) #:nodoc:
+      initialize_without_rgp(args)
+      @extensions << EPPClient::SCHEMAS_URL['rgp']
+    end
+
+    def domain_info_process_with_rgp(xml) #:nodoc:
+      ret = domain_info_process_without_rgp(xml)
+      if (rgp_status = xml.xpath('epp:extension/rgp:infData/rgp:rgpStatus', EPPClient::SCHEMAS_URL)).size > 0
+	ret[:rgpStatus] = rgp_status.map {|s| s.attr('s')}
+      end
+      ret
+    end
+
+    def domain_restore_xml(args) #:nodoc:
+      command(lambda do |xml|
+	xml.update do
+	  xml.update('xmlns' => EPPClient::SCHEMAS_URL['domain-1.0']) do
+	    xml.name args[:name]
+	  end
+	end
+      end, lambda do |xml|
+	xml.update('xmlns' => EPPClient::SCHEMAS_URL['rgp-1.0']) do
+	  if args.key?(:report)
+	    xml.restore(:op => 'report') do
+	      [:preData, :postData, :delTime, :resTime, :resReason].each do |v|
+		xml.__send__(v, args[:report][v])
+	      end
+	      args[:report][:statements].each do |s|
+		xml.statement s
+	      end
+	      if args[:report].key?(:other)
+		xml.other args[:report][:other]
+	      end
+	    end
+	  else
+	    xml.restore(:op => 'request')
+	  end
+	end
+      end)
+    end
+
+    # Restores a domain.
+    #
+    # takes a hash as arguments, with the following keys :
+    # [<tt>:name</tt>]
+    #   the fully qualified name of the domain object to be updated.
+    # [<tt>:report</tt>]
+    #   the optional report with the following fields :
+    #   [<tt>:preData</tt>]
+    #     a copy of the registration data that existed for the domain name prior
+    #     to the domain name being deleted.
+    #   [<tt>:postData</tt>]
+    #     a copy of the registration data that exists for the domain name at the
+    #     time the restore report is submitted.
+    #   [<tt>:delTime</tt>]
+    #     the date and time when the domain name delete request was sent to the
+    #     server.
+    #   [<tt>:resTime</tt>]
+    #     the date and time when the original <rgp:restore> command was sent to
+    #     the server.
+    #   [<tt>:resReason</tt>]
+    #     a brief explanation of the reason for restoring the domain name.
+    #   [<tt>:statements</tt>]
+    #     an array of two statements :
+    #     1. 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 <tt>:other</tt> element described
+    #        below.
+    #     2. a text statement that the information in the restore report is
+    #        factual to the best of the client's knowledge.
+    #   [<tt>:other</tt>]
+    #     an optional element that contains any information needed to support the
+    #     statements provided by the client.
+    #
+    # Returns an array of rgpStatus.
+    def domain_restore(args)
+      response = send_request(domain_restore_xml(args))
+
+      get_result(:xml => response, :callback => :domain_restore_process)
+    end
+
+    def domain_restore_process(xml) #:nodoc:
+      xml.xpath('epp:extension/rgp:upData/rgp:rgpStatus', EPPClient::SCHEMAS_URL).map {|s| s.attr('s')}
+    end
+  end
+end

data/vendor/ietf/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 <check> Command  . . . . . . . . . . . . . .  8
+             4.1.2.  EPP <info> Command . . . . . . . . . . . . . . .  8
+             4.1.3.  EPP <transfer> Command . . . . . . . . . . . . . 11
+       4.2.  EPP Transform Commands . . . . . . . . . . . . . . . . . 11
+             4.2.1.  EPP <create> Command . . . . . . . . . . . . . . 12
+             4.2.2.  EPP <delete> Command . . . . . . . . . . . . . . 12
+             4.2.3.  EPP <renew> Command  . . . . . . . . . . . . . . 12
+             4.2.4.  EPP <transfer> Command . . . . . . . . . . . . . 12
+             4.2.5.  EPP <update> 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 <update> command to
+   initiate the redemption process for a domain name that has entered
+   the Redemption Grace Period (RGP) and it extends the EPP domain
+   <info> 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 <delete> command.
+
+   2.  A <delete> command is received and processed for the domain name.
+
+   3.  RGP begins once the <delete> 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 <restore> operation is requested or the
+       redemption period elapses.
+
+   4.  A <restore> operation can be requested using the extended EPP
+       <update> command.  Go to step 8 if the redemption period elapses
+       before a <restore> request is received.
+
+
+
+
+
+
+Hollenbeck                  Standards Track                     [Page 4]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+   5.  If the <restore> 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 <delete> command),
+       and the RGP status is removed completely.
+
+   8.  The redemption period elapses before a <restore> 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)| <delete> |EPP: pendingDelete (3)|
+   |RGP: N/A              |--------->|RGP: redemptionPeriod |
+   +----------------------+          +----------------------+
+      ^                         (4)    |  ^             |
+      |                      <restore> |  |      No (8) |
+      |                    +-----------+  |   <restore> |
+      |                    |              |             |
+      |                    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 <delete> 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: <check>
+   to determine if an object is known to the server, <info> to retrieve
+   detailed information associated with an object, and <transfer> to
+   retrieve object transfer status information.
+
+4.1.1.  EPP <check> Command
+
+   This extension does not add any elements to the EPP <check> command
+   or <check> response described in the EPP domain mapping [2].
+
+4.1.2.  EPP <info> Command
+
+   This extension does not add any elements to the EPP <info> command
+   described in the EPP domain mapping [2].  Additional elements are
+   defined for the <info> response.
+
+   When an <info> command has been processed successfully, the EPP
+   <resData> element MUST contain child elements as described in [2]. In
+   addition, the EPP <extension> element MUST contain a child
+   <rgp:infData> element that identifies the registry grace period
+   namespace and the location of the registry grace period schema.  The
+   <rgp:infData> element contains a single <rgp:rgpStatus> 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 <info> response for "addPeriod" status:
+
+   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
+   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
+   S:     epp-1.0.xsd">
+   S:  <response>
+   S:    <result code="1000">
+   S:      <msg>Command completed successfully</msg>
+   S:    </result>
+   S:    <resData>
+   S:      <domain:infData
+   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
+   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
+   S:       domain-1.0.xsd">
+   S:        <domain:name>example.com</domain:name>
+   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
+   S:        <domain:status s="ok"/>
+   S:        <domain:registrant>jd1234</domain:registrant>
+   S:        <domain:contact type="admin">sh8013</domain:contact>
+   S:        <domain:contact type="tech">sh8013</domain:contact>
+   S:        <domain:ns>
+   S:          <domain:hostObj>ns1.example.com</domain:hostObj>
+   S:          <domain:hostObj>ns1.example.net</domain:hostObj>
+   S:        </domain:ns>
+   S:        <domain:host>ns1.example.com</domain:host>
+   S:        <domain:host>ns2.example.com</domain:host>
+   S:        <domain:clID>ClientX</domain:clID>
+   S:        <domain:crID>ClientX</domain:crID>
+   S:        <domain:crDate>2003-11-26T22:00:00.0Z</domain:crDate>
+   S:        <domain:exDate>2005-11-26T22:00:00.0Z</domain:exDate>
+   S:        <domain:authInfo>
+   S:          <domain:pw>2fooBAR</domain:pw>
+   S:        </domain:authInfo>
+   S:      </domain:infData>
+   S:    </resData>
+   S:    <extension>
+   S:      <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
+   S:       rgp-1.0.xsd">
+   S:        <rgp:rgpStatus s="addPeriod"/>
+   S:      </rgp:infData>
+   S:    </extension>
+   S:    <trID>
+   S:      <clTRID>ABC-12345</clTRID>
+   S:      <svTRID>54322-XYZ</svTRID>
+   S:    </trID>
+
+
+
+Hollenbeck                  Standards Track                     [Page 9]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+   S:  </response>
+   S:</epp>
+
+   Example <info> response for "redemptionPeriod" status:
+
+   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
+   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
+   S:     epp-1.0.xsd">
+   S:  <response>
+   S:    <result code="1000">
+   S:      <msg>Command completed successfully</msg>
+   S:    </result>
+   S:    <resData>
+   S:      <domain:infData
+   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
+   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
+   S:       domain-1.0.xsd">
+   S:        <domain:name>example.com</domain:name>
+   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
+   S:        <domain:status s="pendingDelete"/>
+   S:        <domain:registrant>jd1234</domain:registrant>
+   S:        <domain:contact type="admin">sh8013</domain:contact>
+   S:        <domain:contact type="tech">sh8013</domain:contact>
+   S:        <domain:ns>
+   S:          <domain:hostObj>ns1.example.com</domain:hostObj>
+   S:          <domain:hostObj>ns1.example.net</domain:hostObj>
+   S:        </domain:ns>
+   S:        <domain:host>ns1.example.com</domain:host>
+   S:        <domain:host>ns2.example.com</domain:host>
+   S:        <domain:clID>ClientX</domain:clID>
+   S:        <domain:crID>ClientY</domain:crID>
+   S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
+   S:        <domain:upID>ClientX</domain:upID>
+   S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
+   S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
+   S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
+   S:        <domain:authInfo>
+   S:          <domain:pw>2fooBAR</domain:pw>
+   S:        </domain:authInfo>
+   S:      </domain:infData>
+   S:    </resData>
+   S:    <extension>
+   S:      <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
+   S:       rgp-1.0.xsd">
+   S:        <rgp:rgpStatus s="redemptionPeriod"/>
+
+
+
+Hollenbeck                  Standards Track                    [Page 10]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+   S:      </rgp:infData>
+   S:    </extension>
+   S:    <trID>
+   S:      <clTRID>ABC-12345</clTRID>
+   S:      <svTRID>54322-XYZ</svTRID>
+   S:    </trID>
+   S:  </response>
+   S:</epp>
+
+   Example <info> response extension for "pendingRestore" status (note
+   that only the extension element changes from the first example):
+
+   S:<extension>
+   S:  <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+   S:   xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
+   S:   rgp-1.0.xsd">
+   S:    <rgp:rgpStatus s="pendingRestore"/>
+   S:  </rgp:infData>
+   S:</extension>
+
+   Example <info> response extension for "pendingDelete" status (note
+   that only the extension element changes from the first example):
+
+   S:<extension>
+   S:  <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+   S:   xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
+   S:   rgp-1.0.xsd">
+   S:    <rgp:rgpStatus s="pendingDelete"/>
+   S:  </rgp:infData>
+   S:</extension>
+
+4.1.3.  EPP <transfer> Command
+
+   This extension does not add any elements to the EPP <transfer>
+   command or <transfer> response described in the EPP domain mapping
+   [2].
+
+4.2.  EPP Transform Commands
+
+   EPP provides five commands to transform objects: <create> to create
+   an instance of an object, <delete> to delete an instance of an
+   object, <renew> to extend the validity period of an object,
+   <transfer> to manage object sponsorship changes, and <update> to
+   change information associated with an object.
+
+
+
+
+
+
+
+Hollenbeck                  Standards Track                    [Page 11]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+4.2.1.  EPP <create> Command
+
+   This extension does not add any elements to the EPP <create> command
+   or <create> response described in the EPP domain mapping [2].
+
+4.2.2.  EPP <delete> Command
+
+   This extension does not add any elements to the EPP <delete> command
+   or <delete> response described in the EPP domain mapping [2].
+
+4.2.3.  EPP <renew> Command
+
+   This extension does not add any elements to the EPP <renew> command
+   or <renew> response described in the EPP domain mapping [2].
+
+4.2.4.  EPP <transfer> Command
+
+   This extension does not add any elements to the EPP <transfer>
+   command or <transfer> response described in the EPP domain mapping
+   [2].
+
+4.2.5.  EPP <update> Command
+
+   This extension defines additional elements to extend the EPP <update>
+   command and response described in the EPP domain mapping [2] for
+   redemption grace period processing.
+
+   The EPP <update> 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 <delete> 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 <update> command.  The requirement to
+   provide at least one <domain:add>, <domain:rem>, or <domain:chg>
+   element is updated by this extension such that at least one empty
+   <domain:add>, <domain:rem>, or <domain:chg> element MUST be present
+   if this extension is specified within an <update> 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 <update> command MUST contain an <extension>
+   element.  The <extension> element MUST contain a child <rgp:update>
+   element that identifies the registry grace period namespace and the
+   location of the registry grace period schema.  The <rgp:update>
+
+
+
+
+Hollenbeck                  Standards Track                    [Page 12]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+   element contains a single <rgp:restore> element that contains an
+   OPTIONAL <rgp:report> element that MAY be used to deliver a
+   redemption grace period restore report.
+
+   The <rgp:restore> 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 <rgp:report> element MUST
+   NOT be present.  If the value of the "op" attribute is "report" an
+   <rgp:report> element MUST be present.
+
+   The <rgp:report> element contains the following child elements:
+
+   -  An <rgp:preData> 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 <rgp:postData> 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 <rgp:delTime> element that contains the date and time when the
+      domain name delete request was sent to the server.
+
+   -  An <rgp:resTime> element that contains the date and time when the
+      original <rgp:restore> command was sent to the server.
+
+   -  An <rgp:resReason> element that contains a brief explanation of
+      the reason for restoring the domain name.
+
+   -  An <rgp:statement> 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 <rgp:other> 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 <rgp:statement> 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 <rgp:other> 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 <update> command without a restore report:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
+   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
+   C:     epp-1.0.xsd">
+   C:  <command>
+   C:    <update>
+   C:      <domain:update
+   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
+   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
+   C:       domain-1.0.xsd">
+   C:        <domain:name>example.com</domain:name>
+   C:        <domain:chg/>
+   C:      </domain:update>
+   C:    </update>
+   C:    <extension>
+   C:      <rgp:update xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
+   C:       rgp-1.0.xsd">
+   C:        <rgp:restore op="request"/>
+   C:      </rgp:update>
+   C:    </extension>
+   C:    <clTRID>ABC-12345</clTRID>
+   C:  </command>
+   C:</epp>
+
+   Example <update> command with a restore report:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
+   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
+   C:     epp-1.0.xsd">
+   C:  <command>
+   C:    <update>
+   C:      <domain:update
+   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
+   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
+   C:       domain-1.0.xsd">
+
+
+
+Hollenbeck                  Standards Track                    [Page 14]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+   C:        <domain:name>example.com</domain:name>
+   C:        <domain:chg/>
+   C:      </domain:update>
+   C:    </update>
+   C:    <extension>
+   C:      <rgp:update xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
+   C:       rgp-1.0.xsd">
+   C:        <rgp:restore op="report">
+   C:          <rgp:report>
+   C:            <rgp:preData>Pre-delete registration data goes here.
+   C:            Both XML and free text are allowed.</rgp:preData>
+   C:            <rgp:postData>Post-restore registration data goes here.
+   C:            Both XML and free text are allowed.</rgp:postData>
+   C:            <rgp:delTime>2003-07-10T22:00:00.0Z</rgp:delTime>
+   C:            <rgp:resTime>2003-07-20T22:00:00.0Z</rgp:resTime>
+   C:            <rgp:resReason>Registrant error.</rgp:resReason>
+   C:            <rgp:statement>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.</rgp:statement>
+   C:            <rgp:statement>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.</rgp:statement>
+   C:            <rgp:other>Supporting information goes
+   C:            here.</rgp:other>
+   C:          </rgp:report>
+   C:        </rgp:restore>
+   C:      </rgp:update>
+   C:    </extension>
+   C:    <clTRID>ABC-12345</clTRID>
+   C:  </command>
+   C:</epp>
+
+   When an extended <update> 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 <update>
+   command.  The extension element contains a single child element
+   (<upData>) that itself contains a single child element (<rgpStatus>)
+   that contains a single attribute "s" whose value MUST be
+   "pendingRestore" if the <restore> request has been accepted.
+
+
+
+
+
+
+Hollenbeck                  Standards Track                    [Page 15]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+   Example "restore request" <update> response:
+
+   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
+   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
+   S:     epp-1.0.xsd">
+   S:  <response>
+   S:    <result code="1000">
+   S:      <msg lang="en">Command completed successfully</msg>
+   S:    </result>
+   S:    <extension>
+   S:      <rgp:upData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
+   S:       rgp-1.0.xsd">
+   S:        <rgp:rgpStatus s="pendingRestore"/>
+   S:      </rgp:upData>
+   S:    </extension>
+   S:    <trID>
+   S:      <clTRID>ABC-12345</clTRID>
+   S:      <svTRID>54321-XYZ</svTRID>
+   S:    </trID>
+   S:  </response>
+   S:</epp>
+
+   When an extended <update> 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
+   <?xml version="1.0" encoding="UTF-8"?>
+
+   <schema targetNamespace="urn:ietf:params:xml:ns:rgp-1.0"
+           xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
+           xmlns="http://www.w3.org/2001/XMLSchema"
+           elementFormDefault="qualified">
+
+
+
+
+Hollenbeck                  Standards Track                    [Page 16]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+     <annotation>
+       <documentation>
+         Extensible Provisioning Protocol v1.0
+         domain name extension schema for registry grace period
+         processing.
+       </documentation>
+     </annotation>
+
+   <!--
+   Child elements found in EPP commands.
+   -->
+     <element name="update" type="rgp:updateType"/>
+
+   <!--
+   Child elements of the <update> command for the
+   redemption grace period.
+   -->
+     <complexType name="updateType">
+       <sequence>
+         <element name="restore" type="rgp:restoreType"/>
+       </sequence>
+     </complexType>
+
+     <complexType name="restoreType">
+       <sequence>
+         <element name="report" type="rgp:reportType"
+          minOccurs="0"/>
+       </sequence>
+       <attribute name="op" type="rgp:rgpOpType" use="required"/>
+     </complexType>
+
+   <!--
+   New redemption grace period operations can be defined
+   by adding to this enumeration.
+   -->
+     <simpleType name="rgpOpType">
+       <restriction base="token">
+         <enumeration value="request"/>
+         <enumeration value="report"/>
+       </restriction>
+     </simpleType>
+
+     <complexType name="reportType">
+       <sequence>
+         <element name="preData" type="rgp:mixedType"/>
+         <element name="postData" type="rgp:mixedType"/>
+         <element name="delTime" type="dateTime"/>
+         <element name="resTime" type="dateTime"/>
+
+
+
+Hollenbeck                  Standards Track                    [Page 17]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+         <element name="resReason" type="rgp:reportTextType"/>
+         <element name="statement" type="rgp:reportTextType"
+          maxOccurs="2"/>
+         <element name="other" type="rgp:mixedType"
+          minOccurs="0"/>
+       </sequence>
+     </complexType>
+
+     <complexType name="mixedType">
+       <complexContent mixed="true">
+         <restriction base="anyType">
+           <sequence>
+             <any processContents="lax"
+              minOccurs="0" maxOccurs="unbounded"/>
+           </sequence>
+         </restriction>
+       </complexContent>
+     </complexType>
+
+     <complexType name="reportTextType">
+       <complexContent mixed="true">
+         <restriction base="anyType">
+           <sequence>
+             <any processContents="lax"
+              minOccurs="0" maxOccurs="unbounded"/>
+           </sequence>
+           <attribute name="lang" type="language" default="en"/>
+         </restriction>
+       </complexContent>
+     </complexType>
+
+   <!--
+   Child response elements.
+   -->
+     <element name="infData" type="rgp:respDataType"/>
+     <element name="upData" type="rgp:respDataType"/>
+
+   <!--
+   Response elements.
+   -->
+     <complexType name="respDataType">
+       <sequence>
+         <element name="rgpStatus" type="rgp:statusType"
+          maxOccurs="unbounded"/>
+       </sequence>
+     </complexType>
+
+   <!--
+
+
+
+Hollenbeck                  Standards Track                    [Page 18]
+
+RFC 3915                EPP Grace Period Mapping          September 2004
+
+
+   Status is a combination of attributes and an optional
+   human-readable message that may be expressed in languages
+   other than English.
+   -->
+     <complexType name="statusType">
+       <simpleContent>
+         <extension base="normalizedString">
+           <attribute name="s" type="rgp:statusValueType"
+            use="required"/>
+           <attribute name="lang" type="language" default="en"/>
+         </extension>
+       </simpleContent>
+     </complexType>
+
+     <simpleType name="statusValueType">
+       <restriction base="token">
+         <enumeration value="addPeriod"/>
+         <enumeration value="autoRenewPeriod"/>
+         <enumeration value="renewPeriod"/>
+         <enumeration value="transferPeriod"/>
+         <enumeration value="pendingDelete"/>
+         <enumeration value="pendingRestore"/>
+         <enumeration value="redemptionPeriod"/>
+       </restriction>
+     </simpleType>
+
+   <!--
+   End of schema.
+   -->
+   </schema>
+   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 <?xml?> 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, <http://www.w3.org/TR/REC-xml>.
+
+   [4]  Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
+        Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
+        <http://www.w3.org/TR/xmlschema-1/>.
+
+   [5]  Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
+        REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
+
+   [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]
+