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 Mon, 11 Jul 2022 at 09:46, 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 <+1%20917-450-8783>
>
>
>
>
>
>
>

-- 
smcgruer • he / him