See also: IRC log
IJ: Chairs not here; I want to formalize any decisions with them next week
https://github.com/w3c/browser-payment-api/milestone/8
<scribe> scribe: Ian
zkoch: The editors triaged
yesterday....
... we marked most of MattS's messages as editorial
... we think there are only a few substantive issues
(e.g., 486)
scribe: so the list is
essentially what it was at the end of FTF meeting
... this will be what we will target over the next 2-6
weeks
IJ: Expectation is issue
management, then spec update, then CfC
... Any to discuss today?
zkoch: We want to discuss issue
481 https://github.com/w3c/browser-payment-api/issues/481
... I'd like to get closure on it
... My inclination is to remove it because it does not
materially affect conformance.
IJ: I also note text elsewhere in the spec: ""The methodData supplied to the PaymentRequest constructor SHOULD be in the order of preference of the caller. "
Ken: I haven't thought about that one. As a general policy my view is that if we can remove any language that provides an unintended bias or preference it's better for the health of the spec to neutralize it.
dezell: At the meeting I
commented on this point. Removing any non-normative text is ok.
Simplifying it is ok, and not entangling the spec with
marketing elements is also fine
... I'm ok with the change
mweksler: I think that this thing that we are trying to do is facilitate merchants using the spec. Merchants today have full control over what they do. The language in the spec already "limits their control"
(Spec says "MAY respect their preference)
scribe: I agree that removing the language doesn't materially change anything, but I think the intent is important
<alyver> +1 to Michel's comments.
scribe: I think that we should think about the opposite direction: the user agent MUST respect the merchant prefs
<dezell> clarifying - I am worried about any changes that go against the original intents of the group as chartered. So far I don't see any of those.
Ken: I agree that we want to make things better for the merchant. We may want to look back at the intent in the charter.
scribe: was the goal to get
interop or support preferences?
... merchants, brands, issuers may not all be adequately
represented here
alyver: I want to add a concern
that if the experience is not consistent...if the merchant
cannot specify the ordering, that means that payment methods
may appear in different order in different browsers.
... that would be one concern we would have...Shopify can
control order exactly today
zkoch: The Spec does not today guarantee that
alyver: I realize that.
Proposal: Neutralize language regarding payment method ordering
<rouslan> +0
<adamR> +0
<Ken> +1
<dezell> +1
zkoch: weak +1
<mweksler> -1
<alyver> -1
zkoch: As I understood it, this was identified as a big issue (potentially for networks) so if it's non-normative and can increase support, I'm ok to take it out
<dezell> I agree with Zack's characterization.
Alan: What does neutralize mean
exactly?
... it's the merchant's web site...merchant's need to have
maximum guidance for controlling what they do
... and if there are separate contractual obligations, it's
their responsibility to meet those
<Zakim> dezell, you wanted to bring up another aspect.
dezell: I agree with Zach's
characterization...I see this as mechanical.
... I think as long as we can agree to the mechanical change,
that's probably a good thing.
... even talking about ordering is fraught
... so that's one reason I'm in favor of saying less
Ken: I want to take exception to
the prospect that what the merchant wants trumps other
preferences.
... we would generally seek balance in a payment
environment....costs and benefits to various stakeholders in
the ecosystem.
... there are other stakeholders to balance as well such as
issuers, card networks, etc.
... I believe that changing the language does not change the
merchant's ability functionally
IJ: Would it be useful to include informative text about superior user experience in goal, taking into account information from the environment (including PR API data, user prefs and history, e tc.)
<alyver> +1
Michel: I think that's fine. It seems like it's the direction things are going in; I'm fine with that and adding that language will help a bit
(Add to my list: security considerations)
Michel: The concern I have is
that we are weakening the spec and making it less likely for
merchants to accept it.
... so I'm ok with this change, but want to remain cognizant of
the risk
Ken: Voice of the merchant is important to us. I note the concern. Separately I've been participating in the merchant adoption task force; please get involved to help drive adoption
https://github.com/w3c/webpayments-method-identifiers/milestone/2
Ian: I see none
IJ: Any for CR?
Roy: We only reviewed PR API yesterday
[Zach back]
IJ: what is expectation about resolving them for CR?
zkoch: I will triage the PMI list. I did not see new issues filed.
<scribe> ACTION: Zkoch to triage the PMI list of issues and send to the WG [recorded in http://www.w3.org/2017/04/06-wpwg-minutes.html#action01]
<trackbot> Created ACTION-55 - Triage the pmi list of issues and send to the wg [on Zach Koch - due 2017-04-13].
Zkoch: It's a small list; some
minor modifications to make....
... I don't think anything material will change
MattS: I thought there were some
issues around basic card.
... the one that springs to mind is the "notRequiredFields" for
Basic Card
https://github.com/w3c/webpayments-methods-card/issues/29
IJ: Did editors review that?
zkoch: I will bring this up with
the editors. But I think we've had this discussion before. I
don't think the arguments have changed even if the discussion
has been reraised.
... I don't think we should use "SHOULD"
... I buy the desired functionality (and have heard from
merchants as well)
... so I'd rather acknowledge the functionality and
postpone.
MattS: there's a related issue
about ambiguity about optional parameters (issue 26)
... BasicCard only requires PAN. Others are optional.
[There are different rules for different schemes]
zkoch: Some schemes require
fields, others do not
... I don't know how to enforce "MUST return data"
... I will comment on the issue thread
MattS: Ian has captured it...this
is not about changing implementations. I think chrome meets the
requirements. But the spec is ambiguous
... today a compliant app could decide to return only PAN
... therefore someone could comply and be useless
... to me it makes sense that the spec capture the intent.
zkoch: My general point is that I
agree on what is being said...I don't have a strong objection
to the language, but we can't enforce this or compliance test
for this
... we can add text but hard to enforce.
MattS: I am talking about intent
rather than testing
... I think it's useful to capture the intent
... if the group as a whole feels it's not useful, that's fine,
but I think that the spec today doesn't capture the behavior of
the card networks today
zkoch: When we wrote this it was
under the expectation that whoever was returning the
information would return all the info necessary to complete the
transaction
... I'm ok to add text knowing that we can't enforce it
see also editorial suggestion in => https://github.com/w3c/webpayments-methods-card/issues/26#issuecomment-290087157
zkoch: I will look at issue 26 and look at appropriate langauge.
MattS: I've also made some editorial comments ... would like to see in CR
zkoch: We will also fix those
Things we plan to mark as issues in the spec
https://github.com/w3c/webpayments-payment-apps-api/milestone/2
<zkoch> ::jazz hands::
(No comments)
IJ: My expectation is FPWD before
CR
... which allows reference to FPWD
... from PR API
https://lists.w3.org/Archives/Public/public-payments-wg/2017Apr/0006.html
<zkoch> 2-6!
<zkoch> (more like 6)
<zkoch> Let’s say 4-6
IJ: Any process questions?
13 April