(I'm sending this again with some of the text re0writeen in the form of possible requirements for an RDDS) The EPP RFCs make no assumptions about the existence of an RDDS. They do, however, describe the syntax of data elements that are included when objects are registered, which may be related to our "What data should be collected, stored, and disclosed?" charter question - especially the "collected" part. So, I'm going to approach my review from the perspective of describing data elements that might be collected for RDDS publication purposes. There are some cases where data elements are repeated across EPP commands or sections of text; I will only identify the first use in each document. RFC 5730: Extensible Provisioning Protocol (EPP) https://tools.ietf.org/html/rfc5730 RFC 5730 is the EPP framework specification. It describes a method for the publication of data collection and disclosure policies in Section 2.4. Possible requirement: RDDS and EPP data collection and disclosure policies must be consistent. RFC 5731: Extensible Provisioning Protocol (EPP) Domain Name Mapping https://tools.ietf.org/html/rfc5731 Section 2.1 describes the syntax of domain names. Section 2.2 describes the syntax of contact and client identifiers. Section 2.3 describes domain status values. Section 2.4 describes the syntax of date-time values. Section 3.2.1, EPP <create> Command This text describes a mandatory domain name element. It also describes optional registration period, name server, registrant identifier, and contact identifier elements. Section 3.2.3, EPP <renew> Command This text describes an expiration date element. Possible requirement: An RDDS must conform to the data element syntax specifications for domain names, EPP contact and client identifiers, EPP domain status values, and date-time values as specified in RFC 5731. RFC 5732: Extensible Provisioning Protocol (EPP) Host Mapping https://tools.ietf.org/html/rfc5732 Section 2.1 describes the syntax of host (name servers in this context) names. Section 2.2 describes the syntax of client identifiers. Section 2.3 describes host status values. Section 2.4 describes the syntax of date-time values. Section 2.5 describes the syntax of IPv4 and IPv6 addresses. Possible requirement: An RDDS must conform to the data element syntax specifications for host (name server) names, EPP client identifiers, EPP host status values, date-time values, and IPv4 and IPv6 addresses as specified in RFC 5732. RFC 5733: Extensible Provisioning Protocol (EPP) Contact Mapping https://tools.ietf.org/html/rfc5733 Section 2.1 describes the syntax of contact and client identifiers. Section 2.2 describes contact status values. Section 2.3 describes the syntax of individual and organizational names. Section 2.4 describes the syntax of postal addresses. Section 2.5 describes the syntax of telephone numbers. Section 2.6 describes the syntax of email addresses. Section 2.7 describes the syntax of date-time values. Section 2.9 describes requires for server disclosure of data collection policies (see above). Section 3.2.1, EPP <create> Command This text describes contact name elements. It also describes the ability to specify localized forms of address information that can be represented using non-ASCII characters. Possible requirement: An RDDS must conform to the data element syntax specifications for EPP contact and client identifiers, EPP contact status values, EPP individual and organizational names, EPP postal addresses, telephone numbers, email addresses, and date-time values as specified in RFC 5733. Possible requirement: An RDDS must have the ability to collect, store, and represent internationalized and localized forms of address information that can be represented using both ASCII and non-ASCII characters. Scott