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 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>
Reply-To: "Mark Svancarek (CELA)" <marksv@microsoft.com>
Date: Tuesday, 19 November 2024 at 00:49
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "dusan@dukes.in.rs" <dusan@dukes.in.rs>, "ua-eai@icann.org"
<ua-eai@icann.org>, "ua-discuss@icann.org" <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>
Sent: Monday, November 18, 2024 5:41 AM
To: Mark Svancarek (CELA) <marksv@microsoft.com>;
dusan@dukes.in.rs;
ua-eai@icann.org; 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>
Sent: Friday, November 15, 2024 6:14 PM
To: Душан Стојичевић <dusan@dukes.in.rs>;
ua-eai@icann.org;
ua-discuss@icann.org; Hollenbeck, Scott <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>
Sent: Friday, November 15, 2024 14:21
To: ua-eai@icann.org;
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>
Датум: 15. 11. 2024. 22:52
Наслов: [EAI] [Errata Verified] RFC6531 (7580)
Коме:
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
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]
--------------------------------------
Status: Verified
Type: Technical
Reported by: Scott Hollenbeck <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
To unsubscribe send an email to ima-leave@ietf.org