Hi, We have two documents in the regext group, two in mailmaint and one that was in extra and is now in the RFC editor’s queue. Regext is the working group that develops the protocols used for registering domains etc. When you register a domain, the registrar’s website will speak a protocol called EPP to a central database at a registry, and regext is the group that works on EPP and a few other things. Regext has two documents relevant to UA. One is about the use of Unicode email addresses for domain contacts, ie. you can enter grå@grå.org<mailto:grå@grå.org> into the ‘domain owner’ field in that website. That one’s taken many years and has suffered from wearisome differences of opinion, but I think Scott is able to get it done. Everyone seems tired and happy. The second is about domain variants. There are some cases where people consider two different strings to be the same, this is to be supported in the DNS in some cases (don’t jump to conclusions here, it’s much more complicated and well-considered than you might think). There’s a document that extends EPP so that a registrar and registry can communicate sensibly about such groups of variant domains. Mailmaint is the IETF group for minor mail maintenance chores. It has two documents to restrict and improve the syntax, to allow everything that people use while also disallowing the kinds of things that make developers scared of supporting Unicode localparts. They’re both at a fairly early stage process-wise. (On a related note, there’s now similar new work going on at the W3C. I’ll do my very best to align everything, if possible so that one references the other. We don’t want accidental discrepancies.) Extra is an older group for mail extensions, much like mailmaint but with different rules for what to work on and how to do the work. It has one document to revise an IMAP extension to eliminate some fairly esoteric problems. We had cases where code written in python and code written in java would act differently, and the ultimate reason was really… details in this RFC didn’t match those in that RFC and should have, and that caused occasional practical problems. My private mail reader crashed once last weekend because of this. Arnt From: Maria Kolesnikova <masha@cctld.ru> Date: Tuesday, 19 November 2024 at 15:02 To: Arnt Gulbrandsen <arnt.gulbrandsen@icann.org>, "'Mark Svancarek (CELA)'" <marksv@microsoft.com>, "'Hollenbeck, Scott'" <shollenbeck@verisign.com>, "dusan@dukes.in.rs" <dusan@dukes.in.rs>, "ua-discuss@icann.org" <ua-discuss@icann.org> Subject: [Ext] RE: [UA-EAI] Re: [EXTERNAL] RE: [UA-discuss] Fwd: [EAI] [Errata Verified] RFC6531 (7580) Dear All, Is it possible to list IETF documents that are in moving now? To see the whole picture and ongoing processes. Thank you in advance. Maria Kolesnikova From: Arnt Gulbrandsen via UA-EAI <ua-eai@icann.org> Sent: Tuesday, November 19, 2024 11:34 AM To: Mark Svancarek (CELA) <marksv@microsoft.com>; Hollenbeck, Scott <shollenbeck@verisign.com>; dusan@dukes.in.rs; ua-eai@icann.org; ua-discuss@icann.org Subject: [UA-EAI] Re: [EXTERNAL] RE: [UA-discuss] Fwd: [EAI] [Errata Verified] RFC6531 (7580) Hi, There are a few IETF documents moving, actually. More activity than five years ago. One document enables use of Unicode addresses in domain contact addresses. Scott is the hero who may finally be able to push that over the finishing line, which would require reviewing some older documents. Arnt From: "Mark Svancarek (CELA) via UA-EAI" <ua-eai@icann.org<mailto:ua-eai@icann.org>> Reply-To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>> Date: Tuesday, 19 November 2024 at 00:49 To: "Hollenbeck, Scott" <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>>, "dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>" <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>>, "ua-eai@icann.org<mailto:ua-eai@icann.org>" <ua-eai@icann.org<mailto:ua-eai@icann.org>>, "ua-discuss@icann.org<mailto:ua-discuss@icann.org>" <ua-discuss@icann.org<mailto:ua-discuss@icann.org>> Subject: [UA-EAI] Re: [EXTERNAL] RE: [UA-discuss] Fwd: [EAI] [Errata Verified] RFC6531 (7580) That’s what I thought. I’m curious, what inspired you to review this in the year 2024? From: Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> Sent: Monday, November 18, 2024 5:41 AM To: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>>; dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>; ua-eai@icann.org<mailto:ua-eai@icann.org>; ua-discuss@icann.org<mailto:ua-discuss@icann.org> Subject: [EXTERNAL] RE: [UA-discuss] Fwd: [EAI] [Errata Verified] RFC6531 (7580) An RFC that updates another one makes a “must incorporate” change to the original specification. RFC 6531 does not update RFC 5321, it describes a new, optional capability that’s described as an extension in the very title of the RFC. That’s why I believe that the original text in 6531 is misleading and why I submitted the report. The correction should help make it clear that the extension does not formally update RFC 5321. Scott From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Friday, November 15, 2024 6:14 PM To: Душан Стојичевић <dusan@dukes.in.rs<mailto:dusan@dukes.in.rs>>; ua-eai@icann.org<mailto:ua-eai@icann.org>; ua-discuss@icann.org<mailto:ua-discuss@icann.org>; Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> Subject: [EXTERNAL] RE: [EXTERNAL] [UA-discuss] Fwd: [EAI] [Errata Verified] RFC6531 (7580) 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. Hmm, I am not so sure. Scott, could you clarify the potential impact of this errata report? /marksv From: Душан Стојичевић via UA-discuss <ua-discuss@icann.org<mailto:ua-discuss@icann.org>> Sent: Friday, November 15, 2024 14:21 To: ua-eai@icann.org<mailto:ua-eai@icann.org>; ua-discuss@icann.org<mailto:ua-discuss@icann.org> Subject: [EXTERNAL] [UA-discuss] Fwd: [EAI] [Errata Verified] RFC6531 (7580) If I am reading this correctly, we will get huge change in EAI. My two cents, Dusan ---------- Прослеђена порука ---------- Од: RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>> Датум: 15. 11. 2024. 22:52 Наслов: [EAI] [Errata Verified] RFC6531 (7580) Коме: shollenbeck@verisign.com,yaojk@cnnic.cn,maowei_ietf@cnnic.cn<mailto:shollenbeck@verisign.com,yaojk@cnnic.cn,maowei_ietf@cnnic.cn> Копија: orie@transmute.industries,iesg@ietf.org,ima@ietf.org,iana@iana.org,rfc-editor@rfc-editor.org<mailto:orie@transmute.industries,iesg@ietf.org,ima@ietf.org,iana@iana.org,rfc-editor@rfc-editor.org> The following errata report has been verified for RFC6531, "SMTP Extension for Internationalized Email". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7580 [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1c36W4TyCnZMPETfveBd...> -------------------------------------- Status: Verified Type: Technical Reported by: Scott Hollenbeck <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> Date Reported: 2023-07-31 Verified by: Orie Steele (IESG) Sections 3.3 and 3.7.3 say: Original Text ------------- The <Mailbox> ABNF rule is imported from RFC 5321 and updated in order to support the internationalized email address. The following ABNF rules imported from RFC 5321, Section 4.1.2, are updated directly or indirectly by this document: This document updates <Mailbox> and <Domain> to support non-ASCII characters. Corrected Text -------------- The <Mailbox> ABNF rule is imported from RFC 5321 and extended in order to support the internationalized email address. The following ABNF rules imported from RFC 5321, Section 4.1.2, are extended directly or indirectly by this document: This document extends <Mailbox> and <Domain> to support non-ASCII characters. Notes ----- The original text can be incorrectly interpreted to suggest that the definitions found in RFC 6531 formally update the definitions found in RFC 5321. RFC 6531 does not formally update RFC 5321. As such, a word like "extends" may be less prone to misinterpretation than "updates". -------------------------------------- RFC6531 (draft-ietf-eai-rfc5336bis-16) -------------------------------------- Title : SMTP Extension for Internationalized Email Publication Date : February 2012 Author(s) : J. Yao, W. Mao Category : PROPOSED STANDARD Source : Email Address Internationalization Stream : IETF Verifying Party : IESG _______________________________________________ IMA mailing list -- ima@ietf.org<mailto:ima@ietf.org> To unsubscribe send an email to ima-leave@ietf.org<mailto:ima-leave@ietf.org>