Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-epp-eai-27

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-regext-epp-eai@ietf.org, jkolker@godaddy.com, orie@or13.io, regext-chairs@ietf.org, regext@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)' to Proposed Standard (draft-ietf-regext-epp-eai-27.txt)

The IESG has approved the following document:
- 'Additional Email Address Extension for the Extensible Provisioning
   Protocol (EPP)'
  (draft-ietf-regext-epp-eai-27.txt) as Proposed Standard

This document is the product of the Registration Protocols Extensions Working
Group.

The IESG contact persons are Andy Newton and Orie Steele.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/

Ballot Text

Technical Summary

   The Extensible Provisioning Protocol (EPP) does not natively support
   internationalized email addresses because the specifications for
   these addresses did not exist when EPP was developed.  This document
   describes a command-response extension that adds support for
   associating an additional email address with an EPP contact object.
   That additional email address can be either an internationalized
   email address or an all-ASCII address.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

     Two technical points required a fair amount of discussion, although both were
     resolved with strong consensus. Initially a proposal was made to change how the
     syntax of email addresses would be validated based on a new namespace URI. 
     However, objections were raised that this would be considered an update to EPP
     which was not desired due to the importance of backward compatibility which was
     considered to be more important.

     This led to the current proposal of an additional extension element added to
     the contact object that can contain either an additional ASCII or SMTPUTF8
     email address.  The working group then had discussions about the relationship
     between the two addresses and concerns about backwards compatibility in email
     systems.  The working group decided that that was a policy concern not a
     technical concern.  As long as clients could provide a proper email address to
     be present, each registry could decide for itself how it wanted to relate the
     two email addresses.  This is important because both situations, the old syntax
     and the new syntax, might each exist in an environment where the other is not
     supported.  So, any rules about requiring both technically seemed inappropriate.

Document Quality

   Are there existing implementations of the protocol?  

     Verisign has implemented a full client and server stub implementation covered
     in Section 8 of the document.

Personnel
   The Document Shepherd is Jody Kolker, but the latest version was uploaded by Jim Galvin.
   The Responsible Area Director is Orie Steele.

RFC Editor Note