Dear John, First, please apologize me for not participating in the original discussion
On Thu, Jun 2, 2022 at 9:06 AM John C Klensin <john-i...@jck.com> 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=40verisign....@dmarc.ietf.org> 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" > > <nore...@ietf.org> 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. > I agree. We have government regulations and ICANN rules for these cases. But all these requirements are out of scope of this document. I agree that it puts an extra burden on the 3rd parties - but the relationship between registry data and 3rd parties are definitely beyond the IETF scope. > 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. > In normal situations registries don't use its database for contacts with domain administrators. If a registry supports non-ASCII email addresses in EPP, it should also support it in case of emergency contact. But again, it's out of scope of registry-registrar protocol (EPP) definition. > 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. > > I replaced these SHOULDs with MUSTs. > > >... > > 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/pDEjCW75nLxnd-NbNcPR3E7VKfE > > > > Thank you, I picked this change and it will appear in next version of the document -- SY, Dmitry Belyavsky
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
