Re: [regext] Internationalized Email Addresses and EPP

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Barry Leiba <[e-mail]>
> Sent: Monday, October 19, 2020 5:48 AM
> To: Hollenbeck, Scott <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: [EXTERNAL] Re: Internationalized Email Addresses and EPP
>
> Hi, Scott,
>
> An interesting question...
>
> I think it depends upon how you want this to appear from an EPP point of
> view:
>
> 1. Do you want the EPP standard to support non-ASCII email addresses?
>
> 2. Do you want to *extend* EPP to support non-ASCII email addresses, as an
> option for those who implement the extension?
>
> For (2), then the EPP extension would be the easiest option, where the
> extension would "update" 5733 and say that the extension changes the
> definition to allow non-ASCII email addresses.  The extension would be at
> Proposed Standard, and 5733 would be at Internet Standard as it is now.
>
> For (1), the best way would be to revise 5733 and change the definition of
> email address syntax, republishing it at Proposed Standard and "obsolete"
> 5733.  The protocol (the new RFC) would then be back at Proposed Standard.
> You could then do a status change later to move the new RFC to Internet
> Standard (without publishing yet another revision).

After doing a bit more document-reading-based research, I think the normative 
reference situation is where it needs to be, though the document relationships 
are a bit unclear because they're not explicitly shown in the IETF 
Datatracker. RFC 5733 includes a normative reference to RFC 5322 ("Internet 
Message Format")  for the definition of email address syntax. Section 3.4.1 is 
where the local-part is specified. 5322 also includes an informative reference 
to 5321, "Simple Mail Transfer Protocol".

RFC 6531 describes an SMTP extension (as provided for in RFC 5321) for 
internationalized addresses. SMTP extensions are OPTIONAL. Section 5 of RFC 
6530 states that "The email message header document [RFC6532] essentially 
updates RFC 5322 to permit some information in email message headers to be 
expressed directly by Unicode characters encoded in UTF-8 when the SMTP 
extension described above is used." RFC 6532 includes "Syntax Extensions to 
RFC 5322" In Section 3.2. Put all this together and we have EAI documents that 
update the syntax specification found in 5322 *if* you choose to support the 
EAI SMTP extension.

So, I believe the reference in 5733 is still appropriate, and the right way to 
tackle this is to create an EPP extension to allow EPP clients and servers to 
support EAI. That extension would need to include normative references to the 
EAI RFCs, and it would need to allow internationalized email addresses in any 
EPP fields, including other extensions, that currently carry email addresses. 
The XML Schema in 5733 already supports internationalized email addresses, so 
that doesn't need to change, either.

I'm looking forward to the discussion at our next meeting, assuming that I can 
stay awake for it.

Scott