<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [ssac-gnso-irdwg] Open discussion: what do we require from IRD?
- To: Jay Daley <jay@xxxxxxxxxxx>
- Subject: Re: [ssac-gnso-irdwg] Open discussion: what do we require from IRD?
- From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
- Date: Wed, 13 Jan 2010 06:52:19 -0800
On 1/6/10 4:23 PM Jan 6, 2010, "Jay Daley" <jay@xxxxxxxxxxx> wrote:
> Hi Dave
>
> On 7/01/2010, at 6:20 AM, Dave Piscitello wrote:
>
>> 1) What do we require from internationalized registration data?
>> b) that registration data be extensible to accommodate users
>> who would benefit from the ability to submit and have registration
>> information displayed in "familiar" characters from local
>> languages and scripts?
>
> We need to be clear on the distinction between the various elements of
> registration data that could be separately internationalised:
>
> - domain names
> - entity names
> - postal addresses
> - email addresses
> - telephone numbers
>
> The questions we ask need to address these elements individually.
Agree. Let's consider these separately
- domain names
Standards exist for representation of domain names in U- and A-labels. These
are sufficient and I don't think it's in our scope to suggest change here.
- entity names
Let's break this into two sub-groups:
{sponsoring registrar} and
{registrant, admin contact name, tech contact name}
In earlier discussions, it's been proposed that the sponsoring registrar
name should always be displayed in machine-readable form (meaning, US-ASCII7
subset of the Latin-1 character set). The rationale offered for this is that
applications and automation use the sponsoring registrar as a search element
in databases of registrar contacts and that these are largely ASCII encoded.
This begs the question of whether, in the future, ICANN would accredit a
company whose entity name makes use of extended character sets as a
registrar, but I felt it useful to share the concern with the group.
- postal addresses
We could adhere to the conventions the UPU establishes or choose our own.
- email addresses
We could adhere to RFC822-MIME conventions or choose our own.
- telephone numbers
We could adhere to ITU telephony conventions or choose our own.
Other ideas?
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|