17:06:07 RRSAgent has joined #wpwg 17:06:07 logging to http://www.w3.org/2016/01/28-wpwg-irc 17:06:12 alamar has joined #wpwg 17:06:18 zakim, take up item 1 17:06:18 agendum 1. "Flows (Adrian)" taken up [from AdrianHB] 17:06:29 scribe: manu 17:06:41 Adrian: Matt is on leave for a while - people are making good progress on flows. 17:07:19 Adrian: He's asking for input on flows being done - there have been two review cycles. 17:07:45 Adrian: There's not much feedback coming in from people outside the flows task force - please have a look at those flows, give feedback. They've been making good progress, but it needs external review. 17:08:31 NickTR: I'll help w/ pushing review cycles onto people next week. 17:08:36 q? 17:08:40 NickTR: Specifically, with the flows. 17:08:46 Topic: Dashboard 17:09:00 zakim, take up item 2 17:09:00 agendum 2. "Update on dashboards (Adrian & Doug)" taken up [from AdrianHB] 17:09:09 Adrian: Doug and I had some good discussion this week on how we improve visibility of issues we're dealing with. 17:09:16 -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Jan/0206.html Dashboard email 17:09:28 -> https://waffle.io/w3c/webpayments Dashboard prototype 17:09:34 q+ to not that he saw the HTTP API proposal via Kanban board - and would've missed it w/o it being on waffle.io. 17:09:51 present+ dlongley 17:10:10 Adrian: We need to hear from folks if they can access waffle.io from behind their corporate firewalls. Only caveat is that you need to login to github at least once. 17:10:19 q? 17:10:22 ack manu 17:10:22 manu, you wanted to not that he saw the HTTP API proposal via Kanban board - and would've missed it w/o it being on waffle.io. 17:10:28 manu: Already helpful to me! 17:10:39 ...I checked the dashboard and caught something I would not have caught. 17:10:39 AdrianHB: Give it a try and let us know. 17:10:41 q+ 17:11:19 Adrian: This is an interactive board - we have a flow for proposals - we do want to have a better dashboard for how we categorize stuff - listing out actions, highlighting proposals by date, etc. Doug and I are still working on it. 17:11:22 ack Ian 17:11:46 Ian: One question is if you've written down goals for the project and how you anticipate how people use dashboard. 17:12:11 Ian: That might be nice to help - I'd be unlikely to start using it regularly 17:12:16 q+ 17:12:18 Ian: until I know how we intend to use it. 17:12:24 q- 17:12:32 dlongley: .... took me a while to connect to the telecon (it was rejecting the access code), regarding flows I reviewed the PayPal ones and worked through some changes with Matt a few weeks ago and believe they're in good shape now. 17:13:09 Adrian: We are using labels, milestones to organize things - Github's UI doesn't do it in the way we want to - two goals for now - specific requirements for now that they think are appropriate, we'd like to hear about it now. 17:13:42 Doug: I'd say that having a visual representation is good, but how you can raise issues - questions, etc. - if you can't get on github, you can get in touch w/ Adrian to log issue. 17:14:20 Some questions to consider in the UI: (1) what are my actions? (2) what's on our agenda next week? (3) what proposals should I be reviewing? 17:14:21 q+ 17:14:52 Doug: As we get into spec work, the flow might change, but we should try to bring spec into web payments github repo so that those issues are also dealt with, as we talk more about technical stuff, we should be tracking it in a common org. Final thing - apologies for using another 3rd party resource - W3C is looking into making a similar interface for W3C, so hopefully if we do that, we won't use a 3rd party resource. We hope this is useful in the short term. 17:15:03 Doug: What do each of the columns mean? 17:15:31 Adrian: Any new issues start on left column, then they move between columns based on labels, if you label it as action, it goes in that column, if you put it in progress, it goes in that column. 17:15:52 Adrian: When proposals get created, they go in the proposals column, as stuff gets resolved, it moves to the right to the "resolution" column. 17:15:56 q? 17:16:02 Adrian: This is the meta-discussion flow that we have for the moment. 17:16:05 ack Ian 17:16:25 Ian: So, a couple of questions - how do I figure out what I should be doing? 17:16:32 Ian: What is on our agenda next week? 17:16:39 Ian: What proposals should I be reviewing? 17:16:59 q? 17:17:12 Ian: I don't have any strong feelings, just make the point that if we know what we want out of it, it'll do it's job. 17:17:38 Doug: I don't know if we can do that easily w/ waffle.io - if we do that w/ the W3C dashboard - I can easily see how we could pull out who an action item is for. 17:17:51 Doug: The hot items, we could label them as being on the agenda - that's what proposals are for as well. 17:18:06 Ian: This is mostly to give a flavor of what I'd want to see. 17:18:19 Ian: I understand that there might be some limitations using waffle.io 17:18:21 q? 17:18:29 zakim, take up item 3 17:18:29 agendum 3. "Draft F2F Agenda (Adrian & Ian)" taken up [from AdrianHB] 17:18:29 Topic: Face-to-Face Agenda 17:18:32 q? 17:18:40 https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016 17:18:55 -> https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016#Agenda Beginnings of agenda 17:19:15 AdrianHB: We've broken it out to foundational stuff, and then break it out into issues. If you look at day 1, we will spend a big part of morning going through flows - specifically what that means. 17:19:21 (Current tally of registrants: 27 + around 6 guests) 17:19:30 Please register -> https://www.w3.org/2002/09/wbs/83744/ftf-201602/ 17:20:01 AdrianHB: There have been some discussion w/ Ian, Matt - what flows mean - whatever we specify in our API is compatible w/ how people do payments. We'll try to overlay flow of APIs, working on intersection points, so things work as prescribed. We may want to do some of that before F2F. 17:20:12 AdrianHB: Then we'll be able to address specifically what we'll be able to do at the meeting. 17:20:20 AdrianHB: I think they can help us understand use cases. 17:20:35 q? 17:20:47 AdrianHB: Demos is intended to be a kind of scene setting session - 2 hours aside for that - anyone that has build something for the group to play w/ what's been spec'd out for the group, should demo it to the group. 17:21:12 AdrianHB: I have a bunch of wireframes, there are polyfills, we should start considering what implementation of our work looks like. Practicalities of what we're doing look like. 17:21:55 AdrianHB: People that are not experts in architecture/web design, relate architectural discussion - shipping address not part of API - how must API use events/promises, etc. - when we have those discussions, we can explain what implications of different things are... 17:22:09 q? 17:22:12 AdrianHB: Anyone that has wireframes, send a mail to the group - nick, Ian, doug - request time slot. 17:22:19 q+ 17:22:24 ack Ian 17:22:46 Ian: If you haven't registered, please do - we're at 27 plus 6 guests - we're going to have to figure out how to eat together. 17:22:58 q? 17:23:12 scribe: Ian 17:23:13 Nick: any other points on face-to-face? 17:23:37 adrianHB: We're logging criteria to be used when addressing issues 17:23:41 AdrianHB: The last part of Face to face is issue bashing - what are priorities - what are we trying to solve - start diving into stuff that is important. 17:23:49 AdrianHB: We want issue list finalized by 16th of February. 17:23:50 ...the plan is to have the issues list available no later than 16 Feb 17:23:59 AdrianHB: There is a plan to have a set of issues to get us started. 17:24:05 q? 17:24:09 AdrianHB: As the discussion progresses - things will morph as we go. 17:24:27 AdrianHB: We need to use this time to solve the difficult questions, some of which haven't come up yet - security, implementation details, 17:24:40 q? 17:24:51 zakim, take up item 4 17:24:51 agendum 4. "PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (Adrian)" taken up [from 17:24:53 AdrianHB: any other questions? Raise it on calls. 17:24:55 ... AdrianHB] 17:24:58 scribe: Ian 17:25:09 I have made the request to generate http://www.w3.org/2016/01/28-wpwg-minutes.html Ian 17:25:33 https://github.com/w3c/webpayments/issues/67 17:25:34 AdrianHB: Proposal was first put forward last week; since then we've had some adjustments based on feedback 17:25:52 PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate 17:25:57 dezell has joined #wpwg 17:26:00 ...ground terms to an ISO20022 glossary 17:26:10 +1 17:26:31 manu: Question about implementation - should we put in the IG glossary? 17:27:36 +1 to pushing these terms to the IG glossary 17:27:41 q+ to note how this works today. 17:27:50 q? 17:28:07 FWIW I believe we all agreed to keep one glossary for the activity, i.e. the IG to maintain. 17:30:02 PROPOSED: The WG recommends that the IG takes up these terms. 17:30:11 (and then once they are in the IG glossary, others can important them consistently) 17:31:06 The proposal includes: The W3C Web Payments Terms and their respective mappings to common terms and ISO20022 will be implemented in the Web Payments IG Glossary, which will be dynamically pulled into all WPWG specifications. 17:32:38 [IJ agrees the right thing is very likely to happen. But I don't want to create dependencies unnecessarily] 17:32:52 +1 17:32:52 +1 17:32:54 +1 17:32:55 +1 17:32:56 +1 17:33:01 The following clause is no longer part of the proposal: "which will be dynamically pulled into all WPWG specifications." 17:33:12 RESOLVED: (1) Adopt the terminology proposal (2) request that the IG adopt the terms in their glossary 17:33:17 +1 17:33:19 +1 17:33:24 +1 17:33:38 ACTION: Nicktr to contact the IG Chairs about taking up the terms 17:33:38 Created ACTION-12 - Contact the ig chairs about taking up the terms [on Nick Telford-Reed - due 2016-02-04]. 17:33:46 zakim, take up item 5 17:33:46 agendum 5. "PROPOSAL: Use strings to represent currency and amount per ISO20022 (Adrian)" taken up [from AdrianHB] 17:34:19 q? 17:34:21 PROPOSAL: Use strings to represent currency and amount per ISO20022 (Adrian) 17:34:22 https://github.com/w3c/webpayments/issues/57 17:34:22 q- 17:34:39 q+ with a question 17:34:42 q+ 17:34:59 (The proposal has more detail on formatting) 17:35:05 q+ to ask whether we're using commas or periods in strings. also how many digits after period/comma is ok. 17:35:49 q+ to note that amount.toString() is a really bad idea (floating point errors) 17:35:50 IJ: What was meant by strings are developer hostile? 17:35:58 AdrianHB: Developers will be working with numbers up to the time 17:35:59 q+ 17:36:14 q? 17:36:29 ack Rouslan 17:36:29 Rouslan, you wanted to ask whether we're using commas or periods in strings. also how many digits after period/comma is ok. 17:36:35 adrianHB: I think the main concern was serialization; I think format will be more well-understood 17:36:36 ack me 17:36:43 can everyone hear me ok? 17:36:45 Nope 17:36:50 ok, here's my question. 17:37:02 should we use commas or periods? 17:37:13 “real” -> it’s actually just me on another workstation pretending 17:37:16 IJ: The proposal is "dot" 17:37:19 may i ask more questions? 17:37:24 ShaneM has joined #wpwg 17:37:28 how many digits after the dot? 17:37:35 wrt the recently resolved proposal: on the record it is assumed that editors will pull the glossary into their specs but the group resolved to not create an unneccessary dependancy 17:37:46 present+ shepazu 17:37:54 Present+ ShaneM 17:38:01 AdrianHB: The proposal is silent on the max number of digits after the dot 17:38:03 present+ 17:38:21 AdrianHB: ISO20022 has more strictly defined types 17:38:22 Doesn’t the proposal state: “The value of the currency property MUST be expressed as a string of 3 characters.” 17:38:28 final note with respect to amount.toString() floating point errors: developers should be using integers, not floating point numbers for prices. that's it for me. thanks! 17:38:31 ...they have had to update their types to deal with the fact that they wanted more precision 17:38:32 ohh, nevermind, dumb 17:39:05 ...but I don't see a good reason for us to enforce that. Degree of precision might be payment method-specific (e.g., new currency divisible down to 10 beyond bitcoin's 8) 17:39:08 q? 17:39:08 +1 to not limit. 17:39:16 zkoch: but currency property being limited to 3 characters isn't good if we want extensibility (URLs for new currency types) 17:39:18 +1 17:39:21 why limit the currency to three characters? 17:39:29 yeah -1 to currency limited to 3 characters 17:39:32 q? 17:39:37 q+ 17:39:40 ack manu 17:39:40 manu, you wanted to note that amount.toString() is a really bad idea (floating point errors) 17:39:56 manu: amount.toString() based idea due to floating point rounding errors 17:40:07 ...so big -1 to developers working with currency amounts as floats. 17:40:21 ..the proposal has 8 things in it 17:40:36 ..and there's one that's popping up as problematic -> currency property limited to 3 characters 17:40:57 ...I thought we had a discussion about being able to extend (e.g., for new currencies) 17:41:14 +1 to drop restriction 17:41:27 AdrianHB: I am ok with dropping 3-letter string limit and allowing "string" 17:41:43 ..but I think that 7 and 8 are good to keep 17:41:50 q? 17:41:57 manu: I want us to be able to use URIs to identify currencies 17:41:59 ack dezell 17:42:14 q+ to suggest changes :) 17:42:29 dezell: agree it's bad practice to use amountTo.string() 17:42:32 amend 8 to say "universally understood code or identifier SHOULD be used" 17:42:39 ...also +1 to removing #6 restriction 17:42:50 ...suggest that best practice is to use 3-digit code where possible. 17:42:53 q? 17:42:57 ack Ian 17:42:57 Ian, you wanted to suggest changes :) 17:43:07 amend 6 to say: The value of the currency property MUST be expressed as a string 17:43:14 +1 to a best practice about currency code 17:43:31 best practice about currency code is dealt with in 7 and 8 17:43:36 Ian: First observation, once we get to specification, there will be a need for additional stuff - valid properties - spec needs to go into error handling, this is just a syntax proposal, we don't need to get into spec details. 17:44:42 Ian: It's fine to say that currency is represented as a string, 7 and 8 may not be the right way to get what you want. If we want interoperability among processors (software), we need to have them behave the same way when they see the same thing. There should be some form of limitation - if 3 character code is used, and ISO 4217 defines it, then processor MUST interpret it as defined in ISO4217. 17:45:15 Ian: It needs to be specific about how certain codes are processed. 17:45:26 q? 17:45:48 IJ: One way of formulating the proposal is "what processors have to do" and "what users should do" 17:45:57 q+ 17:46:03 ack Ian 17:46:29 Suggestion: define the code as a union of string{,3} and URL. More complex than that, but something like that. 17:46:34 proposal: replace 7 and 8 with: "If a 3 character alpha string is used and that string is a valid code from the ISO 4217 Current Currency and Funds list consumers must interpret the currency as the currency listed in the ISO 4217 Current Currency and Funds list" 17:46:42 Ian: I feel like the proposal is very instructive in that it shows us that there is stuff we already want to talk about beyond mere parsing - we may want to drop from this proposal 6, 7, and 8 - limit ourselves to syntax - and processing will be up to spec authors, etc. 17:46:49 q? 17:46:49 Ian: Restrict proposal to only syntax questions. 17:46:56 counter-proposal: drop 6,7 and 8 17:47:01 IJ: And start to take notes on semantics. 17:47:07 I would be a +1 to that, remove 6, 7, and 8. 17:47:24 -1 for removing 2 17:47:33 Ian: I'd go as far as saying remove #2 17:47:36 -1 to remove 2 17:48:05 q? 17:48:07 Ian: It may be the use of MUST / SHOULD language - two properties - but not say much - requirements of specification can be put in there, trying to narrow proposal to syntax. 17:48:31 manu: I agree, we're trying to figure out what that object looks like, so very pro #2. 17:48:40 Ian: I can live w/ #1-#5. 17:48:58 PROPOSAL: 17:49:00 +1 to removing 6, 7, 8 17:49:02 NickTR: Is there consensus that proposal is resolved if it's only items #1-#5? 17:49:02 Amounts MUST be represented as an object. 17:49:02 The amount object MUST have at least two named properties: "currency" and "amount". 17:49:02 The value of the amount property MUST be a string consisting only of numeric digits. 17:49:02 The value of the amount property MAY contain a single dot to denote separation of the fractional suffix from the rest of the amount. 17:49:03 If present, the dot MUST NOT be the first character of the amount. 17:49:17 The value of the currency property MUST be expressed as a string 17:49:21 fine w/ #6 w/o length restriction. 17:49:30 {Shows of support?} 17:49:32 +1 17:49:32 ... oops. Yes 6 is okay with no length. 17:49:38 +1 17:49:38 +1 17:49:39 +1 17:49:39 +1 17:49:44 +1 17:49:47 +1 17:49:49 +1 17:49:53 yes, i'm good, thank you. 17:49:56 q+ to note why long proposals are problematic. 17:50:09 SO RESOLVED 17:50:10 _1 17:50:11 +1 17:50:49 +1 to manu 17:50:57 Manu: Suggest people keep proposals short and atomic. 17:51:00 q? 17:51:02 ack m 17:51:02 manu, you wanted to note why long proposals are problematic. 17:51:04 ack manu 17:51:15 Topic: HTTP API publication schedule 17:51:50 PROPOSAL: Postpone release of an HTTP API FPWD until 1 June 2016 17:51:58 +1 17:52:14 https://github.com/w3c/webpayments/issues/73 17:52:25 PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. 17:52:41 Manu: I think there is more to the proposal than just a publication date 17:52:55 PROPOSAL: Focus on releasing a Browser API FPWD by end of March 2016 and then immediately switch focus and define a common Payment Messaging Format and HTTP API with a firm early June 2016 FPWD date (based on anything we may learn from the Browser API). 17:53:16 +1 to ian 17:53:30 Ian: We already know we want to public on March 2016, if we have a date for HTTP API, it's built in that we'll be focusing on that. 17:53:48 q? 17:54:21 Ian: If we don't think it's possible to get something out in March 2016 then one in June 1 2016 - we should hear that from the group. 17:54:44 PROPOSAL: Postpone release of an HTTP API FPWD until 1 June 2016 17:54:47 +1 17:54:49 Ian: I think this accomplishes what Manu wants but is implicit about some of the requirements. 17:55:20 adrianhb:tabled owl:sameAs english:putOnAgenda 17:55:40 manu: Does the group believe that the HTTP API is the "next thing that we should focus on"? 17:56:14 adrianHB: I don't know that it will "automatically shift" but rather when the JS API starts to stabilize 17:56:23 q? 17:56:25 +1 17:56:26 IJ: +1 to question - do we believe that date? 17:56:39 AdrianHB: I think we have enough time and should try to hit that date. 17:56:54 I am not worried about hitting a 1 June date for a draft. 17:56:58 dlongley: +1 to publishing a date to put pressure on is 17:57:02 q+ 17:57:07 PROPOSAL: Postpone release of an HTTP API FPWD until 1 June 2016 17:57:09 ack nicktr 17:57:09 +1 17:57:11 +1 17:57:22 +1 17:57:38 nicktr: What I am hearing is dave and manu saying "let's reprioritize". So are we kicking the problem down the road? 17:57:46 q? 17:58:09 I am saying that "yes, I am happy to apply energy to that" In particular since I am not personally working on the JS API. 17:59:00 Ian: We're chartered to do a certain API, but we don't have consensus on when we're going to do it. We should note that proposal of June 1 didn't gain traction, then we should come up w/ a different proposal - is there strong support for a June 1 2016 HTTP API. If it's not a priority, then we shouldn't have a date we don't think we're going to hit. 17:59:18 nicktr: I am hearing lukewarm support. 17:59:32 dlongley: Can we see people write -1 or +0 ? 17:59:52 +0 17:59:56 +1 17:59:59 I’m largley ambivalent on the HTTP API 18:00:06 +0? 18:00:17 _1 18:00:50 q+ 18:00:57 I will take that action 18:01:02 Ian: I have another proposal - for people that did +1, can you go caucus and write up a plan that's more detailed for what could happen. So people can look at it and say "yes, that's something I can get behind". That may not get any interest, but generating more support would be a good thing. 18:01:12 Ian: Getting more support is a good thing. 18:01:14 q? 18:01:17 changing my vote to _1 18:01:39 AdrianHB: I think we have no objections to the proposal. We have 5 people who support the proposal (who are interested in doing the work). 18:02:40 q+ 18:02:45 ack adrianba 18:02:47 Ian: I think you just re-iterated the proposal. 18:02:50 ack AdrianHB 18:02:58 AdrianHB: We have a proposal to deliver HTTP API in March 2016. 18:03:03 Ian: That's true, it's in the charter. 18:03:21 (I had not read it that way, but I can see that the charter suggests it) 18:03:25 AdrianHB: I suggest we resolve the proposal, not well supported, but we can resolve and move on. 18:03:26 In that light: +1 to the proposal 18:03:50 Nick: So the postponement to 1 June is SO RESOLVED for the HTTP API spec 18:03:54 topic: Next meeting 18:04:00 4 February 2016 18:04:07 rrsagent, make minutes 18:04:07 I have made the request to generate http://www.w3.org/2016/01/28-wpwg-minutes.html Ian 18:04:18 rrsagent, set logs public 18:05:55 rrsagent, bye 18:05:55 I see 1 open action item saved in http://www.w3.org/2016/01/28-wpwg-actions.rdf : 18:05:55 ACTION: Nicktr to contact the IG Chairs about taking up the terms [1] 18:05:55 recorded in http://www.w3.org/2016/01/28-wpwg-irc#T17-33-38