Move Address definitions/interfaces from the Payment Request API.

[rayankans]

The ContactAddress interface used to depends on the PaymentAddress
interface defined in the Payment Request spec. That definition was
recently removed in w3c/payment-request#955.

[rayankans]

cc @jcayzac, as per your request in w3c/payment-request#955 (comment)

[beverloo]

Change SG, but please do add a warning (linking to an open issue on this repo) asking whether this is the right spec for the interface to live, giving it a place for discussion.

[jcayzac]

cc @jcayzac, as per your request in w3c/payment-request#955 (comment)

Thanks! Also, reiterating the need to review the issues that were closed by w3c/payment-request#955, since they may still be valid in this new context.

Regarding the attributes of ContactAddress (or whetever new name the interface may take if moved in its own document), I think there's an important difference between contact management and payment handling: the former is a simple negotiating between a relying party and the end-user's address book, while the latter had to be very specific on semantics because of the additonal actor in the payment flow (the payment handler). That is why PaymentAddress had global region-independent semantics for its address fields. For an address book entry directly consumed by a relying party I believe the address fields should follow the structure-first region-dependent semantics of the autocomplete atribute instead.

Related

• The HTML autocomplete attribute > Administrative levels in addresses > Variations https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#variations
• Matching PaymentAddress fields to autofill attributes Matching ContactAddress fields to autofill attributes #71

[marcoscaceres]

Happy it found a new home 🎉

Also, if I can get Mozilla to support this, it should be (fairly) trivial to refactor the existing PaymentAddress implementation to use this.