12:56:54 RRSAgent has joined #tagmem 12:56:54 logging to http://www.w3.org/2011/06/06-tagmem-irc 12:57:01 zakim, this is tag 12:57:01 sorry, ht, I do not see a conference named 'tag' in progress or scheduled at this time 12:57:37 scribenick: ht 12:57:40 Ashok has joined #tagmem 12:57:51 meeting: Technical Architecture Group 12:58:17 Scribe: Henry S. Thompson 12:58:27 Chair: Noah Mendelsohn 12:59:12 Agenda: http://www.w3.org/2001/tag/2011/06/06-agenda.html 12:59:31 Topic: Agenda review 13:02:01 Scribe page: www.w3.org/2001/tag/20011/06/F2FScribing.html 13:03:04 ^ http://www.w3.org/2001/tag/20011/06/F2FScribing.html 404 not found 13:03:20 s/20011/2011/ 13:03:23 s/20011/2011/ 13:03:28 s/2001/2011/ 13:03:33 http://www.w3.org/2001/tag/2011/06/F2FScribing.html 13:04:26 jar has joined #tagmem 13:04:28 zakim, who is here? 13:04:28 sorry, ht, I don't know what conference this is 13:04:29 On IRC I see jar, Ashok, RRSAgent, noah, timbl, Zakim, ht, masinter, JeniT, jeff, DKA, Norm, plinss_, Yves, trackbot 13:04:33 zakim, who is on the call? 13:04:33 sorry, ht, I don't know what conference this is 13:04:35 On IRC I see jar, Ashok, RRSAgent, noah, timbl, Zakim, ht, masinter, JeniT, jeff, DKA, Norm, plinss_, Yves, trackbot 13:04:58 Zakim, imagine this is a call. There everyone is here in the room. 13:04:58 I don't understand you, timbl 13:04:59 NM: Minutes of 26 May [http://www.w3.org/2001/tag/2011/05/26-minutes] approved 13:05:07 You will, Zakim, you will. 13:05:25 http://www.w3.org/2001/tag/products/htmlxmlunification.html 13:06:06 NM: I've been moving to using tracker Product pages (above is example) to organize our work on major topics 13:06:25 ... This is an attempt to move up a level from just using Actions 13:06:40 http://www.w3.org/2001/tag/products/htmlxmlunification.html is lacking standard info for a web page/document: date, author, pointer to context 13:07:00 maybe there should be a "TAG product" template 13:07:18 NM: This approach is still novel, and I'm working on expanding and using it 13:07:34 ... I've added a new feature recently 13:07:51 ... which allows us to see who is working on what in a single place 13:08:23 ... ProductAssignments.{xls,pdf} 13:09:10 http://www.w3.org/2001/tag/products/assignments 13:10:34 NM: Concerned that we are getting into a write-only mode 13:10:36 q+ to talk about giving TAG more power, such as hearing appeals and getting involved early in WG chartering and do more 13:10:51 NM: That's better than not writing at all 13:10:59 ... but we need to do more reading and reviewing 13:11:54 NM: JJ has asked many different parts of W3C to come back to him with their two or three main goals for 2011 13:12:26 ... We need to do that, bearing in mind that some of our top-level goals are not expected to deliver before the end of the years 13:13:26 TBL: Suppose NM ends up with 6 or a dozen Products, which will be well-described with timetable info -- is that better for you, JJ, than us picking just two or three of them? 13:13:37 Topic: Meeting with Jeff Jaffe 13:13:50 DKA has joined #tagmem 13:14:51 JJ: A slight correction to NM's starting point -- I don't view the TAG in quite the same way as other parts of W3C -- I don't have a major role in setting the TAG's priorities 13:15:02 ... The TAG is necessarily mostly autonomous 13:15:23 JJ: So my request is more about what I hope the TAG will be doing 13:15:37 ... I like NM's new approach to tracking progress 13:15:45 I think the TAG is not nearly as effective as it could be, partly because there isn't enough external feedback and requirements from W3C 13:15:54 JJ: and I laud the work that's been done already. 13:16:10 JJ: The TAG needs to do big things _and_ small things 13:16:22 ... but be careful not to let too many small things fill all their time 13:17:04 i don't think "big" and "small" are the right criteria. There are "important" and "unimportant" and we should try to make sure the TAG is doing important things. 13:17:08 DKA_ has joined #tagmem 13:17:09 JJ: In strategizing for the W3C, we distinguished between topic areas, such as Privacy, and year-by-year goals, such as having a Workshop 13:17:30 some "small" things can be important, and some "big" things can be unimportant 13:17:59 NM: For us, I think that translates as trying to identify some specific areas where we expect to get closure in the current year 13:20:06 JJ: I'm very pleased with the most recent TAG Status Report 13:20:29 ... which stimulated me to think about what I _need_ from the TAG 13:20:56 JJ: What's the next thing that's going to challenge our ability to have a clean, standard, Web? 13:21:31 JJ: And wrt the fissures we've identified, what can do to fix them? 13:21:36 TAG Status report: http://www.w3.org/2001/tag/2011/sum04 13:22:28 q? 13:23:23 ack masinter 13:23:23 masinter, you wanted to talk about giving TAG more power, such as hearing appeals and getting involved early in WG chartering and do more 13:23:26 timbl has joined #tagmem 13:27:59 q+ to speculate about how we got blindsided on [...] 13:28:34 q+ to respond to Jeff on things like md 13:29:52 q? 13:30:15 LM: I wanted to talk about doing more rather than less 13:30:31 ... important vs. unimportant is better than big vs. little 13:30:47 LM: For example, getting involved earlier in chartering discussion 13:31:15 ... Scoping of WGs is actually crucial to architecture 13:31:31 ... because the one tends to determine the other 13:31:46 ... So having multiple WGs with charters to design metadata, for example 13:31:57 ... leads to multiple metadata mechanisms 13:32:24 LM: We have a work item called Metadata Architecture 13:32:40 ... and trying to produce an overview document 13:32:41 q? 13:33:11 ... but that has been to some extent stalled because we're not involved more directly in the WGs 13:34:15 JJ: Charter drafts go to the AC for review, the TAG could request from the AB that the TAG should be a virtual AC rep for those purposes 13:34:45 LM: I want the staff to use us as a resource _before_ things ever get to the AC 13:34:53 Ashok has joined #tagmem 13:35:00 q+ 13:35:06 ... to help prevent things which cut across web arch in unfortunate ways 13:35:33 JJ: The Team using the TAG as a consultant is an interesting idea 13:36:02 ... but charter content decisions are not always made solely on technical grounds 13:36:12 ack next 13:36:13 ht, you wanted to speculate about how we got blindsided on [...] 13:37:19 HT: History is complicated. Illustrative in one respect. The TAG got involved, made suggestions to the WG, worked hard and in detail 2 years. There came a point at which we concluded that we had done what we could. 13:38:24 DKA has joined #tagmem 13:40:20 ack next 13:40:22 noah, you wanted to respond to Jeff on things like md 13:40:47 Ashok has joined #tagmem 13:40:55 NM: The kind of advice you've asked for opens up something new for us 13:41:33 q+ to find out Noah's 14 other things 13:41:51 jar has joined #tagmem 13:43:06 NM: We often come up to a wall on certain issues 13:43:23 ... When to escalate something to you is going to be a hard call for us 13:43:31 q? 13:43:35 ack next 13:44:13 q+ to talk about responsibility without authority 13:44:21 TBL: I agree with Larry's (also ?? Brooks's) observation about web arch recapitulating WG structure 13:44:47 ... So getting involved with the WG chartering thing looks important 13:44:57 s/Brooks/Fred Brooks/ 13:45:07 s/?? // 13:46:08 TBL: Looking forward rather than back, we need to find a way to get more engaged tactically 13:46:17 getting the TAG to say things may not be nearly as effective as working directly with the communities otherwise affected? 13:46:35 q? 13:46:37 q+ 13:46:37 ack next 13:46:40 jeff, you wanted to find out Noah's 14 other things 13:47:35 JJ: NM asserted there were many cases where the TAG stopped after making the technical point, despite (or because) not having succeeded in changing things 13:48:55 q+ to say there are only a few big ones 13:49:24 q+ ht2 to point out we won one 13:49:43 q+ to give a different analysis 13:50:21 ack next 13:50:22 noah, you wanted to talk about responsibility without authority 13:50:36 JJ: I'm asking the TAG to help me spot major difficulties as early as possible 13:51:26 NM: Not sure if we had had this steer three years ago, we would have been able to do anything different 13:53:26 q? 13:53:33 q? 13:54:07 NM: To a large extent, we have responsibility w/o authority 13:54:52 ... Our only authority is indirect, via TBL's presence on the TAG, and is the ultimate arbiter of what goes forward [to REC, as a WG, ...] 13:55:30 JJ: And as we can observe, TBL's power is in practice very limited 13:55:56 q? 13:57:01 JJ: You can't tell me that I don't need what I need -- your ability to effect change is orthogonal to that 13:57:20 JJ: I hear that what I'm asking is hard 13:58:17 q+ 14:00:00 JJ: The TAG could say "There are 10 things we see that might require the CEO's attention -- which of these did you know about already?" 14:08:41 q? 14:08:50 jar+ 14:09:00 q? 14:09:06 q+ to ask about #! 14:10:44 q+ to ask why staff discussion of metadata architecture is disconnected from TAG discussion of metadata architecure 14:12:49 ack next 14:13:32 DKA: 14:16:19 wonder if we should have a W3C workshop on metadata architecture 14:17:09 q+ to talk about centralization and social aspects being in scope 14:17:38 ack next 14:17:40 ht, you wanted to say there are only a few big ones 14:18:58 ack next 14:18:59 ht2, you wanted to point out we won one 14:19:34 ack next 14:19:36 masinter, you wanted to give a different analysis and to ask why staff discussion of metadata architecture is disconnected from TAG discussion of metadata architecure 14:20:53 LM: If we can identify places where the Team are discussing a topic, and the TAG have something on the go in that area, without making the connection -- we should try harder to avoid that in future 14:21:09 s/If we can identify/There have been/ 14:23:13 ack next 14:24:19 AM: Rigo Wenning compared the TAG to the European Human Rights Commission -- no formal authority, but a lot of influence, because they produce well-written, well-thought out analyses 14:24:22 q? 14:24:46 ack next 14:24:47 noah, you wanted to ask about #! 14:27:08 NM: One thing we might do, two -- four times a year, is to prepare a written note to JJ with a consensus view of what we thing might need your attention. 14:27:48 ... This would allow me to assign a responsible person to get it moving, give us the opportunity to comment/expand/etc. 14:28:17 NM: It would be great to get some early input from JJ as to what he's already aware of 14:28:35 JJ: Yes, that sounds like a good idea, but 14:28:57 ... twice a year is certainly enough, maybe too much 14:29:19 ... I can live with as long a list as possible, but would urge you to _try_ to make it as small as possible 14:29:44 I'd rather see W3C management/staff ask the TAG for help in bringing an architectural perspective to issues; I'm not sure the TAG is the right canary to raise warnings about topics 14:30:25 JJ: I'm willing to let you know in advance what I'm focussing on, but I'm somewhat reluctant 14:31:07 q? 14:31:11 ... Because my saying "I'm working on topic X" may be misunderstood, if you think sub-topic X.Y is the new crucial thing 14:31:17 TAG started some architectural work on security, and we're struggling with how to make progress on that with the upcoming W3C work on security and IETF etc. 14:31:17 ack next 14:31:21 q? 14:31:26 NM: But I'm looking at X.Z 14:33:19 ack next 14:33:20 timbl, you wanted to talk about centralization and social aspects being in scope 14:34:18 TBL: Pushing good architecture is necessarily a centralized activity 14:34:57 . ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F 14:34:59 q? 14:35:00 ... but what we _want_ is decentralized -- we have to accept that this means being aware of 14:35:01 q+ to push on scheduling workshops on topics with the TAG responsible for documenting architectural findings based on workshop work 14:35:12 q+ just brief comment 14:35:21 q+ to say just a brief comment 14:35:25 .. the financial and political is a crucial aspect of architecture 14:35:34 ... because they drive decentralized activity 14:36:29 +1 TBL, this is what I wanted to say. architecture has social and economic goals; can't be "just technical". we favor designs that create and nourish markets, innovation, openness, inclusion 14:36:59 . ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F 14:37:00 and that staff should bring TAG in, rather than TAG proposing pushing in 14:38:00 TBL: I think a report is too formal, a meeting would be better 14:38:09 HST: I'd like to try a report once to see . . . 14:38:48 LM: I don't think the TAG is a very good canary -- better to have the Team come to us with problem aras they would like our input on 14:39:10 JJ: We don't need anything new to enable that. . . 14:40:44 i have no objection to Noah doing what Noah proposes, I just don't think it's enough 14:41:05 ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 14:41:05 Created ACTION-563 - Arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 [on Noah Mendelsohn - due 2011-06-13]. 14:41:48 ACTION-563 Due 2011-09-15 14:41:48 ACTION-563 Arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 due date now 2011-09-15 14:42:06 ack dka 14:42:06 DKA, you wanted to say just a brief comment 14:42:31 ack masinter 14:42:31 masinter, you wanted to push on scheduling workshops on topics with the TAG responsible for documenting architectural findings based on workshop work 14:42:34 q? 14:42:42 DKA: I also agree that we mustn't ignore the social/financial dimension 14:43:19 ... just that in the case under discussion, it's difficult to disentangle those from the technical side 14:44:08 Topic: ISSUE-60 (webApplicationState-60): Web Applications: Client-side state 14:44:28 http://www.w3.org/2001/tag/group/track/issues/60 14:46:23 NM: I've reviewed this from end-to-end, I'm concerned that some of the new material is not consistent with the earlier, introductory material. 14:46:35 jeff_ has joined #tagmem 14:47:21 DKA: What is the next step, officially? 14:47:57 NM: If it's a finding, there is no 'officially'. If we go to REC track for this, then yes, we have to go through the usual hoops 14:48:32 DKA: Even informally, we could ask for wider review explicitly, beyond just sending to www-tag 14:48:53 NM: Ah, JAR points out that we already published TVR's first draft of this as a WD 14:49:58 http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110515.html 14:57:06 NM: Review, by sections, march! 14:57:06 q+ to talk about generalizing to all "active content" (e.g., PDF fragment identifiers) 14:58:18 NM: Abstract 14:58:18 ack next 14:58:21 masinter, you wanted to talk about generalizing to all "active content" (e.g., PDF fragment identifiers) 14:58:42 LM: Active content is the key enabling/context for what we're talking about 14:59:02 ... We should broaden this prose out to make this clear 14:59:22 ... HTML + Javascript is common and important, but not the only example 15:00:28 ... SVG, PDF, even Java 15:00:53 NM: Java is different -- there's no document there. . . 15:01:22 TBL: Abstracts should cover the entire document, not just the problem statement 15:01:36 ... So, specifically, include the headline conclusion 15:02:37 NM: Should be an Editor's Draft, not a WD (yet) 15:02:43 NM: Introduction 15:03:27 NM: Doesn't include the comparison between # and other approaches 15:03:47 DKA: Needs to be more friendly 15:04:33 LM: Strongly disagree with "Fragment identifiers can be used with other protocols such as FTP where they may have different semantics" 15:05:00 NM: Protocols _are_ relevant 15:05:53 ... The protocol is where the use of media type is made explicit 15:06:37 take IMAP for example 15:07:04 if I send you an email with an embedded HTML and it contains fragment identifier relative references, the meaning of the fragement identifier 15:07:16 TBL, others: Not protocols 15:07:38 JAR: Let's just remove the paragraph 15:07:58 content-type sniffing redefines how media types are used anyway 15:08:39 ... the meaning of the fragment identifier is independent of the protocol used to transfer the content, and applies to file: and ftp: as well 15:08:44 (that is, remove the paragraph mentioning FTP) 15:08:57 NM: Chapter 2 15:09:16 also don't like URI and URL should also say IRI etc. 15:09:25 NM: Should be opened up, as for Introduction 15:09:38 Section 2 sentence shouldn't just be about fragment id use cases 15:11:28 JT: 2.1, table -- are we justified in introducing this new label "Client Parameter" ? 15:12:09 NM: Right, these (mostly) mean what they mean, not just client-side 15:12:23 I think the actual use case is a pun -- it is a 'client side parameter' to identify a fragment 15:12:58 just as paths kind of look like file paths, but they're really just arbitrary server side parameter to web server 15:13:57 LM: It's an identifier independent of context, but it's _also_ being used client-side as a parameter 15:14:28 LM: Similar to path, actually -- just a string, but looks like a file-system path, and is often implemented that way 15:15:00 it's not "client and server" it's "active content" vs. "active services" 15:15:25 NM: So need to clarify that this terminology is just for this use case 15:16:10 Larry, what about http://example.org/myfile.html#para1 15:16:12 LM: Again, this is about active content, for which the fragid is intended 15:17:06 ... So I'd be happier with 'active content interpreter', rather than 'client' 15:18:03 LM: The larger background is the whole move to the hybrid model 15:18:14 ... With its own security model 15:18:53 Larry, what about http://example.org/myfile.html#para1 15:19:07 NM: In moving to active content, do need to note that you can't tell by inspection whether a fragid is going to be actively interpreted 15:19:41 ... It may vary over time 15:19:58 I think text/html now requires javascript and thinking otherwise is just wishful thinking 15:20:03 DKA: Or vary per platform 15:20:15 Ashok, it's crucial you point out that you can't tell from the URI whether the fragment is interpreted by active content AND that the answer might change on successive retrieval 15:21:06 ---------- 15:23:27 NM: 2.2 15:24:07 TBL: "Retrieving fragments using time ranges (for time fragments) may be done heuristically" -- need to know what the heuristics are based on 15:24:13 not sure the map viewer example might just confuse people... might need more context, e.g., that it was done before the "?" pattern was done, before web forms 15:24:51 TBL: And what are they guessing heuristically? 15:24:53 TBL: You need to rewrite the mention of heuristic retrieval of video 15:25:08 editorial: section 2.3 uses "URI" and "URL" both 15:25:10 TBL: Clarify what sorts of heuristics 15:25:52 AM: I'll rewrite the 3rd paragraph 15:25:54 JeniT has joined #tagmem 15:26:06 ------------ 15:26:10 NM: 2.3 15:26:15 wonder if geo: URI scheme is relevant 15:26:25 LMM: Section 2.3 para 3 map viewer might confuse people? 15:26:43 LM: Map viewer example -- need more history, to explain e.g. why ? wasn't used 15:27:44 Maybe not, would like someone else's review of it. I know too much about PARC map viewer 15:29:13 NM: At the point you introduce Google Maps, include that there are _two_ ways to browse: 15:29:28 example in document of https://mail.google.com/mail/?shva=1#inbox/12c7e6abbc328af4 doesn't resolve to anything for me... doesn't explain how some URIs aren't really "Uniform", in that they don't carry application state in an interesting way 15:29:30 ... 1) For full-featured browsing with heavy AJAX; 15:29:54 The GMAIL example is an example of a kind of failure, since the URI isn't uniform, different from the CNN case 15:29:55 ... 2) Much lighter-weight implementation w/o Javascript (for mobile devices, e.g.) 15:32:05 they're RIs but not URIs 15:32:57 LM: Not just not uniform, but context-bound -- of no use outside _your_ mail reader 15:33:10 There's a URI scheme for "mid:" for identifying messages, why didn't GMAIL use that? 15:33:20 JT: And this means there are things you lose -- that can be called out 15:34:40 NM: Need to get the facts right wrt GMAIL 15:35:05 topic? 15:35:08 agenda? 15:35:31 --------- 15:35:35 NM: 2.4 15:35:54 DKA: AJAX/DHTML are not going to mean anything to some readers 15:36:26 ... Here at least include, maybe replace, but talking about Web Applications with active content 15:37:01 NM: I think Web App is worse for our readers 15:37:14 the terminology used here needs to be defined in the introduction 15:37:45 http://en.wikipedia.org/wiki/Web_application 15:37:48 the framework that there is active content and web applicaitons 15:37:49 NM: Consider a no-JS but refreshing-every-10-seconds clock page -- is this a WebApp? 15:38:13 DKA: I'm concerned to keep people from thinking "AJAX? I don't use it, so this isn't relevant to me" 15:39:00 LM: So define carefully the whole class at the beginning, then use that class here 15:39:25 LM: ... And the intro can include a bit of the history of how DHTML / AJAX figured 15:40:12 LM: Some references, here 15:40:19 AM: Right, Dojo, for example 15:41:09 LM: What is the point of this section -- maybe needs an intro sentence? 15:42:08 AM: Doing something like this requires apps to take responsibility for managing state. . . 15:42:57 TBL: "Give URIs to everything" can be extended to cover state in active-content, local-updating applications 15:45:16 --------------- 15:45:20 NM: 2.5 15:46:13 NM: Web command line 15:46:21 is an odd name 15:46:43 NM: Parallel with Meta-data in URI 15:47:35 TBL: Design of fragid so that it can be usefully typed by users, modified to modify what is returned. . . 15:47:49 NM: Change the section title? 15:48:03 LM: Expand a bit as well 15:48:40 HST: I'm happy to have multiple similar cases 15:48:46 "This is another example of the use pattern ... " 15:48:50 YL: These cases are not identical 15:48:59 and give more citations of what these are.... 15:49:26 YL: In the slidy case there is only one fetch, even as you edit 15:50:46 ... whereas the others involve multiple fetches 15:50:59 HST: Sort of, the two modes of Google Maps, in practice 15:51:05 ------------ 15:51:16 NM: So, we will return to this in a later session 15:51:26 ... I will add a Product page 15:51:39 ... We may add a second editor 15:52:33 Suspended for lunch and informal discussion with Jim Gettys on "Buffer Bloat": http://mirrors.bufferbloat.net/Talks/PragueIETF/ 15:52:57 RRSAgent, make log world-visible 15:53:04 RRSAgent, log? 15:53:04 I'm logging. Sorry, nothing found for 'log' 17:07:16 scribe: Jonathan Rees 17:07:20 scribenick: jar 17:07:47 Jim Gettys finishing up lunchtime presentation 17:08:56 TimBL: To what extent should browser UIs expose more of the error messages [possibly connected with latency]? 17:08:58 q+ to wonder about reliance on HTTP for distribution of video and staatic content, vs. e.g., Van Jacobson's Content Aware Networking etc. Is there a way of unloading HTTP traffic for video delivery 17:09:36 buffer bloat should be on TAG list to Jaffe of list of issues for W3C to track? just wondering what TAG does 17:10:26 jg: Linux has been putting a timestamp in every TCP packet 17:11:35 jg: Hard to determine which hop in a path is the bloated hop 17:12:07 timbl: Can we make testing software better? 17:12:24 ... [for detecting bloat] 17:12:59 q? 17:14:13 rrsagent, point? 17:14:13 I'm logging. Sorry, nothing found for 'point' 17:14:20 rrsagent, pointer? 17:14:20 See http://www.w3.org/2011/06/06-tagmem-irc#T17-14-20 17:15:01 jg: See new talk on youtube 17:16:57 jg: Now, about web architecture. 17:17:53 (Not scribing in detail because text on Jim's slides will do much better than I will) 17:18:40 jg: Caching is a big problem, same data being sent millions of times 17:19:02 ... because encrypted under different keys 17:19:23 ... CAs have failed 17:20:23 ... authenticity is independent of location 17:21:37 ... audio & video over TCP are futile 17:21:44 ack masinter 17:21:44 masinter, you wanted to wonder about reliance on HTTP for distribution of video and staatic content, vs. e.g., Van Jacobson's Content Aware Networking etc. Is there a way of 17:21:47 ... unloading HTTP traffic for video delivery 17:23:14 ... telephony and teleconferencing, more particularly - when there's a deadline 17:26:02 ... TCP is wrong model for web content generally. We have objects that go to many people simultaneously 17:26:15 note draft-burke-content-signature-00.txt 17:26:58 http://www.ietf.org/id/draft-burke-content-signature-00.txt 17:27:24 jg: synchronization and centralization make the system fragile 17:29:26 ... Croquet is VR without centralized coordination 17:30:10 [Apropos to our previous discussion on schema.org: http://tantek.com/2011/155/t6/schemaorg-open-standards-community-must-reject-schema-org] 17:32:26 jg: Versions should be nameable 17:33:06 ... Segments, e.g. image metadata, frames of movies 17:33:57 "Naming and synchronization in a decentralized computer system." is at http://dspace-test.mit.edu/handle/1721.1/16279 17:34:24 ... Time should be first class naming system. more recent, next one, deadlines 17:36:06 ... (this doesn't relate necessarily to buffer bloat) 17:37:02 jg: CCNx: all content is signed. everything based on names. 17:37:39 ... looking at Web on CCNx (replacing HTTP) 17:42:43 masinter: How to relate this to our conversation with Jeff, and our upcoming IAB meeting? 17:43:14 timbl: Auto fallback to P2P would be nice... 17:43:24 jg: Right, that's just what CCNx is about 17:44:28 jg: Looking for a more robust caching infrastructure 17:44:54 ... and also for new naming opportunities 17:47:17 ... the signature is not in the URI, it's the content that's signed 17:47:35 it's not really 'signature' in that signature requires ownership 17:47:56 jg: You're verifying that the content comes from someone who "owns" the URI 17:49:00 masinter: You have the problem of finding out who owned a URI 30 years later. Where do the keys come from 17:49:50 i think it's not necessary to solve the problems of identity in order to solve the problem of reliability of content delivery through unreliable channels 17:55:16 masinter: More interested in having W3C get an understanding of the problem space, than in diving into paticular possible solutions 17:55:42 s/patic/partic/ 17:56:29 http://www.ccnx.org/ 17:57:59 one of the problems with content distribution repair is realizing how much content depends on usage tracking 18:05:32 jg: http situation has been made worse by changing tcp initial congestion window from 4 to 10 18:05:59 ... httpbis has removed the SHOULD 18:06:42 masinter: The window advice really depends on context. The right place to put the advice would be an applicability statement 18:08:04 jg: the test program to run is netalyzr (see slides) 18:37:24 jeff_ has joined #tagmem 18:45:00 topic: Web Applications: Client-side state 18:48:23 Larry has joined #tagmem 18:48:45 (looking at section 3 of document) 18:50:14 jt: Security aspect. Mention that there are constraints re which URLs can be pushed into the history 18:51:24 noah: Some people have no expectation that the fragid will be meaningful outside the session 18:53:06 noah: ... say some URIs are public. there are 2 approaches, either fragid or other parts of URI 18:53:56 masinter: 'Public' is the wrong word here. Maybe 'reproducible' states (uniformly identified) 18:54:43 ... I want to quibble about 'capture'. You design the app so that the state is reproducible 18:55:08 ... (and identifiable)... it's a design thing, can't be done post hoc 18:56:09 Propose: As discussed above, JavaScript applications can choose to capture public, reproducible states using URIs, either by varying the fragment identifiers, or when modern browser interfaces are available, by altering URI query strings or path segments. 19:00:40 noah: 4 sounds like an endorsement of #! (subtext) 19:00:44 jt: "and no one seems to like it" should occur earlier, in section 4 19:01:10 masinter has joined #tagmem 19:01:40 noah: Use of word "server" is misleading. Better to say "transmitted" (e.g. email) 19:02:43 Specifically: in "In copy-and-paste situations the entire URI is sent to the server and the server can decide, based on the client's capabilities. how to respond." 19:02:49 Change to say: 19:03:14 ht: Copy-paste may be too specific, the more general situation is sending from one place to another (not necessarily on same host/client) 19:03:18 Specifically: in "In copy-and-paste situations the entire URI is transmitted." 19:03:53 ht: You email me a URI containing a #. I'm going to put it into a tool and the server won't get the fragid. 19:04:32 ashok: I'll rewrite that sentence 19:05:59 ashok: Need to publish soon, so that future tense is appropriate (i.e. before all browsers implement state() methods) 19:06:40 noah: Or say that whether this works depends on uptake. 19:07:15 jar: Take a more positive attitude, that it seems this is going to be fixed soon (not a "problem" or "unfortunate") 19:09:29 noah: Use TAGgy "good practice" boxes? 19:10:39 masinter: This is an analysis. Maybe too early to make recommendations. 19:11:38 jar: I think "good practice" boxes are mostly pretentious, seem moralistic, prefer more neutral wording 19:11:39 ht_home has joined #tagmem 19:12:17 timbL: Worth distinguishing between local benefit and global benefit. Explain why "should" 19:12:38 q+ to niggle about "public" again 19:13:28 masinter: Specs talk about compliance. 2119 language is always relative to defining compliance 19:13:47 q+ 19:14:02 noah: I like 'shoulds' 19:15:25 ht: "Public" doesn't belong here [section 5] - too strong - session specificity is OK [?] 19:16:04 masinter: It's possible to design apps that identify states or not; if you do it, that's hard, but there are benefits 19:17:38 masinter: If section 5 is generally a reprise, it should link back 19:19:06 noah: Best practice... app states identified with URIs can be tracked with browser forward/back, and can be shared, etc. etc. 19:19:14 (editor now has enough input) 19:19:55 yves: "Public" is more nuanced... 19:20:07 timbl: Granularity is important. 19:20:16 ht: need to choose the granularity that's right 19:21:05 noah: Editorially, be consistent about how much reader knows/remembers, either explain all bullets or none 19:22:56 jt: back and forward might be events you can catch 19:23:07 noah: There's no page reload, right? Isn't that the point? 19:23:18 ... (on back) 19:24:15 ... Please verify that whatever the section 5 text says is true 19:27:40 (diving into a discussion of google maps whose relevance the scribe fails to grasp) 19:29:27 (question: does google maps start with img links to the map tiles, or does are the first tiles loaded by javascript) 19:30:42 noah: The only advantage of #! is backward compatibility 19:31:07 yves: Twitter is using #! a lot because that makes things easier for server 19:31:15 twitter.com/#!abc 19:31:25 twitter.com/?id=abc 19:32:32 twitter.com/?id=dbc 19:33:05 noah: Query case is not good because it forces a page reload 19:33:23 yves: Predates the state() API 19:33:38 19:33:41 19:33:47 You can get more code reloaded than with 19:33:53 19:33:56 19:34:49 timbl: Within the page id=abc, for non js browsers, you have a link to id=abc, but you put an onclick even that intercepts 19:35:02 noah: Only works for same-page links 19:36:27 masinter: Backpointers to earlier section would be nice 19:37:03 yves: Don't mention #! in the best practices section 19:37:05 LMM: Discuss #! in separate section earlier 19:37:13 NM: Strongly agree with Larry 19:37:23 HT: Put it in 2.N for some N? 19:37:43 then this section is a summary of previous given best practices 19:37:53 YL: Also need to connect to part 6, because #! violates specs 19:38:02 Part 6. 19:39:58 JAR: I prefer "at variance with" to "violate". You can violate laws, not specs. 19:41:21 conflict with? 19:41:31 contradict? 19:41:49 need update 19:42:03 I don't even think it's at variance 19:42:22 I think the only thing that needs updating is fragment identifier definition in HTML spec 19:42:48 noah: Don't want to convey complacence around these extensions 19:43:32 noah: I'm trying to be neutral on whether the apps or wrong, or the specs need updating 19:44:46 this isn't any violation of anything... this is just a normal update 19:46:20 ht: For some years, people have been using # in a different way from how it's specified... 19:46:31 ... [text/html says they identify elements] 19:47:02 ht: They're just getting a job done; but it's just a fact that it's different from what the spec says 19:47:40 RFC 2854 19:48:54 s/says they/says fragids/ 19:49:09 my view is that the new use of fragment identifiers to identify application is not a "violation" or a "conflict" but merely an evolution which hasn't tracked 19:49:40 the specs *are* being updated, and the only unfortunate thing is the dumb power struggle which is getting in the way of getting the documents updated quickly 19:51:37 noah: Get to para 2 more quickly. Punchline: When a representation is text/html, then... "unfortunately" 19:52:48 ashok: Should we add this bit about html 5 media type not specifying script-resolved # either? 19:52:58 all: yes 19:54:18 ht: No, it doesn't belong in a finding, will be outdated 19:54:31 s/all:/anonymous:/ 19:54:51 we could report that we will have asked HTML5 to fix the bug as soon as we can report it 19:55:01 remove 'strictly speaking' 19:55:11 http://www.ietf.org/rfc/rfc2854.txt 19:55:15 Delete But it works in practice. 19:55:30 Delete: strictly speaking 19:56:35 jt: I don't think earlier in the doc you talk about the caching aspect. Should be in sec 2, and refer back to it from sec 6 19:57:04 jt: There *are* audio and video media types 19:57:08 There are audio media types: http://www.iana.org/assignments/media-types/audio/index.html 19:57:26 masinter: They're a mess... 19:58:40 media fragments working group is working on a spec to update audio & video media types? 19:59:48 part of the problem is in the draft-masinter-mime-web-info ... that MIME registration template doesn't have a section for describing fragment identifiers and the process doesn't require defining them 19:59:54 ashok: Here it's hard to figure out what the secondary resource is, in media fragments 20:01:30 noah: If no retrieval is possible, then fragid semantics is unspecified 20:01:55 masinter: You can do as you like, but if it's not specified then you won't get reliable communication 20:02:54 timbl: Many reasons not to put fragid semantics in registrations 20:04:50 ashok: The media fragment spec has a way to say from one time to the next 20:06:58 http://tools.ietf.org/html/rfc3778#section-3 20:07:36 noah: (wants declarative URIs) 20:07:48 note definition of application/pdf fragment identifiers as parameters to a "PDFOpen" process 20:08:55 the only problem is that HTML MIME type spec needs an update 20:11:07 jar: Can we deal with section 6 after our more general fragid discussion? 20:13:08 jt: If you say you want a time chunk, that turns into an http request with a range header 20:14:39 jt: Is that practice something we want to bring up in this finding? Does it conflict with any specs? 20:14:53 yves: Always a problem since it's a priori processing of the fragment 20:14:56 i'm concerned about taking convention about client/server and turning it into unnecessary normative requirements. 20:15:19 there is no normative requirement for ALL uris that fragment identifiers are not 'sent' 20:15:56 ... you are saying things about URIs without fetching them... 20:15:59 I'm wondering about linking fragement definition to media type definition needs update 20:18:13 ashok: Let's take out the "This document discusses highly..." paragraph 20:18:30 ht: Let's not lose the very last sentence of it 20:20:49 noah: all media types should specify ids for passive or active as appropriate 20:21:10 ... swap the two parts 20:21:45 noah: delete "when and how ... active content" 20:23:23 masinter: Whether or not definitions are directly in media type, or in the document itself... 20:23:35 Section 7. 20:24:40 http://www.w3.org/2001/tag/products/ 20:24:52 noah: I started writing a product page... linked from list of TAG product page (NOT IN TRACKER)... 20:27:04 http://www.w3.org/2001/tag/products/clientsidestate.html 20:29:53 discussion of process around this document 20:35:48 consideration of whether and how to take this off of rec track 20:37:12 Yves: Suggest we take the WD [from 2009] and publish it as a note, so that it can tombstoned 20:39:15 DKA: Having it done or close to done by TPAC would be a good thing 20:40:22 noah: TPAC is Nov 1 20:42:38 (noah is editing the clientsidestate product page, URL above) 20:47:59 topic: Administration 20:49:59 summer scheduling 20:50:07 TPAC 20:52:50 location of sept F2F 20:53:35 Congrats to Henry on his promotion 20:56:40 rrsagent, pointer 20:56:40 See http://www.w3.org/2011/06/06-tagmem-irc#T20-56-40 21:00:29 masinter: Regrets for 23 June telcon 21:00:45 noah: Regrets for 30 June and 7 July 21:11:16 Likely won't meet on June 30, July 7, July 28, Aug 11-25. See spreadsheet 21:19:10 discussion of agenda for Tue-Wed 21:23:10 noah: There is some ambiguity around whether the TAG has been asked to respond to the HTML-XML TF's draft 21:25:58 Adjourned 21:49:16 jar has joined #tagmem 22:51:24 Norm has joined #tagmem 22:54:17 Norm has joined #tagmem 23:07:50 Zakim has left #tagmem 23:49:51 ht has joined #tagmem