rfc9873v1.txt | rfc9873.txt | |||
---|---|---|---|---|
skipping to change at line 15 ¶ | skipping to change at line 15 ¶ | |||
ISSN: 2070-1721 VeriSign, Inc. | ISSN: 2070-1721 VeriSign, Inc. | |||
S. Hollenbeck | S. Hollenbeck | |||
Verisign Labs | Verisign Labs | |||
September 2025 | September 2025 | |||
Additional Email Address Extension for the Extensible Provisioning | Additional Email Address Extension for the Extensible Provisioning | |||
Protocol (EPP) | Protocol (EPP) | |||
Abstract | Abstract | |||
The Extensible Provisioning Protocol (EPP) does not natively support | The Extensible Provisioning Protocol (EPP) does not inherently | |||
internationalized email addresses because the specifications for | support internationalized email addresses because the specifications | |||
these addresses did not exist when EPP was developed. This document | for these addresses did not exist when EPP was developed. This | |||
describes a command-response extension that adds support for | document describes a command-response extension that adds support for | |||
associating an additional email address with an EPP contact object. | associating an additional email address with an EPP contact object. | |||
That additional email address can be either an internationalized | That additional email address can be either an internationalized | |||
email address or an all-ASCII address. | email address or an ASCII-only address. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
skipping to change at line 111 ¶ | skipping to change at line 111 ¶ | |||
delivery issues. | delivery issues. | |||
While this extension adds support for an additional email address to | While this extension adds support for an additional email address to | |||
contact objects, and that additional email address can be an SMTPUTF8 | contact objects, and that additional email address can be an SMTPUTF8 | |||
address, it does not in any way update or change any other EPP | address, it does not in any way update or change any other EPP | |||
extension that includes an email address. Adding support for | extension that includes an email address. Adding support for | |||
SMTPUTF8 addresses to those extensions will require an update to the | SMTPUTF8 addresses to those extensions will require an update to the | |||
relevant extension specifications. In cases where a contact object | relevant extension specifications. In cases where a contact object | |||
contains two email addresses, all users of these addresses should be | contains two email addresses, all users of these addresses should be | |||
aware that either address may be forwarded to the other. This | aware that either address may be forwarded to the other. This | |||
implies that a message sent to an all-ASCII address may receive a | implies that a message sent to an ASCII-only address may receive a | |||
reply from an SMTPUTF8 address or vice versa. | reply from an SMTPUTF8 address or vice versa. | |||
1.1. Conventions Used in This Document | 1.1. Conventions Used in This Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
skipping to change at line 134 ¶ | skipping to change at line 134 ¶ | |||
character case presented in order to develop a conforming | character case presented in order to develop a conforming | |||
implementation. | implementation. | |||
In examples, "C:" represents lines sent by a protocol client, and | In examples, "C:" represents lines sent by a protocol client, and | |||
"S:" represents lines returned by a protocol server. Indentation and | "S:" represents lines returned by a protocol server. Indentation and | |||
white space in the examples are provided only to illustrate element | white space in the examples are provided only to illustrate element | |||
relationships and are not REQUIRED in the protocol. | relationships and are not REQUIRED in the protocol. | |||
The XML namespace prefix "addlEmail" is used for the namespace | The XML namespace prefix "addlEmail" is used for the namespace | |||
"urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST | "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST | |||
NOT depend on it and instead employ a proper namespace-aware XML | NOT depend on it and instead MUST employ a proper namespace-aware XML | |||
parser and serializer to interpret and output the XML documents. | parser and serializer to interpret and output the XML documents. | |||
2. Email Address Specification | 2. Email Address Specification | |||
The EPP contact object mapping [RFC5733] normatively references | The EPP contact object mapping [RFC5733] normatively references | |||
[RFC5322] as the specification for email address syntax. That | [RFC5322] as the specification for email address syntax. That | |||
specification does not include support for internationalized email | specification does not include support for internationalized email | |||
addresses. [RFC6530] provides an overview and describes the | addresses. [RFC6530] provides an overview and describes the | |||
framework for internationalized email. SMTPUTF8 email address syntax | framework for internationalized email. SMTPUTF8 email address syntax | |||
is described in Section 3.3 of [RFC6531]. [RFC6531] extends the | is described in Section 3.3 of [RFC6531]. [RFC6531] extends the | |||
Mailbox, Local-part, and Domain ABNF rules in [RFC5321] to support | Mailbox, Local-part, and Domain ABNF rules in [RFC5321] to support | |||
"UTF8-non-ascii" (defined in Section 3.1 of [RFC6532]) for the local- | "UTF8-non-ascii" (defined in Section 3.1 of [RFC6532]) for the local- | |||
part and to support U-label (defined in Section 2.3.2.1 of [RFC5890]) | part and to support U-label (defined in Section 2.3.2.1 of [RFC5890]) | |||
for the domain. The validation rules described in [RFC6531] MUST be | for the domain. The validation rules described in [RFC6531] MUST be | |||
followed when processing internationalized email addresses associated | followed when processing internationalized email addresses associated | |||
with this extension. | with this extension. | |||
3. Additional Email Address Element | 3. Additional Email Address Element | |||
A second email address can be set using the <addlEmail:addlEmail> | A second email address can be set using the <addlEmail:addlEmail> | |||
element with the command and response extensions defined in | element with the command-response extensions defined in Section 5. | |||
Section 5. The <addlEmail:addlEmail> element contains the following | The <addlEmail:addlEmail> element contains the following child | |||
child element: | element: | |||
<addlEmail:email>: An element following the syntax in Section 2 for | <addlEmail:email>: An element following the syntax in Section 2 for | |||
defining a second ASCII or SMTPUTF8 address. An empty | defining a second ASCII or SMTPUTF8 address. An empty | |||
<addlEmail:email/> element unsets the second email address in the | <addlEmail:email/> element unsets the second email address in the | |||
Update Command (Section 5.2.5) and indicates the second email is | Update Command (Section 5.2.5) and indicates the second email is | |||
not set in the Info Response (Section 5.1.2). The | not set in the Info Response (Section 5.1.2). The | |||
<addlEmail:email> element contains an OPTIONAL "primary" | <addlEmail:email> element contains an OPTIONAL "primary" | |||
attribute that can be used to indicate that the extension email | attribute that can be used to indicate that the extension email | |||
address should be treated as the primary email address for the | address should be treated as the primary email address for the | |||
extended contact object. The "primary" attribute MUST NOT be | extended contact object. The "primary" attribute MUST NOT be | |||
skipping to change at line 179 ¶ | skipping to change at line 179 ¶ | |||
Additional email address considerations: | Additional email address considerations: | |||
* The value set for the <contact:disclose><contact:email/> "flag" | * The value set for the <contact:disclose><contact:email/> "flag" | |||
attribute (described in Section 2.9 of [RFC5733]) MUST also be | attribute (described in Section 2.9 of [RFC5733]) MUST also be | |||
applied to all additional email addresses that are added by a | applied to all additional email addresses that are added by a | |||
contact extension. | contact extension. | |||
* Any address included in an extension is intended to be an | * Any address included in an extension is intended to be an | |||
additional address that is associated only with the primary | additional address that is associated only with the primary | |||
<contact:email> address, and that support for any other additional | <contact:email> address, and support for any other additional | |||
email addresses MUST explicitly describe how the additional | email addresses MUST explicitly describe how the additional | |||
addresses are associated with the existing addresses. | addresses are associated with the existing addresses. | |||
4. Extension Considerations | 4. Extension Considerations | |||
4.1. Signaling Client and Server Support | 4.1. Signaling Client and Server Support | |||
As described in Section 2.4 of [RFC5730], the client and the server | As described in Section 2.4 of [RFC5730], the client and the server | |||
can signal support for the extension using a namespace URI in the | can signal support for the extension using a namespace URI in the | |||
login and greeting extension services, respectively. The namespace | login and greeting extension services, respectively. The namespace | |||
skipping to change at line 216 ¶ | skipping to change at line 216 ¶ | |||
The server MUST satisfy the following obligations when support for | The server MUST satisfy the following obligations when support for | |||
this extension has been negotiated: | this extension has been negotiated: | |||
* Accept SMTPUTF8-compliant addresses for the extended contact | * Accept SMTPUTF8-compliant addresses for the extended contact | |||
object in the EPP session. | object in the EPP session. | |||
* Support email address validation based on the SMTPUTF8 validation | * Support email address validation based on the SMTPUTF8 validation | |||
rules defined in Section 2. | rules defined in Section 2. | |||
* Storage of email properties that support internationalized | * Store email properties that support internationalized characters. | |||
characters. | ||||
* Return SMTPUTF8-compliant addresses for the extended contact | * Return SMTPUTF8-compliant addresses for the extended contact | |||
object in EPP responses. | object in EPP responses. | |||
* Support the SMTP extension for internationalized email described | * Support the SMTP extension for internationalized email described | |||
in [RFC6531] when sending or receiving email. | in [RFC6531] when sending or receiving email. | |||
The client MUST satisfy the following obligations when support for | The client MUST satisfy the following obligations when support for | |||
this extension has been negotiated: | this extension has been negotiated: | |||
skipping to change at line 270 ¶ | skipping to change at line 269 ¶ | |||
5.1.2. EPP <info> Command | 5.1.2. EPP <info> Command | |||
This extension does not add any elements to the EPP <info> command | This extension does not add any elements to the EPP <info> command | |||
response described in [RFC5730]. | response described in [RFC5730]. | |||
If the query is successful, the server replies with an | If the query is successful, the server replies with an | |||
<addlEmail:addlEmail> element (Section 3) along with the regular EPP | <addlEmail:addlEmail> element (Section 3) along with the regular EPP | |||
<resData>. | <resData>. | |||
The following is an example <info> contact response using the | ||||
<addlEmail:addlEmail> extension with no alternate email address: | ||||
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
S: <response> | S: <response> | |||
S: <result code="1000"> | S: <result code="1000"> | |||
S: <msg>Command completed successfully</msg> | S: <msg>Command completed successfully</msg> | |||
S: </result> | S: </result> | |||
S: <resData> | S: <resData> | |||
S: <contact:infData | S: <contact:infData | |||
S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
S: <contact:id>sh8013</contact:id> | S: <contact:id>sh8013</contact:id> | |||
skipping to change at line 332 ¶ | skipping to change at line 328 ¶ | |||
S: <trID> | S: <trID> | |||
S: <clTRID>ABC-12345</clTRID> | S: <clTRID>ABC-12345</clTRID> | |||
S: <svTRID>54322-XYZ</svTRID> | S: <svTRID>54322-XYZ</svTRID> | |||
S: </trID> | S: </trID> | |||
S: </response> | S: </response> | |||
S:</epp> | S:</epp> | |||
Figure 1: Example <info> Contact Response Using the | Figure 1: Example <info> Contact Response Using the | |||
<addlEmail:addlEmail> Extension with No Alternate Email Address | <addlEmail:addlEmail> Extension with No Alternate Email Address | |||
The following is an example <info> contact response using the | ||||
<addlEmail:addlEmail> extension with an ASCII alternate email | ||||
address: | ||||
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
S: <response> | S: <response> | |||
S: <result code="1000"> | S: <result code="1000"> | |||
S: <msg>Command completed successfully</msg> | S: <msg>Command completed successfully</msg> | |||
S: </result> | S: </result> | |||
S: <resData> | S: <resData> | |||
S: <contact:infData | S: <contact:infData | |||
S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
S: <contact:id>sh8013</contact:id> | S: <contact:id>sh8013</contact:id> | |||
skipping to change at line 393 ¶ | skipping to change at line 385 ¶ | |||
S: </addlEmail:addlEmail> | S: </addlEmail:addlEmail> | |||
S: </extension> | S: </extension> | |||
S: <trID> | S: <trID> | |||
S: <clTRID>ABC-12345</clTRID> | S: <clTRID>ABC-12345</clTRID> | |||
S: <svTRID>54322-XYZ</svTRID> | S: <svTRID>54322-XYZ</svTRID> | |||
S: </trID> | S: </trID> | |||
S: </response> | S: </response> | |||
S:</epp> | S:</epp> | |||
Figure 2: Example <info> Contact Response Using the | Figure 2: Example <info> Contact Response Using the | |||
<addlEmail:addlEmail> Extension with an ASCII Alternate Email | <addlEmail:addlEmail> Extension with an Alternate ASCII Email | |||
Address | Address | |||
The following is an example <info> contact response using the | ||||
<addlEmail:addlEmail> extension with an SMTPUTF8 primary email | ||||
address: | ||||
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
S: <response> | S: <response> | |||
S: <result code="1000"> | S: <result code="1000"> | |||
S: <msg>Command completed successfully</msg> | S: <msg>Command completed successfully</msg> | |||
S: </result> | S: </result> | |||
S: <resData> | S: <resData> | |||
S: <contact:infData | S: <contact:infData | |||
S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
S: <contact:id>sh8013</contact:id> | S: <contact:id>sh8013</contact:id> | |||
skipping to change at line 477 ¶ | skipping to change at line 465 ¶ | |||
EPP provides five commands to transform objects: <create> to create | EPP provides five commands to transform objects: <create> to create | |||
an instance of an object, <delete> to delete an instance of an | an instance of an object, <delete> to delete an instance of an | |||
object, <renew> to extend the validity period of an object, | object, <renew> to extend the validity period of an object, | |||
<transfer> to manage object sponsorship changes, and <update> to | <transfer> to manage object sponsorship changes, and <update> to | |||
change information associated with an object. | change information associated with an object. | |||
5.2.1. EPP <create> Command | 5.2.1. EPP <create> Command | |||
This extension defines additional elements to extend the EPP <create> | This extension defines additional elements to extend the EPP <create> | |||
command of an object mapping like [RFC5733]. | command described in [RFC5733]. | |||
The EPP <create> command provides a transform operation that allows a | The EPP <create> command provides a transform operation that allows a | |||
client to create an instance of an object. In addition to the EPP | client to create an instance of an object. In addition to the EPP | |||
command elements described in an object mapping like [RFC5733], the | command elements described in [RFC5733], the command MUST contain a | |||
command MUST contain a child <addlEmail:addlEmail> element | child <addlEmail:addlEmail> element (Section 3) for the client to set | |||
(Section 3) for the client to set an alternate email address. | an alternate email address. | |||
The following is an example <create> command to create a contact | ||||
object with an alternate ASCII email address: | ||||
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
C: <command> | C: <command> | |||
C: <create> | C: <create> | |||
C: <contact:create | C: <contact:create | |||
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
C: <contact:id>sh8013</contact:id> | C: <contact:id>sh8013</contact:id> | |||
C: <contact:postalInfo type="int"> | C: <contact:postalInfo type="int"> | |||
C: <contact:name>John Doe</contact:name> | C: <contact:name>John Doe</contact:name> | |||
skipping to change at line 532 ¶ | skipping to change at line 517 ¶ | |||
C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email> | C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email> | |||
C: </addlEmail:addlEmail> | C: </addlEmail:addlEmail> | |||
C: </extension> | C: </extension> | |||
C: <clTRID>ABC-12345</clTRID> | C: <clTRID>ABC-12345</clTRID> | |||
C: </command> | C: </command> | |||
C:</epp> | C:</epp> | |||
Figure 4: Example <create> Command to Create a Contact Object | Figure 4: Example <create> Command to Create a Contact Object | |||
with an Alternate ASCII Email Address | with an Alternate ASCII Email Address | |||
The following is an example <create> command to create a contact | ||||
object with a primary SMTPUTF8 email address: | ||||
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
C: <command> | C: <command> | |||
C: <create> | C: <create> | |||
C: <contact:create | C: <contact:create | |||
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
C: <contact:id>sh8013</contact:id> | C: <contact:id>sh8013</contact:id> | |||
C: <contact:postalInfo type="int"> | C: <contact:postalInfo type="int"> | |||
C: <contact:name>John Doe</contact:name> | C: <contact:name>John Doe</contact:name> | |||
C: <contact:org>Example Inc.</contact:org> | C: <contact:org>Example Inc.</contact:org> | |||
skipping to change at line 601 ¶ | skipping to change at line 583 ¶ | |||
or <renew> response described in [RFC5730]. | or <renew> response described in [RFC5730]. | |||
5.2.4. EPP <transfer> Command | 5.2.4. EPP <transfer> Command | |||
This extension does not add any elements to the EPP <transfer> | This extension does not add any elements to the EPP <transfer> | |||
command or <transfer> response described in [RFC5730]. | command or <transfer> response described in [RFC5730]. | |||
5.2.5. EPP <update> Command | 5.2.5. EPP <update> Command | |||
This extension defines additional elements to extend the EPP <update> | This extension defines additional elements to extend the EPP <update> | |||
command of an object mapping like [RFC5733]. | command described in [RFC5733]. | |||
The EPP <update> command provides a transform operation that allows a | The EPP <update> command provides a transform operation that allows a | |||
client to update an instance of an object. In addition to the EPP | client to update an instance of an object. In addition to the EPP | |||
command elements described in an object mapping like [RFC5733], the | command elements described in [RFC5733], the command MUST contain a | |||
command MUST contain a child <addlEmail:addlEmail> element | child <addlEmail:addlEmail> element (Section 3) for the client to set | |||
(Section 3) for the client to set or unset an alternate email | or unset an alternate email address. If the alternate email address | |||
address. If the alternate email address cannot be applied to the | cannot be applied to the object, the server MUST return an EPP error | |||
object, the server MUST return an EPP error result code of 2201. | result code of 2201. | |||
The following is an example <update> command to set a contact object | ||||
with an alternate ASCII email address: | ||||
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
C: <command> | C: <command> | |||
C: <update> | C: <update> | |||
C: <contact:update | C: <contact:update | |||
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
C: <contact:id>sh8013</contact:id> | C: <contact:id>sh8013</contact:id> | |||
C: </contact:update> | C: </contact:update> | |||
C: </update> | C: </update> | |||
skipping to change at line 636 ¶ | skipping to change at line 615 ¶ | |||
C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email> | C: <addlEmail:email>jdoe-alt@example.net</addlEmail:email> | |||
C: </addlEmail:addlEmail> | C: </addlEmail:addlEmail> | |||
C: </extension> | C: </extension> | |||
C: <clTRID>ABC-12345</clTRID> | C: <clTRID>ABC-12345</clTRID> | |||
C: </command> | C: </command> | |||
C:</epp> | C:</epp> | |||
Figure 6: Example <update> Command to Set a Contact Object with | Figure 6: Example <update> Command to Set a Contact Object with | |||
an Alternate ASCII Email Address | an Alternate ASCII Email Address | |||
The following is an example <update> command to set a contact object | ||||
with an alternate SMTPUTF8 email address: | ||||
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
C: <command> | C: <command> | |||
C: <update> | C: <update> | |||
C: <contact:update | C: <contact:update | |||
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
C: <contact:id>sh8013</contact:id> | C: <contact:id>sh8013</contact:id> | |||
C: </contact:update> | C: </contact:update> | |||
C: </update> | C: </update> | |||
C: <extension> | C: <extension> | |||
skipping to change at line 661 ¶ | skipping to change at line 637 ¶ | |||
C: <addlEmail:email>麥克風@example.com</addlEmail:email> | C: <addlEmail:email>麥克風@example.com</addlEmail:email> | |||
C: </addlEmail:addlEmail> | C: </addlEmail:addlEmail> | |||
C: </extension> | C: </extension> | |||
C: <clTRID>ABC-12345</clTRID> | C: <clTRID>ABC-12345</clTRID> | |||
C: </command> | C: </command> | |||
C:</epp> | C:</epp> | |||
Figure 7: Example <update> Command to Set a Contact Object with | Figure 7: Example <update> Command to Set a Contact Object with | |||
an Alternate SMTPUTF8 Email Address | an Alternate SMTPUTF8 Email Address | |||
The following is an example <update> command to unset a contact | ||||
object alternate email address: | ||||
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> | |||
C: <command> | C: <command> | |||
C: <update> | C: <update> | |||
C: <contact:update | C: <contact:update | |||
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> | |||
C: <contact:id>sh8013</contact:id> | C: <contact:id>sh8013</contact:id> | |||
C: </contact:update> | C: </contact:update> | |||
C: </update> | C: </update> | |||
C: <extension> | C: <extension> | |||
skipping to change at line 739 ¶ | skipping to change at line 712 ¶ | |||
<!-- | <!-- | |||
End of schema. | End of schema. | |||
--> | --> | |||
</schema> | </schema> | |||
<CODE ENDS> | <CODE ENDS> | |||
7. IANA Considerations | 7. IANA Considerations | |||
7.1. XML Namespace | 7.1. XML Namespace | |||
This document uses URNs to describe XML namespaces conforming to a | This document uses URNs to describe XML namespaces and XML schemas | |||
registry mechanism described in [RFC3688]. The following URI | conforming to a registry mechanism described in [RFC3688]. The | |||
assignments have been made by IANA: | following URI assignments have been made by IANA: | |||
Registration for the addlEmail namespace: | Registration for the addlEmail namespace: | |||
URI: urn:ietf:params:xml:ns:epp:addlEmail-1.0 | URI: urn:ietf:params:xml:ns:epp:addlEmail-1.0 | |||
Registrant Contact: IESG | Registrant Contact: IESG | |||
XML: None. Namespace URIs do not represent an XML specification. | XML: None. Namespace URIs do not represent an XML specification. | |||
Registration for the addlEmail XML Schema: | Registration for the addlEmail XML Schema: | |||
URI: urn:ietf:params:xml:schema:epp:addlEmail-1.0 | URI: urn:ietf:params:xml:schema:epp:addlEmail-1.0 | |||
skipping to change at line 776 ¶ | skipping to change at line 749 ¶ | |||
Registrant Name and Email Address: IESG, <iesg@ietf.org> | Registrant Name and Email Address: IESG, <iesg@ietf.org> | |||
TLDs: Any | TLDs: Any | |||
IPR Disclosure: None | IPR Disclosure: None | |||
Status: Active | Status: Active | |||
Notes: None | Notes: None | |||
8. Security Considerations | 8. Security Considerations | |||
As noted in Sections 10.1 and 13 of [RFC6530], unconstrained Unicode | As noted in Sections 10.1 and 13 of [RFC6530], unconstrained Unicode | |||
in email addresses can introduce a class of security threats that do | in email addresses can introduce a class of security threats that do | |||
not exist with all-ASCII email addresses. As EPP exists in | not exist with ASCII-only email addresses. As EPP exists in | |||
ecosystems where email addresses passed in EPP are displayed in the | ecosystems where email addresses passed in EPP are displayed in the | |||
Registration Data Access Protocol (RDAP) and other services, and | Registration Data Access Protocol (RDAP) and other services, and | |||
copy-and-paste of these email addresses is common for businesses | copy-and-paste of these email addresses is common for businesses | |||
transferring domains via EPP, there should be safeguards against | transferring domains via EPP, there should be safeguards against | |||
these threats. Therefore, use of the SMTPUTF8 email addresses as | these threats. Therefore, use of the SMTPUTF8 email addresses as | |||
described in this document SHOULD be done with policies that disallow | described in this document SHOULD be done with policies that disallow | |||
the use of unconstrained Unicode. The domain-part of these SMTPUTF8 | the use of unconstrained Unicode. The domain-part of these SMTPUTF8 | |||
email addresses SHOULD conform to IDNA2008. The local-part of these | email addresses SHOULD conform to IDNA2008 [RFC5895]. The local-part | |||
SMTPUTF8 email addresses SHOULD be restricted to Unicode that does | of these SMTPUTF8 email addresses SHOULD be restricted to Unicode | |||
not introduce the threats noted in [RFC6530]. One such possible | that does not introduce the threats noted in [RFC6530]. One such | |||
solution would be to disallow characters outside of Unicode Annex 31 | possible solution would be to disallow characters outside of Unicode | |||
[Unicode-UAX31]. | Annex 31 [Unicode-UAX31]. | |||
As an email address is often a primary end user contact, an invalid | As an email address is often a primary end user contact, an invalid | |||
email address may put communication with the end user at risk when | email address may put communication with the end user at risk when | |||
such contact is necessary. In case of an invalid domain name in the | such contact is necessary. In case of an invalid domain name in the | |||
email address, a malicious actor can register a valid domain name | email address, a malicious actor can register a valid domain name | |||
with a similar U-label (homograph attack) and assume control over the | with a similar U-label (homograph attack) and assume control over the | |||
domain name associated with the contact using social engineering | domain name associated with the contact using social engineering | |||
techniques. To reduce the risk of the use of invalid domain names in | techniques. To reduce the risk of the use of invalid domain names in | |||
email addresses, registries SHOULD validate the domain name syntax in | email addresses, registries SHOULD validate the domain name syntax in | |||
the provided email addresses and validate whether the domain name | provided email addresses and validate whether the domain name | |||
consists of the code points allowed by "IDNA Rules and Derived | consists of the code points listed in the "IDNA Rules and Derived | |||
Property Values" (https://www.iana.org/assignments/idna-tables). | Property Values" registry <https://www.iana.org/assignments/idna- | |||
tables>). | ||||
Note that the syntax for internationalized email localparts is very | Note that the syntax for internationalized email local-parts is very | |||
liberal. Domains are normalized during MX lookup, while localparts | liberal. Domains are normalized during MX lookup, while local-parts | |||
are unconstrained. Implementers may wish to test that their database | are unconstrained. Implementers may wish to test that their database | |||
is able to store difficult localparts such as U+0061 U+0300 U+00E0. | is able to store difficult local-parts such as U+0061 U+0300 U+00E0. | |||
For more on normalization and these three code points, see [RFC5198], | For more on normalization and these three code points, see [RFC5198], | |||
Section 3. | Section 3. | |||
9. Privacy Considerations | 9. Privacy Considerations | |||
The content of <addlEmail:email> elements can be processed by EPP | The content of <addlEmail:email> elements can be processed by EPP | |||
clients and servers in the same way that <contact:email> elements are | clients and servers in the same way that <contact:email> elements are | |||
processed, including publication in directory services such as RDAP | processed, including publication in directory services such as RDAP | |||
[STD95]. Many data protection regulations recognize email addresses | [STD95]. Many data protection regulations recognize email addresses | |||
as personal data, so any policies governing the collection, | as personal data, so any policies governing the collection, | |||
skipping to change at line 887 ¶ | skipping to change at line 861 ¶ | |||
2: Datatypes Second Edition", W3C Recommendation, 28 | 2: Datatypes Second Edition", W3C Recommendation, 28 | |||
October 2004, | October 2004, | |||
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. | <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. | |||
10.2. Informative References | 10.2. Informative References | |||
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network | [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network | |||
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, | Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, | |||
<https://www.rfc-editor.org/info/rfc5198>. | <https://www.rfc-editor.org/info/rfc5198>. | |||
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for | ||||
Internationalized Domain Names in Applications (IDNA) | ||||
2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, | ||||
<https://www.rfc-editor.org/info/rfc5895>. | ||||
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible | [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible | |||
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, | Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, | |||
February 2015, <https://www.rfc-editor.org/info/rfc7451>. | February 2015, <https://www.rfc-editor.org/info/rfc7451>. | |||
[STD95] Internet Standard 95, | [STD95] Internet Standard 95, | |||
<https://www.rfc-editor.org/info/std95>. | <https://www.rfc-editor.org/info/std95>. | |||
At the time of writing, this STD comprises the following: | At the time of writing, this STD comprises the following: | |||
Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the | Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the | |||
Registration Data Access Protocol (RDAP)", STD 95, | Registration Data Access Protocol (RDAP)", STD 95, | |||
End of changes. 25 change blocks. | ||||
65 lines changed or deleted | 44 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |