Re: [regext] [I18ndir] [Last-Call] Genart last call review of draft-ietf-regext-epp-eai-10

[John C Klensin <[e-mail]>]

Martin,

Further trimming addresses that I know are on the i18ndir and
draft-ietf-regext-epp-eai.al lists.  Procedurally, dropping the
last-call list may be an issue because, unless the authors or
the REGEXT WG withdraw this document for further consideration,
it will go into IESG review on Thursday.  Then, unless the ART
ADs delay or withdraw it at that time (copying them), the IESG
will normally conduct its review based only on what was said on
the Last Call list (or in notes directly to them).

If I correctly understand what you are suggesting, I agree
although, for some senders, creating an alternate account as you
suggest  might raise some other issues and I have not thought
through the implications for replies.  It also suggests
something that the EAI WG did not consider, which would be to
create an "Alternate-AllASCII-ReplyAddress" header (with a
better and shorter name). I have no idea why it did not come up
-- hindsight is wonderful.  The spec would be rather easy to
write if there were any hope that MUA authors would adopt it.

However, I cannot see any way in which either your suggestion or
that alternate header field one would have any impact on
draft-ietf-regext-epp-eai-11, even if they came to be widely
used.  The I-D is, at least AFAICT, about one thing and one
thing only: a registrar taking information in its database
(presumably via a domain application that came to it) and
transferring it to a registry that then, presumably, puts the
information in its database.  The format and handling of the
registrar database are clearly not an IETF problem.  The authors
and I apparently disagree about whether the registry database
and its usability are issues with which the IETF should be
concerned.  But what a prospective mail sender with a non-ASCII
address might choose to include in outgoing mail is, I think,
rather far out of scope.

best,
   john


--On Tuesday, June 7, 2022 17:19 +0900 "Martin J. Dürst"
<[e-mail]> wrote:

> Sorry to again be late with my comments (and deleting
> [e-mail] and gen-art@ietf from the cc list because I
> think that my comment may be a bit premature for them).
> 
> I think John below certainly has a point. But with respect to
> reachability of non-ASCII containing email addresses (SMTPUTF8
> email addresses), it occurs to me that we might sooner or
> later be at a point where a prospective sender doesn't have an
> SMTPUTF8 capable account, but can nevertheless reach an
> SMTPUTF8 email address. The way this is done is simple,
> although a bit tedious: The sender just creates an
> SMTPUTF8-capable email address account (I seem to remember
> that gmail or hotmail may work, although I'm not completely
> sure about this). The mail address gets copied into the 'To'
> field, and the mail gets sent and reaches the destination. The
> reply also should work. Of course, the sender has to check
> this separate account for answers on a regular basis.
> 
> So it may be true that SMTPUTF8 addresses are not reachable
> from every email provider. But it may not be true that
> SMTPUTF8 addresses are not reachable from every user. Of
> course, there's also the question of readability of an
> address, but assuming the address is clearly displayed and can
> be easily copied, it doesn't actually have to be readable by
> the sender.
> 
> Regards,   Martin.
> 
> On 2022-06-02 16:05, John C Klensin wrote:
>> Pete and James,
>> 
>> Let me add one thing to Pete's (and Yoshiro Yoneya's)
>> comments/concerns.  I tried to raise this earlier, but
>> obviously did not explain it well:
>> 
>> 
>> --On Wednesday, June 1, 2022 20:23 +0000 "Gould, James"
>> <jgould=[e-mail]> wrote:
>> 
>>> Pete,
>>> 
>>> Thanks for the review and feedback.  My responses are
>>> embedded below prefixed with "JG - ".
>>> ...
>>> On 6/1/22, 1:14 PM, "Pete Resnick via Datatracker"
>>> <[e-mail]> wrote:
>>> ...
>>>      Reviewer: Pete Resnick
>>>      Review result: On the Right Track
>>> 
>>> ...
>>>      Document: draft-ietf-regext-epp-eai-10
>>>      Reviewer: Pete Resnick
>>>      Review Date: 2022-06-01
>>>      IETF LC End Date: 2022-06-09
>>>      IESG Telechat date: Not scheduled for a telechat
>>> 
>>>      Summary:
>>> 
>>>      I think this proposal is reasonable, but I don't think
>>> enough explanation has     been given regarding the case
>>> where one side supports the protocol but the other side
>>> doesn't.
>> 
>> Unless I don't understand the use cases for the information
>> being handled by EPP and this proposed extension, there are
>> actually three "sides" / "parties" for the data and their use.
>> One is the registrar or equivalent, in software normally the
>> EPP client.  The second is the registry or equivalent, in
>> software normally the EPP server.  If those were the only two
>> actors, one could be quite relaxed about the server being
>> ready to handle non-ASCII email addresses because the
>> decision to accept non-ASCII email addresses or not could be
>> a contractual matter.
>>> From a contractual perspective, a registrar/client who sent a
>> non-ASCII contact address to a registry/server who would nor
>> or could not accept such things would be a much worse problem
>> that questions of how the protocol dealt with that behavior.
>> 
>> However, in many, probably most, registry arrangements, there
>> is also a requirement for registry databases that contain,
>> among other things, contact information for registrants, etc.
>> While circumstances and regulations may impose conditions for
>> third parties to access those data, such access must always be
>> possible.  That is probably the important case for alternate
>> ASCII addresses.  Not only are those third parties typically
>> not part of the EPP transaction itself, but the registry
>> faces the same issues that motivated the EAI WG to generate
>> RFC 6857 and 6858: it cannot know, at the time information is
>> placed in the database, what the capabilities of those
>> authorized to access the data later will be.
>> 
>> Against that backdrop...
>> 
>>>      Major issues:
>>> 
>>>      The last bullet item in section 5.3.2 talks about
>>> "alternative ASCII address",     but I don't see anywhere in
>>> the document which defines how to provide an     alternative
>>> ASCII address in the data. For example, RFC 5733 implies that
>>> there     will be only one email address in the Contact
>>> Mapping; can an implementation     simply add a second? Does
>>> the server then need to distinguish these by the     presence
>>> or absence of non-ASCII characters to determine which is an
>>> EAI and     which is an alternative ASCII address? At the
>>> very least, some discussion of     this seems necessary in
>>> the document.
>>> 
>>> JG - The reference to the "alternative ASCII email address"
>>> is for the client (registrar) when it's recognized that the
>>> server does not support EAI.  If the registrar collected an
>>> EAI address and an ASCII address, then the ASCII address MUST
>>> be provided; otherwise, the optional property SHOULD be
>>> omitted.  The use of an ASCII proxy email address can be used
>>> as well.  In this case, the server does not support EAI
>>> addresses, so it's up to the EAI-supporting client to handle
>>> it.  Most likely the server validates that the address is
>>> only an ASCII address, but there is no guarantee of it.
>> 
>> While I understand you are speaking informally here, to
>> increase the odds that the text will be correct, please note
>> that there are no such things as "supporting EAI" or "EAI
>> addresses".  EAI is simply the name/acronym for the working
>> group that produced a set of specifications.  Those
>> specifications indicate that, if you are looking for a
>> generic term, you should use the name of the SMTP extension,
>> i.e., "SMTPUTF8".
>> 
>> Now, when I read the above paragraph in the context of those
>> registry databases and third parties accessing them (and
>> assume that, when you wrote "EAI", you meant "addresses with
>> non-ASCII local parts" or "SMTPUTF8").  Those EAI
>> WG-developed specs, reinforced by operational experience
>> since they were developed, make it very clear that, unless it
>> is known that those who will be using --not just
>> transferring-- the addresses are able to handle and utilize
>> email addresses with non-ASCII local parts, that either there
>> must be a reliable way to obtain an all-ASCII alternate
>> address or not being able to use the contact address much be
>> acceptable.  Absent a directory structure somewhere that
>> records addresses with non-ASCII local parts and the all-ASCII
>> fallbacks for each -- a directory that, in a registry type of
>> environment, would need to be populated somehow, presumably by
>> EPP -- the only reliable way to have those all-ASCII addresses
>> available is to provide for (and probably require) them in the
>> EPP extension and store them in the registry database.   And,
>> unlike the situation contemplated by RFC 6858, registry
>> databases are typically required to contain contact
>> information that is both usable and accurate, more or less
>> eliminating the option of simply recording an address that
>> cannot be used.
>> 
>> So, coming back to your paragraph, one of my concerns (and I
>> think at least part of Pete's) is that, if one option is "the
>> use of an ASCII proxy email address", then you need to spell
>> out where that address is going to come from.  Or, if the
>> registry cannot guarantee that anyone who might legitimately
>> have access to the registry database will be able to properly
>> process and use contact information that contains email
>> addresses that require SMTPUTF8, they must insist on being
>> given all-ASCII addresses (presumably starting by insisting
>> that the registrar collect them).  That, in turn, would make
>> this extension very nearly useless except, perhaps, for a
>> subset of ccTLDs who could impose just that requirement as a
>> condition of legitimate access.
>> 
>> In addition, you say
>> 
>> 	"If the registrar collected an EAI address and an ASCII
>> 	address, then the ASCII address MUST be provided;
>> 	otherwise, the optional property SHOULD be omitted."
>> 
>> I don't know what that sentence means.  This extension does
>> not appear to allow the registrar/client to transmit two
>> addresses over EPP to the registry.  So, if an all-ASCII
>> address MUST be provided, it is the only one and then there
>> is no need for the extension (at least as I read the spec).
>> If the "optional property" is not used for all-ASCII
>> addresses, then is then, at best meaningless and I don't
>> understand the SHOULD".  The same situation would apply if
>> the registrar collected only an ASCII address: the SHOULD
>> does not appear to make sense.  And, if the registrar
>> collected only an SMTPUTF8 address, then the only way to
>> transmit it is using this optional property.
>> 
>>> ...
>>>      Minor issues:
>>> 
>>>      In the bullets in section 5.3.2, there are quite a few
>>> SHOULDs with no     explanation of why one might choose to
>>> violate these. Why are these not MUSTs?     I can't think of
>>> any reason, for example, that the server would not validate
>>> the email property, and it seems like a really bad idea not
>>> to.
>>> 
>>> JG - I cover each of the SHOULDs below:
>>> 
>>> 1. For the required email property with a client that doesn't
>>> signal support for EAI, the server needs to satisfy the
>>> negotiated services . This should be a MUST to comply with
>>> the negotiated namespaces, since the downside is that the
>>> client will receive an error response with an info command
>>> if they still don't support EAI in the login services.   The
>>> error response is a MUST in the third bullet.
>> 
>>> 2. For the optional
>>> email property falls the same case as the required email
>>> property, since the info response will result in an error.
>>> It should be a MUST as well.  The error response is a MUST
>>> in the fourth bullet.
>> 
>> It seems to me that what you just said is that the "SHOULD"s
>> were in error and that they really should have been "MUST"s.
>> If that is the case, the affected bullet points would, at
>> least, be much more clear.
>> 
>> 
>>> ...
>>>      Section 3: Change "By applying the syntax rules of
>>> [RFC5322]" to "By applying     the syntax rules of [RFC6532]"
>>> 
>>> JG - I'll leave this one for Dmitry to respond to, but
>>> changing RFC5322 to RFC6532 looks correct to me.
>> 
>> FWIW, note that issue was raised in my Last Call comments on
>> May 26 [1] and, so far, not responded to.  If you (and that
>> should mean with approval of the WG, not just you and/or
>> Dmitry) are not going to change it, some explanation would
>> be, at least IMO, appropriate.
>> 
>> thanks,
>>      john
>> 
>> 
>> [1]
>> <https://mailarchive.ietf.org/arch/msg/last-call/pDEjCW75nLxn
>> d-NbNcPR3E7VKfE>
>> 
>