search

w3c / contact-picker

Contact Picker API
https://www.w3.org/TR/contact-picker/
Other
74 stars 8 forks source link

Move Address definitions/interfaces from the Payment Request API. #39

Closed rayankans closed 3 years ago

rayankans commented 3 years ago

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

rayankans commented 3 years ago

cc @jcayzac, as per your request in https://github.com/w3c/payment-request/pull/955#issuecomment-837689399

beverloo commented 3 years ago

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 commented 3 years ago

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