Re: [regext] Internationalized Email Addresses and EPP

[Hollenbeck, Scott]

> -Original Message-
> From: Barry Leiba 
> Sent: Monday, October 19, 2020 5:48 AM
> To: Hollenbeck, Scott 
> 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

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

[Gould, James]

Jody,

I reviewed the draft updates and your responses.  I provide my feedback 
embedded below.  I believe there are still changes that need to be discussed 
and agreed to prior to closing out the WGLC.

Thanks,

--

JG

[cid:image001.png@01D6AE15.51B08F00]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Jody Kolker 
Date: Friday, October 23, 2020 at 5:16 PM
To: "regext@ietf.org" , James Gould , 
"gal...@elistx.com" 
Subject: RE: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-03

Thanks for the detailed feedback Jim and apologies for the late reply.

Responses are inline.

Please let us know if you have any questions.

Jody.

From: regext  On Behalf Of Gould, James
Sent: Tuesday, October 6, 2020 2:28 PM
To: gal...@elistx.com; regext@ietf.org
Subject: Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-03


Hi,



I did a review of draft-ietf-regext-epp-registry-maintenance and the following 
is my feedback:



1.   Section 1.1 Terminology and Definition

a.   Since the draft has moved to WGLC, this is somewhat a non-applicable 
point, but the latest practice for EPP extensions has been to use a pointed XML 
namespace (e.g., “urn:ietf:params:xml:ns:maintenance-0.X”) up until the draft 
moves to WGLC, when the XML namespace moves to 1.0 (e.g., 
“urn:ietf:params:xml:ns:maintenance-1.0”).  Using the pointed XML namespace 
will enable making XML schema changes without impacting existing 
implementations.  Backward compatibility can be broken based on WG feedback 
when using the non-pointed XML namespace.



JWK – Thanks for the feedback We will keep in mind for future drafts.  I don’t 
believe we can change from 1.0 now?



JG – I believe the best method to address this now is to include the epp 
scoping (urn:ietf:params:xml:ns:epp:maintenance-1.0) in the namespace, which 
will be requested by IANA later.



2.   Section 2.3 Maintenance Elements

a.   I would describe the Maintenance Elements in the description of the 
info response (section 3.1.3 EPP  Command) and then for the poll message, 
I would reference the use of the info response.  See how the poll messaging is 
described for the section 2.5 of the Launch Phase Mapping 
(https://tools.ietf.org/html/rfc8334#section-2.5).





JWK – As the elements are defined in 2.3, a reference was added to section 2.3. 
 We would like to only display the descriptions to the elements once instead of 
in both poll and info command sections.



JG – I believe the second sentence in 2.3 needs to be modified to read 
something like “This element will be used for EPP  message and for the 
EPP  response.”.  The remaining issue is that there are two forms of 
Maintenance Elements with the  element.  You could make it clearer 
by defining the two forms in section 2.3, where an individual maintenance could 
use the  element and the maintenances included in the list could 
use the term maintenance item and an element like  to clearer 
separate them.  Both forms of maintenance elements could be described in 
section 2.3, or the two forms could be defined in section 3.1.3 “EPP  
Command”, where the list of maintenance items only applies to the info command 
and not the poll message.  There are multiple ways to cover, this but the 
inclusion of two forms of info commands and responses should be made explicit.



b.   My recommendation is to only define SHOULD for elements that are not 
required per the XML schema, since some of the SHOULD elements in the 
description are for required elements in the XML schema.  The other EPP 
Extension RFCs default to the elements being required, but explicitly define 
optional elements using the OPTIONAL keyword.



JWK – Agreed and updated.



JG – I noticed that the use of SHOULD remain and the XML schema was updated to 
ensure that the SHOULD elements are made optional instead of required.  One 
element that is not in sync is the  element which is defined 
as a SHOULD, but is required in the XML schema.  My recommendation is to change 
the element to a MUST, since it’s a boolean value.  Another item is the value 
of the  element is defined as a SHOULD (e.g., “SHOULD either 
be …”),which it’s a MUST in the XML schema with the use of an enumeration.  My 
recommendation is to change the SHOULD to a MUST.



c.   Should the  element be of type anyURI or is it free-form 
text?

JWK – Updated to “anyURI”.

JG – I confirmed the change.


d.  The  is not defined as a “token” and does not 
include an optiona