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 11 Jul 2022, at 23: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
> 
> 
> 
> 
> 
>

Received on Thursday, 4 August 2022 01:20:43 UTC