Further to the face-to-face meeting of the UASG Coordination group in January, the charter has been reviewed some fundamental changes are proposed. Instead of having a community of volunteers supported by a professional body, we’re proposing shifting to a professional body supported by volunteers. The UASG Coordination group will shift more toward governance than operation, though volunteers are still very highly encouraged. Please find attached a red-lined revision to the Charter. Your comments would be welcome through the 22nd of February. Don
I agree with the comment in the doc that "IDN email" isn't a thing. "Email using EAI" or "Email using address internationalization" or just "EAI" are correct. Otherwise, no comment. A On Tue, Feb 16, 2016 at 03:43:21AM +0000, Don Hollander wrote:
Further to the face-to-face meeting of the UASG Coordination group in January, the charter has been reviewed some fundamental changes are proposed.
Instead of having a community of volunteers supported by a professional body, we’re proposing shifting to a professional body supported by volunteers. The UASG Coordination group will shift more toward governance than operation, though volunteers are still very highly encouraged.
Please find attached a red-lined revision to the Charter.
Your comments would be welcome through the 22nd of February.
Don
-- Andrew Sullivan ajs@anvilwalrusden.com
I still think it's important to distinguish between EAI and addresses in "local@punycode" formats, since many email clients treat those different in various scenarios. What would you call that format? -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Monday, February 15, 2016 8:01 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] Review of UASG Charter I agree with the comment in the doc that "IDN email" isn't a thing. "Email using EAI" or "Email using address internationalization" or just "EAI" are correct. Otherwise, no comment. A On Tue, Feb 16, 2016 at 03:43:21AM +0000, Don Hollander wrote:
Further to the face-to-face meeting of the UASG Coordination group in January, the charter has been reviewed some fundamental changes are proposed.
Instead of having a community of volunteers supported by a professional body, we’re proposing shifting to a professional body supported by volunteers. The UASG Coordination group will shift more toward governance than operation, though volunteers are still very highly encouraged.
Please find attached a red-lined revision to the Charter.
Your comments would be welcome through the 22nd of February.
Don
-- Andrew Sullivan ajs@anvilwalrusden.com
On Wed, Feb 17, 2016 at 11:32:19PM +0000, Mark Svancarek wrote:
I still think it's important to distinguish between EAI and addresses in "local@punycode" formats, since many email clients treat those different in various scenarios. What would you call that format?
"Email address"? I'm not quite sure what you mean by "local@" above, so two possible interpretations: An address of the form [utf-8]@xn--something is just user-hostile. In order for the local-part to be in utf-8, the EAI extensions need to be in place anyway; otherwise it won't work. So refusing to handle the IDNA server-part portion is really just poor implementation (a polite way of saying "broken" ;-)). If you mean the case where you have a non-EAI localpart with a server-part that has at least one A-label, well, that's just old-fashioned email. It's certainly true that the target server name is mystifying. That is frustrating, but basically it's just an IDNA-unaware client. We designed IDNA the way we did precisely because there are so many clients out there that couldn't accept anything but LDH in a domain name slot (thats what the server-part is -- see RFC 5890). There are also clients -- the version of mutt I'm sending this mail with, IIRC -- that have IDNA-awareness compiled in, and they can display the server part as IDNA U-labels as opposed to A-labels. So if I registered crânkycanuck.ca (which under CIRA's rules I think I could), you could send me mail at ajs@xn--crnkycanuck-x7a.ca and (assuming I configured my MTA to take it) I'd see ajs@crânkycanuck.ca. _This_ use case is definitely different to EAI, because the SMTP extensions aren't needed. But it's just ordinary IDNA, I think -- all the transformations have to happen in the client at display time. I suppose there's an issue in that such a client might try EAI when it attempts to send mail, and get a failure. Best regards, A
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Monday, February 15, 2016 8:01 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] Review of UASG Charter
I agree with the comment in the doc that "IDN email" isn't a thing. "Email using EAI" or "Email using address internationalization" or just "EAI" are correct.
Otherwise, no comment.
A
On Tue, Feb 16, 2016 at 03:43:21AM +0000, Don Hollander wrote:
Further to the face-to-face meeting of the UASG Coordination group in January, the charter has been reviewed some fundamental changes are proposed.
Instead of having a community of volunteers supported by a professional body, we’re proposing shifting to a professional body supported by volunteers. The UASG Coordination group will shift more toward governance than operation, though volunteers are still very highly encouraged.
Please find attached a red-lined revision to the Charter.
Your comments would be welcome through the 22nd of February.
Don
-- Andrew Sullivan ajs@anvilwalrusden.com
-- Andrew Sullivan ajs@anvilwalrusden.com
I refer to ASCII@xn--something Here’s an example: 1. I send an email to a pair of recipients: A-label@U-label and ASCII@ASCII. a. (The former is EAI and the latter is non-EAI). 2. Let’s assume that ASCII@ASCII is using the default email client on an iPhone. 3. Both recipients Reply All. 4. The iPhone email app does not reply to A-label@U-label – it replies to A-label@xn--something. That just happens to be how that app is currently designed. a. Now my mailbox contains 2 replies. The reply from the EAI user is to the same addresses that I originally used. The reply from the iPhone user contains a different address than I used. 5. These addresses may be searched and sorted in my mailbox differently. That depends on how my mailbox app is coded. a. AFAIK there is no requirement that these addresses be treated as equivalent. Email is not DNS. 6. In fact, one of these formats does not even have a name, which means that discussing this scenario requires the use of new terminology. I’ve been calling this format “IDN email”. Does that make sense. -----Original Message----- From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] Sent: Wednesday, February 17, 2016 6:46 PM To: Mark Svancarek Cc: ua-discuss@icann.org Subject: Re: [UA-discuss] Review of UASG Charter On Wed, Feb 17, 2016 at 11:32:19PM +0000, Mark Svancarek wrote:
I still think it's important to distinguish between EAI and addresses in "local@punycode" formats, since many email clients treat those different in various scenarios. What would you call that format?
"Email address"? I'm not quite sure what you mean by "local@" above, so two possible interpretations: An address of the form [utf-8]@xn--something is just user-hostile. In order for the local-part to be in utf-8, the EAI extensions need to be in place anyway; otherwise it won't work. So refusing to handle the IDNA server-part portion is really just poor implementation (a polite way of saying "broken" ;-)). If you mean the case where you have a non-EAI localpart with a server-part that has at least one A-label, well, that's just old-fashioned email. It's certainly true that the target server name is mystifying. That is frustrating, but basically it's just an IDNA-unaware client. We designed IDNA the way we did precisely because there are so many clients out there that couldn't accept anything but LDH in a domain name slot (thats what the server-part is -- see RFC 5890). There are also clients -- the version of mutt I'm sending this mail with, IIRC -- that have IDNA-awareness compiled in, and they can display the server part as IDNA U-labels as opposed to A-labels. So if I registered crânkycanuck.ca (which under CIRA's rules I think I could), you could send me mail at ajs@xn--crnkycanuck-x7a.ca<mailto:ajs@xn--crnkycanuck-x7a.ca> and (assuming I configured my MTA to take it) I'd see ajs@crânkycanuck.ca<mailto:ajs@crânkycanuck.ca>. _This_ use case is definitely different to EAI, because the SMTP extensions aren't needed. But it's just ordinary IDNA, I think -- all the transformations have to happen in the client at display time. I suppose there's an issue in that such a client might try EAI when it attempts to send mail, and get a failure. Best regards, A
-----Original Message-----
From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>
[mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan
Sent: Monday, February 15, 2016 8:01 PM
To: ua-discuss@icann.org<mailto:ua-discuss@icann.org>
Subject: Re: [UA-discuss] Review of UASG Charter
I agree with the comment in the doc that "IDN email" isn't a thing.
"Email using EAI" or "Email using address internationalization" or just "EAI" are correct.
Otherwise, no comment.
A
On Tue, Feb 16, 2016 at 03:43:21AM +0000, Don Hollander wrote:
Further to the face-to-face meeting of the UASG Coordination group in January, the charter has been reviewed some fundamental changes are proposed.
Instead of having a community of volunteers supported by a professional body, we’re proposing shifting to a professional body supported by volunteers. The UASG Coordination group will shift more toward governance than operation, though volunteers are still very highly encouraged.
Please find attached a red-lined revision to the Charter.
Your comments would be welcome through the 22nd of February.
Don
--
Andrew Sullivan
ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>
-- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>
On Thu, Feb 18, 2016 at 08:00:51PM +0000, Mark Svancarek wrote:
I refer to ASCII@xn--something
Got it.
1. I send an email to a pair of recipients: A-label@U-label and ASCII@ASCII.
a. (The former is EAI and the latter is non-EAI).
Sorry to be a pain, but one of the things that has hurt us in i18n discussions is terminology. So, I want to say that differently. Let's lay this out carefully. Your MUA supports EAI. Your MTA supports EAI. You compose mail: To: ascii-local-part-1@IDN-as-U-labels, ascii-local-part-2@LDH-only-labels
4. The iPhone email app does not reply to A-label@U-label – it replies to A-label@xn--something. That just happens to be how that app is currently designed.
This, of course, is because the app doesn't support i18n in the headers at all, right?
a. Now my mailbox contains 2 replies. The reply from the EAI user is to the same addresses that I originally used. The reply from the iPhone user contains a different address than I used.
Is that true? Your system, under hypothesis, supports EAI. Didn't your system convert the A-label in the server-part to a U-label? Why not? (There may be a gap in the EAI protocol here; I'm not sure.)
a. AFAIK there is no requirement that these addresses be treated as equivalent. Email is not DNS.
But the server-part in an EAI address is an IDNA-conformant IDN, or else a non-IDN. Since every A-label has exactly one U-label and conversely, why isn't the application catching the equivalence? It already does IDNA. A -- Andrew Sullivan ajs@anvilwalrusden.com
This is the crux of the problem. Since every A-label has exactly one U-label and conversely, why isn't the application catching the equivalence The app doesn't catch the equivalence simply because it never had to do so in the past, and because the mail store/db, the transport, and the search/sort function are likely in different teams working on code bases of different provenance and different update cadence. Just plain old software development snafus of the sort routinely encountered in UA. -----Original Message----- From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] Sent: Thursday, February 18, 2016 12:16 PM To: Mark Svancarek Cc: ua-discuss@icann.org Subject: Re: [UA-discuss] Review of UASG Charter On Thu, Feb 18, 2016 at 08:00:51PM +0000, Mark Svancarek wrote:
I refer to ASCII@xn--something
Got it.
1. I send an email to a pair of recipients: A-label@U-label and ASCII@ASCII.
a. (The former is EAI and the latter is non-EAI).
Sorry to be a pain, but one of the things that has hurt us in i18n discussions is terminology. So, I want to say that differently. Let's lay this out carefully. Your MUA supports EAI. Your MTA supports EAI. You compose mail: To: ascii-local-part-1@IDN-as-U-labels, ascii-local-part-2@LDH-only-labels
4. The iPhone email app does not reply to A-label@U-label – it replies to A-label@xn--something. That just happens to be how that app is currently designed.
This, of course, is because the app doesn't support i18n in the headers at all, right?
a. Now my mailbox contains 2 replies. The reply from the EAI user is to the same addresses that I originally used. The reply from the iPhone user contains a different address than I used.
Is that true? Your system, under hypothesis, supports EAI. Didn't your system convert the A-label in the server-part to a U-label? Why not? (There may be a gap in the EAI protocol here; I'm not sure.)
a. AFAIK there is no requirement that these addresses be treated as equivalent. Email is not DNS.
But the server-part in an EAI address is an IDNA-conformant IDN, or else a non-IDN. Since every A-label has exactly one U-label and conversely, why isn't the application catching the equivalence? It already does IDNA. A -- Andrew Sullivan ajs@anvilwalrusden.com
On Thu, Feb 18, 2016 at 09:38:04PM +0000, Mark Svancarek wrote:
The app doesn't catch the equivalence simply because it never had to do so in the past
Well, wait: it _does_ have to now, because _ex hypothesi_ it's EAI-aware or at least IDNA-aware. Otherwise, you'd never have been able to send the mail in the first place, I think. No? That is, the whole chain starts when someone sends a mail with ascii-local-part@name-with-U-label If you get back an answer that cc:s ascii-local-part@name-with-A-label your software already knows how to do IDNA, because it coped with the U-label in the first place. No? A -- Andrew Sullivan ajs@anvilwalrusden.com
MUA doesn't necessarily need to understand IDNA since that's being handled by MTA. It just needs to handle UTF8 in general. Also, keep in mind again that these are usually separate features prioritized and maintained by separate teams - so specific end-to-end behavior that one might logically expect isn't always going to be reality. Hence the need for UASG. -----Original Message----- From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] Sent: Thursday, February 18, 2016 3:08 PM To: Mark Svancarek Cc: ua-discuss@icann.org Subject: Re: [UA-discuss] Review of UASG Charter On Thu, Feb 18, 2016 at 09:38:04PM +0000, Mark Svancarek wrote:
The app doesn't catch the equivalence simply because it never had to do so in the past
Well, wait: it _does_ have to now, because _ex hypothesi_ it's EAI-aware or at least IDNA-aware. Otherwise, you'd never have been able to send the mail in the first place, I think. No? That is, the whole chain starts when someone sends a mail with ascii-local-part@name-with-U-label If you get back an answer that cc:s ascii-local-part@name-with-A-label your software already knows how to do IDNA, because it coped with the U-label in the first place. No? A -- Andrew Sullivan ajs@anvilwalrusden.com
On Thu, Feb 18, 2016 at 11:28:22PM +0000, Mark Svancarek wrote:
MUA doesn't necessarily need to understand IDNA since that's being handled by MTA. It just needs to handle UTF8 in general.
I really think we're passing over important details then. Either the MUA does IDNA, or it does not. If it does, we have no problem. If it does not, then the upstream server does EAI, and upgrades? A -- Andrew Sullivan ajs@anvilwalrusden.com
This email is written in support of the rights of employees of the american tech industry: After forcing all American citizens to purchase a product, health insurance, the U.S. government is looking to force employees of a private company, Apple, to perform a specific task in the creation of a new product, in this instance, to create new code which would then allow the government to bypass Iphone security protections, according to the article at the following website: http://www.thedailybeast.com/articles/2016/02/17/apple-unlocked-iphones-for-... The U.S. government can legally ask companies to comply with existing regulations, but a government agent forcing individual employees of a private company to perform a specific task, effectively forcing the employee to choose between retaining their job and creating the new product for the government, is simply the next step down the slippery slope. Americans are in the "forced actions phase" of this oligarchy. Internet policy groups and all internet governance groups should at least consider that when the heath insurance mandate was accepted, people wondered what would be the next mandate, would a future president take advantage of the trend towards mandating citizens to act? If apple's employees are forced to comply with a forced action, that in my opinion is no different than Apple having been nationalized by the U.S. government, in my opinion. What's next? The argument is much bigger than phones. U.S. government agents could order any private company employee in the entire country to perform any task the government deemed necessary. If a future government agent deemed that it was immediately necessary for a future apple employee to shine the shoes of the government agent, then they could refer back to the forced creation of code and ask, what's the difference? Oligarchy is about gaining the obedience of its citizens to the state via brutality (see broken windows police theory argument on gaining obedience) and via the provision of lose-lose choices that pit a citizen against his or her own ability to economically support himself or herself. Any male government agent forcing or pressuring a female private employee at apple to perform a specific action would also be violating women's Civil Rights law, same can be said for race etc., civil rights law exist for a reason in the american workplace. Oligarchy is government by hypocritical political criminals and their stooges, and internet governance groups should call it out for what it is and speak out against the american oligarchy on behalf of the U.S. tech industry which employs citizens from all countries. Ron
Jeremy, Thank you for your reply: I would also like to add that regardless of whether or not Apple employees, of a private company, are ever forced to perform any action for a government agent, they are already victims of attempted enslavement by the U.S. government. The reason why Josh Earnest stated publicly that the White House is not demanding that Apple build anything new for the government, is because Josh Earnest knows that any such demand if it occurred was a criminal act, and Josh Earnest wants to distance himself and the President from that attempted enslavement of Apple's employees which in fact already occurred by the time Josh Earnest spoke. Beginning with the Emancipation Proclamation, Enslavement of American citizens has been unconstitutional for well over a century in the United States, and anyone who has participated in the attempted enslavement of Apple employees in this instance is a criminal-at-large at this time, in my opinion which I believe is consistent with the U.S. Codes as I understand them, as enslavement is unlawful as stated in the U.S. Codes. I ask the internet community to speak out against the attempted enslavement of Apple's employees by the criminal participants in that attempted crime, and for the relevant law enforecement entities to arrest all those who have participated in the attempted enslavement of Apple's employees. Barack Obama, as a direct participant in the attempted enslavement of Apples Employees, should be impeached by the U.S. Congress immediately for his administrations support of that unlawful action of attempted enslavement. Any DOJ employee who has already acted as a participant in the attempted enslavement of Apple employees who are American citizens should be charged with treason and deported. As members of the law enforcement community who know or should know the laws against enslavement in the United States, those participants therefore willfully and knowingly committed the crime of attempted enslavement, and are in the process of committing that crime until such demand is withdrawn. Even if the participating DOJ and FBI do withdraw their demand to enslave Apple employees, that should not absolve those who have already participated as criminals committing the crime of attempted enslavement from being prosecuted to the fullest extent of the law, so as to set an example to all Americans that the human rights crimes of slavery and attempted slavery will not again be tolerated in the United States. Anything less than prosecutions and deportations of all the DOJ/FBI participants for their attempted enslavement of Apple's employees will allow, at the very least, for the future opportunity of a reversal of the humane and civilized precedent against slavery established by Abraham Lincoln. Ron
participants (4)
-
Andrew Sullivan -
Don Hollander -
Mark Svancarek -
Ron Baione