- vip - lists.icann.org

Re: [vip] Draft on IDN Tables in XML
by Kim Davies March 7, 2012

March 7, 2012

Hi Thomas, On Mar 1, 2012, at 12:21 PM, Thomas Roessler wrote: A few quick comments on the XML format level upon skimming this (mostly nit-picking): - you don't seem to identify the namespace URI in the normative text, it's hidden in the RNG schema - you don't use the namespace in your examples. - the example in 3.4 doesn't follow the specification for the description element: You either need a CDATA construct, or you need to entity-escape the pointy brackets. - in the specification for the description element, don't talk of "CDATA" as an element. It isn't, but rather a particular way to mark up textual data: http://www.w3.org/TR/xml/#sec-cdata-sect So: The content model for <description> is text; if content includes markup, then CDATA is a convenient method to write that out. - MIME-type -> media type All great fixes I'll work into the next revision. - To the unique identifier point in your issues list -- agree that it might be useful to give the table a unique identifier. I probably wouldn't choose an ID attribute, but would include a "this version" and "latest version" URI in the <meta> section. Sounds good to me. - I may be missing something, but what's the extension model for the @when attribute on <var>? Are certain names there reserved for IANA, and others up for grabs? Want to use URIs for these names, so everybody can coin their own without stepping on others' toes? Something else? Good points, the mechanism for specifying "when" attributes is undefined right now. Right now I know to implement some tables we need to support context in Arabic script strings. I don't know if it is knowable in advance all the types of contextual modes that will need to be supported. If we assume they can not be, then I agree there needs to be a mechanism to keep track of them so the format doesn't extend in competing directions and lose its utility. Hope these are useful, Very, thanks! kim

5 4

Re: [vip] Draft on IDN Tables in XML
by Andrew Sullivan March 7, 2012

March 7, 2012

Hi, On Wed, Mar 07, 2012 at 12:47:36PM +1100, James Mitchell wrote: > 2) The set of code points (or sequences of code points) that are considered equivalent by the registry Could we please not use "equivalent" for this? That word has caused enough trouble already. > The table should not attempt to place rules on the use of code > points within a label as these rules are often non-trivial. One can > easily tell whether a name is registered by performing a DNS lookup > or a WHOIS query for the name. Alternatively a registrar will be > able to notify a potential registrant should a name be considered > "invalid". Withouth rules on the use of code points within a label, the table needs to be supplemented by something else in order to create a complete policy. Where would you want to put those rules? > Further to the above the table should not attempt to define those > variants that are activated/allowed/blocked. An active variant can > be determined from a query to the DNS or WHOIS and these protocols > will have to used considering a variant may have been activated > post-registration. Additionally the rules for determining whether a > variant can be activated are non-trivial. Consider the example > below. See above. Of course they're not trivial. But they need to be expressed somewhere so that one can unambiguously determine whether a string is a candidate to be a U-label in a zone. If you can't determine that, then the policy doesn't actually cover everything it's supposed to. > To avoid the somewhat common mistake of incorrectly defining equivalence I suggest that equivalent sequences of code points are defined in one place. For example > > <char cp="0627"> > <var cp="0625"/> > </char> > <char cp="0625"> >  > </char> > > should be expressed as > > <equivalent> > <char cp="0625"> > <char cp="0627"> > </equivalent> This won't work for cases where the alternatation goes only one way. In Russian, for instance, IE (U+0435) can be used (casually, though not formally) where IO (U+0451) is used; but it is never the case that IO can be used where IE is used. Trivially, in French it is sometimes the case that one substitutes undecorated characters for decorated characters; but you don't do things the opposite way. Now, of course, you might just say, "Do them all in order to avoid confusion." But this is an example where at least some registries have talked about wanting to ensure blocking for some cases and withholding for others; and in that case, "equivalence" is certainly the wrong concept and symmetry is not what you get. Best, A -- Andrew Sullivan ajs(a)anvilwalrusden.com

1 0

Re: [vip] Draft on IDN Tables in XML
by Patrik Fältström March 7, 2012

March 7, 2012

On 7 mar 2012, at 14:21, J-F C. Morfin wrote: > Nothing in protocols forces me to use an UTF-8 keyboard or printer (as long as punycode is supported somewhere down the line, in the IDNA case). As the email from Kim was explicitly tagged with information that it was in charset UTF-8 it is possible for you, and up to you and your tools to do the best of the situation. Patrik

1 0

Re: [vip] Draft on IDN Tables in XML
by Kim Davies March 7, 2012

March 7, 2012

Hi James, On Mar 6, 2012, at 5:47 PM, James Mitchell wrote: > I think this work should focus on identifying only: > > 1) The set of code points that can be used for registration > 2) The set of code points (or sequences of code points) that are considered equivalent by the registry > > The table should not attempt to place rules on the use of code points within a label as these rules are often non-trivial. One can easily tell whether a name is registered by performing a DNS lookup or a WHOIS query for the name. Alternatively a registrar will be able to notify a potential registrant should a name be considered "invalid". I'm not sure I understand what you are asking this to rule out. The design goals state the format is not designed to restrict registry policy, rather act as a method of expressing what it is so others can re-use it as they see fit. I don't see the use case where it could be conceived this would be used in place of a DNS or WHOIS lookup. An IDN table confers nothing about what labels are already allocated in a registry. The most value this format can bring is if it can express as many rulesets are possible in relation to IDN policies. If there is a substantial population of IDN tables that can not be expressed with it, I am not sure it is any more beneficial than the current situation. > Further to the above the table should not attempt to define those variants that are activated/allowed/blocked. An active variant can be determined from a query to the DNS or WHOIS and these protocols will have to used considering a variant may have been activated post-registration. Additionally the rules for determining whether a variant can be activated are non-trivial. Consider the example below. > > <char cp="0627"> > <var cp="0625"/> > </char> > > And a registered name of "0627 0627". It is unclear from the definition above whether the label "0627 0625" is valid because it does not describe whether the substitution should have been applied across the whole label or whether it can be applied to one character. This is only a trivial example however I can provide many more complex rules. I think we're in agreement on this. With the above table and the "0627 0627" string, presumanly it would generate a set of 3 variants: ("0627 0625", "0625 0627", "0625 0625"). Now what the registry does with those variants is the registry's business. As we've seen with the JET guidelines, different registries have taken the same base table but resulted in different approaches to which labels are delegated, reserved or otherwise handled. That said, a suggestion has already been made to me that a registry could optionally specify an attribute as to whether a variant would result in blocking, delegation or something else. This doesn't mean a consumer of the table needs to follow that hint if they wish to repurpose the table. > To avoid the somewhat common mistake of incorrectly defining equivalence I suggest that equivalent sequences of code points are defined in one place. For example > > <char cp="0627"> > <var cp="0625"/> > </char> > <char cp="0625"> >  > </char> > > should be expressed as > > <equivalent> > <char cp="0625"> > <char cp="0627"> > </equivalent> What about one-way variants? It seems kind of clumsy to have them specified in potentially two different duplicative ways. I am not sure how common it has been that registries mess up their tables, but you could probably easily lint your table to pick up where equivalence doesn't exist, and fix it if appropriate. kim

1 0

Re: [vip] Draft on IDN Tables in XML
by Kim Davies March 1, 2012

March 1, 2012

Hi Mark, Thanks for the comments: On Mar 1, 2012, at 11:43 AM, Mark Davis ☕ wrote: A sequence of multiple code points can be specified as a variant of a single code point. For example, the sequence of "o" then "e" can be specified as a variant for an "o with umlaut" (U+00F6) as follows: <char cp="00F6"> <var cp="006F 0065"/> </char> It should be possible for a sequence to map to a character or sequence, rather than restricting to single code points. So the cp in either case should allow space-delimited hex codes. Eg (where x and y are code points) <char cp="x y"> <var cp="y x"/> </char> I agree about the need for this functionality, however given the dual role of the <char> element as specifying both membership in the table for eligibility purposes, and as the target for a specific mapping, I am not sure of the best way to do it. If we take this approach, the question becomes how does one express the eligibility of "x" and "y" in a table? Can it be assumed both "x" and "y" are eligible in any context, or should it be assumed "x" is only eligible when followed by "y", and therefore you would need to explicitly write the following to indicate eligibility of both as: <char cp="x"/> <char cp="y"/> <char cp="x y"> <var cp="y x"/> </char> Another alternative would be to completely decouple <char> from <var>, and have var something like <var from-cp="x y" to-cp="y x"/> <char cp="200c"> <var cp="0000"/> </char> I think this would be less prone to errors as simply <char cp="200c"> <var cp=""/> </char> Good idea. <var cp="0673" when="arabic-isolated"/> The spec needs to have an unambiguous way to determine when a character satisifies the 'when' clause. I struggled with how best to handle Arabic contextual forms and I am not really sure the approach used is the right way to do it. What is in there right now feels awfully ad-hoc. I am wondering if there is some other specification that can be leveraged here, but at the same time not making this specification too unwieldy to implement. Even though there are no IDN tables yet (that I am aware of) that utilise some form of context other than those that use Arabic contextual form, I am sure there is potential for it in the future. kim

1 0

Re: [vip] Final Integrated Issues Report and Project Plan for Next Steps Now Posted
by Naela Sarras Feb. 23, 2012

Feb. 23, 2012

Dear JFC, The proposed project plan is the document currently open for public comment. You can review the proposed plan and submit any comments via the link provided: http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb1… Best regards, Naela Sarras ICANN From: "J-F C. Morfin" <jfc(a)morfin.org<mailto:jfc@morfin.org>> Date: Wed, 22 Feb 2012 09:18:52 -0800 To: Naela Sarras <naela.sarras(a)icann.org<mailto:naela.sarras@icann.org>>, "vip(a)icann.org<mailto:vip@icann.org>" <vip(a)icann.org<mailto:vip@icann.org>> Cc: "idna-update(a)alvestrand.no<mailto:idna-update@alvestrand.no> work" <idna-update(a)alvestrand.no<mailto:idna-update@alvestrand.no>>, "iucg(a)ietf.org<mailto:iucg@ietf.org>" <iucg(a)ietf.org<mailto:iucg@ietf.org>> Subject: Re: [vip] Final Integrated Issues Report and Project Plan for Next Steps Now Posted At 22:55 21/02/2012, Naela Sarras wrote: Dear Colleagues, The final Integrated Issues Report has been posted. In addition, the draft VIP Project Plan for the next steps has been posted for public comment. http://www.icann.org/en/announcements/announcement-20feb12-en.htm http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb1… Both documents will be discussed at the IDN Variant Issues Project Session during the ICANN Costa Rica Meeting, 11-16 March 2012. Best regards, Naela Sarras ICANN Dear Naella, is this list still active for disscussion over the Very Impossible Project (VIP) issue? If yes, what I hope, are new venues allowed in the debate (like Internet extended architectural frameworks able to support variants off the shelves)? Thank you jfc

1 0

Final Integrated Issues Report and Project Plan for Next Steps Now Posted
by Naela Sarras Feb. 21, 2012

Feb. 21, 2012

Dear Colleagues, The final Integrated Issues Report has been posted. In addition, the draft VIP Project Plan for the next steps has been posted for public comment. http://www.icann.org/en/announcements/announcement-20feb12-en.htm http://www.icann.org/en/public-comment/idn-vip-proposed-project-plan-20feb1… Both documents will be discussed at the IDN Variant Issues Project Session during the ICANN Costa Rica Meeting, 11-16 March 2012. Best regards, Naela Sarras ICANN

1 0

FW: ICANN News Alert -- IDN Variant Issues Project: Draft Integrated Issues Report
by Naela Sarras Jan. 11, 2012

Jan. 11, 2012

Dear Colleagues, The Draft Integrated Issues Report is currently available for public comment. The public comment period was opened on 23 December 2011 and will run until 30 January 2012. We apologize about any confusion you may have had by receiving an interim version of the report sent to this list on 6 December 2011. This was a preliminary version of the report that was shared both to inform the list of progress and to seek input into the report before it is published for public comment. We have incorporated as many of your comments as possible into the draft Integrated Issues Report and now request that any additional comments you may have to be posted in the public comment forum, which will be used in considering changes in the Final Integrated Issues Report. The announcement and public comment forum can be accessed at: http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm Best regards, Naela Sarras ICANN From: ICANN News Alert <communications(a)icann.org<mailto:communications@icann.org>> Date: Mon, 26 Dec 2011 15:52:18 -0800 To: Naela Sarras <naela.sarras(a)icann.org<mailto:naela.sarras@icann.org>> Subject: ICANN News Alert -- IDN Variant Issues Project: Draft Integrated Issues Report [http://www.icann.org/images/gradlogo_bow.jpg]<http://www.icann.org/> News Alert http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm ________________________________ IDN Variant Issues Project: Draft Integrated Issues Report 23 December 2011 IDN Variant Issues Project: Draft Integrated Issues Report Comment Period Deadlines (*) Important Information Links Public Comment Box<http://www.icann.org/en/public-comment/idn-vip-integrated-issues-23dec11-en…> Open Date: 23 December 2011 To Submit Your Comments (Forum)<mailto:idn-vip-integrated-issues@icann.org> Close Date: 30 January 2012 Time (UTC): 23:59 View Comments Submitted<http://forum.icann.org/lists/idn-vip-integrated-issues/> Section I: Description, Explanation, and Purpose On 20 April 2011, ICANN announced the IDN Variant Issues Project<http://www.icann.org/en/announcements/announcement-20apr11-en.htm> to explore the benefits and risks associated with the potential inclusion of IDN variant TLDs in the DNS root zone. This project was initiated in response to a 2010 ICANN Board of Directors resolution<http://www.icann.org/en/minutes/resolutions-25sep10-en.htm#2.5>. ICANN is publishing today for public comment<http://www.icann.org/en/public-comment/idn-vip-integrated-issues-23dec11-en…> the draft Integrated Issues Report<http://www.icann.org/en/topics/new-gtlds/idn-vip-integrated-issues-23dec11-…>, a study of the issues that this project has identified in relation to the management of IDN variant TLDs. It represents the result of the completion of the second phase of the project. The first phase involved the formation of six case study teams for the Arabic, Chinese, Cyrillic, Devanagari, Greek and Latin scripts. These teams were comprised of community experts with support by ICANN and worked on identifying issues related to IDN variant TLDs for each particular script, resulting in the publication in October of six individual reports<http://www.icann.org/en/announcements/announcement-4-03oct11-en.htm> detailing their findings. The second phase focused on integrating those six case study reports into the Integrated Issues Report. To complete this phase, ICANN formed a coordination team<http://www.icann.org/en/announcements/announcement-4-03oct11-en.htm> comprised of experts from each of the case study teams. The coordination team advised ICANN in completing the Integrated Issues Report, which summarizes and categorizes the various issues related to the identification and management of IDN variant TLDs. ICANN is now seeking community input on the issues discussed in this draft report. The report will be updated to reflect community feedback and the final Integrated Issues Report will be presented to the ICANN Board of Directors during their meeting at the ICANN public meeting in Costa Rica in March 2012. Following publication of the final Integrated Issues Report, ICANN will facilitate work toward determining the conditions under which certain types of variant TLDs could be implemented. Future work may also involve developing tools, processes, and protocols to support specific solutions, in cooperation with the appropriate experts. For the purpose of arriving at a determination on whether variant TLDs can be delegated, it is expected that the required work can be completed in calendar year 2012. Section II: Background On 25 September 2010 the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN) directed the CEO "to develop an issues report identifying what needs to be done with the evaluation, possible delegation, allocation and operation of gTLDs containing variant characters IDNs as part of the new gTLD process in order to facilitate the development of workable approaches to the deployment of gTLDs containing variant characters IDNs." (http://www.icann.org/en/minutes/resolutions-25sep10-en.htm#2.5) In response, ICANN conducted six case studies of individual scripts to investigate any issues associated with delegating and using IDN variant TLDs that need to be resolved to facilitate a good user experience. The next phase focused on integrating those six case study reports into the draft Integrated Issues Report, which is being posted here for public comment. Section III: Document and Resource Links Documents posted for comment * The IDN Variant Issues Project: A Study of Issues Related to the Management of IDN Variant TLDs<http://www.icann.org/en/topics/new-gtlds/idn-vip-integrated-issues-23dec11-…> Additional Resources * The original Variant Issues Project proposal<http://www.icann.org/en/topics/new-gtlds/idn-variant-tlds-delegation-20apr1…> 20 April 2011. Section IV: Additional Information None Staff Contact: Kurt Pritz Email: kurt.pritz(a)icann.org<mailto:kurt.pritz@icann.org?subject=More%20information%20on%20the%20IDN%20Variant%20Issues%20Project:%20Draft%20Integrated%20Issues%20Report%20public%20comment%20period> (*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses. This message was sent to naela.sarras(a)icann.org<mailto:naela.sarras@icann.org> from: ICANN | 4676 Admiralty Way Suite 330 | Marina del Rey, CA 90292-6601 Email Marketing by [http://app.icontact.com/images/icontact_tryFree.gif] <http://www.icontact.com/a.pl/144186> Manage Your Subscription <http://app.icontact.com/icp/mmail-mprofile.pl?r=9827450&l=6333&s=2E94&m=869…>

7 19

Integrated Issues Report draft
by Karen Lentz Jan. 11, 2012

Jan. 11, 2012

Dear colleagues, As discussed last week, we are circulating for your information the current draft of the Integrated Issues Report, compiling all of the material created to date. We will circulate the section on User Experience issues (section 5.3.2 of the report) under separate cover shortly, so that we can begin discussing this set of issues. This draft of the report is intended to inform the team's discussions at the face-to-face meetings next week. All team members are requested to review and become familiar with the document prior to the meeting. We expect that discussions on the mailing list will continue in the interim. On this Wednesday's team call we will also discuss the agenda for the face-to-face meeting, and any suggestions for the agenda from the team based on the current draft are also welcome. Best regards, Karen Lentz ICANN

6 9

Re: [vip] ICANN variant project update
by SM Jan. 8, 2012

Jan. 8, 2012

At 14:41 04-01-2012, Andrew Sullivan wrote: >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 I browsed through the report. I found it difficult to understand. "if an email is sent to localpart(a)dname.example.com and that name has a DNAME that resolves to realname.example.com, the mail transport agent is not going to rewrite the server-part of the address." I have some doubts about whether the above is correct. "It might, however, be one important type of variant-inspiring behavior, because most of the deployed code today supports IDNA2003 and not IDNA2008." I did not find any comment in the report about how to reverse the trend. "The users of the DNS are varied in respect of what they expect, what they want, and what they need." This section lumps users and technical usage together. There is not much of a difference between Law enforcement and other security investigators and end users. Instead of System administrators and Software developers, it would have been clearer to discuss technical usage and the issues that may occur. "Similarly, any site renumbering and so on will require twice the effort" I don't see what site renumbering has to do with (DNS) strings. "These issues are noted in recent reports from ICANN's Security and Stability Advisory Committee (such as SSAC 051)" That's a report on "Domain Name WHOIS Terminology and Structure". Which name to call WHOIS is not an issue. "Areas of application behavior, resolution and registration services, WHOIS service, and business logic all need to be examined in order to determine if these objectives are achievable." This is buried deep within the report. There are some examples to illustrate how the Internet, which has been reduced to web and email, may be affected. The web examples are simplistic. The two words which stand out in the report are Cost and DNAME. The report emphasizes that there will be higher costs in all areas; i.e. an increase in revenue for anyone with an interest in the work, from ICANN or the software developer. DNAME might be read as the off-the-self "solution" to technical problems. Regards, -sm

3 4