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

["Martin J. Dürst" <[e-mail]>]

Hello John, others,

Many thanks for the comments below. My comment was not intending to stop 
the progress of the draft in question.

Regards,   Martin.

On 2022-06-08 00:50, John C Klensin wrote:
> 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>
>>>