Technical Architecture Group Teleconference -- 09 Jan 2014

<trackbot> Date: 09 January 2014

<dka> Yves We are online on https://opentokrtc.com/w3ctag

<dka> Scribe: Alex

<dka> trackbot, start meeting

<trackbot> Meeting: Technical Architecture Group Teleconference

<trackbot> Date: 09 January 2014

<dka> scribenick: slightlyoff

[ UK train service isn't what it used to be ]

209 response code

209

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

<JeniT> see http://www.w3.org/2001/tag/awwsw/issue57/20120202/#status-code

thanks, JeniT

TBL: it's not arguing over what "representation" means in great detail, but we can just say that there are times when the server doesn't do that (e.g., redirects), and we have many of these situations
... e.g., you should be using that URI instead
... 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"

thanks, ht

TBL: this was used famously in SemWeb stuff where people want to identify objects using URIs with hashes in them
... in this case, the hash used the hash to separate the document from the object
... there are cases where something wants to represent, e.g., a school
... the 303 opens up the possibility that you can redirect to documents that talk about things which don't represent them
... this was a decent compromise except that real systems that dereference URIs now have to pay for an extra round-trip
... 303 was logically sound, but sucked in practice
... 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
... and yesterday we discussed packages (E.g., for CSV or for icons)

<JeniT> we have a draft on this at http://www.w3.org/TR/urls-in-data/

TBL: one possible thing to do is to return a 303 that redirects to a package
... in all of these situations, we have bodies that are RELATED to items, but are not them logically
... 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
... if client software gets a 20x treats it as success if it doesn't understand it
... this enables caches and proxies
... a smart proxy might understand the new status code and start building up a list of related resources
... a dumb proxy would just repeat/passthrough
... in each application, a smarter client can do the right thing...paging, e.g.
... 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.
... the problem is that the W3C folks view working in IETF as a burden that they aren't ready to shoulder

dka: someone needs to write an RFC?

JT: ht and I are on the queue

<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"

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?

[ agreement ]

<Zakim> JeniT, you wanted to highlight why we haven't recommended this previously

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/
... one of the problems that 303 has is that hacking headers and response code is hard for some people (adoption burden)
... the other issue is a question of friendliness; do proxies, etc. actually do the right thing in the face of the new code?
... the fact that we didn't recommend 20x in the past doesn't mean that we shouldn't do this now
... I would view it as the role of the W3C/IETF liason to enable WGs to register these status codes
... I'm not sure that _we_ need to do anything here

(as the TAG)

JeniT: ...that is, unless we want to revisit those previous decisions
... e.g., why are revisiting this now?

TBL: it's sad when we can't make design progress because we feel that server design or configuration is too fixed

[ review of Content-Type difficulities with packaging, e.g. ]

TBL: Yves is an apache committer...we might want to go back into that analysis

<wycats_> Got a cab. Will be there shortly

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

wycats_: no worries

TBL: people who want to publish on servers without .htaccess ahve the ability to just post a lot of files.

JeniT: I'd like to see analysis that clients et. al. do the right thing with 2XX codes they don't understand
... if there are WGs that want this, why don't thye do it?

TBL: they don't have the energy?

JeniT: who has got the energy?

TBL: nobody (proximately), which is why I bring it here
... we have a broader view
... and can leave the architecture cleaner

<Zakim> ht4, you wanted to ask Yves about process

ht: counter argument is "it's too late, HTTPbis is so close to being done that there's no room for this"
... once HTTPbis is done, what's the process for new status codes?

<JeniT> http://tools.ietf.org/id/draft-reschke-http-status-308-07.html

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
... once that document becomes an RFC, it'll be incorporated into the status code repository at IANA
... the requirement is an IETF review

JeniT: does the status code repo exist at IANA? or is it soemthing new?

<JeniT> http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

Yves: I think it exists. It contains HTTP and WebDAV statuses...probably others

thanks, JeniT

JeniT: so the answer is, if you want 209, write an RFC and then it gets put into that repository?

Yves: yep
... if you look at 308, the doc can be pretty small

<JeniT> slightlyoff: wrt 308, was there experience with 308 & intermediaries?

AR: was there experience with intermediaries?

Yves: it will be interpretted as a temporary redirect by proxies that don't understand it 308

ht: why do you think that's the case? why will they do anything at all with 308?

Yves: it's defined in HTTPbis
... similar for 2XX

<timbl> See http://tools.ietf.org/id/draft-reschke-http-status-308-07.html#deployment.considerations

ht: it's in the HTTPbis spec...but most deployed proxies predate it. Is it standard to do this fallback thing?

Yves: this is from 2616 and 2608
... if you don't know the status code, you fallback to the generic version of it

<Zakim> ht3, you wanted to worry about the _principled_ reason for using hashless URIs

<wycats_> can someone give me the tl;dr of what we're discussing?

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
... there are plenty of people who think that serving 200 is reasonable

(e.g., WRT serving RDF w/ 200)

ht: JeniT, Jonathan, and I concluded that there was no basis in the published spec to elide that view...HTTPbis doesn't change that
... we all agreed that we don't want to force agreement about what 200 "means"

<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

[ discussion of history ]

[ it's complicated ]

ht: we can say that it's not clear from the existing specs that "document about X" is a representation of X or not.
... i want the record not to suggest that perf was the only reason
... maybe there's a good argument for 209 if it won't break the web

dka: I'd like us to think more broadly

ht: I'd like this to piggyback on the semantics of 303

TBL: you'll find people who will argue that clients can figure it out in an app-specific way

<Zakim> JeniT, you wanted to ask about the Location field

TBL: many people won't worry about the architecture being crisp

JeniT: just looking at 303, an important thing about it is that it gives you another URL
... it points at another URL
... an important issue for a 209 spec is "where does that other URL come from?"

[background]

JeniT: if 209 is spec'd in terms of 303, where does the other URL come from?

TBL: the "Location:" header

PL: that lets you fill caches

[agreement]

DKA: what's the work that needs to be done? who's going to do it?
... also, do we think there would be pushback?

<Yves> there can be pushback if the story of default behaviour is not the right one

ht: we'd hope the caching would be the same, but I don't know and we'd need to look
... stipulating that we can work thorugh that, the RFC might need not be larger than the 308 RFC

TBL: the security implications are larger, thanks to x-origin fetches

[discussion of content caches across origins]

JeniT: e.g., you're filling a cache in lieu of another URL/fetch

ht: right, so there's no reason to suppose I'm not lying

[discussion of Location header]

AR: why would it be allowed to front for another origin?

TBL: in practice, you'd go to dbpedia.org/resources/paris, and it gives you a 303 to some other place (perhaps very intricate)

AR: ISTM that a browser should ignore 209s under this idea...
... if evil.com can claim it's serving content for good.com (while you're on good.com), that's pretty nasty

<ht> Content-location header: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.1.4.2

JeniT: a new client that understands 209 and understands the different base URL will behave differently to a client that only understands 200

dka: does this mean it's not useful on the web?

AR: you need more restrictions; e.g., you need to dissalow x-origin content

PL: what about signed content? if good.com signs it, who cares where it's hosted?

YK: that's a common use-case

<ht> Location header: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-7.1.2

JeniT: 2 issues: back-compat and security

TBL: back-compat is about base URL

HT: can I bring us back to the header question? (see refs above)
... "Content-Location" appears to be what you want
... the semantics of "content-location" is to say "this is the content", while "Location" says, "it's over there"
... the "Content-Location" does seem to say what you want

[discussion of baseurl]

Yves: there was a case earlier where Content-Location was modifying the BaseURI, everyone ignored it, and it was removed from HTTPbis

TBL: but Content-Location defines the baseuri of the application?

[inaudible]

Responsive Images

<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.

<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. [recorded in http://www.w3.org/2014/01/09-tagmem-minutes.html#action01]

<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].

<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/

[discussion of attestation WRT security relatinship...etag proposed and rescinded]

<timbl> "If Content-Location is included in a 2xx (Successful) response

<timbl> message and its field-value refers to a URI that differs from the

<timbl> effective request URI, then the origin server claims that the URI is

<timbl> an identifier for a different resource corresponding to the enclosed

<timbl> representation. Such a claim can only be trusted if both identifiers

<timbl> share the same resource owner, which cannot be programmatically

<timbl> determined via HTTP."

<timbl> -- http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.1.4.2

<yoav> Slides: http://yoavweiss.github.io/respimg-tag-presentation

YY: [introduction, working in webkit/blink as well as the RICG]
... 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
... it seems like an easy problem, but is harder than it looks
... 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.
... original approach was to serve large images and let clients resize
... RWD became synonymous with slow
... there are tons of savings to be made by resizing images to the device
... retina made things worse. Widened the gap between low-and-high-end devices.
... RICG was foudned 1.5 years ago. We created a use-cases document that described what needs to be done.
... 3 major use-cases: retina images to retina devices (not low-end devices)
... viewport switching: variable width images. SHould be adapted to viewport dimensions
... Doesn't mean that a smaller viewport gets a smaller image
... DPR switching and viewport switching have image dimensions in common, but no quality
... 3rd use-case is Art Direction: takes image adaptation futher. Images that are more relevant to content.
... expanding context with available size; alternative crops
... since the problem is perf, we want to play well with the preloader
... proposed standard solutions are:
... the revised <picture> element + client hints headers
... these can and should work together
... revised <picture> merges 3 previous proposals

<JeniT> http://picture.responsiveimages.org/

YY: new picture uses the old picture's art-direction solution and it adopted the "srcn" proposal
... <source> is used for art direction. srcset indicates DPR/dimensions
... the "sizes" give the ability to hint correct sizes

[ example code ]

(see http://yoavweiss.github.io/respimg-tag-presentation/#/22)

YY: dpr switching in this way is implemented in blink and webkit
... next, art direction (slide: http://yoavweiss.github.io/respimg-tag-presentation/#/23)
... can also work with DPR
... viewport switching
... (example code: http://yoavweiss.github.io/respimg-tag-presentation/#/25)

[questions about what "viewport" means]

<wycats_> http://www.xanthir.com/b4PR0

<wycats_> ^^ Tab Atkins discussing element queries

[discussion about viewports vs element queries]

[css is hard]

TBL: what about iframes?

PL: the viewport is the size of the frame

YK: you don't want to use iframes for all images

[discussion about calculation difficulity]

(http://yoavweiss.github.io/respimg-tag-presentation/#/26)

YY: Tab Atkins is working on a proposal for coverage
... we need things to be calculated before layout
... to cover the srcset syntax in that case, we define resources in terms of width or height

TBL: if I zoom in, does the viewport size increase?

YY: it's a mangifying glass on mobile browsrs.

PL: we're talking about a way in the CSS WG to specify optical zoom

[ discussion of accessibility zoom vs pinch zoom ]

YY: that's the <picture> proposal
... client-hints are an HTTP-based content negotiation solution
... the client declares its capabilities and the server decides what resource to send
... the request headers are: CH-DPR

CH-RW

http://yoavweiss.github.io/respimg-tag-presentation/#/30

YY: client-hints is opt-in only. If sent on all requests can introduce some bloat to HTTP

<Yves> tim, it should.

TBL: opt-in how?

YY: as part of the server-response, the document could set a header or meta switch
... that'd make all sub-resources send client-hints

<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

<Zakim> timbl, you wanted to ask whether the Vary: header will flag this form of conneg

TBL: is the idea that you should be using the Vary: header when hints are available?

YY: this is why each hint is its own header
... we want to enable vary on just one header
... if we had a Key: header, we could gather the hints into a single header, but we don't have that

<timbl> ack

AR: is there an extensibility point, either API or markup?

YY: no, not now
... SW would be able to work with that in an imperative way

AR: yes, on the second-load

twirl: is there anything here about exotic device pixel ratios?

<timbl> (Of course you can embed RDF model metadata in basically any sort of image and in HTML)

twirl: is there upscaling? Things will look bad

<twirl> http://www.quirksmode.org/blog/archives/2012/07/more_about_devi.html

YY: the way it works is that if you have a higher ratio than is offered, you pick the highest
... haven't seen research about 3:5 or 3:4 ration...
... the difference between 1x and 2x is huge
... but beyond that, I don't know

PL: if 1x and 2x are specified, but the actual DPR is 1.5, which one is picked?

YY: the 2x

TBL: I thought the issue was that if you have 1x, 2x, and 4x, and you have a 5x device, which is nicer?

<timbl> TBL: to scale the 4x to 5 or just include the 4x unscaled to get better quality

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
... client hints will let you hit the exact DPR, but not the precise resource width
... this is where (down)scaling comes into play

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
... I was wondering what your perspective is regarding how the work is progressing? is it going more smoothly?

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
... I think a lot of the tension between standards and developers has abated somewhat

DKA: is the work happening in the RICG with a line to the HTML WG?

YY: currently we're morstly working in the CG around the GitHub repo

<Zakim> dka, you wanted to ask about the current logistics and status of the work

YY: it's possible that some people aren't members of the CG but are still involved
... we have some threads on the WHATWG lists, but we're mostly trying to get feedback on the spec from vendors and iterating

DKA: is there anything for the TAG to review or is there a need for formal comment?

annevk: the whole thing seems messy...but abarth and maciej are looking at it which seems fine for me
... I wondered if there was a way to figure out the primitives
... but you need to be able to hook into the prefetch/prescan

AR: [general discussion of the architecture of the client and how running code on the parser would need to look...many constraints]

PL: I'm concerned with how this composes with progressive image formats

AR: we don't have any way to address these sub-images which are at diferent resolutions

they don't have URLs

YY: this is an area I've explored...the problem is the fetch mechanism
... we don't have an efficient way for the browser to indicate "I've got enough"
... we will need to always send 1 extra RTT's worth of data
... we should look into this in the future
... the Responsive Image Container prototype is in that spirity
... it enables the browser to have header-based information to help the browser choose what to download
... I experimented with progressive-JPEG, but the layers are limited
... e.g., you can't have a very small thumbnail expanded to a very large image
... the middle and high-quality images were constrained by the format

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?

PL: wavelet formats don't have that problem

AR: what formats are wavelet based?

<twirl> jpeg2000

twirl: JPEG-2000

YY: it had plenty of adoption time and failed

<twirl> or jp2 sometimes

YY: JPEG-2000 is in the same area as JPEG with efficiency, and WebP, JPEG-XR, etc. are much better
... also, patents

break

<JeniT> http://mobile.smashingmagazine.com/2013/09/24/responsive-image-container/

<annevk> timbl: ht: https://bugzilla.mozilla.org/show_bug.cgi?id=238654

<ht> http://www.ltg.ed.ac.uk/~ht/drm.html

Intro to technical background for that which shall not be named

ht: lots of pointers and links in the document, will be in the TAG wiki space shortly
... started as email discussion, etc.
... adding DRM to HTML5 comes in 2 parts: EME, which adds extensions to <video> and the CDM, which adds a key system and provider
... there's an important caveat: CDM is not required for spec compliance
... it's possible for there to be a no-op provider
... platform owners who provide CDMs seem unlikely to provide Open Source implementation or provide plugin support
... this division of labor is similar to the way the <object> tag works today
... one summary argument is "we're not doing that, we're just giving you EME, just as we added the <object> tag"
... a counter argument is "how can you integrate something like this into Linux?"
... DRM extends all the way to displays, not just HDMI

TBL: HDMI is broken
... so what you send to HDMI is breakable by default
... and it's hairy...legal consequences

[discussion of ChromeOS as existence proof for CDM + Linux]

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
... the <object> tag argument isn't a technical one, but it's useful to get a sense for the argument
... TBL replied "can we imagine an EME system that's usable by anyone as a publisher?"
... hsivonen responded (see slides)

[pause to read]

<dka> AR: [speaking on ChromeOS's implementation] in verified boot mode there is a crypto device on the board which verifies your boot

<dka> ... same crypto that is used for a chain of drivers and software for enforcing DRM ...

<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 ...

<dka> ... every chromeOS device has one of these ...

<dka> AR: EME plugs into the widevine CDM - provides the CDM - runs on windows, android, macos.... it's part of chrome.

(but not chromium)

<dka> AR: does not require verified boot. verified boot is how you get to a locked down world...

<dka> tbl: some are worried that verified boot makes it possible for a world in which all hardware is out of users' control...

<dka> AR: ChromeOS is a linux - but [is more locked down] than linux.

thanks dka

dka: happy to scribe

<scribe> scribenick: slightlyoff

twirl: I'd like to emphasize that entire countries will become ghettos

ht: no CDM acceptable to the providers will be available to you

YK: can you watch Netflix now?
... how does it change anything?

(answer: Netflix isn't in Russia)

<ht> http://www.ltg.ed.ac.uk/~ht/drm.html

AR: [UK/US example]

YK: will this change the status quo?

twirl: there are lots of people who use US credit cards and itunes gift certificates to abritrage around this already...

YK: wait...but itunes could do geolocation checks today? what's different?

TBL: is it ip geolocation or the DRM?
... we haven't discussed what I'd like to: can we make different versions?
... can we sandbox the EME system so that it doesn't have access to many things?
... suppose we make it illegal for a DRM system to access your location

[back to box diagram]

TBL: it doesn't show the flow of keys

YK: we should look at Unity...not think about Flash, per sae

(in response to Annevk noting that there aren't many Open Source plugins)

<Zakim> timbl, you wanted to mention different levels

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

<wycats_> I cannot imagine any regulatory changes that would be sensitive to the nuances in this area

TBL: can we have a CDM that anyone can negotiate with?

e.g., a system that won't refuse to play any content that wants to collaborate with it in an open way

(private key is defended, but business relationship isn't)

YK: so who would build this

HT: for Tim's vision to be true, we need CDMs to be widely deployed/pluggable, and browsers are moving in the other direction

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.

[discussion about what content is available today]

DKA: imagine a Finnish company wants to build their own videos and their own CDM...how do we enable that?
... the implication is that it's not like a plugin system because you can't add other things....

YK: WinRT, ChromeOS, iOS...

TBL/YK: [discussion of the ability to add new things in the face of verified boot]

TBL: lets imagine a single freely deployed plugin where the server is freely available

YK: My mind is changed by ht's presentation
... I was deeply opposed, but I don't understand what new harm that defining a subset of our plugin capability will do

PL: what if we were to define CDMs in a way such that they were able to be implemented in JS?

AR: [background on Pepper as it was brought up]

TBL: the future is much bigger

PL: maybe we throw out some of the capabilities if we need to

[Web Crypto mentioned]

annevk: but NPAPI is a standard...

(spec, sorry)

[discussion about implementing a CDM in JS]

AVK: notes that Mozilla presented sandboxing to the WG and it was rejected

[thanks to HT for his detailed technical contribution]

thanks plinss

<dka> ACTION: Jeni to start a write-up on this EME discussion. [recorded in http://www.w3.org/2014/01/09-tagmem-minutes.html#action02]

<trackbot> Created ACTION-852 - Start a write-up on this eme discussion. [on Jeni Tennison - due 2014-01-16].

<twirl> ScribeNick: twirl

<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

<slightlyoff> [discussion of layering regarding Responsive Images]

<dka> ACTION: Yehuda to start a write-up on architectural / layering considerations on responsive images. [recorded in http://www.w3.org/2014/01/09-tagmem-minutes.html#action03]

<trackbot> Created ACTION-853 - Start a write-up on architectural / layering considerations on responsive images. [on Yehuda Katz - due 2014-01-16].

<dka> action-853?

<trackbot> action-853 -- Yehuda Katz to Start a write-up on architectural / layering considerations on responsive images. -- due 2014-01-16 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/853

<dka> scribe: sergey

<dka> Scribenick: twirl

<dka> http://adactio.com/journal/6629/

DKA: We don't have a document for design principles and the layering

Design Principles

YK: It's time to write down some stuff
... High-level APIs should be defined in terms of low-level APIs
... people have questions about it and we should answer them

<annevk> JeniT: internet did my job, http://storify.com/jorabin/meet-the-tag-2

DKA: Is this the same is API Design Guide?

YK: No, Guide is more concrete

JT: Who is target audience? API makers?

<dka> ACTION: Yehuda to start working on a design principles write-up on "layering" - an explainer document and FAQ / examples on the architectural principles. [recorded in http://www.w3.org/2014/01/09-tagmem-minutes.html#action04]

<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].

YK: No, that's an explanation of principles addressed to everyone

Promises

<JeniT> brucel's writeup of meet the TAG: http://www.brucelawson.co.uk/2014/i-met-the-tag-2/

[ AR and YK explain the history of question ]

AR: TC39 has a consensus on Promises

<wycats_> had*

AR: there are some objections from Domenic and from developers
... in my opinion October draft has several regressions

[ general disagreement ]

[ discussion on whether TC39 would ship smth that is not subclassable ]

[ discussion whether browsers should ship that feature independently ]

AR: I have some fears on progress of Streams and other features wrt Promises disagreements

<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

<slightlyoff> ht: what am I looking at here?

<slightlyoff> oh, great, thanks

AR: I think we found stable design
... Working groups may use it

[ discussion on Streams vs Promises in video API ]

AR: many people care about possible memory leaks with Promises and Streams
... we should probably have promises-for-overall-operations

DKA: should we have a special guide?

<dka> action-834?

<trackbot> action-834 -- Сергей / Sergey Константинов / Konstantinov to Start fleshing out an api review document -- due 2014-01-06 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/834

<dka> https://github.com/w3ctag/api-design-guide/blob/master/API%20Design%20Guide.md

<wycats_> incidentally, async functions in ES7 may moot the biggest areas of disagreement in Promises

<dka> https://github.com/w3ctag/promises-spec-text

<annevk> https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md

<annevk> ^^ is the text wycats_ dka

<dka> [...notionally putting the action on one of our potential new TAG members on putting text into this document...]

<plinss> rrsagent. pointer?

Push

https://dvcs.w3.org/hg/push/raw-file/tip/index.html

https://github.com/w3ctag/spec-reviews/tree/master/2013/08

<Bryan> What's the bridge code

<dka> Sergey: at our last teleconf we outlined some questions to be considered...

https://github.com/w3ctag/spec-reviews/blob/master/2013/08/Push%20API.md

<dka> Sergey: we should consider these open question ....

<dka> Sergey: we need to consider the implementations...

<dka> Bryan: pointers to implementations of underlying protocol?

<dka> Sergey: yes.

<dka> ... we should refer to the underlying protocol of the spec.

<dka> Anne: it needs to be clear how we implement the entire feature. Both API and protocol.

<dka> Bryan: by protocol you mean the wire protocol or between server and client?

<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.

<dka> Bryan: we refer to browser server as the push server.

<dka> Anne: you need to standardize what goes between the push server and the 3rd party server. And that is not done.

<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.

<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.

<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.

<dka> AR: Does it need to be part of the spec?

<dka> Anne: no but it needs to be part of the feature..

<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.

<dka> Sergey: it doesn't specify what to do next.

<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...

<dka> DKA: Would specifying a northbound protocol mean it would be mandatory?

<dka> Bryan: no.

<dka> Anne: I think the API hands out an endpoint - a url - that presumes something about how you're going to communicate.

<dka> Byran: yes - there is an assumption [that it is a URL].

<dka> Bryan: generally yes this will be http - that is assumed - although there could be other options.

<dka> Bryan: exactly what that interface is will have to be derived from that URI that you get.

<dka> Anne: if you don't standardize that how will people use this feature?

<dka> Tim: question is - if it's not standardized and you get multiple implementations how do you get interop?

<dka> Bryan: Feature is implemented in a number of propriety ways - and you have services such as Urban Airship that normalize...

<dka> AR: I think this is inappropriate -

<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.

<dka> Bryan: suggest it would be a separate spec.

<dka> Bryan: I would like to have as part of the data the app gets back from the browser a description of the system.

<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...

<dka> Bryan: we do not have dynamic discovery of services today...

<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.

<dka> Tim: In the SPARQL context there has been push this - defining "follow your nose".

<dka> AR: That's an uncommon property.

<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 ...

<dka> Tim: you need back channel information at the moment.

<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.

<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....

<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

<dka> AR: there are existing services we are the middleman for ...

<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.

<dka> YK: [on service worker]

<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.

<dka> Bryan: yes. I agree. Would be helpful to have guidance on that.

<dka> Bryan: i will draw up a straw man proposal and work with you.

<JeniT> [discussion of whether it's necessary to have an interoperable network protocol]

<dka> [some disagreement on how important / vital specifying the network (northbound) protocol]

<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.

<timbl> not in the same spec

<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

<wycats_> not any actual spec work

<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.

<wycats_> sounds good

<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.

<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..

ht: I've been on the TAG for a long time
... One observation/suggestion: it's great that TAG is shifting to cover new APIs
... but I'm not convinced that's a right thing to do
... (thouh this work, of course, should be done)
... two things were always historically in center of TAG's interesting: accessibility and i18n
... and I'd like to concentrate on my work

<dka> ht: we need a new model for the Web - TAG is one of the few bodies who could do that.

<dka> ht: I have been working on something: "just use http:" - a few drafts have been written but not published.

<dka> ht: is http: wedded to HTTP protocol? Yes in principle these are independent...

<dka> ... but I think actually we need to decouple naming from the hint of the protocol that is still there.

<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.

<dka> ... The introduction to the http spec should be written differently [in the face of today's web].

<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...

<dka> ... that it has survived and grown to what it is is astonishing ....

<slightlyoff> (unrelated to anything, group photo: http://www.flickr.com/photos/slightlyoff/11856406496/)

Fetch

<dka> http://fetch.spec.whatwg.org

AvK: between APIs endpoints and resources there is fetch
... Fetch defines how does it works
... For HTTP it defines how protocols works
... Fetch takes request object and returns response object
... which are HTTP response and request
... you can read headers, e.g. content-type header
... for file it's up to implementation
... same for FTP
... XHR constructs a request object and passes to fetch
... fetch returns response object
... Fetch queues tasks to network queue
... 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
... Response object may be a NetworkError
... There is one-to-one relationship between fetch and APIs
... Its up to c++ level how to implement that

TBL: Is it possible to get more than one answer?

AvK: No, you can't
... it's always either success or error
... there is a flag for automated redirects

YK: Why to have this flag?

AvK: just for convenience since most APIs follow redirects

TBL: In some situations you want to observe redirects

YK: sometimes you want to implement specific reactions on 302, for example
... flags make things complicated

AvK: It makes sense

TBL: is it possible to look at all the fetches?

AvK: via performance panel
... the reason for having flags is that you don't want to make additional tasks until you get result
... and there is some generic setup as well
... there are may be 30 or so algorithms to implement all possible combinations

<annevk> http://url.spec.whatwg.org/

URLs

AvK: three tasks there: parsing URLs, tackling DNS
... define an API for URLs to do new URLs
... to provide base for anchor elements, etc
... in particular for query strings and x-www-form-urlencoded
... but convincing browsers to change url parsing is hard
... API implemented by geck and chrome, search params implemented by gecko

<dka> Thanks, Yves for joining us!

<dka> RESOLUTION: thanks to both Anne and Henry for their service to the TAG.

<dka> Adjourned.

- DRAFT -

Technical Architecture Group Teleconference

09 Jan 2014

Attendees

Contents