16:59:35 <RRSAgent> RRSAgent has joined #wpwg
16:59:36 <RRSAgent> logging to http://www.w3.org/2015/12/17-wpwg-irc
16:59:37 <trackbot> RRSAgent, make logs public
16:59:38 <Zakim> Zakim has joined #wpwg
16:59:39 <trackbot> Zakim, this will be
16:59:40 <Zakim> I don't understand 'this will be', trackbot
16:59:41 <trackbot> Meeting: Web Payments Working Group Teleconference
16:59:41 <trackbot> Date: 17 December 2015
16:59:41 <Ian> present+ Ian
16:59:47 <collier-matthew> present+ MattC
16:59:49 <CyrilV> Present+ CyrilV
17:00:21 <dlongley> Present+ dlongley
17:00:58 <dlehn> Present+ dlehn
17:01:52 <nicktr> nicktr has joined #wpwg
17:02:06 <MattS> MattS has joined #wpwg
17:02:34 <manu> Present+ Manu
17:02:36 <zkoch> zkoch has joined #wpwg
17:02:42 <zkoch> Present+ zkoch
17:03:02 <manu> Present+ Manu
17:03:11 <AdrianHB> https://mit.webex.com/mit/j.php?MTID=m5b3574cfbd517695ada1d26368d2adc8
17:03:11 <AdrianHB> Meeting number: 647 126 801
17:03:53 <nicktr> Present+ nicktr
17:03:58 <shepazu> present+ ShaneM
17:04:06 <shepazu> present+ shepazu
17:04:19 <Ian> agenda: https://github.com/w3c/webpayments/wiki/Agenda-17th-December-2015-at-1700-UTC
17:04:42 <Ian> scribe: AdrianHB
17:04:58 <AdrianHB> topic: Flows
17:05:11 <kris> kris has joined #wpwg
17:05:27 <VincentK> VincentK has joined #wpwg
17:05:27 <AdrianHB> matt: we've revised the list of flows
17:05:52 <Ian> list of flows: https://github.com/w3c/webpayments/wiki/Flows
17:05:56 <AdrianHB> ... dropped v.me as we have no volunteers to do it and the consensus was that it was close enough to MasterPass
17:05:57 <VincentK> present+ Vincent_Kuntz
17:06:15 <AdrianHB> ... dropped a redundant one for SCT
17:06:40 <adrianba> Present+ adrianba
17:06:56 <AdrianHB> ... updated flows to be explicit about the use case where data goes directly to PSP (as opposed to via merchant)
17:07:00 <Ian> (Matt has pinged volunteers to remind them of 7 Jan 2016 deadline)
17:07:20 <AdrianHB> ... contributors being pushed by Matt to have them in by 7 January
17:07:21 <manu> q+ to ask if it would be helpful to integrate flows into specs? If so, which ones?
17:07:45 <AdrianHB> nicktr lists outstanding flows
17:08:03 <nicktr> q?
17:08:08 <nicktr> ack manu
17:08:08 <Zakim> manu, you wanted to ask if it would be helpful to integrate flows into specs? If so, which ones?
17:08:28 <AdrianHB> nicktr: Matt, have you got confirmation that the contributors will have theirs in by 7 Jan
17:08:37 <AdrianHB> matt: not all
17:08:54 <AdrianHB> manu: which flow is most ready to test against the proposals?
17:09:12 <Ian> q+
17:09:19 <AdrianHB> matt: I'd recommend the standard debit/credit charge card as a start (simple first)
17:09:45 <AdrianHB> matt: where are we on standardising terminology with the IG?
17:09:46 <manu> ACTION: Manu to integrate Standard flow into Web Payments CG's Browser API spec.
17:09:47 <trackbot> Created ACTION-10 - Integrate standard flow into web payments cg's browser api spec. [on Manu Sporny - due 2015-12-24].
17:10:51 <AdrianHB> 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.
17:11:33 <nicktr> q?
17:11:37 <AdrianHB> ian: +1 to that synopsis. In additiona there are IG memebrs in the WG to ensure there is feedback
17:11:40 <nicktr> ack Ian
17:12:00 <AdrianHB> ian: there is a general q about how we are using the flows?
17:12:23 <nicktr> q?
17:12:25 <AdrianHB> ... how are we prioritising flows and using them for evaluation of the proposals
17:12:46 <manu> q+ to say he was planning on using the flow in the appendix to show how the API achieves the flow.
17:12:50 <AdrianHB> matt: my understanding is that what's listed is the prioritised set (no weighting within that set)
17:13:18 <AdrianHB> ... I have started analyzing the flows and noting this in the wiki
17:13:18 <manu> q+ to say he expects the experiment to be a partial failure, but hopes the group learns /something/ from it.
17:13:48 <AdrianHB> ... 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
17:14:21 <AdrianHB> ian: I have added a note to the wiki that states the flows submitted by 7 Jan are the ones we will use
17:14:32 <zkoch> We’re also using the flows as a sanity check against any API changes we make
17:14:49 <AdrianHB> manu: I'm planning to test how the flows and proposals match up
17:15:12 <AdrianHB> topic: evaluation criteria
17:15:22 <manu> q+ to note that he's pro "work the issues", a bit concerned about creating "evaluation criteria"
17:15:48 <AdrianHB> nicktr: The chairs have been discussing how we can define a way to evaluate the proposals.
17:16:15 <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
17:16:18 <nicktr> adrian: would be great to evaluate the flows and the specs, but not sure that this will allow us to evaluate the proposals
17:16:30 <nicktr> q?
17:16:42 <zkoch> q+
17:16:52 <MattS> q+
17:16:59 <AdrianHB> manu: we need to hear from the group on this topic
17:17:15 <AdrianHB> ... I'm concerned that we are not making progress on defining the feature set we need
17:17:40 <AdrianHB> ... the editors took and action to review them and log issues which i have done
17:18:01 <AdrianHB> ... typical WG process is to raise issues and then make resolutions on those issues
17:18:03 <Ian> q?
17:18:18 <AdrianHB> ... there is a lot of discussion but we don't seem to be getting to resolutions
17:19:16 <AdrianHB> ... 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.
17:19:42 <nicktr> q?
17:19:46 <nicktr> ack manu
17:19:46 <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
17:19:49 <Zakim> ... hopes the group learns /something/ from it. and to note that he's pro "work the issues", a bit concerned about creating "evaluation criteria"
17:19:53 <AdrianHB> ... I don't think we should keep the specs separate as this delays the process of getting consensus
17:20:11 <ShaneM> The specs should not drive the requirements.  The requirements should drive the creation of a spec.
17:20:18 <manu> +1 ShaneM
17:20:21 <dlongley> +1 ShaneM
17:20:46 <dlongley> +1 to bringing issues to this call, working through them, and then changing specs to reflect the consensus decision.
17:20:53 <AdrianHB> 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?
17:20:54 <manu> +1 to bringing issues that have had a lot of discussion to the call
17:20:55 <Ian> +1 to bringing the salient issues to this call (as we have done today re: HTTP API)
17:20:56 <Ian> q+
17:20:56 <nicktr> ack zkoch
17:21:41 <AdrianHB> zkoch: it sounds like we are treating the specs as final and saying we need to evaluate them and pick a winner
17:21:55 <manu> +1 to Zach - we shouldn't view the specs as "done and ready" and "ready to be chosen"
17:22:07 <dlongley> +1 specs are "works in progress" and this call is the venue to make decisions on the issues
17:22:09 <nicktr> ack MattS
17:22:12 <AdrianHB> ... I think we need to keep iterating on the specs and resolve the issues with each
17:22:29 <manu> -1 to keeping the specs apart for 1.5 months.
17:22:41 <manu> +1 to MattS for doubling the work that we're having to do.
17:22:55 <manu> (as in, that's what's happening)
17:23:22 <AdrianHB> 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.
17:23:27 <nicktr> q?
17:23:33 <nicktr> ack Ian
17:23:36 <manu> q+ to note that the issues have been raised as "compare/contrast questions"
17:23:39 <AdrianHB> ... example currency format should be debated when there is a single spec
17:24:08 <AdrianHB> ian: ack many points made. There is value to the way things are proceeding.
17:24:24 <manu> q+ to wring his hands around timeline.
17:24:37 <AdrianHB> ... lot of input to date. I am also getting external eyes on the proposals which is valuable.
17:24:57 <AdrianHB> ... don't want to deny that we are adding cost by having two proposals
17:25:15 <AdrianHB> ... support matt's proposal that we prioritise the issues and address the bug ones in the call
17:25:25 <AdrianHB> ... chairs and team contacts will work on this
17:25:31 <manu> q+ to request that we start discussing issues "ready to be discussed" on the call
17:25:43 <AdrianHB> ... +1 for letting the specs evolve independantly for a while longer
17:26:12 <AdrianHB> nicktr: consensus that we bring prioritised issues to the call
17:26:12 <ShaneM> q+ to ask how we handle meta issues - where do those get lodged and debated?  When there are two specs it is not clear.
17:26:27 <AdrianHB> ... don't seem to have consensus on when to merge specs
17:26:37 <Ian> (The meta-instrument is a human brain)
17:26:40 <AdrianHB> q+
17:26:55 <AdrianHB> q?
17:27:02 <manu> ack manu
17:27:02 <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
17:27:03 <nicktr> ack manu
17:27:06 <Zakim> ... "ready to be discussed" on the call
17:28:00 <AdrianHB> 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.
17:28:16 <MattS> q+
17:29:11 <AdrianHB> ... 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
17:29:15 <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
17:29:25 <MattS> q-
17:29:25 <nicktr> ack ShaneM
17:29:26 <AdrianHB> +1 to Ian
17:29:26 <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.
17:29:27 <dlongley> +1 merge specs sooner rather than later based on consensus decisions on issues
17:29:44 <AdrianHB> shanem: where do we pose meta-issues?
17:30:08 <nicktr> q?
17:30:12 <nicktr> ack AdrianHB
17:30:40 <manu> I have asked people NOT to comment against the Web Payments CG specs in those issue trackers.
17:31:10 <manu> q+ to explain approach.
17:31:12 <ShaneM> Thanks for the answer.
17:32:03 <zkoch> q+ to disagree with manu :)
17:32:35 <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)
17:32:41 <manu> ack manu
17:32:41 <Zakim> manu, you wanted to explain approach.
17:32:47 <Ian> (IJ observes there is not agreement to merge. But there is agreement the ultimate goal is one spec.)
17:32:54 <nicktr> ack zkoch
17:32:54 <Zakim> zkoch, you wanted to disagree with manu :)
17:33:28 <Ian> q+
17:33:29 <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
17:33:37 <AdrianHB> manu: there are too many issues that are common to both that are being missed because they are logged in multiple places
17:33:51 <nicktr> ack Ian
17:33:54 <shepazu> q+
17:34:08 <AdrianHB> zkoch: we are iterating rapidly and there are issues specific to individual specs so I see no issue with putting them against that spec
17:34:33 <manu> q+ to note that we don't want to get into "nuh uh, yeah huh" editor "battles" - we need WG members to engage more deeply.
17:34:48 <AdrianHB> 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
17:34:52 <manu> 4+ years.
17:35:30 <AdrianHB> ... 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
17:35:57 <manu> +1 to Ian
17:36:09 <AdrianHB> ... but I want to be sure that the authors are listening to issues form the WG and considering them in their iterations.
17:36:30 <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.
17:36:34 <nicktr> ack dlongley
17:36:34 <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
17:37:11 <nicktr> ack shepazu
17:37:15 <ShaneM> +1 to david's concern
17:37:26 <AdrianHB> 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
17:37:52 <manu> +1 to Doug
17:37:54 <nicktr> ack manu
17:37:54 <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.
17:38:23 <AdrianHB> shepazu: think there was a mistatement that we have a WG spec which we don't. We have 2 proposals
17:38:50 <MattS> q+
17:38:59 <AdrianHB> 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
17:39:04 <nicktr> zakim, close the queue
17:39:04 <Zakim> ok, nicktr, the speaker queue is closed
17:39:13 <nicktr> ack MattS
17:39:37 <manu> +1 to single wiki page to prioritize these issues for discussion
17:39:56 <AdrianHB> 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.
17:40:06 <nicktr> zakim, open the queue
17:40:06 <Zakim> ok, nicktr, the speaker queue is open
17:40:48 <AdrianHB> nicktr: if anyone is feeling they have issues that they cant log for some reason please let the chairs know
17:40:53 <AdrianHB> topic: HTTP API
17:41:00 <MattS> q+
17:41:09 <AdrianHB> nicktr: Should we be speccing an HTTP API?
17:41:09 <Ian> http://www.w3.org/Payments/WG/charter-201510.html
17:41:15 <Ian> http://www.w3.org/Payments/WG/charter-201510.html#deliverables
17:42:00 <AdrianHB> ian: The charter suggests that there could be an HTTP API. So I believe we are chartered to do this.
17:42:06 <manu> https://github.com/web-payments/web-payments-http-api
17:42:17 <AdrianHB> ... next question is, do we have resources to do this and volunteers to do it
17:42:40 <manu> Human readable form of this spec: http://web-payments.github.io/web-payments-http-api/
17:42:46 <dlongley> "separable"
17:42:59 <AdrianHB> ... there is a CG spec for this but this depends on the CG API proposal seperating the messaging schema from API spec
17:42:59 <manu> Here's the CG's messaging spec: http://web-payments.github.io/web-payments-messaging/
17:43:25 <AdrianHB> ... q for Zach: can your proposal be split this way
17:43:50 <manu> Here is a link to the paymentRequest architecture document: http://wicg.github.io/paymentrequest/
17:44:19 <AdrianHB> 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
17:44:44 <dlongley> +1 to making sure specs can lend themselves to separating messages from the API (so other kinds of APIs can reuse the messages)
17:44:45 <kris> q+
17:44:52 <AdrianHB> 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
17:45:03 <ShaneM> I don't like characterizing the various proposals as "sides"
17:45:12 <ShaneM> we are all on the same side here
17:45:29 <AdrianHB> ... not sure if this is a priority. If not for zkoch and adrianba then perhaps for others?
17:46:29 <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.
17:46:30 <AdrianHB> ian: if we can separate the messaging and API in both proposals then it's easier for us to progress on an HTTP API
17:46:56 <nicktr> q?
17:47:17 <AdrianHB> zkoch: that's not how we've looked at this so far. It's not a priority for us.
17:47:19 <AdrianHB> q+
17:47:31 <Ian> zkoch: But that organization could be done.
17:47:59 <AdrianHB> nicktr: Ian had 2 ques. 1- should we have an HTTP API, 2 - How are the two proposals equipped to deal with that.
17:48:03 <dlongley> +1 should have an HTTP API
17:48:19 <MattS> +1 to have HTTP API
17:48:26 <ShaneM> +1 should have an HTTP API
17:48:31 <ShaneM> q?
17:48:48 <AdrianHB> ian: 1 - are we chartered to do an HTTP API - in my view yes
17:48:53 <dlongley> +1 we are charted to do an HTTP API
17:49:02 <manu> +1 we're chartered to do it, +1 we should do it in parallel.
17:49:09 <AdrianHB> ... 2 - what is the priority? Shoudl we do it at the same time as the browser API?
17:49:10 <dlongley> +1 to ensuring messages are separable so we have flexibility for when we do it, but would +1 doing it in parallel now.
17:49:13 <MattS> -1 to doing it now, +1 to doing it once we have a single spec for JS API
17:49:26 <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.
17:49:47 <dlongley> +1 ShaneM
17:49:54 <AdrianHB> q?
17:49:54 <Ian> zakim, who's here?
17:49:56 <Zakim> Present: Ian, MattC, CyrilV, dlongley, dlehn, Manu, zkoch, nicktr, ShaneM, shepazu, Vincent_Kuntz, adrianba
17:49:56 <Zakim> On IRC I see VincentK, kris, zkoch, MattS, nicktr, Zakim, RRSAgent, CyrilV, ShaneM, dezell, AdrianHB, slightlyoff, shepazu, dlehn, mkwst, adrianba, davidillsley, dwim_, ijmad,
17:49:56 <Zakim> ... dveditz, schuki, manu, dlongley, collier-matthew, trackbot, Ian, wseltzer
17:50:05 <shepazu> +1 to do the message now, if possible, since it might change the shape of the API
17:50:44 <AdrianHB> q?
17:50:51 <AdrianHB> ack Matts
17:51:37 <AdrianHB> matts: It sounds the debate is about when to do it. I am -1 to doing 2 HTTP APIs in parallel
17:51:42 <dlongley> +1 to Nick, do NOT do two HTTP APIs.
17:51:43 <AdrianHB> q?
17:51:57 <manu> +1 to MattS, do NOT have two HTTP APIs.
17:52:33 <manu> -1 on not working on HTTP API untila fter F2F
17:52:36 <zkoch> +1 to post F2F
17:52:37 <AdrianHB> 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
17:52:41 <dlongley> q+ 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
17:52:55 <manu> q+ to push back on "not working on HTTP API"
17:52:58 <AdrianHB> ack kris
17:53:17 <manu> q+ to mention process and simple proposals.
17:53:40 <AdrianHB> kris: I think an HTTP API is key. From an ISO 20022 perspective it is important to have a separation of messages and API
17:53:54 <AdrianHB> ... also how will we know that the work is happening?
17:54:25 <Ian> (IJ thinks that one way of determining what we have formally taken up is that we have a WG draft)
17:54:26 <AdrianHB> shepazu: Ian and I are working on improved messaging around the WG work
17:54:59 <AdrianHB> nicktr: to be clear there is one HTTP API proposal already available for review
17:55:02 <manu> http://web-payments.github.io/web-payments-http-api/
17:55:19 <AdrianHB> kris: how stable is this?
17:55:23 <AdrianHB> manu: proposal
17:55:47 <AdrianHB> kris: Ian said we could work on this after the F2F?
17:55:56 <AdrianHB> nicktr: there is not consensus on this
17:55:56 <Ian> q?
17:56:08 <AdrianHB> ack AdrianHB
17:56:09 <nicktr> ack adrianba
17:56:25 <Ian> adrianhb: A point that's been missed relates to discussion of evaluation criteria
17:57:08 <Ian> ...we need to decide as a group whether an HTTP API is part of the evaluation criteria of the JS API
17:57:20 <Ian> ..that makes separation of the messaging and API a requirement
17:57:25 <nicktr> ack dlongley
17:57:25 <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
17:57:29 <Ian> (IJ does not think it's a requirement...it may be an optimization)
17:57:57 <nicktr>  ack manu
17:57:57 <Zakim> manu, you wanted to push back on "not working on HTTP API" and to mention process and simple proposals.
17:58:23 <nicktr> q+
17:58:37 <AdrianHB> dlongley: deciding if we separate messaging and API is important as this will determine if we can do the HTTP API in future
17:59:14 <manu> DRAFT PROPOSED: Producing an HTTP API is in scope and the group will commit to produce one.
17:59:14 <manu> DRAFT PROPOSED: There should be messaging, browser API, and HTTP API specifications.
17:59:14 <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.
17:59:24 <AdrianHB> manu: will continue working on the HTTP API spec. Concerned that we are not tracking proposals and resolutions in the minutes.
18:00:02 <AdrianHB> ian: I was trying to do this but we didn't have consensus on the proposal so we couldn't proceed
18:00:51 <manu> Much faster to reach consensus here, but yes can also be done on mailing list.
18:01:20 <ShaneM> This is called a "call for consensus" and there are procedures for this.
18:01:31 <AdrianHB> nicktr: no consensus on this call but we'll discuss how to move that forward
18:01:42 <AdrianHB> ... reminder to register for F2F
18:01:48 <AdrianHB> ... next call is Jan 7
18:02:17 <zkoch> thanks! bye
18:02:20 <AdrianHB> ... have a good holiday, look forward to chatting in the new year
18:02:20 <Ian> rrsagent, make minutes
18:02:20 <RRSAgent> I have made the request to generate http://www.w3.org/2015/12/17-wpwg-minutes.html Ian
18:02:24 <Ian> rrsagent, set logs public
18:11:07 <zkoch> zkoch has joined #wpwg
19:14:10 <dezell> dezell has left #wpwg
20:01:55 <Zakim> Zakim has left #wpwg
20:20:02 <zkoch> zkoch has joined #wpwg
20:29:55 <zkoch> zkoch has joined #wpwg
20:33:38 <AdrianHB> AdrianHB has joined #wpwg
22:37:17 <zkoch> zkoch has joined #wpwg
22:57:21 <sam> sam has joined #wpwg
23:01:24 <zkoch> zkoch has joined #wpwg
23:05:41 <dlehn> dlehn has joined #wpwg