IRC log of tagmem on 2011-03-03

Timestamps are in UTC.

17:46:16 [RRSAgent]
RRSAgent has joined #tagmem
17:46:16 [RRSAgent]
logging to
17:48:30 [plinss]
zakim, this will be TAG_Weekly
17:48:30 [Zakim]
ok, plinss; I see TAG_Weekly()1:00PM scheduled to start in 12 minutes
17:56:01 [johnk]
johnk has joined #tagmem
18:00:00 [Zakim]
TAG_Weekly()1:00PM has now started
18:00:07 [Zakim]
18:00:24 [Larry]
Larry has joined #tagmem
18:00:51 [Zakim]
18:01:02 [Zakim]
18:01:53 [ht]
ht has joined #tagmem
18:02:25 [Larry]
18:02:45 [Zakim]
18:02:47 [Zakim]
18:02:51 [johnk]
hmmm, I'm having trouble getting into the call...
18:02:54 [noah_lunch]
noah_lunch has joined #tagmem
18:03:06 [noah]
zakim, who is here?
18:03:06 [Zakim]
On the phone I see Masinter, jar_, plinss, noah, ht
18:03:07 [Zakim]
On IRC I see noah, ht, Larry, johnk, RRSAgent, Zakim, jar_, Norm, timbl, plinss, jar, trackbot, Yves
18:03:10 [Zakim]
18:03:22 [Zakim]
+ +1.413.458.aaaa
18:04:35 [ht]
meeting: TAG telcon
18:04:40 [ht]
chair: Noah Mendelsohn
18:04:46 [ht]
scribe: Henry S. Thompson
18:04:51 [ht]
scribenick: ht
18:06:08 [Larry]
zakim, who is here?
18:06:08 [Zakim]
On the phone I see Masinter, jar_, plinss, noah, ht (muted), Yves, +1.413.458.aaaa
18:06:10 [Zakim]
On IRC I see noah, ht, Larry, johnk, RRSAgent, Zakim, jar_, Norm, timbl, plinss, jar, trackbot, Yves
18:06:15 [ht]
PL: Regrets for next week
18:06:21 [Zakim]
18:06:28 [johnk]
18:06:35 [Yves]
I read the first two days, and thought they were OK.
18:06:53 [Larry]
zakim, 413 is JohnK
18:06:53 [Zakim]
sorry, Larry, I do not recognize a party named '413'
18:07:07 [Larry]
zakim, aaaa is johnk
18:07:07 [Zakim]
+johnk; got it
18:07:30 [jar_]
have scanned the f2f minutes (for lines with my own initials and a bit more)
18:07:48 [Zakim]
18:08:22 [ht]
NM: f2f minutes read by anyone?
18:08:32 [ht]
JR: Scanned, but not read in detail
18:08:59 [johnk]
FWIW, I read the first day and thought it was OK
18:09:07 [DKA]
DKA has joined #tagmem
18:09:11 [ht]
YL: Read first two days carefully, since I wasn't there, they were fine
18:09:19 [Larry]
+1 approve minutes
18:09:25 [ht]
NM: RESOLVED: Approve the 8--10 Feb f2f minutes
18:09:33 [noah]
PROPOSE: Approve minutes of 8-10 Feb 2011
18:09:44 [noah]
RESOLUTIO: Minutes of 8-10 Feb 2011 are approved
18:09:50 [noah]
RESOLUTION: Minutes of 8-10 Feb 2011 are approved
18:10:17 [ht]
NM: Some concerns about the initial draft, please try harder
18:10:32 [ht]
NM: Minutes of 24 Feb?
18:10:39 [noah]
RESOLUTION: Minutes of 24 Feb 2011 are approved
18:10:43 [ht]
PL: I reviewed a bit
18:10:44 [Zakim]
18:11:00 [Zakim]
18:11:04 [Zakim]
18:11:25 [ht]
scribenick: DKA
18:11:43 [DKA]
NM: John is coming back for this call for his work item.
18:11:51 [DKA]
NM: Put one thing ahead - IAB panel.
18:12:14 [DKA]
NM: Also - at f2f Dan suggested we talk about offline web application packaging.
18:12:23 [DKA]
NM: Also we should discuss 303 redirections.
18:12:31 [DKA]
Topic: IAB Panel
18:13:02 [DKA]
NM: anything you'd like to spend time on, Henry?
18:13:10 [DKA]
HT: Not at this time.
18:13:20 [DKA]
NM: Anyone else?
18:13:53 [DKA]
LM: Relationship between scalability and registries - I had some thoughts.
18:14:16 [DKA]
LM: We had this issue and discussion on role of registries and IANA.
18:14:22 [DKA]
LM: We had a discussion on MIME types.
18:14:49 [DKA]
LM: Architectural issue is preference in webarch for using URIs rather than registered values (DTD style).
18:15:27 [noah]
Good point, Larry
18:16:12 [ht]
ht has joined #tagmem
18:16:22 [jar_]
jar +1 larry saying: Scalability of URI access relates to the registry question.
18:16:44 [Larry]
I was trying to talk about a somewhat vague thought connecting work on registries to work on scalability
18:17:05 [noah]
What I heard was: if you're going to encourage people to use URIs for things that otherwise would have been in registries, you tempt them to make accesses to those URIs, and we've seen that as a source of scalability problems.
18:17:10 [Larry]
if the web architecture prefers using URI-assignment rather than registry allocation by IANA....
18:17:33 [jar_]
E.g. putting the registries and schemas in URI space under urn: instead of http: might somehow help with scalability question. Yes?
18:17:36 [noah]
q+ to say it's only one bit of the scalability problem.
18:17:51 [DKA]
LM: In so far as this talk at IETF is to start some discussions on web architecture and internet architecture: we can have topics we want to talk about even if we don't have answers.
18:17:55 [noah]
ack next
18:17:56 [Zakim]
noah, you wanted to say it's only one bit of the scalability problem.
18:17:56 [jar_]
18:18:24 [ht]
q+ to add that if I put in a slide on this, I should add two lines about the registry<->URI connection in e.g. XPointer scheme names
18:18:27 [Larry]
well, if the URI used was "data:", there wouldn't have been a scalability issue
18:18:32 [DKA]
NM: I see the scalability problem as a fundamental issue for the web. This type of problem is one concern but not the only one that might arise.
18:19:29 [Larry]
early discussions were about unexpected flash crowds, where some TV commentator says "look up this cool picture at NASA" and suddenly NASA's web space is cut down
18:19:33 [DKA]
NM: For example, the home page for nytimes and cnn - these people aren't surprised about heavy access, but you could imaging lots of different resources that might have the same scalability issues.
18:20:05 [Larry]
18:20:14 [DKA]
NM: ... when you use URIs, there are scalability issues because people do [dereference] them inappropriately.
18:20:39 [DKA]
LM: I am also worried about content-centric networking... would like to understand this better.
18:20:52 [Yves]
scalability issue depends also on cache infrastructures in the network
18:21:11 [DKA]
MN: [it might be premature to discuss it at the IETF meeting]
18:21:26 [noah]
18:21:39 [noah]
ack next
18:21:41 [Zakim]
ht, you wanted to add that if I put in a slide on this, I should add two lines about the registry<->URI connection in e.g. XPointer scheme names
18:22:17 [DKA]
HT: I think it's important to realise that there are a number of cases in which the boundaries between registries and URIs have been blurred.
18:23:46 [DKA]
...It's worth mentioning : we do have a very intentional hybrid system - the xpointer registry - a database backed registry which results in a URI being served for everything in the registry.
18:23:57 [DKA]
LM: Can you give an overview for the panel?
18:24:00 [DKA]
HT: Yes I think so.
18:24:21 [DKA]
NM: Moving on to John's topic.
18:24:40 [DKA]
18:24:40 [trackbot]
ACTION-355 -- John Kemp to explore the degree to which AWWW and associated findings tell the interaction story for Web Applications -- due 2011-02-02 -- PENDINGREVIEW
18:24:40 [trackbot]
18:24:58 [DKA]
Topic: interaction story for web applications
18:25:31 [DKA]
NM: To frame: identification (URIs), interaction (protocols), ...
18:26:10 [DKA]
NM: when we started to look at extending work on web arch to application (as opposed to docuemnts) and we started to see interactions which are not simple request-response, John undertook this issue to frame the interaction issues for webapps.
18:26:23 [noah]
18:26:23 [trackbot]
ACTION-355 -- John Kemp to explore the degree to which AWWW and associated findings tell the interaction story for Web Applications -- due 2011-02-02 -- PENDINGREVIEW
18:26:23 [trackbot]
18:26:31 [johnk]
18:26:33 [DKA]
JK: I did an investigation of awww. What I found I sent in an email to the TAG list.
18:26:46 [noah]
18:26:50 [DKA]
... the way the interaction model is currently described is over http.
18:26:55 [noah]
Links to document:
18:27:12 [DKA]
... some of the things I mentioned were client-side manipulation and generation of URIs...
18:28:13 [DKA]
... what is the relationship between a server-side application and the client-side javascript that's running and what enables the client-side script to know it can construct a URI reliably?
18:28:13 [DKA]
... comet, websocket, ajax-based polling: information rendered to the user is different than what was downloaded initially.
18:29:03 [DKA]
... In the old model, you had to be running a server to expose a resource on the web; now you have clients that are servers, also exposing client resources (e.g. gps) exposed as web resources to another entity.
18:29:25 [DKA]
... multi-party security is an issue - multiple pieces of content are mashed up to create a running application.
18:29:38 [DKA]
... More recently I wrote some examples.
18:30:09 [DKA]
... one is the use of websockets; another is the use of geo api to expose the client's location to the document they've downloaded; another is client-side URI generation.
18:30:20 [noah]
I think when we expose something like an accelerometer using Javascript APIs as opposed to URIs, then it's best not to call that a "Web resource". What we have are resources that are linkable through the mechanisms of the Web, others (like the acceleromotere) available only at the client, and others that are networked with non-Web protocols.
18:30:33 [DKA]
... I think it would be useful to use these examples as a framework to talk about [webapps architecture]
18:31:08 [DKA]
... All of these things are dependent on an eventing based model associated with javascript and a document object model that runs on the client - different from http - so different from what is document in awww.
18:31:19 [DKA]
NM: Open floor for discussion.
18:31:56 [DKA]
NM: How deep and how broad is our investigation of webapps going to be?
18:32:05 [DKA]
... is this close to a TAG finding?
18:32:14 [DKA]
... doesn't really draw conclusions yet.
18:32:23 [DKA]
... do we want to carry forward with work based on this?
18:32:50 [DKA]
... to elaborate some principles / best practices - terminology for the abstractions and good practices.
18:33:51 [DKA]
+1 to us building on John's work.
18:34:02 [DKA]
LM: WebApps are [where it's at]
18:34:04 [jar_]
mnot: "Open Source is taking the place of Open Standards"
18:34:44 [DKA]
NM: Do we have one or two individuals who can work aggressively on this - 5 to 10 hours a week to write and gain consensus - on this topic?
18:35:46 [DKA]
LM: We have a motivation to work on this in terms of starting some conversations ... at the IETF panel ... IETF has raised some issues on webapps ...
18:36:12 [jar_]
noah would prefer to talk about who is doing the work, rather than the work.
18:36:21 [DKA]
NM: We set ourselves a goal of writing a new section of webarch - new story about interaction. If we're going to write something we need to write it.
18:36:44 [DKA]
18:37:04 [noah]
ack next
18:38:39 [DKA]
DKA: I think we need to engage with a webapps community of practice to work on this - worried about being able to do this.
18:39:34 [DKA]
NM: we should be challenging that community by asking some questions [ / making some assertions].
18:39:53 [DKA]
... Webarch has good stuff like cool URIs don't change, etc.. provides real advice.
18:40:21 [DKA]
... we should get to that point. Where we can say : here's good practice and here's bad - and here's useful terminology...
18:40:43 [DKA]
... We should say something specific.
18:41:29 [DKA]
LM: In the general problem - where we have something to say that's important but we don't have the resources - could we e.g. ask the webapps working group what should happen to awww to make it more relevant to them?
18:41:39 [DKA]
NM: Goal here is to update the TAG document.
18:42:30 [DKA]
NM: I'm frustrated we can't find the time to do this.
18:43:05 [DKA]
18:43:53 [DKA]
LM: What if we publish this as a blog post, ask for suggestions from the community?
18:44:24 [johnk]
I would not want to publish what I've already done as a blog post
18:44:33 [DKA]
NM: Chapters suggest terminology, they have principles, good practices notes...
18:45:11 [noah]
18:45:11 [DKA]
18:45:17 [noah]
ack next
18:46:03 [jar_]
What problem does web architecture solve? ... the answer would tell us what to do in the apps space.
18:47:16 [Larry]
maybe we will get some feedback from IETF meeting on what we need to do?
18:47:39 [DKA]
DKA: I am happy to reach out the webapps chairs... am worried about the impactfulness of this proposed document to the community we are trying to influence.
18:47:53 [DKA]
NM: We committed to do some work in this space...
18:48:12 [DKA]
... I think you [Dan] are saying the deliverable might be premature.
18:48:35 [DKA]
... then I think we should stop telling the community we're going to do comprehensive work on webapps.
18:49:24 [jar_]
Every journey begins with a single step.
18:49:29 [DKA]
... I am willing to back off on the notion that one of our big deliverables is a comprehensive webapps architecture.
18:49:29 [noah]
18:50:12 [DKA]
JAR: I think the goal has been a good one -- in that we have looked at topics [in this space].
18:50:47 [DKA]
NM: if what we're doing is chaining from "major document" to "umbrella theme which is influencing a number of point pieces of work" then we should [be clear on that
18:50:50 [DKA]
18:51:20 [jar_]
Has to do with the TAG status report, setting W3C mgmt expectations.
18:51:37 [noah]
18:52:31 [DKA]
JAR: There's no crisis here -
18:52:45 [DKA]
... the people who did it felt like there was a real reason to do it.
18:53:05 [DKA]
... one thing we need here - we should try to figure out what are the dangers - what are the bad things that might go wrong if we don't publish this.
18:53:22 [jar_]
s/did it/did AWWW/
18:54:08 [DKA]
NM: My perception on webarch - the TAG has principles in its charter; one of these is to document principles of web architecture. Web apps architecture f[follows on from this]. When you read webarch and then look at [web apps] [they don't fit together.]
18:54:25 [DKA]
NM: We should document the web architecture as used today.
18:55:03 [DKA]
JAR: I think it's not just a matter of responsibility and charter - bad things can actually happen and we care about them.
18:55:04 [noah]
18:55:43 [DKA]
HT: I don't want to lose this task. If I have time between now and the end of my time on the TAG this will be the next thing up because I think it's hugely important.
18:56:09 [DKA]
[discussion on priorities]
18:57:16 [DKA]
NM: Propose we close ACTION-355 with thanks to John - then see what else we can propose in the short term.
18:57:32 [ht]
ACTION: Noah to work with HST to identify a way forward wrt interaction
18:57:32 [trackbot]
Created ACTION-536 - Work with HST to identify a way forward wrt interaction [on Noah Mendelsohn - due 2011-03-10].
18:57:39 [noah]
18:57:39 [trackbot]
ACTION-355 -- John Kemp to explore the degree to which AWWW and associated findings tell the interaction story for Web Applications -- due 2011-02-02 -- PENDINGREVIEW
18:57:39 [trackbot]
18:57:52 [DKA]
close ACTION-355
18:57:52 [trackbot]
ACTION-355 Explore the degree to which AWWW and associated findings tell the interaction story for Web Applications closed
18:57:53 [ht]
action-536 due 2011-08-01
18:57:53 [trackbot]
ACTION-536 Work with HST to identify a way forward wrt interaction due date now 2011-08-01
18:58:11 [DKA]
NM: Now - proposals on short-term work?
18:58:58 [DKA]
JK: Larry mentioned mark N's comments - related to this issue.
18:59:05 [DKA]
... we could link these together....
18:59:07 [noah]
ACTION Dan to reach out to Web apps chair to solicit help on framing architecture (incluing terminology, good practice) relating to interaction
18:59:07 [trackbot]
Created ACTION-537 - Reach out to Web apps chair to solicit help on framing architecture (incluing terminology, good practice) relating to interaction [on Daniel Appelquist - due 2011-03-10].
19:00:08 [Larry]
hmmm, s/web apps chair/web apps working group/
19:01:36 [jar_]
larry email was sent feb 18...
19:01:40 [DKA]
NM: Anything else under this interaction topic? If not, let's move on...
19:02:04 [Yves]
19:02:08 [DKA]
NM: Please put links to this in ACTION-355 and ACTION-356.
19:02:13 [johnk]
19:02:58 [ht]
+1 to JR's proposal to regroup under a renamed ACTION-534
19:03:11 [DKA]
Topic: 303 related issues.
19:03:26 [ht]
19:03:39 [jar_]
I proposed
19:03:52 [ht]
+1 to JR's proposed new name for ISSUE-57 -- close enough for government work
19:04:02 [Zakim]
19:04:23 [DKA]
JAR: I did a survey of URI meaning issues... Rather than opening a new issue it might be better to use ISSUE-57.
19:04:38 [DKA]
... if we just fix the title and amend it then it will serve perfectly well.
19:04:43 [DKA]
... I found one caution from Tim.
19:04:50 [jar_]
@f2f timbl: Let's not re-define issues under the same number, that's fraud :-)
19:05:12 [DKA]
... but this isn't a redefinition - just a re-titling.
19:05:28 [DKA]
NM: Do you want to make a case for the scope / new title.
19:06:11 [DKA]
JAR: The issue was opened up because of an email to the TAG regarding 303's - that they weren't working and urging the TAG to look at other ways to do the same thing.
19:06:18 [noah]
19:07:27 [noah]
19:07:44 [noah]
19:08:01 [noah]
19:08:28 [johnk]
johnk has joined #tagmem
19:08:58 [DKA]
[some discussion on history of the issue]
19:09:37 [noah]
At their meeting in 16th July 2007 [1] the TAG resolved to create a new issue, HttpRedirections-57 as a response to a community request
19:09:47 [noah]
19:10:46 [noah]
19:11:03 [jar_]
19:11:21 [jar_]
that's giovanni's email which i consider the heart of issue-57
19:11:29 [Larry]
I don't understand what we're talking about and why we're taking meeting time to talk about it
19:12:01 [Larry]
maybe JAR and Noah can take this offline and come back with one or two proposals for what to do?
19:12:17 [DKA]
JAR: the way I think of this - issue-14 was closed with a decision about how 200s are used - our alternative for those troubled by this is 303.
19:12:21 [DKA]
... years passed by ...
19:12:33 [DKA]
... then people started saying the solution (using 303) doesn't work.
19:12:48 [DKA]
... that's a problem that never got fixed - that I'm trying to fix this year.
19:12:55 [DKA]
... hence issue-57.
19:13:03 [noah]
From issue-57 description:
19:13:04 [noah]
At the TAG F2F of 4 March 2009 (, the TAG agreed to "split Issue-57 into two issues as edited by NM, with one abstention DanC". Issue 62 was opened immediately. Later issue 63 was opened.
19:13:32 [Larry]
If people who are trying to deploy something don't like the implementation consequences of a TAG finding.... it just shows to me the risk of the TAG coming out with "findings" that propose technology solutions, without the 'direct' participation of the implementation community
19:13:39 [DKA]
[discussion on whether or not issue-57 was superseded]
19:13:46 [Larry]
and this should be a topic of a working group, not the TAG
19:15:29 [Larry]
I have no problem with JAR changing issues to match his understanding of the issue
19:15:44 [Larry]
19:15:58 [noah]
ack next
19:17:15 [jar_]
larry: The TAG made a recommendation (little R) for 303, and it didn't get review.
19:17:46 [noah]
I didn't get formal AC review, but it got a ton of community review (if not complete consensus)
19:18:02 [jar_]
larry: People said, we tried it and it didn't work for us... therefore need a WG
19:18:36 [DKA]
LM: What should happen now is to tell people who are trying to engineer solutions : you should form a working group. Because we suggested a direction, but if it's not working then I don't think the response should be we should go back and review them. The response should be : Ok - the thing we recommended has performance requirements, go and form a working group to come up with something different.
19:19:38 [DKA]
NM: It could also be one of the existing semantic web working groups...
19:20:01 [DKA]
... the community has chosen not to invest before...
19:20:14 [DKA]
JAR: Tim has said this is a TAG issue, not specific to RDF.
19:20:46 [DKA]
NM: Jonathan has made a concrete proposal - an update for issue-57 and an agreement to use that issue to track our upcoming work on this (which may not be very much).
19:21:16 [DKA]
... going back to Jonathan's specific proposal, I am willing to say "OK."
19:21:22 [DKA]
+1 sounds OK to me.
19:21:44 [noah]
19:21:48 [Larry]
whether it's forming another working group or assigning it to an existing one?
19:22:03 [jar_]
. change per proposal given here
19:22:05 [Larry]
note that "Community Groups" in W3C are intended to lower the overhead of forming a working group
19:22:12 [Larry]
q+ to note community groups
19:22:15 [jar_]
thanks larry.
19:22:16 [noah]
1) Chamge issue-57 title to: At the TAG F2F of 4 March 2009 (, the TAG agreed to "split Issue-57 into two issues as edited by NM, with one abstention DanC". Issue 62 was opened immediately. Later issue 63 was opened.
19:22:30 [noah]
2) Add a paragraph to the description per Jonathan's email:
19:22:37 [noah]
"On its 2011-dd-dd telcon [6] the TAG noted that members of
19:22:37 [noah]
the community (e.g. in [7]) report that the performance
19:22:37 [noah]
characteristics and deployment complexity of using 303
19:22:37 [noah]
redirects leave them feeling that they have little option but
19:22:37 [noah]
to use 200 responses for this purpose, at variance with the
19:22:38 [noah]
TAG's httpRange-14 resolution [8]."
19:23:05 [noah]
19:23:30 [noah]
1) Chamge issue-57 title to: "Mechanisms for obtaining information about the intended
19:23:30 [noah]
meaning of a given URI"
19:24:23 [noah]
Noodling on this:
19:24:28 [DKA]
NM: any others worried about use of word "meaning"?
19:24:39 [noah]
1) Chamge issue-57 title to: "Mechanisms for obtaining information about the referent of a URI"
19:24:59 [DKA]
LM: You can't ever determine the intended meaning - my worry is the word "intended."
19:25:16 [DKA]
LM: A design goal of URIs is to have uniformity of meaning.
19:25:29 [Yves]
I am for 'intended meaning', to avoid 'intended semantic'
19:25:49 [DKA]
[debate on the meaning of meaning]
19:25:59 [Larry]
i don't like "intended" is that it begs the question of who itnends it
19:26:08 [Larry]
19:26:39 [Larry]
depends on what the meaning of 'is' is
19:27:09 [Yves]
who intends it... whoever minted the URI
19:27:26 [Larry]
19:27:26 [trackbot]
ISSUE-57 -- The use of HTTP Redirection -- open
19:27:26 [trackbot]
19:27:40 [Larry]
19:27:43 [noah]
19:27:46 [Larry]
19:27:47 [DKA]
NM: who prefers meaning and who prefers referent
19:27:49 [Yves]
19:27:51 [DKA]
19:27:52 [jar_]
+1 meaning but not important enought to quibble about
19:28:06 [Larry]
actually, tdb:2006:
19:28:17 [jar_]
19:28:41 [noah]
RESOLUTION: to change tile of issue-57 to Mechanisms for obtaining information about the intended
19:28:41 [noah]
meaning of a given URI
19:29:05 [noah]
meaning of a given URI and add para of description per jonathans email
19:30:04 [noah]
RESOLUTION: Change title of ISSUE-57 to "Mechanisms for obtaining information about the meaning of a given URI" and add paragrph of description per Jonathan's email
19:30:46 [DKA]
NM: OK - thanks for your patience with this. Our next call next week. Let's adjourn for now.
19:30:49 [Zakim]
19:30:51 [Zakim]
19:30:53 [Zakim]
19:30:53 [Zakim]
19:30:55 [Zakim]
19:30:59 [Zakim]
19:31:02 [Zakim]
19:31:03 [Zakim]
TAG_Weekly()1:00PM has ended
19:31:06 [Zakim]
Attendees were Masinter, jar_, plinss, noah, ht, Yves, +1.413.458.aaaa, DKA, johnk
19:31:19 [noah]
Jonathan: please leave some tracks in the issue description to point out when/why it was changed.
19:31:22 [DKA]
rrsagent, make minutes
19:31:22 [RRSAgent]
I have made the request to generate DKA
19:31:35 [DKA]
rrsagent, make logs public
20:25:59 [Norm]
Norm has joined #tagmem
21:03:51 [jar_]
jar_ has joined #tagmem
21:34:38 [ht]
ht has left #tagmem
21:43:03 [Zakim]
Zakim has left #tagmem
22:08:08 [jar_]
rrsagent, pointer
22:08:08 [RRSAgent]
22:38:00 [DKA]
DKA has joined #tagmem
23:12:00 [Norm]
Norm has joined #tagmem
23:13:09 [jar_]
jar_ has joined #tagmem
23:26:26 [Norm]
Norm has joined #tagmem