IRC log of tagmem on 2013-12-19
Timestamps are in UTC.
- 17:53:03 [RRSAgent]
- RRSAgent has joined #tagmem
- 17:53:03 [RRSAgent]
- logging to http://www.w3.org/2013/12/19-tagmem-irc
- 17:53:08 [Zakim]
- TAG_Weekly()1:00PM has now started
- 17:53:14 [Zakim]
- +Bryan_Sullivan
- 17:53:53 [bryan]
- bryan has joined #tagmem
- 17:54:19 [dka]
- dka has joined #tagmem
- 17:54:59 [dka]
- trackbot, this will be tag
- 17:54:59 [trackbot]
- Sorry, dka, I don't understand 'trackbot, this will be tag'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
- 17:55:08 [dka]
- trackbot, start meeting
- 17:55:10 [trackbot]
- RRSAgent, make logs public
- 17:55:12 [trackbot]
- Zakim, this will be TAG
- 17:55:12 [Zakim]
- ok, trackbot, I see TAG_Weekly()1:00PM already started
- 17:55:13 [trackbot]
- Meeting: Technical Architecture Group Teleconference
- 17:55:13 [trackbot]
- Date: 19 December 2013
- 17:55:42 [Zakim]
- +plinss
- 17:55:50 [dka]
- regrets+: Henry Thompson
- 17:56:38 [Zakim]
- +dka
- 17:57:24 [twirl]
- twirl has joined #tagmem
- 18:00:08 [efullea]
- efullea has joined #tagmem
- 18:00:09 [dka]
- zakim, who is here?
- 18:00:09 [Zakim]
- On the phone I see Bryan_Sullivan, plinss, dka
- 18:00:11 [Zakim]
- On IRC I see efullea, twirl, dka, bryan, RRSAgent, Zakim, timbl, marcosc, wycats_, slightlyoff, Yves, trackbot, plinss
- 18:00:46 [Zakim]
- +??P9
- 18:00:49 [JeniT]
- JeniT has joined #tagmem
- 18:01:08 [Zakim]
- +Yves
- 18:01:28 [ArtB]
- ArtB has joined #tagmem
- 18:01:34 [Zakim]
- +[IPcaller]
- 18:01:41 [Zakim]
- + +34.91.432.aaaa
- 18:01:44 [ArtB]
- zakim, what's the code?
- 18:01:44 [Zakim]
- the conference code is 0824 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), ArtB
- 18:01:54 [ArtB]
- zakim, call art_barstow
- 18:01:54 [Zakim]
- I am sorry, ArtB; I do not know a number for art_barstow
- 18:02:23 [plinss]
- zakim, aaaa is efullea
- 18:02:23 [Zakim]
- +efullea; got it
- 18:02:25 [Zakim]
- +Art_Barstow
- 18:03:15 [chaals]
- chaals has joined #tagmem
- 18:03:33 [dka]
- Chair: Peter
- 18:03:49 [chaals]
- zakim, code?
- 18:03:49 [Zakim]
- the conference code is 0824 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), chaals
- 18:04:13 [Zakim]
- +[IPcaller]
- 18:04:18 [chaals]
- zakim, [ip is me
- 18:04:18 [Zakim]
- +chaals; got it
- 18:04:21 [dka]
- Scribe: Dan
- 18:04:26 [dka]
- ScribeNick: dka
- 18:04:33 [Zakim]
- +TimBL
- 18:05:25 [bryan]
- eduardo, are you OK with me forwarding your comments to the Push API draft comments to the www-tag list along with the rest of my responses?
- 18:05:35 [efullea]
- yes
- 18:05:37 [slightlyoff]
- heya
- 18:05:40 [slightlyoff]
- on the way
- 18:05:43 [slightlyoff]
- apologies for being late
- 18:05:57 [chaals]
- zakim, agenda?
- 18:05:57 [Zakim]
- I see nothing on the agenda
- 18:06:06 [dka]
- Peter: Starting the discussion on Push. Welcome to our invited guests.
- 18:06:09 [chaals]
- rrsagent, draft minutes
- 18:06:09 [RRSAgent]
- I have made the request to generate http://www.w3.org/2013/12/19-tagmem-minutes.html chaals
- 18:06:35 [dka]
- Bryan: I am going to send a note to the www-tag list with my comments on the draft comments prepared already.
- 18:06:52 [ArtB]
- -> http://lists.w3.org/Archives/Public/www-tag/2013Dec/0028.html Draft for note to send to Push API editors/authors
- 18:07:05 [dka]
- Topic: Push
- 18:07:14 [dka]
- Bryan: Shall I give my responses to the TAG feedback?
- 18:07:18 [dka]
- Peter: yes
- 18:07:43 [Zakim]
- +??P19
- 18:07:46 [twirl]
- https://github.com/w3ctag/spec-reviews/blob/c218958ce2c9b655282bd1ebdbe93e8902b423e1/2013/08/Push%20API.md
- 18:07:58 [slightlyoff]
- Zakim: ??P19 is me
- 18:08:02 [dka]
- Bryan: the first issue was that the concepts are unclear - things such as : why is a push service needed? in general the need is understood by app developers in the market.
- 18:08:30 [dka]
- Bryan: we didn't feel it was necessary to explain all that. We did have some use cases that we brought to the webapps discussion - I put a reference to those use cases.
- 18:08:36 [chaals]
- rrsagent, make log public
- 18:08:44 [dka]
- +1 to the importance of having push functionality in the Web platform, by the way.
- 18:09:25 [dka]
- Alex: It's not necessarily unclear but it seems there has been some debate about e.g. the wired protocol...
- 18:09:38 [ArtB]
- https://dvcs.w3.org/hg/push/raw-file/default/index.html -> Push API (Editor's Draft)
- 18:09:44 [dka]
- Bryan: I provided a link to the use case we used in the webapps rechartering.
- 18:09:48 [chaals]
- [+1 to linking to explicit use cases]
- 18:10:18 [dka]
- Bryan: 2nd thing - what is "how should the app server deal with" mean?
- 18:10:19 [slightlyoff]
- go ahead marcosc
- 18:10:28 [slightlyoff]
- there's a second issue that I'll bring up in a second
- 18:10:49 [dka]
- Sergey: the over the air protocol. How should a web page know how to negotiate with a push server?
- 18:11:41 [dka]
- Bryan: There are a variety of ways to interact with push systems e.g. the urban airship protocol. Currently the wire protocol has not been in scope for this API.
- 18:12:17 [dka]
- Alex: I guess I can buy that but I am curious to know how the message delivery is meant to work regarding the execution context.
- 18:12:42 [dka]
- Alex: let's say I've got a way of targeting some application on the device and the system delivering the message thinks it knows how to do it, what is the exec context meant to be?
- 18:12:52 [dka]
- Alex: what about when the document isn't open, for example?
- 18:13:37 [dka]
- Bryan: in that case a webapp will make a registration. based on the reg object created, the user agent will deliver the notification to a particular javascript function. Presumably the code that will execute is still in the dom.
- 18:13:42 [dka]
- Alex: how does that happen?
- 18:14:04 [dka]
- Bryan: that's an implementation decision. In prototype implementations we'll figure out how that works.
- 18:14:16 [dka]
- Bryan: could work with service worker.
- 18:14:47 [dka]
- Alex: Service worker is like web worker. It can live disconnected from documents. It's usually invoked by innovation to a url [pattern].
- 18:15:07 [dka]
- Alex: anything within that pattern can invoke that service worker.
- 18:15:11 [dka]
- Alex: it's not persistent.
- 18:15:30 [dka]
- Alex: you could deliver [push] messages to a registered service worker.
- 18:16:12 [Zakim]
- -twirl
- 18:16:19 [dka]
- Eduardo: the current draft is based on system messages defined by sysapps working group.
- 18:16:27 [dka]
- Eduardo: but that this work has been discontinued.
- 18:16:29 [Zakim]
- +??P9
- 18:16:44 [dka]
- Alex: we should make sure that we have a solution for this to meet the criteria for a good api.
- 18:16:46 [dka]
- Bryan: I agree.
- 18:17:07 [dka]
- Bryan: Next question - what info is passing through the push service and how is the UA authenticated?
- 18:17:24 [dka]
- Bryan: the current version is now just a trigger.
- 18:17:39 [dka]
- Bryan: anything delivered between the push server to the user agent is not described in the spec?
- 18:17:44 [dka]
- Sergey: then what spec?
- 18:18:06 [slightlyoff]
- bryan: I can agree with that as a decent place to be with this. Not sure you need to spec out all of the device APIs there.
- 18:18:28 [dka]
- Bryan: there are a variety of specifications. We reference a couple of them. But it's up to the implementation of the device and the user agent. This is only an API providing access to a service. Doesn't depend on a particular service design.
- 18:19:00 [slightlyoff]
- twirl: it's pretty clear they aren't defining any of that?
- 18:19:02 [dka]
- Sergey: do we allow a user to change a push server? Is it possible? Does it work like Jabber? If we design it that way then we must define the protocol.
- 18:19:15 [dka]
- Bryan: it's possible to switch bearers.
- 18:19:34 [dka]
- ... but we don't get into those details.
- 18:20:15 [dka]
- Alex: Maybe something that prevent this question from coming up would be informative text giving an example configuration between a device and a network.
- 18:20:35 [dka]
- Bryan: as long as we can do that without being slanted towards an implementaiton.
- 18:21:02 [dka]
- Alex: I'm not worried about non-normative / normative but we should have text saying "for example... it could work like this:..."
- 18:21:16 [dka]
- ... there is nothing in your API now that would suggest one implementation over another.
- 18:21:46 [dka]
- Sergey: It's hard to imagine how to write a web app to work with push API. I understand all the answers can't be in the spec but ...
- 18:21:58 [dka]
- Alex: [we don't need the whole stack]
- 18:22:31 [dka]
- Bryan: I could describe a sample implementation.
- 18:22:55 [dka]
- Eduardo: Firefox OS is implementing this Api so this is a reference implementation.
- 18:23:00 [slightlyoff]
- exciting!
- 18:23:05 [ArtB]
- Is there any other impl in progress?
- 18:23:13 [dka]
- Bryan: hopefully the geeks phone device I just got supports it so I can test it.
- 18:23:35 [slightlyoff]
- how persistent?
- 18:23:46 [dka]
- Bryan: registrations are unique to each webapp instance.
- 18:23:54 [slightlyoff]
- and what's a webapp instance? a tab? a document?
- 18:24:02 [dka]
- Bryan: it's the user agent's responsibility to store them as registration objects and we don't specify how.
- 18:24:10 [slightlyoff]
- got it
- 18:24:13 [dka]
- Bryan: it could be that service worker gives us something there.
- 18:24:51 [dka]
- Bryan: next - what is a webapp in the sense of the spec? It's a URL with a domain, a document obtained from that with a DOM object and after that a unique object in the user agent. It's the same as any other case.
- 18:25:12 [dka]
- Alex: You're creating leeway for user agent to create these documents which may match the registration.
- 18:25:53 [dka]
- Alex: let's say I go example.com/app and I open up in 2 tabs - then I open up a sub-document, now 3 tabs - two of them looking at the same document... what happens?
- 18:26:28 [dka]
- Bryan: we have all the tools for that... they have the ability to delegate the first one in as the entry point to push using shared messaging...
- 18:26:46 [dka]
- Bryan: you don't have to share. you don't have to broadcast. If each one wants to create its own push registration it can.
- 18:27:04 [dka]
- Bryan: the registration is bound to a particular webapp instance.
- 18:27:10 [dka]
- Sergey: a particular URL or not?
- 18:27:33 [dka]
- Bryan: invoked through a URL but then becomes a structure within the DOM - this is what the registration is against.
- 18:28:08 [dka]
- Alex: If we come up with a design with service worker we can explain what that means in terms of [service worker].
- 18:28:19 [dka]
- Alex: let's continue to talk about it and iterate on it.
- 18:28:24 [dka]
- Bryan: sounds good.
- 18:28:37 [dka]
- Bryan: an example of a multiple app design might be useful as well.
- 18:28:58 [dka]
- Bryan: how should the user agent invoke an active webapp? could be with service worker...
- 18:29:15 [dka]
- Sergey: invoking an app doesn't mean that browser opens new tab - so how should it be invoked?
- 18:29:41 [dka]
- Alex: thats' kind of what we're talking about - how will delivery happen when the user doesn't have a document...?
- 18:29:52 [dka]
- Alex: you're tied to documents in a way that is unfriendly.
- 18:30:02 [dka]
- Alex: if we figure that out we can get a solution here.
- 18:30:28 [dka]
- Bryan: question we need to get to - how is a webapp constructed and how is it reconstructed when it needs to be reinvoked?
- 18:30:49 [dka]
- Alex: I want to express my enthusiasm for getting this capability into the platform.
- 18:31:29 [dka]
- Bryan: How to invoke a webapp that's using history API -
- 18:31:53 [dka]
- Bryan: does the history manipulation have the ability to change a registration? I don't think it does.
- 18:31:56 [Zakim]
- -twirl
- 18:32:08 [Zakim]
- +??P9
- 18:32:09 [dka]
- Bryan: "express permission" needs to be clarified.
- 18:32:15 [Zakim]
- -JeniT
- 18:32:29 [JeniT]
- JeniT has left #tagmem
- 18:32:43 [dka]
- Bryan: we are channeling this discussion we've had over a long time - how do you describe the need to get user opt-in for an app having access to an API that might be privacy or security sensititive.
- 18:33:00 [dka]
- ... we're just saying the user must be engaged in the decision to authorize access.
- 18:34:13 [dka]
- Bryan: "no modification error" needs clarification. I think the spec clarifies that.
- 18:34:44 [dka]
- Bryan: if the request doesn't relate to an active push registration then this error is thrown.
- 18:35:00 [dka]
- Sergey: the unregister might be rejected [?]
- 18:35:35 [dka]
- Bryan: if there is a sync error then the webapp knows - can invoke through its app ID -
- 18:36:01 [dka]
- Sergey: the name is wrong - that is some unknown error. At the moment it seems the user could disallow apps to register...
- 18:36:23 [dka]
- Eduardo: maybe there is a better suggestion we can change it....
- 18:36:35 [dka]
- Bryan: we need to explain further the role of this ...
- 18:36:48 [dka]
- Bryan: any suggestions for a different name for the error would be useful.
- 18:37:06 [dka]
- Bryan: a number of suggesttions for push manager...
- 18:37:31 [dka]
- Bryan: access granting and push manager register are bound together.
- 18:37:44 [dka]
- Bryan: can we ask permission in one interface and based on the result register in a different?
- 18:38:19 [dka]
- Eduardo: actually the way the implementation should work is - you don't need to ask for explicit permission every time - once the user has given access then you don't need to ask for permission.
- 18:38:39 [dka]
- Eduardo: as for whether to split it, it hasn't been considered. I need to understand the advantages / benefits.
- 18:39:05 [dka]
- Sergey: first of all I don't like way UA asks permission....
- 18:39:17 [dka]
- Alex: it seems it's the UA's job to mediate that permissions requests.
- 18:39:28 [slightlyoff]
- hey all, I really need to apologize...I need to get to another meeting
- 18:39:51 [dka]
- Sergey: it's logical - to ask permission once - that is concealed from the web developer. That leads to odd behavior when you need to ask permission again.
- 18:40:05 [dka]
- Alex: the required permission should be async. Could create permission or not...
- 18:40:21 [dka]
- Sergey: logic should be obvious but not concealed inside push manager registry.
- 18:40:34 [dka]
- Alex: API should request some permission and hand you back a promise.
- 18:40:55 [dka]
- Alex: Async nature of the operation gives the UA the option to prompt or not.
- 18:41:02 [Zakim]
- -Art_Barstow
- 18:41:18 [dka]
- Bryan: We differentiate permission from API access.
- 18:41:38 [Zakim]
- -??P19
- 18:42:10 [dka]
- Sergey: there is another issue with the errors.
- 18:42:16 [dka]
- Bryan: It's a good point and I noted that.
- 18:43:25 [dka]
- Bryan: webapps know which registrations belong to them.
- 18:43:42 [dka]
- Bryan: if you have multiple instances you can use a shared worker if you are concerned about too much asking permission.
- 18:44:14 [dka]
- Sergey: if we say that user agent would ask permission each time then it would be very strange behaviour.
- 18:44:27 [dka]
- Bryan: the intent is not to over-prompt the user for permission.
- 18:46:05 [dka]
- Eduardo: I think the different registrations can be differentiated with the push registration ID.
- 18:46:15 [dka]
- ... this is unique to the each registration.
- 18:46:36 [dka]
- ... notifications associated to each registration are differentiated by ID.
- 18:47:08 [dka]
- Bryan: then a number of suggestions for renaming. In general they are OK.
- 18:47:16 [dka]
- Eduardo: no it would't be a problem to change the naming.
- 18:47:36 [Zakim]
- -twirl
- 18:47:55 [Zakim]
- +??P9
- 18:48:07 [dka]
- Bryan: the question of routing of messages as an exercise for developers - and the binding of documents to URL space - I think this understood for things browsed.
- 18:48:56 [dka]
- ... in general a push system is different in that it's server-initiaitve. It's bound to the URL that the webapp was invoked from because that webapp creates the registration.
- 18:49:06 [dka]
- ... hopefully in my email response this is clarified.
- 18:49:39 [dka]
- ... I think it would be great to have concrete examples and I can provide those for the ones I'm familiar with.
- 18:50:33 [dka]
- Tim: it can't be used in any context
- 18:50:44 [dka]
- Bryan: it probably does;t have any meaning in any other context.
- 18:51:24 [dka]
- Bryan: it's a URL exposed by a push server. The registration ID is a string relating to the webapp instance that made the request. Those things don't have a meaning outside of a specific push service.
- 18:52:10 [dka]
- Bryan: we might have some new specs come out on these if we can people can bring that to the table.
- 18:52:26 [dka]
- Bryan: next question - related to the idea of a message queue.
- 18:52:48 [dka]
- ... why not use DOM event model?
- 18:53:14 [dka]
- Eduardo: this is based on the system messages design.
- 18:53:34 [dka]
- ... seems system messages are going to be discontinued. So we need to find an altertnative.
- 18:53:54 [dka]
- Bryan: I agree we should use tired and true eventing interfaces.
- 18:54:35 [dka]
- Bryan: final question - it's unclear from the code examples how this is meant to be invoked.
- 18:54:41 [dka]
- Bryan: it's largely left out of scope.
- 18:54:57 [dka]
- Bryan: the system being the push server and the user agent are assumed to know about eachother.
- 18:55:06 [dka]
- ... that might in the end rely on service workers.
- 18:55:20 [dka]
- ... but it's considered to be out of scope.
- 18:55:50 [dka]
- Peter: it's seems like the kind of things that service workers would help out with but to me it seems like relying on magic.
- 18:56:18 [dka]
- ... if you think about a push message delivered to the platform and the browser isn't running. what happens? Should that be part of the registration?
- 18:56:38 [Zakim]
- -dka
- 18:56:41 [dka]
- Bryan: that is one of the permutations we are going to haver to cover.
- 18:56:57 [Zakim]
- +dka
- 18:57:20 [dka]
- Peter: anything else?
- 18:57:47 [dka]
- Sergey: many things more clear than before. I will edit the review on github thought i still have questions and I need time to formulate.
- 18:58:18 [dka]
- I suggest we add this to our f2f agenda and maybe we can ask Eduardo and Bryan to call in?
- 18:59:01 [dka]
- Peter: thanks all for joining us.
- 18:59:10 [dka]
- ... we need to keep lines of communication open.
- 18:59:21 [dka]
- ... we have a f2f coming up in a couple weeks.
- 18:59:24 [dka]
- Jan 7-9
- 19:00:16 [dka]
- Eduardo: yes it's ok.
- 19:00:24 [dka]
- Bryan: i'l be at CES but I'll do my best.
- 19:00:37 [Zakim]
- -Bryan_Sullivan
- 19:00:38 [Zakim]
- -efullea
- 19:00:43 [dka]
- Peter: Tim did you want to bring up http 209?
- 19:00:46 [dka]
- Topic 209
- 19:01:01 [Zakim]
- -chaals
- 19:01:07 [dka]
- tim: something the tag talked about way back. Linked to http-range-14.
- 19:01:18 [dka]
- ... this shouldn't involve too much philosophy.
- 19:01:30 [Zakim]
- -twirl
- 19:01:43 [dka]
- ... there is return code used for LD 303 - you've asked for something I'm not going to give you but I'll give you info about it.
- 19:02:09 [dka]
- ... in LD it happens when X is some abstract thing and Y is a document about the thing.
- 19:02:37 [dka]
- ... the time it would be useful - you've asked for a database but I'm going to give you info for querying it.
- 19:03:20 [dka]
- ... LDP group is one that is doing read-write access to stores. They've got a paging system to ask for a piece of data and if it's too big then you get the first page.
- 19:04:09 [dka]
- ... another case: you asked for this but it's a very small thing. I'm giving you information about a bunch of other things as well.
- 19:04:14 [ht]
- ht has joined #tagmem
- 19:04:32 [dka]
- ... all this happens with a 303. 303s involve a http roundtrip. slows things down.
- 19:05:10 [dka]
- ... so the conclusion is - having another 20x code - a 209. this is equivalent of a 303 followed by a 200.
- 19:05:17 [dka]
- ... this will speed things up a lot.
- 19:05:58 [dka]
- ... reason I'm bringing to the TAG - the LDP working group needs this ... but could be useful to anyone using 303.
- 19:06:28 [dka]
- ... [hasn't happened becasuse] defining a new return code would be trouble... we'll have to make an RFC...
- 19:06:52 [dka]
- ... I feel it would be good for the web to have a new 20x code ...
- 19:07:50 [dka]
- ... [has been some disconnect between LD people / semantic web people / protocol people ]
- 19:08:15 [dka]
- ... so what should we do? One possibility is for LDP to ask Yves nicely to do this - as an RFC>
- 19:08:24 [dka]
- ... and get this adopted.
- 19:08:36 [dka]
- ... or maybe we should get write an extension spec.
- 19:08:56 [Yves]
- http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
- 19:08:57 [dka]
- ... one possiblity is to do ths...
- 19:09:16 [dka]
- Yves: first the http status code registry requires IETF consensus - so you need an rfc.
- 19:09:28 [dka]
- Tim: does it have a way of reserving a code?
- 19:09:31 [dka]
- Yves: no.
- 19:09:38 [dka]
- Yves. Non.
- 19:10:10 [dka]
- Yves: ...but chances are high that if you have a draft out there then it won't be taken.
- 19:10:38 [dka]
- Suggest now that we've laid out the problem we make this part of our discussion on data on the Web at the next TAG f2f....
- 19:11:04 [dka]
- Yves: the best is to have the group interested in working on that draft (as an RFC) what they want to have.
- 19:11:19 [dka]
- ... then get feedback from IETF community.
- 19:11:42 [dka]
- Peter: should we discuss during the data on the web topic at the f2f.
- 19:11:47 [dka]
- Tim: yes I'm happy with that.
- 19:12:22 [dka]
- Dan: could be useful to have some draft text as a straw man.
- 19:12:39 [dka]
- Tim: yes - it sounds like a small thing but ...
- 19:12:49 [dka]
- ... something like 233 or somehting....
- 19:12:57 [Yves]
- example of a small rfc to add a status code: http://tools.ietf.org/html/draft-reschke-http-status-308-07
- 19:13:34 [dka]
- One question I have: does it have non-data non-LD use cases?
- 19:14:25 [dka]
- Tim: what's interesting about is the machine understanding the relationship between the two documents.
- 19:14:40 [dka]
- Tim: if you're dealing with a human being you just get a 200.
- 19:15:19 [dka]
- Dan: would it be useful in a httprequest context?
- 19:15:39 [dka]
- Tim: it would be more useful in machine-readable context.
- 19:16:22 [dka]
- Tim: it would only work if you had an expect ion fron the server that the clinet would understand it .
- 19:16:42 [dka]
- Peter: you also mentioned a case using it for pagination.
- 19:17:00 [dka]
- ... that could have broader use for API calls as well...
- 19:18:23 [dka]
- Tim: another use - [in captive portals]
- 19:19:15 [dka]
- Tim: I think the 209 is a simple thing to push through.
- 19:20:29 [dka]
- [discussion / rant on captive portals and the evil of...]
- 19:22:20 [Zakim]
- -dka
- 19:22:23 [Zakim]
- -Yves
- 19:22:25 [Zakim]
- -plinss
- 19:22:34 [dka]
- Adjourned
- 19:22:41 [dka]
- rrsaegent, make minutes
- 19:22:51 [dka]
- rrsagent, make minutes
- 19:22:51 [RRSAgent]
- I have made the request to generate http://www.w3.org/2013/12/19-tagmem-minutes.html dka
- 19:22:56 [dka]
- rrsagent, make logs public
- 19:23:46 [dka]
- rrsagent, make minutes
- 19:23:46 [RRSAgent]
- I have made the request to generate http://www.w3.org/2013/12/19-tagmem-minutes.html dka
- 19:35:00 [Zakim]
- disconnecting the lone participant, TimBL, in TAG_Weekly()1:00PM
- 19:35:01 [Zakim]
- TAG_Weekly()1:00PM has ended
- 19:35:01 [Zakim]
- Attendees were Bryan_Sullivan, plinss, dka, twirl, Yves, JeniT, +34.91.432.aaaa, efullea, Art_Barstow, [IPcaller], chaals, TimBL
- 20:09:43 [dka]
- dka has joined #tagmem
- 20:17:14 [JeniT]
- JeniT has joined #tagmem
- 20:28:44 [timbl]
- timbl has joined #tagmem
- 20:58:34 [dka]
- dka has joined #tagmem
- 21:23:00 [Zakim]
- Zakim has left #tagmem
- 22:19:00 [chaals]
- chaals has left #tagmem