diff options
Diffstat (limited to 'doc/rfc/rfc9167.txt')
| -rw-r--r-- | doc/rfc/rfc9167.txt | 981 |
1 files changed, 981 insertions, 0 deletions
diff --git a/doc/rfc/rfc9167.txt b/doc/rfc/rfc9167.txt new file mode 100644 index 0000000..96e57ec --- /dev/null +++ b/doc/rfc/rfc9167.txt @@ -0,0 +1,981 @@ + + + + +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 |