09:06:21 <RRSAgent> RRSAgent has joined #tagmem
09:06:21 <RRSAgent> logging to http://www.w3.org/2014/01/09-tagmem-irc
09:06:23 <trackbot> RRSAgent, make logs public
09:06:23 <Zakim> Zakim has joined #tagmem
09:06:25 <trackbot> Zakim, this will be TAG
09:06:25 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
09:06:26 <trackbot> Meeting: Technical Architecture Group Teleconference
09:06:26 <trackbot> Date: 09 January 2014
09:06:46 <dka> Yves We are online on https://opentokrtc.com/w3ctag
09:08:41 <dka> Scribe: Alex
09:08:55 <dka> trackbot, start meeting
09:08:57 <trackbot> RRSAgent, make logs public
09:08:59 <trackbot> Zakim, this will be TAG
09:08:59 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
09:09:00 <trackbot> Meeting: Technical Architecture Group Teleconference
09:09:00 <trackbot> Date: 09 January 2014
09:09:22 <dka> scribenick: slightlyoff
09:09:29 <dka> chair: dan
09:10:14 <slightlyoff> [ UK train service isn't what it used to be ]
09:10:21 <slightlyoff> Topic: 209 response code
09:11:00 <dka> Topic: 209
09:11:41 <slightlyoff> TBL: the way the web works today is that if you get a 200 response, what you get back is a representation of what you asked for
09:12:19 <JeniT> see http://www.w3.org/2001/tag/awwsw/issue57/20120202/#status-code
09:12:29 <slightlyoff> thanks, JeniT
09:12:31 <ht> ht has joined #tagmem
09:13:13 <slightlyoff> TBL: it's not arguing over what "representation" means in great detail, but we can just say that there are times when the server does that (e.g., redirects), and we have many of these situations
09:13:25 <slightlyoff> TBL: e.g., you should be using that URI instead
09:13:41 <ht> s/server does/server doesn't do/
09:13:49 <slightlyoff> TBL: 303 indicates that "I'm not going to give you the answer, nor a way to find it, but somplace where you can find out how to get an answer"
09:13:59 <slightlyoff> thanks, ht
09:14:36 <slightlyoff> TBL: this was used famously in SemWeb stuff where people want to identify objects using URIs with hashes in them
09:15:02 <slightlyoff> TBL: in this case, the hash used the hash to separate the document from the object
09:15:16 <slightlyoff> TBL: there are cases where something wants to represent, e.g., a school
09:15:39 <slightlyoff> TBL: the 303 opens up the possibility that you can redirect to documents that talk about things which don't represent them
09:15:52 <dka_> dka_ has joined #tagmem
09:16:01 <slightlyoff> TBL: this was a decent compromise except that real systems that dereference URIs now have to pay for an extra round-trip
09:16:09 <slightlyoff> TBL: 303 was logically sound, but sucked in practice
09:17:05 <slightlyoff> TBL: post SemWeb, we have similar situations that arise; linked-data folks who get data want to return a first page but not an entire data set up-front
09:17:15 <slightlyoff> TBL: and yesterday we discussed packages (E.g., for CSV or for icons)
09:17:27 <JeniT> we have a draft on this at http://www.w3.org/TR/urls-in-data/
09:17:35 <slightlyoff> TBL: one possible thing to do is to return a 303 that redirects to a package
09:18:01 <slightlyoff> TBL: in all of these situations, we have bodies that are RELATED to items, but are not them logically
09:18:12 <ht> q+ to check a paraphrase: 2xx == "i could have given you a 303, but I'll save you the trouble of the refetch by giving you the result of that right away"
09:18:26 <slightlyoff> TBL: if we were redesigning HTTP, we might do this with a different success code...the logical thing to do now is a new error code
09:18:30 <dka_> q?
09:18:51 <JeniT> q+ to highlight why we haven't recommended this previously
09:18:52 <slightlyoff> TBL: if client software gets a 20x treats it as success if it doesn't understand it
09:19:05 <slightlyoff> TBL: this enables caches and proxies
09:19:44 <slightlyoff> TBL: a smart proxy might understand the new status code and start building up a list of related resources
09:19:58 <slightlyoff> TBL: a dumb proxy would just repeat/passthrough
09:20:07 <ht> q+ ht2 to ask about proxies and response codes
09:20:12 <slightlyoff> TBL: in each application, a smarter client can do the right thing...paging, e.g.
09:21:06 <slightlyoff> TBL: we have some places where this will be useful and places where 303 has caused damage. It'd be good if the TAG could find a way to make 20x a reality.
09:21:23 <slightlyoff> TBL: the problem is that the W3C folks view working in IETF as a burden that they aren't ready to shoulder
09:21:38 <slightlyoff> dka: someone needs to write an RFC?
09:21:42 <dka> q?
09:21:44 <slightlyoff> JT: ht and I are doing that
09:21:45 <dka> ack ht
09:21:45 <Zakim> ht, you wanted to check a paraphrase: 2xx == "i could have given you a 303, but I'll save you the trouble of the refetch by giving you the result of that right away"
09:22:06 <JeniT> s/ht and I are doing that/ht and I are on the queue/
09:22:56 <slightlyoff> ht: whatever other properties this has, you're not introducing new semantics, you're just saying "here's a short circuit for your request", right?
09:22:59 <slightlyoff> [ agreement ]
09:23:02 <dka> ack jenit
09:23:02 <Zakim> JeniT, you wanted to highlight why we haven't recommended this previously
09:23:17 <timbl> timbl has joined #tagmem
09:23:27 <ht> q+ ht3 to worry about the _principled_ reason for using hashless URIs
09:23:37 <slightlyoff> JeniT: to also talk about history, we've talked about this previously, and we've published the URLS in Data draft: http://www.w3.org/TR/urls-in-data/
09:23:59 <slightlyoff> JeniT: one of the problems that 303 has is that hacking headers and response code is hard for some people (adoption burden)
09:24:27 <slightlyoff> JeniT: the other issue is a question of friendliness; do proxies, etc. actually do the right thing in the face of the new code?
09:24:45 <slightlyoff> JeniT: the fact that we didn't recommend 20x in the past doesn't mean that we shouldn't do this now
09:25:12 <slightlyoff> JeniT: I would view it as the role of the W3C/IETF liason to enable WGs to register these status codes
09:25:19 <slightlyoff> JeniT: I'm not sure that _we_ need to do anything here
09:25:21 <ht> q+ ht4 to ask Yves about process
09:25:23 <slightlyoff> (as the TAG)
09:25:35 <slightlyoff> JeniT: ...that is, unless we want to revisit those previous decisions
09:25:43 <slightlyoff> JeniT: e.g., why are revisiting this now?
09:26:06 <slightlyoff> TBL: it's sad when we can't make design progress because we feel that server design or configuration is too fixed
09:27:04 <slightlyoff> [ review of Content-Type difficulities with packaging, e.g. ]
09:27:43 <slightlyoff> TBL: Yves is an apache committer...we might want to go back into that analysis
09:28:22 <wycats_> Got a cab. Will be there shortly
09:28:24 <slightlyoff> TBL: the people who were pushing for URIs without hashes in them were companies that had built their severs without flexibility to handle them...they had pursued other options
09:28:26 <slightlyoff> wycats_: no worries
09:28:47 <slightlyoff> TBL: people who want to publish on servers without .htaccess ahve the ability to just post a lot of files.
09:29:13 <slightlyoff> JeniT: I'd like to see analysis that clients et. al. do the right thing with 2XX codes they don't understand
09:29:23 <slightlyoff> JeniT: if there are WGs that want this, why don't thye do it?
09:29:27 <slightlyoff> TBL: they don't have the engergy?
09:29:37 <slightlyoff> JeniT: who has got the energy?
09:29:51 <slightlyoff> TBL: nobody (proximately), which is why I bring it here
09:29:56 <twirl> s/engergy/energy
09:30:01 <slightlyoff> TBL: we have a broader view
09:30:11 <dka> q?
09:30:17 <slightlyoff> TBL: and can leave the architecture cleaner
09:30:25 <timbl> q?
09:30:43 <ht> ack ht4
09:30:43 <Zakim> ht4, you wanted to ask Yves about process
09:31:46 <slightlyoff> ht: counter argument is "it's too late, HTTPbis is so close to being done that there's no room for this"
09:31:57 <slightlyoff> ht: once HTTPbis is done, what's the process for new status codes?
09:33:03 <JeniT> http://tools.ietf.org/id/draft-reschke-http-status-308-07.html
09:33:09 <slightlyoff> Yves: see status code 308, which was introduced when we working on httpbis and it was defined as an external draft intended to become an RFC post HTTPbis
09:33:30 <slightlyoff> Yves: once that document becomes an RFC, it'll be incorporated into the status code repository at IANA
09:33:38 <slightlyoff> Yves: the requirement is an IETF review
09:33:52 <slightlyoff> JeniT: does the status code repo exist at IANA? or is it soemthing new?
09:34:10 <JeniT> http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
09:34:11 <slightlyoff> Yves: I think it exists. It contains HTTP and WebDAV statuses...probably others
09:34:16 <slightlyoff> thanks, JeniT
09:34:37 <slightlyoff> JeniT: so the answer is, if you want 209, write an RFC and then it gets put into that repository?
09:34:39 <slightlyoff> Yves: yep
09:34:51 <slightlyoff> Yves: if you look at 308, the doc can be pretty small
09:34:53 <ht> q- ht2
09:35:18 <JeniT> slightlyoff: wrt 308, was there experience with 308 & intermediaries?
09:35:22 <dka> q?
09:35:27 <slightlyoff> AR: was there experience with intermediaries?
09:35:48 <slightlyoff> Yves: it will be interpretted as a temporary redirect by proxies that don't understand it 308
09:36:00 <slightlyoff> ht: why do you think that's the case? why will they do anything at all with 308?
09:36:09 <slightlyoff> Yves: it's defined in HTTPbis
09:36:14 <slightlyoff> Yves: similar for 2XX
09:36:16 <timbl> See http://tools.ietf.org/id/draft-reschke-http-status-308-07.html#deployment.considerations
09:36:44 <slightlyoff> ht: it's in the HTTPbis spec...but most deployed proxies predate it. Is it standard to do this fallback thing?
09:36:56 <slightlyoff> Yves: this is from 2616 and 2608
09:37:05 <slightlyoff> Yves: if you don't know the status code, you fallback to the generic version of it
09:37:07 <dka> q?
09:37:09 <dka> ack ht3
09:37:09 <Zakim> ht3, you wanted to worry about the _principled_ reason for using hashless URIs
09:37:38 <wycats_> can someone give me the tl;dr of what we're discussing?
09:37:48 <slightlyoff> ht: I think it's necessary to note that there were 2 reasons people didn't and won't use 303, and might not want 209: 1.) the performance reason 2.) people disagree about what a "representation" is
09:38:05 <slightlyoff> ht: there are plenty of people who think that serving 200 is reasonable
09:38:16 <slightlyoff> (e.g., WRT serving RDF w/ 200)
09:39:07 <slightlyoff> ht: JeniT, Jonathan, and I concluded that there was no basis in the published spec to elide that view...HTTPbis doesn't change that
09:39:17 <slightlyoff> ht: we all agreed that we don't want to force agreement about what 200 "means"
09:39:42 <JeniT> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-6 states that unrecognised status code xyy must be interpreted as x00
09:39:44 <slightlyoff> [ discussion of history ]
09:39:51 <slightlyoff> [ it's complicated ]
09:40:15 <slightlyoff> ht: we can say that it's not clear from the existing specs that "document about X" is a representation of X or not.
09:40:40 <slightlyoff> ht: i want the record not to suggest that perf was the only reason
09:41:05 <slightlyoff> ht: maybe there's a good argument for 209 if it won't break the web
09:41:50 <slightlyoff> dka: I'd like us to think more broadly
09:42:00 <slightlyoff> ht: I'd like this to piggyback on the semantics of 303
09:42:32 <slightlyoff> TBL: you'll find people who will argue that clients can figure it out in an app-specific way
09:42:37 <JeniT> q+ to ask about the Location field
09:42:40 <dka> ack jeni
09:42:40 <Zakim> JeniT, you wanted to ask about the Location field
09:42:45 <slightlyoff> TBL: many people won't worry about the architecture being crisp
09:43:14 <slightlyoff> JeniT: just looking at 303, an important thing about it is that it gives you another URL
09:43:22 <slightlyoff> JeniT: it points at another URL
09:43:36 <slightlyoff> JeniT: an important issue for a 209 spec is "where does that other URL come from?"
09:43:49 <slightlyoff> [background]
09:44:03 <slightlyoff> JeniT: if 209 is spec'd in terms of 303, where does the other URL come from?
09:44:15 <slightlyoff> TBL: the "Location:" header
09:44:17 <dka> q?
09:44:35 <slightlyoff> PL: that lets you fill caches
09:44:41 <slightlyoff> [agreement]
09:44:56 <slightlyoff> DKA: what's the work that needs to be done? who's going to do it?
09:45:05 <slightlyoff> DKA: also, do we think there would be pushback?
09:45:29 <Yves> there can be pushback if the story of default behaviour is not the right one
09:46:42 <slightlyoff> ht: we'd hope the caching would be the same, but I don't know and we'd need to look
09:46:58 <slightlyoff> ht: stipulating that we can work thorugh that, the RFC might need not be larger than the 308 RFC
09:47:19 <slightlyoff> TBL: the security implications are larger, thanks to x-origin fetches
09:48:02 <slightlyoff> [discussion of content caches across origins]
09:48:24 <slightlyoff> JeniT: e.g., you're filling a cache in lieu of another URL/fetch
09:48:33 <slightlyoff> ht: right, so there's no reason to suppose I'm not lying
09:49:27 <slightlyoff> [discussion of Location header]
09:50:06 <slightlyoff> AR: why would it be allowed to front for another origin?
09:50:59 <slightlyoff> TBL: in practice, you'd go to dbpedia.org/resources/paris, and it gives you a 303 to some other place (perhaps very intricate)
09:52:21 <slightlyoff> AR: ISTM that a browser should ignore 209s under this idea...
09:52:39 <slightlyoff> AR: if evil.com can claim it's serving content for good.com (while you're on good.com), that's pretty nasty
09:52:46 <ht> Content-location header: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.1.4.2
09:53:13 <slightlyoff> JeniT: a new client that understands 209 and understands the different base URL will behave differently to a client that only understands 200
09:53:42 <slightlyoff> dka: does this mean it's not useful on the web?
09:54:20 <slightlyoff> AR: you need more restrictions; e.g., you need to dissalow x-origin content
09:54:43 <slightlyoff> PL: what about signed content? if good.com signs it, who cares where it's hosted?
09:54:51 <slightlyoff> YK: that's a common use-case
09:54:55 <ht> Location header: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-7.1.2
09:55:00 <slightlyoff> JeniT: 2 issues: back-compat and security
09:55:08 <slightlyoff> TBL: back-compat is about base URL
09:55:19 <slightlyoff> HT: can I bring us back to the header question? (see refs above)
09:55:33 <slightlyoff> HT: "Content-Location" appears to be what you want
09:55:58 <slightlyoff> HT: the semantics of "content-location" is to say "this is the content", while "Location" says, "it's over there"
09:56:08 <slightlyoff> HT: the "Content-Location" does seem to say what you want
09:56:37 <slightlyoff> [discussion of baseurl]
09:56:59 <slightlyoff> Yves: there was a case earlier where Content-Location was modifying the BaseURI, everyone ignored it, and it was removed from HTTPbis
09:57:15 <slightlyoff> TBL: but Content-Location defines the baseuri of the application?
09:57:29 <slightlyoff> [inaudible]
09:57:43 <slightlyoff> Topic: Responsive Images
09:57:44 <dka> PROPOSED ACTION: Yves to draft an analysis document detailing these issues discussed on 209 with a view towards this document being fodder for an RFC.
09:58:44 <dka> ACTION: Yves to draft an analysis document detailing these issues discussed on 209 with a view towards this document being fodder for an RFC.
09:58:45 <trackbot> Created ACTION-851 - Draft an analysis document detailing these issues discussed on 209 with a view towards this document being fodder for an rfc. [on Yves Lafon - due 2014-01-16].
09:59:16 <ht> s/is to say "this is the content", while "Location" says, "it's over there"/is absolute, w/o regard to response code, so will be backwards compatible, whereas "Location" is specified to have response-code dependent semantics, and so _will_ raise compatibiity issues/
10:00:30 <slightlyoff> [discussion of attestation WRT security relatinship...etag proposed and rescinded]
10:00:31 <timbl> "If Content-Location is included in a 2xx (Successful) response
10:00:32 <timbl>    message and its field-value refers to a URI that differs from the
10:00:33 <timbl>    effective request URI, then the origin server claims that the URI is
10:00:35 <timbl>    an identifier for a different resource corresponding to the enclosed
10:00:36 <timbl>    representation.  Such a claim can only be trusted if both identifiers
10:00:37 <timbl>    share the same resource owner, which cannot be programmatically
10:00:38 <timbl>    determined via HTTP."
10:00:40 <timbl> -- http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.1.4.2
10:00:45 <slightlyoff> Topic: Responsive Images
10:00:55 <yoav> Slides: http://yoavweiss.github.io/respimg-tag-presentation
10:02:01 <JeniT> Present: Dan, Jeni, Alex, Tim, Anne, Henry, Sergey, Peter, Yehuda, Yoav
10:02:12 <slightlyoff> YY: [introduction, working in webkit/blink as well as the RICG]
10:02:40 <annevk> annevk has joined #tagmem
10:02:51 <slightlyoff> YY: I'll start by describing the problem: the basic definition is that we're trying to serve the right images to the right devices in an efficient manner
10:03:00 <slightlyoff> YY: it seems like an easy problem, but is harder than it looks
10:03:30 <slightlyoff> YY: the reason it's important is that Responsive Web Design is arguably the future of web design. Serving dedicated versions of sites to each client doesn't scale.
10:03:49 <slightlyoff> YY: original approach was to serve large images and let clients resize
10:03:59 <slightlyoff> YY: RWD became synonymous with slow
10:04:16 <slightlyoff> YY: there are tons of savings to be made by resizing images to the device
10:04:32 <slightlyoff> YY: retina made things worse. Widened the gap between low-and-high-end devices.
10:04:50 <slightlyoff> YY: RICG was foudned 1.5 years ago. We created a use-cases document that described what needs to be done.
10:05:07 <slightlyoff> YY: 3 major use-cases: retina images to retina devices (not low-end devices)
10:05:29 <slightlyoff> YY: viewport switching: variable width images. SHould be adapted to viewport dimensions
10:05:41 <slightlyoff> YY: Doesn't mean that a smaller viewport gets a smaller image
10:06:03 <slightlyoff> YY: DPR switching and viewport switching have image dimensions in common, but no quality
10:06:26 <slightlyoff> YY: 3rd use-case is Art Direction: takes image adaptation futher. Images that are more relevant to content.
10:06:42 <slightlyoff> YY: expanding context with available size; alternative crops
10:07:00 <slightlyoff> YY: since the problem is perf, we want to play well with the preloader
10:07:08 <slightlyoff> YY: proposed standard solutions are:
10:07:19 <slightlyoff> YY: the revised <picture> element + client hints headers
10:07:28 <slightlyoff> YY: these can and should work together
10:07:43 <slightlyoff> YY: revised <picture> merges 3 previous proposals
10:07:57 <JeniT> http://picture.responsiveimages.org/
10:08:52 <slightlyoff> YY: new picture uses the old picture's art-direction solution and it adopted the "srcn" proposal
10:09:10 <slightlyoff> YY: <source> is used for art direction. srcset indicates DPR/dimensions
10:09:23 <slightlyoff> YY: the "sizes" give the ability to hint correct sizes
10:09:29 <slightlyoff> [ example code ]
10:09:52 <slightlyoff> (see http://yoavweiss.github.io/respimg-tag-presentation/#/22)
10:10:59 <slightlyoff> YY: dpr switching in this way is implemented in blink and webkit
10:11:13 <slightlyoff> YY: next, art direction (slide: http://yoavweiss.github.io/respimg-tag-presentation/#/23)
10:11:44 <slightlyoff> YY: can also work with DPR
10:12:49 <slightlyoff> YY: viewport switching
10:13:02 <slightlyoff> YY: (example code: http://yoavweiss.github.io/respimg-tag-presentation/#/25)
10:15:19 <slightlyoff> [questions about what "viewport" means]
10:18:00 <wycats_> http://www.xanthir.com/b4PR0
10:18:22 <wycats_> ^^ Tab Atkins discussing element queries
10:18:55 <slightlyoff> [discussion about viewports vs element queries]
10:20:34 <slightlyoff> [css is hard]
10:20:46 <slightlyoff> TBL: what about iframes?
10:20:55 <slightlyoff> PL: the viewport is the size of the frame
10:21:02 <slightlyoff> YK: you don't want to use iframes for all images
10:21:55 <slightlyoff> [discussion about calculation difficulity]
10:25:04 <slightlyoff> (http://yoavweiss.github.io/respimg-tag-presentation/#/26)
10:26:12 <slightlyoff> YY: Tab Atkins is working on a proposal for coverage
10:26:29 <slightlyoff> YY: we need things to be calculated before layout
10:27:01 <slightlyoff> YY: to cover the srcset syntax in that case, we define resources in terms of width or height
10:27:10 <slightlyoff> TBL: if I zoom in, does the viewport size increase?
10:27:20 <slightlyoff> YY: it's a mangifying glass on mobile browsrs.
10:28:12 <slightlyoff> PL: we're talking about a way in the CSS WG to specify optical zoom
10:29:47 <slightlyoff> [ discussion of accessibility zoom vs pinch zoom ]
10:29:54 <slightlyoff> YY: that's the <picture> proposal
10:30:06 <slightlyoff> YY: client-hints are an HTTP-based content negotiation solution
10:30:17 <slightlyoff> YY: the client declares its capabilities and the server decides what resource to send
10:30:25 <slightlyoff> YY: the request headers are: CH-DPR
10:30:42 <slightlyoff> CH-RW
10:30:49 <slightlyoff> http://yoavweiss.github.io/respimg-tag-presentation/#/30
10:31:15 <timbl> q+ to ask whether the Vary: header will flag this form of conneg
10:33:03 <slightlyoff> YY: client-hints is opt-in only. If sent on all requests can introduce some bloat to HTTP
10:33:04 <Yves> tim, it should.
10:33:34 <slightlyoff> q+
10:33:37 <twirl> q+ fractional dpr
10:33:43 <slightlyoff> TBL: opt-in how?
10:33:50 <twirl> q+
10:34:00 <twirl> q- fractional
10:34:08 <twirl> q- dpr
10:34:10 <slightlyoff> YY: as part of the server-response, the document could send a header or meta switch
10:34:18 <slightlyoff> s/send/set/
10:34:30 <slightlyoff> YY: that'd make all sub-resources send client-hints
10:34:50 <dka> q?
10:35:43 <timbl> The server response to the original HTML page -- such as  HTTP header or equivalent met tag inHTML - would be used to turn on client hints
10:36:13 <dka> q?
10:36:16 <dka> ack timbl
10:36:16 <Zakim> timbl, you wanted to ask whether the Vary: header will flag this form of conneg
10:36:29 <slightlyoff> TBL: is the idea that you should be using the Vary: header when hints are available?
10:36:57 <slightlyoff> YY: this is why each hint is its own header
10:36:59 <dka> q?
10:37:05 <slightlyoff> YY: we want to enable vary on just one header
10:37:25 <slightlyoff> YY: if we had a Key: header, we could gather the hints into a single header, but we don't have that
10:37:40 <timbl> ack
10:37:44 <dka> ack sli
10:38:10 <slightlyoff> AR: is there an extensibility point, either API or markup?
10:38:15 <slightlyoff> YY: no, not now
10:38:55 <dka> ack twirl
10:38:56 <slightlyoff> YY: SW would be able to work with that in an imperative way
10:39:01 <slightlyoff> AR: yes, on the second-load
10:39:18 <dka> q?
10:39:20 <slightlyoff> timbl: is there anything here about exotic device pixel ratios?
10:39:29 <slightlyoff> s/timbl/twirl/
10:39:38 <timbl> (Of course you can embed RDF model metadata in basically any sort of image and in HTML)
10:39:38 <slightlyoff> twirl: is there upscaling? Things will look bad
10:39:55 <twirl> http://www.quirksmode.org/blog/archives/2012/07/more_about_devi.html
10:39:56 <slightlyoff> YY: the way it works is that if you have a higher ratio than is offered, you pick the highest
10:40:14 <slightlyoff> YY: haven't seen research about 3:5 or 3:4 ration...
10:40:23 <slightlyoff> YY: the difference between 1x and 2x is huge
10:40:31 <slightlyoff> YY: but beyond that, I don't know
10:40:48 <dka> q+ to ask about the current logistics and status of the work
10:40:56 <slightlyoff> PL: if 1x and 2x are specified, but the actual DPR is 1.5, which one is picked?
10:40:58 <slightlyoff> YY: the 2x
10:41:21 <slightlyoff> TBL: I thought the issue was that if you have 1x, 2x, and 4x, and you have a 5x device, which is nicer?
10:42:33 <timbl> TBL: to scale the 4x to 5 or just include the 4x unscaled to get better quality
10:42:49 <slightlyoff> YY: if you're sending close-enough images so that the byte-size impact won't be that bad, we enable you to hit the exact DPR
10:43:27 <slightlyoff> YY: client hints will let you hit the exact DPR, but not the precise resource width
10:43:55 <slightlyoff> YY: this is where (down)scaling comes into play
10:45:19 <slightlyoff> DKA: you mentioned that these are the latest proposals, but you had mentioned earlier that there were some issues with the way had been received by the HTML WG
10:45:36 <slightlyoff> DKA: I was wondering what your perspective is regarding how the work is progressing? is it going more smoothly?
10:46:34 <slightlyoff> YY: things are going more smoothly since Tab Atkins got involved. We have some resistance from browser vendors, but it's mostly down to technical issues...less political and less contentious
10:46:49 <slightlyoff> YY: I think a lot of the tension between standards and developers has abated somewhat
10:47:07 <slightlyoff> DKA: is the work happening in the RICG with a line to the HTML WG?
10:47:23 <slightlyoff> YY: currently we're morstly working in the CG around the GitHub repo
10:47:27 <dka> q?
10:47:30 <dka> ack dka
10:47:30 <Zakim> dka, you wanted to ask about the current logistics and status of the work
10:47:36 <slightlyoff> YY: it's possible that some people aren't members of the CG but are still involved
10:48:33 <slightlyoff> YY: we have some threads on the WHATWG lists, but we're mostly trying to get feedback on the spec from vendors and iterating
10:49:13 <slightlyoff> DKA: is there anything for the TAG to review or is there a need for formal content?
10:49:18 <slightlyoff> s/content/comment/
10:49:58 <slightlyoff> annevk: the whole thing seems messy...but abarth and maciej are looking at it which seems fine for me
10:50:14 <slightlyoff> annevk: I wondered if there was a way to figure out the primitives
10:50:33 <slightlyoff> annevk: but you need to be able to hook into the prefetch/prescan
10:53:04 <slightlyoff> AR: [general discussion of the architecture of the client and how running code on the parser would need to look...many constraints]
10:53:20 <slightlyoff> PL: I'm concerned with how this composes with progressive image formats
10:54:34 <slightlyoff> AR: we don't have any way to address these sub-images which are at diferent resolutions
10:54:41 <slightlyoff> they don't have URLs
10:54:57 <slightlyoff> YY: this is an area I've explored...the problem is the fetch mechanism
10:55:10 <slightlyoff> YY: we don't have an efficient way for the browser to indicate "I've got enough"
10:55:23 <slightlyoff> YY: we will need to always send 1 extra RTT's worth of data
10:55:39 <slightlyoff> YY: we should look into this in the future
10:55:53 <slightlyoff> YY: the Responsive Image Container prototype is in that spirity
10:56:23 <slightlyoff> YY: it enables the browser to have header-based information to help the browser choose what to download
10:56:40 <slightlyoff> YY: I experimented with progressive-JPEG, but the layers are limited
10:56:58 <slightlyoff> YY: e.g., you can't have a very small thumbnail expanded to a very large image
10:57:09 <slightlyoff> YY: the middle and high-quality images were constrained by the format
10:57:35 <slightlyoff> TBL: if it's 2:1, is it the case that the low-res is as high-quality as it'd be if you scaled it from scratch?
10:58:00 <slightlyoff> PL: wavelet formats don't have that problem
10:58:45 <slightlyoff> AR: what formats are wavelet based?
10:58:47 <twirl> jpeg200
10:58:53 <twirl> s/200/2000
10:58:54 <slightlyoff> twirl: JPEG-2000
10:59:06 <slightlyoff> YY: it had plenty of adoption time and failed
10:59:12 <twirl> or jp2 simetimes
10:59:20 <twirl> s/sime/some
11:00:07 <slightlyoff> YY: JPEG-2000 is in the same area as JPEG with efficiency, and WebP, JPEG-XR, etc. are much better
11:00:18 <slightlyoff> YY: also, patents
11:02:35 <slightlyoff> Topic: break
11:05:51 <JeniT> http://mobile.smashingmagazine.com/2013/09/24/responsive-image-container/
11:20:36 <annevk> timbl: ht: https://bugzilla.mozilla.org/show_bug.cgi?id=238654
11:22:11 <ht> http://www.ltg.ed.ac.uk/~ht/drm.html
11:24:40 <slightlyoff> Topic: Intro to technical background for that which shall not be named
11:25:15 <slightlyoff> ht: lots of pointers and links in the document, will be in the TAG wiki space shortly
11:25:32 <slightlyoff> ht: started as email discussion, etc.
11:27:32 <slightlyoff> ht: adding DRM to HTML5 comes in 2 parts: EME, which adds extensions to <video> and the CDM, which adds a key system and provider
11:28:18 <slightlyoff> ht: there's an important caveat: CDM is not required for spec compliance
11:29:00 <slightlyoff> ht: it's possible for there to be a no-op provider
11:30:41 <slightlyoff> ht: platform owners who provide CDMs seem unlikely to provide Open Source implementation or provide plugin support
11:32:15 <slightlyoff> ht: this division of labor is similar to the way the <object> tag works today
11:33:12 <slightlyoff> ht: one summary argument is "we're not doing that, we're just giving you EME, just as we added the <object> tag"
11:34:19 <slightlyoff> ht: a counter argument is "how can you integrate something like this into Linux?"
11:35:04 <slightlyoff> ht: DRM extends all the way to displays, not just HDMI
11:35:09 <slightlyoff> TBL: HDMI is broken
11:35:22 <slightlyoff> TBL: so what you send to HDMI is breakable by default
11:35:33 <slightlyoff> TBL: and it's hairy...legal consequences
11:36:57 <slightlyoff> [discussion of ChromeOS as existence proof for CDM + Linux]
11:37:24 <slightlyoff> ht: if we end up in a place where, if you choose to use Linux you can't opt into one of these ecosystems, that's pretty serious
11:37:44 <slightlyoff> ht: the <object> tag argument isn't a technical one, but it's useful to get a sense for the argument
11:37:54 <twirl> q+
11:38:43 <slightlyoff> ht: TBL replied "can we imagine an EME system that's usable by anyone as a publisher?"
11:38:53 <slightlyoff> ht: hsivonen responded (see slides)
11:40:21 <slightlyoff> [pause to read]
11:40:23 <dka> q?
11:41:07 <wycats_> q+
11:41:11 <dka> q?
11:42:15 <dka> AR: [speaking on ChromeOS's implementation] in verified boot mode there is a crypto device on the board which verifies your boot
11:42:46 <dka> ... same crypto that is used for a chain of drivers and software for enforcing DRM ...
11:43:34 <dka> ... the other mode is that you can flip into developer mode in which case all the memory is your's  - you can also install ant other OS ...
11:43:51 <dka> ... every chromeOS device has one of these ...
11:46:00 <dka> AR: EME plugs into the widevine CDM - provides the CDM - runs on windows, android, macos....  it's part of chrome.
11:46:16 <slightlyoff> (but not chromium)
11:46:29 <dka> AR: does not require verified boot. verified boot is how you get to a locked down world...
11:47:03 <dka> tbl: some are worried that verified boot makes it possible for a world in which all hardware is out of users' control...
11:47:26 <dka> AR: ChromeOS is a linux - but [is more locked down] than linux.
11:48:21 <dka> q?
11:48:24 <slightlyoff> thanks dka
11:48:28 <dka> ack twi
11:48:29 <slightlyoff> dka: happy to scribe
11:48:31 <timbl> q+ to mention different levels
11:48:43 <slightlyoff> scribenick: slightlyoff
11:49:09 <slightlyoff> twirl: I'd like to emphasize that entire countries will become ghettos
11:49:29 <slightlyoff> ht: no CDM acceptable to the providers will be available to you
11:49:39 <slightlyoff> YK: can you watch Netflix now?
11:49:52 <slightlyoff> YK: how does it change anything?
11:49:58 <slightlyoff> (answer: Netflix isn't in Russia)
11:49:58 <ht> http://www.ltg.ed.ac.uk/~ht/drm.html
11:50:12 <dka> q?
11:51:00 <slightlyoff> AR: [UK/US example]
11:51:07 <slightlyoff> YK: will this change the status quo?
11:51:31 <slightlyoff> twirl: there are lots of people who use US credit cards and itunes gift certificates to abritrage around this already...
11:52:10 <slightlyoff> YK: wait...but itunes could do geolocation checks today? what's different?
11:52:21 <slightlyoff> TBL: is it ip geolocation or the DRM?
11:52:44 <slightlyoff> TBL: we haven't discussed what I'd like to: can we make different versions?
11:53:02 <slightlyoff> TBL: can we sandbox the EME system so that it doesn't have access to many things?
11:53:47 <slightlyoff> TBL: suppose we make it illegal for a DRM system to access your location
11:54:37 <slightlyoff> [back to box diagram]
11:54:51 <slightlyoff> TBL: it doesn't show the flow of keys
11:56:45 <slightlyoff> YK: we should look at Unity...not think about Flash, per sae
11:56:58 <slightlyoff> (in response to Annevk noting that there aren't many Open Source plugins)
11:58:35 <dka> q?
11:58:39 <dka> ack timbl
11:58:39 <Zakim> timbl, you wanted to mention different levels
11:58:42 <slightlyoff> TBL: can we imagine some technical and regulatory changes that would put limits on CDMs such that they guarantee that any content provider can use at least one CDM on a system
11:58:44 <slightlyoff> ?
11:59:01 <wycats_> I cannot imagine any regulatory changes that would be sensitive to the nuances in this area
11:59:29 <slightlyoff> TBL: can we have a CDM that anyone can negotiate with?
12:00:49 <slightlyoff> e.g., a system that won't refuse to play any content that wants to collaborate with it in an open way
12:01:00 <slightlyoff> (private key is defended, but business relationship isn't)
12:02:37 <slightlyoff> YK: so who would build this
12:02:38 <slightlyoff> ?
12:04:22 <slightlyoff> HT: for Tim's vision to be true, we need CDMs to be widely deployed/pluggable, and browsers are moving in the other direction
12:05:05 <slightlyoff> TBL: so the way I use the MSFT system is that I buy MSFT server software and pay a license fee. Apple works differently. But suppose that Google made the CDM/server free for anyone to use.
12:07:17 <slightlyoff> [discussion about what content is available today]
12:07:38 <slightlyoff> DKA: imagine a Finnish company wants to build their own videos and their own CDM...how do we enable that?
12:08:35 <slightlyoff> DKA: the implication is that it's not like a plugin system because you can't add other things....
12:08:48 <slightlyoff> YK: WinRT, ChromeOS, iOS...
12:09:39 <slightlyoff> TBL/YK: [discussion of the ability to add new things in the face of verified boot]
12:10:06 <dka> q?
12:10:16 <dka> ack wycats
12:10:20 <slightlyoff> TBL: lets imagine a single freely deployed plugin where the server is freely available
12:10:57 <slightlyoff> YK: My mind is changed by ht's presentation
12:11:16 <slightlyoff> YK: I was deeply opposed, but I don't understand what new harm that defining a subset of our plugin capability will do
12:11:41 <slightlyoff> PT: what if we were to define CDMs in a way such that they were able to be implemented in JS?
12:12:42 <slightlyoff> AR: [background on Pepper as it was brought up]
12:13:03 <slightlyoff> TBL: the future is much bigger
12:13:15 <slightlyoff> PT: maybe we throw out some of the capabilities if we need to
12:13:22 <slightlyoff> [Web Crypto mentioned]
12:14:51 <slightlyoff> annevk: but NPAPI is a standard...
12:14:55 <slightlyoff> (spec, sorry)
12:15:08 <slightlyoff> [discussion about implementing a CDM in JS]
12:16:40 <marcosc> marcosc has joined #tagmem
12:16:46 <slightlyoff> AVK: notes that Mozilla presented sandboxing to the WG and it was rejected
12:17:01 <slightlyoff> [thanks to HT for his detailed technical contribution]
12:18:45 <plinss> s/PT:/PL:/g
12:19:07 <slightlyoff> thanks plinss
12:23:58 <dka> ACTION: Jeni to start a write-up on this EME discussion.
12:23:58 <trackbot> Created ACTION-852 - Start a write-up on this eme discussion. [on Jeni Tennison - due 2014-01-16].
12:27:20 <annevk> annevk has joined #tagmem
12:47:39 <dka> dka has joined #tagmem
12:49:38 <twirl> twirl has joined #tagmem
12:50:03 <annevk> annevk has joined #tagmem
12:50:23 <twirl> ScribeNick: twirl
13:03:57 <slightlyoff> YK: there was lunch discussion that the general shape of a layered system is clear once we have WebCrypto: we need some sort of secure worker system that can talk to WebCrypto. Plumbing processed output through is a challenge that isn't clear in the current APIs
13:04:10 <slightlyoff> [discussion of layering regarding Responsive Images]
13:05:07 <dka> ACTION: Yehuda to start a write-up on architectural / layering considerations on responsive images.
13:05:07 <trackbot> Created ACTION-853 - Start a write-up on architectural / layering considerations on responsive images. [on Yehuda Katz - due 2014-01-16].
13:05:23 <dka> action-853?
13:05:23 <trackbot> action-853 -- Yehuda Katz to Start a write-up on architectural / layering considerations on responsive images. -- due 2014-01-16 -- OPEN
13:05:23 <trackbot> http://www.w3.org/2001/tag/group/track/actions/853
13:10:29 <dka> scribe: sergey
13:10:36 <dka> Scribenick: twirl
13:11:25 <dka> http://adactio.com/journal/6629/
13:11:57 <twirl> DKA: We don't have a document for design principles and the layering
13:12:32 <dka> Topic: Design Principles
13:12:39 <twirl> YK: It's time to write down some stuff
13:13:40 <twirl> YK: High-level APIs should be defined in terms of low-level APIs
13:13:54 <twirl> ... people have questions about it and we should answer them
13:14:20 <annevk> JeniT: internet did my job, http://storify.com/jorabin/meet-the-tag-2
13:14:35 <twirl> DKA: Is this the same is API Design Guide?
13:14:51 <twirl> YK: No, Guide is more concrete
13:17:20 <twirl> JT: Who is target audience? API makers?
13:17:34 <dka> ACTION: Yehuda to start working on a design principles write-up on "layering" - an explainer document and FAQ / examples on the architectural principles.
13:17:34 <trackbot> Created ACTION-854 - Start working on a design principles write-up on "layering" - an explainer document and faq / examples on the architectural principles. [on Yehuda Katz - due 2014-01-16].
13:17:43 <twirl> YK: No, that's an explanation of principles addressed to everyone
13:19:04 <dka> Topic: Promises
13:19:24 <JeniT> brucel's writeup of meet the TAG: http://www.brucelawson.co.uk/2014/i-met-the-tag-2/
13:20:12 <twirl> [ AR and YK explain the history of question ]
13:20:30 <twirl> AR: TC39 has a consensus on Promises
13:22:24 <wycats_> had*
13:23:19 <twirl> .. there are some objections from Domenic and from developers
13:24:14 <twirl> .. in my opinion October draft has several regressions
13:24:50 <twirl> [ general disagreement ]
13:27:40 <dka> q?
13:27:41 <twirl> [ discussion on whether TC39 would ship smth that is not subclassable ]
13:30:18 <twirl> [ discussion whether browser should ship that feature independently ]
13:30:27 <twirl> s/browser/browsers
13:31:23 <twirl> AR: I have some fears on progress of Streams and other features wrt Promises disagreements
13:36:02 <ht> Note to Alex Russell: Link to my presentation on DRM to use in the minutes, please: http://www.w3.org/2001/tag/2014/01/hst_drm_notes.html
13:38:02 <slightlyoff> ht: what am I looking at here?
13:38:08 <slightlyoff> oh, great, thanks
13:38:55 <twirl> AR: I think we found stable design
13:39:30 <twirl> AR: Working groups may use it
13:40:20 <twirl> [ discussion on Streams vs Promises in video API ]
13:41:55 <twirl> AR: many people care about possible memory leaks with Promises and Streams
13:42:30 <twirl> AR: we should probably have promises-for-overall-operations
13:43:06 <twirl> DKA: should we have a speical guide?
13:43:17 <twirl> s/speical/special
13:43:19 <dka> action-834?
13:43:19 <trackbot> action-834 -- Сергей / Sergey Константинов / Konstantinov to Start fleshing out an api review document -- due 2014-01-06 -- OPEN
13:43:19 <trackbot> http://www.w3.org/2001/tag/group/track/actions/834
13:44:52 <marcosc> marcosc has joined #tagmem
13:45:41 <dka> https://github.com/w3ctag/api-design-guide/blob/master/API%20Design%20Guide.md
13:46:12 <wycats_> incidentally, async functions in ES7 may moot the biggest areas of disagreement in Promises
13:46:19 <dka> https://github.com/w3ctag/promises-spec-text
13:47:16 <annevk> https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md
13:47:22 <annevk> ^^ is the text wycats_ dka
13:47:34 <dka> [...notionally putting the action on one of our potential new TAG members on putting text into this document...]
13:57:29 <annevk> RRSAgent, draft minutes
13:57:29 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/09-tagmem-minutes.html annevk
13:57:45 <annevk> RRSAgent, make public
13:57:45 <RRSAgent> I'm logging. I don't understand 'make public', annevk.  Try /msg RRSAgent help
13:57:52 <annevk> RRSAgent, make minutes public
13:57:52 <RRSAgent> I'm logging. I don't understand 'make minutes public', annevk.  Try /msg RRSAgent help
13:58:00 <annevk> RRSAgent, make logs public
13:58:09 <annevk> RRSAgent, you better
13:58:09 <RRSAgent> I'm logging. I don't understand 'you better', annevk.  Try /msg RRSAgent help
13:58:57 <plinss> rrsagent. pointer?
13:59:24 <plinss> rrsagent, pointer?
13:59:24 <RRSAgent> See http://www.w3.org/2014/01/09-tagmem-irc#T13-59-24
14:02:42 <dka> Topic: Push
14:03:33 <twirl> https://dvcs.w3.org/hg/push/raw-file/tip/index.html
14:03:53 <twirl> https://github.com/w3ctag/spec-reviews/tree/master/2013/08
14:05:43 <annevk> Zakim, who is here?
14:05:43 <Zakim> sorry, annevk, I don't know what conference this is
14:05:45 <Zakim> On IRC I see marcosc, annevk, twirl, dka, ht, Zakim, RRSAgent, JeniT, darobin, yoav, bkardell, slightlyoff, wseltzer, projector, wycats_, plinss, Yves, trackbot
14:06:11 <dka> zakim, room for 4
14:06:11 <Zakim> I don't understand 'room for 4', dka
14:06:20 <plinss> zakim, room for 4?
14:06:20 <dka> zakim, room for 4?
14:06:21 <Zakim> ok, plinss; conference Team_(tagmem)14:06Z scheduled with code 26631 (CONF1) for 60 minutes until 1506Z
14:06:21 <Zakim> dka, an adhoc conference was scheduled here less than 2 minutes ago
14:06:44 <Bryan> Bryan has joined #tagmem
14:06:57 <Bryan> What's the bridge code
14:07:14 <timbl> timbl has joined #tagmem
14:07:26 <timbl> rrsagent, pointer?
14:07:26 <RRSAgent> See http://www.w3.org/2014/01/09-tagmem-irc#T14-07-26
14:07:49 <Zakim> Team_(tagmem)14:06Z has now started
14:07:55 <Zakim> +DKA
14:07:56 <Zakim> +Bryan_Sullivan
14:09:21 <dka> Sergey: at our last teleconf we outlined some questions to be considered...
14:10:03 <twirl> https://github.com/w3ctag/spec-reviews/blob/master/2013/08/Push%20API.md
14:10:57 <dka> Sergey: we should consider these open question ....
14:11:22 <dka> Sergey: we need to consider the implementations...
14:11:48 <dka> Bryan: pointers to implementations of underlying protocol?
14:11:53 <dka> Sergey: yes.
14:12:08 <dka> ... we should refer to the underlying protocol of the spec.
14:12:33 <dka> Anne: it needs to be clear how we implement the entire feature. Both API and protocol.
14:12:50 <dka> Bryan: by protocol you mean the wire protocol or between server and client?
14:13:37 <dka> Anne: as I understand, the way it is set up is you have the 3 parties - the browser, the browser server (in cloud), and the web site.
14:13:52 <dka> Bryan: we refer to browser server as the push server.
14:14:12 <dka> Anne: you need to standardize what goes between the push server and the 3rd party server. And that is not done.
14:14:45 <dka> Bryan: that's what I'd call the northbound interface. there are a variety of instances. They depend on a variety of approaches some of which are proprietary.
14:15:03 <dka> Anne: given that this is a new API it would seem to me that what goes between push server and 3rd party server - we can do anything.
14:15:33 <dka> Bryan: yes we can create something completely new - e.g. a post operation with a token and a body. We could do that but was not part of the scope.
14:15:38 <dka> AR: Does it need to be part of the spec?
14:15:49 <dka> Anne: no but it needs to be part of the feature..
14:16:23 <dka> ... you need something from 3rd party server to communicate to the push server ... the API does have the handing out of the [push server pointer] but unclear on how that works.
14:16:31 <dka> Sergey: it doesn't specify what to do next.
14:17:52 <dka> Bryan: yes. Today it's out of scope. We'll give guidance. In the absence of a generic northbound protocol supported by all push systems the app server needs to figure out the push server protocol... App server will need to use SDK applicable based on the URI that it gets...
14:18:33 <dka> DKA: Would specifying a northbound protocol mean it would be mandatory?
14:19:06 <dka> Bryan: no.
14:19:30 <dka> Anne: I think the API hands out an endpoint - a url - that presumes something about how you're going to communicate.
14:19:54 <dka> Byran: yes - there is an assumption [that it is a URL].
14:20:10 <dka> Bryan: generally yes this will be http - that is assumed - although there could be other options.
14:20:26 <dka> Bryan: exactly what that interface is will have to be derived from that URI that you get.
14:20:39 <dka> Anne: if you don't standardize that how will people use this feature?
14:21:07 <dka> Tim: question is - if it's not standardized and you get multiple implementations how do you get interop?
14:21:38 <dka> Bryan: Feature is implemented in a number of propriety ways - and you have services such as Urban Airship that normalize...
14:21:59 <dka> AR: I think this is inappropriate -
14:23:01 <dka> Bryan: the way in which an end to end system can work... if we find that that result is non-interoperable solution we can work on defining a northbound interface. I would be happy to have Apple, google, etc... supporting that. That's what we did in OMA push rest.
14:23:15 <dka> Bryan: suggest it would be a separate spec.
14:23:40 <dka> Bryan: I would like to have as part of the data the app gets back from the browser a description of the system.
14:24:41 <Zakim> +Yves
14:25:18 <dka> DKA: I think the URI is not the right place to carry the info of what protocol it is - since URIs are supposed to be opaque strings...
14:25:44 <dka> Bryan: we do not have dynamic discovery of services today...
14:26:23 <dka> AR: This is not unique to push. We don't have automated service property discovery based on the URL of a service. Not a specifc problem to your domain.
14:26:42 <dka> Tim: In the SPARQL context there has been push this - defining "follow your nose".
14:26:51 <dka> AR: That's an uncommon property.
14:27:32 <dka> Anne: there'a s difference - you know you are getting a URI back to push to, but in this case you need to know what to ...
14:27:42 <dka> Tim: you need back channel information at the moment.
14:28:16 <dka> Anne: this protocol is simple - the 3rd party server would just do a post to he push server. We should just define something simple and have it work.
14:29:03 <dka> AR: 1 - there are existing services you'd like to be compatible with - which the current design allows. 2. even if you do have a standard then it's an additional thing these services need to support....
14:29:29 <dka> Anne: do we need to interoperate with the rest of the world? This is the first time we're designing push on the web
14:29:51 <dka> AR: there are existing services we are the middleman for ...
14:30:26 <dka> Anne: that is why we have the 2 server setup. It effectively puts the a simple protocol between 3rd party and the push server and we don't need to standardize the push server to client.
14:32:37 <dka> YK: [on service worker]
14:33:11 <dka> YK: it seems to me it would be good for this API to live int he service worker - to allow for the service worker to know what to do with the push notification... would be helpful if javascript libraries could work with.
14:33:33 <dka> Bryan: yes. I agree. Would be helpful to have guidance on that.
14:35:44 <Zakim> -Bryan_Sullivan
14:35:45 <dka> Bryan: i will draw up a straw man proposal and work with you.
14:36:00 <Zakim> -DKA
14:36:26 <Zakim> -Yves
14:36:27 <Zakim> Team_(tagmem)14:06Z has ended
14:36:27 <Zakim> Attendees were DKA, Bryan_Sullivan, Yves
14:48:38 <JeniT> [discussion of whether it's necessary to have an interoperable network protocol]
14:53:27 <dka> [some disagreement on how important / vital specifying the network (northbound) protocol]
15:04:22 <dka> PROPOSED RESOLUTION: on Push - aside from the work on the existing push API specification, the TAG would like to see a specified reference "northbound" protocol - between the web server and the push server.
15:09:16 <timbl> not in the same spec
15:09:26 <wycats_> what we just discussed in person was that the current spec work just involves a high-level notion of what the full system would look like
15:09:30 <wycats_> not any actual spec work
15:09:36 <dka_> dka_ has joined #tagmem
15:09:55 <dka_> PROPOSED RESOLUTION: on Push - aside from the work on the existing push API specification, the TAG would like to see - not necessarily in the same spec - a specified reference "northbound" protocol - between the web server and the push server. we'd also like to see a proposal for a server between the push server and the UA.  We would like to see architectural consideration of these issues before the push API spec is finalized.
15:10:09 <wycats_> sounds good
15:10:54 <dka_> PROPOSED RESOLUTION: on Push - aside from the work on the existing push API specification, the TAG would like to see a specified reference "northbound" protocol - between the web server and the push server. we'd also like to see a proposal for a protocol between the push server and the UA.  Neither of these issues should block the finalization of the API but we would like to see architectural consideration of these issues before the push API spec is finalized.
15:11:44 <timbl> Iq+ to with concern on a more general level…   1) the centralization of the design putting all reliance on a single central node for all pushes for a given type of device   and 2) the lack of standardization in the network protocols for the push server preventing a new push server to be dropped in if needed, 3) Lack of user ability to chose which push server to trust, though there is a lack of trust in these things on the net today..
15:38:43 <dka_> dka_ has joined #tagmem
15:47:37 <twirl> ht: I've been on the TAG for a long time
15:48:22 <twirl> .. One observation/suggestion: it's great that TAG is shifting
15:48:53 <twirl> .. but I'm not convinced that's a right thing to do
15:49:11 <twirl> .. (thouh this work, of course, should be done)
15:49:38 <twirl> s/is shifting/is shifting to cover new APIs
15:50:41 <twirl> .. two things were always historically in center of TAG's interesting: accessibility and i18n
15:52:14 <twirl> .. and I'd like to concentrate on my work
15:53:02 <dka> ht: we need a new model for the Web - TAG is one of the few bodies who could do that.
15:53:57 <dka> ht: I have been working on something: "just use http:" - a few drafts have been written but not published.
15:54:26 <dka> ht: is http: wedded to HTTP protocol? Yes in principle these are independent...
15:54:53 <dka> ... but I think actually we need to decouple naming from the hint of the protocol that is still there.
15:55:40 <dka> ... we need URIs that we will still use 10 years from now (which may not have http:) - I want actionable URIs - should we stop and think again about designing the actionable URI for the next 20 years - not a new protocol, but the naming architecture.
15:56:36 <dka> ... The introduction to the http spec should be written differently [in the face of today's web].
15:57:26 <dka> ... The original purposes of the Web was to solve a problem - to share preprints between physicists; we now use it to buy airplane tickets...
15:57:45 <dka> ... that it has survived and grown to what it is is astonishing ....
15:58:03 <slightlyoff> (unrelated to anything, group photo: http://www.flickr.com/photos/slightlyoff/11856406496/)
16:05:04 <dka> Topic: Fetch
16:05:12 <dka> http://fetch.spec.whatwg.org
16:06:19 <twirl> AvK: between APIs endpoints and resources there is fetch
16:06:29 <twirl> .. Fetch defines how does it works
16:06:43 <twirl> .. For HTTP it defines how protocols works
16:06:57 <twirl> .. Fetch takes request object and returns response object
16:07:20 <twirl> .. which are HTTP response and request
16:07:46 <twirl> .. you can read headers, e.g. content-type header
16:08:00 <twirl> .. for file it's up to implementation
16:08:13 <twirl> .. same for FTP
16:09:19 <twirl> .. XHR constructs a request object and passes to fetch
16:09:33 <twirl> .. fetch returns response object
16:10:15 <twirl> .. Fetch queues tasks to network queue
16:11:36 <twirl> .. XHR is one consumer, other consumers (i.e. includes, images, etc) should be directed to Fetch, though in present moment that's not completely true
16:11:53 <twirl> .. Response object may be a NetworkError
16:13:31 <twirl> .. There is one-to-one relationship between fetch and APIs
16:14:38 <twirl> .. Its up to c++ level how to implement that
16:15:19 <twirl> TBL: Is it possible to get more than one answer?
16:15:32 <twirl> AvK: No, you can't
16:15:50 <twirl> .. it's always either succes or error
16:15:59 <twirl> s/succes/success
16:17:10 <twirl> .. there is a flag for automated redirects
16:17:20 <twirl> YK: Why to have this flag?
16:18:02 <twirl> AvK: just for convenience since most APIs follow redirects
16:18:36 <twirl> TBL: In some situations you want to observe redirects
16:19:10 <twirl> YK: sometimes you want to implement specific reactions on 302, for example
16:19:25 <darobin> darobin has joined #tagmem
16:19:57 <twirl> YK: flags make things complicated
16:20:07 <twirl> AvK: It makes sense
16:21:22 <twirl> TBL: is it possible to look at all the fetches?
16:21:41 <twirl> AvK: via performance panel
16:23:24 <twirl> AvK: the reason for having flags is that you don't want to make additional tasks until you get result
16:23:39 <twirl> .. and there is some generic setup as well
16:24:59 <twirl> .. there are may be 30 or so algorithms to implement all possible combinations
16:25:53 <annevk> http://url.spec.whatwg.org/
16:26:22 <twirl> Topic: URLs
16:26:42 <twirl> AvK: three tasks there: parsing URLs, tackling DNS
16:26:59 <twirl> .. define an API for URLs to do new URLs
16:27:19 <twirl> .. to provide base for anchor elements, etc
16:28:22 <twirl> .. in particular for query strings and x-www-form-urlencoded
16:30:05 <twirl> .. but convincing browsers to change url parsing is hard
16:30:50 <twirl> .. API implemented by geck and chrome, search params implemented by gecko
16:35:39 <Zakim> Zakim has left #tagmem
16:37:50 <Zakim> Zakim has joined #tagmem
16:41:56 <dka> Thanks, Yves for joining us!
16:46:40 <dka> RESOLUTION: thanks to both Anne and Henry for their service to the TAG.
16:47:26 <dka> dka has joined #tagmem
16:47:36 <dka> Adjourned.
16:47:43 <dka> rrsagent, make minutes
16:47:43 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/09-tagmem-minutes.html dka