Arnt,
Thank you for your review and input. I believe the content that you propose would be best suited for an Implementation Considerations section. There are many options related to addressing the risk of registry database storage issues, based on the chosen database and persistence toolkit. I would revise this to read as a consideration without the use of the normative MUST, since I don't believe this recommendation is universally applicable to all implementations (e.g., Relational Database with ORM, NoSQL Database). How about the following: Storing of arbitrary user-supplied UTF-8 strings might not be preserved in the database. The following implementation considerations apply to ensuring that the server preserves the UTF-8 string for the SMTPUTF8 compliant addresses: 1. Have the database field used for the SMTPUTF8 compliant addresses support Unicode data types, such as the SQL NCHAR data types (NCHAR, NVARCHAR2, and NCLOB). 2. As part of processing the <create> (Section 6.2.1) and <update> (Section 6.2.5) transform commands, read the SMTPUTF8 compliant address from the database in the same way as processing the <info> command (Section 6.1.2), compare the SMTPUTF8 complaint address read with that supplied in the transform command using byte-by-byte comparison, and return an error if there is not a match. Are there any other considerations that apply to provide guidance to the implementers? Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 2/28/24, 5:47 AM, "regext on behalf of Arnt Gulbrandsen" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of a...@gulbrandsen.priv.no <mailto:a...@gulbrandsen.priv.no>> wrote: 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, I suggested some wording changes several months ago (new wording in sections 3 and 6.2). It took me several tries to put together that wording, and I quite like it: I think the database check requirement takes care of John's worries in a practical way. Arnt > I fail at writing anything involving alternate addresses. My > problem is that I think that if someone wants to use EAI and is > required to supply an ASCII alternative, then there's a decent > chance that they'll forward the ASCII alternative to their EAI > address. > > Which implies that if you can't send email to an EAI address, > want to communicate with the registrant and do it by sending > mail to an ASCII forwarding address, communication will break > down as soon as the registrant replies. That's feeble > compatibility. A compatiblity feature should provide more than > that, or else it should IMO be dumped. > > I see four options, and three of them are poor. > > 1. "EAI users MUST supply an ASCII address and MUST prefer > ASCII when replying to mail" — unrealistic. > > 2. "Anyone who wants to send mail to a registrant MUST be able > to receive a reply from an EAI address" — well, if they can > receive, why not send? > > 3. "Anyone who sends mail to an ASCII alternate MUST be aware > that a reply may not be possible through no fault of the > registrant" — what sort of communication does that enable? > > 4. "Anyone who wants to send email to a registrant MUST be able > to send mail to EAI addresses" > > The last is IMO the only workable option. EAI not that hard. > All the top MTAs support that in their latest version. Postfix > and Exim, Halon and Momentum, O365 and Gmail. > > So that's what I suggest. > c> > There is a risk that database layers might inadvertently change > the address and make it undeliverable. That shouldn't happen, > but RFC 8264 hadn't been published yet when e.g. the Oracle > RDBMS was written, so I can see why one might worry about that. > > Therefore, I suggest the following new wording for the > transform commands, perhaps at the start of section 6.2: > > - snip - > > There is some concern that arbitrary user-supplied UTF-8 > strings might not be preserved in the registry's database. > Therefore, when the the server stores an EAI address as part of > processing a mutating command such as <create>, it MUST read the > address from the database (in the same way as when processing > <info>), compare the address read with that supplied in the > command using byte-by-byte comparison, and return an error if > there was any discrepancy. > > A future revision of this specification is expected to relax > this requirement. > > - snip - > > Which error should it return? I'm not sure and I don't care. _______________________________________________ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1pvQpPOz0CTsmBZMTJs94UR2ux4rjAvuT47jogWBoZa7uTgrDETFUewcWBIlzU4hArllw_sEU0Mb5uY3RjSRN7Vw7xTU421pg8q-Og0EiTb7AYv1oeL4Qo3u1ybvVy10DPGbh_Xr5WI0iE_1mWzLjsumka3JPW-zLk3jmLFmlw7UMZji3ASxSStRMowzlzwIekrgmzdaS1QUpv4xWOzk8DOZ6GrSaBpaDAqzl9czXb9ai-cyKmpYx33QGv7PwyerUBxEoeca5lKJUItpyyat5j--1jchhZncLrflmFJrRguI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1pvQpPOz0CTsmBZMTJs94UR2ux4rjAvuT47jogWBoZa7uTgrDETFUewcWBIlzU4hArllw_sEU0Mb5uY3RjSRN7Vw7xTU421pg8q-Og0EiTb7AYv1oeL4Qo3u1ybvVy10DPGbh_Xr5WI0iE_1mWzLjsumka3JPW-zLk3jmLFmlw7UMZji3ASxSStRMowzlzwIekrgmzdaS1QUpv4xWOzk8DOZ6GrSaBpaDAqzl9czXb9ai-cyKmpYx33QGv7PwyerUBxEoeca5lKJUItpyyat5j--1jchhZncLrflmFJrRguI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
