Rik, all, Correct, contracted parties are not required by the recommendations to perform the transformation. RDDS (I.e. RDAP) consumers are responsible to perform the transformation, if not provided by the contracted party.
The language / script used by the registrant is a key data point required by the RDDS consumer to perform the transformation. My understanding of the recommendations is that capturing the language / script used by the registrant at the point of data entry and transmitting this information (i.e. language-tag) to the Registry is a requirement. Regardless, if both (i.e. transformation, and capturing / providing the language-tag for data provided by the registrant) requirements end up being optional, the policy will allow contracted parties to support this, and some may opt to do it, therefore an standard mechanism is needed. The final policy language is being discussed in the IRT (Implementation Review Team). If you are interested in joining the IRT, please send an email to Brian Aitchison <brian.aitchison at icann.org> as the deadline of call for volunteers already passed. Regards, Gustavo From: Rik Ribbers <rik.ribb...@sidn.nl> Date: Thursday, July 21, 2016 at 03:36 To: Gustavo Lozano <gustavo.loz...@icann.org> Cc: "regext@ietf.org" <regext@ietf.org> Subject: Re: [regext] regext - Update to a Meeting Session Request for IETF 96 > Gustavo, > > I have been reading > http://gnso.icann.org/en/issues/gtlds/translation-transliteration-contact-fina > l-12jun15-en.pdf until Recommendation #1 > > What happened to Recommendation #1 The Working Group recommends that it is not > desirable to make transformation of contact information mandatory. > > Is this still applicable? And if so, why would any registry even consider > implementing such a complex EPP extension? > > Gr, > Rik > > >> On 25 Jun 2016, at 01:38, Gustavo Lozano <gustavo.loz...@icann.org> wrote: >> >> Hello Colleagues, >> >> >> I would like to discuss the status of: >> >> * draft-ietf-regext-tmch-func-spec-01 >> * draft-lozano-rdap-nameservers-sharing-name-01 >> >> >> I am working in the support for Transliteration and Translation of Contact >> information in RDAP and EPP, see >> http://gnso.icann.org/en/issues/gtlds/translation-transliteration-contact-f >> inal-12jun15-en.pdf. >> >> The following draft is the initial version to support Transliteration and >> Translation in RDAP: >> https://tools.ietf.org/html/draft-lozano-regext-rdap-transf-contact-inf-00 >> >> >> A draft to support Transliteration and Translation in EPP should be >> published next week. >> >> >> I think that 15-20 minutes should be enough for the four drafts. >> >> Regards, >> Gustavo >> >> >> On 6/10/16, 07:00, "regext on behalf of James Galvin" >> <regext-boun...@ietf.org on behalf of gal...@elistx.com> wrote: >> >>> The change that was made was to reduce the requested schedule time to 90 >>> minutes from 2 hours. >>> >>> It seems the IETF schedule is overbooked and they were asking WG chairs >>> to reconsider their meeting requests. >>> >>> Although we have a number of active documents at this time we are not >>> expecting new work discussions as we had the last time, so the chairs >>> believed the shorter time was reasonable. >>> >>> Thanks! >>> >>> Antoin and Jim >>> >>> >>> >>> On 10 Jun 2016, at 9:40, "IETF Meeting Session Request Tool" wrote: >>> >>>> An update to a meeting session request has just been submitted by Jim >>>> Galvin, a Chair of the regext working group. >>>> >>>> >>>> --------------------------------------------------------- >>>> Working Group Name: Registration Protocols Extensions >>>> Area Name: Applications and Real-Time Area >>>> Session Requester: Jim Galvin >>>> >>>> Number of Sessions: 1 >>>> Length of Session(s): 1.5 Hours >>>> Number of Attendees: 50 >>>> Conflicts to Avoid: >>>> First Priority: dnsop dnssd dprive dbound dane lager homenet >>>> Second Priority: ianaplan >>>> >>>> >>>> >>>> Special Requests: >>>> Please avoid conflicts with, in order: >>>> 1. DNS BOFs >>>> 2. ART BOFs >>>> 3. ART WGs >>>> --------------------------------------------------------- >>> >>> _______________________________________________ >>> regext mailing list >>> regext@ietf.org >>> https://www.ietf.org/mailman/listinfo/regext >> _______________________________________________ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
