15:24:03 <RRSAgent> RRSAgent has joined #pwg
15:24:03 <RRSAgent> logging to https://www.w3.org/2019/04/29-pwg-irc
15:24:04 <ivan> rrsagent, set log public
15:24:04 <ivan> Meeting: Publishing Working Group Telco
15:24:04 <ivan> Chair: garth
15:24:04 <ivan> Date: 2019-04-29
15:24:04 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Apr/0026.html
15:24:04 <ivan> ivan has changed the topic to: Meeting Agenda 2019-04-29: https://lists.w3.org/Archives/Public/public-publ-wg/2019Apr/0026.html
15:24:05 <ivan> Regrets+ BillK, mateus, luc
15:24:30 <ivan> regrets+ george
15:51:02 <laurent_> laurent_ has joined #pwg
15:51:58 <NickRuffilo> NickRuffilo has joined #pwg
15:54:08 <Rachel> Rachel has joined #pwg
15:56:36 <George> George has joined #pwg
15:57:16 <ivan> present+
15:58:21 <ivan> present+ NickRuffilo
15:58:39 <ivan> regrets- george
15:58:43 <ivan> present+ george
15:58:47 <Rachel> present+
15:58:50 <wendyreid> present+
15:59:03 <dauwhe> present+
15:59:33 <George> present+ George
15:59:55 <laurent_> present+
15:59:58 <romain> romain has joined #pwg
16:00:33 <geoffjukes> geoffjukes has joined #pwg
16:01:07 <ivan> present+ teenya
16:01:19 <NickRuffilo> ScribeNick: NickRuffilo
16:01:21 <franco> franco has joined #pwg
16:01:21 <romain> present+
16:01:32 <ivan> present+ geoffjukes
16:01:34 <franco> present+
16:01:40 <JunGamo> JunGamo has joined #pwg
16:01:46 <gpellegrino> gpellegrino has joined #pwg
16:01:50 <gpellegrino> present+
16:01:51 <wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-04-15-pwg
16:01:55 <JunGamo> present+
16:02:03 <NickRuffilo> Wendy: First agenda item.  Meeting minutes from last meeting.  (4-15)  Comments or questions?
16:02:13 <ivan> resolved: last meeting minutes accepted
16:02:21 <NickRuffilo> ... minutes approved.
16:02:23 <Avneesh> Avneesh has joined #pwg
16:02:34 <dkaplan3> dkaplan3 has joined #pwg
16:02:35 <Teenya> Teenya has joined #pwg
16:02:36 <ivan> topic: packaging (LPF) format issues
16:02:41 <rkwright> rkwright has joined #pwg
16:02:41 <NickRuffilo> ... Today we're going to discuss packaging format - the "lightweight packaging format"  Laurent - please take us through the issues to discuss
16:02:43 <Teenya> present+
16:02:49 <Avneesh> present+
16:02:57 <dkaplan3> present+
16:02:58 <bigbluehat> present+
16:03:04 <rkwright> present+
16:03:16 <NickRuffilo> Laurent: Hello!  After the first time we discussed - i took the issues and modified the document with the results of the issues.  I propose that we go through all of them.  They should be no-brainers, so this should be quick to decide.
16:03:18 <BenSchroeter> BenSchroeter has joined #pwg
16:03:27 <ivan> subtopic: media type
16:03:27 <BenSchroeter> present+
16:03:31 <david_stroup> david_stroup has joined #pwg
16:04:00 <User2> User2 has joined #pwg
16:04:01 <ivan> link: https://github.com/w3c/pwpub/issues/29
16:04:27 <NickRuffilo> ... I invite you to open reference #6 - the upf light document. The first issue is issue #29 - we need to decide on the media type of the format.  We want to use application-lpf+zip since lpf is lightweight packaging format, the +zip is that the underlying format is zip
16:04:28 <ivan> github-bot, bye
16:04:28 <github-bot> github-bot has left #pwg
16:04:43 <wendyreid> q?
16:04:50 <marisa> marisa has joined #pwg
16:04:52 <CharlesL> CharlesL has joined #pwg
16:04:56 <NickRuffilo> ... It was discussed - but are there any comments on this proposal?
16:04:59 <CharlesL> present+
16:05:04 <marisa> present+
16:05:19 <ivan> proposed: media-type: application/lpf+zip, extension: .lpf
16:05:35 <mattg> mattg has joined #pwg
16:05:44 <mattg> present+
16:05:49 <geoffjukes> +1
16:05:52 <laurent_> +1
16:05:54 <NickRuffilo> +1
16:05:58 <JunGamo> +1
16:06:01 <ivan> +1
16:06:02 <rkwright> +1
16:06:06 <George> q+
16:06:11 <dauwhe> q+
16:06:15 <wendyreid> ack George
16:06:29 <NickRuffilo> George: I'm assuming there are no conflicts with this extension on the various operating systems where they are registered?
16:06:36 <dauwhe> https://filext.com/file-extension/LPF
16:06:55 <NickRuffilo> Laurent: I looked at the list, and it was only used in a very obscure way, and it wasn't registered.  Do you know of an open list of media types that we can check?
16:07:03 <garth> garth has joined #pwg
16:07:09 <garth> present+ Garth
16:07:16 <Rachel> 0 - I don't understand the impact clearly enough to vote
16:07:19 <NickRuffilo> George: I don't know, but I just recall how long it took to get epub recognized by the various browsers so that it would download.  As long as there are no conflicts.
16:07:28 <wendyreid> ack dauwhe
16:07:32 <garth> q?
16:07:38 <duga> duga has joined #pwg
16:07:47 <duga> present+
16:07:47 <NickRuffilo> Dave: I had a similar question to George - the only LPF I find is unrelated and not widely used, so i think we're pretty safe
16:08:20 <garth> +1
16:08:23 <geoffjukes> FYI https://www.iana.org/assignments/media-types/media-types.xhtml
16:08:35 <laurent_> also found the obscure https://assiste.com/Types_de_fichiers/Extension_LPF.html
16:08:38 <NickRuffilo> Wendy: Any additional votes for the media-type application/lpf+zip and extension: .lpf ?
16:08:51 <BenSchroeter> +1
16:09:15 <gpellegrino> +1
16:09:16 <George> +1
16:09:26 <dauwhe> 0
16:09:47 <duga> 0
16:09:51 <dkaplan3> 0
16:10:10 <CharlesL> 0
16:10:12 <mattg> 0
16:10:13 <marisa> 0
16:10:28 <ivan> resolved: media-type: application/lpf+zip, extension: .lpf
16:10:33 <garth> https://github.com/w3c/pwpub/issues/42
16:10:37 <ivan> subtopic: entry.html
16:10:46 <Karen> Karen has joined #pwg
16:11:08 <NickRuffilo> George: The next item in line is issue #42 -> changing the name of the primary entry page from entry.html to index.html.  Quickly looking at the comments -> Laurent?
16:11:27 <NickRuffilo> Laurent: we've seen the comments.  It was opened by Dave, but there is agreements in the comments - any comments here?
16:11:41 <ivan> proposed: use entry.html instead of index.html
16:11:43 <geoffjukes> +1
16:11:45 <garth> proposal: go with index.html
16:11:47 <garth> +1
16:11:48 <duga> 0
16:11:51 <NickRuffilo> Ivan - flip that
16:12:02 <ivan> +1
16:12:03 <bigbluehat> +1
16:12:05 <mattg> 0
16:12:12 <wendyreid> +1
16:12:16 <geoffjukes> recount!
16:12:18 <George> +1
16:12:21 <rkwright> +1
16:12:23 <CharlesL> +1
16:12:29 <laurent_> +1
16:12:31 <BenSchroeter> +1
16:12:32 <Rachel> +1
16:12:33 <dkaplan3> +1
16:12:34 <NickRuffilo> +1 to index.html as entry page
16:12:37 <romain> +1
16:12:39 <josh> josh has joined #pwg
16:12:40 <ivan> resolved: go with index.html
16:12:41 <franco> +1
16:12:46 <NickRuffilo> Garth: This one is resolved.
16:12:55 <garth> https://github.com/w3c/pwpub/issues/43
16:13:00 <garth> q?
16:13:15 <ivan> Subtopic: Renamed the required `manifest.jsonld` to `publication.json`
16:13:17 <NickRuffilo> Laurent: Next is #43 - rename the manifest jsonld to publication.json
16:13:32 <josh> present+
16:13:43 <NickRuffilo> Ivan: From a JSON LD point of view, either is fine.  The original comment is about avoiding using the word manifest - which is used all over the place
16:13:50 <garth> Propopsed: go with manifest.json
16:14:04 <ivan> s/Propopsed/proposed/
16:14:05 <ivan> +1
16:14:08 <garth> +1
16:14:11 <laurent_> +1
16:14:14 <josh> +1
16:14:20 <bigbluehat> q+
16:14:46 <dkaplan3> present+
16:14:47 <NickRuffilo> Benjamin: The proposal says go with manifest.json - but the issue is about renaming it to publication.  So the proposal should be to use publication.json...
16:14:55 <garth> Proposal: Go with proposal.json
16:14:56 <gpellegrino> gpellegrino has joined #pwg
16:14:58 <geoffjukes> I think everyone is having a Monday...
16:15:01 <dkaplan3> s/present+/+1/
16:15:10 <duga> +1
16:15:18 <NickRuffilo> +1 to publication.json
16:15:19 <geoffjukes> +1 to publication.json
16:15:22 <BenSchroeter> +1 to use publication.json
16:15:23 <rkwright> +1
16:15:24 <bigbluehat> +1 to publication.json
16:15:25 <CharlesL> +1
16:15:30 <josh> +1 publication.json
16:15:32 <George> +1
16:15:32 <wendyreid> +1 to publication.json
16:15:35 <Rachel> +1
16:15:39 <NickRuffilo> Garth: Resolved...
16:15:50 <NickRuffilo> Laurent: Issue is #31 - proposal is to do nothing.
16:15:52 <garth> https://github.com/w3c/pwpub/issues/31
16:16:02 <ivan> resolved: go with publication.json
16:16:19 <ivan> Subtopic: Allow signing the components of a package
16:16:27 <NickRuffilo> ... In OCF there was a signature and a definition about not using something complex - but to use hash mechanism of resources as a way to show completeness
16:16:33 <garth> Proposal: Don’t define a signature mechanism (certainly not signature.xml!)
16:16:38 <garth> q?
16:16:40 <NickRuffilo> ... it seems we do not need to define any additional information
16:16:47 <bigbluehat> ack bigbluehat
16:17:03 <garth> +1
16:17:04 <josh> +1 to no signature mechanism
16:17:10 <laurent_> +1
16:17:11 <NickRuffilo> Garth: I put a proposal matching what laurent just said.
16:17:13 <dauwhe> q+
16:17:19 <NickRuffilo> +1 to no signature mechanism
16:17:20 <garth> ack dauwhe
16:17:49 <duga> +1
16:17:52 <garth> q?
16:17:53 <dauwhe> +1
16:17:53 <NickRuffilo> Dave: I would note that epub has this mechanism but the community group was opposed to putting any requirements on this - so you could have an invalid signature and things still display to the reader...
16:17:59 <BenSchroeter> +1
16:18:02 <ivan> +1
16:18:04 <rkwright> +1
16:18:07 <ivan> resolved: Don’t define a signature mechanism (certainly not signature.xml!)
16:18:10 <dkaplan3> +1
16:18:20 <garth> https://github.com/w3c/pwpub/issues/37
16:18:21 <ivan> subtopic: Relative IRI-s section in the LPF document
16:19:18 <NickRuffilo> Laurent: Next - 37 - proposed by Ivan.  The rewriting of the section about IRI.  Section 2.3.  Ivan has proposed to rewrite something simple, and I proposed to remove IRI and use URL instead, even if IRI are valid - but no one is using it...
16:20:05 <ivan> q+
16:20:14 <romain> q+
16:20:21 <garth> ack ivan
16:20:21 <NickRuffilo> ... everyone understands a URL.  Relative URLs would be the target language.  There was a reference to RFC, but we removed it...  I think the text that is now in 2.3 is sufficient in what we want to express.
16:20:53 <NickRuffilo> Ivan: To make it easier, and Matt is on the call, we make a reference from the packaging document to wpub - because in wpub there is a longer description of this.  There is a reference with a longer comment...
16:21:16 <bigbluehat> q+
16:21:28 <NickRuffilo> ... in the reference to URLs in the HTML spec.  There is a mess about this term and a longer description in the HTML spec at the end to say "we use URL which may include other uses" so it's taken care of.
16:21:51 <NickRuffilo> ... essentially what the web publication document does is say we won't redefine the wheel - in that chain, the document refers there.
16:22:18 <garth> ack romain
16:22:51 <NickRuffilo> Romain: I was going to ask about what was meant about following the rules?  This refers to the specific paragraph about URLs - in part 1 publication manifest.  We should be more specific and link out.
16:23:32 <NickRuffilo> ... the other point is that it leads to a question about web publications and the relationship to the manifest and canonical manifest (which is authoritative).  In the canonical manifest, all the URLs are made absolute.  So what we see are a serialization of a manifest.
16:23:32 <garth> ack bigbluehat
16:24:07 <romain> for the record, the Web Pub section on URLs in the manifest: https://www.w3.org/TR/wpub/#value-url
16:24:22 <NickRuffilo> Benjamin: I was hoping someone was more qualified is available, but it takes us back to the IRI note - Japan and other cultures, less restricted to 26 characters, do use IRIs to represent their URLs.  Whether that's necessary in spec language is orthongal, but we shouldn't dismiss it...
16:24:29 <garth> q?
16:25:03 <NickRuffilo> .. it's heavily used elsewhere, but maybe not where we are.  Specifically - what processing and parsing algorithm, as there is a host of them.  The HTML one is fine for what it is, but it assumes a browser context and in the case of an audiobook, may not come with the same constraint...
16:25:12 <garth> q?
16:25:14 <ivan> q+
16:25:18 <NickRuffilo> ... which could introduce more things - so the URI spec might be better.
16:25:22 <JunGamo> In Japanese web, I believe using only URL is fine enough.
16:25:26 <garth> ack ivan
16:25:26 <ivan> https://www.w3.org/TR/html52/references.html#normative
16:25:26 <bigbluehat> URI 3986 https://tools.ietf.org/html/rfc3986
16:25:45 <timCole> timCole has joined #pwg
16:26:40 <NickRuffilo> Ivan: I put in IRC a reference here.  This is the normative reference. There is a reference to URL - then a very long note (somewhat unusual) about URL and all the various terms.  I think as far as we are concerened, we should accept whatever the HTML spec does.  The HTML spec is used in japan.
16:26:46 <garth> q?
16:26:50 <NickRuffilo> ... if it works for users in general, we should just say "this is what we do."
16:27:08 <George> q+
16:27:10 <NickRuffilo> Garth: That seems sensible - does anyone have a different view?
16:27:38 <garth> q?
16:27:43 <garth> ack George
16:27:44 <NickRuffilo> Ivan: As far as I remember, this is what we refer to in the web publication document.  And explicitly we can refer to this note.  The LPF document shouldn't point to anything more than what is done in the web publication doc.
16:28:16 <NickRuffilo> George: this is for my lack of understanding - when we say absolute URL, we're talking about www.somehting.com/whatever but when it's in the package and unzipped, isn't it necessary to use a relative URL in order to consume that file?
16:28:26 <ivan> q+
16:29:09 <NickRuffilo> Ivan: This comes back to the question from Romain - a relative URL is relative to the canonical URL, which is doable.  On the other hand, you might have an absolute URL which refers to a file that is relative.  Both should be OK for a reading system.
16:29:17 <garth> ack ivan
16:29:30 <bigbluehat> q+
16:29:31 <NickRuffilo> ... this is not a perfect answer because the canonicalization gives absolute URLs - which might refer to the same area.
16:29:38 <garth> ack bigbluehat
16:30:07 <NickRuffilo> Benjamin: This is in a package, distributed into a device with or without device - there are absolute URLs that are different than what the system will have locally.  The system will not know that things map together...
16:30:22 <garth> q?
16:30:26 <NickRuffilo> ... a relative URL in a zip file would should relative items.
16:30:27 <NickRuffilo> q+
16:30:29 <ivan> q+
16:31:21 <NickRuffilo> ... the related thing in JSON LD which could solve for this - it's called @base and it's a way to include in the JSON LD what you are relative to.  This introduces a way to have all urls relative to a specific value - but then locally if that isn't there, then the processing system isn't there.
16:31:36 <NickRuffilo> ... so it could also be used to turn the filesystem into a related url set...
16:31:41 <garth> ack NickRuffilo
16:33:45 <garth> ack ivan
16:34:07 <duga> q+
16:34:15 <garth> ack duga
16:34:19 <garth> q+ ivan
16:35:25 <NickRuffilo> Nick: If we use the root - such as "localhost/" and everything builds off that - wouldn't URLs all be absolute?  If items are relative - could there be an issue of accesing items outside of the file itself...  Would the file URL base be the origin?  So - could the file itself be considered similar to using a localhost server
16:37:23 <duga> It is dangerous to conflate "localhost" and opening a local file. In the first case, we are opening a file from a server that happens to have a well known ip address, and any file opened that way will have the same origin. In the second case, we have a local file that will have a different origin than other files opened the same way
16:38:23 <NickRuffilo> Ivan: Let step back a few levels here - I think that it is correct what Romain said - that canonicalization requiring the absolutization of the URL may create problems here.  Because the canonicalization is in fact a series of specs to make clear what the user agent has to do with the information...
16:39:02 <NickRuffilo> ... there is nothing imposed there.  I may propose that we raise an issue that the absolutization step should be removed from the canonicalization but maybe try to use what benjamin noted - so what Benjamin does is clear...
16:39:11 <romain> q+
16:39:18 <garth> ack ivan
16:40:15 <NickRuffilo> .. then a packaging environment can go happily.  I still believe this is not something that should be defined by us.  The lightweight packaging format should refer to the web publication - then the responsibility to properly describe it is in the web publication document.
16:41:17 <NickRuffilo> Romain: there is potentially another issue related to all that - which may not be resolved by removing absolutization.  When it comes to obtaining a manifest, and the origin of the entry page.  At some point we will have to modify the algorithm, or define the origin of the lightweight package.
16:41:18 <garth> q?
16:41:19 <laurent_> q+
16:41:27 <garth> ack romain
16:41:33 <garth> ack laurent_
16:41:43 <bigbluehat> q+
16:41:50 <romain> q+
16:41:55 <bigbluehat> q-
16:41:57 <bigbluehat> q+
16:41:57 <NickRuffilo> Laurent: I don't think we can define the origin within the package.  it's when the package is put somewhere and exposed - it's up to the publisher/distributor to define the origin of the web publication.  The package itself has no origin.
16:42:11 <garth> ack romain
16:42:32 <dauwhe> q?
16:42:34 <garth> ack bigbluehat
16:42:36 <NickRuffilo> Romain: I think we then have to define the rules how a user agent may or must define the origin of a package.  These give alot to the user agent, and unless we define it we will ahve interoperability issues.
16:42:40 <dauwhe> q+
16:43:13 <NickRuffilo> Ben: I wanted to continue what Romain said - the origin isn't somehting the publisher decides, it's the user agent.  On the web, it's related to where you hit the thing, but the origin is restricted to a space defined by the user agent.  We have the origin spec to determine what to do with that.
16:43:48 <garth> q?
16:43:50 <NickRuffilo> ... in the case of something opened out of a zip file - there is a defined origin for that.  Because zip file could be used within an android app and unpackaged - they are going to create their own origins, then create a space of null origin where it's heavily (or un) restricted
16:44:22 <NickRuffilo> ... and the developers need to know what they can/should do.  Whe ahven't said that the manifests in the package are restricted to what is in the package - for example, it could bull in data from outside the package and from the web.
16:44:35 <garth> ack dauwhe
16:44:36 <NickRuffilo> Garth: We wanted to get trhough more, but not sure we can push through this.
16:45:08 <NickRuffilo> Dave: I wanted to emphasis what Romain and Benjamin just said - this is a problem we need to solve and is key to security.  We can't end up where there is not an origin and we have issues like in epub.
16:45:29 <garth> q?
16:45:45 <NickRuffilo> Garth: Given that, can we say the changes made in LPF should point back to WP
16:46:22 <laurent_> q+
16:46:24 <NickRuffilo> Garth: Can we agree on this at this stage?  That is where the LPF spec is in the current draft.
16:46:57 <garth> Proposal: LPF draft is okay as (with deep link added), additional issues to be rasied in WP.
16:47:01 <NickRuffilo> Laurent: I can try to add a deep link to the proper section in the web specification - a link to 2.6.3.3 but I don't really know the best way to do it.  Maybe I would need some advice.
16:47:24 <garth> Proposal: LPF draft is okay as is (with deep link added to WP), additional issues to be rasied in WP.
16:47:37 <romain> -0.5
16:48:02 <ivan> q+
16:48:02 <laurent_> q+
16:48:14 <garth> ack laurent_
16:48:17 <NickRuffilo> +1 to move language and table conversation
16:48:24 <josh> q+
16:48:37 <rkwright> +1 to tabling.  Too many questions
16:48:48 <garth> q?
16:49:17 <romain> (-0.5 because it's likely that the origin issue will need to be addressed specifically in the LPF)
16:49:18 <NickRuffilo> Laurent: in section 3 - maybe it would be there we express that the user agent exposes a package as a web application, it has to decide what the origin is of the web publication.  it's not an issue of web publication, but processing a package when it becomes a web publication...
16:49:28 <NickRuffilo> ... so it's related to packaging...
16:49:54 <NickRuffilo> Garth: There seems to be lots of votes for tabling for next week in boston.  Then we do need to have some time for F2F logistics
16:49:54 <garth> ack ivan
16:50:22 <ivan> summary: deep link to WP, raise an issue on absolutization, and discuss origin vs. packages
16:50:41 <garth> +1
16:50:46 <NickRuffilo> Ivan: I agree with Tabling - whatever semantics we use on it.  Those items are the 3 that came up that we have an agreement on that we need to discuss.
16:50:50 <romain> +1
16:51:06 <mattg> mattg has joined #pwg
16:51:23 <NickRuffilo> ... We will have to discuss origin VS packages.  Not sure what document - i have no idea what should be put there yet.  Maybe both should be separate issues?
16:51:27 <garth> Proposal: deep link to WP, raise an issue on absolutization, and discuss origin vs. packages (at F2F)
16:51:33 <garth> +1
16:51:36 <ivan> +1
16:51:37 <laurent_> +1
16:51:40 <NickRuffilo> Garth: I'm turning your summary into a proposal - then we'll revote
16:51:41 <romain> +1
16:51:43 <timCole> +1
16:51:46 <NickRuffilo> +1
16:52:05 <josh> +1
16:52:09 <rkwright> +1
16:52:29 <NickRuffilo> Garth: Do we have time for 1 more?
16:52:31 <ivan> resolved: deep link to WP, raise an issue on absolutization, and discuss origin vs. packages (at F2F)
16:52:36 <garth> https://github.com/w3c/pwpub/issues/5
16:52:52 <ivan> Subtopic: First-class citizenship of resources in PWPs
16:52:53 <NickRuffilo> Laurent: Issue 5 - if we summarize - there was an ask that any resource should be addressable via URI/URLs - that's what we've done in the wording
16:53:02 <garth> Proposal: Existing text resolved this.
16:53:13 <garth> +1
16:53:17 <laurent_> +1
16:53:21 <ivan> +1
16:53:21 <geoffjukes> +1
16:53:24 <NickRuffilo> +1
16:53:27 <josh> +1
16:53:35 <garth> q?
16:53:36 <rkwright> +1
16:53:36 <ivan> resolved: Existing text resolved this.
16:53:51 <garth> ack josh
16:53:54 <josh> q-
16:54:03 <ivan> q+
16:54:18 <garth> ack ivan
16:54:34 <NickRuffilo> Ivan: before we move to the next topic - i have an admin question for Laurent - When I clean up the minutes, I'll put in comments on all the resolutions, which means most of the issues can be closed.  Will you close them when you have them in the document?
16:54:46 <NickRuffilo> Laurent: I can close them - but there is one that requires additional action.
16:55:09 <NickRuffilo> Garth: Lets take 38, 17, and 40 which we can discuss in Boston
16:55:09 <garth> q?
16:55:21 <ivan> topic: F2F practicalities
16:55:22 <garth> https://docs.google.com/document/d/1-TB-_KCg97smmjcsbIVpi728qduOwESr3Og91-2Gtd4/edit#heading=h.9kn2s1bey23f
16:56:08 <NickRuffilo> Garth: let's take 1-2 minutes to talk f2f stuff.  It's very close to the RED line at the Kendall MIT stop.  The logistics are in the document.
16:58:15 <dkaplan3> q+
16:59:04 <dauwhe> q?
16:59:26 <garth> q?
17:00:16 <garth> ack dkaplan3
17:00:26 <garth> q?
17:00:27 <dauwhe> Ice Cream Social Sunday night :)
17:00:38 <garth> ack dkaplan
17:01:27 <CharlesL> CharlesL has left #pwg
17:01:33 <JunGamo> JunGamo has left #pwg
17:16:47 <dkaplan3> dkaplan3 has left #pwg
17:43:58 <Karen> Karen has joined #pwg
19:38:30 <Karen> Karen has joined #pwg
19:50:12 <plinss_> plinss_ has joined #pwg
20:17:35 <Karen> Karen has joined #pwg
20:29:16 <Zakim> Zakim has left #pwg
23:06:54 <Karen> Karen has joined #pwg
23:57:43 <Karen> Karen has joined #pwg