Re: [w3c/payment-request] PaymentAddress 'region' inconsistencies (#663)

> @sebsg You wrote: "We have the data for most countries and I'm trying to get the data for the rest." Is this an open-source dataset (or standardized registry) that other implementations can use? A common approach would help reduce user confusion across browsers.

IIUC, it's from https://github.com/googlei18n/libaddressinput/wiki/AddressValidationMetadata and it's what we use in Fx already.

> @mnoorenberghe The original posting from @TSMatthews mentioned shipping options, so it seems that we wouldn't necessarily need to gather the regionCode in places like Belgium that don't require regions for mail delivery. However, supporting that level of nuance adds a further level of business logic to the code, and it seems easier to gather the regionCode if the country has defined regions in the dataset / registry. What do you think?

Shipping options require knowing two things:
1. Can I ship to this address (taking into account regional laws)?
2. How much are the shipping options?

My point is that in order to know (1), you may need to know the region if there are regional laws (e.g. if one province in Belgium prohibits the purchasing of ivory).

libaddressinput doesn't currently have regions for [Belgium](https://chromium-i18n.appspot.com/ssl-address/data/BE) and indicates that they're not required for mailing labels so it's easiest for us to pretend they don't exist but I'm trying to get this understanding standardized as I don't want some browsers returning regions for Belgium and others not. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/663#issuecomment-373606760