Re: Call for Consensus to Remove regionCode from Payment Request API - Review requested by 24 January

Vote: Reach does not support the proposal to remove "regionCode" from the
API.
Justification:  Address verification systems, though not supported
worldwide, rely on standardized input for addresses, including the region.
Though not all countries have regions, there should be a standardized
method of including this field as input for those countries that do.

David

On Thu, Jan 17, 2019 at 8:47 AM Ian Jacobs <ij@w3.org> wrote:

> Dear Web Payments Working Group Participants,
>
> Payment Request API today allows the party that calls the API to
> request a "regionCode," defined to be:
>
>      "[...] an [ISO3166-2] country subdivision name (i.e., the characters
>       after the hyphen in an ISO3166-2 country subdivision code element,
>       such as "CA" for the state of California in the USA, or "11" for the
>       Lisbon district of Portugal)."
>
> As of today (documented in issue 816 [1]) there are no implementations
> that support regionCode. Browser vendors have indicated a desire to
> implement the feature, but no timeline.
>
> This is a call for consensus to remove "regionCode" from Payment
> Request API. Removal at this time does not preclude it being added to
> a future version of the specification. Indeed, the current expectation is
> to return the feature to the specification after version 1 has been
> published as a Recommendation.
>
> Working Group participants are invited to respond to this proposal by
> 24 January 2019 (10am ET).
>
> For the co-Chairs,
> Ian Jacobs
>
> [1] https://github.com/w3c/payment-request/issues/816
>
> =========
> PROPOSAL
>
> That the Web Payments Working Group drop regionCode from the Payment
> Request API specification by adopting this pull request (possibly with
> minor editorial changes):
> https://github.com/w3c/payment-request/pull/823
>
> Please indicate one of the following in your response:
>
> 1. Support the proposal.
> 2. Request some changes, but support the proposal even if suggested
> changes are not taken into account.
> 3. Request some changes, and do not support the proposal unless the
> changes are taken into account.
> 4. Do not support the proposal (please provide rationale).
> 5. Support the consensus of the Web Payments Working Group.
> 6. Abstain.
>
> We invite you to include rationale in your response.
>
> If there is strong consensus by 24 January 2019 (10am ET) for the
> proposal, it will carry.
>
> ==========================
> Formal Objections
>
> * If you wish your LACK of support to publish to be conveyed to the
> Director and reviewed, please include the phrase "FORMAL OBJECTION” in your
> response and be sure to include substantive arguments or rationale. The W3C
> Director takes Formal Objections seriously, and therefore they typically
> require significant time and effort to address.
>
> * Silence will be taken to mean there is no Formal Objection.
>
> * If there are Formal Objections, the Chairs plan to contact the
> individual(s) who made them to see whether there are changes that would
> address the concern and increase consensus to publish.
>
> For more information, see:
> https://www.w3.org/2018/Process-20180201/#Consensus
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>
>

-- 

David Benoit

*Chief Technology Officer*

benoit@withreach.com | +1 514 701 0419
------------------------------
You are receiving this email because you opted in and consented to
receiving information from Reach. If you would rather not receive this type
of communication please email compliance@withreach.com to unsubscribe.