    [Search] [txt|html|xml|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

    From: draft-ietf-regext-epp-registry-maintenance-19    Proposed Standard

    Internet Engineering Task Force (IETF)                        T. Sattler
    Request for Comments: 9167
    Category: Standards Track                                      R. Carney
    ISSN: 2070-1721                                                J. Kolker
                                                                GoDaddy Inc.
                                                               December 2021

       Registry Maintenance Notification for the Extensible Provisioning
                                 Protocol (EPP)

    Abstract

       This document describes an Extensible Provisioning Protocol (EPP)
       extension called "Registry Maintenance Notification", which is used
       by EPP servers to notify EPP clients and allow EPP clients to query
       EPP servers regarding maintenance events.

    Status of This Memo

       This is an Internet Standards Track document.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Further information on
       Internet Standards is available in Section 2 of RFC 7841.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       https://www.rfc-editor.org/info/rfc9167.

    Copyright Notice

       Copyright (c) 2021 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
       (https://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Revised BSD License text as described in Section 4.e of the
       Trust Legal Provisions and are provided without warranty as described
       in the Revised BSD License.

    Table of Contents

       1.  Introduction
         1.1.  Terminology and Definitions
       2.  Migrating to Newer Versions of This Extension
       3.  Object Attributes
         3.1.  Internationalized Domain Names
         3.2.  Dates and Times
         3.3.  Maintenance Elements
       4.  EPP Command Mapping
         4.1.  EPP Query Commands
           4.1.1.  EPP <info> Command
           4.1.2.  EPP <poll> Command
         4.2.  EPP Transform Commands
       5.  Formal Syntax
         5.1.  Registry Maintenance Notification EPP Mapping Schema
       6.  IANA Considerations
         6.1.  XML Namespace
         6.2.  EPP Extension Registry
       7.  Security Considerations
       8.  References
         8.1.  Normative References
         8.2.  Informative References
       Acknowledgments
       Authors' Addresses

    1.  Introduction

       The Extensible Provisioning Protocol (EPP), as defined in [RFC5730],
       is a protocol whose original motivation is to provide a standard
       Internet domain name registration protocol for use between registries
       and registrars.

       Registries routinely update systems to ensure a higher quality of
       service, implement new services, or upgrade protocols to the latest
       standards.  These updates are pushed to various registry environments
       during time frames communicated to registrars as "maintenance
       events".  Maintenance events may require making services unavailable
       for some limited time while the upgrade happens.  Registries usually
       inform registrars about maintenance events in various formats, none
       of which are standardized between registries.

       The DNS namespace expansion has led to many additional registries
       that registrars must interact with, adding more maintenance events
       and formats.  It is now desirable to provide an efficient approach to
       notify registrars.

       This document describes an extension mapping for version 1.0 of the
       EPP to provide a mechanism by which EPP servers may notify EPP
       clients of and allow EPP clients to query EPP servers on upcoming
       maintenance events.

    1.1.  Terminology and Definitions

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in
       BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
       capitals, as shown here.

       XML [W3C.REC-xml-20081126] 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.

       The XML namespace prefix "maint" is used for the namespace
       "urn:ietf:params:xml:ns:epp:maintenance-1.0", 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.

       "ote" is an abbreviation for "Operational Test and Evaluation".

       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.

    2.  Migrating to Newer Versions of This Extension

       Servers that implement this extension SHOULD provide a way for
       clients to progressively update their implementations when a new
       version of the extension is deployed.  A newer version of the
       extension is expected to use an XML namespace with a higher version
       number than the prior versions.

       Servers SHOULD (for a temporary migration period up to server policy)
       provide support for older versions of the extension in parallel to
       the newest version and allow clients to execute their preferred
       version of the <info> command based on the maintenance <objURI>
       elements of the server <greeting>.  The version of the maintenance
       <info> response MUST match the version of the maintenance <info>
       command executed by the server.

       Servers MUST return a Registry Maintenance Notification poll message
       matching the newest negotiated version of the maintenance extension,
       based on an intersection of the maintenance <objURI> elements in the
       server <greeting> and the client <login> command.  If the
       intersection of the maintenance <objURI> elements of the server
       <greeting> and the client <login> command results in an empty set,
       the server MUST return the newest version of the Registry Maintenance
       Notification poll message supported by the server based on "Usage
       with Poll-Message EPP Responses" in Section 6 of [RFC9038].

    3.  Object Attributes

    3.1.  Internationalized Domain Names

       Names of affected hosts MUST be provided in A-label form, according
       to [RFC5891].

    3.2.  Dates and Times

       All date and time attribute values MUST be expressed in Universal
       Coordinated Time (UTC) using the Gregorian calendar.  The date-time
       format defined as "date-time" in [RFC3339], with time-offset="Z",
       MUST be used.

    3.3.  Maintenance Elements

       The <maint:item> element describes a single registry maintenance
       event during a specific period.  This element is used in a
       maintenance item EPP <info> command and response as well as in a
       <poll> response.

       If an element is not marked as optional, it is mandatory.

       <maint:id>
          The server-unique identifier for the maintenance event with the
          OPTIONAL "name" attribute that includes a human-readable name of
          the event.  The server-unique identifier SHALL NOT be changed if
          the event is updated or deleted.  When the "name" attribute is
          set, the OPTIONAL "lang" attribute, per the language structure in
          [RFC5646], MAY be present to identify the language if the
          negotiated value is something other than the default value of "en"
          (English).

       <maint:type>
          Zero or more OPTIONAL types of the maintenance event, with the
          possible set of values defined by server policy, such as "Routine
          Maintenance", "Software Update", "Software Upgrade", or "Extended
          Outage".  The OPTIONAL "lang" attribute MAY be present to identify
          the language if the negotiated value is something other than the
          default value of "en" (English).

       <maint:pollType>
          The OPTIONAL <maint:pollType> element for a Registry Maintenance
          Notification poll message; values MUST be "create", "update",
          "delete", "courtesy", or "end".  For the "create" and "update"
          types, the server includes the state of the maintenance event
          after the creation or update.  For the "delete" type, the server
          includes the state of the event before the delete.  The "courtesy"
          provides a reminder of an event, and the "end" provides a
          notification of the end of the event without updating the
          maintenance object and includes the latest state of the event.
          This element MUST be present only for poll messages.

       <maint:systems>
          One or more <maint:system> elements that are affected by the
          maintenance event.

          <maint:system>
             The <maint:system> element contains the following child
             elements:

             <maint:name>
                The name of the affected system, such as "EPP", "WHOIS",
                "DNS", "Portal", "RDAP", etc.

             <maint:host>
                The OPTIONAL affected maintained system's hostname, which
                SHALL be in A-label form, according to [RFC5891].

             <maint:impact>
                The impact level; the values MUST be "full", "partial", or
                "none".  If access is expected to be intermittently
                unavailable, it is "partial".  If access is expected to be
                completely unavailable, it is "full".  If access is not
                affected, it is "none".

       <maint:environment>
          The type of the affected system; the attribute "type" is REQUIRED
          and MUST be "production", "ote", "staging", "dev", or "custom".
          For extensibility, the <maint:environment> element includes the
          OPTIONAL "name" attribute that can define the name of the custom
          environment when the <maint:environment> element "type" attribute
          has the "custom" value.  For example, for the custom "marketing"
          environment, the <maint:environment> element should be:
          <maint:environment type="custom" name="marketing"/>.

       <maint:start>
          The date and time of the start of the maintenance event.

       <maint:end>
          The date and time of the end of the maintenance event.  The
          <maint:end> element MUST be greater than the <maint:start>
          element.

       <maint:reason>
          The reason behind the maintenance event; the values MUST be either
          "planned" or "emergency".

       <maint:detail>
          The OPTIONAL URI to the detailed maintenance event description,
          formatted according to [RFC3986].

       <maint:description>
          Zero or more OPTIONAL free-form descriptions of the maintenance
          event, usable without creating and traversing an external resource
          as defined by the <maint:detail> element.  The OPTIONAL "lang"
          attribute MAY be present to identify the language if the
          negotiated value is something other than the default value of "en"
          (English).  The OPTIONAL "type" attribute MAY be present to
          identify the format of the description.  It MUST be either "plain"
          for plain text or "html" for HTML text, as defined in [HTML5], and
          XML-escaped, with a default value of "plain".

       <maint:tlds>
          The OPTIONAL <maint:tlds> element contains one or more <maint:tld>
          child elements.  If the <maint:tlds> is not present, the entire
          system is affected.

          <maint:tld>
             The affected top-level domain or registry zone, which SHALL be
             in A-label form, according to [RFC5891].

          <maint:intervention>
             The OPTIONAL <maint:intervention> element contains the
             following child elements:

             <maint:connection>
                The value SHALL be boolean and indicates if a client needs
                to perform a connection-related action such as a reconnect.
                The attribute should only be used as a flag to indicate
                connections will be affected.  Servers SHOULD include a
                description of how the connections are affected in the
                <maint:description> element or use the <maint:detail>
                element above.

             <maint:implementation>
                The value SHALL be boolean and indicates if a client needs
                to perform an implementation-related action such as a code
                change.  The attribute should only be used as a flag to
                indicate implementation will be affected.  Servers SHOULD
                include a description of how the implementation is affected
                in the <maint:description> element or use the <maint:detail>
                element above.

          <maint:crDate>
             The date and time of the maintenance object creation.

          <maint:upDate>
             The OPTIONAL date and time of the most recent maintenance
             object modification.  This element MUST NOT be present if the
             maintenance object has never been modified.

    4.  EPP Command Mapping

       A detailed description of the EPP syntax and semantics can be found
       in the EPP core protocol specification [RFC5730].  The command
       mappings described here are specifically used to notify registrars of
       registry maintenance events and object mapping.

    4.1.  EPP Query Commands

       EPP [RFC5730] 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.

       This extension does not add any elements to EPP <check> and
       <transfer> commands or responses.

    4.1.1.  EPP <info> Command

       EPP provides the <info> command that is used to retrieve registry
       maintenance information.  In addition to the standard EPP command
       elements, the <info> command MUST contain a <maint:info> element that
       identifies the maintenance namespace.

       The <maint:info> element MUST contain a child element.  It is either
       the <maint:id> child element, described in Section 4.1.1.1, to query
       for a specific maintenance item or the <maint:list> child element,
       described in Section 4.1.1.2, to query all maintenance items.

    4.1.1.1.  Info Maintenance Item

       The information regarding a specific maintenance item can be
       retrieved by using the <info> command with the <maint:info> element
       and the <maint:id> child element, defined in Section 3.3.  If the
       maintenance identifier does not exist, the server MUST return an EPP
       error result code of 2303 ("Object does not exist") [RFC5730].

       The following is an example of retrieving a specific maintenance item
       in an <info> 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:    <info>
       C:      <maint:info
       C:        xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
       C:        <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id>
       C:      </maint:info>
       C:    </info>
       C:    <clTRID>ABC-12345</clTRID>
       C:  </command>
       C:</epp>

       When an <info> command has been processed successfully, the EPP
       <resData> element MUST contain a child <maint:infData> element that
       identifies the maintenance namespace.  The <maint:infData> element
       contains the <maint:item> element defined in Section 3.3.

       The following is an example of returning a specific maintenance item
       in an <info> response.

       S:<?xml version="1.0" encoding="UTF-8"?>
       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>
       S:        <maint:infData
       S:          xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
       S:          <maint:item>
       S:            <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6
       S:            </maint:id>
       S:            <maint:type lang="en">Routine Maintenance</maint:type>
       S:            <maint:systems>
       S:              <maint:system>
       S:                <maint:name>EPP</maint:name>
       S:                <maint:host>epp.registry.example
       S:                </maint:host>
       S:                <maint:impact>full</maint:impact>
       S:              </maint:system>
       S:            </maint:systems>
       S:            <maint:environment type="production"/>
       S:            <maint:start>2021-12-30T06:00:00Z</maint:start>
       S:            <maint:end>2021-12-30T07:00:00Z</maint:end>
       S:            <maint:reason>planned</maint:reason>
       S:            <maint:detail>
       S:              https://www.registry.example/notice?123
       S:            </maint:detail>
       S:            <maint:description lang="en">free-text
       S:            </maint:description>
       S:            <maint:description lang="de">Freitext
       S:            </maint:description>
       S:            <maint:tlds>
       S:              <maint:tld>example</maint:tld>
       S:              <maint:tld>test</maint:tld>
       S:            </maint:tlds>
       S:            <maint:intervention>
       S:              <maint:connection>false</maint:connection>
       S:              <maint:implementation>false</maint:implementation>
       S:            </maint:intervention>
       S:            <maint:crDate>2021-11-08T22:10:00Z</maint:crDate>
       S:          </maint:item>
       S:        </maint:infData>
       S:      </resData>
       S:      <trID>
       S:         <clTRID>ABC-12345</clTRID>
       S:         <svTRID>54321-XYZ</svTRID>
       S:      </trID>
       S:   </response>
       S:</epp>

    4.1.1.2.  Info Maintenance List

       The information for a list of maintenance items can be retrieved by
       using the <info> command with the <maint:info> element and the empty
       <maint:list> child element.  Server policy determines if completed
       maintenance events will be included in the list of maintenance items.

       The following is an example of retrieving the list of maintenance
       items in an <info> 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:    <info>
       C:      <maint:info
       C:        xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
       C:        <maint:list/>
       C:      </maint:info>
       C:    </info>
       C:    <clTRID>ABC-12345</clTRID>
       C:  </command>
       C:</epp>

       When an <info> command has been processed successfully, the EPP
       <resData> element MUST contain a child <maint:infData> element that
       identifies the maintenance namespace.  The <maint:infData> element
       contains the <maint:list> element with zero or more <maint:listItem>
       child elements.  The <maint:listItem> element contains the following
       child elements:

          <maint:id>
             The <maint:id> element defined in Section 3.3.

          <maint:start>
             The <maint:start> element defined in Section 3.3.

          <maint:end>
             The <maint:end> element defined in Section 3.3.

          <maint:crDate>
             The <maint:crDate> element defined in Section 3.3.

          <maint:upDate>
             The OPTIONAL <maint:upDate> element defined in Section 3.3.

       The following is an example of returning the list of maintenance
       items in an <info> response.

       S:<?xml version="1.0" encoding="UTF-8"?>
       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>
       S:        <maint:infData
       S:          xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
       S:          <maint:list>
       S:            <maint:listItem>
       S:              <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6
       S:              </maint:id>
       S:              <maint:start>2021-12-30T06:00:00Z</maint:start>
       S:              <maint:end>2021-12-30T07:00:00Z</maint:end>
       S:              <maint:crDate>2021-11-08T22:10:00Z</maint:crDate>
       S:            </maint:listItem>
       S:            <maint:listItem>
       S:              <maint:id>91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f
       S:              </maint:id>
       S:              <maint:start>2021-12-15T04:30:00Z</maint:start>
       S:              <maint:end>2021-12-15T05:30:00Z</maint:end>
       S:              <maint:crDate>2021-11-08T22:11:00Z</maint:crDate>
       S:              <maint:upDate>2021-11-17T15:00:00Z</maint:upDate>
       S:            </maint:listItem>
       S:          </maint:list>
       S:        </maint:infData>
       S:      </resData>
       S:      <trID>
       S:         <clTRID>ABC-12345</clTRID>
       S:         <svTRID>54321-XYZ</svTRID>
       S:      </trID>
       S:   </response>
       S:</epp>

    4.1.2.  EPP <poll> Command

       The EPP <poll> command and response are defined in Section 2.9.2.3 of
       [RFC5730].  The Registry Maintenance Notification is included in the
       EPP <poll> response in [RFC5730].

       There are five types of poll messages for the Registry Maintenance
       Notification, defined by the <maint:pollType> element in Section 3.3.
       A poll message might be generated when a maintenance event is
       created, updated, or deleted.  A courtesy poll message can be sent as
       a reminder of an upcoming maintenance event.  An end poll message can
       be sent when the maintenance event is completed.  In the case of a
       message specific to Registry Maintenance, a <maint:infData> element
       that identifies the maintenance namespace will be included within the
       <resData> element of the standard <poll> response.  The
       <maint:infData> element contains the <maint:item> element defined in
       Section 3.3.

       The following is an example of a <poll> 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:    <poll op="req"/>
       C:    <clTRID>ABC-12345</clTRID>
       C:  </command>
       C:</epp>

       Example <poll> 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="1301">
       S:      <msg>Command completed successfully; ack to dequeue</msg>
       S:    </result>
       S:  <msgQ count="1" id="12345">
       S:    <qDate>2021-11-08T22:10:00Z</qDate>
       S:    <msg lang="en">Registry Maintenance Notification</msg>
       S:  </msgQ>
       S:  <resData>
       S:    <maint:infData
       S:      xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
       S:      <maint:item>
       S:        <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id>
       S:        <maint:pollType>create</maint:pollType>
       S:        <maint:systems>
       S:          <maint:system>
       S:            <maint:name>EPP</maint:name>
       S:            <maint:host>epp.registry.example
       S:            </maint:host>
       S:            <maint:impact>full</maint:impact>
       S:          </maint:system>
       S:        </maint:systems>
       S:        <maint:environment type="production"/>
       S:        <maint:start>2021-12-30T06:00:00Z</maint:start>
       S:        <maint:end>2021-12-30T07:00:00Z</maint:end>
       S:        <maint:reason>planned</maint:reason>
       S:        <maint:detail>
       S:          https://www.registry.example/notice?123
       S:        </maint:detail>
       S:        <maint:tlds>
       S:          <maint:tld>example</maint:tld>
       S:          <maint:tld>test</maint:tld>
       S:        </maint:tlds>
       S:        <maint:intervention>
       S:          <maint:connection>false</maint:connection>
       S:          <maint:implementation>false</maint:implementation>
       S:        </maint:intervention>
       S:        <maint:crDate>2021-11-08T22:10:00Z</maint:crDate>
       S:      </maint:item>
       S:    </maint:infData>
       S:  </resData>
       S:  <trID>
       S:    <clTRID>ABC-12345</clTRID>
       S:    <svTRID>54321-XYZ</svTRID>
       S:  </trID>
       S:  </response>
       S:</epp>

    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.

       This extension does not add any elements to the EPP <create>,
       <delete>, <renew>, <transfer>, and <update> commands.

    5.  Formal Syntax

       The EPP Registry Maintenance Notification schema is presented here.

       The formal syntax is a complete schema representation of the object
       mapping suitable for automated validation of EPP XML instances.  The
       <CODE BEGINS> and <CODE ENDS> tags are not part of the schema; they
       are used to note the beginning and end of the schema for URI
       registration purposes.

    5.1.  Registry Maintenance Notification EPP Mapping Schema

       <CODE BEGINS>
       <?xml version="1.0" encoding="UTF-8"?>
         <schema targetNamespace="urn:ietf:params:xml:ns:epp:
           maintenance-1.0"
           xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
           xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
           xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"
           xmlns="https://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified">
         <!--
         Import common element types
         -->
         <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
         <import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
         <annotation>
           <documentation>
             Extensible Provisioning Protocol v1.0
             Registry Maintenance Notification Mapping Schema.
           </documentation>
         </annotation>
         <!--
         Child elements found in EPP commands.
         -->
         <element name="info" type="maint:infoType"/>
         <!--
          Child elements of the <info> command.
         -->
         <complexType name="infoType">
           <sequence>
             <choice>
               <element name="list"/>
               <element name="id" type="maint:idType"/>
             </choice>
           </sequence>
         </complexType>
         <!--
         Human-readable text may describe the maintenance
         -->
         <complexType name="idType">
           <simpleContent>
             <extension base="token">
               <attribute name="name" type="token"/>
               <attribute name="lang" type="language" default="en"/>
             </extension>
           </simpleContent>
         </complexType>
         <!--
          Info Response element
         -->
         <element name="infData" type="maint:infDataType"/>
         <!--
          <info> response elements.
         -->
         <complexType name="infDataType">
           <choice>
             <element name="list" type="maint:listDataType"/>
             <element name="item" type="maint:maintDataType"/>
           </choice>
         </complexType>
         <!--
          Attributes associated with the list info response
         -->
         <complexType name="listDataType">
           <sequence>
             <element name="listItem" type="maint:maintItemType"
              minOccurs="0" maxOccurs="unbounded"/>
           </sequence>
         </complexType>
         <!--
          Attributes associated with the list item info response
         -->
         <complexType name="maintItemType">
           <sequence>
             <element name="id" type="maint:idType"/>
             <element name="start" type="dateTime"/>
             <element name="end" type="dateTime"/>
             <element name="crDate" type="dateTime"/>
             <element name="upDate" type="dateTime" minOccurs="0"/>
           </sequence>
         </complexType>
         <!--
          Attributes associated with the maintenance info response
         -->
         <complexType name="maintDataType">
           <sequence>
             <element name="id" type="maint:idType"/>
             <element name="type" type="maint:typeType" minOccurs="0"
              maxOccurs="unbounded"/>
             <element name="pollType" type="maint:pollType" minOccurs="0"/>
             <element name="systems" type="maint:systemsType"/>
             <element name="environment" type="maint:envType"/>
             <element name="start" type="dateTime"/>
             <element name="end" type="dateTime"/>
             <element name="reason" type="maint:reasonEnum"/>
             <element name="detail" type="anyURI" minOccurs="0"/>
             <element name="description" type="maint:descriptionType"
              minOccurs="0" maxOccurs="unbounded"/>
             <element name="tlds" type="maint:tldsType" minOccurs="0"/>
             <element name="intervention" type="maint:interventionType"
              minOccurs="0"/>
             <element name="crDate" type="dateTime"/>
             <element name="upDate" type="dateTime" minOccurs="0"/>
           </sequence>
         </complexType>
         <!--
          systems element
         -->
         <complexType name="systemsType">
           <sequence>
             <element name="system" type="maint:systemType"
              maxOccurs="unbounded"/>
           </sequence>
         </complexType>
         <!--
          Enumerated list of poll types
         -->
         <simpleType name="pollType">
           <restriction base="token">
             <enumeration value="create"/>
             <enumeration value="update"/>
             <enumeration value="delete"/>
             <enumeration value="courtesy"/>
             <enumeration value="end"/>
           </restriction>
         </simpleType>
         <!--
          Enumerated list of impacts
         -->
         <simpleType name="impactEnum">
           <restriction base="token">
             <enumeration value="none"/>
             <enumeration value="partial"/>
             <enumeration value="full"/>
           </restriction>
         </simpleType>
         <!--
          description element
         -->
         <complexType name="descriptionType">
           <simpleContent>
             <extension base="string">
               <attribute name="lang" type="language" default="en"/>
               <attribute name="type" type="maint:descEnum" default="plain"
               />
             </extension>
           </simpleContent>
         </complexType>
         <!--
          Enumerated list of description mime types
         -->
         <simpleType name="descEnum">
           <restriction base="token">
             <enumeration value="plain"/>
             <enumeration value="html"/>
           </restriction>
         </simpleType>
         <!--
          type element
         -->
         <complexType name="typeType">
           <simpleContent>
             <extension base="string">
               <attribute name="lang" type="language" default="en"/>
             </extension>
           </simpleContent>
         </complexType>
         <!--
          system element
         -->
         <complexType name="systemType">
           <sequence>
             <element name="name" type="token"/>
             <element name="host" type="eppcom:labelType" minOccurs="0"/>
             <element name="impact" type="maint:impactEnum"/>
           </sequence>
         </complexType>
         <!--
          Enumerated list of environments
         -->
         <simpleType name="envEnum">
           <restriction base="token">
             <enumeration value="production"/>
             <enumeration value="ote"/>
             <enumeration value="staging"/>
             <enumeration value="dev"/>
             <enumeration value="custom"/>
           </restriction>
         </simpleType>
         <!--
          environment element
         -->
         <complexType name="envType">
           <simpleContent>
             <extension base="token">
               <attribute name="type" type="maint:envEnum" use="required"/>
               <attribute name="name" type="token" use="optional"/>
             </extension>
           </simpleContent>
         </complexType>
         <!--
          Enumerated list of reasons
         -->
         <simpleType name="reasonEnum">
           <restriction base="token">
             <enumeration value="planned"/>
             <enumeration value="emergency"/>
           </restriction>
         </simpleType>
         <!--
          tlds element
         -->
         <complexType name="tldsType">
           <sequence>
             <element name="tld" type="eppcom:labelType"
              maxOccurs="unbounded"/>
           </sequence>
         </complexType>
         <!--
          intervention element
         -->
         <complexType name="interventionType">
           <sequence>
             <element name="connection" type="boolean"/>
             <element name="implementation" type="boolean"/>
           </sequence>
         </complexType>
         <!--
          End of schema.
         -->
         </schema>
       <CODE ENDS>

    6.  IANA Considerations

    6.1.  XML Namespace

       This document uses URNs to describe XML namespaces and XML schemas
       conforming to a registry mechanism defined in [RFC3688].

       The following entry has been registered as an XML namespace:

       URI:  urn:ietf:params:xml:ns:epp:maintenance-1.0
       Registrant Contact:  IESG
       XML:  None.  Namespace URIs do not represent an XML specification.

       The following entry has been registered to the XML maintenance
       schema:

       URI:  urn:ietf:params:xml:schema:epp:maintenance-1.0
       Registrant Contact:  IESG
       XML:  See the "Formal Syntax" section of this document.

    6.2.  EPP Extension Registry

       The following entry has been added to the "Extensions for the
       Extensible Provisioning Protocol (EPP)" registry, described in
       [RFC7451]:

       Name of Extension:  Registry Maintenance Notification for the
          Extensible Provisioning Protocol (EPP)
       Document status:  Standards Track
       Reference:  RFC 9167
       Registrant Name and Email Address:  IESG <iesg@ietf.org>
       TLDs:  Any
       IPR Disclosure:  None
       Status:  Active
       Notes:  None

    7.  Security Considerations

       The security considerations of [RFC5730] apply in this document.
       Additionally, a server MUST only provide maintenance information to
       clients that are authorized.  Suppose a client queries a maintenance
       identifier that it is not authorized to access per Section 4.1.1.1,
       "Info Maintenance Item".  In that case, the server SHOULD return an
       EPP error result code of 2201 ("Authorization error") or 2303
       ("Object does not exist") [RFC5730].  The list of top-level domains
       or registry zones returned in the "Info Maintenance Item" response
       SHOULD be filtered based on the top-level domains or registry zones
       for which the client is authorized.  Authorization of poll messages
       is done at the time of poll message insertion and not at the time of
       poll message consumption.

    8.  References

    8.1.  Normative References

       [HTML5]    WHATWG, "HTML - Living Standard", December 2021,
                  <https://html.spec.whatwg.org/multipage/>.

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119,
                  DOI 10.17487/RFC2119, March 1997,
                  <https://www.rfc-editor.org/info/rfc2119>.

       [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                  Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
                  <https://www.rfc-editor.org/info/rfc3339>.

       [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                  Resource Identifier (URI): Generic Syntax", STD 66,
                  RFC 3986, DOI 10.17487/RFC3986, January 2005,
                  <https://www.rfc-editor.org/info/rfc3986>.

       [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
                  Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
                  September 2009, <https://www.rfc-editor.org/info/rfc5646>.

       [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
                  STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
                  <https://www.rfc-editor.org/info/rfc5730>.

       [RFC5891]  Klensin, J., "Internationalized Domain Names in
                  Applications (IDNA): Protocol", RFC 5891,
                  DOI 10.17487/RFC5891, August 2010,
                  <https://www.rfc-editor.org/info/rfc5891>.

       [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                  May 2017, <https://www.rfc-editor.org/info/rfc8174>.

       [RFC9038]  Gould, J. and M. Casanova, "Extensible Provisioning
                  Protocol (EPP) Unhandled Namespaces", RFC 9038,
                  DOI 10.17487/RFC9038, May 2021,
                  <https://www.rfc-editor.org/info/rfc9038>.

       [W3C.REC-xml-20081126]
                  Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
                  F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
                  Edition)", World Wide Web Consortium Recommendation REC-
                  xml-20081126, November 2008,
                  <https://www.w3.org/TR/2008/REC-xml-20081126>.

    8.2.  Informative References

       [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
                  DOI 10.17487/RFC3688, January 2004,
                  <https://www.rfc-editor.org/info/rfc3688>.

       [RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
                  Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
                  February 2015, <https://www.rfc-editor.org/info/rfc7451>.

    Acknowledgments

       The authors wish to thank the following persons for their feedback
       and suggestions: James Gould, Michael Bauland, Patrick Mevzek, Quoc-
       Anh Pham, Raymond Zylstra, Christopher Martens, Anthony Eden, Neal
       McPherson, Craig Marchant, and Andreas Huber.

    Authors' Addresses

       Tobias Sattler

       Email: mail@tobiassattler.com
       URI:   https://tobiassattler.com

       Roger Carney
       GoDaddy Inc.
       2155 E GoDaddy Way
       Tempe, AZ 85284
       United States of America

       Email: rcarney@godaddy.com
       URI:   https://www.godaddy.com

       Jody Kolker
       GoDaddy Inc.
       2155 E GoDaddy Way
       Tempe, AZ 85284
       United States of America

       Email: jkolker@godaddy.com
       URI:   https://www.godaddy.com