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