comments on the draft
- To: <ird-wg-report@xxxxxxxxx>
- Subject: comments on the draft
- From: "Dr. Sarmad Hussain" <sarmad@xxxxxxxxxx>
- Date: Sun, 20 Feb 2011 00:23:57 +0500
Some comments in my personal capacity.
The models being proposed face the following challenges:
1. Fundamentally, registrant is the owner of the IRD. Registrar is
maintaining the data on his/her behalf and sharing it for use by others,
including registry, law enforcement, community and others.
2. If translation or transliteration is provided by the registrar (and
not by the registrant), the fundamental ownership of data is violated (and
data consistency problems occur; see 4. below). Thus, registrar should not
generate registrant data on its own (in any language). But this is what is
being proposed by Models 3 and 4.
3. Following on the principle in 1. above, if the registrant is
monolingual, which is the expectation and motivation behind the IDNs, user
cannot verify the translation or transliteration of the data being provided
in a “must-be-present” script. Thus, the “must-be-present” script, e.g.
ASCII, is also not a viable option, as required by Models 1, 3 and 4. How
can one make a registrant accept responsibility of data verification in a
language/script which s/he does not recognize and understand?
4. Translation or transliteration process is highly subjective. There
will be problems or both consistency and accuracy.
a. Transliteration or translation is not possible on the knowledge of
the script alone. One would need to know the language
b. Transliteration or translation may vary significantly across
languages using the same script
c. Two people may translate/transliterate differently even within a
d. The same person may translate/transliterate differently at different
times for the same language
Taking a concrete example, محمد is a commonly used name in the Arabic script
based languages (270 million pages for محمد found on Google on 19th Feb.
2011). It is translated(?)/transliterated(?) in ASCII (?) in the many ways
(some listed below):
Mohammed, Mohamed, Muhammed, Muhamed, Mohammad, Mohamad, Muhammad, Muhamad,
… (one can google محمد to view these spelling variations) .
So if محمد is the name of a monolingual registrant (a likely possibility),
which spellings will Registrar A choose? Will Registrar B choose the same
spelling? Also, how would a registrar determine which particular spellings
to use for a particular registrant? How would the monolingual registrant
ever verify such information even if presented such data by the registrar or
by a third organization which does transliteration or translation?
Thus, even Model 2 has challenges. Also, as spelling is personal choice and
arbitrary, harmonizing data (4.5.6 in the draft) in any automated way (e.g.
using tables) will create erroneous data (Person A and Person B are named
محمد but spell their names differently in ASCII, e.g. in their passports)
5. IRD should follow the IDN protocol specifications, and specifically
the stipulation of the registry. This is possible if the language table and
rules published by the registry is also used by the registrar to verify IRD.
6. There is a Model 5: Registrant provides the data in the script and
language of their choice. The registrant specifies the language (locale(?))
of the data (this is critical for any transliteration or translation).
Transliteration or translation of IRD in any other language is not required
(so there is no “must-be-present” language)
Any individual/organization that needs this data for legitimate use can
access the data and if needed transliterate/translated the data based on the
language information provided by the registrant. This is the simplest model
(simpler is better?) which keeps data consistent and does not violate the
fundamental right of the registrant to be the sole provider of IRD.
Further, if automatic tools and agencies can be used for
transliteration/translation, the onus to find such possibilities should be
on the user of the data, not the provider or maintainer of the data.
If this simple model has been discussed, why is it not been short-listed?
7. In conclusion:
a. A monolingual registrant could only be expected to provide IRD in a
single language of s/he speaks
b. Registrar should ensure that the IRD is based on characterset and
variants based on the “language” table and rules for the IDN TLD, as
provided by the registry
c. Translation and/transliteration should be the responsibility of the
person or organization that wants to use IRD
d. Models 1-4 do not fulfill these conditions. A simpler Model 5 is
proposed for consideration
In addition, comments on Section 5.
If Whois service returns the variants, should it also tell status of each
variant: reserved, blocked, allowed, primary; as requested by registrant and
maintained by registry?
It is not clear from the document what the benefits/reasons are for Whois
service to return the U-label, and why it is not left to the Whois client?
Why shouldn’t the Whois service only return A-label?