IRC log of wpwg on 2016-12-15

Timestamps are in UTC.

14:58:35 [RRSAgent]
RRSAgent has joined #wpwg
14:58:35 [RRSAgent]
logging to http://www.w3.org/2016/12/15-wpwg-irc
14:58:37 [trackbot]
RRSAgent, make logs public
14:58:37 [Zakim]
Zakim has joined #wpwg
14:58:39 [trackbot]
Zakim, this will be
14:58:39 [Zakim]
I don't understand 'this will be', trackbot
14:58:40 [trackbot]
Meeting: Web Payments Working Group Teleconference
14:58:40 [trackbot]
Date: 15 December 2016
14:58:52 [stan]
stan has joined #wpwg
14:59:03 [Ian]
agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161215
14:59:05 [Ian]
scribe: ian
14:59:12 [Max]
Max has joined #wpwg
14:59:17 [Ian]
Ian has changed the topic to: WPWG Conf Call - 15 Dec https://github.com/w3c/webpayments/wiki/Agenda-20161215
15:00:08 [manu]
present+ Manu
15:00:18 [Ian]
present+ Ian
15:00:21 [Ian]
present+ Max
15:00:44 [oyiptong_]
oyiptong_ has joined #wpwg
15:01:04 [rouslan]
rouslan has joined #wpwg
15:01:04 [Ian]
present+ Stan
15:01:19 [Ian]
present+ Rouslan
15:01:32 [Ian]
chair: NickTR
15:01:58 [dezell]
dezell has joined #wpwg
15:02:04 [dezell]
present+ dezell
15:02:16 [Ian]
present+ Olivier
15:02:35 [Ian]
present+ Alan
15:02:54 [Ian]
present+ AdrianHB
15:03:04 [Ian]
rrsagent, make minutes
15:03:04 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian
15:03:12 [Ian]
present+ Adam
15:03:18 [Ian]
regrets+ zkoch
15:03:28 [nicktr]
present+ nicktr
15:03:39 [Ian]
agenda => https://github.com/w3c/webpayments/wiki/Agenda-20161215
15:04:08 [Ian]
topic: end of year blog post
15:04:27 [manu]
Ian: I've started to work on an end of year Blog post at the end of the year, talking about progress, topics we've been looking at.
15:04:38 [manu]
Ian: Some payment method spec advancements, keep an eye out for that.
15:04:55 [Ian]
topic: Pre CR outreach
15:04:57 [manu]
Ian: The purpose is to give a high-level mention of topics for folks not closely following this work.
15:05:35 [alyver]
alyver has joined #wpwg
15:05:41 [AdrianHB]
+1 on Payment Apps progress
15:05:55 [manu]
Ian: In Lisbon, we discussed advancement to CR - take away was that folks wanted to see third party payment apps further along. Test suites, a couple of other things, I feel like we've made substantial progress on 3rd party payment app API. The Task Force resolved to go to FPWD for that spec. Trying to get what we can get done between now and then.
15:06:07 [manu]
Ian: So late January, early Feb, we'd have FPWD of Payment Apps API
15:06:25 [MaheshK]
MaheshK has joined #wpwg
15:06:48 [manu]
Ian: We're getting lots of edits/refinements of Payment Request... it's solidifying, we're getting deployments, if we look ahead, going to CR in February timeframe, one of the CR entry criteria is wide review. Can we start wide review process in early January?
15:06:54 [betehess]
betehess has joined #wpwg
15:07:19 [AdrianHB]
q?
15:07:28 [manu]
Ian: Since we have auto-publishing, all changes are in TR page, now I can point people at those specs comfortably. For example, have discussions with Privacy IG. Can we begin outreach, wider review of specs, make decision to go to CR -we've fulfilled that portion of that criteria.
15:07:34 [manu]
q+ to be concerned
15:07:40 [Ian]
ack manu
15:07:40 [Zakim]
manu, you wanted to be concerned
15:07:59 [Ian]
manu: My read for payment apps further along is we want to see implementation
15:08:01 [Ian]
q+
15:08:34 [Ian]
manu: I have no problem with getting review of PR API (the wide review part)
15:08:49 [Ian]
manu: We still haven't answered the digital signature question around payment requests
15:09:36 [manu]
Ian: I think that we can get wide review and that is independent of the need to close additional issues. I can't guarantee that there won't be new issues raised. We can continue to get wide review, so people can get a broader sense of review of these specs.
15:10:02 [manu]
Ian: Regarding payment app implementation - we're getting implementations. We know of native implementations, we are also doing experimentation with web-based payment apps.
15:10:32 [manu]
Ian: That is not a criteria for getting to FPWD, but there is a request to understand if web-based payment apps work with the Payment Request API.
15:11:03 [manu]
Ian: Regarding digital signatures, that's something that as a group, we'd want to address known issues before requesting to go to CR. I'm not suggesting that we rush that, only that we start the process of getting wide review, because that takes a while.
15:11:03 [nicktr]
q?
15:11:05 [Ian]
ack me
15:11:13 [manu]
All that sounds good, Ian.
15:11:18 [Ian]
Ian: Thanks Manu
15:12:18 [manu]
Ian: The sense I have from watching the Github discussions, implementers increasingly want stability, we've tried to move faster with PaymentApp API, we may get pushback from implementers of significant changes.
15:12:26 [AdrianHB]
q?
15:12:38 [manu]
Ian: It's thrilling to have implementations, people are excited about that.
15:12:52 [manu]
Ian: When we get wider review, we may face some challenges. That's the reality of doing this work.
15:12:57 [AdrianHB]
q+ to ask manu what he'd expect as a goal re signatures
15:13:04 [nicktr]
ack AdrianHB
15:13:04 [Zakim]
AdrianHB, you wanted to ask manu what he'd expect as a goal re signatures
15:13:04 [manu]
q+ to ask about "yes, but have you had the extra changes reviewed?"
15:13:27 [Ian]
AdrianHB: You've listed digital signatures as an issue you think we need to resolve before we go to CR
15:13:57 [Ian]
..are you satisfied if we say "The group has decided digital signatures are a payment methods specific topic"
15:14:33 [Ian]
Manu: the issue is "what is our strategy around digital signatures" and if our response is "it's per payment method" then I think it's not good enough; I want to ensure the group realizes it's painting itself into a corner
15:14:58 [Ian]
..it's not that I'm preposing a particular signature approach, I would like to have clarity around strategy
15:15:13 [manu]
This is the digital signature issue: https://github.com/w3c/browser-payment-api/issues/291
15:15:41 [Ian]
ack manu
15:15:41 [Zakim]
manu, you wanted to ask about "yes, but have you had the extra changes reviewed?"
15:15:52 [Ian]
Manu: No objection from me to putting out a call for pre-CR review; that's good and healthy
15:15:59 [nicktr]
ack manu
15:16:23 [Ian]
...we'll get reviews and then we'll have to show more review over changes
15:16:44 [pascal_bazin]
pascal_bazin has joined #wpwg
15:17:00 [Ian]
NickTR: I hear no objections to starting the process of soliciting wide review
15:17:01 [manu]
Correct, no objections (from me)
15:17:10 [Ian]
ACTION: Ian will begin soliciting wide review of PR API in January 2017
15:17:10 [trackbot]
'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
15:17:14 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian
15:17:15 [AdrianHB]
+1 let's start wide review process
15:17:18 [nicktr]
q?
15:17:31 [Ian]
topic: Detecting payment method availability
15:17:39 [adamR]
q+
15:17:45 [Ian]
ack ad
15:17:46 [nicktr]
ack adamR
15:18:05 [rouslan]
q+ to talk about active
15:18:06 [Ian]
adamR: I can't speak to the issue itself, but what I want to verify is whether we are doing this for "payment methods" or "active payment methods"
15:18:06 [MaheshK]
q+
15:18:15 [nicktr]
ack rouslan
15:18:15 [Zakim]
rouslan, you wanted to talk about active
15:18:15 [Ian]
ack rouslan
15:18:30 [Ian]
rouslan: The current text is silent on whether it's active or not. The Edge plan is to always return "true" for basic card
15:18:46 [Ian]
..the Chrome plan is to check whether the autofill store has info and return "true" accordingt6ly
15:18:48 [adrianba]
q+
15:18:52 [Ian]
...but this is left to the implementer
15:19:05 [nicktr]
q?
15:19:07 [Ian]
AdamR: And both are considered explicitly valid?
15:19:08 [Ian]
Rouslan: Yes
15:19:21 [Ian]
mahesh: Here's an update on the pull request
15:19:23 [pascal_bazin]
Sorry I'm late
15:19:43 [Ian]
...I spoke with Zach and he proposed to make some editorial changes to the PR
15:19:51 [Ian]
...Domenic Denicola is also reviewing it
15:20:03 [Ian]
...so it will be modifications to the current pull request <URL?>
15:20:17 [AdrianHB]
https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md
15:20:25 [nicktr]
q?
15:20:26 [Ian]
..the new PR is not yet there
15:20:27 [Ian]
ack M
15:20:34 [nicktr]
ack adrianba
15:20:38 [adrianba]
https://github.com/w3c/browser-payment-api/pull/380
15:20:45 [Ian]
adrianba: Zach and I met yesterday and we merged the new pull request in.
15:20:53 [Ian]
...we anticipate making some further changes
15:21:01 [Ian]
...this pull request doesn't distinguish active v. not active
15:21:28 [Ian]
...that's kind of by design, but the conversation Zach and I had was, based on WPWG discussions and the fact that we use the word "support" to mean different things, we need to elaborate on the text that's there for clarity
15:21:29 [Ian]
q+
15:21:39 [Ian]
..so that's now in the current spec and available for review
15:21:59 [Ian]
...we intend to add a note indicating that it's valid to limit "support' to mean "active" and also valid to not make that check
15:22:12 [Ian]
q+ to mention issue 367
15:22:24 [nicktr]
q?
15:22:27 [nicktr]
ack Ian
15:22:27 [Zakim]
Ian, you wanted to mention issue 367
15:22:31 [Ian]
https://w3c.github.io/browser-payment-api/#canmakepayment-method
15:22:40 [Ian]
ack me
15:22:46 [Ian]
Added issue 367 https://github.com/w3c/browser-payment-api/issues/367
15:22:58 [adrianba]
q+
15:23:28 [manu]
Ian: Matt Saxxon has been concerned about issue 367, was closed prematurely
15:23:35 [Ian]
ack ad
15:23:42 [nicktr]
ack adrianba
15:23:53 [Ian]
adrianba: Right now the language in the spec leaves it to implementations to make a determination about "the right way of limiting"
15:24:16 [Ian]
...nobody is happy with timeout even though timing is mentioned
15:24:19 [Ian]
...as a consideration
15:24:27 [Ian]
...we will probably change how we do this over time
15:24:53 [manu]
Ian: So, I'm hearing that the issue should stay open.
15:24:56 [Ian]
...so I don't think we need to say anything else
15:25:06 [Ian]
...changes and experimentation will continue after the spec is frozen
15:25:32 [nicktr]
q+ to be worldpay for a moment
15:25:38 [manu]
Ian: I don't think Matt Saxxon is on the call, we could ask him to close the issue if he is... but I suggest we leave it open until the person that wanted it raised is okay with the result.
15:25:40 [Ian]
ack nic
15:25:40 [Zakim]
nicktr, you wanted to be worldpay for a moment
15:26:03 [Ian]
nicktr: Thanks IJ for raising the issue that Matt is tracking; I'd like the issue to stay open for now....the question is whether we signpost that in the spec or not.
15:26:13 [Ian]
q?
15:27:01 [Ian]
IJ: I will put tokenization and credit transfer on a January agenda
15:27:05 [Ian]
....progress on both!
15:27:28 [Ian]
topic: PMI Specification
15:27:47 [Ian]
https://w3c.github.io/webpayments-method-identifiers/
15:28:16 [manu]
Ian: Based on filtering, use of URLs, etc. we've updated this spec.
15:28:39 [Ian]
https://github.com/w3c/webpayments-method-identifiers/issues/17
15:28:39 [manu]
Ian: There are still a number of issues, notably around Manifest spec, but AdrianHB raised some issues, before we get to those, there is one particular one... Issue #17 -
15:29:10 [manu]
Ian: We said that we constrained the shape of URls for PMIs, which include HTTPS every time. AdrianHB raised if that was overly constraining because of things he cited in the issue. Let's discuss
15:29:22 [Ian]
Text from AdrianHB's issue:
15:29:29 [Ian]
-----
15:29:29 [Ian]
There is a concern that having browsers all over the world fetching a manifest all the time will put significant strain on the hosts of the manifest.
15:29:29 [Ian]
There are protocols that are better at serving static content than HTTP such as IPFS. While they're not supported in most browsers yet, they may be soon.
15:29:30 [Ian]
So, should we be limiting the PMI URLs to https as the scheme or rather wording this as something that requires fetching the manifest through a SecureContext or similar?
15:29:31 [Ian]
----
15:30:07 [Ian]
Ian: There is a link from the spec to that issue
15:30:08 [manu]
q+ to provide input, if that would be helpful.
15:30:29 [Ian]
AdrianHB: HTTPS is restrictive in terms of how a manifest is hosting
15:30:42 [Ian]
...hosting a manifest is potentially a resource-intensive thing (for popular payment methods)
15:31:10 [Ian]
...while there are CDNs and cachgin, and there are better protocols e.g., for distribution
15:31:24 [Ian]
...so I would prefer we not have this limitation to HTTPs
15:31:38 [rouslan]
q+
15:31:43 [Ian]
ack manu
15:31:43 [Zakim]
manu, you wanted to provide input, if that would be helpful.
15:31:47 [nicktr]
ack manu
15:31:53 [Ian]
manu: +1 to AdrianHB's comment; I would not restrict to HTTPs
15:32:12 [nicktr]
q?
15:32:14 [Ian]
...the spec can say something about expectations for secure transport (e.g., HTTPs)
15:32:22 [Ian]
AdrianHB: +1 to HTTPs as an example
15:32:39 [nicktr]
q?
15:32:54 [Ian]
ack rouslan
15:33:07 [Ian]
rouslan: +1 to not saying HTTPs and talking about secure hosting
15:33:27 [nicktr]
q?
15:33:48 [manu]
Ian: We have a draft manifest spec
15:33:59 [manu]
Ian: That seems to be the appropriate place for discussion of secure hosting of manifest files.
15:34:02 [ShaneM]
present+ ShaneM
15:34:19 [Ian]
Delete "The URL scheme MUST be https. " from PMI spec
15:34:20 [manu]
Ian: So, this would mean that it's no longer a syntax of the payment method identifier, we could remove the constraint on the URLs from the PMI spec.
15:34:32 [manu]
Ian: There is another conversation that's happening, whether to put manifest spec in PMI spec
15:34:47 [manu]
Ian: I would say there are two modifications to make. Delete from syntax spec, add to manifest spec.
15:34:59 [nicktr]
q?
15:35:03 [manu]
Ian: I don't think there will be substantive impact to merge specs, but we could discuss more.
15:35:27 [Ian]
ACTION: AdrianHB to propose changes to PMI spec and Payment Manifest spec regarding loosening of the HTTPs syntax requirement and secure payment method manifest hosting
15:35:28 [trackbot]
Created ACTION-40 - Propose changes to pmi spec and payment manifest spec regarding loosening of the https syntax requirement and secure payment method manifest hosting [on Adrian Hope-Bailie - due 2016-12-22].
15:35:54 [Ian]
Topic: Addressing payment method manifest files
15:36:19 [Ian]
https://github.com/w3c/webpayments-method-identifiers/issues/19
15:37:06 [Ian]
(Adrian going into detail)
15:37:33 [Ian]
AdrianHB: Useful to be able to go in both directions; we need to take into account service workers
15:38:30 [manu]
Ian: Zachs proposal is outlined here - https://github.com/w3c/webpayments-method-identifiers/issues/19
15:39:03 [manu]
Ian: There are proposals for: Hard-coded URL, HTTP Link Header, Content Negotiation, Serve JSON for PMI, then link to human readable content from there.
15:39:25 [nicktr]
q?
15:39:26 [manu]
Ian: Those are four proposals on the table, some pros and cons based on what folks suggest. We need to figure out which of those we want to do.
15:40:24 [manu]
AdrianHB: The second bullet refers to what I was discussing
15:41:00 [manu]
Ian: In any case, we should post pone payment app discussion after payment method identifiers.
15:41:13 [manu]
Ian: So, this issue - https://github.com/w3c/webpayments-method-identifiers/issues/19
15:41:24 [manu]
Ian: These are the four options, is anyone else aware of other options that they think may get traction.
15:41:45 [manu]
Ian: Then folks can go off and study these, and then come back so we can discuss.
15:41:54 [Ian]
https://w3c.github.io/webpayments/proposals//Payment-Manifest-Proposal.html
15:41:57 [manu]
Ian: In the Payment Manifest spec...
15:41:59 [AdrianHB]
q+ to ask some questions about the issue?
15:42:36 [manu]
Ian: There is a section called "Manifest File Addressing" and cheated and said there is an algorithm. For example, you can use HTTP Link headers, and if that doesn't give you an answer, you can use a hard coded URL. Maybe not restrict and provide multiple methods via an algorithm.
15:42:48 [adamR]
q+
15:43:01 [manu]
Ian: I hesitate to go too far down that path, but we could use two of these. Header takes precedence over hard coded URL.
15:43:04 [nicktr]
ack AdrianHB
15:43:04 [Zakim]
AdrianHB, you wanted to ask some questions about the issue?
15:43:06 [Ian]
ack AdrianHB
15:43:14 [Ian]
AdrianHB: I have a few questions about the options in that issue.
15:43:36 [Ian]
...first high-level question - for a link header what would be the URL I would be visiting?
15:43:36 [manu]
Ian: The payment method identifier URL
15:43:40 [Ian]
IJ: You do a Head request on the PMI
15:43:58 [Ian]
..and we would register the header type with IANA
15:44:25 [manu]
q+ to ask about content negotiation?
15:44:27 [nicktr]
q?
15:44:34 [Ian]
AdrianHB: So I am hearing that the PMI points to (a potential) machine readable page, and HEAD on the PMI gives you a link for a registered header type.
15:44:43 [Ian]
...so options 2 and 4 seem relatively interchangeable
15:44:44 [nicktr]
ack adamR
15:44:44 [manu]
q-
15:45:07 [Ian]
adamR: We can add new link relations in the HTTP Link approach, but option 4 does not allow that
15:45:07 [Ian]
q+
15:45:32 [Ian]
adamR: Regarding an algorithm...we accrue the list of "cons"...I would steer us away from that approach
15:45:54 [manu]
Ian: One of the limitations of option #1 - you can only have a single manifest file.
15:46:13 [AdrianHB]
q+ to consider the ability of servers to do HEAD properly for option 2
15:46:18 [manu]
Ian: In different jurisdictions, you may want to serve different manifest files, therefore, having the ability to only get one takes you closer to content negotiation.
15:46:21 [nicktr]
ack ian
15:46:26 [manu]
Ian: You may be able to address multiple manifest files.
15:46:39 [manu]
Ian: Are there real world use cases for having different manifest files is useful?
15:46:51 [Ian]
ack AdrianHB
15:46:51 [Zakim]
AdrianHB, you wanted to consider the ability of servers to do HEAD properly for option 2
15:46:53 [manu]
Ian: Or, would you serve different files and you don't need to address them differently.
15:47:10 [Ian]
AdrianHB: One of the cons listed for conneg is the challenge of setting up servers; I appreciate that can be difficult to do
15:47:19 [Ian]
...but I am wondering how easy it is to set up Link headers
15:47:39 [manu]
q+ to wonder if conneg is a problem for payment method creators? How many of these folks are out there? Aren't they technically capable?
15:47:40 [Ian]
...is it possible to do HTTP Link stuff via <link>?
15:47:49 [adamR]
q+
15:47:58 [nicktr]
ack manu
15:47:58 [Zakim]
manu, you wanted to wonder if conneg is a problem for payment method creators? How many of these folks are out there? Aren't they technically capable?
15:48:17 [Ian]
manu: I don't think there will be a lot of payment method manifest files; maybe several hundred
15:48:43 [Ian]
...I think that it's not that hard to do
15:48:46 [AdrianHB]
+1
15:49:01 [nicktr]
q?
15:49:04 [manu]
Ian: There are concerns to caching as well
15:49:14 [Ian]
ack Adam
15:49:21 [AdrianHB]
(proxy support is a concern with conneg I think)
15:49:43 [Ian]
adamR: I was also going to say that, in terms of entities that will create these identifiers, those entities will have no difficulty with conneg config
15:50:06 [AdrianHB]
adamR:... or headers (option2)
15:50:21 [adamR]
s/conneg/link headers/
15:50:41 [Ian]
IJ: Remind me whether servers look at META for Link headers?
15:50:45 [Ian]
Shane: Not in general
15:51:07 [manu]
Ian: There are four options listed, suggestions about other options and support for existing four are welcome.
15:51:09 [Ian]
IJ: Welcome both other options and indications of support or concerns about the existing 4
15:51:16 [Ian]
...will return to this in January
15:51:32 [Ian]
---
15:51:33 [Ian]
Any optimization desirable for the case where someone wants to say "I have a URL for my payment method and want to allow any payment app to implement it; but don't want to host a manifest file."
15:51:34 [Ian]
---
15:52:16 [manu]
Ian: Matt was concerned around the ability for W3C to mint new URLs w/o paying the cost for serving manifest files where everyone else does.
15:52:44 [manu]
Ian: We don't want to prevent people from minting short names, but they need explicit support in browsers for shortnames.
15:53:20 [manu]
Ian: There are modern techniques for managing server load wrt. multiple trips to get manifest file and server load in HTTP/2 and proper config, these are much less significant performance issues. We should go in the direction of good practice to help them do the right thing.
15:53:56 [manu]
Ian: There may or may not be a connection to the approach that we're going to take for the addressing. We should hang on to this, don't recall if we have an issue for this explicitly. We should not lose sight of this wrt. payment method good practice note.
15:54:16 [Ian]
ACTION: Ian to add a note to the payment method good practice spec to not lose track of the performance topic
15:54:16 [trackbot]
'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
15:54:40 [Ian]
topic: Basic Card
15:54:58 [Ian]
nicktr: I am seeing traction within EMVCo to engage with W3C on basic and tokenization topics
15:55:22 [Ian]
https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md
15:55:33 [Ian]
q?
15:56:42 [manu]
Ian: Asking for input on https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md
15:56:44 [nicktr]
q+ to note all those short names are EMVco members
15:57:08 [Ian]
IJ: Please provide feedback on the proposal
15:57:09 [manu]
Ian: That issue will affect tokenizatin spec, SEPA CT spec, feedback is welcome.
15:57:09 [Ian]
ack nicktr
15:57:09 [Zakim]
nicktr, you wanted to note all those short names are EMVco members
15:57:26 [Ian]
ACTION: NickTR to ask EMVCo if they would be ok with our use of short strings this way
15:57:26 [trackbot]
Created ACTION-41 - Ask emvco if they would be ok with our use of short strings this way [on Nick Telford-Reed - due 2016-12-22].
15:57:35 [adamR]
Tentative +1 to put network names in their own spec (or registry, but W3C doesn’t have a registry story….)
15:57:56 [Ian]
Topic: meetings
15:58:01 [Ian]
Next teleconf is 5 January
15:58:25 [Ian]
FTF: proposed 23-24 March in Chicago week before IETF
15:59:27 [Ian]
PROPOSED: 23-24 March in Chicago
15:59:37 [adamR]
+1 for date and city
16:00:43 [dezell]
q+
16:01:13 [Ian]
ack dezell
16:01:14 [nicktr]
ack dezell
16:01:44 [AdrianHB]
+1 with dates and venue
16:01:46 [Ian]
IJ: Perfectly happy to have the IG meet alongside that
16:01:56 [nicktr]
+1 for dates nad venue
16:01:56 [Ian]
..it's not precluded
16:02:40 [Ian]
RESOLVED: Next WPWG FTF meeting is 23-24 March in Chicago
16:02:45 [MaheshK]
Happy Holidays everyone!
16:02:48 [alyver]
alyver has left #wpwg
16:02:53 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian
16:04:11 [Ian]
tx
16:04:52 [Ian]
rrsagent, make minutes
16:04:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian
16:04:55 [Ian]
rrsagent, set logs public
16:34:49 [stan]
stan has joined #wpwg
16:38:14 [zkoch_]
zkoch_ has joined #wpwg
17:55:52 [betehess]
betehess has joined #wpwg
18:31:50 [Zakim]
Zakim has left #wpwg
18:55:05 [adamlake]
adamlake has joined #wpwg
19:23:16 [stan]
stan has joined #wpwg
19:38:45 [betehess]
betehess has joined #wpwg
19:46:41 [olivexu1]
olivexu1 has joined #wpwg
20:18:04 [adamlake]
adamlake has joined #wpwg
20:18:52 [stan]
stan has joined #wpwg
21:12:20 [betehess]
betehess has joined #wpwg
21:30:01 [betehess]
betehess has joined #wpwg
22:09:56 [stan]
stan has joined #wpwg
22:44:50 [zkoch_]
zkoch_ has joined #wpwg
22:46:32 [stan]
stan has joined #wpwg
22:52:29 [zkoch_]
zkoch_ has joined #wpwg
23:11:36 [zkoch_]
zkoch_ has joined #wpwg
23:24:48 [betehess]
betehess has joined #wpwg