Dear John, Many thanks for your letter! See my response below.
On Thu, Aug 18, 2022 at 7:59 AM John C Klensin <john-i...@jck.com> wrote: > 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. > I strongly consider those alternative addresses as a part of registrar business processes not affecting the EPP protocol. Answering your sub-questions: First, the registrar has direct obligations to the registrant (and needs more contact information). Registry normally doesn't have direct contract to a registrant until smth urgent happens to the registrar. Second, this draft doesn't specify any new data that differs from those currently collected by the registry. But this collection/transfer is managed by IETF standardized protocols, and any amendments to this protocol is definitely a legitimate topic for IETF standardization. Also, as these data are available (at least partially, for some categories of registrants, etc) via RDAP, it is part of operations of the public Internet. > best, > john > > > > --On Wednesday, August 17, 2022 13:20 +0000 "Gould, James" > <jgould=40verisign....@dmarc.ietf.org> 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. > -- SY, Dmitry Belyavsky
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
