If we are trying to encourage adoption, I’d avoid terms such as “simple and efficient” as those (understandably) scare many IT administrators as being too “black box” and marketing-oriented.
I think the concept that you are trying to convey is that “Punycode is a two-way encoding/decoding algorithm; if the message travels through a mail system that only understands ASCII, the original EAI can be restored from the Punycode representation.”
From: Jiankang Yao [mailto:yaojk@cnnic.cn]
Sent: Monday, January 23, 2017 8:34 PM
To: Don Hollander <don.hollander@icann.org>; Stuart Stuple <stuartst@exchange.microsoft.com>
Cc: Mark Svancarek <marksv@microsoft.com>; ua-eai@icann.org
Subject: Re: Re: [UA-EAI] [Ext] RE: [UA-Coordination] Revised UASG013 - Quick Guide to EAI
or we may just use the definition in the abstract of rfc3492,
Punycode is a simple and efficient transfer encoding syntax designed
for use with Internationalized Domain Names in Applications (IDNA).
Subject: Re: [UA-EAI] [Ext] RE: [UA-Coordination] Revised
UASG013 - Quick Guide to EAI
That it can convert from IDN to Punycode and from Punycode to IDN - that’s what we mean by bi-directional.
I would welcome suggestions for a better phrasing.
What is meant by “bi-directional” in this context? I think you mean “can handle bi-directional domain names”. ASCII characters are inherently Left-to-right and hence never bidirectional.
Good catch. The ACE prefix indicates to a parser that the following string is the Punycoded transformation of an IDNA-compatible Unicode string, but is not actually a part
of that transformation.
"Punycode is an algorithm that converts an IDN into an ASCII string that starts with xn--. The Punycode
algorithm is bi-directional. " needs some adjustment.
where "xn--" is a prefix and "abcdeddaa" is output of the Punycode algorithm. So Punycode output does not include "xn--".
======================================following are texts from RFC5890===============================
" the string following "xn--" must be the valid output of the Punycode algorithm
and must be convertible into valid U-label form."
Subject: [UA-Coordination]
Revised UASG013 - Quick Guide to EAI
Last month I sent out a formatted Quick Guide to EAI.
This resulted in a number of comments from Ajay, Stuart, Mark, Lars & Dennis.
These enhancements were mostly focused on the Email Service Provider.
I have revised the source document which is attached.
And for reference, I’m also including the formatted earlier draft.
Could I please get any final comments by the end of this week (25th)?
Universal Acceptance Steering Group
Don Hollander
Universal Acceptance Steering Group