James, Replying to this note rather that several of the others because it most clearly identifies what is being done. I am copying, I hope, the relevant review teams. There are, I believe, three separate but closely-related issues here: (1) The document, through the -14 draft, contained some language about an "extra" all-ASCII address when an SMTPUTF8 address was supplied. It failed to indicate how that was to be transmitted, what function it served, where it might appear in data structures, etc. You now propose to solve that problem by eliminating the discussion of such addresses, presumably because it is strictly a registrar <-> registrant issues. That would be fine, except... (2) Whether we like it or not, when non-ASCII email addresses, especially ones using scripts very different from European and other so-called GLC-related one are used in arbitrary ways, they don't work smoothly and globally. They are fine for, e.g., ccTLDs where communications, as well as domain name labels are confined to a script or two and known providers, but not for generalized communications or registries handling arbitrary scripts. If the purpose of this protocol is ultimately to populate registry databases -- databases whose contents are expected to provide reliable contact and identify information for registrants even if that information is only accessible under court order or the equivalent -- then all-ASCII alternative addresses are a necessity. It would remain a necessity if the relevant registrar (or, for that matter, some of its agents) goes out of business, taking any data with them that are not part of the registry database. Provision for the alternate names should be part of the protocol, part of the data structure, and part of the databases. There may be cases where they are not needed, but that does not reduce the requirement to be able to carry and process them. (3) Or if, as I believe one of your recent notes suggested, those alternative addresses are strictly a matter between the registrar and registrant, that raises two other questions. First, if a registrar is in need of the information to adequately communicate with the registrant, why isn't the registry and those with legitimate access to registry databases? Second, if the information covered by this draft is strictly a matter of data supporting business relationships -- either registrant-registrar or even registrar-registry -- and not the operation of the public Internet -- the document does not make the case that it is a legitimate topic for IETF standardization any more than elements of service contracts between ISPs and end users would be. best, john --On Wednesday, August 17, 2022 13:20 +0000 "Gould, James" <jgould=40verisign.com@xxxxxxxxxxxxxx> wrote: > Nemo, > > In the -15 draft, we will be removing the following two > statements in section 5.3.2 and fix the nit "allow:ed" in > section 8. I believe this addresses your issues. Can you > clear your "Ready with Issues" status in the tracker? > > 1. Delete "It can be an extra ASCII email address collected by > registrar or registrar-provided proxy email address." from the > fifth bullet in section 5.3.2. 2. Delete "The provided > address can be an extra ASCII email address collected by > registrar or registrar-provided proxy email address." from the > last bullet in section 5.3.2. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
