PR Request for Payment Request and Payment Method Identifiers #377
Comments
ianbjacobs
added
Entering PR
|
Update: I wrote to the WG about my omission of PMI and asked for feedback by 10 September at noon ET: |
|
Previous transition: #346 |
|
For the record: "A Proposed Recommendation may identify itself as intending to allow new features (class 4 changes) after its initial publication as a Recommendation," I don't see any of that in the proposed SOTD. Is it intentional? |
|
I would not say that it's intentional because we did not discuss it. Therefore I would say it's ok this way because nobody has suggested it. |
|
I mentioned that I sought feedback from the WG by 10 September on advancing PMI. I have heard no objections from the WG. |
|
Note: i18n WG is still pondering w3c/payment-request#948 |
|
@ianbjacobs if it's not too late, I strongly encourage you to ask the WG regarding the mention in the SOTD since it will affect how the future Rec can be revised. cc @marcoscaceres . While knowing the outcome of that discussion is not a blocker for the Director, you should solve this before the actual PR publication. |
|
@plehegar, do you have an example of a spec that does this? |
|
Pubrules recommends: For an example, see the sotd of WebRTC 1.0. |
|
Our proposed charter sets and expectation that we will not add new features to PR API during the next charter period. Would it make sense to include that sentence in the spec ("just in case") but still set an expectation that we don't plan to add features in this version of the charter? |
|
Hmmm… I think we should add this. Specially as SPC builds on PR API, which may bring unexpected feature requests. Ps: we don’t need to add it manually. ReSpec supports setting a class attribute on the sotd section. |
Thanks for flagging this, @plehegar It does appear that the label property defined in 8. PaymentItem dictionary is not covered by the note added by #944 since the property cannot reasonably be translated by the user agent nor the API. For this property, shouldn't the spec note that it is the responsibility of the Web application to provide a language appropriate item description? |
plehegar
added
Awaiting Working Group
|
@swickr, The need is for the site to label the text direction and language. The spec does not provide a mechanism and implementations don't provide a mechanism. |
|
@swickr, I found a reference to ISO 3166-2 that was not used in the document, so I removed it. I think @ianbjacobs will regenerate the document. |
|
Transition approved. @plehegar has pinged i18n a couple of times on w3c/payment-request#948. This can proceed. |
|
Thank you! |
Document title, URLs, estimated publication date
Payment Request API
https://w3c.github.io/payment-request/
Payment Method Identifiers
https://w3c.github.io/payment-method-id/
Estimated publication date: 21 September 2021
Abstract
https://w3c.github.io/payment-request/#abstract
https://w3c.github.io/payment-method-id/#abstract
Status
https://w3c.github.io/payment-request/#sotd
https://w3c.github.io/payment-method-id/#sotd
Link to group's decision to request transition
https://lists.w3.org/Archives/Public/public-payments-wg/2021Jun/0013.html
Note: The decision does not mention Payment Method Identifiers by name, which is a bug. The group's
expectation for years has been to advance these documents together; see, for example:
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0020.html
Because PMI has not changed in a long time (other than to remove "basic card" as a standardized
payment method identifier), the staff contact neglected to mention it in the call for consensus to
advance to PR.
Changes
https://w3c.github.io/payment-request/#changelog
https://github.com/w3c/payment-method-id/commits/
Requirements satisfied
The specification has been published for multiple years and has converged
around an interoperable set of features.
Dependencies met (or not)
Yes.
Wide Review
PR API has been reviewed over many years, with most recent changes being to remove features.
There was I18N review during this CR period:
https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aclosed+label%3Ai18n-needs-resolution+
There was also privacy review, leading to removal of features related to addresses.
w3c/payment-request#842 (comment)
Issues addressed
https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aclosed
https://github.com/w3c/payment-method-id/issues?q=is%3Aissue+is%3Aclosed
Formal Objections
No new Formal Objections since the previous transition.
Implementation
Payment Request API is implemented in Chrome and Webkit.
https://caniuse.com/payment-request
Payment request implementation report:
https://w3c.github.io/test-results/payment-request/all.html
Payment method identifiers implementation report:
https://w3c.github.io/test-results/payment-method-id/all.html
Patent disclosures
https://www.w3.org/groups/wg/payments/ipr
The text was updated successfully, but these errors were encountered: