November 2024 - UA-discuss

Fwd: [wsis20] GP Digital insights into WSIS+20
by anil Jain Nov. 21, 2024

Nov. 21, 2024

Dear all, Following information on GDC and WSIS+20 may be useful to you. Thanks, Anil Kumar Jain Sent from my iPad Begin forwarded message: > From: Jordan Carter via wsis20 <wsis20(a)icann.org> > Date: 21 November 2024 at 4:45:32 AM IST > To: ICANN wsis20 <wsis20(a)icann.org> > Subject: [wsis20] GP Digital insights into WSIS+20 > Reply-To: Jordan Carter <jordan.carter(a)auda.org.au> > > > Hi all, hope those of you travelling back from ICANN had a good trip. > > An excellent analysis from GP Digital about the WSIS+20 substance and process came into my inbox and it’s worth a read: > > https://www.gp-digital.org/everything-you-need-to-know-about-the-wsis20-rev… > > They have also published a nice calendar of what is happening when: > > https://www.gp-digital.org/digital-technology-governance-calendar/ > > cheers > Jordan > > _______________________________________________ > > > Learn more about the WSIS+20 Outreach Network and review relevant resources: https://go.icann.org/wsis20 > > Read the public archives for this mailing list: https://mm.icann.org/pipermail/wsis20/ > > _______________________________________________ > By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

1 0

Re: [UA-EAI] Re: [EXTERNAL] RE: Fwd: [EAI] [Errata Verified] RFC6531 (7580)
by Arnt Gulbrandsen Nov. 19, 2024

Nov. 19, 2024

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

2 2

Re: [EXTERNAL] RE: Fwd: [EAI] [Errata Verified] RFC6531 (7580)
by Mark Svancarek (CELA) Nov. 18, 2024

Nov. 18, 2024

That’s what I thought. I’m curious, what inspired you to review this in the year 2024? From: Hollenbeck, Scott <shollenbeck(a)verisign.com> Sent: Monday, November 18, 2024 5:41 AM To: Mark Svancarek (CELA) <marksv(a)microsoft.com>; dusan(a)dukes.in.rs; ua-eai(a)icann.org; ua-discuss(a)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(a)microsoft.com<mailto:marksv@microsoft.com>> Sent: Friday, November 15, 2024 6:14 PM To: Душан Стојичевић <dusan(a)dukes.in.rs<mailto:dusan@dukes.in.rs>>; ua-eai(a)icann.org<mailto:ua-eai@icann.org>; ua-discuss(a)icann.org<mailto:ua-discuss@icann.org>; Hollenbeck, Scott <shollenbeck(a)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(a)icann.org<mailto:ua-discuss@icann.org>> Sent: Friday, November 15, 2024 14:21 To: ua-eai(a)icann.org<mailto:ua-eai@icann.org>; ua-discuss(a)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(a)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<https://secure-web.cisco.com/1c36W4TyCnZMPETfveBdGnpSZI3eQnmHuvcuQ2X6ma4qHD…> -------------------------------------- Status: Verified Type: Technical Reported by: Scott Hollenbeck <shollenbeck(a)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(a)ietf.org<mailto:ima@ietf.org> To unsubscribe send an email to ima-leave(a)ietf.org<mailto:ima-leave@ietf.org>

1 0

Fwd: [EAI] [Errata Verified] RFC6531 (7580)
by Душан Стојичевић Nov. 15, 2024

Nov. 15, 2024

2 1

FW: ICANN81: UA Strategy Capacity Building Initiatives
by Seda Akbulut Nov. 10, 2024

Nov. 10, 2024

Dear all, You are cordially invited to join the “ICANN81: UA Strategy Capacity Building Initiatives” session on Monday 11 November at 10:45 am local time (or 7:45 am UTC). Session link: https://icann81.sched.com/event/1p2Cn/ua-strategy-capacity-building-initiat… Location: B2 Floor Beylerbeyi (Secondary Ballroom) Slide deck: https://static.sched.com/hosted_files/icann81/05/UA%20Strategy_Capacity%20B… Best regards Seda

1 0

UASG-Newcomers session today at 7:30 UTC
by Seda Akbulut Nov. 10, 2024

Nov. 10, 2024

Hello all, You are cordially invited to join UASG session with the Newcomers at ICANN81 today at 7:30 am UTC. Sunday, 10 Nov 2024 10:30 - 12:00 local time Uskudar (Primary Ballroom) Get to Know ICANN Community: IPC, ISPCP and UASG<https://icann81.sched.com/event/1p2DJ/get-to-know-icann-community-ipc-ispcp…> (11:00 - 11:30 for UASG local time) FYI Kind regards, Seda Akbulut

1 0

idnforums is back
by André Schappo Nov. 8, 2024

Nov. 8, 2024

After a long absence, https://www.idnforums.com <https://www.idnforums.com/> is back. It is full of the trials and tribulations of IDNs 🙂, functioning IDNs and stories about IDNs. André

3 2

Re: [EXTERNAL] Transparency of Coordination WG and process [was: Re: UASG working at a glance]
by Nitin Walia Nov. 3, 2024

Nov. 3, 2024

Dear Mark, Thank you for sharing this background&mdashit certainly provides valuable insight into the evolution of the coordination group within UASG. Understanding the initial intent and how it has transformed over time highlights both the flexibility and challenges in managing cross-WG activities . It&rsquos clear that the original ad hoc coordination served a practical need for streamlining efforts between WGs. Over time, though, the shift toward a more structured recurring group may indeed warrant further discussion, especially if it`s now acting beyond its original ad hoc purpose and without a formal charter and purpose . I appreciate the openness in sharing this context, and I look forward to any discussions on how UASG might align structure more closely with our chartered objectives to ensure effective and cohesive collaboration across our initiatives . Thanks Warm Regards Nitin Walia | DirectorData Ingenious Global LimitedTel: +91-141-2554970Fax: +91-141-2554972LinkedIn Twitternitin(a)data.in | नितिन(a)xn--c2bd1gb.xn--h2brj9c | https://data.inCelebrating 25 Years of Innovation and ExcellenceVC: https://bridge01.videomeet.in - room: nitin pwd: 10000Get email id like me in your own language, download DATAMAIL app from your iOS or android play store. भाषाकीआजादी - Bridging the Digital Divide, Getting Next billion online From: "Mark Svancarek (CELA) via UA-discuss" MailId : [144422844]To: Jim DeLaHunt ,"ua-discuss(a)icann.org" Subject: [UA-discuss] Re: [EXTERNAL] Transparency of Coordination WG and process [was: Re: UASG working at a glance]Date: 29 Oct 2024 05:06:58 AM History lesson: Some time (maybe two years) after UASG was chartered, leadership noticed that some WG activities were unaligned with each other. An ad hoc coordination group was suggested, solely for the purpose of coordinating cross-WG activities. As a very lazy WG chair, I found it easier to just ask the ICANN staff person assigned to EAI to manage any coordination tasks we identified. That&rsquos why I never noticed or commented on the fact that it had somehow mutated from an ad hoc thing to a large recurring group, meeting regularly and acting without charter . From: Jim DeLaHunt via UA-discuss Sent: Monday, October 28, 2024 3:19 PM To: ua-discuss(a)icann.org Subject: [EXTERNAL] [UA-discuss] Transparency of Coordination WG and process [was: Re: UASG working at a glance] Anil Jain: I appreciate the recent updates on UASG management activity. It is better to get these reports than to hear nothing . It does lead to two questions, however: On 2024-10-28 14:26, anil Jain via UA-discuss wrote: UASG Oct 2024 &hellipIn continuation with my earlier emails to community, let me remind that We have taken special steps In following areas.&hellip &hellip 5. Several Governance Issuse were reported to us. We had long discussions on all Governance issues which were being discusssed since 2017, decided and submitted. We will re submit these outcomes with Coordination WG once we finalised &ldquo Decision Making process&rdquo for Coordination Working Group.&hellip 6. It was reported to us that we have to frame norms for UASG members to strictly follow ICANN Standard Behaviour. We discussed and finalised the same. Submitted to ICANN Org to get legal wetting before final implementations. 7. As coordination WG is expected to take major decisions as per provisions under UASG Charter,We decided to draft &ldquo Decison Making Process&rdquo within Coordination Working Group. We discusssed all aspects of decision making , consensus, raising concerns, reporting not consideration of points raised etc,finalised the same and submitted to ICANN org for legal wetting and also to ensure that it meet expectations of ICANN at large. On 7th Oct,2024, Coordination WG had discussions with Ms Theresa, Sr VP ICANN, &hellip Clearly the Coordination WG is becoming more and more dominant in the actions of the UASG. I think it is time for some transparency on what the Coordination WG is, who participates in it, and what they do. Is the name "Coordination Working Group" even appropriate still, since the scope seems more like a "Management Committee"? On the UASG`s website, under UASG Structure and Groups , there is no mention of the Coordination WG. That page does say, "For detailed description of the UASG Working Groups, please refer to: UASG Structure and Groups." But the page linked to is . The scope of that page is limited to genuine working groups . Could we please have the Coordination WG publish its structure, charter, and minutes of meetings at least as transparently as those of the genuine working groups? Also, in your comments, you frequently use the term "we" as if it is separate from the Coordination WG, and separate from the regular participants of UASG. Who is this "we"? Is it just the UASG chair? Or the UASG chair and the lead ICANN staff person supporting U ASG? It would be good to be transparent about that also, because that "we" seems to be playing an increasingly active role also. Or, am I misreading the message, and in fact "we" consistently refers to the Coordination WG? Best regards, &mdashJim DeLaHunt, Vancouver, Canada (participant in UA-EAI, UA-Tech, and UA-Measurement WGs) -- --Jim DeLaHunt, jdlh(a)jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant, Vancouver, Canada _______________________________________________UA-discuss mailing list -- ua-discuss(a)icann.orgTo unsubscribe send an email to ua-discuss-leave(a)icann.org_______________________________________________By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.Do not Remove:[HID]20241029050658421[-HID] [XGENFOOTER] [-XGENFOOTER]

4 3

Tarek Kamel Fellowship
by anil Jain Nov. 1, 2024

Nov. 1, 2024

Dear fellow UASG members, This is a great news, The Fellowship Program Selection Committee has chosen returning Fellow Raymond Selorm Mamattah, from Ghana, as the recipient of the Tarek Kamel Fellowship Recognition<https://www.icann.org/resources/pages/tarek-kamel-fellowship-recognition-aw…> Award for ICANN82. We at UASG are honoured to have such an outstanding person in UASG team. I am honoured to work with Raymond as Vice Chair of Communication WG in UASG. Thank You ICANN in correctly choosing Raymond,who not only truly deserves the honour but inspire millions netizens. Thanks, Anil Kumar Jain Sent from my iPhone

3 2