Subject: [provreg] Internationalised/Localised postal code and country elements

From: Gavin Brown <[email-masked]>
Date: Wed, 14 Nov 2012 08:05:48 +0000

Dear colleagues,

RFC 5733 puts the <contact:pc> and <contact:cc> elements inside the <contact:address> element, presumably so that they are grouped together with the other address elements.

However, this means that a contact could have two representations of its postal address - one with type="loc" and one with type="int" - which each have a different country and postcode. Since both of these fields consist solely of ASCII text (my research suggests that internationally, postal codes are solely alphanumeric), i cant see any benefit to allowing this, and I can conceive of a scenario where such a difference could cause operational or security problems (eg an abusive or malfunctioning domain appears to be registered in different territories, depending on the I18N preferences of a WHOIS client).

A "proper" fix would be to change the schema move the <contact:pc> and <contact:cc> elements into the <contact:postalInfo> element, but that would be rather disruptive as it would require a change to clients, so I thought it was worth raising this issue so that other server operators can decide whether to ensure that these fields are identical across both address types.

Regards,

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 14 Nov 2012 00:34:57 -0800

Hi Gavin,

I actually had the same thought as you do, but I'm not sure if "loc" and "int" would be the same...

pc and cc are defined as:

 <simpleType name="ccType">
      <restriction base="token">
        <length value="2"/>
      </restriction>
    </simpleType>

    <simpleType name="pcType">
      <restriction base="token">
        <maxLength value="16"/>
      </restriction>
    </simpleType>

So technically a postal code can be provided in any script as well as the country code as long as the length value is met.

Folks that communicate in writing using non ascii characters would find that useful.

regards,

On Nov 14, 2012, at 12:05 AM, Gavin Brown <[email-masked]> wrote:

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 14 Nov 2012 10:12:16 +0100

On 14/11/12 09:34, Francisco Obispo wrote:
> Hi Gavin,
>
> [...]
>
> So technically a postal code can be provided in any script as well as the
> country code as long as the length value is met.

Hi,

at least the country code should be identical in both variants and ASCII only, 
as RFC 5733 requires the country code to be one of the ISO 3166 codes.

Regards,

Klaus

---

From: Gavin Brown <[email-masked]>
Date: Wed, 14 Nov 2012 10:26:46 +0000

> Folks that communicate in writing using non ascii characters would find that useful.

According to Wikipedia (so usual caveats apply, but the article looks
pretty thorough), postal codes are almost exclusively numeric around the
world, with just a few countries using A-Z (mainly the UK and former
British colonies).

http://en.wikipedia.org/wiki/Postcode#Character_sets

There are no official international standards that specify this, but it
appears to be a de-facto standard that post codes are exclusively ASCII.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Nov 2012 09:59:37 -0500

> pretty thorough), postal codes are almost exclusively numeric around the

And what do you mean by "numeric"?  Remember that not all digits are
the ones familiar to those with a US keyboard.

Internationalization and localization are the twisty maze of passages.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Gavin Brown <[email-masked]>
Date: Wed, 14 Nov 2012 16:11:24 +0000

> the ones familiar to those with a US keyboard.

I mean the range of code points from U+0030 to U+0039 inclusive.

Here's another source which shows the format used by each country:

http://www.geopostcodes.com/resources

> Internationalization and localization are the twisty maze of passages.

You are not wrong.

G.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Nov 2012 11:53:06 -0500

> I mean the range of code points from U+0030 to U+0039 inclusive.

That's what I figured.  The problem is, not everyone writes their
numbers that way, and many people who have these other ways to denote
the "same digits" think that they're equivalent.  In India, I have
observed signs with fairly free intermixing of what I think were
Devanagari digits and digits I recognized as mine.  Fun fact: using
Devanagari, this is a seven: ७.  Better, ५ is a five.  Six is ६.

I have been informed more than once that spreadsheets in the Arabic
world store Arabic-digit input as our familiar digits, and then
translate back at presentation time.  This is so that character
encoding can't mess up arithmetic operations. 

So, if someone is entering a localized version of an address and they
get to the post code field, are we confident that they're not going
to use localized digits, even if they use ASCII letters?

(None of this is to denigrate your suggestion, which I think is
reasonable.  I just want us to understand what rule we're making and
what the consequences will be, for whom.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]