- gtld-tech - lists.icann.org

FW: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017
by Gustavo Lozano Aug. 1, 2016

Aug. 1, 2016

Hello Colleagues, I think that you may find this news alert of your interest. Regards, Gustavo From: ICANN News Alert <no-reply(a)external.icann.org> Reply-To: "no-reply(a)external.icann.org" <no-reply(a)external.icann.org> Date: Tuesday, July 26, 2016 at 17:34 To: Gustavo Lozano <gustavo.lozano(a)icann.org> Subject: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017 > ICANN News Alert > <http://www.icann.org/> > News Alert > https://www.icann.org/news/announcement-2016-07-26-en > > New Registration Data Directory Services Requirements for gTLD Registries, > Registrars to Take Effect in February 2017 > 26 July 2016 > > ICANN today announced that gTLD contracted parties must update their > Registration Data Directory Services (RDDS) by 1 February 2017. Registries and > registrars are required to implement the new Registration Data Access Protocol > (RDAP) gTLD Profile <https://www.icann.org/rdap-gtld-profile> . Registries > must also implement the data specifications defined in the Registry > Registration Data Directory Services Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> . > > The RDAP gTLD Profile and the RDDS Consistent Labeling and Display Policy are > the products of community efforts to improve the current system used to > discover who controls a domain name. This system comprises data retrieval > protocols WHOIS and a web-based version of WHOIS and databases controlled > by registries and registrars that contain domain registration information. > > ICANN has notified contracted parties that they are responsible for modifying > their systems within six months. ICANN consulted these parties when defining > the new requirements and implementation plans. > Background > The Registration Data Access Protocol was developed by the Internet > Engineering Task Force <https://ietf.org/> to eventually replace the WHOIS > protocol. This new protocol is superior to WHOIS in terms of data access > security, support for international characters, extensibility, and in the > standardization of query, response and error messages. The RDAP gTLD Profile > maps ICANN policy and contractual requirements onto technical requirements in > order to standardize directory services across gTLD contracted parties. > > The RDDS Consistent Labeling and Display Policy is a Consensus Policy > developed and adopted in accordance with ICANN Bylaws. The policy is the > result of recommendations adopted by the GNSO Council after the completion of > the Thick WHOIS Policy Development Process. The ICANN board adopted these > recommendations on 7 February 2014. > > The goal of the RDDS Consistent Labeling and Display Policy is to align the > way registries and registrars label and display registration data outputs. The > policy uses the output specifications found in the 2013 Registrar > Accreditation Agreement as the standard, thus only registries need to update > their systems. Changes might include renaming or re-ordering fields and > displaying additional data, such as registrar abuse contact information. > > For more information on these topics, visit: > * Registration Data Access Protocol gTLD Profile > <https://www.icann.org/rdap-gtld-profile> > * Registry RDDS Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> > * Thick WHOIS Policy Implementation > <https://www.icann.org/resources/pages/thick-whois-2016-06-27-en> > * Policy Implementation at ICANN <https://www.icann.org/policy/implementation> > About ICANN > ICANN's mission is to help ensure a stable, secure and unified global > Internet. To reach another person on the Internet, you have to type an address > into your computer - a name or a number. That address has to be unique so > computers know where to find each other. ICANN helps coordinate and support > these unique identifiers across the world. ICANN was formed in 1998 as a > not-for-profit public-benefit corporation and a community with participants > from all over the world. ICANN and its community help keep the Internet > secure, stable and interoperable. It also promotes competition and develops > policy for the top-level of the Internet's naming system and facilitates the > use of other unique Internet identifiers. For more information please visit: > www.icann.org <https://www.icann.org/> . > > > This message was sent to gustavo.lozano(a)icann.org from: ICANN News Alert | > no-reply(a)external.icann.org | ICANN | 12025 Waterfront Drive Suite 300 | Los > Angeles, CA 90094-2536 Email Marketing by > <http://www.icontact.com/a.pl/144186> > Manage Your Subscription > <http://app.icontact.com/icp/mmail-mprofile.pl?r=23976128&l=6333&s=2VAT&m=99… > 78&c=165637>

2 1

number of characters in a domain?
by Ryan Finnesey July 23, 2016

July 23, 2016

I was hoping someone can help me confirm my research. I am correct that domains are now limited to 67 characters in length including the extension? Cheers Ryan

3 2

Re: [gtld-tech] gtld-tech Digest, Vol 39, Issue 5
by Brian Mountford July 23, 2016

July 23, 2016

Francisco, I have questions about sections 1.5.14, 1.5.16 and 2.8.2. Profile Directive 1.5.14. The domain object in the RDAP response MUST contain the following events: - An event of eventAction type registration. - An event of eventAction type expiration. - An event of eventAction type last changed. The event of eventAction type last changed MUST be omitted if the domain name has not been updated since it was created. - An event of eventAction type last update of RDAP database. Is any particular ordering preferred in the results? Expiration will probably be later than last changed and last update. Should it come before or after the last changed and last update? Profile Directive 1.5.16. Entities MUST use jCard [RFC7095] structured addresses. RFC 7095 defines two different types of structured address: 3.3.1.3. Structured Property Values The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings. jCard Example: ["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. jCard Example: ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] Which form is to be used in RDAP responses? If it is the first version (list of simple strings), what is to be done with addresses containing more than two street address lines? Profile Directive 2.8.2. Registrar object lookup using an entity search on the fn element MUST be supported. RFC 7482 3.2.3. says: XXXX is a search pattern representing the "FN" property of an entity (such as a contact, registrant, or registrar) name as specified in Section 5.1 of [RFC7483]. This is straightforward enough when referring to contacts and registrants, but I am not sure how it applies to registrars. Our database stores registrars, which have a name, and also registrar contacts, which hang off registrars, and themselves also have names. Are you asking us to search by registrar name (which we would prefer), or by registrar contact name? Thanks. Brian

2 3

Do not implement before date in CL&D and RDAP profile
by Francisco Arias July 21, 2016

July 21, 2016

Dear colleagues, As you may recall the gTLD RDAP profile and Thick Whois policy implementation – Consistent Labeling and Display (CL&D for short) are synchronized and have a proposed effective date of 1 February 2017. This means enforcement would start on that date. However, in monitoring compliance with a given policy or contractual requirement we also need time to develop our tools and be able to *not* report false compliance issues (e.g., our current tool would raise an issue if it encounters the new Whois output that is specified in CL&D). We need to update that tool to avoid that issue from happening. We’d like to add to both CL&D and the RDAP profile a “do not implement before” date to avoid the aforementioned issue. We are thinking we are going to need approximately four months to update/build our tools be able to identify the updated Whois output and RDAP output. That would give contracted parties approximately a two-month window for release before the effective. We are planning to add such a date to the documents, unless there is a reason why people think we should not. Regards, -- Francisco

6 9

gTLD RDAP profile - release candidate
by Francisco Arias June 30, 2016

June 30, 2016

Dear colleagues, I’ve attached release candidate 1 (i.e., draft final) of the gTLD RDAP profile in PDF and Office Open XML formats. This version is a redline vs the version that underwent public comment. We plan to publish the final version by the end of July. Please review and let us know if you find any glaring issues by 15 July. This version incorporates the feedback received during the public comment period we run earlier this year and this mailing list. The main changes are as follows: 1. Section 1.3.6: allow contracted parties to add fields, events, roles without further ICANN approval. 2. Section 1.4.1: clarify requirement to support queries for strings mixing A- and U-labels. 3. Section 1.5.6: clarify mapping of EPP to RDAP statuses. 4. Section 1.5.15: make registrar expiration date optional. 5. Section 1.5.23: allow contracted parties to operate RDAP test services. 6. Section 3.1.1: limit requirement for registrars to offer RDAP services for thin registrations only. 7. Section 3.1.1: clarify that registrars will only be required to offer RDAP services for thin registrations under .com, .jobs, and .net until the effective date of the Thick Whois policy. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN PGP fingerprint: 1FDE 819F 7BEC 1CB2 127E EE54 9A4D 337B D510 E397

1 0

FW: Draft Consistent Labeling & Display - Revised Policy Language
by Francisco Arias June 29, 2016

June 29, 2016

FYI On 6/29/16, 6:42 PM, "gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of Fabien Betremieux" <gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of fabien.betremieux(a)icann.org<mailto:fabien.betremieux@icann.org>> wrote: Dear IRT members, As discussed in our meeting earlier today, we have posted our revision of the Policy language for implementation of the Consistent Labeling and Display requirement on our wiki: https://community.icann.org/pages/editpage.action?pageId=52889541. It is also attached to this email for your convenience. Please note that the format of the policy, after our revision, is different from the draft we posted for public comments in December (https://www.icann.org/public-comments/rdds-output-2015-12-03-en) We believe this was necessary to address the feedback we received from the community and the IRT in terms of the linkage of the Policy with Specification 3 of the 2013 RRA and the Whois Clarifications Advisory. For instance, while the draft policy required "The labeling and display of all gTLD registries web-based RDDS output , must be consistent with: (a) Specification 3 of the 2013 Registrar Accreditation Agreement (RAA)”, the revised policy lists specific requirements such as “3. If shown, the "Registrar Registration Expiration Date" field MUST appear immediately after the "Registry Expiry Date" field." Please also note that while the Policy has changed in format, it did not change in substance in order to address the community’s feedback we received in the public comment forum. Therefore, we believe this revision does not require further public comments and can be announced by 31 July 2016 for implementation with an effective date of 1 February 2017. Please review this revised Policy language as soon as possible, ideally before Friday 8 July COB. In the meantime, we will use the opportunity of our meeting in Helsinki tomorrow (http://sched.co/7Mdw) to present and discuss this revised policy language. Thank you for your consideration Best Regards -- Fabien Betremieux Sr. Registry Services & Engagement Manager Global Domains Division, ICANN US: +1 310 463 5334 | FR: +33 7 60 09 09 40 | Skype: fabien.betremieux

1 0

Re: [gtld-tech] WG: ICANN gTLDs v2 public report
by Matthias Pfeifer | DOTZON GmbH June 16, 2016

June 16, 2016

Hello list. Can we please add the country code of the RO to the JSON output? This would be very helpful to maintain statistical research. Best, Matthias Pfeifer DOTZON GmbH - incubating name spaces Akazienstrasse 28 10823 Berlin Deutschland - Germany Tel: +49 30 49802723 Mobil: +49 (0) 172 437 40 11 Fax: +49 30 49802727 pfeifer(a)dotzon.com www.dotzon.com DOTZON GmbH Registergericht: Amtsgericht Berlin-Charlottenburg, HRB 118598 Geschäftsführer: Katrin Ohlmer Sitz der Gesellschaft: Akazienstrasse 28, 10823 Berlin Von: gtld-tech-bounces(a)icann.org<mailto:gtld-tech-bounces@icann.org> [mailto:gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org>] Im Auftrag von Eduardo Alvarez Gesendet: Dienstag, 24. Mai 2016 01:58 An: gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> Betreff: [gtld-tech] ICANN gTLDs v2 public report Dear colleagues, We are planning to release a new version in JSON format of the new gTLDs CSV report (newgtlds.csv, currently available at http://newgtlds.icann.org/newgtlds.csv) The report will list all gTLDs that have signed a Registry agreement with ICANN, including gTLDs removed from the root, with the following fields: A-label, U-label, registry operator, the contract signing date, application number, delegation date, removal date and whether the gTLD was granted Specification 13 or not. The content of the new version of the report should be helpful to browsers and other software vendors trying to make decisions on gTLDs that have signed an agreement, or amendment including Specification 13 (http://newgtlds.icann.org/en/applicants/agb/base-agreement-spec-13-proposed…) For example, https://bugzilla.mozilla.org/show_bug.cgi?id=1196364. An example and the detail of the requirements considered for this new report are available in the attached .pdf file. Please note that we are not planning on replacing or changing the current newgtlds.csv report, which will continue to be updated as usual. Your feedback is welcome. Should you wish to provide any comments, please send them to gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> by June 30, 2016. Best regards, Eduardo Alvarez Technical Services Sr. Manager ICANN

2 1

FW: T/T Call for Volunteers
by Francisco Arias June 7, 2016

June 7, 2016

0*« *H÷ *0*10 `He0ä *H÷ ÕÑContent-type: multipart/alternative; boundary="B_3548140170_878579757" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3548140170_878579757 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Colleagues, =20 The below announcement might be of interest to you. There is a call for vol= unteers for the Translation and Transliteration policy implementation, you c= an see the details in the link below. =20 Regards, =20 --=20 Francisco =20 On 6/7/16, 9:09 AM, "Brian Aitchison" <brian.aitchison(a)icann.org> wrote: =20 Hi Francisco, =20 Fabien suggested to share the T/T call for volunteers with the =E2=80=9Cgtld-tech= =E2=80=9D mailing list to attract some tech-minded people to the IRT. If you agree= , would you mind circulating the link to the announcement?=20 =20 http://gnso.icann.org/en/announcements/announcement-29may16-en.htm =20 Thanks very much and let me know of any questions, =20 Brian=20 --B_3548140170_878579757 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:schema= s-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/office/20= 04/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta name=3DTitle c= ontent=3D""><meta name=3DKeywords content=3D""><meta http-equiv=3DContent-Type conte= nt=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft Word 1= 5 (filtered medium)"><style></style></head><body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple><di= v class=3DWordSection1><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-f= amily:Calibri'>Colleagues,<o:p></o:p></span></p><p class=3DMsoNormal><span sty= le=3D'font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></p><p cla= ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:Calibri'>The below an= nouncement might be of interest to you. There is a call for volunteers for t= he Translation and Transliteration policy implementation, you can see the de= tails in the link below.<o:p></o:p></span></p><p class=3DMsoNormal><span style= =3D'font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></p><p class= =3DMsoNormal><span style=3D'font-size:11.0pt;font-family:Calibri'>Regards,<o:p><= /o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family= :Calibri'><o:p> </o:p></span></p><div><p class=3DMsoNormal><span style=3D'f= ont-size:10.5pt;font-family:Calibri;color:black'>-- <o:p></o:p></span><= /p></div><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Calibr= i;color:black'>Francisco</span><span style=3D'font-size:11.0pt;font-family:Cal= ibri'><o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt= ;font-family:Calibri'><o:p> </o:p></span></p><div><div><p class=3DMsoNorm= al>On 6/7/16, 9:09 AM, "Brian Aitchison" <<a href=3D"mailto:brian= .aitchison(a)icann.org">brian.aitchison(a)icann.org</a>> wrote:<o:p></o:p></p= ></div></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><blockquote = style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt= ;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE= "><div><div><div><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-famil= y:Arial;color:black'>Hi Francisco,<o:p></o:p></span></p></div><div><p class=3D= MsoNormal><span style=3D'font-size:10.5pt;font-family:Arial;color:black'><o:p>=  </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-size:= 10.5pt;font-family:Arial;color:black'>Fabien suggested to share the T/T call= for volunteers with the “gtld-tech” mailing list to attract som= e tech-minded people to the IRT. If you agree, would you mind circulating th= e link to the announcement? <o:p></o:p></span></p></div><div><p class=3DM= soNormal><span style=3D'font-size:10.5pt;font-family:Arial;color:black'><o:p>&= nbsp;</o:p></span></p></div><div><p style=3D'margin:0in;margin-bottom:.0001pt'= ><span style=3D'font-size:11.0pt;font-family:Calibri;color:black'><a href=3D"htt= p://gnso.icann.org/en/announcements/announcement-29may16-en.htm">http://gnso= .icann.org/en/announcements/announcement-29may16-en.htm</a><o:p></o:p></span= ></p></div><div><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family= :Arial;color:black'><o:p> </o:p></span></p></div><div><p class=3DMsoNorma= l><span style=3D'font-size:10.5pt;font-family:Arial;color:black'>Thanks very m= uch and let me know of any questions,<o:p></o:p></span></p></div><div><p cla= ss=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Arial;color:black'><o= :p> </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-si= ze:10.5pt;font-family:Arial;color:black'>Brian <o:p></o:p></span></p></= div></div></div></blockquote></div></body></html> --B_3548140170_878579757-- 0t0\ tînG¡}Î¿²Kp0 *H÷ 0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert SHA2 Assured ID CA0 150604000000Z 180604120000Z010 UUS10U California10ULos Angeles1<0:U 3Internet Corporation for Assigned Names and Numbers10UFrancisco Arias0"0 *H÷ 0 œÝ-=èACÆH)¢:uUÇ ¹Œ£¢|2{39\@)ÉRnnÿ DK©a«7ŽÑáp:«mr>ÅUèjø'5'%1ýÔkß¢î ó÷& _ +žû¹+Ÿäm2¥ãÆHzÛ¯ñ¢ø(K¢&«&PÍ^-¹ÊÁóm¬|Œ¹Í±ÔÁ#ÿ¬3Ž¶ä]}¹XÊwCA'Þ®m'ßÀ[Z£IF¬m¢®GöóÅAõ+QÝ]@#Íªÿ&ãÚ Ò0±5œéÀsÒâ*3ê@âWü C¯£ò0î0U#0ç#OØ×ŒÙ?t9I2<y0UžäÜ$ì£xPNy¿¬OÀ0Uÿ00$U0francisco.arias(a)icann.org0Uÿ 0U%0++0CU <0:08 `Hýl0*0(+https://www.digicert.com/CPS0U0~0= ; 97http://crl3.digicert.com/DigiCertSHA2AssuredIDCA-g1.crl0= ; 97http://crl4.digicert.com/DigiCertSHA2AssuredIDCA-g1.crl0y+m0k0… *H÷ ÙSÖ-/K eFêõ4Û};=D¿ hÈ@õ©(RgoìÃf¹ºÆtPŠÃŒ1¯7ê!ÛHuûæRÛå_É³që4*Éäöz×ó(rù|4âû¿ŒåYgD¯=_$H£~ÚOKœÍW²OŸDá1ÉC48±mrO5bbo³ŸÖcyî¥Ã$_¯%nl¬ ÚÖæGüî0[ÒžæçÄw Ÿh6FüªC÷Ñ]X%#z^99(.önØ57QÊrM ivÑg uVm)ñøÕ~Ñ0N06 ®y`ff¹ÅŠl[ÜÍ0 *H÷ 0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert Assured ID Root CA0 131105120000Z 281105120000Z0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert SHA2 Assured ID CA0"0 *H÷ 0 Üø#?jµïÀ'y-¢C1ßÔOw€"Î>pðŸÝ'*Œ¶, ÊÝiXAíjÚcxY",+øº~É5;Vñ|B~%°#ÆE8×=Dù |`®°ZŸ;÷©ðŠcI¶AS@2œOæPzP%Eèñ¯Íÿ^ÿPóðÿœÅõœb¹ØûEmÍÅHMý&«6Eê6×_jâA ÜéÙõÆ!8<æfÕMÙFÚöÏR§};$ÃŽÁQ5ÆëÔï~ä{áDœz7àOË qäŠà,ó²s<Á°}œ«}Å}¡,Âs£ø0ô0Uÿ0ÿ0Uÿ04+(0&0$+0http://ocsp.digicert.com0Uz0x0: 8 64http://crl4.digicert.com/DigiCertAssuredIDRootCA.crl0: 8 64http://crl3.digicert.com/DigiCertAssuredIDRootCA.crl0U%0++0³U ª0Š0¢ `Hýl00(+https://www.digicert.com/CPS0d+0VRAny use of this Certificate constitutes acceptance of the DigiCert CP/CPS and the Relying Party Agreement which limit liability and are incorporated herein by reference.0Uç#OØ×ŒÙ?t9I2<y0U#0Eë¢¯ôË1-Q§§!ómÈ0 *H÷ NÔ'¹ýw~(ñ /É;>œÆ¯úQ2TkèÊÁqQ\µúàbŠ|'Ûå¢Ùö DWÄ4ms:Ö =ÞãäEk²ë%ý^9Ÿ[BöÎ`ãù VHÎ3h{Í«ðjËOX¹{]§"âWI'îŸiS:.]ÈôPNÙ°]ŽùU@fíØ»(_íLaíX(SDŒG )²lØT;uÛgx,xÆU=X2nœCM4Û{ÆBÛìŸ«aLãß!*PWÀ`¢5Õ$f7 IÏÕøe³àânÂ0·0 çàåØFþå`üð090 *H÷ 0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert Assured ID Root CA0 061110000000Z 311110000000Z0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert Assured ID Root CA0"0 *H÷ 0 ÎäC\±ó·`ùq¥®Ü&ªôÎõ 9(X`øÚ©2a<µ±(Ü z¬çyS\1*ö26vÌÞÝ<š¢ïjû!òRaß ×â±ÙþdÒ[_ùX5ŒGÍ¡6ùkÔ°8>ÁÃ3ÙØ/þ(³§ÖÃnDÀa5þYvm×ñ¢K +ÿrÚ`Ð5ÆxU ¡Ïåm ÈI|13l"éÐ2Z¢ºí9:r¡æú€ÙÕ1u®}"®?Fö(yÈ±ÚäWÄ~°ŽŠV³œ²íª§ð·Åš?Ðÿ¡ë_wO£c0a0Uÿ0Uÿ0ÿ0UEë¢¯ôË1-Q§§!ómÈ0U#0Eë¢¯ôË1-Q§§!ómÈ0 *H÷ ¢Œßâíðãrszd¿÷rfØ2äBub®ëòÕÙÞV³ÌÎ(¹ `\LXäÓ=IEX5išGêVÆy«Øgß <æž&, œ=³(÷_ÿ"âéeïàßÁgI³]ë² *ë&íxŸ}?+ó·&5m_¶I[«=%ÁÌ¶ÂñoÆúdhë-ëB·úÝbñŸPg·lœóñk67|©[mzñF`×'ŸKÎŸÃg*hßç3f¿ nócú%ml¥·a±Ò£&¡qâÃùÃQ·+Î.æP²§ú E/¢ðò100y0e10 UUS10U DigiCert Inc10Uwww.digicert.com1$0"UDigiCert SHA2 Assured ID CA tînG¡}Î¿²Kp0 `He i0/ *H÷ 1" ¿Ir/ãSK7LÞ*ºTñJ7ô£2ûñÇ|ß 0 *H÷ 1 *H÷ 0 *H÷ 1 160607172930Z0 *H÷ 3Ë®Íáj ¡lYþËeEv·³g%Ðã²]Üíå~cÄëzKñÈ]<ŒT-ÑrÒ²"Kµ1Þ.(fŠàO*QcC[Ü¶[øú#'uB³Ð¯;ZlW9pÛÕí{ '¿W æm)W\mvÞ«3äQA ßŸú Ü#çÒà×~oÛÈž¡á0üÎ@`žâóËÔ1Ü;ÁqU·³tr!óKŸÑ%£Ìï[}içú·Ií$t¿¶?ïáY·.Tt3.iY\ßqµ Å±»ÈLÃzå'`Ü¬ C;zß/21 "

1 0

ICANN gTLDs v2 public report
by Eduardo Alvarez May 25, 2016

May 25, 2016

Dear colleagues, We are planning to release a new version in JSON format of the new gTLDs CSV report (newgtlds.csv, currently available at http://newgtlds.icann.org/newgtlds.csv) The report will list all gTLDs that have signed a Registry agreement with ICANN, including gTLDs removed from the root, with the following fields: A-label, U-label, registry operator, the contract signing date, application number, delegation date, removal date and whether the gTLD was granted Specification 13 or not. The content of the new version of the report should be helpful to browsers and other software vendors trying to make decisions on gTLDs that have signed an agreement, or amendment including Specification 13 (http://newgtlds.icann.org/en/applicants/agb/base-agreement-spec-13-proposed -06dec13-en.pdf). For example, https://bugzilla.mozilla.org/show_bug.cgi?id=1196364. An example and the detail of the requirements considered for this new report are available in the attached .pdf file. Please note that we are not planning on replacing or changing the current newgtlds.csv report, which will continue to be updated as usual. Your feedback is welcome. Should you wish to provide any comments, please send them to gtld-tech(a)icann.org <mailto:gtld-tech@icann.org> by June 30, 2016. Best regards, Eduardo Alvarez Technical Services Sr. Manager ICANN

2 2

A-label and U-label mixing - RDAP query
by Gustavo Lozano April 19, 2016

April 19, 2016

Hello colleagues, Apologies for crossposting. During the public comments period of the "Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars", https://www.icann.org/public-comments/rdap-profile-2015-12-03-en, the following comment was received: "Section 1.4.1 of the Operational Profile is inconsistent with the guidance given in RFC 7482 regarding processing of RDAP queries containing a mixture of IDN A-labels and U-labels. Per RFC 7482, ³IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels². This requirement is not only inconsistent with RFC 7482, it is also counter to the consensus of the IETF community regarding appropriate processing of IDN queries. " Another comment on the same path says: "Allowing A-labels and U-labels will be particularly unworkable for right to left languages unless the RDAP server introduces arbitrary restrictions. It is important to remember that RDAP is intended for machine-to-machine communication. Since RFC 7482 is very clear on this guidance (do not mix the two) any software client that generates this sort of query is broken. With the relative youth of the RDAP standard there is unlikely to be a large install base of software clients with said broken implementation. If ICANN is aware of a software client that has incorrectly implemented the RDAP standard and is now generating queries which combine A-labels and U-labels then ICANN should take its concerns to the IETF where such challenges are considered as part of any implementation discussion. Enshrining bad practice within the Operational Profile will result in needless future changes to the technology or additional service restrictions." The comment is related to the following section of the gTLD RDAP profile: "1.4.1 The RDAP server MUST support Internationalized Domain Name (IDN) RDAP lookup queries using A-label or U-label format [RFC 5890] for domain name and name server objects. The RDAP server MUST accept a mixture of the two (i.e. A-label and U-label format) in the same RDAP lookup query². The purpose of this message is to obtain feedback from this community regarding this issue. We believe that the following text from RFC 7482 is a requirement for the RDAP client: "IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels.". RFC7482 provides an example of why a server may receive a mixture of A-labels and U-labels in the query: "It is possible for an RDAP client to assemble a query string from multiple independent data sources. Such a client might not be able to perform conversions between A-labels and U-labels." RFC7482 gives two options to the server: "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup. In such cases, the response to be returned to the query source may not match the input from the query source. Alternatively, the server MAY refuse to process the query". We believe that the reasoning in RFC 7482 is sufficient to require gTLD RDAP servers to accept and process a query that mixes A-labels and U-labels. Question for this community: is the behavior specified in the gTLD RDAP Profile (I.e. requiring processing of queries that mixes A-labels and U-labels) consistent with RFC 7482? Your feedback is appreciated. Regards, Gustavo

4 4