IRC log of tagmem on 2013-05-29

Timestamps are in UTC.

08:11:14 [RRSAgent]
RRSAgent has joined #tagmem
08:11:14 [RRSAgent]
logging to http://www.w3.org/2013/05/29-tagmem-irc
08:11:16 [trackbot]
RRSAgent, make logs public
08:11:16 [Zakim]
Zakim has joined #tagmem
08:11:18 [trackbot]
Zakim, this will be TAG
08:11:18 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
08:11:19 [trackbot]
Meeting: Technical Architecture Group Teleconference
08:11:19 [trackbot]
Date: 29 May 2013
08:11:44 [ht]
ScribeNick: ht
08:11:50 [JeniT]
JeniT has joined #tagmem
08:11:52 [ht]
Scribe: Henry S. Thompson
08:12:36 [marcosc]
marcosc has joined #tagmem
08:12:38 [ht]
Meeting: TAG Face-to-face, London
08:13:20 [ht]
ht has changed the topic to: Agenda: http://www.w3.org/2001/tag/2013/05/29-agenda.html
08:13:37 [timbl]
timbl has joined #tagmem
08:15:45 [ht]
Chairs: Noah Mendelsohn, Peter Linss, Dan Appelquist
08:15:53 [noah]
noah has joined #tagmem
08:16:49 [noah]
The it's not an agenda: http://www.w3.org/2001/tag/2013/05/29-agenda.html
08:17:08 [noah]
The agenda wiki: http://www.w3.org/wiki/TAG/Planning/May-2013-F2F
08:17:31 [ht]
Topic: Intro
08:17:43 [ht]
NM: I had a meeting with PL and DA last night
08:18:03 [ht]
... Our goal is to generate momentum, and get some major topics moving
08:18:15 [ht]
... In principle I'm still chair, for a few days
08:18:25 [noah]
http://www.w3.org/2001/tag/2013/04/18-minutes
08:18:25 [ht]
... In practice PL and DA will be running things
08:18:42 [noah]
http://www.w3.org/2001/tag/2013/05/16-minutes
08:19:02 [ht]
RESOLUTION: http://www.w3.org/2001/tag/2013/04/18-minutes are approved as a correct record of our meeting of 2013-04-18
08:19:04 [noah]
http://www.w3.org/2001/tag/2013/05/29-agenda.html
08:19:35 [ht]
RESOLUTION: http://www.w3.org/2001/tag/2013/05/16-minutes are approved as a correct record of our meeting of 2013-05-16
08:20:42 [ht]
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
08:21:44 [ht]
NM: 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
08:22:50 [ht]
DA: [recites the declaration of independence]
08:23:12 [ht]
s/DA: [recites the declaration of independence]//
08:23:47 [ht]
DA: The TAG is changing now, reflecting a change in the Web community
08:24:13 [ht]
... More of a leadership role is being called for, not exclusively, but an essential part of the conversation
08:24:29 [ht]
DA: The new membership of the TAG is part of that
08:25:31 [ht]
DA: Our challenge is to take this injection of energy and use it to generate momentum around the topics we choose to take forward
08:25:57 [ht]
... We need to use the next 3 days to propel us
08:26:32 [ht]
PL: I'd like to identify some short-term demonstrable impact
08:27:48 [ht]
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
08:28:14 [ht]
DA: So, next step is to work on the Agenda, via the wiki
08:29:06 [ht]
HST: Logistics?
08:29:41 [ht]
AvK: Lunch is sometime between 12 and 1...
08:30:27 [ht]
DA: Thursday evening at 1830 we have 60 web devs coming to give us their . . . input
08:31:54 [ht]
NM: Structure?
08:32:14 [ht]
DA: It's a reception, start by introducing ourselves, then mingle
08:32:26 [ht]
AvK: We should have an intro about what we do
08:32:42 [ht]
DA: Yes, but the point is not for us to talk to them, but for us to _listen_ to them
08:32:51 [ht]
s/to them/at them/
08:33:03 [ht]
DA: At 2100 we dinner nearby
08:33:29 [ht]
s/dinner/have dinner/
08:34:22 [ht]
DA: On Friday, we'll aim to wrap by 1600
08:34:56 [ht]
Topic: Agenda
08:35:15 [ht]
NM: We do need some time to discuss next (2?) f2f dates/locations
08:35:23 [ht]
... 1st afternoon is often good for that
08:35:30 [ht]
NM: We have maybe 1 in October
08:35:39 [ht]
... and nothing after that
08:37:33 [ht]
YK: We should put meta-topics early, so we don't keep circling back to them
08:37:40 [ht]
... AR and I have some suggestions
08:38:13 [ht]
TBL: I sent some suggestions
08:39:09 [ht]
s/suggestions/suggestions about Futures/
08:39:25 [Yves_]
Yves_ has joined #tagmem
08:39:45 [ht]
YK: Yes, and we should discuss that topic -- my suggestion was to get the strategic discussion at least started first
08:39:59 [ht]
[wiki -> whiteboard agenda negotiation]
08:46:17 [ht]
NM: Responsive?
08:46:33 [ht]
DA: Responsive _design_
08:47:34 [ht]
YK: E.g. reacting to orientation change of the client device
08:48:02 [ht]
DA: Goals and TAG operations are not the same
08:56:24 [darobin]
darobin has joined #tagmem
09:06:18 [ht]
DA: Whiteboard is a tentative plan for the Agenda
09:06:27 [ht]
[will be captured and posted]
09:06:32 [ht]
Topic: Goals of the TAG
09:06:55 [dka_]
dka_ has joined #tagmem
09:07:02 [ht]
YK: We've cleared our plate a bit over the last few months, which is good
09:07:23 [ht]
... New members were asked to wait a bit before driving forward, and we've done this
09:07:44 [ht]
YK: We'd like to broaden 'architecture' to include the architecture of the platform
09:07:53 [dka_]
q?
09:08:16 [ht]
... We'd like the TAG to take this on: help WGs coalesce around a coherent approach to APIs
09:08:32 [ht]
... Help them to coordinate
09:09:28 [ht]
YK: This means asking WGs to present new stuff to us, and move the TAG to the forefront of managing the overall architecture of the platform
09:09:38 [ht]
s/asking/encouraging/
09:09:54 [ht]
MC: We can't and shouldn't compel WGs
09:10:12 [ht]
YK: Indeed, but it is our job to seek coherence
09:10:39 [ht]
NM: That's what we're chartered to do, but we have no enforcement powers, and it doesn't always worked
09:10:53 [ht]
s/doesn't/hasn't/
09:11:09 [ht]
YK: Past failures, yes, but let's look to the future
09:11:21 [ht]
NM: It extends back past HTML5. . .
09:11:40 [ht]
AR: I've spending a lot of time on this (API coherence) in my day job
09:11:56 [wycats_]
q+ to discuss the related TC39 process
09:11:57 [ht]
... There's a real need, on the part of people putting individual specs forward
09:12:59 [ht]
AR: 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
09:13:17 [wycats_]
I don't think we can do this on an as-noticed basis
09:13:47 [wycats_]
we need to take on the responsibility of being aware of the platform's progress and proactively discovering overlapping and conflicting architectures
09:13:57 [ht]
AR: Examples: Web Midi, Web Crypto, Web RTC -- all of these have defined separate but incompatible callback styles
09:14:09 [ht]
TBL: Patterns the same?
09:14:31 [ht]
AvK: Similar problems, but arbitrary design differences in response
09:14:48 [ht]
AvK: Local perspective doesn't motivate generic solutions
09:15:05 [ht]
TBL: Not just a matter of renaming/reordering parameters
09:15:13 [ht]
AR: No, subtle semantic differences
09:15:32 [ht]
AvK: Inventing new primitives independently
09:15:46 [ht]
... We now have Futures, but a bit too late
09:16:00 [ht]
TBL: Doesn't this require lots of backwards changes?
09:16:36 [ht]
YK: In many cases the changes are pretty easy: replace "return void" as last arg't to "return [future]"
09:16:52 [ht]
AR: And backporting gives WGs something to do
09:16:55 [ht]
TBL: Cost?
09:17:07 [ht]
AR: GC -- Futures take storage from the heap
09:17:37 [ht]
DA: Up-level: We have the opportunity to influence other groups, from a position of "we're here to help"
09:18:07 [dka_]
q?
09:18:09 [ht]
DA: We need to map out which groups/individuals will be most receptive, so we can quickly demonstrate TAG value
09:18:09 [noah]
q+ timbl
09:18:50 [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
09:18:53 [wycats_]
(things like futures)
09:19:06 [ht]
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
09:19:53 [wycats_]
"structured engagement" -> I like that term
09:19:59 [ht]
AR: We're hoping for a substantially changed new version of IndexDB, for instance
09:20:28 [ht]
AR: By and large people are trying to do the right thing, we need to make it easier for them
09:20:35 [timbl]
q?
09:21:34 [ht]
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
09:22:08 [ht]
AR: Specific issues: Futures/Promises; Streams (we _need_ this, it's a trainwreck at the moment)
09:22:41 [ht]
AR: We need a process for Streams in the same way we got Futures done
09:22:50 [ht]
TBL: Futures are done?
09:22:59 [ht]
AR: Short answer: yes
09:23:10 [ht]
YK: TC39 is more-or-less agreed
09:23:19 [ht]
TBL: Unresolved issues?
09:23:31 [ht]
AvK: There were, but they have been resolved
09:23:47 [ht]
TBL: Microsoft happy?
09:23:58 [ht]
YK: Their rep. has signed off, yes
09:24:07 [ht]
ack wycats_
09:24:07 [Zakim]
wycats_, you wanted to discuss the related TC39 process
09:24:28 [ht]
YK: My perspective is informed by my TC39 experience
09:24:44 [ht]
... They don't meet all that often, they can't _do_ the technical work
09:24:58 [ht]
... They manage the 'complexity budget' of the language
09:25:27 [ht]
... And focussing on that is what TC39 does best, leaving the detailed technical work to small groups
09:25:40 [ht]
YK: And that's v. parallel to the TAG situation
09:25:50 [ht]
TBL: Yes, that's what we're chartered to do
09:26:34 [ht]
YK: So "come to us", not for approval, but because we have something recognizable to offer them: our higher-level perspective on the platform
09:27:00 [ht]
YK: "You (or any WG) are welcome to come and present for 30 minutes, and we'll try to help"
09:28:25 [ht]
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
09:28:52 [ht]
... Even giving tutorials at TPAC...
09:29:04 [dka_]
q?
09:29:35 [ht]
q- timbl
09:30:13 [ht]
AR: We need some kind of calendar or temperature chart, so we know what's nearing the point where we need to get involved
09:30:32 [ht]
DA: We can't change the W3C process on our own
09:31:04 [ht]
JT: Being more aware of what W3C as a whole is working on, and the state of the various WGs
09:31:34 [Yves]
http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications
09:31:38 [ht]
YK: You can see all the drafts, and sort by status, on the TR page
09:31:53 [ht]
... it's hard to use, but it's all there
09:32:29 [ht]
YL: WebApps dashboard is a possible model: http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications
09:33:00 [ht]
NM: Sometimes that's too late -- charter proposals are sometimes the point you need to catch: see e.g. SOAP
09:34:16 [timbl]
https://www.ietf.org/mailman/listinfo/new-work
09:34:19 [ht]
YK: Standing agenda item for New Charters
09:34:23 [annevk]
wycats_: raw data is http://www.w3.org/2002/01/tr-automation/tr.rdf I think
09:34:32 [annevk]
wycats_: maybe http://www.w3.org/TR/tr.xml
09:35:03 [ht]
HST: It's an 80/20 thing, we can do better than we are doing now, without assuming we will get everything
09:35:44 [timbl]
ooops new-work is not public
09:36:19 [ht]
DA: YL, can you help populate that agenda item?
09:36:44 [ht]
YL: Can do: I'll take a standing action item:
09:37:44 [ht]
ACTION Yves to bring new W3C initiatives to TAG's attention, open-ended, due 2015-12-31
09:37:44 [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].
09:38:07 [ht]
NM: Anyone attending IETF regularly
09:38:29 [ht]
s/Anyone/Need this beyond W3C. Anyone/
09:38:41 [ht]
JT: Larry Masinter was, no-one now
09:39:31 [ht]
DA: Other opportunities for quick engagement: Web midi, Web RTC, Sysapps, Webapps
09:39:35 [ht]
DA: Webapps is big
09:39:42 [ht]
YK: Let _them_ roll it up
09:40:30 [ht]
ACTION Dan to talk with Art Barstow and/or Charles Mac??-Neville to find out who from Webapps might come to talk to us
09:40:30 [trackbot]
Created ACTION-803 - Talk with Art Barstow and/or Charles Mac??-Neville to find out who from Webapps might come to talk to us [on Daniel Appelquist - due 2013-06-05].
09:40:59 [ht]
MC: I will present for Sysapps
09:41:18 [ht]
MC: I could use the Sysapps slot
09:41:42 [ht]
NM: Do this kind of thing at TPAC, with the _whole_ WG?
09:41:50 [timbl]
wycats_, FTR the TR page data is in http://www.w3.org/2002/01/tr-automation/tr.rdf
09:41:53 [ht]
HST: That's the _second_ step, surely
09:42:20 [ht]
NM: That has often done a lot to build bridges -- get recognition of who we are and what we can do
09:42:36 [wycats_]
http://www.w3.org/TR/tr.xml seems to return something
09:42:55 [ht]
DA: We should indeed discuss what we do at TPAC, in general
09:43:13 [ht]
... Two TPACs a year?
09:43:56 [ht]
TBL: IETF meet 3 times a year
09:44:11 [ht]
DA: Web audio?
09:44:57 [ht]
MC: I can reach out to them, but they are pretty resistent to change
09:45:09 [ht]
YL: The editor is in London. . .
09:45:38 [ht]
AR: It has a strong core functionality, but the API has some idiosyncratic properties
09:46:05 [ht]
DA: Invite the chair for Friday?
09:46:26 [ht]
AR: Great topic for telcon
09:47:06 [ht]
ACTION Yves to invite Olivier Theroux to lunch on Friday due 2013-05-29
09:47:06 [trackbot]
Created ACTION-804 - Invite Olivier Theroux to lunch on Friday due 2013-05-29 [on Yves Lafon - due 2013-06-05].
09:47:25 [ht]
trackbot, action 804 due 2013-05-30
09:47:32 [ht]
trackbot, action-804 due 2013-05-30
09:47:32 [trackbot]
Set ACTION-804 Invite Olivier Theroux to lunch on Friday due 2013-05-29 due date to 2013-05-30.
09:48:01 [noah]
ACTION-804?
09:48:02 [trackbot]
ACTION-804 -- Yves Lafon to invite Olivier Theroux to lunch on Friday due 2013-05-29 -- due 2013-05-30 -- OPEN
09:48:02 [trackbot]
http://www.w3.org/2001/tag/group/track/actions/804
09:48:08 [ht]
ACTION Anne to find a representative of Web RTC to talk to the TAG
09:48:08 [trackbot]
Created ACTION-805 - Find a representative of Web RTC to talk to the TAG [on Anne van Kesteren - due 2013-06-05].
09:48:54 [ht]
YK: I'll undertake to keep TC39 information flowing to the TAG
09:49:43 [ht]
JT: There is new work on SemWeb tabular data on the web, next step is CSV, Phil Archer and Ivan Herman are involved
09:50:13 [ht]
ACTION Jeni to invite Phil Archer to talk to the TAG
09:50:13 [trackbot]
Created ACTION-806 - Invite Phil Archer to talk to the TAG [on Jeni Tennison - due 2013-06-05].
09:51:02 [ht]
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
09:51:47 [JeniT]
wycats_: uriburner is broken I guess
09:51:47 [ht]
ACTION Dan to invite someone from Responsive Images CG to talk to the TAG
09:51:47 [trackbot]
Created ACTION-807 - Invite someone from Responsive Images CG to talk to the TAG [on Daniel Appelquist - due 2013-06-05].
09:52:25 [ht]
YK: Should we look at the general issue of relations with CGs?
09:53:08 [ht]
DA: They are so diverse. . .I don't think a blanket approach is possible
10:17:15 [dka_]
dka_ has joined #tagmem
10:18:09 [dka_]
q?
10:18:54 [ht]
MC: What are the concrete action items?
10:19:11 [ht]
HST: Actions for contacts to WGs are in the tracker
10:19:27 [ht]
YK: I think we're good for now
10:19:46 [ht]
DA: I'm satisfied for now -- we need to get to having concrete progress
10:20:56 [ht]
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?
10:21:27 [ht]
YK: We've talked about an API Design Guide
10:21:43 [ht]
AR: Futures could be a deliverable
10:22:01 [ht]
DA: Would we write something which points to other docs, saying: use this?
10:22:50 [ht]
AR: More general: What does it mean to design a good Web API: declarative, structured, etc.
10:23:11 [ht]
... Sort of a "So you're building your first API -- here's what you need to know"
10:23:43 [ht]
YK: Separate legacy from new stuff, so that legacy doesn't get copied on
10:24:22 [ht]
AR: New specs keep getting written which indiscrimately use too much of WebIDL
10:24:40 [ht]
YK: We need "WebIDL, the good bits"
10:24:49 [ht]
TBL: E.g.?
10:25:34 [ht]
AR: Objects [?] w/o constructors, overloaded methods based on type alone, not arity
10:25:51 [ht]
TBL: Doesn't JQuery handle all that
10:26:00 [ht]
YK: Yes, but at huge cost in some cases
10:26:50 [ht]
MC: A lot of the problems stem from people copying existing WebIDL w/o understanding it
10:27:52 [ht]
AR: It's not that the IDL is necessarily weird, it's the relationship _between_ WebIDL and JS which leads to great weirdness
10:28:05 [ht]
TBL: So in principle it would be good to design just for JS. . .
10:29:07 [ht]
MC: It leads to one VM inside another, with JS at both ends, which is just . . . confusing
10:30:34 [ht]
MC: Any reason why we _shouldn't_ do a Futures API spec?
10:31:06 [ht]
HST: It's unprecedented. YK's TC39 model also doesn't suggest that, rather that we need to motivate a WG to do it.
10:31:33 [ht]
MC: But there isn't a WG for shared APIs which many groups need
10:31:50 [ht]
AR: We may need to embed someone in an existing WG
10:32:18 [ht]
DA: We clearly need to identify work items which don't have a home
10:33:04 [ht]
... 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"
10:33:40 [ht]
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
10:35:20 [ht]
trackbot, close ACTION-804
10:35:20 [trackbot]
Closed ACTION-804 Invite Olivier Theroux to lunch on Friday due 2013-05-29.
10:35:56 [ht]
DA: So should Promises by a finding?
10:36:31 [ht]
AR: I'm more interested in the overall API Best Practices document, where using Promises would play a part
10:36:51 [ht]
JT: Is it spec. authors we're aiming at, or web devs?
10:37:18 [ht]
AR: W3C has little ability to affect web devs, except via specs, so, spec. authors
10:37:48 [ht]
NM: This is a good example of why 'architecture' is valuable to keep in view
10:39:11 [ht]
... 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"
10:39:28 [ht]
YK: Not at too high a level
10:39:52 [ht]
NM: So, no "On Promises" document?
10:40:18 [ht]
YK: Yes, but with emphasis on concrete Best Practices, not so much on _why_ they are Best
10:40:50 [ht]
YK: So that's a separate Note on why you should use Promises
10:41:09 [ht]
... but not with a cookbook
10:42:04 [ht]
AR: I will undertake to produce that Note
10:42:25 [wycats_]
it makes sense for the best practices docs to link to the architecture notes
10:42:43 [ht]
YK: I expect the Good Practices document will often come first, with the architecture 'why' note later
10:43:45 [ht]
JT: Still not sure about the targetting
10:43:59 [ht]
HST: Both those docs are targetted. . .
10:44:08 [ht]
YK: . . . at spec authors
10:44:33 [ht]
AvK: At least some devs want to understand 'why' as well
10:45:31 [ht]
PL: The guide to WebApps architecture Best Practices is really needed
10:45:49 [ht]
AR: What did HTML do right, and what did they do wrong
10:46:06 [ht]
... e.g. don't loose sight of the tree structure
10:47:05 [ht]
YK: If we write such a guide, it would be obsolete in a year
10:47:25 [noah]
With apologies for the residual use of CVS, I have posted a (slightly fuzzy) image of the agenda whiteboard as of approximately 11:30 AM Wed.
10:47:27 [noah]
It
10:47:30 [noah]
It's at http://www.w3.org/2001/tag/2013/05/WhiteboardAgenda1130Wed.jpg
10:48:12 [ht]
HST: Now talking about a Primer?
10:48:23 [ht]
YK: Not us, rather they exist already
10:50:08 [ht]
HST: So the "Guide to WebApps Best Practices" and the "API Best Practices" mentioned above are two distinct documents
10:50:38 [ht]
HST: The API Best Practices is aimed at spec. writes, and we are all pretty much clear it should happen
10:51:45 [ht]
DA: The "Guide to WebApps architectural principles" is for those who want to know why
10:52:06 [ht]
s/WebApps Best Practices/WebApps archictural principles/
10:54:53 [ht]
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
10:55:37 [ht]
PL: Two document _spaces_
10:56:07 [ht]
NM: The architectural principles doc is for both communities
10:56:25 [ht]
s/API Best Practices/API Design Best Practices/
10:56:56 [ht]
DA: When we had the #URI discussion, JT produced a great blog post, which evolved and morphed into a finding
10:57:25 [ht]
DA: We could take AR's blog post on Web Components down a similar route
10:57:50 [ht]
NM: First WD is a good route too
10:58:17 [ht]
PL: Lets get back from mechanism to substance
10:59:18 [ht]
YK: The key point is to back up design choices which depend on architectural goals with documents which articulate the architectural background
10:59:30 [ht]
Topic: TC39
10:59:38 [dka_]
dka_ has joined #tagmem
10:59:52 [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.
11:00:01 [ht]
YK: We all talked about TC39 in our platform when we ran for the TAG
11:00:16 [ht]
... W3C and TC39 complain about each other
11:00:20 [slightlyoff]
noah: and I'm totally good with that. But that stuff probably needs heavy editing = )
11:00:34 [slightlyoff]
noah: my writing isn't...erm...good
11:00:57 [ht]
YK: TC39 operates almost as if it were a W3C WG, with responsibility for Javascript
11:01:24 [ht]
... So AR and I have been trying to facilitate coordination as if that were true
11:02:04 [ht]
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
11:02:21 [ht]
... They don't yet feel included
11:02:28 [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"
11:05:53 [ht]
AR: TC39 is evolving---it has shifted focus from just language fixes to a recognition of its place in devs lives
11:06:00 [ht]
s/devs/devs'/
11:06:37 [ht]
YK: Many new members are designers/devs (as opposed, at least a bit, to Prog Lang people)
11:08:14 [ht]
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
11:08:34 [ht]
NM: So there's a coordinating role that the TAG could/should play?
11:08:46 [ht]
YK: Yes
11:08:54 [ht]
NM: Should we write something?
11:09:31 [ht]
s/Yes/Yes: encourage DOM to recognise that they sit on top of JS, not independent of it/
11:09:53 [ht]
YK: AvK is coming to next TC39 meeting
11:11:39 [ht]
NM: Do we need to prepare the ground by going to the DOM WG sooner rather than later?
11:12:15 [ht]
HST: We do introductions and then get out of the way
11:13:40 [ht]
DA: We could invite a TC39 rep to a TAG call, or organize a workshop
11:14:08 [ht]
NM: You get them together too early, they just resume their ongoing battles
11:14:56 [ht]
DA: So AR and AvK will explore ways of engage with the W3C groups
11:15:36 [ht]
HST: There is no DOM WG, right?
11:15:39 [ht]
AvK: WebApps actually own the DOM now
11:16:13 [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.)
11:16:14 [ht]
YK: We certainly need to know who the sub-group owner is within WebApps
11:17:01 [ht]
YL: WebApps is a meta-group, the chairs know at any point who is working on what
11:17:05 [annevk]
wycats_: http://www.w3.org/2008/webapps/wiki/PubStatus
11:18:17 [ht]
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
11:18:44 [darobin]
darobin has joined #tagmem
11:18:57 [ht]
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
11:19:22 [ht]
DA: Who's the guy on the WhatWG side?
11:19:26 [ht]
AvK: Me
11:19:34 [ht]
DA: Who's the guy onn the W3C side?
11:19:38 [ht]
AvK: Not me
11:20:56 [ht]
DA: Should we try to meet w. TC39 at TPAC?
11:21:02 [ht]
AvK: It's in China
11:21:18 [ht]
YK: We can invite them. . .
11:21:50 [ht]
AvK: It didn't work well last time
11:23:16 [ht]
AR: We need to have a very concrete activity plan for them
11:25:12 [ht]
HST: We need to make as good as we can on the "TC39 is effectively a WG" story
11:25:45 [ht]
DA: Right, so ask JJ to invite TC39 as full partipants at TPAC
11:26:01 [ht]
YK: TC39 has 15 active members
11:26:24 [ht]
TBL: We should check for scheduling conflicts, and membership issues
11:26:58 [ht]
... Don't try to solve the whole thing, get a partial picture and then take it to JJ
11:28:01 [ht]
ACTION Dan to pull together a plan for TC39 participation at TPAC in November in China
11:28:01 [trackbot]
Created ACTION-808 - Pull together a plan for TC39 participation at TPAC in November in China [on Daniel Appelquist - due 2013-06-05].
11:28:09 [timbl]
[2013/5/29 10:07:35] Tim Berners-Lee: http://www.w3.org/2013/11/TPAC/
11:28:10 [timbl]
[2013/5/29 10:07:45] Tim Berners-Lee: SHENZHEN, CHINA 11-15 NOVEMBER 2013
11:29:27 [ht]
[Adjourned for lunch until 1330]
11:30:27 [ht]
Scribe: Marcos Cáceres
11:30:38 [ht]
ScribeNick: marcosc
11:43:27 [darobin_]
darobin_ has joined #tagmem
12:20:54 [Zakim]
Zakim has left #tagmem
12:31:24 [JeniT]
JeniT has joined #tagmem
12:31:46 [dka_]
dka_ has joined #tagmem
12:34:19 [noah]
noah has joined #tagmem
12:41:32 [marcosc]
scribe: Marcos
12:41:40 [marcosc]
scribenick: marcosc
12:42:03 [marcosc]
TOPIC: Layering
12:46:06 [marcosc]
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
12:47:09 [marcosc]
yehuda: so, if we look at some thing like appcache [history of app cache and how it was made by the WHATWG and friends].
12:48:35 [marcosc]
slightlyoff: [gives overview of a similar situation in with regards to google gears]. With the lessons of Google gears, appcache was born...
12:49:03 [slightlyoff]
marcosc: well, just saying that Google motivated both the Gears and the AppCache work
12:49:32 [slightlyoff]
marcosc: and Aaron Boodman et. al. were working on other things (notably Chrome) by the time AppCache was being built
12:51:10 [marcosc]
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.
12:52:01 [bkardell]
bkardell has joined #tagmem
12:52:14 [marcosc]
dan: as a side bar, Andrew Betts has a lot of feedback with regards to app cache from Financial Times' experience with that appcache.
12:54:52 [marcosc]
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
12:54:52 [marcosc]
el network API (e.g., navigation controller).
12:55:50 [marcosc]
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.
12:55:56 [marcosc]
noah: is this a plugin?
12:56:08 [marcosc]
yehuda: no, this is not a pluging.
12:56:23 [marcosc]
s/pluging/plugin/
12:57:06 [marcosc]
noah: so, you want to be careful with this. As you are downloading a hook that can reroute network requests.
12:59:08 [marcosc]
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.
12:59:46 [marcosc]
alex: so, this uses a "shared working" (bit of code that is securely shared across documents in the same domain)
13:00:25 [marcosc]
noah: so, how is the security checking done?
13:01:23 [marcosc]
noah: so, that code gets cached, and the whole thing fires itself up and runs.
13:01:26 [dka_]
q?
13:01:41 [dka_]
trackbot, start meeting
13:01:43 [trackbot]
RRSAgent, make logs public
13:01:43 [Zakim]
Zakim has joined #tagmem
13:01:45 [trackbot]
Zakim, this will be TAG
13:01:45 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
13:01:46 [trackbot]
Meeting: Technical Architecture Group Teleconference
13:01:46 [trackbot]
Date: 29 May 2013
13:01:49 [marcosc]
ht: there is some kind of precedence order here.
13:01:56 [dka_]
q?
13:02:03 [marcosc]
alex: last one wins
13:02:42 [marcosc]
dan: you mentioned this is being implemented? by who?
13:03:03 [marcosc]
alex: a bit of work is being done by network controller. I have a team, we are doing it. \
13:04:12 [marcosc]
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.
13:04:23 [marcosc]
yehuda: and potentially extend the platform
13:04:38 [marcosc]
yehuda: which can then feedback into the standards process
13:05:34 [marcosc]
noah: the TAG spent a long time looking at distributed extensibility. This seems to go in the opposite direction.
13:06:20 [marcosc]
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).
13:08:14 [marcosc]
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.
13:08:46 [marcosc]
hp: the point is that you can write a scoped handler
13:08:59 [marcosc]
s/hp/ht/
13:09:52 [marcosc]
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).
13:10:19 [marcosc]
yehuda: it's not scary to do that, but it could be scary if people write their own PNG handlers
13:10:37 [JeniT]
q?
13:10:43 [JeniT]
q+ to ask what it is the TAG should do
13:10:59 [ht]
q+ to ask why you're using a new tag
13:11:14 [marcosc]
yehuda: once you these hooks, you can imagine users making their own solutions as showing us (standards people) what they want in the core platform
13:11:46 [marcosc]
plinss: what you are asking from the TAG is to define what these hooks could be.
13:12:28 [marcosc]
noah: if you are using markup for this, you could end up with the custom elements and weird markup.
13:14:19 [marcosc]
yehuda: the intention is that people change their markup once a solution is standardised
13:14:48 [marcosc]
alex: so, to get compat, you might need to use a nesting hack. And that is ok.
13:15:50 [marcosc]
yeahuda: there is still going to hacks to get around platform limitations. But for components that are standardized, then the browser just handles that.
13:16:04 [JeniT]
s/yeahuda/yehuda/
13:16:14 [marcosc]
dan: what about prollyfills? wont the web become of a bunch of polly/prollyfills?
13:17:03 [marcosc]
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.
13:18:28 [marcosc]
yehuda: this removes a centralized bottleneck for getting new stuff on the Web.
13:19:42 [marcosc]
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.
13:20:14 [marcosc]
noah: I wonder if it would be worth while going through the platform to see where the extensibility points are
13:21:46 [marcosc]
noah: up to now, this has been sold as a way for some part of the web community to experiment.
13:22:03 [marcosc]
yehuda: how do you suggest that someone actually solve this problem?
13:22:17 [marcosc]
annevk: so going into this right now doesn't help.
13:23:03 [marcosc]
annevk: 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
13:23:48 [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
13:23:54 [marcosc]
noah: as Anne says, no one is using the media types.
13:24:51 [marcosc]
noah: so, if say media types is broken, then we should go and fix the broken underlying specs that mandate them in the platfomr.
13:24:58 [marcosc]
s/platfomr/platform/
13:25:36 [marcosc]
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.
13:26:16 [marcosc]
alex: our security model right now is "same origin". It would be great if it was some other model.
13:27:56 [marcosc]
[fast discussion about different examples/scenarios]
13:29:05 [marcosc]
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]
13:30:12 [marcosc]
yehuda: right now, this proposal solves some of the friction in the platform.
13:31:04 [marcosc]
annevk: if you wanted to invent new UI widgets, this allows you to create new things to experiment with.
13:31:26 [marcosc]
dan: what is the overlap between when you would use this VS when you would use shadow dom?
13:31:43 [marcosc]
yehuda: this is a sort of implementation of this proposal
13:32:14 [marcosc]
yehuda: it makes composition harder
13:32:55 [marcosc]
alex: gmail was fighting a losing battle against the depth limit of the dom in FireFox.
13:33:38 [marcosc]
[alex explains what the shadow dom is]
13:35:00 [marcosc]
[yehuda gives a concrete example of how input types work with shadow dom in browsers]
13:36:08 [marcosc]
http://www.w3.org/TR/shadow-dom/
13:36:57 [marcosc]
yehuda: you can view it in Chrome's dev tools
13:38:36 [marcosc]
alex: the shadow dom does not affect the document's dom
13:39:30 [marcosc]
alex: a few of use worked together on the shadow dom model (referring to http://www.w3.org/TR/shadow-dom/)
13:41:47 [marcosc]
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
13:42:04 [JeniT]
q?
13:42:50 [marcosc]
timbl: it might be good for the TAG to recommend a registry for custom tags
13:43:10 [marcosc]
yehuda: I can see something like Ember doing something like that
13:43:39 [marcosc]
alex: we've learned the hard way about accessibility issues
13:44:29 [marcosc]
alex: 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)
13:45:47 [marcosc]
ht: the basic metric for some company is: how many staff am I going to have to hire to support some feature?
13:46:22 [JeniT]
shadow-com spec doesn't say anything about <element>, I guess it's somewhere else
13:46:28 [JeniT]
s/shadow-com/shadow-dom/
13:47:31 [JeniT]
ah https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
13:47:53 [marcosc]
yehuda: we should allow people to make little registries
13:48:04 [annevk]
JeniT, yes
13:48:42 [marcosc]
noah: there was a time when there were multiple element (image/img), eventually one won
13:48:57 [JeniT]
annevk, I thought I saw a primer once
13:49:17 [annevk]
JeniT, https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
13:49:24 [annevk]
JeniT, I think
13:49:31 [marcosc]
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-"
13:50:00 [marcosc]
yehuda: we should consider how to allow people to create things without "-"
13:50:12 [JeniT]
annevk, yes that was it
13:50:57 [marcosc]
annevk: "x-" is for browsers. It's a user agent or server layer instead of the app layer.
13:52:09 [marcosc]
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.
13:52:25 [marcosc]
alex: it might be an opportunity
13:53:18 [marcosc]
noah: I don't believe the damage is zero, because there might be a place for globally unique identifiers for these
13:53:58 [marcosc]
timbl: there are two ways this can go: 1. to get stuff into html, 2. it becomes a modular programming system.
13:54:44 [Norm]
Norm has joined #tagmem
13:56:25 [marcosc]
[discussion around dependencies, dll hell vs debian dependencies]
13:58:24 [dka_]
q?
13:58:32 [dka_]
q?
13:59:48 [marcosc]
dan: I'm interested in getting some action items. How do we move forward with all this great stuff?
14:00:39 [ht]
ack next
14:00:41 [Zakim]
JeniT, you wanted to ask what it is the TAG should do
14:01:39 [marcosc]
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?
14:03:07 [marcosc]
JeniT: 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
14:03:27 [marcosc]
JeniT: is this what you guys (alex, yehuda) had in mind?
14:03:37 [marcosc]
yehuda: yes
14:03:40 [marcosc]
alex: yes
14:04:31 [marcosc]
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.
14:05:13 [marcosc]
plinss: what JeniT is suggesting is that we identify the underlying extensibility points
14:05:39 [marcosc]
JeniT: it would be useful in a document to specify through different examples
14:06:23 [marcosc]
yehuda: when we notice something like fetch, we should make sure that groups don't redefine things over and over
14:07:23 [marcosc]
alex: trying to find the right point at which to target their API (high low level)... this is hard to do.
14:07:39 [ht]
ack next
14:07:40 [Zakim]
ht, you wanted to ask why you're using a new tag
14:07:44 [marcosc]
JeniT: it might be easier to do that if we have some document the describes this
14:08:09 [marcosc]
plinss: this also ties in with working with other working groups
14:08:13 [ht]
s/ht, you wanted to ask why you're using a new tag/[overtaken]/
14:08:28 [marcosc]
plinss: it's our role to provide guidance wrt architecture
14:08:33 [marcosc]
plinss: to other groups
14:08:45 [marcosc]
dan: so, how does that translate into actions
14:09:02 [slightlyoff]
annevk: from me, with love: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/firefox/create_fails.md
14:09:36 [annevk]
slightlyoff: why is URL there?
14:09:39 [annevk]
slightlyoff: or Text?
14:09:52 [annevk]
slightlyoff: or ProcessingInstruction or the others I mentioned earlier?
14:09:57 [marcosc]
ACTION: yehuda and alex will create an initial draft of high level view/survey and how they relate to system capabilities
14:09:57 [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].
14:10:15 [JeniT]
ah, from previous meeting: https://gist.github.com/wycats/5205250
14:10:42 [slightlyoff]
annevk: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/firefox/create.html#L437
14:10:52 [slightlyoff]
dka_: lawls.
14:10:57 [marcosc]
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
14:11:13 [annevk]
slightlyoff: I see, you're using a browser
14:11:23 [annevk]
slightlyoff: well yeah, they're broken
14:11:34 [slightlyoff]
noah: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
14:11:39 [marcosc]
[BREAK]
14:11:48 [annevk]
(although nightlies are getting better)
14:11:52 [slightlyoff]
noah: in particular https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#shadow-dom-section
14:12:12 [slightlyoff]
annevk: feel free to send me edits to the md file
14:36:30 [dka_]
dka_ has joined #tagmem
14:40:43 [noah]
noah has joined #tagmem
14:48:17 [marcosc]
TOPIC: capability URLs
14:49:31 [marcosc]
[JeniT presents slides: http://w3ctag.github.io/presentations/reveal/capability-urls.html]
14:55:38 [slightlyoff]
annevk: moved the file: https://github.com/slightlyoff/ZOMGWebIDL/blob/master/create_fails.md
14:56:30 [annevk]
slightlyoff: so, I don't think I'm going to go through that thing again and edit it for now
14:56:44 [annevk]
slightlyoff: it's useful enough as is
14:56:49 [slightlyoff]
oh, you had edited it?
14:56:55 [slightlyoff]
annevk: send me your edit
14:57:10 [annevk]
no haven't
14:57:24 [annevk]
sorry for the confusion, meant to look through it and remove those that are handled by specs
14:57:30 [slightlyoff]
oh, OK
14:57:33 [slightlyoff]
I can do that
14:59:42 [marcosc]
[JeniT presents slides... Web Arch... ]
15:00:00 [marcosc]
annevk: I feel like you are conflating a whole bunch of stuff together in this slide
15:00:18 [marcosc]
noah: a fair amount is explained in the document
15:00:35 [marcosc]
JeniT: I agree, there is more to go into there..
15:00:56 [marcosc]
Slide - beyond single page
15:01:07 [marcosc]
slide - recommendations
15:01:16 [marcosc]
slide - application design
15:01:26 [annevk]
So it seems the architecture concern doesn't apply here: http://www.w3.org/TR/webarch/#uri-aliases
15:01:34 [annevk]
It talks about network effects, but here you want to keep them secret
15:01:38 [marcosc]
JeniT: we should make some recommendations about this (we === tag)
15:01:45 [annevk]
So you don't want network effects :)
15:01:54 [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.
15:02:09 [marcosc]
slide - capability URL design
15:02:31 [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
15:02:34 [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.
15:03:22 [marcosc]
yehuda: there are not good answers to these problems. I don't know the answer.
15:03:31 [marcosc]
JeniT: that's what makes it interesting work
15:03:36 [Yves]
ht, as they are not reaching proxies, that's normal
15:04:11 [marcosc]
yehuda: I can live with password resets, and emailed URLS... but accessing gists, etc. is not so good.
15:04:19 [ht]
Yves, where is _that_ noted? All I see is that the trajectory must be secured from end to end. . .
15:04:22 [noah]
From Web arch:
15:04:30 [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
15:04:30 [noah]
book is published), otherwise they are free to exchange them."
15:04:31 [marcosc]
JeniT: the document may describe the implications
15:04:40 [marcosc]
JeniT: if you do X, then Y may happen
15:04:48 [ht]
q+ to talk about actually secure capability URI designs
15:05:21 [marcosc]
yehuda: it's a problem that URLs can be leaked when they are supposed to be private
15:06:45 [marcosc]
[conversation about issues]
15:07:10 [ht]
ack next
15:07:11 [Zakim]
ht, you wanted to talk about actually secure capability URI designs
15:07:12 [dka_]
q?
15:07:13 [marcosc]
yehuda: it's a real failing that people can leak the urls
15:07:20 [noah]
q?
15:07:39 [marcosc]
ht: there are strategy to address this issue, but it's complicated.
15:08:51 [marcosc]
ht: 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.
15:09:17 [Yves]
ht, see rfc2818 for https
15:09:21 [marcosc]
ht: these things exist, but they are complicated.
15:10:33 [marcosc]
ht: it's often a 3 actor situation ... or a trusted 4th party. This stuff is a bit of rocket science right now, so I suggest that we don't publish anything that doesn't acknowledge existing capability systems.
15:11:19 [ht]
s/so I/but I do/
15:11:26 [marcosc]
noah: the ones that I've seen are built on systems similar to unix
15:11:58 [dka_]
q?
15:12:33 [marcosc]
[discussion about various types of capability systems]
15:13:42 [marcosc]
dan: what we are talking about here is to help people do what they are doing already
15:13:47 [noah]
q?
15:13:50 [noah]
q+ noah
15:14:02 [marcosc]
alex: is this something that we should encourage them to do?
15:14:13 [marcosc]
annevk: we should document the concerns around this
15:14:22 [marcosc]
dan: some of the best practices
15:15:11 [marcosc]
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.
15:15:12 [dka_]
ack noah
15:15:46 [marcosc]
noah: there is an obligation for the TAG to clarify this for user agents, or proxies, to handle this.
15:16:10 [marcosc]
noah: and you need to explain how to do this without for example using a HTTP header or some other solution
15:16:22 [dka_]
q+
15:16:51 [marcosc]
noah: I expect to be able to mail URLs, but there should be some level of protection at the UA level
15:17:13 [marcosc]
yehuda: there is certainly a social norm issue of sharing URIs
15:18:01 [dka_]
ack me
15:18:02 [noah]
q-
15:19:14 [marcosc]
dan: before we start making recommendations, it seems to me that there are some best practices around capability URLs that could be documented.
15:19:37 [marcosc]
s/start making recommendations/start making recommendations to UAs and proxies/
15:19:38 [ht]
Yves, HTTPbis explicitly says it supersedes 2818
15:19:44 [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.
15:20:16 [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.
15:20:38 [marcosc]
annevk: I still want these things cached (or still be in location bar)
15:20:43 [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
15:21:24 [ht]
Yves, ah, not supersedes, but updates
15:21:25 [marcosc]
timbl: capability urls are relatively rare when compared to other urls
15:21:42 [marcosc]
ht: I used two today
15:21:47 [ht]
Yves, hmm, really not clear what's still normative in 2818 and what's overtaken
15:21:52 [ht]
s/today/yesterday/
15:21:56 [Yves]
indeed
15:22:15 [marcosc]
timbl: so you are suggesting best practice aimed at web devs, as opposed to UAs and proxies
15:22:27 [marcosc]
dan: What existing material is out there that we could build on?
15:22:51 [marcosc]
JeniT: there are some links in the slides, which is what I've found through searching
15:23:50 [marcosc]
dan: do we know if there are any internal recommendations about capability URLs?
15:24:00 [marcosc]
annevk: I suspect not
15:24:30 [marcosc]
JeniT: maybe Google has something?
15:24:52 [marcosc]
annevk: the links in the presentation are from google guys
15:26:02 [marcosc]
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.
15:26:28 [marcosc]
dan: JeniT, are you proposing to be an editor of this?
15:26:35 [marcosc]
JeniT: yes
15:26:41 [marcosc]
annevk: I'm happy to help review stuff
15:27:16 [marcosc]
plinss: do you see this as being a note or rec track doc?
15:27:37 [marcosc]
JeniT: right now, it's just about writing up stuff... we can decide what to do with it later
15:27:46 [marcosc]
plinss: I'm interested in scope
15:27:53 [marcosc]
plinss: is all
15:28:16 [marcosc]
JeniT: that's all I need
15:29:04 [Norm]
Norm has joined #tagmem
15:29:21 [marcosc]
ACTION: Jeni to create a first draft of capability document guidelines
15:29:21 [trackbot]
Created ACTION-810 - Create a first draft of capability document guidelines [on Jeni Tennison - due 2013-06-05].
15:29:40 [marcosc]
alex: do we have consensus if we want to do this?
15:30:06 [marcosc]
annevk: we should describe the landscape
15:30:49 [marcosc]
dan: one of the early slides said that this contravenes WebArch.. is that something that should be discussed.
15:30:57 [marcosc]
timbl: that is one of the least worrying bits
15:31:43 [marcosc]
noah: I happen to like this rule... lets chip away at Web Arch
15:31:55 [marcosc]
s/lets/let's
15:32:18 [marcosc]
noah: I think it would be good to enhance web arch with regards to this matter
15:32:45 [marcosc]
noah: either explain don't do that, or explain the trade off
15:41:47 [JeniT]
yehuda: there's one thing that people could do, which is have a one-off capability URL that upgrades to a cookie
15:42:20 [JeniT]
alex: there's a strong timing component, usually they should be short-lived
15:43:01 [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
15:44:06 [marcosc]
TOPIC: HTTP Bis
15:45:59 [marcosc]
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.
15:47:08 [marcosc]
ht: 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.
15:48:01 [marcosc]
ht: 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
15:48:18 [marcosc]
ht: if there is a difference, then how should those differences be expressed?
15:49:06 [marcosc]
ht: 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?
15:49:54 [marcosc]
ht: 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
15:50:13 [marcosc]
ht: I will send the email to the public list soon
15:50:34 [marcosc]
ht: Roy has added more language about REST.
15:51:00 [marcosc]
yehuda: I'm lacking context about REST... i know what it is, but how does it relate to this?
15:52:18 [marcosc]
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]
15:55:47 [marcosc]
ht: ... at the end of the day, this only really matters for spec weenies what URIs mean.
15:56:32 [annevk_]
annevk_ has joined #tagmem
15:56:32 [marcosc]
ht: devs are really only interested in operational stuff like status codes, cache control.
15:57:56 [marcosc]
ht: 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?
16:00:09 [marcosc]
ht: 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.
16:01:32 [marcosc]
ht: the spec assumes human expectations about how people use URIs
16:01:54 [marcosc]
ht: but there are all sort of assumptions about what people do
16:02:07 [annevk]
annevk has joined #tagmem
16:02:24 [marcosc]
ht: I'm going to send a few comments back to the HTTP bis WG. But is there other stuff I should do?
16:02:53 [marcosc]
ht: one of the things people would like to know, when I get a 200?
16:02:59 [marcosc]
annevk: that's it's OK?
16:03:08 [marcosc]
[room laughs]
16:03:23 [marcosc]
ht: but what does that mean as a social contract?
16:03:42 [marcosc]
timbl: but to make this part of the TAG, we need to look at the applicability of this
16:04:31 [marcosc]
ht: right now, it's not clear what the semantics are with regards to method
16:05:30 [marcosc]
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
16:05:58 [marcosc]
noah: it's good to be clear about the semantic difference between GET, POST, etc.
16:06:35 [marcosc]
noah: it's a bit of a grey area, so you have to be careful about what is defined
16:08:16 [marcosc]
[discussion about philosophy behind different GETs]
16:09:49 [JeniT]
[annevk's conneg rant]
16:09:50 [marcosc]
[discussion about conneg...]
16:10:10 [JeniT]
[wycats_'s pro conneg rant]
16:10:35 [marcosc]
[...interpretive dance about bags of bits.... ]
16:13:37 [marcosc]
dan: we might have a TAG deliverables that updates URLs and URIs and discusses that
16:14:05 [marcosc]
ht: I have a working title: "what would it be like to document what is true about URLs?"
16:15:11 [marcosc]
ht: asking them to get rid of philosophising would be counter productive
16:15:37 [marcosc]
s/them/the HTTP Bis WG/
16:16:06 [marcosc]
ht: what I am reviewing is just a clarifications of HTTP 1.0 - it's a cleanup
16:18:40 [wycats_]
I assume you mean 1.1?
16:18:55 [annevk]
yes
16:19:02 [marcosc]
s/HTTP 1.0/HTTP 1.1
16:19:37 [marcosc]
TOPIC: F2F Planning
16:20:01 [marcosc]
13-15 Oct at MIT
16:20:27 [marcosc]
noah: 13-15 Oct at MIT, we also identified, week of Jan 06.
16:26:35 [marcosc]
[discussion about TPAC, Marcos being booted from the tag, etc. ]
16:35:37 [dka_]
dka_ has joined #tagmem
16:35:51 [JeniT]
Jan 7-9 in Europe
16:42:25 [marcosc]
TOPIC: Polyglot
16:42:41 [marcosc]
ht: we've said everything we want to say.
16:42:58 [marcosc]
yehuda: I think we reached consensus on this already
16:43:13 [marcosc]
ht: is there a link to the discussion?
16:44:19 [JeniT]
https://lists.w3.org/Archives/Member/tag/2013Apr/0046.html
16:44:26 [marcosc]
ht: the background is that Paul Cotton asked to clarify where we are at
16:45:07 [ht]
http://www.w3.org/2001/tag/group/track/actions/791
16:45:47 [marcosc]
yehuda: we all agreed that we can all live with the proposed text.
16:46:27 [marcosc]
ht: we should consider Larry's feedback
16:46:49 [marcosc]
annevk: I don't agree with the change Larry suggests. I think it's wrong
16:46:58 [marcosc]
yehuda: I agree.
16:47:08 [marcosc]
annevk: it could be clearer
16:47:53 [JeniT]
email should s/wether/whether/
16:48:40 [marcosc]
annevk: it would be clearer if with xhtml mime type you use xhtml, and with html mime type you use html
16:49:48 [marcosc]
ht: if we could capture the above in the proposed text, then that would be great.
16:49:48 [annevk]
see also http://html-differences.whatwg.org/#syntax which describes that
16:51:09 [ht]
My proposed change "using HTML5 syntax and mediatypes (either HTML syntax and text/html, or XHTML syntax and application/xhtml+xml"
16:55:17 [marcosc]
yehuda: in the Web Arch document there is a section that talks about the content-type in normative terms that don't match reality.
16:56:11 [annevk]
http://www.w3.org/TR/CSS1/
16:56:11 [marcosc]
ht: we can't just change the spec in place
16:56:24 [noah]
What change to what spec is being proposed?
16:56:44 [Yves]
it's actually a new spec
16:57:05 [ht]
http://www.w3.org/2001/tag/webarch/errata.html
16:57:06 [noah]
I thought Yehuda said: "Published spec XXX says MUST" which one?
16:57:22 [marcosc]
http://www.w3.org/TR/webarch/
16:57:36 [marcosc]
yehuda: section 3.3
16:57:46 [annevk]
"Agents MUST NOT ignore message metadata without the consent of the user."
17:00:06 [marcosc]
noah: the TAG should take a strong line that normative spec should be followed.
17:00:47 [marcosc]
noah: it would be better to get the normative text updated in the appropriate spec
17:00:48 [ht]
Stand by for HTTPbis:
17:00:50 [ht]
In practice, resource owners do not always properly configure their
17:00:50 [ht]
origin server to provide the correct Content-Type for a given
17:00:50 [ht]
representation, with the result that some clients will examine a
17:00:50 [ht]
payload's content and override the specified type. Clients that do
17:00:50 [ht]
so risk drawing incorrect conclusions, which might expose additional
17:00:50 [ht]
security risks (e.g., "privilege escalation"). Furthermore, it is
17:00:50 [ht]
impossible to determine the sender's intent by examining the data
17:00:51 [ht]
format: many data formats match multiple media types that differ only
17:00:51 [ht]
in processing semantics. Implementers are encouraged to provide a
17:00:51 [ht]
means of disabling such "content sniffing" when it is used.
17:02:46 [marcosc]
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.
17:02:52 [ht]
trackbot, Action-791?
17:02:52 [trackbot]
ACTION-791 -- Alex Russell to redraft proposed "status" section that TAG is suggesting for Polyglot -- due 2013-04-16 -- OPEN
17:02:52 [trackbot]
http://www.w3.org/2001/tag/group/track/actions/791
17:03:00 [ht]
trackbot, close action-791
17:03:00 [trackbot]
Closed ACTION-791 Redraft proposed "status" section that TAG is suggesting for Polyglot.
17:03:11 [marcosc]
Dan: so, Polyglot can be closed.
17:07:26 [marcosc]
[MEETING ADJOURNED]
17:10:27 [marcosc]
marcosc has joined #tagmem
17:21:34 [Zakim]
Zakim has left #tagmem