Thanks Mark/Ajay

 

So we now have several edit requests and two weeks of space since we looked at this document intently.

 

  1. The sense of the diagram as outlined below
  2. The definition of Variant that Ajay noted
  3. The examples used in IMAP that Ajay noted.
  4. Some potential additional entries to the Glossary.

 

Are there any others that people want to submit?

 

Don

-------

 

 

Ajay’s note:

Few points.. 

In Glossary: We may consider to -

Add:
Alias (In this document, we are calling this as "substitute ASCII address")
Downgrading
LGR
IDN

Change:
Variant characters: "Characters in a script with the same meaning but different visual representations", does not seem to explain correctly. we need to rewrite by considering the following. 

Recommended by Sarmad on 10th April:  
--------------------
Please either use “variant label” or “variant code point” to clarify which level you are talking about.  Using “variant” is ambiguous as it can mean either a label or a code point.  This practice is being recommended by the IDN Guidelines WG in their recent revision of the IDN Guidelines.

So that could be visually identical?  - YES variants – though identical is hard to define

Or confusingly similar? – NO, not variants – unless considered variants for some other reason by the community

Or the same semantic meaning? – Yes for Chinese, but could be considered non-variants for other scripts
-----------------------

IMAP: Internet Message Access Protocol, a standard for managing mail messages and folders on remote servers. The current version is IMAP4. Compare to POP.

The domain name used receive.net / sender.org in examples may require attention as I found that receive.net is resolving to 69.172.201.153 [mxtoolbox.com] . May be we can have receive.uasg.tech and send.uasg.tech or something else . 


 

From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of Mark Svancarek via UA-EAI
Sent: Friday, 22 June 2018 3:38 AM
To: ua-eai@icann.org
Subject: [UA-EAI] Edit request for UASG-012

 

Unfortunately, I have a request for edit.  Sorry I didn’t catch this sooner.

 

On page 14, we have this diagram, which implies that legacy-to-legacy email is broken:

 

I think it should be revised to: