https://mit.webex.com/mit/j.php?MTID=m5b3574cfbd517695ada1d26368d2adc8

Meeting number: 647 126 801

<Ian> scribe: AdrianHB

Flows

matt: we've revised the list of flows

<Ian> list of flows: https://github.com/w3c/webpayments/wiki/Flows

<scribe> ... dropped v.me as we have no volunteers to do it and the consensus was that it was close enough to MasterPass

<scribe> ... dropped a redundant one for SCT

UNKNOWN_SPEAKER: updated flows to be explicit about the use case where data goes directly to PSP (as opposed to via merchant)

<Ian> (Matt has pinged volunteers to remind them of 7 Jan 2016 deadline)

UNKNOWN_SPEAKER: contributors being pushed by Matt to have them in by 7 January

nicktr lists outstanding flows

<Zakim> manu, you wanted to ask if it would be helpful to integrate flows into specs? If so, which ones?

nicktr: Matt, have you got confirmation that the contributors will have theirs in by 7 Jan

matt: not all

manu: which flow is most ready to test against the proposals?

matt: I'd recommend the standard debit/credit charge card as a start (simple first)
... where are we on standardising terminology with the IG?

<manu> ACTION: Manu to integrate Standard flow into Web Payments CG's Browser API spec. [recorded in http://www.w3.org/2015/12/17-wpwg-minutes.html#action01]

<trackbot> Created ACTION-10 - Integrate standard flow into web payments cg's browser api spec. [on Manu Sporny - due 2015-12-24].

nicktr: It was raised at the IG. There is still not consensus on the use of the word app. I believe that the feeling was that if we have a working set of terms we should use them and the IG will work out how those relate to the broader industry terminology.

ian: +1 to that synopsis. In additiona there are IG memebrs in the WG to ensure there is feedback
... there is a general q about how we are using the flows?
... how are we prioritising flows and using them for evaluation of the proposals

matt: my understanding is that what's listed is the prioritised set (no weighting within that set)
... I have started analyzing the flows and noting this in the wiki
... I am not sure if I'll get through that by 7 Jan but it would be great if that document was built upon for the evaluation

ian: I have added a note to the wiki that states the flows submitted by 7 Jan are the ones we will use

<zkoch> We’re also using the flows as a sanity check against any API changes we make

manu: I'm planning to test how the flows and proposals match up

evaluation criteria

nicktr: The chairs have been discussing how we can define a way to evaluate the proposals.

<Ian> AHB: I think it will be great to evaluate proposals against the flows, but I don't think that will be sufficient to tell us which proposal to adopt

<nicktr> adrian: would be great to evaluate the flows and the specs, but not sure that this will allow us to evaluate the proposals

manu: we need to hear from the group on this topic
... I'm concerned that we are not making progress on defining the feature set we need
... the editors took and action to review them and log issues which i have done
... typical WG process is to raise issues and then make resolutions on those issues
... there is a lot of discussion but we don't seem to be getting to resolutions
... coming up with evaluation criteria is hard. Not sure doing that would be a good use of our time. I think we should discuss the issues and resolve them by updating the specs.

<Zakim> manu, you wanted to say he was planning on using the flow in the appendix to show how the API achieves the flow. and to say he expects the experiment to be a partial failure, but

manu: I don't think we should keep the specs separate as this delays the process of getting consensus

<ShaneM> The specs should not drive the requirements. The requirements should drive the creation of a spec.

<manu> +1 ShaneM

<dlongley> +1 ShaneM

<dlongley> +1 to bringing issues to this call, working through them, and then changing specs to reflect the consensus decision.

nicktr: my sense (personal) is that the proposals will continue to be seperate for a while longer. I note and agree with your observation that there are a lot of open issues and no resolutions. Shoudl we be resolving them on the call or setting deadlines for resolution?

<manu> +1 to bringing issues that have had a lot of discussion to the call

<Ian> +1 to bringing the salient issues to this call (as we have done today re: HTTP API)

zkoch: it sounds like we are treating the specs as final and saying we need to evaluate them and pick a winner

<manu> +1 to Zach - we shouldn't view the specs as "done and ready" and "ready to be chosen"

<dlongley> +1 specs are "works in progress" and this call is the venue to make decisions on the issues

zkoch: I think we need to keep iterating on the specs and resolve the issues with each

<manu> -1 to keeping the specs apart for 1.5 months.

<manu> +1 to MattS for doubling the work that we're having to do.

<manu> (as in, that's what's happening)

matt: I appreciate that it would be nice to keep the proposals separate but we are doubling the work. I'd like to see a comparison of the two that we could bring to the call and debate.
... example currency format should be debated when there is a single spec

ian: ack many points made. There is value to the way things are proceeding.
... lot of input to date. I am also getting external eyes on the proposals which is valuable.
... don't want to deny that we are adding cost by having two proposals
... support matt's proposal that we prioritise the issues and address the bug ones in the call
... chairs and team contacts will work on this
... +1 for letting the specs evolve independantly for a while longer

nicktr: consensus that we bring prioritised issues to the call
... don't seem to have consensus on when to merge specs

<Ian> (The meta-instrument is a human brain)

<Zakim> manu, you wanted to note that the issues have been raised as "compare/contrast questions" and to wring his hands around timeline. and to request that we start discussing issues

manu: when I reviewed the specs I tried to raise issues that compared and contrasted the specs. i.e. create an issue that asks a question. mention how each spec handles the question and then discuss.
... I'm also concerned that not merging the specs is putting off difficult discussions and it will be hard to merge the specs just before we publish a FPWD

<Ian> IJ: My view is that the FTF meeting will be the place where we resolved the differences and end up with a single spec thereafter

+1 to Ian

<Zakim> ShaneM, you wanted to ask how we handle meta issues - where do those get lodged and debated? When there are two specs it is not clear.

<dlongley> +1 merge specs sooner rather than later based on consensus decisions on issues

shanem: where do we pose meta-issues?

<manu> I have asked people NOT to comment against the Web Payments CG specs in those issue trackers.

<ShaneM> Thanks for the answer.

<shepazu> (note that we don't have a "WG spec"… we have 2 different proposals, one developed in the Web Payments Community Group, and one being developed in the Web Platform Incubator Community Group)

<Zakim> manu, you wanted to explain approach.

<Ian> (IJ observes there is not agreement to merge. But there is agreement the ultimate goal is one spec.)

<Zakim> zkoch, you wanted to disagree with manu :)

<dlongley> +q to say deciding between two full specs vs getting consensus on individual issues and building a combined spec will be much more contentious than necessary

manu: there are too many issues that are common to both that are being missed because they are logged in multiple places

zkoch: we are iterating rapidly and there are issues specific to individual specs so I see no issue with putting them against that spec

ian: part of the problem is that we have a spec that has some history vs one that is very new so it makes sense that the authors of the new spec would ask for more time to iterate over their spec

<manu> 4+ years.

ian: I am hearing an urge to merge and understand the motiviations but I don't think we will benefit from forcing this before the authors have a chance to flesh their spec out

<manu> +1 to Ian

ian: but I want to be sure that the authors are listening to issues form the WG and considering them in their iterations.

<manu> I also want to make sure people know that I'm expressing concerns, I don't think things are "bad" right now - just raising concerns.

<Zakim> dlongley, you wanted to say deciding between two full specs vs getting consensus on individual issues and building a combined spec will be much more contentious than necessary

<ShaneM> +1 to david's concern

dlongley: +1 to ian. The longer we go independant the more likely we have an A vs B decision as opposed to merging valuable bits from both

<manu> +1 to Doug

<Zakim> manu, you wanted to note that we don't want to get into "nuh uh, yeah huh" editor "battles" - we need WG members to engage more deeply.

shepazu: think there was a mistatement that we have a WG spec which we don't. We have 2 proposals

manu: the same people are weighing in on all discussions and that quickly becomes a conflict of personal opinions as opposed to a route to group consensus

<manu> +1 to single wiki page to prioritize these issues for discussion

matts: based on what I've heard I think we need a wiki page that references the key issues. The vast number of duplicate issues is part of the problem and this may resolve this.

nicktr: if anyone is feeling they have issues that they cant log for some reason please let the chairs know

HTTP API

nicktr: Should we be speccing an HTTP API?

<Ian> http://www.w3.org/Payments/WG/charter-201510.html

<Ian> http://www.w3.org/Payments/WG/charter-201510.html#deliverables

ian: The charter suggests that there could be an HTTP API. So I believe we are chartered to do this.

<manu> https://github.com/web-payments/web-payments-http-api

ian: next question is, do we have resources to do this and volunteers to do it

<manu> Human readable form of this spec: http://web-payments.github.io/web-payments-http-api/

<dlongley> "separable"

ian: there is a CG spec for this but this depends on the CG API proposal seperating the messaging schema from API spec

<manu> Here's the CG's messaging spec: http://web-payments.github.io/web-payments-messaging/

ian: q for Zach: can your proposal be split this way

<manu> Here is a link to the paymentRequest architecture document: http://wicg.github.io/paymentrequest/

adrianb: You could conceptualise the API having message objects (messaging) but I put a pin in this to think about it more and how this would influence the API shape

<dlongley> +1 to making sure specs can lend themselves to separating messages from the API (so other kinds of APIs can reuse the messages)

ian: it would be very helpful if both proposals lend themselves to that so thanks for taking time to think about the proposal in that way

<ShaneM> I don't like characterizing the various proposals as "sides"

<ShaneM> we are all on the same side here

ian: not sure if this is a priority. If not for zkoch and adrianba then perhaps for others?

<ShaneM> supporting an HTTP api is MUCH easier if the messaging is separate from the interfaces. Hence the move to try to not have objects be data AND methods.

ian: if we can separate the messaging and API in both proposals then it's easier for us to progress on an HTTP API

zkoch: that's not how we've looked at this so far. It's not a priority for us.

<Ian> zkoch: But that organization could be done.

nicktr: Ian had 2 ques. 1- should we have an HTTP API, 2 - How are the two proposals equipped to deal with that.

<dlongley> +1 should have an HTTP API

<MattS> +1 to have HTTP API

<ShaneM> +1 should have an HTTP API

ian: 1 - are we chartered to do an HTTP API - in my view yes

<dlongley> +1 we are charted to do an HTTP API

<manu> +1 we're chartered to do it, +1 we should do it in parallel.

ian: 2 - what is the priority? Shoudl we do it at the same time as the browser API?

<dlongley> +1 to ensuring messages are separable so we have flexibility for when we do it, but would +1 doing it in parallel now.

<MattS> -1 to doing it now, +1 to doing it once we have a single spec for JS API

<ShaneM> we MUST design the browser API to amke it easy to use either that API or the HTTP API. The design MUST NOT preclude the possibility of an HTTP API.

<dlongley> +1 ShaneM

<shepazu> +1 to do the message now, if possible, since it might change the shape of the API

matts: It sounds the debate is about when to do it. I am -1 to doing 2 HTTP APIs in parallel

<dlongley> +1 to Nick, do NOT do two HTTP APIs.

<manu> +1 to MattS, do NOT have two HTTP APIs.

<manu> -1 on not working on HTTP API untila fter F2F

<zkoch> +1 to post F2F

ian: I think we will only have 1 HTTP API as the editors of the one proposal have not expressed an interest in doing one

kris: I think an HTTP API is key. From an ISO 20022 perspective it is important to have a separation of messages and API
... also how will we know that the work is happening?

<Ian> (IJ thinks that one way of determining what we have formally taken up is that we have a WG draft)

shepazu: Ian and I are working on improved messaging around the WG work

nicktr: to be clear there is one HTTP API proposal already available for review

<manu> http://web-payments.github.io/web-payments-http-api/

kris: how stable is this?

manu: proposal

kris: Ian said we could work on this after the F2F?

nicktr: there is not consensus on this

<Ian> adrianhb: A point that's been missed relates to discussion of evaluation criteria

<Ian> ...we need to decide as a group whether an HTTP API is part of the evaluation criteria of the JS API

<Ian> ..that makes separation of the messaging and API a requirement

<Zakim> dlongley, you wanted to say it's important we can separate messaging from the API so we can do other kinds of APIs like an HTTP API in the future

<Ian> (IJ does not think it's a requirement...it may be an optimization)

<Zakim> manu, you wanted to push back on "not working on HTTP API" and to mention process and simple proposals.

dlongley: deciding if we separate messaging and API is important as this will determine if we can do the HTTP API in future

<manu> DRAFT PROPOSED: Producing an HTTP API is in scope and the group will commit to produce one.

<manu> DRAFT PROPOSED: There should be messaging, browser API, and HTTP API specifications.

<manu> DRAFT PROPOSED: The HTTP API may be worked on before the face-to-face, but will be focused on more after the face-to-face.

manu: will continue working on the HTTP API spec. Concerned that we are not tracking proposals and resolutions in the minutes.

ian: I was trying to do this but we didn't have consensus on the proposal so we couldn't proceed

<manu> Much faster to reach consensus here, but yes can also be done on mailing list.

<ShaneM> This is called a "call for consensus" and there are procedures for this.

nicktr: no consensus on this call but we'll discuss how to move that forward
... reminder to register for F2F
... next call is Jan 7

<zkoch> thanks! bye

nicktr: have a good holiday, look forward to chatting in the new year

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: AdrianHB
Inferring ScribeNick: AdrianHB
Present: Ian MattC CyrilV dlongley dlehn Manu zkoch nicktr ShaneM shepazu Vincent_Kuntz adrianba
Agenda: https://github.com/w3c/webpayments/wiki/Agenda-17th-December-2015-at-1700-UTC

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 17 Dec 2015
Guessing minutes URL: http://www.w3.org/2015/12/17-wpwg-minutes.html
People with action items: manu