--- 1/draft-ietf-regext-epp-fees-03.txt	2017-06-05 12:13:19.688660025 -0700
+++ 2/draft-ietf-regext-epp-fees-04.txt	2017-06-05 12:13:19.748661460 -0700
@@ -1,20 +1,20 @@
 
 Registration Protocols Extensions                              R. Carney
 Internet-Draft                                              GoDaddy Inc.
 Intended status: Standards Track                                G. Brown
-Expires: October 26, 2017                           CentralNic Group plc
+Expires: December 6, 2017                           CentralNic Group plc
                                                                J. Frakes
-                                                          April 24, 2017
+                                                            June 4, 2017
 
  Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
-                     draft-ietf-regext-epp-fees-03
+                     draft-ietf-regext-epp-fees-04
 
 Abstract
 
    This document describes an Extensible Provisioning Protocol (EPP)
    extension mapping for registry fees.
 
 Status of This Memo
 
    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.
@@ -22,21 +22,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on October 26, 2017.
+   This Internet-Draft will expire on December 6, 2017.
 
 Copyright Notice
 
    Copyright (c) 2017 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -60,43 +60,44 @@
        3.4.2.  Grace Periods . . . . . . . . . . . . . . . . . . . .   6
        3.4.3.  Correlation between Refundability and Grace Periods .   7
        3.4.4.  Applicability . . . . . . . . . . . . . . . . . . . .   7
      3.5.  Account Balance . . . . . . . . . . . . . . . . . . . . .   7
      3.6.  Credit Limit  . . . . . . . . . . . . . . . . . . . . . .   7
      3.7.  Classification of Objects . . . . . . . . . . . . . . . .   8
      3.8.  Phase and Subphase Attributes . . . . . . . . . . . . . .   8
    4.  Server Handling of Fee Information  . . . . . . . . . . . . .   9
    5.  EPP Command Mapping . . . . . . . . . . . . . . . . . . . . .   9
      5.1.  EPP Query Commands  . . . . . . . . . . . . . . . . . . .   9
-       5.1.1.  EPP <check> Command . . . . . . . . . . . . . . . . .   9
-         5.1.1.1.  Server Handling of Elements . . . . . . . . . . .  13
+       5.1.1.  EPP <check> Command . . . . . . . . . . . . . . . . .  10
+         5.1.1.1.  Server Handling of Elements . . . . . . . . . . .  14
        5.1.2.  EPP Transfer Query Command  . . . . . . . . . . . . .  14
      5.2.  EPP Transform Commands  . . . . . . . . . . . . . . . . .  15
        5.2.1.  EPP <create> Command  . . . . . . . . . . . . . . . .  15
        5.2.2.  EPP <delete> Command  . . . . . . . . . . . . . . . .  18
        5.2.3.  EPP <renew> Command . . . . . . . . . . . . . . . . .  19
        5.2.4.  EPP <transfer> Command  . . . . . . . . . . . . . . .  21
        5.2.5.  EPP <update> Command  . . . . . . . . . . . . . . . .  23
    6.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  25
      6.1.  Fee Extension Schema  . . . . . . . . . . . . . . . . . .  25
    7.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
      8.1.  XML Namespace . . . . . . . . . . . . . . . . . . . . . .  29
-     8.2.  EPP Extension Registry  . . . . . . . . . . . . . . . . .  29
+     8.2.  EPP Extension Registry  . . . . . . . . . . . . . . . . .  30
    9.  Implemntation Status  . . . . . . . . . . . . . . . . . . . .  30
-     9.1.  RegistryEngine EPP Service  . . . . . . . . . . . . . . .  30
+     9.1.  RegistryEngine EPP Service  . . . . . . . . . . . . . . .  31
    10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
    11. Change History  . . . . . . . . . . . . . . . . . . . . . . .  31
-     11.1.  Change from 02 to 03 . . . . . . . . . . . . . . . . . .  31
-     11.2.  Change from 01 to 02 . . . . . . . . . . . . . . . . . .  31
-     11.3.  Change from 00 to 01 . . . . . . . . . . . . . . . . . .  32
-     11.4.  Change from draft-brown-00 to draft-ietf-regext-fees-00   32
+     11.1.  Change from 03 to 04 . . . . . . . . . . . . . . . . . .  31
+     11.2.  Change from 02 to 03 . . . . . . . . . . . . . . . . . .  32
+     11.3.  Change from 01 to 02 . . . . . . . . . . . . . . . . . .  32
+     11.4.  Change from 00 to 01 . . . . . . . . . . . . . . . . . .  32
+     11.5.  Change from draft-brown-00 to draft-ietf-regext-fees-00   32
    12. Normative References  . . . . . . . . . . . . . . . . . . . .  32
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33
 
 1.  Introduction
 
    Historically, domain name registries have applied a simple fee
    structure for billable transactions, namely a basic unit price
    applied to domain <create>, <renew>, <transfer> and RGP [RFC3915]
    restore commands.  Given the relatively small number of EPP servers
    to which EPP clients have been required to connect, it has generally
@@ -104,49 +105,49 @@
    of these fees out-of-band by contacting the server operators.
 
    Given the recent expansion of the DNS namespace, and the
    proliferation of novel business models, it is now desirable to
    provide a method for EPP clients to query EPP servers for the fees
    and credits associated with certain commands and specific objects.
 
    This document describes an extension mapping for version 1.0 of the
    Extensible Provisioning Protocol (EPP) [RFC5730].  This EPP mapping
    provides a mechanism by which EPP clients may query the fees and
-   credits associated with various billable transactions, and also
-   obtain their current account balance.
+   credits associated with various billable transactions, and obtain
+   their current account balance.
 
 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 RFC 2119 [RFC2119].
 
    XML is case sensitive.  Unless stated otherwise, XML specifications
    and examples provided in this document MUST be interpreted in the
    character case presented in order to develop a conforming
    implementation.
 
    "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:fee-
-   0.17".  The XML namespace prefix "fee" is used, but implementations
+   0.19".  The XML namespace prefix "fee" is used, but implementations
    MUST NOT depend on it and instead employ a proper namespace-aware XML
    parser and serializer to interpret and output the XML documents.
 
    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 are provided only to illustrate element
    relationships and are not a REQUIRED feature of this protocol.
 
    (Note to RFC Editor: remove the following paragraph before
    publication as an RFC.)
 
    The XML namespace prefix above contains a version number,
-   specifically "0.17".  This version number will increment with
+   specifically "0.19".  This version number will increment with
    successive versions of this document, and will reach 1.0 if and when
    this document is published as an RFC.  This permits clients to
    distinguish which version of the extension a server has implemented.
 
 2.  Migrating to Newer Versions of This Extension
 
    (Note to RFC Editor: remove this section before publication as an
    RFC.)
 
    Servers which implement this extension SHOULD provide a way for
@@ -196,41 +197,41 @@
 3.2.  Currency Codes
 
    The <fee:currency> element is used to indicate which currency fees
    are charged in.  This value of this element MUST be a three-character
    currency code from [ISO4217].
 
    Note that ISO 4217 provides the special "XXX" code, which MAY be used
    if the server uses a non-currency based system for assessing fees,
    such as a system of credits.
 
-   The use of <fee:currency> elements in commands is OPTIONAL: if a
-   <fee:currency> element is not present in a command, the server MUST
+   The use of <fee:currency> elements in client commands is OPTIONAL: if
+   a <fee:currency> element is not present in a command, the server MUST
    determine the currency based on the client's account settings which
    MUST be agreed by the client and server via an out-of-band channel.
    However, the <fee:currency> element MUST be present in responses.
 
    Servers SHOULD NOT perform a currency conversion if a client uses an
    incorrect currency code.  Servers SHOULD return a 2004 "Parameter
    value range" error instead.
 
 3.3.  Validity Periods
 
    When querying for fee information using the <check> command, the
    <fee:period> element is used to indicate the units to be added to the
    registration period of objects by the <create>, <renew> and
    <transfer> commands.  This element is derived from the
    <domain:period> element described in [RFC5731].
 
-   The <fee:period> element is OPTIONAL in <check> commands: if omitted,
-   the server MUST determine the fee(s) using a validity period of 1
-   year.  The <fee:period> element MUST be present in <check> responses.
+   The <fee:period> element is OPTIONAL in <check> commands, if omitted,
+   the server MUST determine the fee(s) using the server default period.
+   The <fee:period> element MUST be present in <check> responses.
 
 3.4.  Fees and Credits
 
    Servers which implement this extension will include elements in
    responses which provide information about the fees and/or credits
    associated with a given billable transaction.
 
    The <fee:fee> and <fee:credit> elements are used to provide this
    information.  The presence of a <fee:fee> element in a response
    indicates a debit against the client's account balance; a
@@ -342,22 +343,22 @@
    Whether or not the <fee:creditLimit> is included in responses is a
    matter of server policy.  However, if a server chooses to offer
    support for this element, it MUST be included in responses to all
    "transform" commands (ie <create>, <renew>, <update>, <delete>,
    <transfer op="request">).
 
 3.7.  Classification of Objects
 
    Objects may be assigned to a particular class, category, or tier,
    each of which has a particular fee or set of fees associated with it.
-   The <fee:class> element which appears in <check> responses is used to
-   indicate the classification of an object.
+   The <fee:class> element, which MAY appear in <check> and transform
+   responses, is used to indicate the classification of an object.
 
    If a server makes use of this element, it should provide clients with
    a list of all the values that the element may take via an out-of-band
    channel.  Servers MUST NOT use values which do not appear on this
    list.
 
    Servers which make use of this element MUST use a <fee:class> element
    with the value "standard" for all objects that are subject to the
    standard or default fee.
 
@@ -393,23 +394,30 @@
    subphase combination) not supported by server the server MUST respond
    with a 2004 "Parameter value range" error.
 
 4.  Server Handling of Fee Information
 
    Depending on server policy, a client MAY be required to include the
    extension elements described in this document for certain transform
    commands.  Servers must provide clear documentation to clients about
    the circumstances in which this extension must be used.
 
+   The server MUST return avail="0" in its response to a <check> command
+   for any domain name in the <check> command that does not include the
+   <fee:check> extension for which the server would likewise fail a
+   domain <create>> command when no <fee< extension is provided for that
+   same domain name.
+
    If a server receives a command from a client which does not include
-   the extension elements required by the server for that command, then
-   it MUST respond with a 2003 "Required parameter missing" error.
+   the fee extension data elements required by the server for that
+   command, then the server MUST respond with a 2003 "Required parameter
+   missing" error.
 
    If the currency or total fee provided by the client do not agree with
    the server's own calculation of the fee for that command, then the
    server MUST reject the command with a 2004 "Parameter value range"
    error.
 
 5.  EPP Command Mapping
 
    A detailed description of the EPP syntax and semantics can be found
    in [RFC5730].
@@ -427,97 +435,96 @@
    The command MAY contain an <extension> element which MAY contain a
    <fee:check> element.  The <fee:check> element MAY contain one
    <fee:currency> element and MUST contain one or more <fee:command>
    elements.
 
    The <fee:command> element(s) contain(s) a "name" attribute, an
    OPTIONAL "phase" attribute, and an OPTIONAL "subphase" attribute.
    The <fee:command> element(s) MAY have the following child elements:
 
    o  An OPTIONAL <fee:period> element.
-   o  An OPTIONAL <fee:class> element.
 
    Example <check> command:
 
    C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
    C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    C:   <command>
    C:     <check>
    C:       <domain:check
    C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    C:         <domain:name>example.com</domain:name>
    C:         <domain:name>example.net</domain:name>
    C:         <domain:name>example.xyz</domain:name>
    C:       </domain:check>
    C:     </check>
    C:     <extension>
-   C:       <fee:check xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   C:       <fee:check xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    C:         <fee:currency>USD</fee:currency>
    C:         <fee:command name="create">
    C:           <fee:period unit="y">2</fee:period>
    C:         </fee:command>
    C:         <fee:command name="renew"/>
    C:         <fee:command name="transfer"/>
    C:         <fee:command name="restore"/>
    C:       </fee:check>
    C:     </extension>
    C:     <clTRID>ABC-12345</clTRID>
    C:   </command>
    C: </epp>
 
    When the server receives a <check> command that includes the
    extension elements described above, its response MUST contain an
    <extension> element, which MUST contain a child <fee:chkData>
    element.  The <fee:chkData> element MUST contain a <fee:currency>
-   element and a <fee:cd> for each <domain:name> element referenced in
-   the <domain:check> element of the client command.
+   element and a <fee:cd> for each element referenced in the client
+   <check> command.
 
    Each <fee:cd> element MUST contain the following child elements:
 
-   o  A <fee:objID> element, which MUST match a <domain:name> from the
-      client command.
-   o  A <fee:command> element matching each <fee:command> that appeared
-      in the corresponding <fee:check> of the client command.  This
-      element MAY have the OPTIONAL "phase" and "subphase" attributes,
-      which MUST match the same attributes in the corresponding
-      <fee:command> element of the client command.
+   o  A <fee:objID> element, which MUST match an element referenced in
+      the client <check> command.
+   o  A <fee:command> element matching each <fee:command> (unless the
+      "avail" attribute of the <fee:cd> if false) that appeared in the
+      corresponding <fee:check> of the client command.  This element MAY
+      have the OPTIONAL "phase" and "subphase" attributes, which MUST
+      match the same attributes in the corresponding <fee:command>
+      element of the client command.
 
    The <fee:cd> element also has an OPTIONAL "avail" attribute which is
    a boolean.  If the value of this attribute evaluates to false, this
    indicates that the server cannot calculate the relevant fees, because
    the object, command, currency, period, class or some combination is
    invalid per server policy.  If "avail" is false then the <fee:cd>
-   element MAY contain a <fee:reason> element and the server MAY
+   element MUST contain a <fee:reason> element and the server MAY
    eliminate some or all of the <fee:command> element(s).
 
    The <fee:command> element(s) MAY have the following child elements:
 
    o  An OPTIONAL <fee:period> element, which contains the same unit
       that appeared in the <fee:period> element of the command.  If the
       value of the preceding <fee:command> element is "restore", this
       element MUST NOT be included, otherwise it MUST be included.  If
-      no <fee:period> appeared in command (and the command is not
-      "restore") then the server MUST return its default period value.
+      no <fee:period> appeared in the client command (and the command is
+      not "restore") then the server MUST return its default period
+      value.
    o  Zero or more <fee:fee> elements.
    o  Zero or more <fee:credit> elements.
    o  An OPTIONAL <fee:class> element.
    o  An OPTIONAL <fee:reason> element.
 
-   If the "avail" attribute of the <fee:cd> elelment is true and if no
+   If the "avail" attribute of the <fee:cd> element is true and if no
    <fee:fee> elements are present in a <fee:command> element, this
    indicates that no fee will be assessed by the server for this
    command.
 
-   If the "avail" attribute of the <fee:cd> element is false, then the
-   <fee:command> element MUST NOT contain any <fee:fee> or <fee:credit>
-   child elements.  If the "avail" attribute is true, then the
-   <fee:command> element MUST NOT contain a <fee:reason> element.
+   If the "avail" attribute is true, then the <fee:command> element MUST
+   NOT contain a <fee:reason> element.
 
    Example <check> response:
 
 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
 S:   <response>
 S:     <result code="1000">
 S:       <msg>Command completed successfully</msg>
 S:     </result>
 S:     <resData>
@@ -529,24 +536,24 @@
 S:         <domain:cd>
 S:           <domain:name avail="1">example.net</domain:name>
 S:         </domain:cd>
 S:         <domain:cd>
 S:           <domain:name avail="1">example.xyz</domain:name>
 S:         </domain:cd>
 S:       </domain:chkData>
 S:     </resData>
 S:     <extension>
 S:       <fee:chkData
-S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.17"
+   S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.19"
 S:           xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
 S:         <fee:currency>USD</fee:currency>
-S:         <fee:cd>
+   S:         <fee:cd avail="1">
 S:           <fee:objID>example.com</fee:objID>
 S:           <fee:command name="create">
 S:             <fee:period unit="y">2</fee:period>
 S:             <fee:fee
 S:               description="Registration Fee"
 S:               refundable="1"
 S:               grace-period="P5D">10.00</fee:fee>
 S:           </fee:command>
 S:           <fee:command name="renew">
 S:             <fee:period unit="y">1</fee:period>
@@ -560,21 +567,21 @@
 S:             <fee:fee
 S:               description="Transfer Fee"
 S:               refundable="1"
 S:               grace-period="P5D">5.00</fee:fee>
 S:           </fee:command>
 S:           <fee:command name="restore">
 S:             <fee:fee
 S:               description="Redemption Fee">5.00</fee:fee>
 S:           </fee:command>
 S:         </fee:cd>
-S:         <fee:cd>
+   S:         <fee:cd avail="1">
 S:           <fee:objID>example.net</fee:objID>
 S:           <fee:command name="create">
 S:             <fee:period unit="y">2</fee:period>
 S:             <fee:fee
 S:               description="Registration Fee"
 S:               refundable="1"
 S:               grace-period="P5D">10.00</fee:fee>
 S:           </fee:command>
 S:           <fee:command name="renew">
 S:             <fee:period unit="y">1</fee:period>
@@ -592,65 +599,63 @@
 S:           </fee:command>
 S:           <fee:command name="restore">
 S:             <fee:fee
 S:               description="Redemption Fee">5.00</fee:fee>
 S:           </fee:command>
 S:         </fee:cd>
 S:         <fee:cd avail="0">
 S:           <fee:objID>example.xyz</fee:objID>
 S:           <fee:command name="create">
 S:             <fee:period unit="y">2</fee:period>
-S:             <fee:reason>Only 1 year registration periods are vaild.</fee:reason>
+   S:             <fee:reason>Only 1 year registration periods are
+   S:               vaild.</fee:reason>
 S:           </fee:command>
 S:         </fee:cd>
 S:       </fee:chkData>
 S:     </extension>
 S:     <trID>
 S:       <clTRID>ABC-12345</clTRID>
 S:       <svTRID>54322-XYZ</svTRID>
 S:     </trID>
 S:   </response>
 S: </epp>
 
 5.1.1.1.  Server Handling of Elements
 
    Clients MAY include a <fee:class> in the <fee:command> element.
-   There are three ways in which servers may handle this element:
+   There are two ways in which servers may handle this element:
 
    1.  If the server supports the concept of tiers or classes of
        objects, then the value of this element MUST be validated.  If
        incorrect for the specified object, the "avail" attribute of the
-       corresponding <fee:command> element MUST be false.
-
+       corresponding <fee:cd> element MUST be false.
    2.  If the server supports different "types" of object registrations
        (such as a "blocking" registration which does not resolve, or
        where a registry provides a value-added service that requires an
        opt-out to disable), then, as with the first model, the server
        MUST validate the value of the element.  If the value is
-       incorrect, the "avail" attribute of the corresponding
-       <fee:command> element MUST be false, and a <fee:reason> element
-       MUST be provided.
-   3.  If the server supports neither of the above models, the element
-       MUST be ignored.
+       incorrect, the "avail" attribute of the corresponding <fee:cd>
+       element MUST be false, and a <fee:reason> element MUST be
+       provided.
 
    Server operators must provide clear documentation to client operators
    which of the above models it supports.
 
 5.1.2.  EPP Transfer Query Command
 
    This extension does not add any elements to the EPP <transfer> query
    command, but does include elements in the response, when the
    extension has been selected during a <login> command.
 
    When the <transfer> query command has been processed successfully,
    the client selected the extension when it logged in, and the client
-   is authorised by the server to view information about the transfer,
+   is authorized by the server to view information about the transfer,
    the server MAY include in the <extension> section of the EPP response
    a <fee:trnData> element, which contains the following child elements:
 
    o  A <fee:currency> element.
    o  A <fee:period> element.
    o  Zero or more <fee:fee> elements containing the fees that will be
       charged to the gaining client.
    o  Zero or more <fee:credit> elements containing the credits that
       will be refunded to the losing client.
 
@@ -675,21 +680,21 @@
    S:         <domain:name>example.com</domain:name>
    S:         <domain:trStatus>pending</domain:trStatus>
    S:         <domain:reID>ClientX</domain:reID>
    S:         <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate>
    S:         <domain:acID>ClientY</domain:acID>
    S:         <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>
    S:         <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
    S:       </domain:trnData>
    S:     </resData>
    S:     <extension>
-   S:       <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   S:       <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    S:         <fee:currency>USD</fee:currency>
    S:         <fee:period unit="y">1</fee:period>
    S:         <fee:fee>5.00</fee:fee>
    S:       </fee:trnData>
    S:     </extension>
    S:     <trID>
    S:       <clTRID>ABC-12345</clTRID>
    S:       <svTRID>54322-XYZ</svTRID>
    S:     </trID>
    S:   </response>
@@ -746,21 +751,21 @@
    C:         </domain:ns>
    C:         <domain:registrant>jd1234</domain:registrant>
    C:         <domain:contact type="admin">sh8013</domain:contact>
    C:         <domain:contact type="tech">sh8013</domain:contact>
    C:         <domain:authInfo>
    C:           <domain:pw>2fooBAR</domain:pw>
    C:         </domain:authInfo>
    C:       </domain:create>
    C:     </create>
    C:     <extension>
-   C:       <fee:create xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   C:       <fee:create xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    C:         <fee:currency>USD</fee:currency>
    C:         <fee:fee>5.00</fee:fee>
    C:       </fee:create>
    C:     </extension>
    C:     <clTRID>ABC-12345</clTRID>
    C:   </command>
    C: </epp>
    Example <create> response:
 
    S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
@@ -771,21 +776,21 @@
    S:     </result>
    S:     <resData>
    S:       <domain:creData
    S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    S:         <domain:name>example.com</domain:name>
    S:         <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
    S:         <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
    S:       </domain:creData>
    S:     </resData>
    S:     <extension>
-   S:       <fee:creData xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   S:       <fee:creData xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    S:         <fee:currency>USD</fee:currency>
    S:         <fee:fee
    S:           description="Registration Fee"
    S:           refundable="1"
    S:           grace-period="P5D">5.00</fee:fee>
    S:         <fee:balance>-5.00</fee:balance>
    S:         <fee:creditLimit>1000.00</fee:creditLimit>
    S:       </fee:creData>
    S:     </extension>
    S:     <trID>
@@ -815,21 +820,21 @@
    Example <delete> response:
 
    S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
    S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    S:   <response>
    S:     <result code="1000">
    S:       <msg>Command completed successfully</msg>
    S:     </result>
    S:     <extension>
    S:       <fee:delData
-   S:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   S:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    S:         <fee:currency>USD</fee:currency>
    S:         <fee:credit description="AGP Credit">-5.00</fee:credit>
    S:         <fee:balance>1005.00</fee:balance>
    S:       </fee:delData>
    S:     </extension>
    S:     <trID>
    S:       <clTRID>ABC-12345</clTRID>
    S:       <svTRID>54321-XYZ</svTRID>
    S:     </trID>
    S:   </response>
@@ -866,21 +871,21 @@
    C:   <command>
    C:     <renew>
    C:       <domain:renew
    C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    C:         <domain:name>example.com</domain:name>
    C:         <domain:curExpDate>2000-04-03</domain:curExpDate>
    C:         <domain:period unit="y">5</domain:period>
    C:       </domain:renew>
    C:     </renew>
    C:     <extension>
-   C:       <fee:renew xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   C:       <fee:renew xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    C:         <fee:currency>USD</fee:currency>
    C:         <fee:fee>5.00</fee:fee>
    C:       </fee:renew>
    C:     </extension>
    C:     <clTRID>ABC-12345</clTRID>
    C:   </command>
    C: </epp>
    Example <renew> response:
 
    S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
@@ -890,21 +895,21 @@
    S:       <msg>Command completed successfully</msg>
    S:     </result>
    S:     <resData>
    S:       <domain:renData
    S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    S:         <domain:name>example.com</domain:name>
    S:         <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
    S:       </domain:renData>
    S:     </resData>
    S:     <extension>
-   S:       <fee:renData xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   S:       <fee:renData xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    S:         <fee:currency>USD</fee:currency>
    S:         <fee:fee
    S:           refundable="1"
    S:           grace-period="P5D">5.00</fee:fee>
    S:         <fee:balance>1000.00</fee:balance>
    S:       </fee:renData>
    S:     </extension>
    S:     <trID>
    S:       <clTRID>ABC-12345</clTRID>
    S:       <svTRID>54322-XYZ</svTRID>
@@ -946,21 +951,21 @@
    C:       <domain:transfer
    C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    C:         <domain:name>example.com</domain:name>
    C:         <domain:period unit="y">1</domain:period>
    C:         <domain:authInfo>
    C:           <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
    C:         </domain:authInfo>
    C:       </domain:transfer>
    C:     </transfer>
    C:     <extension>
-   C:       <fee:transfer xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   C:       <fee:transfer xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    C:         <fee:currency>USD</fee:currency>
    C:         <fee:fee>5.00</fee:fee>
    C:       </fee:transfer>
    C:     </extension>
    C:     <clTRID>ABC-12345</clTRID>
    C:   </command>
    C: </epp>
    Example <transfer> response:
 
    S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
@@ -975,21 +980,21 @@
    S:         <domain:name>example.com</domain:name>
    S:         <domain:trStatus>pending</domain:trStatus>
    S:         <domain:reID>ClientX</domain:reID>
    S:         <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate>
    S:         <domain:acID>ClientY</domain:acID>
    S:         <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>
    S:         <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
    S:       </domain:trnData>
    S:     </resData>
    S:     <extension>
-   S:       <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   S:       <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    S:         <fee:currency>USD</fee:currency>
    S:         <fee:fee
    S:           refundable="1"
    S:           grace-period="P5D">5.00</fee:fee>
    S:       </fee:trnData>
    S:     </extension>
    S:     <trID>
    S:       <clTRID>ABC-12345</clTRID>
    S:       <svTRID>54322-XYZ</svTRID>
    S:     </trID>
@@ -1028,38 +1033,38 @@
    C:     <update>
    C:       <domain:update
    C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    C:         <domain:name>example.com</domain:name>
    C:         <domain:chg>
    C:           <domain:registrant>sh8013</domain:registrant>
    C:         </domain:chg>
    C:       </domain:update>
    C:     </update>
    C:     <extension>
-   C:       <fee:update xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   C:       <fee:update xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    C:         <fee:currency>USD</fee:currency>
    C:         <fee:fee>5.00</fee:fee>
    C:       </fee:update>
    C:     </extension>
    C:     <clTRID>ABC-12345</clTRID>
    C:   </command>
    C: </epp>
    Example <update> response:
 
    S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
    S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    S:   <response>
    S:     <result code="1000">
    S:       <msg>Command completed successfully</msg>
    S:     </result>
    S:     <extension>
-   S:       <fee:updData xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
+   S:       <fee:updData xmlns:fee="urn:ietf:params:xml:ns:fee-0.19">
    S:         <fee:currency>USD</fee:currency>
    S:         <fee:fee>5.00</fee:fee>
    S:       </fee:updData>
    S:     </extension>
    S:     <trID>
    S:       <clTRID>ABC-12345</clTRID>
    S:       <svTRID>54321-XYZ</svTRID>
    S:     </trID>
    S:   </response>
    S: </epp>
@@ -1072,24 +1077,24 @@
    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.
 
 6.1.  Fee Extension Schema
 
   BEGIN
   <?xml version="1.0" encoding="utf-8"?>
   <schema xmlns="http://www.w3.org/2001/XMLSchema"
-    xmlns:fee="urn:ietf:params:xml:ns:fee-0.17"
+    xmlns:fee="urn:ietf:params:xml:ns:fee-0.19"
     xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
-    targetNamespace="urn:ietf:params:xml:ns:fee-0.17"
+    targetNamespace="urn:ietf:params:xml:ns:fee-0.19"
     elementFormDefault="qualified">
 
     <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
     <import namespace="urn:ietf:params:xml:ns:domain-1.0" />
 
     <annotation>
       <documentation>
         Extensible Provisioning Protocol v1.0 Fee Extension
 
       </documentation>
@@ -1107,21 +1112,21 @@
     <element name="update" type="fee:transformCommandType" />
     <element name="updData" type="fee:transformResultType" />
     <element name="delData" type="fee:transformResultType" />
 
     <!-- client <check> command -->
     <complexType name="checkType">
       <sequence>
         <element name="currency" type="fee:currencyType"
           minOccurs="0" />
         <element name="command" type="fee:commandType"
-          minOccurs=""1" "maxOccurs="unbounded" />
+          minOccurs="1" maxOccurs="unbounded" />
       </sequence>
     </complexType>
 
     <complexType name="objectIdentifierType">
       <simpleContent>
         <extension base="eppcom:labelType">
           <attribute name="element"
           type="NMTOKEN" default="name" />
         </extension>
       </simpleContent>
@@ -1187,29 +1192,34 @@
       <sequence>
         <element name="period" type="domain:periodType"
           minOccurs="0" maxOccurs="1" />
         <element name="fee" type="fee:feeType"
           minOccurs="0" maxOccurs="unbounded" />
         <element name="credit" type="fee:creditType"
           minOccurs="0" maxOccurs="unbounded" />
         <element name="class" type="token" minOccurs="0" />
         <element name="reason" type="token" minOccurs="0" />
       </sequence>
-      <attribute name="name" type="fee:commandTypeValue"/>
+      <attribute name="name" type="fee:commandEnum"/>
+      <attribute name="customName" type="token"/>
       <attribute name="phase" type="token" />
       <attribute name="subphase" type="token" />
     </complexType>
 
-    <simpleType name="commandTypeValue">
+    <simpleType name="commandEnum">
       <restriction base="token">
-        <minLength value="3"/>
-        <maxLength value="16"/>
+        <enumeration value="create"/>
+        <enumeration value="delete"/>
+        <enumeration value="renew"/>
+        <enumeration value="transfer"/>
+        <enumeration value="restore"/>
+        <enumeration value="custom"/>
       </restriction>
     </simpleType>
 
     <simpleType name="nonNegativeDecimal">
       <restriction base="decimal">
         <minInclusive value="0" />
       </restriction>
     </simpleType>
 
     <simpleType name="negativeDecimal">
@@ -1263,21 +1275,21 @@
    to this specification as well.
 
 8.  IANA Considerations
 
 8.1.  XML Namespace
 
    This document uses URNs to describe XML namespaces and XML schemas
    conforming to a registry mechanism described in [RFC3688].  The
    following URI assignment is requested of IANA:
 
-   URI: ietf:params:xml:ns:fee-0.17
+   URI: ietf:params:xml:ns:fee-0.19
 
    Registrant Contact: See the "Author's Address" section of this
    document.
 
    XML: See the "Formal Syntax" section of this document.
 
 8.2.  EPP Extension Registry
 
    The EPP extension described in this document should be registered by
    the IANA in the EPP Extension Registry described in [RFC7451].  The
@@ -1356,53 +1369,62 @@
    o  Ben Levac and Jeff Eckhaus of Demand Media
    o  Seth Goldman of Google
    o  Klaus Malorny and Michael Bauland of Knipp
    o  Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy
    o  Michael Holloway of Com Laude
    o  Santosh Kalsangrah of Impetus Infotech
    o  Alex Mayrhofer of Nic.at
 
 11.  Change History
 
-11.1.  Change from 02 to 03
+11.1.  Change from 03 to 04
+
+   Updated scheme to version 0.19 to correct typos and to replace the
+   commandTypeValue type with the commandEnum type and customName
+   attribute for stricter validation.  Updated various text for grammar
+   and clarity.  Added text to section 4 clarifying the <check> response
+   when the client provided no fee extension but the server was
+   expecting the extension.
+
+11.2.  Change from 02 to 03
 
    Updated scheme to version 0.17 to simplify the check command syntax.
    Moved fee avail to objectCDType to allow fast failing on error
-   situations.  Removed the objectCheckTpye as it was no longer being
+   situations.  Removed the objectCheckType as it was no longer being
    used.  Updated examples to reflect these scheme changes.  Added
    language for server failing a <create> if the <fee:fee> passed by the
    client is less than the server fee.
 
-11.2.  Change from 01 to 02
+11.3.  Change from 01 to 02
 
    Updated scheme to version 0.15 to fix errors in CommandType,
    objectCDType, transformCommandType and transformResultType
    definitions.
 
-11.3.  Change from 00 to 01
+11.4.  Change from 00 to 01
 
    Added Roger Carney as author to finish draft.  Moved Formal Syntax
    section to main level numbering.  Various grammar, typos, and
    administrative edits for clarity.  Removed default value for the
    "applied" attribute of <fee:fee> so that it can truly be optional.
    Added support for the <delete> command to return a <fee:fee> element
    as well.  Modified default response on the <check> command for the
    optional <fee:period> when it was not provided in the command,
    leaving it to the server to provide the default period value.
    Extensive edits were done to the <check> command, the <check>
    response and to the fee extension schema (checkType, objectCheckType,
    objectIdentifierType, objectCDType, commandType) to support
    requesting and returning multiple transformation fees in a single
    call.  Added section on Phase/Subphase to provide more context on the
    uses.
 
-11.4.  Change from draft-brown-00 to draft-ietf-regext-fees-00
+11.5.  Change from draft-brown-00 to draft-ietf-regext-fees-00
 
    Updated to be REGEXT WG document.
 
 12.  Normative References
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,
               DOI 10.17487/RFC2119, March 1997,
               <http://www.rfc-editor.org/info/rfc2119>.