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/





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.

_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

Reply via email to