> -----Original Message----- > From: Klaus Malorny <klaus.malo...@knipp.de> > Sent: Thursday, November 19, 2020 10:21 AM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: regext@ietf.org > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > Hi Scott et al., > > sorry for proposing the following so late in the discussion. Due to other > duties, my visits to the list were less frequent in the recent time. Looking > at > the two options - update of RFC 5733 or an extension -, I probably would > tend to the first option, but I understand the problems with it. > > What I regard as suboptimal in respect to the proposed EPP extension [1] is > the big effort for the little issue (RFC-wise and implementation-wise), and > also using this dummy placeholder [EAI-DUMMY] in the original <email> XML > element (while I know that this has been done before). For a non-supporting > registrar the latter is probably similarly confusing as an updated RFC 5733. > Well, you could argue that the registry can distinguish supporting and non- > supporting clients upon extensions specified at the login and behave > differently. And here comes my proposal: > > As the original email XML element could transport the internationalized e- > mail address XML schema-wise, as mentioned before, why not reduce the > whole extension to a single extension URI without any real EPP extension in > the <extension> section? No schema, no extra data. The presence in the > login would simply indicate: "yes, I can deal with internationalized e-mail > addresses in the <email> element in the contact object", like a flag. Well, I > know that would be a novel way of using extensions, but it would reduce the > implementation effort a lot on the other hand.
It could certainly be done that way, Klaus. An extension doesn’t have to require a lot of overhead if there's a simpler way to make it work. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
