[w3c/browser-payment-api] Request to remove 'careOf' field from the PaymentAddress interface (#244)

**Summary**: The [PaymentAddress](https://w3c.github.io/browser-payment-api/#paymentaddress-interface) interface has a `careOf` field which is non-standard (no well-known address standards support it, see below). The `careOf` field is unnecessary, the `recipient` and `organization` fields sufficiently support all necessary use cases. Adding `careOf` poses significant issues in terms of interoperability with existing postal address schemas and APIs.

I’m with the internationalization group at Google who support all aspects of address input, validation, conversion between schemas, and formatting for all countries, including the open source [libaddressinput](https://github.com/googlei18n/libaddressinput).

`careOf` was added in #198 without much discussion. Every new field has potential benefit but may also have a non-trivial maintenance and interoperability cost. As such we think it's important that the value of any new fields is examined carefully and weighed against the cost. The other fields in `PaymentAddress` are there for very solid, defensible reasons. E.g. name & organization are there because depending on the purpose, these are used differently and many major APIs / address schemas have these two fields (or equivalents thereof).

`careOf` is problematic because it requires everyone handling addresses to retain the field type, decide where in input/editing forms and formatting it goes, offer UI for it and internationalize all of this for hundreds of countries and decide what to do with it when converting to & from all the other schemas / APIs which don’t have this field.
This would be fine if it provided enough value to outweigh the cost. But the value is unclear and the interoperability & handling cost is very significant. Companies / existing solutions can handle `recipient` and `organization` fields. Which service / library can format / validate addresses in 200+ countries with such a `careOf` field?


List of major postal address / shipping schemas & APIs **none of which have a careOf field** (or similar) as a separate field but do have a name/contact and a organization/company/firm field:

*   **libaddressinput** (open-source library) has organization & recipient. ([link](https://github.com/googlei18n/libaddressinput/blob/master/common/src/main/java/com/google/i18n/addressinput/common/AddressData.java))
*   ***H-card / adr microformat*** have a p-name and a p-org field. ([adr](http://microformats.org/wiki/adr) depends on the parent [h-card](http://microformats.org/wiki/h-card) for addressee fields)
*   **USPS**’ own “International Label APIs” doesn’t have a careOf field. They have ‘ToFirm’ and ToName (or rather ‘ToFirstName’, ‘ToLastName’) fields. ([link](https://www.usps.com/business/web-tools-apis/international-shipping-label-api.htm))
*   **Fedex** has a field for the contact & CompanyName, nothing separate for careOf ([link](http://www.fedex.com/templates/components/apps/wpor/secure/downloads/pdf/201408/ShipServiceWSDLGuide_v2014.pdf), see “Table 57: Recipient Information Elements”)
*   **UPS** has AttentionName and CompanyName fields in ShipTo ([zip download](https://www.ups.com/gec/techdocs/pdf/Shipping_Pkg_Gnd.zip), see “Shipping Package XML Developer Guide.pdf” section /ShipmentConfirmRequest/Shipment/ShipTo)
*   **easypost** have a field for the name and for the company. ([link](https://www.easypost.com/docs/api#addresses))
*   **Authorize.net** has a firstName, lastName & company in its shipTo address fields. ([link](https://developer.authorize.net/api/reference/))
*   **Android Pay**’s UserAddress has CompanyName and Name fields. ([link](https://developers.google.com/android/reference/com/google/android/gms/identity/intents/model/UserAddress))
*   **xNAL 3.0** (as part of OASIS CIQ) models it as “Addressee” (0+) which can have PartyName (person or org or unstructured) and a DependencyName (same). xNAL is a very powerful schema (and flexible regarding granularity), not the simplest to use (in its full spec). Yet it doesn’t break out careOf as a separate field. ([link](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq#download))

We don't know of any standard / API which has these 3 fields (`careOf`, `recipient`, `organization`), irrespective of the exact field name (e.g. `recipient` vs. `name` vs. `contact`). We are aware of schemas / APIs which only have a single name/contact field rather than also having a separate field for `organization`, yet `organization` is there in the above mentioned APIs / schemas for good reasons.

We think there’s overwhelming evidence against a `careOf` field. If that’s not the case, please present the case to have a `careOf` field.

To summarize: The `recipient` field is good enough (together with the `organization` field). The `recipient` field is and can be used instead of the `careOf` field.

Thanks for your consideration,
Andy on behalf of the team behind libaddressinput, address formatting in Google Maps, etc.

-- 
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/browser-payment-api/issues/244