<<<
Chronological Index
>>> <<<
Thread Index
>>>
Comments from Key-Systems GmbH
- To: comments-transliteration-contact-initial-16dec14@xxxxxxxxx
- Subject: Comments from Key-Systems GmbH
- From: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>
- Date: Fri, 23 Jan 2015 16:35:59 +0100
Dear Sir / Madam
I am submitting these comments in my capacity as General Counsel of Key-Systems
GmbH, an ICANN accredited registrar based in Germany.
Firstly I would like to thank the members of the Working Group for their
efforts to tackle this matter. Volunteer work is at the core of ICANN's
activities and should be recognized and appreciated.
Key-Systems supports the comments made by the RrSG, and offers the following
additional considerations:
Charter Question 1:
We respectfully suggest that there should be no requirement to translate or
transliterate contact information to a single common language or script.
Instead, registrants should be able to input their data in the language or
script most applicable to them, provided such script is supported by the
sponsoring registrar.
Contactability of the registered name holder is always guaranteed by the
presence of the email address data.
Charter Question 2:
We respectfully suggest that the burden of accessing and understanding contact
information is best placed on the side of the beneficiary of such data, i.e.
the data requestor.
As a requestor may itself use a different script or language from any common
script or language mandated, a mandated translation or transliteration
would only benefit the subgroup of potential requestors that share the common
script or language with the mandated one. Consequently, all requestors who do
not share that
script or language may have to perform the translation or transliteration on
their own anyway. Additionally, free translation services are available that
fulfill
the required purposes for requestors.
Furthermore, transforming all records despite the fact that only a fraction
thereof will ever be requested by a requestor would result in a significant
cost-benefit imbalance.
We therefore support preliminary recommendation #1.
We do not support preliminary recommendation #3 as most registrars operate
internationally. The language the registrar operates under may
therefore not be appropriate to serve customers elsewhere. Such a
recommendation would hinder competition between registrars and hinder free
transferability of
domain names.
We further propose adding an additional tag to the contact data that identifies
the script or language used for easier reference of the requestor
as contemplated in PR #2 and PR #4 should be strictly optional as neither
registrar nor registrant can be expected to know the tag applicable to any
given set of data. Nonetheless,
having the option to display available to registrars and registrants, such a
tag may yield beneficial results for requestors.
We agree with PR # 5 that any optionally provided transformation should only be
presented in additional fields, preserving the originally entered
data in the mandatory fields.
--
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@xxxxxxxxxxxxxxx
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is
addressed. Furthermore it is not permitted to publish any content of this
email. You must not use, disclose, copy, print or rely on this e-mail. If an
addressing or transmission error has misdirected this e-mail, kindly notify the
author by replying to this e-mail or contacting us by telephone.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|