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

Thanks to Chris M. Lonvick for their secdir review. 

I found this draft easy to understand.

Thanks for the work on this document.

Only a minor comment - please add note to RFC Editor to remove Appendix A before publication as an RFC.

Hi Dmitry, James, and Scott, 

Thanks for the effort put into this specification.

Please find some very few comments: 

# Not a new behavior: Either cite the text as a quote or remove the normative language

CURRENT:
   As described in [RFC5733], the email address associated
   with the base contact object MUST be an ASCII-only address.  

# Smells like a specification by examples

CURRENT:
   XML is case sensitive.  Unless stated otherwise, XML specifications
   and examples provided in this document MUST be interpreted in the
   character case presented in order to develop a conforming
   implementation.

Why insisting on the examples needed here? Shouldn’t compliance be based in the first sentence?

# Check normative language use

CURRENT:
   In examples, "C:" represents lines sent by a protocol client and "S:"
   represents lines returned by a protocol server.  Indentation and
   white space in the examples are provided only to illustrate element
   relationships and are not REQUIRED in the protocol.

This is misleading as this is about “not required”. Not sure I would use the normative language at the first place. I see that 5733 has an a similar instance of “not a REQUIRED feature of this protocol”, though.

# Capability negotiation

CURRENT:
   If both client and server have indicated support for SMTPUTF8
   addresses during session establishment, they MUST be able to process
   an SMTPUTF8 address in any extended contact object during the
   established EPP session.  

Is the negotiation controllable by configuration on a client/server that support the extension must always advertise/negotiate it?

Cheers,
Med

I did find the use of the "primary" attribute confusing. It seems to be defined as "this is really the primary contact, use this instead of the ascii primary contact".

If no email address is set, and an EPP client tries to add one in SMTPUTF8, should an error be thrown? Can this happen
or can't the last ASCII email address listed not be deleted?

What is the meaning of an email attribute not using the "primary" attribute that is in SMTPUTF8? It is not an
alternative email to an ASCII email address? But then what is it? Or is it an alternative to a combo of (ASCII + primary SMTPUTF8) ?

Can one delete an ASCII email so that a SMTPUTF8 email is the only one on record? I understand this is not
supposed to happen? Should an error be returned for such a delete attempt ?

Authors may consider using more recent dates in the examples.