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