See also: IRC log
<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
<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
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
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"
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]
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
[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
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
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
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?
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]
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]
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
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
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
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]
