Internationalised/Localised postal code and country elements
Gavin Brown <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
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. _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg