Dear all, In attach You can find screenshot that illustrate one UA issue. Dusan --- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://www.avast.com/antivirus
Let's change the discussion from issues, which are just processes, to accomplishments. What can we accomplish in UA, other than fine-tuning UA processes, by the end of the month, thoughts? I guarantee that there will not be a single accomplishment mentioned which is also not a change to a UA process. Give it a whirl folks. Ron
Hi all, they are on our Outreach-List and I just contacted them. Kind regards, Lars -----Ursprüngliche Nachricht----- Von: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] Im Auftrag von Dusan Stojicevic Gesendet: Samstag, 16. Januar 2016 19:58 An: ua-discuss@icann.org Betreff: [UA-discuss] UA issue Dear all, In attach You can find screenshot that illustrate one UA issue. Dusan --- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://www.avast.com/antivirus
Dusan, I'm not sure this is an UA issue. At least, not at face value. I'm not expert, but I would ask: Is the email 'me@michele.irish' a workable email address? I.e. does a MX record exist for Michele.irish and does the mail server approve or reject a query to the recipient address (i.e. 'me')? These online tools: http://www.verifyemailaddress.org/ and http://mailtester.com/testmail.php found that the e-mail address 'me@michele.irish' did not exist or was not responsive at the time of validation, therefore, while the syntax may be correct, 'me@michele.irish' was not a valid mailbox . Of course, I'm making this statement using just two test cases, but you get the idea. Here is the sample response from verifyemailaddres.org: MX record found: siracusa.mneylon.com (Priority 30) Connecting to siracusa.mneylon.com Connected to siracusa.mneylon.com Dialog with siracusa.mneylon.com ok ------------------------------------------------------------ 220 mailserver1.blacknight.ie ESMTP Postfix (Ubuntu) HELO verifyemailaddress.org 250 mailserver1.blacknight.ie MAIL FROM: <noreply@verifyemailaddress.org> 250 2.1.0 Ok RCPT TO: <me@michele.irish> 450 4.7.1 <me@michele.irish>: Recipient address rejected: Policy Rejection- Please try later. QUIT 221 2.0.0 Bye ------------------------------------------------------------ Email address me@michele.irish rejected -Dennis -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Dusan Stojicevic Sent: Saturday, January 16, 2016 1:58 PM To: ua-discuss@icann.org Subject: [UA-discuss] UA issue Dear all, In attach You can find screenshot that illustrate one UA issue. Dusan --- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://www.avast.com/antivirus
On 20 January 2016 at 12:35, Tan Tanaka, Dennis <dtantanaka@verisign.com> wrote:
Dusan, I'm not sure this is an UA issue. At least, not at face value.
I'm not expert, but I would ask: Is the email 'me@michele.irish' a workable email address?
This is not even a fine point that needs to be clear, "working" is not the same as "valid." It's a matter that's been on my mind since the quick guides were offered for comment and the best part of the Validation document was, in my experience and opinion: "1. Don’t validate at all unless it’s required for the operation of the application or service." Since the matter is "acceptance" it should be broadly inclusive, "definitely not invalid" the only filter. The test Dennis conducted (equivalent to sending an email to the address, the empirical method, by doing) is still inconclusive, "Policy Rejection- Please try later." People will accept their own mistakes with more aplomb, than being informed that an address that is working for them, RFC 5322 compliant, is invalid by the login page of a lounge's Wi-Fi capture portal. So I would say this is definitely a UA issue, whether the email address in question works or not, it is valid. Hamish. -- https://www.onename.io/hamishmacewan
Thanks, Dennis, and thanks, Hamish, my opinion is exactly the same. "Valid" is not equal to "working". On the other hand, "working" email, especially in new gtld world, is not always the case of "working properly". Dusan Poslato sa mog Sony Xperia™ pametnog telefona ---- Hamish MacEwan je napisao/la ----
On 20 January 2016 at 12:35, Tan Tanaka, Dennis <dtantanaka@verisign.com> wrote:
Dusan, I'm not sure this is an UA issue. At least, not at face value.
I'm not expert, but I would ask: Is the email 'me@michele.irish' a workable email address?
This is not even a fine point that needs to be clear, "working" is not the same as "valid."
It's a matter that's been on my mind since the quick guides were offered for comment and the best part of the Validation document was, in my experience and opinion:
"1. Don’t validate at all unless it’s required for the operation of the application or service."
Since the matter is "acceptance" it should be broadly inclusive, "definitely not invalid" the only filter.
The test Dennis conducted (equivalent to sending an email to the address, the empirical method, by doing) is still inconclusive, "Policy Rejection- Please try later."
People will accept their own mistakes with more aplomb, than being informed that an address that is working for them, RFC 5322 compliant, is invalid by the login page of a lounge's Wi-Fi capture portal.
So I would say this is definitely a UA issue, whether the email address in question works or not, it is valid.
Hamish. -- https://www.onename.io/hamishmacewan
We have been discussing terminology and taxonomy, this is a good example. I like “well-formed” and “syntactically correct” and “RFC-compliant” to describe strings which we expect UA-Ready applications and services to consume in RFC-compliant ways. I think “valid” is a good way to describe strings which are not only syntactically correct but also in use in the ecosystem. From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Dusan Stojicevic Sent: Tuesday, January 19, 2016 11:32 PM To: ua-discuss@icann.org; Hamish MacEwan <hamish.macewan@gmail.com> Subject: [UA-discuss] ODG: Re: UA issue Thanks, Dennis, and thanks, Hamish, my opinion is exactly the same. "Valid" is not equal to "working". On the other hand, "working" email, especially in new gtld world, is not always the case of "working properly". Dusan Poslato sa mog Sony Xperia™ pametnog telefona ---- Hamish MacEwan je napisao/la ---- On 20 January 2016 at 12:35, Tan Tanaka, Dennis <dtantanaka@verisign.com<mailto:dtantanaka@verisign.com>> wrote:
Dusan, I'm not sure this is an UA issue. At least, not at face value.
I'm not expert, but I would ask: Is the email 'me@michele.irish<mailto:me@michele.irish>' a workable email address?
This is not even a fine point that needs to be clear, "working" is not the same as "valid." It's a matter that's been on my mind since the quick guides were offered for comment and the best part of the Validation document was, in my experience and opinion: "1. Don’t validate at all unless it’s required for the operation of the application or service." Since the matter is "acceptance" it should be broadly inclusive, "definitely not invalid" the only filter. The test Dennis conducted (equivalent to sending an email to the address, the empirical method, by doing) is still inconclusive, "Policy Rejection- Please try later." People will accept their own mistakes with more aplomb, than being informed that an address that is working for them, RFC 5322 compliant, is invalid by the login page of a lounge's Wi-Fi capture portal. So I would say this is definitely a UA issue, whether the email address in question works or not, it is valid. Hamish. -- https://www.onename.io/hamishmacewan<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.onename.io%2fhamishmacewan&data=01%7c01%7cmarksv%40microsoft.com%7c29e7e6e77b2c4eda3c5c08d3216c9d1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ufm24NiuI93sFMQUyLeWNlJbOOq87FLGP7SIWcdyYR0%3d>
On Thu, Jan 21, 2016 at 07:35:38PM +0000, Mark Svancarek wrote:
We have been discussing terminology and taxonomy, this is a good example.
I like “well-formed” and “syntactically correct” and “RFC-compliant” to describe strings which we expect UA-Ready applications and services to consume in RFC-compliant ways.
I think “valid” is a good way to describe strings which are not only syntactically correct but also in use in the ecosystem.
IDNA has the notion of PVALID (or PROTOCOL-VALID) for code points that are definitely allowed, so "valid" might sow confusion. Perhaps "proper"? A -- Andrew Sullivan ajs@anvilwalrusden.com
Good point. But I don't think that "proper" captures the fact that the string is in use and could be expected to return a result... -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, January 21, 2016 2:18 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] ODG: Re: UA issue On Thu, Jan 21, 2016 at 07:35:38PM +0000, Mark Svancarek wrote:
We have been discussing terminology and taxonomy, this is a good example.
I like “well-formed” and “syntactically correct” and “RFC-compliant” to describe strings which we expect UA-Ready applications and services to consume in RFC-compliant ways.
I think “valid” is a good way to describe strings which are not only syntactically correct but also in use in the ecosystem.
IDNA has the notion of PVALID (or PROTOCOL-VALID) for code points that are definitely allowed, so "valid" might sow confusion. Perhaps "proper"? A -- Andrew Sullivan ajs@anvilwalrusden.com
On Fri, Jan 22, 2016 at 12:45:46AM +0000, Mark Svancarek wrote:
Good point. But I don't think that "proper" captures the fact that the string is in use and could be expected to return a result...
Maybe I'm not understanding, then, but is the idea that this is an all-ok-in-protocol string (I'm being coy, because IDNA is defined for labels, for instance) or is it not necessarily that? It's worth noting that IDNA2008's idea of IDN is clear: it has only A-labels, U-labels, or NR-LDH labels. Since every A-label is a U-label and conversely, this boils down to "traditional labels, or IDNA stuff". The _problem_ with that is that some people use "IDN" to mean things outside of IDNA2008, including IDNA2003-compatible names and Unicode-on-the-wire names. The latter two may contain labels that are not U-labels in IDNA2008. So, at least in the case of domain names, I'm trying to understand whether we're talking about subsets of IDNA2008 rules that are actually in use, or things that are actually in use that may not conform to IDNA2008. Thanks, A
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, January 21, 2016 2:18 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] ODG: Re: UA issue
On Thu, Jan 21, 2016 at 07:35:38PM +0000, Mark Svancarek wrote:
We have been discussing terminology and taxonomy, this is a good example.
I like “well-formed” and “syntactically correct” and “RFC-compliant” to describe strings which we expect UA-Ready applications and services to consume in RFC-compliant ways.
I think “valid” is a good way to describe strings which are not only syntactically correct but also in use in the ecosystem.
IDNA has the notion of PVALID (or PROTOCOL-VALID) for code points that are definitely allowed, so "valid" might sow confusion. Perhaps "proper"?
A
-- Andrew Sullivan ajs@anvilwalrusden.com
-- Andrew Sullivan ajs@anvilwalrusden.com
A proposal for discussion purposes only Already in use Not in use Syntactically correct per RFCs and IDNA 2008 Combine any of these: • “in use” ; “active”; “deployed” With any of these: • “Well-formed”; “syntactically correct”; “UA-compliant” Combine any of these: • “unused” ; “inactive”; “undeployed” With any of these: • “Well-formed”; “syntactically correct”; “UA-compliant” other “non-compliant legacy” “invalid” -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, January 21, 2016 4:58 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] ODG: Re: UA issue On Fri, Jan 22, 2016 at 12:45:46AM +0000, Mark Svancarek wrote:
Good point. But I don't think that "proper" captures the fact that the string is in use and could be expected to return a result...
Maybe I'm not understanding, then, but is the idea that this is an all-ok-in-protocol string (I'm being coy, because IDNA is defined for labels, for instance) or is it not necessarily that? It's worth noting that IDNA2008's idea of IDN is clear: it has only A-labels, U-labels, or NR-LDH labels. Since every A-label is a U-label and conversely, this boils down to "traditional labels, or IDNA stuff". The _problem_ with that is that some people use "IDN" to mean things outside of IDNA2008, including IDNA2003-compatible names and Unicode-on-the-wire names. The latter two may contain labels that are not U-labels in IDNA2008. So, at least in the case of domain names, I'm trying to understand whether we're talking about subsets of IDNA2008 rules that are actually in use, or things that are actually in use that may not conform to IDNA2008. Thanks, 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: Thursday, January 21, 2016 2:18 PM
To: ua-discuss@icann.org<mailto:ua-discuss@icann.org>
Subject: Re: [UA-discuss] ODG: Re: UA issue
On Thu, Jan 21, 2016 at 07:35:38PM +0000, Mark Svancarek wrote:
We have been discussing terminology and taxonomy, this is a good example.
I like “well-formed” and “syntactically correct” and “RFC-compliant” to describe strings which we expect UA-Ready applications and services to consume in RFC-compliant ways.
I think “valid” is a good way to describe strings which are not only syntactically correct but also in use in the ecosystem.
IDNA has the notion of PVALID (or PROTOCOL-VALID) for code points that are definitely allowed, so "valid" might sow confusion. Perhaps "proper"?
A
--
Andrew Sullivan
ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>
-- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>
Hi, On Fri, Jan 22, 2016 at 09:29:05PM +0000, Mark Svancarek wrote:
Combine any of these:
• “unused” ; “inactive”; “undeployed”
How would we determine that? There are millions of zones on the Internet, and even if you managed to crawl all the public zones you'd still miss stuff because of internal-to-some-network views. Note that several different uses of the DNS conflict, too. For example, both Active Directory and Apple's Bonjour over wide area (that is, DNS-SD) use labels that are not compatible with IDNA2008. That's a mighty big installed base. To see a discussion of just one of the issues, see https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 A -- Andrew Sullivan ajs@anvilwalrusden.com
I don't think we need to determine which fall into this category a priori, I'm just making sure there are no undefined cells in the matrix. The verbiage would be used as in this example: "Regardless whether validation was performed after the email address was accepted in the UI, a service may need to send a test message to the email address to determine if it is *active* or not, thus avoiding assignment and maintenance of accounts attached to *unused* addresses." -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Friday, January 22, 2016 2:42 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] ODG: Re: UA issue Hi, On Fri, Jan 22, 2016 at 09:29:05PM +0000, Mark Svancarek wrote:
Combine any of these:
• “unused” ; “inactive”; “undeployed”
How would we determine that? There are millions of zones on the Internet, and even if you managed to crawl all the public zones you'd still miss stuff because of internal-to-some-network views. Note that several different uses of the DNS conflict, too. For example, both Active Directory and Apple's Bonjour over wide area (that is, DNS-SD) use labels that are not compatible with IDNA2008. That's a mighty big installed base. To see a discussion of just one of the issues, see https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.... A -- Andrew Sullivan ajs@anvilwalrusden.com
Dear all, Please, find screen-shot with illustration of the Opera's work on UA uri-string was defined as тіанде.укр (tiande) bad visualization in punycode only, resolving ok. -- Yuri mailto:yvk@uanic.info
Dear Yuriy, thanks. This kind of error is similar in Google Chrome and Firefox, when the user's language support and script are set as different than IDN input in location bar. Cheers, Dusan On 20.1.2016 18:34, Yuriy Kargapolov wrote:
Dear all,
Please, find screen-shot with illustration of the Opera's work on UA uri-string was defined as тіанде.укр (tiande) bad visualization in punycode only, resolving ok.
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://www.avast.com/antivirus
Dear Dusan, thanks Is it only one way - to write relevant letter in Opera's address? Does Opera was not aware and ignored as a child IDN questions? :) How many letters must be from us? :) We done. --Yuri Wednesday, January 20, 2016, 10:15:04 PM, you wrote:
Dear Yuriy, thanks.
This kind of error is similar in Google Chrome and Firefox, when the user's language support and script are set as different than IDN input in location bar.
Cheers, Dusan
On 20.1.2016 18:34, Yuriy Kargapolov wrote:
Dear all,
Please, find screen-shot with illustration of the Opera's work on UA uri-string was defined as тіанде.укр (tiande) bad visualization in punycode only, resolving ok.
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://www.avast.com/antivirus
Interesting. Bing knew this was a web site (not a search term). But when Bing launched the website it Punycoded the all the labels including TLD). -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Thursday, January 21, 2016 3:32 AM To: Dusan Stojicevic <dusan@dukes.in.rs>; ua-discuss@icann.org Subject: Re: [UA-discuss] UA issue, Opera browser Dear Dusan, thanks Is it only one way - to write relevant letter in Opera's address? Does Opera was not aware and ignored as a child IDN questions? :) How many letters must be from us? :) We done. --Yuri Wednesday, January 20, 2016, 10:15:04 PM, you wrote:
Dear Yuriy, thanks.
This kind of error is similar in Google Chrome and Firefox, when the user's language support and script are set as different than IDN input in location bar.
Cheers, Dusan
On 20.1.2016 18:34, Yuriy Kargapolov wrote:
Dear all,
Please, find screen-shot with illustration of the Opera's work on UA uri-string was defined as тіанде.укр (tiande) bad visualization in punycode only, resolving ok.
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.a vast.com%2fantivirus&data=01%7c01%7cmarksv%40microsoft.com%7c08f61da6e 27a4a28c1c008d322569a7a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=F uwAGKcYPQURjxfNB4J3CtAhxgBgcA8ZdHjWOXUuMzU%3d
Thanks Mark, Bing really correctly finds web-site тіанде.укр and launching the correct site, visualization the second level in punycode, TLD = .укр, i.e. visualization of the TLD is correct --Yuri Thursday, January 21, 2016, 9:25:33 PM, you wrote:
Interesting. Bing knew this was a web site (not a search term). But when Bing launched the website it Punycoded the all the labels including TLD).
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Thursday, January 21, 2016 3:32 AM To: Dusan Stojicevic <dusan@dukes.in.rs>; ua-discuss@icann.org Subject: Re: [UA-discuss] UA issue, Opera browser
Dear Dusan, thanks
Is it only one way - to write relevant letter in Opera's address? Does Opera was not aware and ignored as a child IDN questions? :) How many letters must be from us? :) We done.
--Yuri
Wednesday, January 20, 2016, 10:15:04 PM, you wrote:
Dear Yuriy, thanks.
This kind of error is similar in Google Chrome and Firefox, when the user's language support and script are set as different than IDN input in location bar.
Cheers, Dusan
On 20.1.2016 18:34, Yuriy Kargapolov wrote:
Dear all,
Please, find screen-shot with illustration of the Opera's work on UA uri-string was defined as тіанде.укр (tiande) bad visualization in punycode only, resolving ok.
--- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.a vast.com%2fantivirus&data=01%7c01%7cmarksv%40microsoft.com%7c08f61da6e 27a4a28c1c008d322569a7a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=F uwAGKcYPQURjxfNB4J3CtAhxgBgcA8ZdHjWOXUuMzU%3d
I have just tested Opera on OSX and it correctly shows the Unicode form тіанде.укр in the address bar. Please see attached screen shot André Schappo [cid:754A7B3F-1673-4E8B-A3DE-6140B85E371D] On 20 Jan 2016, at 17:34, Yuriy Kargapolov wrote: Dear all, Please, find screen-shot with illustration of the Opera's work on UA uri-string was defined as тіанде.укр (tiande) bad visualization in punycode only, resolving ok. -- Yuri mailto:yvk@uanic.info<Opera-UA-w-idn.jpg>
Hello All, 1.OSX Safari Version 6.2.8 (8537.85.17.9.1) changes string тіанде.укр to http://xn--80aid4ax4j.xn--j1amh right after you push enter after copy pasting the URL formally it works, but not very human readable 2.OSX Chrome Version 47.0.2526.111 (64-bit) changes тіанде.укр visually to http://xn--80aid4ax4j.укр , but if you copy the text via CTRL-C it turns to be in the clipboard -> http://xn--80aid4ax4j.xn--j1amh/ P.s: and OSX Opera allows you to copy paste http://тіанде.укр/ without alterations. Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID m. +7 916 6761580 skype oldfrogger Current UTC offset: +3.00 (Moscow) On Jan 22, 2016, at 12:56 , Andre Schappo <A.Schappo@lboro.ac.uk> wrote:
I have just tested Opera on OSX and it correctly shows the Unicode form тіанде.укр in the address bar. Please see attached screen shot
André Schappo
On 20 Jan 2016, at 17:34, Yuriy Kargapolov wrote:
Dear all,
Please, find screen-shot with illustration of the Opera's work on UA uri-string was defined as тіанде.укр (tiande) bad visualization in punycode only, resolving ok. --
Yuri mailto:yvk@uanic.info<Opera-UA-w-idn.jpg>
On Jan 22, 2016, at 2:41 AM, Maxim Alzoba <m.alzoba@gmail.com> wrote:
1.OSX Safari Version 6.2.8 (8537.85.17.9.1) changes string тіанде.укр <http://xn--80aid4ax4j.xn--j1amh/> to http://xn--80aid4ax4j.xn--j1amh <http://xn--80aid4ax4j.xn--j1amh/> right after you push enter after copy pasting the URL
formally it works, but not very human readable
Maxim, It’s entirely likely older versions of Safari had this issue. The latest version of Safari is version 9.1 and it does NOT change the string тіанде.укр to punnycode after pasting the URL. -- Eric Zelenka Worldwide Product Marketing Apple Inc.
participants (11)
-
Andre Schappo -
Andrew Sullivan -
Dusan Stojicevic -
Eric Zelenka -
Hamish MacEwan -
Lars Steffen -
Mark Svancarek -
Maxim Alzoba -
Ron Baione -
Tan Tanaka, Dennis -
Yuriy Kargapolov