See also: IRC log
<manu> scribe: manu
Adrian: Matt is on leave for a
while - people are making good progress on flows.
... He's asking for input on flows being done - there have been
two review cycles.
... 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.
NickTR: I'll help w/ pushing
review cycles onto people next week.
... Specifically, with the flows.
Adrian: Doug and I had some good discussion this week on how we improve visibility of issues we're dealing with.
<Ian> Dashboard email
<Ian> Dashboard prototype
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.
<Zakim> 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.
<Ian> manu: Already helpful to me!
<Ian> ...I checked the dashboard and caught something I would not have caught.
AdrianHB: Give it a try and let us know.
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.
Ian: One question is if you've
written down goals for the project and how you anticipate how
people use dashboard.
... That might be nice to help - I'd be unlikely to start using
it regularly
... until I know how we intend to use it.
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.
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.
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.
<Ian> 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?
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.
... What do each of the columns mean?
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.
... When proposals get created, they go in the proposals
column, as stuff gets resolved, it moves to the right to the
"resolution" column.
... This is the meta-discussion flow that we have for the
moment.
Ian: So, a couple of questions -
how do I figure out what I should be doing?
... What is on our agenda next week?
... What proposals should I be reviewing?
... 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.
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.
... The hot items, we could label them as being on the agenda -
that's what proposals are for as well.
Ian: This is mostly to give a
flavor of what I'd want to see.
... I understand that there might be some limitations using
waffle.io
<AdrianHB> https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016
<Ian> Beginnings of agenda
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.
<Ian> (Current tally of registrants: 27 + around 6 guests)
<Ian> Please register -> https://www.w3.org/2002/09/wbs/83744/ftf-201602/
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.
... Then we'll be able to address specifically what we'll be
able to do at the meeting.
... I think they can help us understand use cases.
... 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.
... 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.
... 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...
... Anyone that has wireframes, send a mail to the group -
nick, Ian, doug - request time slot.
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.
<Ian> scribe: Ian
<manu> Nick: any other points on face-to-face?
adrianHB: We're logging criteria to be used when addressing issues
<manu> 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.
<manu> AdrianHB: We want issue list finalized by 16th of February.
adrianHB: the plan is to have the issues list available no later than 16 Feb
<manu> AdrianHB: There is a plan to have a set of issues to get us started.
<manu> AdrianHB: As the discussion progresses - things will morph as we go.
<manu> AdrianHB: We need to use this time to solve the difficult questions, some of which haven't come up yet - security, implementation details,
<manu> AdrianHB: any other questions? Raise it on calls.
<scribe> scribe: Ian
<AdrianHB> https://github.com/w3c/webpayments/issues/67
AdrianHB: Proposal was first put forward last week; since then we've had some adjustments based on feedback
PROPOSAL: Adopt ISO20022
terminology for payer and payee and use synonyms as
appropriate
... ground terms to an ISO20022 glossary
<AdrianHB> +1
manu: Question about implementation - should we put in the IG glossary?
<AdrianHB> +1 to pushing these terms to the IG glossary
<dezell> FWIW I believe we all agreed to keep one glossary for the activity, i.e. the IG to maintain.
PROPOSED: The WG recommends that the IG takes up these terms.
(and then once they are in the IG glossary, others can important them consistently)
<AdrianHB> 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.
[IJ agrees the right thing is very likely to happen. But I don't want to create dependencies unnecessarily]
<dezell> +1
<dlongley> +1
<zkoch> +1
<manu> +1
<Rouslan> +1
<AdrianHB> The following clause is no longer part of the proposal: "which will be dynamically pulled into all WPWG specifications."
RESOLUTION: (1) Adopt the terminology proposal (2) request that the IG adopt the terms in their glossary
<shepazu> +1
<AdrianHB> +1
<nicktr> +1
<scribe> ACTION: Nicktr to contact the IG Chairs about taking up the terms [recorded in http://www.w3.org/2016/01/28-wpwg-minutes.html#action01]
<trackbot> Created ACTION-12 - Contact the ig chairs about taking up the terms [on Nick Telford-Reed - due 2016-02-04].
PROPOSAL: Use strings to represent currency and amount per ISO20022 (Adrian)
https://github.com/w3c/webpayments/issues/57
(The proposal has more detail on formatting)
IJ: What was meant by strings are developer hostile?
AdrianHB: Developers will be working with numbers up to the time
<Zakim> Rouslan, you wanted to ask whether we're using commas or periods in strings. also how many digits after period/comma is ok.
adrianHB: I think the main concern was serialization; I think format will be more well-understood
<Rouslan> can everyone hear me ok?
<zkoch> Nope
<Rouslan> ok, here's my question.
<Rouslan> should we use commas or periods?
<zkoch> “real” -> it’s actually just me on another workstation pretending
IJ: The proposal is "dot"
<Rouslan> may i ask more questions?
<Rouslan> how many digits after the dot?
<AdrianHB> 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
AdrianHB: The proposal is silent
on the max number of digits after the dot
... ISO20022 has more strictly defined types
<zkoch> Doesn’t the proposal state: “The value of the currency property MUST be expressed as a string of 3 characters.”
<Rouslan> 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!
AdrianHB: they have had to update their types to deal with the fact that they wanted more precision
<zkoch> ohh, nevermind, dumb
AdrianHB: 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)
<Rouslan> +1 to not limit.
<manu> zkoch: but currency property being limited to 3 characters isn't good if we want extensibility (URLs for new currency types)
<shepazu> +1
<dlongley> why limit the currency to three characters?
<manu> yeah -1 to currency limited to 3 characters
<Zakim> manu, you wanted to note that amount.toString() is a really bad idea (floating point errors)
manu: amount.toString() based
idea due to floating point rounding errors
... so big -1 to developers working with currency amounts as
floats.
... the proposal has 8 things in it
... and there's one that's popping up as problematic ->
currency property limited to 3 characters
... I thought we had a discussion about being able to extend
(e.g., for new currencies)
<dlongley> +1 to drop restriction
AdrianHB: I am ok with dropping
3-letter string limit and allowing "string"
... but I think that 7 and 8 are good to keep
manu: I want us to be able to use URIs to identify currencies
dezell: agree it's bad practice to use amountTo.string()
<AdrianHB> amend 8 to say "universally understood code or identifier SHOULD be used"
dezell: also +1 to removing #6
restriction
... suggest that best practice is to use 3-digit code where
possible.
<Zakim> Ian, you wanted to suggest changes :)
<AdrianHB> amend 6 to say: The value of the currency property MUST be expressed as a string
<ShaneM> +1 to a best practice about currency code
<AdrianHB> best practice about currency code is dealt with in 7 and 8
<manu> 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.
<manu> 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.
<manu> Ian: It needs to be specific about how certain codes are processed.
IJ: One way of formulating the proposal is "what processors have to do" and "what users should do"
<dezell> Suggestion: define the code as a union of string{,3} and URL. More complex than that, but something like that.
<AdrianHB> 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"
<manu> 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.
<manu> Ian: Restrict proposal to only syntax questions.
<AdrianHB> counter-proposal: drop 6,7 and 8
IJ: And start to take notes on semantics.
<manu> I would be a +1 to that, remove 6, 7, and 8.
<manu> -1 for removing 2
<manu> Ian: I'd go as far as saying remove #2
<dlongley> -1 to remove 2
<manu> 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.
<manu> manu: I agree, we're trying to figure out what that object looks like, so very pro #2.
<manu> Ian: I can live w/ #1-#5.
PROPOSAL:
<ShaneM> +1 to removing 6, 7, 8
<manu> NickTR: Is there consensus that proposal is resolved if it's only items #1-#5?
Amounts MUST be represented as an object.
The amount object MUST have at least two named properties: "currency" and "amount".
The value of the amount property MUST be a string consisting only of numeric digits.
The value of the amount property MAY contain a single dot to denote separation of the fractional suffix from the rest of the amount.
If present, the dot MUST NOT be the first character of the amount.
The value of the currency property MUST be expressed as a string
<manu> fine w/ #6 w/o length restriction.
{Shows of support?}
<AdrianHB> +1
<ShaneM> ... oops. Yes 6 is okay with no length.
<dlongley> +1
+1
<dezell> +1
<manu> +1
<zkoch> +1
<ShaneM> +1
<shepazu> +1
<Rouslan> yes, i'm good, thank you.
SO RESOLVED
<Rouslan> _1
<Rouslan> +1
<shepazu> +1 to manu
Manu: Suggest people keep proposals short and atomic.
<Zakim> manu, you wanted to note why long proposals are problematic.
PROPOSAL: Postpone release of an HTTP API FPWD until 1 June 2016
<AdrianHB> +1
<AdrianHB> https://github.com/w3c/webpayments/issues/73
<AdrianHB> PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized.
Manu: I think there is more to the proposal than just a publication date
<manu> 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).
<dlongley> +1 to ian
<manu> 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.
<manu> 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.
PROPOSAL: Postpone release of an HTTP API FPWD until 1 June 2016
<dlongley> +1
<manu> Ian: I think this accomplishes what Manu wants but is implicit about some of the requirements.
adrianhb: tabled owl:sameAs english:putOnAgenda
manu: Does the group believe that the HTTP API is the "next thing that we should focus on"?
adrianHB: I don't know that it will "automatically shift" but rather when the JS API starts to stabilize
<manu> +1
IJ: +1 to question - do we believe that date?
AdrianHB: I think we have enough time and should try to hit that date.
<ShaneM> I am not worried about hitting a 1 June date for a draft.
dlongley: +1 to publishing a date to put pressure on is
PROPOSAL: Postpone release of an HTTP API FPWD until 1 June 2016
<manu> +1
<dlongley> +1
<AdrianHB> +1
nicktr: What I am hearing is dave and manu saying "let's reprioritize". So are we kicking the problem down the road?
<ShaneM> 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.
<manu> 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.
nicktr: I am hearing lukewarm support.
dlongley: Can we see people write -1 or +0 ?
<dezell> +0
<nicktr> +1
<zkoch> I’m largley ambivalent on the HTTP API
<zkoch> +0?
<zkoch> _1
<ShaneM> I will take that action
<manu> 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.
<manu> Ian: Getting more support is a good thing.
<dezell> changing my vote to _1
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).
<manu> Ian: I think you just re-iterated the proposal.
<manu> AdrianHB: We have a proposal to deliver HTTP API in March 2016.
<manu> Ian: That's true, it's in the charter.
(I had not read it that way, but I can see that the charter suggests it)
<manu> AdrianHB: I suggest we resolve the proposal, not well supported, but we can resolve and move on.
In that light: +1 to the proposal
Nick: So the postponement to 1 June is SO RESOLVED for the HTTP API spec
4 February 2016