http://blog.gmane.org/gmane.ietf.idnabis hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.idnabis/7447 <pre>http://annevankesteren.nl/2012/11/idna-hell </pre> Paul Hoffman 2012-11-28T03:28:44 http://comments.gmane.org/gmane.ietf.idnabis/7385 <pre>Dear all, I had this small discussion with Mark and Markus and, despite our treefold homonymy, we couldn't get to common ground, so I've decided to get a reading of the standard directly from the IDNA2008 editors. According to my interpretation (cf. RFC 5891, Section 5) the lookup protocol relies on the assumption that names that are already present in the DNS are valid. And, in fact, I have a bunch of domains in my database with hyphens in the third and fourth position, so-called reserved LDH labels that are not XN-labels (s. nomenclature in RFC 5890, Section 2.3.2.1). Take for instance "ad--acta.de". My expectation would be that the protocol doesn't fail on those*. Mark however reminded me of the restrictions in RFC 5891, Section 4.2.3.1. But those are for the registration, which I am not interested in at the moment. If at all relevant, we'd have Section 5.4: "Putative U-labels with any of the following characteristics MUST be rejected prior to DNS lookup: [·..] o Labels containing '--' (</pre> Marcos Sanz 2012-11-06T15:43:02 http://comments.gmane.org/gmane.ietf.idnabis/7371 <pre> The following errata report has been submitted for RFC5892, "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5892&amp;eid=3312 -------------------------------------- Type: Editorial Reported by: Patrik Fältström &lt;paf&lt; at &gt;netnod.se&gt; Section: A and A.1 Original Text ------------- In A: Code point: The code point, or code points, to which this rule is to be applied. Normally, this implies that if any of the code points in a label is as defined, then the rules should be applied. If evaluated to True, the code point is OK as used; if evaluated to False, it is not OK. In A.1: Rule Set: False; If Canonical_Combining_Class(Before(cp)) .eq. Virama Then True; If RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*\u200C (Joining_Type:T)*(Joining_Type:{R,D})) Then True; Corrected Text -------------- In A: Code point: The code point, or code </pre> RFC Errata System 2012-08-09T09:06:59 http://comments.gmane.org/gmane.ietf.idnabis/7366 <pre>Hi, RFC5892 contains the following rule about the contextual validity of U+200C: By intuition, I understand that "\u200C" within the regex means the code point in question. So, a feasible interpretation would be: (*) The code point MUST occur between Joining_Type:{L,D} and Joining_Type:{R,D}, where arbitrary occurences of Joining_Type:T MAY be in between. On the other hand, the statement literally defines just a regex that should match the string somewhere (with no reference to "cp" as in other rules), such that the rule would be satisfied already if any U+200C fulfill the requirement. The literally interpretation sounds stupid, but I found both variants within IDNA2008 implementations. For instance, consider the Perl module Net::IDN::UTS46 on CPAN. Here, it's taken literally and hence the sequence U+0628 U+200C U+0627 U+200C U+0627 is considered to be valid, although U+0627 is Joining_Type:R and thus the second U+200C doesn't meet the requirement (*). On the other hand, the (probably more reliab</pre> debug< at >test1.org 2012-08-06T02:31:27 http://comments.gmane.org/gmane.ietf.idnabis/7356 <pre>Greeting all, It might be a little bit odd to ask this question at the moment, I know it is a little bit late and I tried my best to search for it. What is the main reason for not supporting the UNICODE in the DNS protocol and to not use the hack-and-slash current way to solve this issue? I tried to virtualized these scenarios but I failed to fulfill them cause I found another scenario which can contradict it: 1) It is hard to update the internet old legacy of machines will be impossible to maintain: Well considering current supporting for IPv6 RRs, DNSSEC RRs, ... and other records within the protocol I don't think it is hard to use the UNICODE as based encoding in DNS servers. 2) It is bad to increase the size of the zone which will slow the cashing and will increase paging which will cause slowness in responses: again, with ICANN allowing the new GTLDs and supporting the DNSSEC (big chunk of hashes) these things already increased the size. 3) As technical part it is hard to maintain s</pre> Abdulrahman I. ALGhadir 2012-07-01T05:43:50 http://comments.gmane.org/gmane.ietf.idnabis/7355 <pre>Greetings again. The websec WG is in WG Last Call for draft-ietf-websec-strict-transport-sec, an interesting document that is likely to be widely deployed in web browsers and servers. There are a few places in the document that touch (slam?) into IDNA 2003 and IDNA 2008, so I thought this list should pay attention now rather than later. In specific, please see section 8 (just the beginning), section 9, and section 13. The WG LC ends April 9. Please send any comments to the websec WG mailing list, not here. Thanks! --Paul Hoffman </pre> Paul Hoffman 2012-03-21T01:09:50 http://comments.gmane.org/gmane.ietf.idnabis/7314 <pre>Colleagues, I have posted a first draft regarding a format that could be used for representing IDN Tables in XML to the I-D Repository: https://datatracker.ietf.org/doc/draft-davies-idntables/ After discussion with a number of folks that felt this would be good work to undertake, I've put together a first cut which is not comprehensive, but I think goes some way toward a potential format. Unless there is interest in this being a more formal activity, my assumption is to aim to publish the final result independently as an Informational RFC. However, the mechanism of publication is secondary to coming up with something useful that would benefit TLD registries and other implementors. A list of design goals, from the document, is as follows: • MUST be in a format that can be implemented in a reasonably straightforward manner in software; • The format SHOULD be able to be checked for formatting errors, such that common mistakes can be caught; • An IDN Table MUST be able to express the set of valid </pre> Kim Davies 2012-03-01T19:15:06 http://comments.gmane.org/gmane.ietf.idnabis/7309 <pre>Dear colleagues, Apologies if you see this more than once. Because of prior interest here, I'm posting this message here, but not cross-posting. ICANN has published the final version of the Variant Issues Project report, and has published a project plan for next steps. You may read about these developments on the following pages: http://www.icann.org/en/announcements/announcement-20feb12-en.htm http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb12-en.htm Best regards, Andrew </pre> Andrew Sullivan 2012-02-21T22:22:00 http://comments.gmane.org/gmane.ietf.idnabis/7279 <pre>Thanks to all on this list who provided input; I have taken several of your suggestions into this proposal for a change to the way Firefox chooses how to display IDNs: https://wiki.mozilla.org/IDN_Display_Algorithm Comments, particularly on the "Possible Issues and Open Questions", would be very welcome. Gerv </pre> Gervase Markham 2012-01-20T18:38:30 http://comments.gmane.org/gmane.ietf.idnabis/7278 <pre>FYI, since my e-mail is blocked on this list, I sent this mail to ICANN. jfc --------------------- Gentlemen, the IUCG accompanies the iucg&lt; at &gt;ietf.org non-WG mailing list. Its purpose is to permit Internet, and IETF users to contribute to the architecture, technology and practice of their own multitechnology Integrated and Intelligent Use (IUse) of the whole digital ecosystem. In the considered area it therefore explores the architectural support of polynymy (strict synonymy in a different context) and orthotypography (typographical syntax of a language) that IDNA2008 does not consider but locates in the user part of the presentation layer support (RFC 5895). We plan having a debate on the VIP report in the coming weeks and meet the Jan 31, 2012 deadline. We could not engage into such a debate prior to the publication of the report (however some of our members participated to the WG/VIP discussion) because we have difficulties in understanding how it fits in our targets. Our priority is: how t</pre> JFC Morfin 2012-01-05T12:56:42 http://comments.gmane.org/gmane.ietf.idnabis/7276 <pre>Dear colleagues, Apologies in advance for duplicate postings. I didn't cross-post because of the difficulty that sometimes causes if people follow up on list to discuss issues. Many of you will be aware that ICANN undertook the IDN Variant Issues Project last year. (Full disclosure: I was involved in the project.) On 23 December 2011 the report was posted for public comment, and I realise that I have been remiss in drawing people's attention to it. This message is to fix that. You can see the public announcement at http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm. That's also a good place to start in order to submit comments if you have them. The pubic comment period closes at the end of January 2012. ICANN is eagerly soliciting comments, and I hope that those of you interested in this topic will take the time to read the report and send your observations. Having been a participant in this particular sausage-making exercise, I will say that I am sure there are things that need impr</pre> Andrew Sullivan 2012-01-04T22:41:24 http://comments.gmane.org/gmane.ietf.idnabis/7278 <pre>FYI, since my e-mail is blocked on this list, I sent this mail to ICANN. jfc --------------------- Gentlemen, the IUCG accompanies the iucg&lt; at &gt;ietf.org non-WG mailing list. Its purpose is to permit Internet, and IETF users to contribute to the architecture, technology and practice of their own multitechnology Integrated and Intelligent Use (IUse) of the whole digital ecosystem. In the considered area it therefore explores the architectural support of polynymy (strict synonymy in a different context) and orthotypography (typographical syntax of a language) that IDNA2008 does not consider but locates in the user part of the presentation layer support (RFC 5895). We plan having a debate on the VIP report in the coming weeks and meet the Jan 31, 2012 deadline. We could not engage into such a debate prior to the publication of the report (however some of our members participated to the WG/VIP discussion) because we have difficulties in understanding how it fits in our targets. Our priority is: how t</pre> JFC Morfin 2012-01-05T12:56:42 http://comments.gmane.org/gmane.ietf.idnabis/7276 <pre>Dear colleagues, Apologies in advance for duplicate postings. I didn't cross-post because of the difficulty that sometimes causes if people follow up on list to discuss issues. Many of you will be aware that ICANN undertook the IDN Variant Issues Project last year. (Full disclosure: I was involved in the project.) On 23 December 2011 the report was posted for public comment, and I realise that I have been remiss in drawing people's attention to it. This message is to fix that. You can see the public announcement at http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm. That's also a good place to start in order to submit comments if you have them. The pubic comment period closes at the end of January 2012. ICANN is eagerly soliciting comments, and I hope that those of you interested in this topic will take the time to read the report and send your observations. Having been a participant in this particular sausage-making exercise, I will say that I am sure there are things that need impr</pre> Andrew Sullivan 2012-01-04T22:41:24 http://comments.gmane.org/gmane.ietf.idnabis/7278 <pre>FYI, since my e-mail is blocked on this list, I sent this mail to ICANN. jfc --------------------- Gentlemen, the IUCG accompanies the iucg&lt; at &gt;ietf.org non-WG mailing list. Its purpose is to permit Internet, and IETF users to contribute to the architecture, technology and practice of their own multitechnology Integrated and Intelligent Use (IUse) of the whole digital ecosystem. In the considered area it therefore explores the architectural support of polynymy (strict synonymy in a different context) and orthotypography (typographical syntax of a language) that IDNA2008 does not consider but locates in the user part of the presentation layer support (RFC 5895). We plan having a debate on the VIP report in the coming weeks and meet the Jan 31, 2012 deadline. We could not engage into such a debate prior to the publication of the report (however some of our members participated to the WG/VIP discussion) because we have difficulties in understanding how it fits in our targets. Our priority is: how t</pre> JFC Morfin 2012-01-05T12:56:42 http://comments.gmane.org/gmane.ietf.idnabis/7276 <pre>Dear colleagues, Apologies in advance for duplicate postings. I didn't cross-post because of the difficulty that sometimes causes if people follow up on list to discuss issues. Many of you will be aware that ICANN undertook the IDN Variant Issues Project last year. (Full disclosure: I was involved in the project.) On 23 December 2011 the report was posted for public comment, and I realise that I have been remiss in drawing people's attention to it. This message is to fix that. You can see the public announcement at http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm. That's also a good place to start in order to submit comments if you have them. The pubic comment period closes at the end of January 2012. ICANN is eagerly soliciting comments, and I hope that those of you interested in this topic will take the time to read the report and send your observations. Having been a participant in this particular sausage-making exercise, I will say that I am sure there are things that need impr</pre> Andrew Sullivan 2012-01-04T22:41:24 http://comments.gmane.org/gmane.ietf.idnabis/7242 <pre>Congrats to Xiaodong Lee &lt;lee&lt; at &gt;cnnic.cn&gt;!!! Mao Wei will miss you!!! From the bumpf: ... Dr. Xiaodong Lee of the Chinese Academy of Sciences as ICANN's new Vice President for Asia. Most recently, Dr. Lee has served as the Deputy Director General and Chief Technology Officer of CNNIC, the state network information center of China. Eric </pre> Eric Brunner-Williams 2011-12-13T19:07:37 http://comments.gmane.org/gmane.ietf.idnabis/7219 <pre>http://www.ted.com/talks/bobby_mcferrin_hacks_your_brain_with_music.html This scientific funny sequence shows the way semiotics works and how it differs from computers programming, and A,B,C methods. Everyone in the room follows this guy, without a single word being uttered or text being entered/displayed. However, any kid on earth can use this kind of communication and language to easily learn how connect its favorite site. Please remember that the real browser of the future is most probably Kinect+TV screen, and that JOSDNs (jabbed, oral, snapped domain names) are therefore already being supported. jfc </pre> J-F C. Morfin 2011-12-13T04:01:31 http://comments.gmane.org/gmane.ietf.idnabis/7184 <pre>Further to my yesterday mail: 1. I have added the inputs of Gervase to the http://iucg.org/wiki/IAB!_NOW! entry of JMB de Potzamparc, so it may serve as a current reference. 2. I have added the IDNA2010 (how to interface IDNA2008 from the user side) review in the page http://iucg.org/wiki/IDNA2010_Common_Objectives 3. I have initiated the working wiki I_D page. The abstract is as follows: en: This framing memorandum discusses the high-level architecture of an intelligent use of the whole digital ecosystem (WDE) and how the emerging community of IUtilisateurs explores it from a smart interfacing with the Internet layers. fr: Cette note de cadrage traite de l'architecture de haut niveau de l'utilisation intelligente de l'ensemble de l'écosystème numérique (EEN) et de comment la communauté émergente des IUtilisateurs l'explore à partir d'un interfaçage élégant avec les couches Internet. Tentative table of contents coming. Comments welcome. jfc PS: I suggest you to have a look to http://du</pre> J-F C. Morfin 2011-12-11T17:20:37 http://comments.gmane.org/gmane.ietf.idnabis/7151 <pre>Recently, Mozilla community member Jothan Frakes was kind enough to do some research about how different popular web browsers implement IDN, and when they display the real characters and when they display Punycode. This is in the context of a Mozilla review of our policy. I am interested in the opinions of people on this list (see below). As it turns out, the behaviour of all popular browsers is summarised at the bottom a Chromium project document here: http://www.chromium.org/developers/design-documents/idn-in-google-chrome The policies fall into 3 approximate buckets: A (IE, Chrome): Unicode if the (single) 'language' of the string is configured in the options, Punycode otherwise. B (Firefox, Opera): Unicode if the TLD is in a whitelist, Punycode otherwise. Arbitrary script mixing permitted (registry policy used to prevent abuse). C (Safari): Unicode if the script is in a whitelist (which by default does not include Cyrillic or Greek), Punycode otherwise. Not sure about script mixing. Firefox has hi</pre> Gervase Markham 2011-12-09T11:12:29 http://comments.gmane.org/gmane.ietf.idnabis/7146 <pre>Dear colleagues, I'm going to send related messages to four IETF lists where I suspect there might be people who are interested: dnsext, dnsop, apps-discuss, and idna-update. My apologies to those of you who get it more than once. For those of you who have been following or otherwise interested in the ICANN Variant Issues Project, the case study reports are up. The public comment period is open until 14 November. The Project is aimed at sorting out, for some scripts, what people mean when they talk about "variant names" in the DNS. As a matter of full disclosure, I point out that I have been involved with these reports, providing some observations about the (technical) feasibility of various things people wanted to do. I provided advice, but of course the teams actually responsible for the reports were free to do as they wished with my advice (including ignore it). I encourage those of you who are interested in the topic to read the reports and make any comments you think are useful in the public com</pre> Andrew Sullivan 2011-10-11T15:05:29 http://comments.gmane.org/gmane.ietf.idnabis/7144 <pre> Hi John, my main point was that the Unicode IDNA online tool works again; I could test xn--cocacola. It contains three occurrences of two unassigned Unicode points sometimes shown as U+FFFD. And the remaining PVALID points are in a script I cannot read; so from my POV I _hope_ that user agents will offer to display only scripts selected by me, and otherwise stick to raw XN-labels. That preference isn't affected by the IDNA version or UTS 46. If user agents can somehow display only "my" scripts, then they would be also able to flag say Latin + Cyril mixtures, no matter if that is an otherwise "valid" U-label below .net or .blogspot.com or .xn--xyzzy.dyndns.org. ACK, no problem with that. If user agents do not know a given Unicode point they will handle it as "unassigned". And their "knowledge" can be in ROM (or similar scenarios). Nothing relevant on this list, I know where I can disable IDNA in Firefox, and I'd know how to submit Chrome feature requests. Just two examples of user agents where I c</pre> Frank Ellermann 2011-10-11T05:17:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.idnabis