> -----Original Message-----
> From: Barry Leiba <barryle...@computer.org>
> Sent: Monday, October 19, 2020 5:48 AM
> To: Hollenbeck, Scott <shollenb...@verisign.com>
> Cc: art-...@ietf.org; regext@ietf.org
> 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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
