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