17:03:11 RRSAgent has joined #apps 17:03:11 logging to http://www.w3.org/2016/06/02-apps-irc 17:03:13 adamR has joined #apps 17:03:14 Zakim has joined #apps 17:03:30 dwim has joined #apps 17:03:36 https://mit.webex.com/mit/j.php?MTID=m41d897ddf2e922b6374c95ac1ee115bf 17:03:49 AdrianHB has joined #apps 17:03:54 https://mit.webex.com/mit/j.php?MTID=m41d897ddf2e922b6374c95ac1ee115bf 17:04:15 present+ Mahesh, Adam, Ian, Dongwoo, AdrianHB 17:04:30 jnormore has joined #apps 17:04:48 https://mit.webex.com/mit/j.php?MTID=m41d897ddf2e922b6374c95ac1ee115bf 17:04:52 present+ Jason 17:06:55 Topic: Goal 17:07:06 Proposed: App spec by FTF 17:07:28 1 July available to the WG 17:07:40 adam: +1 17:07:50 +1 17:07:52 mahesh: +1 17:07:59 +1 17:08:14 maheshk has joined #apps 17:09:02 Question: How? :) 17:09:20 AdrianHB: we have a single document 17:09:32 ...if someone wants to propose a conceptual change, I think it affects a lot of the document 17:09:41 ...I have had challenges lately of making time for this 17:09:49 ..I hope to do more at least tomorrow and next week 17:09:55 ...not sure what availability is for others 17:10:03 ..and if we want to figure out a way to divide up work 17:10:07 q+ 17:11:06 q+ 17:11:18 IJ: I can translate wiki into spec form 17:11:19 ack me 17:11:24 adamR: +1 17:11:26 +1 too 17:11:32 +1 17:13:10 IJ: My proposal would be to move the content into "spec form" 17:13:16 and then let the rest of you write down what an API looks like 17:13:26 q? 17:13:35 ack adamR 17:13:35 AdrianHB: Then we should use the issues list 17:13:52 ...I think we could put up an idea or question, discuss it, and then someone can take an action to write a pull request 17:14:51 Goal is: 16 July discuss built up issues 17:15:07 16 June rather 17:15:13 maybe meet 23 June if needed 17:15:40 IJ might try to have an updated draft by 24 June and then people can share with the WG either right away or after more edits 17:16:21 +1 17:16:25 Ok with that as next step ("ball is in Ian's court") 17:16:25 +1 17:16:48 AdamR: At risk 16 June 17:17:02 topic: How can a Web Based Payment App cancel the payment flow? #128 17:17:05 https://github.com/w3c/webpayments/issues/128 17:17:07 Losing you again Ian 17:19:24 IJ: In a payment app spec, what needs to be said? 17:19:30 AdrianHB: How to return a failure response. 17:19:38 ...how does it say "here's a response" 17:19:44 IJ: response codes? 17:20:04 AdrianHB: Right, are there payment method specific response codes? What about a general "fail" response? 17:20:40 ...we may have some other failuremodeus 17:20:44 ...e.g., user cancels 17:20:51 ...or "no matching payment method" (browser error) 17:20:59 ...or app advertised something it supports but it can't really 17:21:19 ...so we may need a mechanism to enumerate failure modes and have a way to get data back to the browser 17:21:44 adamR: This is different from what communication mechanism to use 17:21:46 (IJ: Agrees) 17:22:23 Topic: Browser-based payment apps only (in v1)? Or any "Web app"? 17:24:16 Q: Do we only care about apps that work in the browser, or more? 17:24:32 adamr: Isomorphic...even if we just say "in the browser" those apps can call out to the wild (e.g., server-based apps) 17:24:59 AdrianHB: My point in being specific is that in the future, e.g., we will be dealing with IOT payments 17:25:10 ..."in the browser" requires people to register JS with the browser. 17:25:22 ..but we could do HTTP more easily 17:25:29 ...relates also to the question of registration 17:25:46 q+ 17:25:59 AdrianHB: I have come around to the notion that some JS will be necessary 17:26:03 q+ about usecase who calls registration API 17:27:25 IJ: Seems mostly isomorphic but perhaps not entirely 17:27:39 Adamr: You can use service workers in one case... 17:27:45 IJ: +1 to not having both 17:28:25 AdrianHB: I agree devs have a choice...people can do what they prefer with lightweight shims 17:28:51 ack mah 17:29:14 mahesh: When will registration take place? 17:30:14 ...what will user experience be? 17:30:37 me 30 mins 17:31:15 ...how do users know which browser they are registering with? 17:31:55 AdrianHB: Echoing back - some users have multiple browsers. When they register an app in one browser, they might not find the app when using a different browser 17:33:08 q+ 17:34:12 IJ: I expect people will be browsing, will be visiting web sites to register apps in the browser they are using 17:34:30 Mahesh: Another use case is the app is on the phone but the user is not signed up for it. 17:34:46 "Recommended app" 17:34:47 this is the enabled vs supported payment methods concept 17:35:47 IJ: I don't know whether "recommended app" will survive in the spec but it's been discussed 17:36:04 AdrianHB: In our spec we will define an API to let people register a payment app in a given browser. 17:36:15 ...I think that implementers of browsers or platforms will come up with OTHER (non-standard) ways 17:36:42 ..so, e.g., android might allow you to register an app and android might tell all browsers 17:37:01 ..to be clear we are defining the standard way but other platform-specific ways might exist. 17:37:28 AdrianHB: I understood Zach's comment today to be that the payment app should not take you on an enrollment process. 17:37:45 ..that is different from the merchant being able to recommend alternative payment apps before you invoke a given payment app 17:37:51 (IJ agrees with that distinction; thanks) 17:37:58 ...I think the latter one is useful 17:38:07 ...especially when the user has no apps installed 17:38:37 Mahesh: Thanks! 17:38:46 I have made the request to generate http://www.w3.org/2016/06/02-apps-minutes.html Ian 17:39:03 Topic: SUmmary 17:39:08 - Ian does next draft 17:39:12 - People raise issues in the list 17:39:18 - Next meeting 16 June 17:39:35 rrsagent, make minutes public 17:39:35 I'm logging. I don't understand 'make minutes public', Ian. Try /msg RRSAgent help 17:39:47 rrsagent, make minutes 17:39:47 I have made the request to generate http://www.w3.org/2016/06/02-apps-minutes.html Ian 17:39:49 rrsagent, set logs public 19:39:51 Zakim has left #apps