Re: Call for Consensus to Publish Payment Request API 1.1 as a First Public Working Draft - RESPONSE REQUESTED BY 18 JULY

1. Support the proposal.

On July 11, 2022 9:45:43 a.m. EDT, Ian Jacobs <ij@w3.org> wrote:
>Dear Web Payments Working Group Participants,
>
>This is a Call for Consensus to publish the following specification as a First Public Working Draft:
>
>  Payment Request API
>  https://w3c.github.io/payment-request/
>  (8 July 2022 draft plus any non-substantive edits).
>  Expected Title: Payment Request API 1.1
>  Expected short name: payment-request-1.1
>
>Publication as a First Public Working Draft does NOT indicate that the document is complete or represents Working Group consensus.
>
>PLEASE RESPOND to the proposal by 18 July 2022 (14h00 UTC).
>
>For example, if you support the proposal, respond to this list with "1. Support the proposal."
>
>We thank the editors for preparing this document.
>
>For the co-Chairs,
>Ian Jacobs
>
>----------
>BACKGROUND
>
>W3C published [1] Payment Request API 1.0 as a Proposed Recommendation
>in September 2021. Since then, W3C has been working to resolve two
>Formal Objections from W3C Members; see the Team Report [2] for
>details. At this time, a Council is evaluating the Formal Objections
>to determine whether Payment Request API 1.0 should advance to
>Recommendation or be returned to the Working Group for changes.
>
>In the meantime, the Editors have continued to update the Editor's
>Draft [3]. See below for information about changes since September
>2021.
>
>Developers and implementers are taking interest in the new features
>defined in the Editor's draft. To provide them with more confidence
>about these features, the Chairs would like to formally publish the
>Editor's Draft as a new W3C Working Draft. This will also provide the
>group with a foundation for potential discussion at TPAC about the
>future of Payment Request.
>
>It is not uncommon for a Working Group to work on different revisions
>of a specification simultaneously (e.g., see the CSS WG). With that in
>mind, and because our current charter [4] anticipates enhancements to
>Payment Request 1.0, we seek to publish a first 1.1 draft.
>
>Note: If Payment Request API 1.0 advances to Recommendation, the
>Editors will determine whether it would be preferable to fold these
>changes into an evolving 1.0 Recommendation, or to continue to nurture
>a 1.1 branch. At the current time, we do not need to make that
>decision.
>
>[1] https://www.w3.org/blog/news/archives/9269
>[2] https://www.w3.org/2022/03/prapi-fo-report.html
>[3] https://w3c.github.io/payment-request/
>[4] https://www.w3.org/Payments/WG/charter-201912.html
>
>--------
>PROPOSAL
>
>That the Web Payments Working Group request that the W3C Director approve publication of Payment Request API 1.1 as a First Public Working Draft on the Recommendation Track.
>
>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.
>
>------------------------------------------------
>CHANGES SINCE PROPOSED RECOMMENDATION (PUBLISHED SEP 2021)
>
>See the diff:
> https://www.w3.org/2022/07/prapi-diff-20220707.html
>
>Substantive changes (the primary reason to publish):
>
>* Two new definitions for both the IDL type that
>  PaymentMethodData/data should be converted into, and for the
>  validation steps that a payment method will perform on it. This
>  allows payment method specs to define these in a way that is
>  cross-linkable to the PaymentRequest specification. This is useful
>  for Secure Payment Confirmation. This change is mostly editorial,
>  except that it allows for arbitrary error types to be thrown during
>  validation (previously only TypeError would be thrown).
>
>* Passing data on complete(). This is an optional feature that allows
>  payment handler to provide some information about the nature of a
>  completed payment.
>
>* Validate .data on construction. This is an optional feature
>  supported in Webkit.
>
>Non-substantive changes:
>
>* Added internationalization support for human readable labels (#971)
>
>* Low-level changes related to imported concepts (e.g., whose names changed
>  and we needed to update our reference to them).
>
>* Editorial fixes (example, cross-reference fix)
>
>-----------------
>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. Therefore, please limit any Formal Objections to issues
>  related to the scope of this document rather than technical
>  content where the Working Group has not yet made a decision.
>
>* 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/2021/Process-20211102/#Consensus
>
>----------
>NEXT STEPS
>
>Transition Request Following a Working Group Decision to Publish
>
>* In the case where this Call for Consensus results in a decision to
>  publish, the Chairs plan to request approval from the W3C Director
>  to publish a First Public Working Draft (including review of any
>  Formal Objections).
>
>--
>Ian Jacobs <ij@w3.org>
>https://www.w3.org/People/Jacobs/
>Tel: +1 917 450 8783
>
>
>
>
>
>