RFC 9167

Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)

📅 published December 2021, from ietf

Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) 🎀

Okay bestie, this one is from the IETF (the crew that writes the Internet's rulebook 📜). It's RFC 9167, a Standards Track document, so it's an official, real-deal spec and not just a vibe. The authors are T. Sattler, R. Carney, and J. Kolker, all from GoDaddy Inc., and it was published in December 2021. The ISSN is 2070-1721. The header doesn't list any RFCs that it obsoletes or updates, so it's not replacing or patching anything else. Iconic! 💅

Abstract ✨

This doc describes an EPP extension called "Registry Maintenance Notification" 🔔. EPP servers use it to notify EPP clients about maintenance events, and clients can also ask servers about those events. It's giving info-sharing realness 🫶

Status of This Memo

This is an Internet Standards Track document 🌈

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, which means everyone agreed on it 🙌 It also got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9167 🔗

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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📄 Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 💜

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 ✨

EPP, as defined in [RFC5730], is a protocol that started out with a big goal 🎯 It was meant to be a standard Internet domain name registration protocol that registries and registrars could both use to talk to each other 💖

Registries are always updating their systems so things run smoother, they can launch new services, or they can move their protocols to the latest standards 🚀 These updates get pushed out to different registry environments during windows that get communicated to registrars as "maintenance events." Sometimes a maintenance event means services go down for a little while during the upgrade 😭 The tricky part is that registries usually tell registrars about these events in their own formats, and none of those formats are standardized across registries 🙈

The DNS namespace keeps expanding, so registrars have to deal with even more registries. That means even more maintenance events and even more formats. Honestly, it's giving "we need a better way" energy, so an efficient approach to notifying registrars is seriously needed 💅

This document describes an extension mapping for version 1.0 of EPP. It gives EPP servers a way to notify EPP clients about upcoming maintenance events, and it lets EPP clients query EPP servers about those events too 🔔

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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in all capitals, just like shown here 🔠 Lowercase versions are just regular words, so no stress 💜

XML [W3C.REC-xml-20081126] is case sensitive. Unless it says otherwise, XML specs and examples in this document MUST be read with the character case shown, so you can build a conforming implementation 🎀 Be precise, bestie 😤

The XML namespace prefix "maint" is used for the namespace "urn:ietf:params:xml:ns:epp:maintenance-1.0". Implementations MUST NOT depend on that prefix, though. Instead, they should use a proper namespace-aware XML parser and serializer to read and write the XML documents 🧠

"ote" is short for "Operational Test and Evaluation" 🧪

In examples, C: marks lines sent by a protocol client, and S: marks lines returned by a protocol server 💬 Indentation and whitespace in examples are just there to show how the elements relate to each other. They're not a required feature of this protocol 🌸

2. Migrating to Newer Versions of This Extension 🦋

Servers that implement this extension SHOULD give clients a way to update their implementations step by step whenever a new version of the extension gets deployed 🪜 A newer version is expected to use an XML namespace with a higher version number than the older ones 🔢

Servers SHOULD (for a temporary migration period, up to server policy) keep supporting older versions of the extension alongside the newest one 🤝 They should also let clients run their preferred version of the <info> command, based on the maintenance <objURI> elements in the server <greeting> 💅 The version of the maintenance <info> response MUST match the version of the maintenance <info> command that the server ran 🎯

Servers MUST return a Registry Maintenance Notification poll message that matches the newest negotiated version of the maintenance extension. That negotiation is based on the overlap between the maintenance <objURI> elements in the server <greeting> and in the client <login> command ✨ If that overlap comes out as an empty set, the server MUST return the newest version of the Registry Maintenance Notification poll message it supports, based on "Usage with Poll-Message EPP Responses" in Section 6 of [RFC9038] 🫶 No empty-set drama allowed!

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] MUST be used, with time-offset="Z" 💖

3.3. Maintenance Elements

okay bestie, this section is all about the <maint:item> element 🎀 It describes ONE registry maintenance event during a specific period ✨ You'll see it in a maintenance item EPP <info> command and response, and also in a <poll> response 💌

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

<maint:id> This is the server-unique identifier for the maintenance event 🔑 It comes with an OPTIONAL "name" attribute that holds a human-readable name for 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 🍓 The possible values are set by server policy, like "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 is 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" value is a reminder of an event, and the "end" value is a notification of the end of the event, without updating the maintenance object, and it 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> This element contains the following child elements 🌷

  • <maint:name> The name of the affected system, like "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 📊 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". Main character energy for sure 👑

<maint:environment> This is the type of the affected system 🏷️ The "type" attribute is REQUIRED and MUST be "production", "ote", "staging", "dev", or "custom". For extensibility, the element includes the OPTIONAL "name" attribute, which can define the name of the custom environment when the "type" attribute has the "custom" value 🎀 For example, for the custom "marketing" environment, the 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. No time travel allowed 🙅‍♀️

<maint:reason> The reason behind the maintenance event 🧐 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 📝 They're usable without creating and traversing an external resource, like the one from <maint:detail> 🦋 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 <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 it 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 it 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. Fresh and untouched, iconic 🍼

4. EPP Command Mapping

okay so, the full EPP syntax and semantics live in the EPP core protocol specification [RFC5730] 📚 The command mappings in this part are specifically used to notify registrars of registry maintenance events and object mapping 🦋

4.1. EPP Query Commands

EPP [RFC5730] gives you three commands to retrieve object information 🧚 There's <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. Nothing new there, no cap 🫶

4.1.1. EPP <info> Command

EPP provides the <info> command, which 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's 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 about 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] 💀

Here's 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 ✨

Here's 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

Want the whole list of maintenance items? 🌸 Just send an <info> command with the <maint:info> element and an empty <maint:list/> child. The server's policy decides whether finished maintenance events show up in the list too 👀

Here's what that request looks like 💅

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>

Once an <info> command succeeds, the <resData> element MUST contain a child <maint:infData> element that names the maintenance namespace 🎀 That <maint:infData> holds a <maint:list> with zero or more <maint:listItem> children. Each <maint:listItem> has these child elements:

  • <maint:id>: the <maint:id> element from Section 3.3.
  • <maint:start>: the <maint:start> element from Section 3.3.
  • <maint:end>: the <maint:end> element from Section 3.3.
  • <maint:crDate>: the <maint:crDate> element from Section 3.3.
  • <maint:upDate>: the OPTIONAL <maint:upDate> element from Section 3.3. 🫶

Here's a response with the list ✨

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 its response are defined in Section 2.9.2.3 of [RFC5730] 📬 The Registry Maintenance Notification rides along in the EPP <poll> response described in [RFC5730], so it's all one vibe 🦋

There are five poll message types for the Registry Maintenance Notification, set by the <maint:pollType> element in Section 3.3 🌈 A poll message might show up when a maintenance event gets created, updated, or deleted. A courtesy poll message is a friendly reminder about an upcoming maintenance event 🧚 An end poll message lets you know the maintenance event is done. For a Registry Maintenance message, a <maint:infData> element that names the maintenance namespace goes inside the <resData> element of the standard <poll> response. That <maint:infData> element holds the <maint:item> element from Section 3.3 💜

Here's 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>

And here's an 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 gives you five transform commands to play with objects 🎀 <create> makes a new instance of an object, <delete> removes an instance, <renew> extends an object's validity period, <transfer> handles sponsorship changes, and <update> changes the info attached to an object 💅

This extension doesn't add any elements to the EPP <create>, <delete>, <renew>, <transfer>, or <update> commands 🙈 Nothing new to learn there, bestie ✨

5. Formal Syntax

Here's the EPP Registry Maintenance Notification schema 🔥

The formal syntax is a complete schema representation of the object mapping, so automated validation of EPP XML instances can use it 🧚 The <CODE BEGINS> and <CODE ENDS> tags are not part of the schema. They just mark where the schema starts and ends for URI registration purposes 🌸

5.1. Registry Maintenance Notification EPP Mapping Schema 🎀

Okay bestie, here's the schema itself. It's long, so scroll with intention 🫶

   <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

Okay so this doc uses URNs to describe XML namespaces and XML schemas that follow a registry mechanism defined in [RFC3688]. Very organized of them 💜

Here's the namespace entry that got registered:

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

And this entry got 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 extension got its own spot in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry from [RFC7451], and it's giving main character energy 🦋

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 🔐

Okay this part is SERIOUS bestie, so listen up 😭

The security considerations of [RFC5730] apply in this document too. On top of that, a server MUST only provide maintenance information to clients that are authorized. Like, no exceptions 🙅‍♀️

Suppose a client asks about a maintenance identifier it isn't 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 down to the ones the client is actually authorized for. Filter it, babe 💅

Last bit: authorization of poll messages happens when the poll message gets inserted, not when it gets consumed. Keep that timing straight and you're golden ✨

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgments

Okay bestie, the authors wanted to give a shoutout to their squad for feedback and suggestions 🫶 Thank you James Gould, Michael Bauland, Patrick Mevzek, Quoc-Anh Pham, Raymond Zylstra, Christopher Martens, Anthony Eden, Neal McPherson, Craig Marchant, and Andreas Huber 💖 Literally the real MVPs 👑

Authors' Addresses

Okay so here are the authors and how to reach them ✨

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

📦 where this page comes from