Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)mail@tobiassattler.comhttps://tobiassattler.comGoDaddy Inc.2155 E GoDaddy WayTempeAZ85284United States of Americarcarney@godaddy.comhttps://www.godaddy.comGoDaddy Inc.2155 E GoDaddy WayTempeAZ85284United States of Americajkolker@godaddy.comhttps://www.godaddy.com
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
.
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
() 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
Introduction
The Extensible Provisioning Protocol (EPP), as defined in ,
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.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
when, and only when, they appear in all capitals, as shown here.
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.
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.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 .Object AttributesInternationalized Domain Names
Names of affected hosts MUST be provided in A-label form, according
to .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 , with time-offset="Z",
MUST be used.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 , 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 .
<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 .
<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
, 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 .
<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.
EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found in the
EPP core protocol specification . The command mappings described here are specifically
used to notify registrars of registry maintenance events and object
mapping.EPP Query Commands
EPP provides three commands to
retrieve object information: <check> to determine if an object is
known to the server, <info> to retrieve detailed information
associated with an object, and <transfer> to retrieve object transfer
status information. This extension does not add any elements to EPP
<check> and <transfer> commands or responses.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
, to query for a specific
maintenance item or the <maint:list> child element, described in
, to query all maintenance
items.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 . If the maintenance identifier does not exist, the
server MUST return an EPP error result code of 2303 ("Object
does not exist") . 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 .
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>
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 .
<maint:start>
The <maint:start> element defined in .
<maint:end>
The <maint:end> element defined in .
<maint:crDate>
The <maint:crDate> element defined in .
<maint:upDate>
The OPTIONAL <maint:upDate> element defined in .
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>
EPP <poll> Command
The EPP <poll> command and response are defined in . The Registry Maintenance Notification is included in
the EPP <poll> response in .
There are five types of poll messages for the Registry Maintenance
Notification, defined by the <maint:pollType> element in . 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 . 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>
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.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.Registry Maintenance Notification EPP Mapping Schema
<?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>
IANA ConsiderationsXML Namespace
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism defined in .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.
EPP Extension Registry
The following entry has been added to the "Extensions for the Extensible Provisioning Protocol (EPP)" registry, described
in :
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
Security Considerations
The security considerations of
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 , "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") . 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.ReferencesNormative ReferencesHTML - Living StandardWHATWGKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Date and Time on the Internet: TimestampsThis document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]Tags for Identifying LanguagesThis document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Extensible Provisioning Protocol (EPP)This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]Internationalized Domain Names in Applications (IDNA): ProtocolThis document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Extensible Provisioning Protocol (EPP) Unhandled NamespacesThe Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in RFC 5730.Extensible Markup Language (XML) 1.0 (Fifth Edition)World Wide Web Consortium Recommendation REC-xml-20081126Informative ReferencesThe IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Extension Registry for the Extensible Provisioning ProtocolThe Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.Acknowledgments
The authors wish to thank the following persons for their feedback
and suggestions: , , ,
, , , ,
, , and .Authors' Addressesmail@tobiassattler.comhttps://tobiassattler.comGoDaddy Inc.2155 E GoDaddy WayTempeAZ85284United States of Americarcarney@godaddy.comhttps://www.godaddy.comGoDaddy Inc.2155 E GoDaddy WayTempeAZ85284United States of Americajkolker@godaddy.comhttps://www.godaddy.com