W3C

- DRAFT -

Technical Architecture Group Teleconference

29 May 2013

See also: IRC log

Attendees

Present
Dan Appelquist, Tim Berners-Lee, Marcos Cáceres, Yehuda Katz, Anne van Kesteren, Yves Lafon, Peter Linss, Noah Mendelsohn, Alex Russell, Jeni Tennison, Henry S. Thompson
Regrets
Chair
Noah Mendelsohn, Peter Linss, Dan Appelquist
Scribe
Henry S. Thompson, Marcos Cáceres

Contents


<noah> [The 'agenda' is] not [a real] agenda: http://www.w3.org/2001/tag/2013/05/29-agenda.html

<noah> The agenda wiki: http://www.w3.org/wiki/TAG/Planning/May-2013-F2F

Intro

<noah> http://www.w3.org/2001/tag/2013/04/18-minutes

<noah> http://www.w3.org/2001/tag/2013/05/16-minutes

RESOLUTION: http://www.w3.org/2001/tag/2013/04/18-minutes are approved as a correct record of our meeting of 2013-04-18

RESOLUTION: http://www.w3.org/2001/tag/2013/05/16-minutes are approved as a correct record of our meeting of 2013-05-16

NM: I had a meeting with PL and DA last night
... Our goal is to generate momentum, and get some major topics moving
... In principle I'm still chair, for a few days

NM: In practice PL and DA will be running things

NM: We have both the historic 'agenda' page http://www.w3.org/2001/tag/2013/05/29-agenda.html and the Wiki http://www.w3.org/wiki/TAG/Planning/May-2013-F2F -- we'll sort out what we edit as we go along
... I'm very grateful to TBL for giving me the opportunity to serve as chair for the last 4 years, and a member before that, but I'm also confident that this is a good time to hand over

DA: The TAG is changing now, reflecting a change in the Web community
... More of a leadership role is being called for, not exclusively, but an essential part of the conversation
... The new membership of the TAG is part of that
... Our challenge is to take this injection of energy and use it to generate momentum around the topics we choose to take forward
... We need to use the next 3 days to propel us

PL: I'd like to identify some short-term demonstrable impact

YK: Myself, AR and AvK have been getting used to how the TAG works, and I think we're ready now to start getting work done

DA: So, next step is to work on the Agenda, via the wiki

HST: Logistics?

AvK: Lunch is sometime between 12 and 1...

DA: Thursday evening at 1830 we have 60 web devs coming to give us their . . . input

NM: Structure?

DA: It's a reception, start by introducing ourselves, then mingle

AvK: We should have an intro about what we do

DA: Yes, but the point is not for us to talk to them, but for us to listen at them
... At 2100 we have dinner nearby
... On Friday, we'll aim to wrap by 1600

Agenda

NM: We do need some time to discuss next (2?) f2f dates/locations
... 1st afternoon is often good for that
... We have maybe one set of dates in place in October
... and nothing after that

YK: We should put meta-topics early, so we don't keep circling back to them
... AR and I have some suggestions

TBL: I sent some suggestions about Futures

YK: Yes, and we should discuss that topic -- my suggestion was to get the strategic discussion at least started first

[wiki -> whiteboard agenda negotiation]

NM: Responsive?

DA: Responsive design

YK: E.g. reacting to orientation change of the client device

DA: Goals and TAG operations are not the same
... Whiteboard is a tentative plan for the Agenda

[whiteboard will be captured and posted]

<noah> As of approximately 11:30 AM Wed. at http://www.w3.org/2001/tag/2013/05/WhiteboardAgenda1130Wed.jpg

Whiteboard photo with TAG agenda

Goals of the TAG

YK: We've cleared our plate a bit over the last few months, which is good. New members were asked to wait a bit before driving forward, and we've done this

YK: We'd like to broaden 'architecture' to include the architecture of the platform
... We'd like the TAG to take this on: help WGs coalesce around a coherent approach to APIs
... Help them to coordinate
... This means encouraging WGs to present new stuff to us, and move the TAG to the forefront of managing the overall architecture of the platform

MC: We can't and shouldn't try to compel WGs

YK: Indeed, but it is our job to seek coherence

NM: That's what we're chartered to do, but we have no enforcement powers, and it hasn't always worked

YK: Past failures, yes, but let's look to the future

NM: It extends back past HTML5. . .

AR: I've spending a lot of time on this (API coherence) in my day job
... There's a real need, on the part of people putting individual specs forward
... They're not looking for an "us vs. them" confrontation, so if we come with the right kind of helpful suggestions, we can earn a responsive hearing

<wycats_> I don't think we can do this on an as-noticed basis

<wycats_> we need to take on the responsibility of being aware of the platform's progress and proactively discovering overlapping and conflicting architectures

AR: Examples: Web Midi, Web Crypto, Web RTC -- all of these have defined separate but incompatible callback styles

TBL: Patterns the same?

AvK: Similar problems, but arbitrary design differences in response
... Local perspective doesn't motivate generic solutions

TBL: Not just a matter of renaming/reordering parameters?

AR: No, subtle semantic differences

AvK: Inventing new primitives independently
... We now have Futures, but a bit too late

TBL: Doesn't this require lots of backwards changes?

YK: In many cases the changes are pretty easy: replace "return void" as last arg't to "return [future]"

AR: And backporting gives WGs something to do

TBL: Cost?

AR: GC -- Futures take storage from the heap

DA: Up-level: We have the opportunity to influence other groups, from a position of "we're here to help"
... We need to map out which groups/individuals will be most receptive, so we can quickly demonstrate TAG value

<wycats_> DA, Agreed. We already have a level of success, but the TAG is not getting credit. By taking on the responsibility explicitly, we can associate the wins with TAG (things like futures)

AR: I've seen different levels of cooperativeness -- I meet different levels of engagement with the proposition "We all have responsibility for the commons", but I haven't failed yet

<wycats_> "structured engagement" -> I like that term

AR: We're hoping for a substantially changed new version of IndexDB, for instance
... By and large people are trying to do the right thing, we need to make it easier for them

DA: The social construct of 'the commons' is a very valuable hook to hang this all on. Also, the idea of involving TAG work with our day jobs is an important one to keep our eyes on

AR: Specific issues: Futures/Promises; Streams (we need this, it's a trainwreck at the moment)
... We need a process for Streams in the same way we got Futures done

TBL: Futures are done?

AR: Short answer: yes

YK: TC39 is more-or-less agreed

TBL: Unresolved issues?

AvK: There were, but they have been resolved

TBL: Microsoft happy?

YK: Their rep. has signed off, yes

<Zakim> wycats_, you wanted to discuss the related TC39 process

YK: My perspective is informed by my TC39 experience
... They don't meet all that often, they can't do the technical work
... They manage the 'complexity budget' of the language
... And focussing on that is what TC39 does best, leaving the detailed technical work to small groups
... And that's v. parallel to the TAG situation

TBL: Yes, that's what we're chartered to do

YK: So "come to us", not for approval, but because we have something recognizable to offer them: our higher-level perspective on the platform
... "You (or any WG) are welcome to come and present for 30 minutes, and we'll try to help"

TBL: So, analogous to TC39, make sure that everybody understands the direction e.g. Futures are going, so that WGs are not tempted to say "They're behind us, we can't wait" -- in our role as glue, the TAG can re-assure people that they can and should switch
... Even giving tutorials at TPAC...

AR: We need some kind of calendar or temperature chart, so we know what's nearing the point where we need to get involved

DA: We can't change the W3C process on our own

JT: Being more aware of what W3C as a whole is working on, and the state of the various WGs

YK: You can see all the drafts, and sort by status, on the TR page
... it's hard to use, but it's all there

<annevk> wycats_, raw data is http://www.w3.org/2002/01/tr-automation/tr.rdf I think

<annevk> wycats_, maybe http://www.w3.org/TR/tr.xml

<timbl> wycats_, FTR the TR page data is in http://www.w3.org/2002/01/tr-automation/tr.rdf

YL: WebApps dashboard is a possible model: http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications

NM: Sometimes that's too late -- charter proposals are sometimes the point you need to catch: see e.g. SOAP

HST: It's an 80/20 thing, we can do better than we are doing now, without assuming we will get everything

<timbl> https://www.ietf.org/mailman/listinfo/new-work

<timbl> ooops new-work is not public

YK: Standing agenda item for New Charters?

DA: YL, can you help populate that agenda item?

YL: Can do: I'll take a standing action item:

ACTION Yves to bring new W3C initiatives to TAG's attention, open-ended, due 2015-12-31

<trackbot> Created ACTION-802 - Bring new W3C initiatives to TAG's attention, open-ended, due 2015-12-31 [on Yves Lafon - due 2013-06-05].

NM: Need this beyond W3C. Anyone attending IETF regularly?

JT: Larry Masinter was, no-one now

DA: Other opportunities for quick engagement: Web midi, Web RTC, Sysapps, Webapps
... Webapps is big

YK: Let them roll it up [YK: Scribe lost context here, can't make sense of this -- can you?]

ACTION Dan to talk with Art Barstow and/or Charles MaCathie-Nevile to find out who from Webapps might come to talk to us

<trackbot> Created ACTION-803 - Talk with Art Barstow and/or Charles MaCathie-Nevile to find out who from Webapps might come to talk to us [on Daniel Appelquist - due 2013-06-05].

MC: I will present for Sysapps
... I could use the Sysapps slot

NM: Do this kind of thing at TPAC, with the whole WG?

HST: That's the second step, surely

NM: That has often done a lot to build bridges -- get recognition of who we are and what we can do

<wycats_> http://www.w3.org/TR/tr.xml seems to return something

DA: We should indeed discuss what we do at TPAC, in general
... Two TPACs a year?

TBL: IETF meet 3 times a year

DA: Web audio?

MC: I can reach out to them, but they are pretty resistent to change

YL: The chair is in London. . .

AR: It has a strong core functionality, but the API has some idiosyncratic properties

DA: Invite the chair for Friday?

AR: Great topic for telcon

ACTION Yves to invite Olivier Theroux to lunch on Friday due 2013-05-29

<trackbot> Set ACTION-804 Invite Olivier Theroux to lunch on Friday due 2013-05-29 due date to 2013-05-30.

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

ACTION Anne to find a representative of Web RTC to talk to the TAG

<trackbot> Created ACTION-805 - Find a representative of Web RTC to talk to the TAG [on Anne van Kesteren - due 2013-06-05].

YK: I'll undertake to keep TC39 information flowing to the TAG

JT: There is new work on SemWeb tabular data on the web, next step is CSV, Phil Archer and Ivan Herman are involved

ACTION Jeni to invite Phil Archer to talk to the TAG

<trackbot> Created ACTION-806 - Invite Phil Archer to talk to the TAG [on Jeni Tennison - due 2013-06-05].

HST: That list is long enough -- if we want to have early impact, we will need to narrow that down as soon as we've had a few presentations/visitors

ACTION Dan to invite someone from Responsive Images CG to talk to the TAG

<trackbot> Created ACTION-807 - Invite someone from Responsive Images CG to talk to the TAG [on Daniel Appelquist - due 2013-06-05].

YK: Should we look at the general issue of relations with CGs?

DA: They are so diverse. . .I don't think a blanket approach is possible

MC: What are the concrete action items?

HST: Actions for contacts to WGs are in the tracker

YK: I think we're good for now

DA: I'm satisfied for now -- we need to get to having concrete progress

JT: So we have a plan for getting information, and then maybe we feed back into those WGs, maybe by email. But what about any deliverables? Are we still looking to write anything?

YK: We've talked about an API Design Guide

AR: Futures could be a deliverable

DA: Would we write something which points to other docs, saying: use this?

AR: More general: What does it mean to design a good Web API: declarative, structured, etc.
... Sort of a "So you're designing your first API -- here's what you need to know"

YK: Separate legacy from new stuff, so that legacy doesn't get copied on

AR: New specs keep getting written which indiscrimately use too much of WebIDL

YK: We need "WebIDL, the good bits"

TBL: E.g.?

AR: Objects w/o constructors, overloaded methods based on type alone, not arity [Scribe not sure about this item]

TBL: Doesn't JQuery handle all that

YK: Yes, but at huge cost in some cases

MC: A lot of the problems stem from people copying existing WebIDL w/o understanding it

AR: It's not that the IDL is necessarily weird, it's the relationship between WebIDL and JS which leads to great weirdness

TBL: So in principle it would be good to design just for JS. . .

MC: It leads to one VM inside another, with JS at both ends, which is just . . . confusing
... Any reason why we shouldn't do a Futures API spec?

HST: It's unprecedented. YK's TC39 model also doesn't suggest that, rather that we need to motivate a WG to do it.

MC: But there isn't a WG for shared APIs which many groups need

AR: We may need to embed someone in an existing WG

DA: We clearly need to identify work items which don't have a home
... Then we might e.g. send a message to ac-forum to the effect "The TAG thinks this item needs a home, what shall we do"

MC: Still we need some stub, say for Navigation Control, where the TAG says: here's a draft requirement, this needs to be taken forward

DA: So should Promises by a finding?

AR: I'm more interested in the overall API Best Practices document, where using Promises would play a part

JT: Is it spec. authors we're aiming at, or web devs?

AR: W3C has little ability to affect web devs, except via specs, so, spec. authors

NM: This is a good example of why 'architecture' is valuable to keep in view
... So either or both communities, but the point we want to push is "there is a benefit/set of trade-offs wrt using composable APIs, and here's how using Promises fits with that"

YK: Not at too high a level

NM: So, no "On Promises" document?

YK: Yes, but with emphasis on concrete Best Practices, not so much on why they are Best
... So that's a separate Note on why you should use Promises
... but not with a cookbook

AR: I will undertake to produce that Note

<wycats_> it makes sense for the best practices docs to link to the architecture notes

YK: I expect the Good Practices document will often come first, with the architecture 'why' note later

JT: Still not sure about the targetting

HST: Both those docs are targetted. . .

YK: . . . at spec authors

AvK: At least some devs want to understand 'why' as well

PL: The guide to WebApps architecture Best Practices is really needed

AR: What did HTML do right, and what did they do wrong
... e.g. don't loose sight of the tree structure

YK: If we write such a guide, it would be obsolete in a year

HST: Now talking about a Primer?

YK: Not us, rather they exist already

HST: So the "Guide to WebApps archictural principles" and the "API Best Practices" mentioned above are two distinct documents
... The API Design Best Practices is aimed at spec. writes, and we are all pretty much clear it should happen

DA: The "Guide to WebApps architectural principles" is for those who want to know why

PL: Two docs, two targets, both docs need both a how and a why, so the main difference is between the audiences: the "API Design Best Practices" is for spec. writers, the "Guide to WebApps architectural principles" is for devs
... Two document spaces

NM: The architectural principles doc is for both communities

DA: When we had the #URI discussion, JT produced a great blog post, which evolved and morphed into a finding
... We could take AR's blog post on Web Components down a similar route

NM: First WD is a good route too

PL: Lets get back from mechanism to substance

YK: The key point is to back up design choices which depend on architectural goals with documents which articulate the architectural background

<noah> What I was specifically suggesting was: if you think Alex's blog post is a good start, you could start by cloning at is a TAG blog post to get it in W3C space, or use it as the starting point for a first draft. The advantage of the latter is much more visibility, and the probability that there will be undated as well as dated URIs the people can use to watch the ideas evolve.

<slightlyoff> noah, and I'm totally good with that. But that stuff probably needs heavy editing = )

<slightlyoff> noah, my writing isn't...erm...good

<noah> Alex, while you were out of the room it was Dan A who suggested stealing your blog entry and putting in the TAG block. I was saying: "yes to stealing it", if you're willing, but "suspicious that TAG blog may not be best W3C form in which to put it in"

TC39

YK: We all talked about TC39 in our platform when we ran for the TAG
... W3C and TC39 complain about each other

YK: TC39 operates almost as if it were a W3C WG, with responsibility for Javascript
... So AR and I have been trying to facilitate coordination as if that were true

AR: TC39 don't understand W3C process, many of them come from the Programming Languages community, which doesn't have a precedent for understanding W3C
... They don't yet feel included

AR: TC39 is evolving---it has shifted focus from just language fixes to a recognition of its place in devs' lives

YK: Many new TC39 members are designers/devs (as opposed, at least a bit, to Prog Lang people)

AR: TC39<->DOM is a particular challenge, in that TC39 feels that the DOM unilaterally create new semantics, whereas the DOM WG feels that TC39 change things that affect the DOM unilaterally

NM: So there's a coordinating role that the TAG could/should play?

YK: Yes: encourage DOM to recognise that they sit on top of JS, not independent of it

NM: Should we write something?

YK: AvK is coming to next TC39 meeting

NM: Do we need to prepare the ground by going to the DOM WG sooner rather than later?

HST: We do introductions and then get out of the way

DA: We could invite a TC39 rep to a TAG call, or organize a workshop

NM: You get them together too early, they just resume their ongoing battles

DA: So AR and AvK will explore ways of engage with the W3C groups

HST: There is no DOM WG, right?

AvK: WebApps actually own the DOM now

<annevk> (Part of the confusion might be that some people refer to DOM as all APIs and some mean DOM as just Nodes and such.)

YK: We certainly need to know who the sub-group owner is within WebApps

YL: WebApps is a meta-group, the chairs know at any point who is working on what

<annevk> wycats_, http://www.w3.org/2008/webapps/wiki/PubStatus

AvK: For some areas under WebApps, a lot of the work is happening at WhatWG, and then being imported into W3C, which means that the PubStatus page is not the end of the story

DA: If technical work is going on on e.g. the DOM, wherever it's going on, and there's a coordination problem with TC39, we (the TAG) should help
... Who's the guy on the WhatWG side?

AvK: Me

DA: Who's the guy onn the W3C side?

AvK: Not me

DA: Should we try to meet w. TC39 at TPAC?

AvK: It's in China

YK: We can invite them. . .

AvK: It didn't work well last time

AR: We need to have a very concrete activity plan for them

HST: We need to make as good as we can on the "TC39 is effectively a WG" story

DA: Right, so ask JJ to invite TC39 as full partipants at TPAC

YK: TC39 has 15 active members

TBL: We should check for scheduling conflicts, and membership issues
... Don't try to solve the whole thing, get a partial picture and then take it to JJ

ACTION Dan to pull together a plan for TC39 participation at TPAC in November in China

<trackbot> Created ACTION-808 - Pull together a plan for TC39 participation at TPAC in November in China [on Daniel Appelquist - due 2013-06-05].

<timbl> [2013/5/29 10:07:35] Tim Berners-Lee: http://www.w3.org/2013/11/TPAC/

<timbl> [2013/5/29 10:07:45] Tim Berners-Lee: SHENZHEN, CHINA 11-15 NOVEMBER 2013

trackbot, close ACTION-804

<trackbot> Closed ACTION-804 Invite Olivier Theroux to lunch on Friday due 2013-05-29.

[Adjourned for lunch until 1330]

Layering

yehuda: it's the meta discussion as to why I ran. I've been writting up a document about this. The way the standards process seems to work is driven by use cases. From this they create an API - it's usually extremely high or low level. It gets implemented - done. But then the use cases come up again, and people point to the API
... so, if we look at some thing like appcache [history of app cache and how it was made by the WHATWG and friends].

slightlyoff: [gives overview of a similar situation in with regards to google gears]. With the lessons of Google gears, appcache was born...

<slightlyoff> marcosc, well, just saying that Google motivated both the Gears and the AppCache work

<slightlyoff> marcosc, and Aaron Boodman et. al. were working on other things (notably Chrome) by the time AppCache was being built

yehuda: so, appcache is "scenario solving" - it introduces new capabilities, but introduces new problems/limitations in the platform. So, then developers tried to use it for offline apps, but it didn't work. So I went to look at the imperative API to try to fix the issues.

dan: as a side bar, Andrew Betts has a lot of feedback with regards to app cache from Financial Times' experience with that appcache.

yehuda: what I am not suggesting is that you do imperative + declarative side of an API and have them match 1 to 1. What I'm saying is that there should be a lower level API (primitive) from which you build the declarative and imperative from. This can be a win for security as you deal with the security issues at a lower/one level. So, given this, you could build XHR, CSP, etc. anything that uses, for example, the network, you use the lower lev

el network API (e.g., navigation controller).

yehuda: So, this way, you can basically use navigation controller to impose various security policies or experiment with different solution that then feedback to the platform.

noah: is this a plugin?

yehuda: no, this is not a plugin.

noah: so, you want to be careful with this. As you are downloading a hook that can reroute network requests.

alex: so, this is my design - will explain: every page is constructed with a url. Controllers are registered against some part of the URL space (e.g., http://example.com/*). So, when the page is loaded in this URL space, install/use this controller.
... so, this uses a "shared working" (bit of code that is securely shared across documents in the same domain)

noah: so, how is the security checking done?
... so, that code gets cached, and the whole thing fires itself up and runs.

<dka_> trackbot, start meeting

<trackbot> Meeting: Technical Architecture Group Teleconference

<trackbot> Date: 29 May 2013

ht: there is some kind of precedence order here.

alex: last one wins

dan: you mentioned this is being implemented? by who?

alex: a bit of work is being done by network controller. I have a team, we are doing it. \

yehuda: Let say you have an image tag. Right now, it's opaque how an image ends up on the screen, etc. The overall goal that Alex and I are working on is to expose some of those things imperatively - so that people can fix bug in the platform.
... and potentially extend the platform
... which can then feedback into the standards process

noah: the TAG spent a long time looking at distributed extensibility. This seems to go in the opposite direction.

yehuda: in my view there is a crisis of imperative right now (to extend the platform right now, you need to write a ton of JS code - potentially reimplementing parts of the platform).

alex: here is real example: currently, Firefox does not support WebM. So there is work that coverts code to asm.js to in order to do fast image conversion.

ht: the point is that you can write a scoped handler

noah: it's scoped to the place where the thing came from. That is, if I got this from website X, and you can scope it to the site (e.g., with processing images).

yehuda: it's not scary to do that, but it could be scary if people write their own PNG handlers
... once you these hooks, you can imagine users making their own solutions as showing us (standards people) what they want in the core platform

plinss: what you are asking from the TAG is to define what these hooks could be.

noah: if you are using markup for this, you could end up with the custom elements and weird markup.

yehuda: the intention is that people change their markup once a solution is standardised

alex: so, to get compat, you might need to use a nesting hack. And that is ok.

yehuda: there is still going to hacks to get around platform limitations. But for components that are standardized, then the browser just handles that.

dan: what about prollyfills? wont the web become of a bunch of polly/prollyfills?

alex: so, the point of polyfills is to help solve a particular problem or overcome limitations - to give users are feature they don't have.

yehuda: this removes a centralized bottleneck for getting new stuff on the Web.

noah: my intuition about this stuff is that the general direction is good. Being able to use the web's existing extensibility hooks (e.g., mime types) would be good.
... I wonder if it would be worth while going through the platform to see where the extensibility points are
... up to now, this has been sold as a way for some part of the web community to experiment.

yehuda: how do you suggest that someone actually solve this problem?

annevk: so going into this right now doesn't help.
... there is a problem with this, if you do a cross domain request, you will get a tainted response - so you won't be able to access the bytes

<JeniT> sounds to me like that there are two possible types of deliverables for TAG here: 1. guide for spec editors to make sure that they build in extension points and 2. possibly guides for web developers to know when and how to extend and upgrade etc

noah: as Anne says, no one is using the media types.
... so, if say media types is broken, then we should go and fix the broken underlying specs that mandate them in the platform.

timbl: I would be interested to see if you could move from a system that is not well defined to one that is in a secure manner.

alex: our security model right now is "same origin". It would be great if it was some other model.

[fast discussion about different examples/scenarios]

yehuda: I don't think these extensibility points fix fundamental problems on the web, but it doesn't make it worst [...discussion moved to identity and URIs]
... right now, this proposal solves some of the friction in the platform.

annevk: if you wanted to invent new UI widgets, this allows you to create new things to experiment with.

dan: what is the overlap between when you would use this VS when you would use shadow dom?

yehuda: this is a sort of implementation of this proposal
... it makes composition harder

alex: gmail was fighting a losing battle against the depth limit of the dom in FireFox.

[alex explains what the shadow dom is]

[yehuda gives a concrete example of how input types work with shadow dom in browsers]

http://www.w3.org/TR/shadow-dom/

yehuda: you can view it in Chrome's dev tools

alex: the shadow dom does not affect the document's dom
... a few of use worked together on the shadow dom model (referring to http://www.w3.org/TR/shadow-dom/)

yehuda: the point is that we assume that people will want to leave behind their own custom elements instead of using the new standardized ones

timbl: it might be good for the TAG to recommend a registry for custom tags

yehuda: I can see something like Ember doing something like that

alex: we've learned the hard way about accessibility issues
... because they have to send code down the wire, it means they take a huge performance hits which means they sometimes throw away a bunch of stuff (e.g., accessibility)

ht: the basic metric for some company is: how many staff am I going to have to hire to support some feature?

<JeniT> shadow-dom spec doesn't say anything about <element>, I guess it's somewhere else

<JeniT> ah https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

yehuda: we should allow people to make little registries

<annevk> JeniT, yes

noah: there was a time when there were multiple element (image/img), eventually one won

<JeniT> annevk, I thought I saw a primer once

<annevk> JeniT, https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

<annevk> JeniT, I think

yehuda: polymer, from google, will have a lot of stuff that will be very google specific. So it might be ok for them just to use "google-"
... we should consider how to allow people to create things without "-"

<JeniT> annevk, yes that was it

annevk: "x-" is for browsers. It's a user agent or server layer instead of the app layer.

noah: there is a case to be made that pointing to your own implementation changes the game. If timbl then goes an invents his own that uses your "xxx-" tag, then that might not cause an issue. But when people go and search for "xxxx-", then it might be a loss.

alex: it might be an opportunity

noah: I don't believe the damage is zero, because there might be a place for globally unique identifiers for these

timbl: there are two ways this can go: 1. to get stuff into html, 2. it becomes a modular programming system.

[discussion around dependencies, dll hell vs debian dependencies]

dan: I'm interested in getting some action items. How do we move forward with all this great stuff?

<Zakim> JeniT, you wanted to ask what it is the TAG should do

JeniT: this is all excellent. The thing that stands out is being able to go down to a lower level. Not too different form last F2F. What is it that the TAG should be doing on this?
... there are a few deliverables: 1. if we are going to be reviewing specs, then we could look at the potential extensibility points in relation to this. When this is more hashed out, then we could have some guidance for web devs around extensibility - and how do web devs plan to use these extensibility points
... is this what you guys (alex, yehuda) had in mind?

yehuda: yes

alex: yes

plinss: what we don't want is here is a feature and here is the extensibility points for feature X. Instead, we (TAG) want to look at what the lower level primitives are.
... what JeniT is suggesting is that we identify the underlying extensibility points

JeniT: it would be useful in a document to specify through different examples

yehuda: when we notice something like fetch, we should make sure that groups don't redefine things over and over

alex: trying to find the right point at which to target their API (high low level)... this is hard to do.

JeniT: it might be easier to do that if we have some document the describes this

plinss: this also ties in with working with other working groups
... it's our role to provide guidance wrt architecture
... to other groups

dan: so, how does that translate into actions

<slightlyoff> annevk, from me, with love: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/firefox/create_fails.md

<annevk> slightlyoff, why is URL there?

<annevk> slightlyoff, or Text?

<annevk> slightlyoff, or ProcessingInstruction or the others I mentioned earlier?

<scribe> ACTION: yehuda and alex will create an initial draft of high level view/survey and how they relate to system capabilities [recorded in http://www.w3.org/2001/tag/2013/05/29-minutes.html#action01]

<trackbot> Created ACTION-809 - And alex will create an initial draft of high level view/survey and how they relate to system capabilities [on Yehuda Katz - due 2013-06-05].

<JeniT> ah, from previous meeting: https://gist.github.com/wycats/5205250

<slightlyoff> annevk, https://github.com/slightlyoff/ZOMGWebIDL/blob/master/firefox/create.html#L437

<slightlyoff> dka_, lawls.

yehuda: we can't obviously do too many APIs in the time we have, but we could for instance start with the Web audio API and how it might relate to the audio tag

<annevk> slightlyoff, I see, you're using a browser

<annevk> slightlyoff, well yeah, they're broken

<slightlyoff> noah, https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

[BREAK]

<annevk> (although nightlies are getting better)

<slightlyoff> noah, in particular https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#shadow-dom-section

<slightlyoff> annevk, feel free to send me edits to the md file

capability URLs

[JeniT presents slides: http://w3ctag.github.io/presentations/reveal/capability-urls.html]

<slightlyoff> annevk, moved the file: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/create_fails.md

<annevk> slightlyoff, so, I don't think I'm going to go through that thing again and edit it for now

<annevk> slightlyoff, it's useful enough as is

<slightlyoff> oh, you had edited it?

<slightlyoff> annevk, send me your edit

<annevk> no haven't

<annevk> sorry for the confusion, meant to look through it and remove those that are handled by specs

<slightlyoff> oh, OK

<slightlyoff> I can do that

[JeniT presents slides... Web Arch... ]

annevk: I feel like you are conflating a whole bunch of stuff together in this slide

noah: a fair amount is explained in the document

JeniT: I agree, there is more to go into there..

Slide - beyond single page

slide - recommendations

slide - application design

<annevk> So it seems the architecture concern doesn't apply here: http://www.w3.org/TR/webarch/#uri-aliases

<annevk> It talks about network effects, but here you want to keep them secret

JeniT: we should make some recommendations about this (we === tag)

<annevk> So you don't want network effects :)

<noah> It seems to me that capability URIs, by conflating identity with access rights, tend to break one of the main use cases for the Web: I want to provide to you a link to an interesting resource, and the access you have should depend on >your< rights, not mine.

slide - capability URL design

<ht> I note (Yves???) that HTTPbis has removed the only mention I can find of https not being (publicly) cached: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2040

<noah> I think capability systems are really interesting, but I'm suspicious of the merits of tunneling a capability architecture through the Web, which is not inherently capability-oriented.

yehuda: there are not good answers to these problems. I don't know the answer.

JeniT: that's what makes it interesting work

<Yves> ht, as they are not reaching proxies, that's normal

yehuda: I can live with password resets, and emailed URLS... but accessing gists, etc. is not so good.

<ht> Yves, where is that noted? All I see is that the trajectory must be secured from end to end. . .

<noah> From Web arch:

<noah> "It is reasonable to limit access to a resource (for commercial or security reasons, for example), but merely identifying the resource is like referring to a book by title. In exceptional circumstances, people may have agreed to keep titles or URIs confidential (for example, a book author and a publisher may agree to keep the URI of page containing additional material secret until after the

<noah> book is published), otherwise they are free to exchange them."

JeniT: the document may describe the implications
... if you do X, then Y may happen

yehuda: it's a problem that URLs can be leaked when they are supposed to be private

[conversation about issues]

<Zakim> ht, you wanted to talk about actually secure capability URI designs

yehuda: it's a real failing that people can leak the urls

ht: there are strategy to address this issue, but it's complicated.
... I would like to give the ability to one site to write resources to another site - but with rules (e.g., 10 per day, once a month). I.e., you allow a capability without actually acting as the user.

<Yves> ht, see rfc2818 for https

ht: these things exist, but they are complicated.
... it's often a 3 actor situation ... or a trusted 4th party. This stuff is a bit of rocket science right now, but I do suggest that we don't publish anything that doesn't acknowledge existing capability systems.

noah: the ones that I've seen are built on systems similar to unix

[discussion about various types of capability systems]

dan: what we are talking about here is to help people do what they are doing already

alex: is this something that we should encourage them to do?

annevk: we should document the concerns around this

dan: some of the best practices

noah: what are the responsibilities of the user agents? For the web platform, it would be good to clarify what happens when one of these URLs leaks.
... there is an obligation for the TAG to clarify this for user agents, or proxies, to handle this.
... and you need to explain how to do this without for example using a HTTP header or some other solution
... I expect to be able to mail URLs, but there should be some level of protection at the UA level

yehuda: there is certainly a social norm issue of sharing URIs

dan: before we start making recommendations to UAs and proxies, it seems to me that there are some best practices around capability URLs that could be documented.

<ht> Yves, HTTPbis explicitly says it supersedes 2818

<noah> Again, my recommendation was to document the current platform rules: what are the responsibilities, of server, proxy, user agent and other Web code to protect or prevent copying of certain URIS.

<noah> With that in hand, we can consider 1) explaining the pros and cons of capability URIs and maybe 2) recommending mechanisms for controlling such things.

annevk: I still want these things cached (or still be in location bar)

<noah> FWIW, and this will be no news to long-time TAG members, I'm not a fan of trying to tunnel capability capbility :-) through the Web

<ht> Yves, ah, not supersedes, but updates

timbl: capability urls are relatively rare when compared to other urls

ht: I used two yesterday

<ht> Yves, hmm, really not clear what's still normative in 2818 and what's overtaken

<Yves> indeed

timbl: so you are suggesting best practice aimed at web devs, as opposed to UAs and proxies

dan: What existing material is out there that we could build on?

JeniT: there are some links in the slides, which is what I've found through searching

dan: do we know if there are any internal recommendations about capability URLs?

annevk: I suspect not

JeniT: maybe Google has something?

annevk: the links in the presentation are from google guys

alex: Tyler has worked on a bunch of stuff related to this. Teams at Google often have their own thing - but I don't want to misrepresent what they are doing.

dan: JeniT, are you proposing to be an editor of this?

JeniT: yes

annevk: I'm happy to help review stuff

plinss: do you see this as being a note or rec track doc?

JeniT: right now, it's just about writing up stuff... we can decide what to do with it later

plinss: I'm interested in scope
... is all

JeniT: that's all I need

<scribe> ACTION: Jeni to create a first draft of capability document guidelines [recorded in http://www.w3.org/2001/tag/2013/05/29-minutes.html#action02]

<trackbot> Created ACTION-810 - Create a first draft of capability document guidelines [on Jeni Tennison - due 2013-06-05].

alex: do we have consensus if we want to do this?

annevk: we should describe the landscape

dan: one of the early slides said that this contravenes WebArch.. is that something that should be discussed.

timbl: that is one of the least worrying bits

noah: I happen to like this rule... let's chip away at Web Arch
... I think it would be good to enhance web arch with regards to this matter
... either explain don't do that, or explain the trade off

<JeniT> yehuda, there's one thing that people could do, which is have a one-off capability URL that upgrades to a cookie

<JeniT> alex, there's a strong timing component, usually they should be short-lived

<JeniT> yehuda, like you could enter your phone number, and then have to enter a passcode that's been SMSed to you every time you want to access it after that

HTTP Bis

ht: the focus of my interest is in basic arch properties as a whole, but not so much on browsers. But I wanted to tell you a little bit about one of the long running issues. Which is, what URIs are and how they hold the web together (if they do!). RFC2616 is the one being replaced - it is over 10 years old.
... it has been being edited for over 3 years, which is exceptions for the IETF. One of the things the TAG has tried to help with is the arch is in the "identifier" part of the URI. We have pushed the IETF to be clear about URIs.
... this is not because we are architecture astronauts. its because question have arisen about how the URIs are used on the "vanilla web" VS the semantic web
... if there is a difference, then how should those differences be expressed?
... so I've been going through the specs, fairly carefully. To try to see what picture is emerging. If you just read this spec as if you had no background in HTTP/s, what would a reader get out of that?
... if people are interested in this topic, I encourage people to read the intro sections and the email I sent to the TAG member list
... I will send the email to the public list soon
... Roy has added more language about REST.

yehuda: I'm lacking context about REST... i know what it is, but how does it relate to this?

timbl: for me, the arch of the web is the hash... [tim describes how the web work and how the semantic web works in a rapid fire manner]

ht: ... at the end of the day, this only really matters for spec weenies what URIs mean.
... devs are really only interested in operational stuff like status codes, cache control.
... so I wanted to give you an overview of the comments I'm making about the document. But what would be say about URIs if this was up to the TAG?
... what we should say, if we could, the biggest gap from my perspective what is people's behaviour with regards to this technology have to be ... to lead the web to it's full potential? We need to identify who the players are, and what their obligations are with regards to using URIs - i.e., what is the social contract.
... the spec assumes human expectations about how people use URIs
... but there are all sort of assumptions about what people do
... I'm going to send a few comments back to the HTTP bis WG. But is there other stuff I should do?
... one of the things people would like to know, when I get a 200?

annevk: that's it's OK?

[room laughs]

ht: but what does that mean as a social contract?

timbl: but to make this part of the TAG, we need to look at the applicability of this

ht: right now, it's not clear what the semantics are with regards to method

annevk: httpbis can't change the state of the world. But they can try to fix bugs in implementations. But they should just leave the philosophy to a primer or something else

noah: it's good to be clear about the semantic difference between GET, POST, etc.
... it's a bit of a grey area, so you have to be careful about what is defined

[discussion about philosophy behind different GETs]

<JeniT> [annevk's conneg rant]

[discussion about conneg...]

<JeniT> [wycats_'s pro conneg rant]

[...interpretive dance about bags of bits.... ]

dan: we might have a TAG deliverables that updates URLs and URIs and discusses that

ht: I have a working title: "what would it be like to document what is true about URLs?"
... asking the HTTP Bis WG to get rid of philosophising would be counter productive
... what I am reviewing is just a clarifications of HTTP 1.1 - it's a cleanup

<wycats_> I assume you mean 1.1?

<annevk> yes

F2F Planning

13-15 Oct at MIT

noah: 13-15 Oct at MIT, we also identified, week of Jan 06.

[discussion about TPAC, Marcos being booted from the tag, etc. ]

<JeniT> Jan 7-9 in Europe

Polyglot

ht: we've said everything we want to say.

yehuda: I think we reached consensus on this already

ht: is there a link to the discussion?

<JeniT> https://lists.w3.org/Archives/Member/tag/2013Apr/0046.html

ht: the background is that Paul Cotton asked to clarify where we are at

<ht> http://www.w3.org/2001/tag/group/track/actions/791

yehuda: we all agreed that we can all live with the proposed text.

ht: we should consider Larry's feedback

annevk: I don't agree with the change Larry suggests. I think it's wrong

yehuda: I agree.

annevk: it could be clearer

<JeniT> email should s/wether/whether/

annevk: it would be clearer if with xhtml mime type you use xhtml, and with html mime type you use html

ht: if we could capture the above in the proposed text, then that would be great.

<annevk> see also http://html-differences.whatwg.org/#syntax which describes that

<ht> My proposed change "using HTML5 syntax and mediatypes (either HTML syntax and text/html, or XHTML syntax and application/xhtml+xml"

yehuda: in the Web Arch document there is a section that talks about the content-type in normative terms that don't match reality.

<annevk> http://www.w3.org/TR/CSS1/

ht: we can't just change the spec in place

<noah> What change to what spec is being proposed?

<Yves> it's actually a new spec

<ht> http://www.w3.org/2001/tag/webarch/errata.html

<noah> I thought Yehuda said: "Published spec XXX says MUST" which one?

http://www.w3.org/TR/webarch/

yehuda: section 3.3

<annevk> "Agents MUST NOT ignore message metadata without the consent of the user."

noah: the TAG should take a strong line that normative spec should be followed.
... it would be better to get the normative text updated in the appropriate spec

<ht> Stand by for HTTPbis:

<ht> In practice, resource owners do not always properly configure their

<ht> origin server to provide the correct Content-Type for a given

<ht> representation, with the result that some clients will examine a

<ht> payload's content and override the specified type. Clients that do

<ht> so risk drawing incorrect conclusions, which might expose additional

<ht> security risks (e.g., "privilege escalation"). Furthermore, it is

<ht> impossible to determine the sender's intent by examining the data

<ht> format: many data formats match multiple media types that differ only

<ht> in processing semantics. Implementers are encouraged to provide a

<ht> means of disabling such "content sniffing" when it is used.

ht: given the normative text comes from 2616, the appropriate text in Web Arch should be updated when HTTP Bis updates the HTTP 1.1 spec.

<ht> trackbot, Action-791?

<trackbot> ACTION-791 -- Alex Russell to redraft proposed "status" section that TAG is suggesting for Polyglot -- due 2013-04-16 -- OPEN

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

<ht> trackbot, close action-791

<trackbot> Closed ACTION-791 Redraft proposed "status" section that TAG is suggesting for Polyglot.

Dan: so, Polyglot can be closed.

[MEETING ADJOURNED]

Layering

yehuda: it's the meta discussion as to why I ran for the TAG. I've been

writing up a document about this. The way the standards

process seems to work is driven by use cases. From this they

create an API - it's usually extremely high or low level. It

gets implemented - done. But then the use cases come up again,

and people point to the API. so, if we look at some thing like appcache [history of app

cache and how it was made by the WHATWG and friends].

alex: [gives overview of a similar situation with

regards to google gears]. With the lessons of Google gears,

appcache was born...

alex: well, just saying that Google motivated

both the Gears and the AppCache work

alex: marcosc, and Aaron Boodman et. al. were working

on other things (notably Chrome) by the time AppCache was being

built

yehuda: so, appcache is "scenario solving" - it introduces new

capabilities, but introduces new problems/limitations in the

platform. So, then developers tried to use it for offline apps,

but it didn't work. So I went to look at the imperative API to

try to fix the issues.

dan: as a side bar, Andrew Betts has a lot of feedback with

regards to app cache from Financial Times' experience using it.

yehuda: what I am not suggesting is that you do imperative +

declarative side of an API and have them match 1 to 1. What I'm

saying is that there should be a lower level API (primitive)

from which you build the declarative and imperative from. This

can be a win for security as you deal with the security issues

at a lower level. So, given this, you could build XHR, CSP,

etc. anything that uses, for example, the network, you use the

lower level network API (e.g., navigation controller).

yehuda: So, this way, you can basically use navigation

controller to impose various security policies or experiment

with different solutions that then feedback to the platform.

noah: is this a plugin?

yehuda: no, this is not a plugin.

noah: so, you want to be careful with this. As you are

downloading a hook that can reroute network requests.

alex: so, this is my design - will explain: every page is

constructed with a url. Controllers are registered against some

part of the URL space (e.g., http://example.com/*). So,

when the page is loaded in this URL space, install/use this

controller. so, this uses a "shared worker" (bit of code that is

securely shared across documents in the same domain)

noah: so, how is the security checking done? so, that code gets cached, and the whole thing fires itself

up and runs.

henry: there is some kind of precedence order here.

alex: last one wins

dan: you mentioned this is being implemented? by who?

alex: a bit of work is being done by Google on network controller. I have

a team, we are doing it.

yehuda: Let say you have an image tag. Right now, it's opaque

how an image ends up on the screen, etc. The overall goal that

Alex and I are working on is to expose some of those things

imperatively - so that people can fix bugs in the platform.

yehuda: and potentially extend the platform
... which can then feedback into the standards process

noah: the TAG spent a long time looking at distributed

extensibility. This seems to go in the opposite direction.

yehuda: in my view there is a crisis of imperative right now

(to extend the platform right now, you need to write a ton of

JS code - potentially reimplementing parts of the platform).

alex: here is a real example: currently, Firefox does not support

WebM. So there is work that converts code to asm.js to in order

to do fast image conversion.

henry: the point is that you can write a scoped handler

noah: it's scoped to the place where the thing came from. That

is, if I got this from website X, and you can scope it to the

site (e.g., with processing images).

yehuda: it's not scary to do that, but it could be scary if

people write their own PNG handlers

yehuda: once you have these hooks, you can imagine users making their

own solutions as showing us (standards people) what they want

in the core platform.

plinss: are you asking from the TAG is to define what

these hooks could be?

noah: if you are using markup for this, you could end up with

the custom elements and weird markup.

yehuda: the intention is that people change their markup once a

solution is standardised.

alex: so, to get compat, you might need to use a nesting hack.

And that is ok.

yehuda: there is still going to be hacks to get around platform

limitations. But for components that are standardized, then the

browser just handles that.

dan: what about prollyfills? wont the web become of a bunch of

polly/prollyfills?

alex: so, the point of polyfills is to help solve a particular

problem or overcome limitations - to give users are feature

they don't have.

yehuda: this removes a centralized bottleneck for getting new

stuff on the Web.

noah: my intuition about this stuff is that the general

direction is good. Being able to use the web's existing

extensibility hooks (e.g., mime types) would be good.

noah: I wonder if it would be worth while going through the

platform to see where the extensibility points are.

noah: up to now, this has been sold as a way for some part of the

web community to experiment.

yehuda: how do you suggest that someone actually solve this

problem?

annevk: so going into this right now doesn't help.
... there is a problem with this (images), if you do a cross domain

request, you will get a tainted response - so you won't be able

to access the bytes.

Jeni: sounds to me like that there are two possible types of

deliverables for TAG here: 1. guide for spec editors to make

sure that they build in extension points and 2. possibly guides

for web developers to know when and how to extend and upgrade

etc

noah: as Anne says, no one is using the media types.

so, if say media types is broken, then we should go and fix

the broken underlying specs that mandate them in the platform.

timbl: I would be interested to see if you could move from a

system that is not well defined to one that is in a secure

manner.

alex: our security model right now is "same origin". It would

be great if it was some other model.

[fast discussion about different examples/scenarios]

yehuda: I don't think these extensibility points fix

fundamental problems on the web, but it doesn't make it worse

[...discussion moved to identity and URIs]

yehuda: right now, this proposal solves some of the friction in the

platform.

annevk: if you wanted to invent new UI widgets, this allows you

to create new things to experiment with.

dan: what is the overlap between this VS shadow dom (web components)?

yehuda: this is a sort of implementation of this proposal it makes composition harder

alex: gmail was fighting a losing battle against the depth

limit of the dom in FireFox.

[alex explains what the shadow dom is]

[yehuda gives a concrete example of how input types work with

shadow dom in browsers]

[33]http://www.w3.org/TR/shadow-dom/

yehuda: you can view the shadow dom of elements (e.g., video's controls) in Chrome's dev tools

alex: the shadow dom does not affect the document's dom
... a few of us worked together on the shadow dom model

(referring to [34]http://www.w3.org/TR/shadow-dom/)

[34] http://www.w3.org/TR/shadow-dom/)

yehuda: the point is that we assume that people will want to

leave behind their own custom elements instead of using the new

standardized ones

timbl: it might be good for the TAG to recommend a registry for

custom tags

yehuda: I can see something like Ember.js doing that

alex: we've learned the hard way about accessibility issues because developers have to send code down the wire, it means they

take a huge performance hit which means they sometimes throw

away a bunch of stuff (e.g., accessibility related code suffers)

ht: the basic metric for some company is: how many staff am I

going to have to hire to support some feature?

yehuda: we should allow people to make little registries

noah: there was a time when there were multiple element

(image/img), eventually one won

yehuda: polymer, from google, will have a lot of stuff that

will be very google specific. So it might be ok for them just

to use "google-" we should consider how to allow people to create things

without "-"

annevk: "x-" is for browsers. It's a user agent or server layer

instead of the app layer.

noah: there is a case to be made that pointing to your own

implementation changes the game. If timbl then goes an invents

his own that uses your "xxx-" tag, then that might not cause an

issue. But when people go and search for "xxxx-", then it might

be a loss.

alex: it might be an opportunity

noah: I don't believe the damage is zero, because there might

be a place for globally unique identifiers for these

timbl: there are two ways this can go: 1. to get stuff into

html, 2. it becomes a modular programming system.

[discussion around dependencies, dll hell vs debian

dependencies]

dan: I'm interested in getting some action items. How do we

move forward with all this great stuff?

JeniT: this is all excellent. The thing that stands out is

being able to go down to a lower level. Not too different form

last F2F. What is it that the TAG should be doing on this? there are a few deliverables: 1. if we are going to be

reviewing specs, then we could look at the potential

extensibility points in relation to this. When this is more

hashed out, then we could have some guidance for web devs

around extensibility - and how do web devs plan to use these

extensibility points is this what you guys (alex, yehuda) had in mind?

yehuda: yes

alex: yes

plinss: what we don't want is here is a feature and here is the

extensibility points for feature X. Instead, we (TAG) want to

look at what the lower level primitives are. what JeniT is suggesting is that we identify the underlying

extensibility points

JeniT: it would be useful in a document to specify through

different examples

yehuda: when we notice something like fetch, we should make

sure that groups don't redefine things over and over

alex: trying to find the right point at which to target their

API (high low level)... this is hard to do.

JeniT: it might be easier to do that if we have some document

the describes this

plinss: this also ties in with working with other working

groups it's our role to provide guidance wrt architecture to other groups

dan: so, how does that translate into actions

<scribe> ACTION: yehuda and alex will create an initial draft

of high level view/survey and how they relate to system

capabilities [recorded in

[38]http://www.w3.org/2001/tag/2013/05/29-minutes.html#action01

]

JeniT: ah, from previous meeting:

[39]https://gist.github.com/wycats/5205250

[39] https://gist.github.com/wycats/5205250

yehuda: we can't obviously do too many APIs in the time we

have, but we could for instance start with the Web audio API

and how it might relate to the audio tag

[BREAK]

Capability URLs

JeniT presents slides:

[43]http://w3ctag.github.io/presentations/reveal/capability-url

s.html]

[JeniT presents slides... Web Arch... ]

annevk: I feel like you are conflating a whole bunch of stuff

together in this slide

noah: a fair amount is explained in the document

JeniT: I agree, there is more to go into there.

slide - beyond single page

slide - recommendations

slide - application design

annevk: So it seems the architecture concern doesn't apply

here: [45]http://www.w3.org/TR/webarch/#uri-aliases

annevk: It talks about network effects, but here you want to

keep them secret

JeniT: we should make some recommendations about this (we ===

tag)

annevk: So you don't want network effects :)

noah: It seems to me that capability URIs, by conflating

identity with access rights, tend to break one of the main use

cases for the Web: I want to provide to you a link to an

interesting resource, and the access you have should depend on

>your< rights, not mine.

slide - capability URL design

noah: I think capability systems are really interesting, but

I'm suspicious of the merits of tunneling a capability

architecture through the Web, which is not inherently

capability-oriented.

yehuda: there are no good answers to these problems.

JeniT: that's what makes it interesting work

yehuda: I can live with password resets, and emailed URLs...

but people accessing my private gists, etc. is not so good.

noah: From Web arch:

"It is reasonable to limit access to a resource (for

commercial or security reasons, for example), but merely

identifying the resource is like referring to a book by title.

In exceptional circumstances, people may have agreed to keep

titles or URIs confidential (for example, a book author and a

publisher may agree to keep the URI of page containing

additional material secret until after the book is published),

otherwise they are free to exchange them."

JeniT: the document may describe the implications if you do X, then Y may happen

yehuda: it's a problem that URLs can be leaked when they are

supposed to be private

[conversation about issues]

yehuda: it's a real failing that people can leak the urls

ht: there are strategies to address this issue, but it's

complicated. I would like to give the ability to one site to write

resources to another site - but with rules (e.g., 10 per day,

once a month). I.e., you allow a capability without actually

acting as the user.

ht: these things exist, but they are complicated. it's often a 3 actor situation ... or a trusted 4th party.

This stuff is a bit of rocket science right now, but I do

suggest that we don't publish anything that doesn't acknowledge

existing capability systems.

noah: the ones that I've seen are built on systems similar to

unix

[discussion about various types of capability systems]

dan: what we are talking about here is to help people do what

they are doing already

alex: is this something that we should encourage them to do?

annevk: we should document the concerns around this

dan: some of the best practices

noah: what are the responsibilities of the user agents? For the

web platform, it would be good to clarify what happens when one

of these URLs leaks. there is an obligation for the TAG to clarify this for user

agents, or proxies, to handle this. and you need to explain how to do this without for example

using a HTTP header or some other solution I expect to be able to mail URLs, but there should be some

level of protection at the UA level

yehuda: there is certainly a social norm issue of sharing URIs

dan: before we start making recommendations to UAs and proxies,

it seems to me that there are some best practices around

capability URLs that could be documented.

noah: Again, my recommendation was to document the current

platform rules: what are the responsibilities, of server,

proxy, user agent and other Web code to protect or prevent

copying of certain URIS.

noah: With that in hand, we can consider 1) explaining the

pros and cons of capability URIs and maybe 2) recommending

mechanisms for controlling such things.

annevk: I still want these things cached (or still be in

my browser's location bar)

noah: FWIW, and this will be no news to long-time TAG members,

I'm not a fan of trying to tunnel capability capability :-) through the Web

timbl: capability urls are relatively rare when compared to

other urls

timbl: so you are suggesting best practice aimed at web devs,

as opposed to UAs and proxies

dan: What existing material is out there that we could build

on?

JeniT: there are some links in the slides, which is what I've

found through searching

dan: do we know if there are any internal recommendations about

capability URLs?

annevk: I suspect not

JeniT: maybe Google has something?

annevk: the links in the presentation are from google guys.

alex: Tyler has worked on a bunch of stuff related to this.

Teams at Google often have their own thing - but I don't want

to misrepresent what they are doing.

dan: JeniT, are you proposing to be an editor of this?

JeniT: yes

annevk: I'm happy to help review stuff

plinss: do you see this as being a note or rec track doc?

JeniT: right now, it's just about writing up stuff... we can

decide what to do with it later

plinss: I'm interested in scope is all

JeniT: that's all I need

<scribe> ACTION: Jeni to create a first draft of capability

document guidelines [recorded in

[47]http://www.w3.org/2001/tag/2013/05/29-minutes.html#action02

]

alex: do we have consensus if we want to do this?

annevk: we should describe the landscape

dan: one of the early slides said that this contravenes

WebArch.. is that something that should be discussed.

timbl: that is one of the least worrying bits

noah: I happen to like this rule... let's chip away at Web Arch I think it would be good to enhance web arch with regards

to this matter either explain don't do that, or explain the trade off

JeniT: yehuda, there's one thing that people could do, which

is have a one-off capability URL that upgrades to a cookie

JeniT: alex, there's a strong timing component, usually they

should be short-lived

JeniT: yehuda, like you could enter your phone number, and

then have to enter a passcode that's been SMSed to you every

time you want to access it after that

HTTP Bis

ht: the focus of my interest is in basic archecture properties as a

whole, but not so much on browsers. But I wanted to tell you a

little bit about one of the long running issues. Which is, what

URIs are and how they hold the web together (if they do!).

RFC2616 is the one being replaced - it is over 10 years old. it has been edited for over 3 years, which is

exceptional for the IETF. One of the things the TAG has tried to

help with with describing the "identifier" part of the URI.

We have pushed the IETF to be clear about URIs. this is not because we are architecture astronauts. its

because questions have arisen about how URIs are used on the

"vanilla web" VS the semantic web if there is a difference, then how should those differences

be expressed? so I've been going through the specs, fairly carefully. To

try to see what picture is emerging. If you just read this spec

as if you had no background in HTTP/s, what would a reader get

out of that? if people are interested in this topic, I encourage you

to read the intro sections and the email I sent to the TAG

member list I will send the email to the public list soon Roy has added more language about REST.

yehuda: I'm lacking context about REST... i know what it is,

but how does it relate to this?

timbl: for me, the arch of the web is the hash... [tim

describes how the web works and how the semantic web works in a

rapid fire manner - for summary, please see http://i.imgur.com/UmpOi.gif ]

ht: ... at the end of the day, this only really matters for

spec weenies what URIs mean. devs are really only interested in operational stuff like

status codes, cache control. so I wanted to give you an overview of the comments I'm

making about the document. But what would be say about URIs if

this was up to the TAG? what we should say, if we could, the biggest gap from my

perspective what is people's behavior with regards to this

technology have to be ... to lead the web to it's full

potential? We need to identify who the players are, and what

their obligations are with regards to using URIs - i.e., what

is the social contract. the spec assumes human expectations about how people use

URIs but there are all sorts of assumptions about what people do I'm going to send a few comments back to the HTTP bis WG.

But is there other stuff I should do? one of the things people would like to know, when I get a

200?

annevk: that's it is OK? o_0

[room laughs]

ht: but what does that mean as a social contract?

timbl: but to make this part of the TAG, we need to look at the

applicability of this

ht: right now, it's not clear what the semantics are with

regards to method

annevk: httpbis can't change the state of the world. But they

can try to fix bugs in implementations. But they should just

leave the philosophy to a primer or something else.

noah: it's good to be clear about the semantic difference

between GET, POST, etc. it's a bit of a grey area, so you have to be careful about

what is defined

[discussion about philosophy behind different GETs]

JeniT: [annevk's conneg rant]

[discussion about conneg...]

JeniT: [wycats_'s pro conneg rant]

[...interpretive dance about bags of bits.... ]

dan: we might have a TAG deliverable that updates URLs and

URIs and discusses that

ht: I have a working title: "what would it be like to document

what is true about URLs?" asking the HTTP Bis WG to get rid of philosophising would

be counter productive what I am reviewing is just a clarifications of HTTP 1.1 -

it's a cleanup

F2F Planning

13-15 Oct at MIT

noah: 13-15 Oct at MIT, we also identified, week of Jan 06.

[discussion about TPAC, Marcos being booted from the TAG, etc.

]

JeniT: Jan 7-9 in Europe

Polyglot

ht: we've said everything we want to say.

yehuda: I think we reached consensus on this already

ht: is there a link to the discussion?

JeniT: [48]https://lists.w3.org/Archives/Member/tag/2013Apr/0046.html

ht: the background is that Paul Cotton asked to clarify where

we are at

ht: [49]http://www.w3.org/2001/tag/group/track/actions/791

yehuda: we all agreed that we can all live with the proposed

text.

ht: we should consider Larry's feedback

annevk: I don't agree with the change Larry suggests. I think

it's wrong.

yehuda: I agree.

annevk: it could be clearer.

JeniT: email should s/wether/whether/

annevk: it would be clearer if with xhtml mime type you use

xhtml, and with html mime type you use html

ht: if we could capture the above in the proposed text, then

that would be great.

annevk: see also [50]http://html-differences.whatwg.org/#syntax which describes

that

ht: My proposed change "using HTML5 syntax and mediatypes

(either HTML syntax and text/html, or XHTML syntax and

application/xhtml+xml"

yehuda: in the Web Arch document there is a section that talks

about the content-type in normative terms that don't match

reality.

annevk: [51]http://www.w3.org/TR/CSS1/

ht: we can't just change the spec in place

noah: What change to what spec is being proposed?

Yves: it's actually a new spec

ht: [52]http://www.w3.org/2001/tag/webarch/errata.html

noah: I thought Yehuda said: "Published spec XXX says MUST"

which one?

[53]http://www.w3.org/TR/webarch/

yehuda: section 3.3

annevk: AWWW says, "Agents MUST NOT ignore message metadata without the

consent of the user."

noah: the TAG should take a strong line that normative spec text

should be followed. it would be better to get the normative text updated in the

appropriate spec

ht: Stand by for HTTPbis:

"... In practice, resource owners do not always properly

configure their origin server to provide the correct Content-Type for a

given representation, with the result that some clients will

examine a payload's content and override the specified type. Clients

that do so risk drawing incorrect conclusions, which might expose

additional security risks (e.g., "privilege escalation").

Furthermore, it is impossible to determine the sender's intent by examining

the data format: many data formats match multiple media types that

differ only in processing semantics. Implementers are encouraged to

provide a means of disabling such "content sniffing" when it is

used." - HTTPBis

ht: given the normative text comes from 2616, the appropriate

text in Web Arch should be updated when HTTP Bis updates the

HTTP 1.1 spec.

ht: trackbot, Action-791?

[54]http://www.w3.org/2001/tag/group/track/actions/791

ht: trackbot, close action-791

Dan: so, Polyglot can be closed.

[MEETING ADJOURNED]

Summary of Action Items

[NEW] ACTION: Jeni to create a first draft of capability document guidelines [recorded in http://www.w3.org/2001/tag/2013/05/29-minutes.html#action02]
[NEW] ACTION: yehuda and alex will create an initial draft of high level view/survey and how they relate to system capabilities [recorded in http://www.w3.org/2001/tag/2013/05/29-minutes.html#action01]
[NEW] ACTION: Jeni to create a first draft of capability
[NEW] ACTION: yehuda and alex will create an initial draft
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2013-06-14 03:32:12 $