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/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 code points that are allowed for registration under a specific zone administrator's policies; • MUST be able to express computed alternatives to a given domain name based on a one-to-one, or one-to-many relationship. These computed alternatives are commonly known as "IDN variants"; • IDN Variants SHOULD be able to be tagged with specific categories, such that the categories can be used to support registry policy (such as whether to list the computed variant in the zone, or to merely block it from registration); • IDN Variants MUST be able to stipulated based on contextual information. For example, specific variants may only be applicable when they follow another specific code point, or when the code point is displayed in a specific presentation form; • The data contained within the table MUST be unambiguous, such that independent implementations that utilise the contents will arrive at the same results; • IDN Tables SHOULD be suitable for comparison and re-use, such that one could easily compare the contents of two or more to see the differences, to merge them, and so on. • As many existing IDN Tables are practicable SHOULD be able to be migrated to the new format with all applicable logic retained. It is explicitly NOT the goal of this format to: • Stipulate what code points should be listed in an IDN Table by a zone administrator. What registration policies are used for a particular zone is outside the scope of this memo. • Stipulate what a consumer of an IDN Table must do when they determine a particular domain is valid or invalid; or arrive at a set of computed IDN variants. IDN Tables are only used to describe rules for computing code points, but does not prescribe how registries and other parties utilise them. I'd appreciate any feedback. cheers, kim </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 to implement IDNA2008 (i.e. the RFC set from RFC 5890 to RFC 5895) on the user side (what we called the IDNA2010 project) and to organize its mutual interadministration (what we called the IDNA2012 project). 1. The ICANN charter of the work (http://www.icann.org/en/topics/new-gtlds/idn-variant-tlds-delegation-20apr11-en.pdf): - does not quote IDNA as architecture, only as an area of expertise for DNS experts. - does not refer to IDNA2008 or to any other RFC. The only RFC which is quoted (in a note) is the RFC 3743 to define a possible meaning of the key word "variant". We therefore had to wait for the completion of the http://www.icann.org/en/topics/new-gtlds/idn-vip-integrated-issues-23dec11-en.pdf draft to review a complete and homogeneous set of positions. 2. When we first discovered that document we decided to work out first: - an IUWW version (i.e. a working wiki). This is underway. - the missing executive summary which is necessary for a constructive debate over a document of 108 pages plus substantial annexes. - a general "Internet+" framework integrating the IAB/IETF end to end network now finalized capacities within the fringe to fringe Intelligent Use solutions we need and expect. This post-IDNA2008 "Internet+" people centric (cf. WSIS [World Summit on Information Society] unanimous resolution) framework has to be in continuity with the RFC 1287, RFC 1958 and RFC 3439, respecting the RFC 3935, attentive to RFC 3869, following the ICANN-ICP-3 requirements, in phase with the responses we obtained from the IESG and IAB and able to positively take advantage from the VIP work, the ICANN Affirmation of Commitment with the US Government (and hopefully all the other similar affirmation jointly signed with GAC Members) as well as other contributions received or expected from other multilinguistics (as the discipline of the linguistic coexistence) and digital architecture oriented agoras. Regards. JFC Morfin Facilitator, iucg&lt; at &gt;ietf.org </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 improvement, expansion, or more careful statement. I'm aware that the report as it stands is rather long, and I appreciate the difficulty in finding the time to read, digest, and comment on all of it. Given the importance of the topic, however, I think it's worth it. It might be tempting to discuss the document on this list, but I think it would be better to take such discussion either to the project list (which is still, as far as I know, open -- vip&lt; at &gt;icann.org, list info at https://mm.icann.org/mailman/listinfo/vip) or to use the public-comment links in the announcement to send such comments. That way, ICANN staff are sure to see the comments. Thanks and best regards, Andrew </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 to implement IDNA2008 (i.e. the RFC set from RFC 5890 to RFC 5895) on the user side (what we called the IDNA2010 project) and to organize its mutual interadministration (what we called the IDNA2012 project). 1. The ICANN charter of the work (http://www.icann.org/en/topics/new-gtlds/idn-variant-tlds-delegation-20apr11-en.pdf): - does not quote IDNA as architecture, only as an area of expertise for DNS experts. - does not refer to IDNA2008 or to any other RFC. The only RFC which is quoted (in a note) is the RFC 3743 to define a possible meaning of the key word "variant". We therefore had to wait for the completion of the http://www.icann.org/en/topics/new-gtlds/idn-vip-integrated-issues-23dec11-en.pdf draft to review a complete and homogeneous set of positions. 2. When we first discovered that document we decided to work out first: - an IUWW version (i.e. a working wiki). This is underway. - the missing executive summary which is necessary for a constructive debate over a document of 108 pages plus substantial annexes. - a general "Internet+" framework integrating the IAB/IETF end to end network now finalized capacities within the fringe to fringe Intelligent Use solutions we need and expect. This post-IDNA2008 "Internet+" people centric (cf. WSIS [World Summit on Information Society] unanimous resolution) framework has to be in continuity with the RFC 1287, RFC 1958 and RFC 3439, respecting the RFC 3935, attentive to RFC 3869, following the ICANN-ICP-3 requirements, in phase with the responses we obtained from the IESG and IAB and able to positively take advantage from the VIP work, the ICANN Affirmation of Commitment with the US Government (and hopefully all the other similar affirmation jointly signed with GAC Members) as well as other contributions received or expected from other multilinguistics (as the discipline of the linguistic coexistence) and digital architecture oriented agoras. Regards. JFC Morfin Facilitator, iucg&lt; at &gt;ietf.org </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 improvement, expansion, or more careful statement. I'm aware that the report as it stands is rather long, and I appreciate the difficulty in finding the time to read, digest, and comment on all of it. Given the importance of the topic, however, I think it's worth it. It might be tempting to discuss the document on this list, but I think it would be better to take such discussion either to the project list (which is still, as far as I know, open -- vip&lt; at &gt;icann.org, list info at https://mm.icann.org/mailman/listinfo/vip) or to use the public-comment links in the announcement to send such comments. That way, ICANN staff are sure to see the comments. Thanks and best regards, Andrew </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 to implement IDNA2008 (i.e. the RFC set from RFC 5890 to RFC 5895) on the user side (what we called the IDNA2010 project) and to organize its mutual interadministration (what we called the IDNA2012 project). 1. The ICANN charter of the work (http://www.icann.org/en/topics/new-gtlds/idn-variant-tlds-delegation-20apr11-en.pdf): - does not quote IDNA as architecture, only as an area of expertise for DNS experts. - does not refer to IDNA2008 or to any other RFC. The only RFC which is quoted (in a note) is the RFC 3743 to define a possible meaning of the key word "variant". We therefore had to wait for the completion of the http://www.icann.org/en/topics/new-gtlds/idn-vip-integrated-issues-23dec11-en.pdf draft to review a complete and homogeneous set of positions. 2. When we first discovered that document we decided to work out first: - an IUWW version (i.e. a working wiki). This is underway. - the missing executive summary which is necessary for a constructive debate over a document of 108 pages plus substantial annexes. - a general "Internet+" framework integrating the IAB/IETF end to end network now finalized capacities within the fringe to fringe Intelligent Use solutions we need and expect. This post-IDNA2008 "Internet+" people centric (cf. WSIS [World Summit on Information Society] unanimous resolution) framework has to be in continuity with the RFC 1287, RFC 1958 and RFC 3439, respecting the RFC 3935, attentive to RFC 3869, following the ICANN-ICP-3 requirements, in phase with the responses we obtained from the IESG and IAB and able to positively take advantage from the VIP work, the ICANN Affirmation of Commitment with the US Government (and hopefully all the other similar affirmation jointly signed with GAC Members) as well as other contributions received or expected from other multilinguistics (as the discipline of the linguistic coexistence) and digital architecture oriented agoras. Regards. JFC Morfin Facilitator, iucg&lt; at &gt;ietf.org </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 improvement, expansion, or more careful statement. I'm aware that the report as it stands is rather long, and I appreciate the difficulty in finding the time to read, digest, and comment on all of it. Given the importance of the topic, however, I think it's worth it. It might be tempting to discuss the document on this list, but I think it would be better to take such discussion either to the project list (which is still, as far as I know, open -- vip&lt; at &gt;icann.org, list info at https://mm.icann.org/mailman/listinfo/vip) or to use the public-comment links in the announcement to send such comments. That way, ICANN staff are sure to see the comments. Thanks and best regards, Andrew </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://duolingo.com. May be someone could come with a script/orthotypographic variant :-) </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 historically resisted adopting a Type A policy because we consider it seriously detrimental to IDN adoption and use. It seems to me that IDN can never be reliable for site owners, and therefore will not succceed, if a significant proportion of the world's browsers adopt Type A or Type C policies. This is because site owners can never know what proportion of their visitors will see gobbledegook in the URL bar rather than their nice domain name. Perhaps for sites whose visitors are all guaranteed to be from a particular country or language group, with properly-configured browsers and OSes which know that they speak a certain language or use a certain script, it might work - but I suggest that's a small subset of all sites. Many people in non-English-speaking countries still use English OSes and English browsers, with default settings. Type C is particularly bad - Russian and Greek IDNs are broken by default, but even if you persuade your users to turn it on, they can then be mixed-script spoofed. You get to choose between functionality and security. By contrast, with a Type B policy, if your IDN domain works in one copy of Firefox, it works in them all. If everyone had Type B policies, there would be no risk of a properly-registered domain coming up as gibberish. It has been suggested that Firefox switch to a Type A policy. As it is, the mix of policies means that the goal of universal acceptability is not being met anyway. Firefox switching to Type A would also not meet that goal by itself, but one could argue that there's a bit more consistency to browser behaviour. I would be interested in the opinion of people on this list as to: - whether my analysis seems reasonable; - whether they prefer type A, B or C; and - whether they see any particular policy as more damaging to IDN adoption than another. Has anyone lobbied one browser manufacturer or another to change their policy? Is there another option that is not currently in use which would be better? (Note that "no restrictions" is not an option, given what happened in 2005 with payp-cyrillic-a-l.com, and I would rather not derail this debate by rehearsing those arguments again.) Gerv </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 comment forum, or (for that matter) by discussing things on the open ICANN list devoted to the project (https://mm.icann.org/mailman/listinfo/vip). Note that the usual ICANN processes don't include the discussion on the mailing list as public comments, so if you want your comments to be considered formally, you'll need to post them in the appropriate area. Best regards, Andrew </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 cannot select which scripts I know. Apparently UTS 46 got it "right" for the few characters I'd really need (äöüß as it used to be in IDNA2003), for a very subjective concept of "right". Yes, I'd like it better if there would be 36*36 potential Unicode subsets indicated by aa-- to 99-- labels, where registered subsets are specified in an RFC and/or IANA registry. I could then pick "show valid cy-- labels for Cyril" and "valid nn-- labels for what I consider as no-nonsense Latin (no szlig, no long s, no IPA)". But obviously that's not what happened in IDNA, and emulating this arguably desired behaviour on top of xn-- is left as an exercise for browser developers. I posted the xn--cocacola update here, because I stumbled over an unrelated ICANN draft, where I saw two "long s" Unicode points U+1E9C and U+1E9D without the real thing U+017F, but including U+00DF: &lt;http://www.icann.org/en/topics/new-gtlds/latin-vip-issues-report-07oct11-en.pdf&gt; That is ominously inconsistent, but the Unicode IDN FAQ at least answered my questions about U+00DF. Oddly I read RFC 5890 + 5894 before, and still missed the essential fact that IDNA2008 allows U+00DF. Of course there was never a chance to get this right for everybody. This ICANN draft doesn't use the word "multi-stakeholder" anywhere and references IDNA2008; some folks on this list might like it. There are similar ICANN drafts for other scripts, I read only the Latin paper. I certainly won't miss any "I&lt;love&gt;something" labels, my keyboard has no &lt;love&gt;-key, and I don't know the Unicode points (plural) for &lt;love&gt;-dingbats by &lt;heart&gt;. But I'll hate u+00DF forever, that is just the consequence of too many years with QWERTY before QWERTZ came around, plus a spelling reform not matching what I learned in school (BTW, in theory I like this reform, because it simplified the u+00DF rules, but in practice I rarely get it right), plus the stupi^H^H^Hrange U+1E9E. ACK, generally. But UTS 46 has a point wrt U+00DF, and I expect the same behaviour for äöü vs. ÄÖÜ as for aou vs. AOU in labels. Apparently IDNA2008 does not more enforce this behaviour. Nothing in particular, I used xn--cocacola in an example, because I thought it is a known funny XN-label, and was caught off guard when Jeff reported that this "works" to some degree with Firefox. Anything else were just side-effects of my attempts to understand why some folks don't like IDNA2008. Meanwhile I got it. -Frank </pre> Frank Ellermann 2011-10-11T05:17:51 http://comments.gmane.org/gmane.ietf.idnabis/7134 <pre>Adam Barth said: &gt; &gt; On Fri, Sep 30, 2011 at 1:02 PM, =JeffH &lt;Jeff.Hodges&lt; at &gt;kingsmountain.com&gt; wrote: &gt;&gt; Adam Barth &lt;ietf&lt; at &gt;adambarth.com&gt; said: &gt;&gt;&gt; More concretely, I can tell you that Chrome plans to continue to &gt;&gt;&gt; implement IDNA2003 for the foreseeable future. &gt;&gt; &gt;&gt; Does that mean just Chrome itself, or Webkit as a whole (and thus having &gt;&gt; implications for all webkit-based browsers) ? &gt; &gt; Different WebKit ports can make different choices in this regard. &gt; However, I don't know of any major ports choosing anything other than &gt; IDNA2003. So I'm wondering how well this is going to work out if the DNS registry &amp; registrar world migrates to IDNA2008 per se (i.e. with or without RFC5895, but without UTS#46) ? If I understand correctly, one example issue is: If some DNS registries do not allow Esszet and Final Sigma (Latin small letter sharp S and Greek small final sigma) to be registered, and if some applications that use DNS are applying IDNA2003, then some lookups will make it appear that, for example, Esszet HAS been registered because of the conversion to "ss" (assuming a target using the "ss" form actually exists). And of course, the bit about having a target actually exist could be conveniently arranged by phishers. What are other potential impedance-mismatch issues that might arise that folks might be aware of? Thus I'm curious about what the momentum is like for ccTLDs and gTLDs to support IDNA and which version thereof ( IDNA2008, IDNA2008 + RFC5895, IDNA2008 + UTS46, or IDNA2003) ? And also which IETF lists might such momentum be discussed on? I don't really see anything pertinent on dnsop&lt; at &gt;ietf.org in the last year except for specific discussion of draft-liman-tld-names. thanks, =JeffH </pre> =JeffH 2011-10-06T04:40:35 http://comments.gmane.org/gmane.ietf.idnabis/7117 <pre>Adam Barth &lt;ietf&lt; at &gt;adambarth.com&gt; said: &gt; &gt; More concretely, I can tell you that Chrome plans to continue to &gt; implement IDNA2003 for the foreseeable future. Does that mean just Chrome itself, or Webkit as a whole (and thus having implications for all webkit-based browsers) ? thanks, =JeffH </pre> =JeffH 2011-09-30T20:02:51 http://comments.gmane.org/gmane.ietf.idnabis/7116 <pre>while investigating this stuff I heard that the "DNS world" is moving to IDNA2008 -- not exactly sure what that means -- registry/registrars, resolver code, ... ? But given the deltas between IDNA2008, IDNA2008 + RFC5895, IDNA2008 + UTS46, and IDNA2003, it seems to me that it'd be a good thing if we can try to get more uniform IDNA2008 adoption overall, i.e. bite the bullet now rather than later when it's a lot bigger. I note that these issues have been discussed at length on this list over the prior few years, and a perusal of the archives will likely be useful (e.g. cite previous messages rather than typing them all over again :) =JeffH </pre> =JeffH 2011-09-30T19:59:00 http://comments.gmane.org/gmane.ietf.idnabis/7104 <pre> Hi, In working towards completion of.. HTTP Strict Transport Security (HSTS) &lt;https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec&gt; ..and.. The Web Origin Concept https://tools.ietf.org/html/draft-ietf-websec-origin ..we are attempting to address the proper way to reference IDNA2008 and IDNA2003 in terms of stipulating comparisons of domain names (that may or may not be IDNs). In discussions with our ADs and a few IDNA-literate folks, we've been informed that the IDNA-specific language in the recently-released RFC6265 HTTP State Management spec isn't quite up to the standards they would like to see at this time. Thus I've performed some surgery on draft-ietf-websec-strict-transport-sec and have included below the specific section portions that are IDNA specific (this is from my working copy which isn't quite yet overall ready tonight to submit as -03). The key context to keep in mind when reviewing the below is that the key "processing" -- essentially a domain name comparison -- will occur deep within the bowels of HTTP clients, well along the processing pipeline for URIs, and presumably after IDNA-canonicalization and requisite validation/testing has occurred. However, the guidance we've received is that given the complexities and subtleties of IDNA processing and considerations, our specs really should be more explicit about the foregoing assumption(s) and the downside risks if the requisite validation/testing is not performed. With that context in mind, thoughts on the below are solicited. Apologies for just having these excerpts at this time, but I ought to have -websec-strict-transport-sec-03 submitted in the next few days at most. thanks, =JeffH . . . 7. User Agent Processing Model This section describes the HTTP Strict Transport Security processing model for UAs. There are several facets to the model, enumerated by the following subsections. This processing model assumes that the UA implements IDNA2008 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11 "Internationalized Domain Names for Applications (IDNA): Dependency and Migration". It also assumes that all domain names manipulated in this specification's context are already IDNA-canonicalized as outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to the processing specified in this section. The above assumptions mean that this processing model also specifically assumes that appropriate IDNA and Unicode validations and character list testing have occured on the domain names, in conjunction with their IDNA-canonicalization, prior to the processing specified in this section. See the IDNA-specific security considerations in Section 13.2 "Internationalized Domain Names" for rationale and further details. . . . 8. Domain Name IDNA-Canonicalization An IDNA-canonicalized domain name is the string generated by the following algorithm, whose input must be a valid Unicode-encoded (in NFC form [Unicode6]) string-serialized domain name: 1. Convert the domain name to a sequence of individual domain name label strings. 2. When implementing IDNA2008, convert each label that is not a Non- Reserved LDH (NR-LDH) label, to an A-label. See Section 2.3.2 of [RFC5890] for definitions of the former and latter, refer to Sections 5.3 through 5.5 of [RFC5891] for the conversion algorithm and requisite input validation and character list testing procedures. Otherwise, when implementing IDNA2003, convert each label using the "ToASCII" conversion in Section 4 of [RFC3490] (see also the definition of "equivalence of labels" in Section 2 of the latter specification). 3. Concatenate the resulting labels, separating each label from the next with (".") a %x2E character. See also Section 11 "Internationalized Domain Names for Applications (IDNA): Dependency and Migration" and Section 13.2 "Internationalized Domain Names" of this specification for further details and considerations. . . . 11. Internationalized Domain Names for Applications (IDNA): Dependency and Migration Textual domain names on the modern Internet may contain one or more "internationalized" domain name labels. Such domain names are referred to as "internationalized domain names" (IDNs). The specification suites defining IDNs and the protocols for their use are named "Internationalized Domain Names for Applications (IDNA)". At this time, there are two such specification suites: IDNA2008 [RFC5890] and its predecessor IDNA2003 [RFC3490]. IDNA2008 obsoletes IDNA2003, but there are differences between the two specifications, and thus there can be differences in processing (e.g. converting) domain name labels that have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003-based domain name labels will exist in the wild. User agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003. . . . 13. Security Considerations . . . 13.2. Internationalized Domain Names Internet security relies in part on the DNS and the domain names it hosts. Domain names are used by users to identify and connect to Internet hosts and other network resources. For example, Internet security is compromised if a user entering an internationalized domain name (IDN) is connected to different hosts based on different interpretations of the IDN. The processing models specified in this specification assume that the domain names they manipulate are IDNA-canonicalized, and that the canonicalization process correctly performed all appropriate IDNA and Unicode validations and character list testing per the requisite specifications (e.g., as noted in Section 8 "Domain Name IDNA- Canonicalization"). These steps are necessary in order to avoid various potentially compromising situations. In brief, some examples of issues that could stem from lack of careful and consistent Unicode and IDNA validations are things such as unexpected processing exceptions, truncation errors, and buffer overflows, as well as false-positive and/or false-negative domain name matching results. Any of the foregoing issues could possibly be leveraged by attackers in various ways. Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in terms of disallowed characters and character mapping conventions. This situation can also lead to false-positive and/or false-negative domain name matching results, resulting in, for example, users possibly communicating with unintended hosts, or not being able to reach intended hosts. For details, refer to the Security Considerations sections of [RFC5890], [RFC5891], and [RFC3490], as well as the specifications they normatively reference. Additionally, [RFC5894] provides detailed background and rationale for IDNA2008 in particular, as well as IDNA and its issues in general, and should be consulted in conjunction with the former specifications. 13.3. Denial of Service (DoS) . . . --- end </pre> =JeffH 2011-09-30T03:07:15 http://comments.gmane.org/gmane.ietf.idnabis/7093 <pre>IDNA2008 has introduced the need for post IDNA2008 protocol and technology adaptations in different areas. Several mailing lists are working on such adaptations. There is a need they know the others' targets and they use the same terminology with the same meaning. To that end we have compiled charters and drafts, terminology definitions and propositions from the different souces involved: IAB, IETF/WG/IDNA2008, IETF/WG/PRECIS, ICANN/WG/VIP, UNICODE, IUCG, IUTF, ALFA, IANA and Unicode. The file is http://iucg.org/wiki/IDNS_Common_Glossary. At this stage we would like to continue compiling suggestions to add to this document in order to have a comprehensive consolidation of ideas and terms. Once inputs are stabilized, I will sort all the terms towards an update of the IANA terminology file. I hope it could help reaching consensuses more easily if we speak the same language. Portzamparc _______________________________________________ Idna-update mailing list Idna-update&lt; at &gt;alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update </pre> jean-michel bernier de portzamparc 2011-08-19T18:34:43 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.idnabis