17:58:40 RRSAgent has joined #tagmem 17:58:40 logging to http://www.w3.org/2011/12/08-tagmem-irc 17:58:42 RRSAgent, make logs public 17:58:42 Zakim has joined #tagmem 17:58:44 Zakim, this will be TAG 17:58:44 ok, trackbot, I see TAG_Weekly()1:00PM already started 17:58:45 Meeting: Technical Architecture Group Teleconference 17:58:45 Date: 08 December 2011 17:58:48 noah has joined #tagmem 17:59:00 zakim, who is here? 17:59:00 On the phone I see +44.771.520.aaaa 17:59:01 On IRC I see noah, Zakim, RRSAgent, DKA, timbl, plinss, trackbot, Yves 17:59:04 zakim aaaa is me 17:59:12 zakim, aaaa is me 17:59:12 +DKA; got it 18:00:17 Ashok has joined #tagmem 18:00:23 +noah 18:00:23 JeniT has joined #tagmem 18:00:34 +plinss 18:01:23 +Ashok_Malhotra 18:01:33 +[IPcaller] 18:01:36 Larry` has joined #tagmem 18:01:44  /me Zakim, [IPcaller] is me 18:01:46 ls 18:02:21 +Yves 18:02:32 zakim, who is here? 18:02:34 On the phone I see DKA, noah, plinss, Ashok_Malhotra, JeniT, Yves 18:02:35 On IRC I see Larry`, JeniT, Ashok, noah, Zakim, RRSAgent, DKA, timbl, plinss, trackbot, Yves 18:03:37 Scribe: Dan 18:03:37 +Masinter 18:03:44 ScribeNick: DKA 18:03:51 Chair: Noah 18:04:06 Noah: any regrets for next week? 18:04:43 Dan: regrets for next week. 18:05:05 Yves: I can likely scribe next week. Ask me next week. 18:05:17 Noah: Approval of minutes from December 1st... 18:05:25 [no objections heard] 18:05:34 Minutes of 1 December meeting approved. 18:05:39 Topic: Administrative items 18:06:12 Noah: We are mostly dependent on people fulfilling out actions for f2f. 18:06:24 … there is a link to a local arrangements page on our agenda for today. 18:06:38 … this meeting is Wednesday through Friday. 18:06:51 +TimBL 18:08:11 Dan: I will have to give regrets for Friday, unfortunately, unless I can switch my flight (unlikely). 18:10:38 depth of ice ... if seriously cold bring skates but looking warm at the moment 18:10:55 Noah: TAG election - Ian announced the candidates. 18:12:06 … There will be an election. Robin Berjon, Henry Thompson, and Glenn Adams nominated. Election closes Jan 9th. I will invite both new candidates to participate over the phone in the f2f. 18:12:13 … any objections? [none heard] 18:12:30 … in same note from Ian, I have been reappointed. 18:12:52 Topic: Draft on best practices for registries 18:12:59 Noah: can you give us an intro, Larry? 18:13:05 http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt 18:13:08 Draft from Larry: http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt 18:13:33 ACTION-531? 18:13:33 ACTION-531 -- Larry Masinter to draft document on architectural good practice relating to registries -- due 2011-07-30 -- OPEN 18:13:33 http://www.w3.org/2001/tag/group/track/actions/531 18:13:54 Larry: We've been talking about registries and had a lot of different discussions about it. I have put together an overview of the topic and what we might want to recommend as best practices. 18:14:51 … this was an attempt to gather this in a document that would make intentionally strong recommendations. There was some feedback from Thomas that they might be too strong [?] but I think a finding needs to say something substantive. 18:15:13 … … in a framework of extensibility in general. 18:16:10 Why does this paragraph appear twice, follwed by different lists? 18:16:12 "There are a variety of ways of managing extensibility of sets of 18:16:12 … there is an alternative to allowing extensibility point which is to have a living standard where you update the whole document when you want to change anything. 18:16:12 enumerated values, and establishing a mechanism for introducing 18:16:12 private and/or public extensions." 18:16:38 Tim: The document could be more explicit on that point. 18:16:41 For an RDF scheme, often addingto the exitsing spec is the best ay to go. 18:18:02 (Not the RGB colours don't work for me --- mainly IANA registration is mainly for when there is a new value WITH NEW SEMANTICS. 'orage' is very easy to define , is really just a macro for exaiting semantic of an RGB value. 18:18:12 Larry: [summarizes some points of the document] 18:18:42 By comparison, exitend 'left, center, right' to 'left, center, right, justify' is an extension to semantics. 18:19:04 Larry: [on Findings] a registry needs to be managed in a public, fair and transparent way… I think this is important. 18:19:37 … we have had, traditionally a recommendation that using URIs over registries is preferable. Perhaps we want to make that recommendation more explicit among these choices. 18:20:11 q+ doc about registries vs URIs 18:20:12 … do we want to recommend that you should use http URIs? This is related to our work on http-range-14... 18:20:20 q+ to ask if doc is about registries vs URIs 18:20:22 q+ to say Three reasons for doing a registry I can think of: to insist on qiality, to allow lookup of semantics, to limit number because of cost of adidng new things. May be differently important. 18:21:02 … Using namespaces and vendor prefixes - do we want to recommend those? There have been interesting discussions about the pitfalls and transition plan from prefix names to non-prefix names… 18:21:28 … For Registries - if the values that are in a W3C spec are shared with other IETF-managed protocols, then W3C should use IANA as the registry. 18:21:38 q+ to say Four reasons for doing a registry I can think of: to avoid conflict, to insist on qualiy, to allow lookup of semantics, to limit number because of cost of adding new things. May be differently important for differnt extension points. 18:22:01 … There is a PCP which is RFC-5226... 18:22:22 s/PCP/BCP/ 18:22:27 The draft speculates on "... recommend http: URIs? ..." Is https going to prove preferable in the long run. In any case, don't we intend to allow for that as an option? 18:23:44 … Section on sniffing… technical specs that want to override existing registries. 18:24:30 … some discussion on prefixes to convey status (e.g. x-) and how this is ineffective.... 18:24:52 … this is rough, but contains enough material that we could massage into a workable document. 18:24:53 q? 18:24:56 ack next 18:24:57 JeniT, you wanted to ask if doc is about registries vs URIs 18:25:45 JeniT: I think it's good. Some of the BPs are actually about using URIs , not registries… So is it actually about extensibility mechanisms in general and not just registries. 18:26:00 Extensibility points: Examples: content-types, uri schemes, color names, host names, html attributes to the a given element, country codes, HTTP headers, css rounded corners. 18:26:00 Larry: Yes. it does seem to be about that. 18:26:35 JeniT: I'm happy with the boarder scope. It makes sense to make recommendations on when do registries make sense, when do URIs make sense...? 18:27:01 Noah: Proposal: let's cover the bits about registries first. 18:27:09 ack next 18:27:10 timbl, you wanted to say Three reasons for doing a registry I can think of: to insist on qiality, to allow lookup of semantics, to limit number because of cost of adidng new 18:27:14 ... things. May be differently important. and to say Four reasons for doing a registry I can think of: to avoid conflict, to insist on qualiy, to allow lookup of semantics, to 18:27:15 Tim: I think we should just broaden the scope. 18:27:18 ... limit number because of cost of adding new things. May be differently important for differnt extension points. 18:28:05 Tim: I agree this is about extensibility points - how you control these. Looking through what it says but thinking of different examples… You can distinguish 4 reasons for wanting a registry: 18:28:57 q+ to point out I've moved to wanting URI schemes to be FCFS with only 'expert review' to weed out obviously broken entries 18:29:17 … 1 in order to avoid conflict; 2 you want to set a bar and set review - you want to have a quality of anything introduced ; 3 it may be there to provide look-up [shame that IANA is not oriented towards lookup] ; 4 you want to limit the number because there is a cost of introducing each one. 18:29:31 q+ to talk about how this fits with other TAG priorities, and Larry's other commitments 18:29:52 Also, HTML defines an extensible web+ URI scheme 18:29:55 … for example, [4] a new URI scheme could cause a lot of extra work. 18:30:26 … for HTML tags, when you introduce a new section, everyone needs to understand that who implements browsers. But if you add metadata, it's no skin of anyone's nose. 18:30:53 … so you have 2 situations - one on which you need whole community to get involved and one in which anyone besides a sub-community can ignore. 18:31:31 Tim: CSS rounded corners another good example... 18:31:45 tim: optimal finding would have a matrix or decision tree 18:31:51 Only tangentially related to registry-based solutions, Mark Nottingham quotes (http://lists.w3.org/Archives/Public/www-tag/2011Dec/0049.html) Roy Fielding as calling mustUnderstand-based approaches "socially reprehensible" 18:31:59 … we need a decision tree - questions to answer to understand what kind of extension you're doing and which of these techniques you should use. 18:32:09 ack next 18:32:10 Larry`, you wanted to point out I've moved to wanting URI schemes to be FCFS with only 'expert review' to weed out obviously broken entries 18:33:14 q+ 18:34:07 Larry: Tim you included URI schemes - I've been moving towards in my own opinion towards first-come-first-served maybe with a areview to prevent spam… HTML5 itself needs a mechanism for URI schemes and protocol handlers… [?] HTML ISSUE 198 - prefix coordination. Naming convention for URI schemes where you say web+schemepreferences ... 18:34:22 q+ about link relations 18:34:26 q+ to talk about link relations 18:34:35 Hmm. Can you use your own new scheme in the identifier for that same new scheme :-)? 18:35:37 tim: operation of preventing conflict is separate from process for insuring review 18:35:40 Tim: With URI schemes, you should allow people with very little cost to block out a name so that nobody else can get it… 18:35:56 ack next 18:35:57 noah, you wanted to talk about how this fits with other TAG priorities, and Larry's other commitments 18:36:02 … you could make a list that you encourage browser vendors to implement - a curated list that involves serious review. 18:36:58 this seemed like a big chunk of the MIME and the web area... that is, most of those issues were registries issues 18:37:24 Noah: The action under which this work has been done was hatched in February. It's never had visibility as one of our bigger projects. We're now talking about doing a finding and broadening its scope… so - does this fit under one of our existing products, should we spend time on this, and what's the scheduling / effort on this? 18:37:41 NM: We don't have a "product"-leve focus on this. Does it fit under existing product, if not what priority do we want to give this? 18:37:45 Larry: this is related to my work on mime and the Web. 18:37:53 LM: Well, it's motivated by and related to work on MIME on the Web. 18:38:03 http://www.w3.org/2001/tag/products/mimeweb.html 18:38:28 30 September 2011: Draft of final report (e-mail from Larry Masinter provides outline, but says this is running a bit behind schedule) 18:38:28 31 December 2011: Final TAG Report on MIME architecture, most likely in the form of a TAG finding 18:38:28 31 December 2011: TAG achieves success criteria set out on the product page, and identifies further goals and next steps, if any 18:38:36 Noah: In the master list i see these deliverables. 18:39:08 i see this is a process of destructuring the MIME issues ... 18:39:21 … so we could do the larger report and finish it, treat registries lightly there and indicate that we will do something additional on registries in 2012; or we could punt on the larger deliverable. 18:39:47 s/so we/Noah: so we/ 18:40:29 Noah: Could you give us the larger issues draft in time for the f2f? 18:40:45 Larry: I think that they're overlapping - there is a big overlap. 18:41:52 Noah: let's assume the larger document gets drafted and we issue a finding - there is then a proposal to ramp up a registry document… Right? 18:42:18 Larry: It seems to me that the scheduling depends on what others' ideas on priorities are... 18:43:05 Noah: let's discuss the priority of this... 18:43:42 DKA: Seems to me that putting a pause on this while waiting for the bigger work might be counterproductive. 18:43:43 note that IAB is working on an extensibility document and this one might be part of TAG/IAB collaboration 18:44:02 Is it an either-or? We've committed the broader document for a long time, we have a schedule, and I think we're close to meeting it. 18:44:20 Dan: seems like this work has some momentum behind it… Maybe reverse the order and do this one first? 18:44:40 if you had a choice of which topic you'd like to talk about in future meetings -- which do you think would be eager to talk about? 18:44:41 Noah: I think we're far enough down the road with the larger piece... 18:45:01 … I'd like to finish what we committed. 18:45:14 … other thoughts? 18:45:38 ACTION-531? 18:45:38 ACTION-531 -- Larry Masinter to draft document on architectural good practice relating to registries -- due 2011-07-30 -- OPEN 18:45:38 http://www.w3.org/2001/tag/group/track/actions/531 18:46:06 Larry: I will note that the IAB is working on a document on extensibility and it might be [timely] but reluctant to put them in our critical path... 18:46:31 Larry: MIME document is now small. 18:46:41 Noah: Right, which is one reason I was reluctant to delay it. 18:46:58 q- 18:48:03 Noah: I think we should stay the course. Larry you will get us a draft by the f2f for review. for now we will continue ACTION-531 and if you have new stiff that merits discussion at the f2f then let me know. 18:48:29 Larry: My pushback - I detect a lot more enthusiasm for this topic then for the mime topic... 18:48:43 q- 18:49:06 ack next 18:49:45 Larry: I will do what I can on the mine thing. 18:50:07 s/mine/mime/ 18:50:27 Noah: Is there anyone who objects to making the registries work into a product level effort. 18:50:36 [no objections heard] 18:51:00 or is it more generally about extensibility points and a decision tree of how to decide which one to use? 18:51:06 s/which one/which method/ 18:51:24 . RESOLUTION: The TAG, with Larry in the lead, will explore mechanisms for extensibility of specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture. 18:52:02 . RESOLUTION: The TAG, with Larry in the lead, will prepare a document, likely a finding, discussing extensibility of specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture. 18:52:25 . RESOLUTION: The TAG, with Larry in the lead, will prepare a document, likely a finding, discussing architecture for extensibility points in specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture. 18:52:43 Tim: We've fallen in this trap of thinking of extensibility too generally. This is about a specific part of extensibility… This is very narrow and I think it's good to keep it focused on that. 18:53:00 +1 on the PR 18:53:38 . RESOLUTION: The TAG, with Larry in the lead, will prepare a document (based on http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt), likely a finding, discussing architecture for extensibility points in specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture. 18:53:54 that's good too. 18:54:05 RESOLUTION: The TAG, with Larry in the lead, will prepare a document (based on http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt), likely a finding, discussing architecture for extensibility points in specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture. 18:54:36 Noah: Thanks, Larry. 18:54:36 ACTION-531? 18:54:36 ACTION-531 -- Larry Masinter to draft document on architectural good practice relating to registries -- due 2011-07-30 -- OPEN 18:54:36 http://www.w3.org/2001/tag/group/track/actions/531 18:54:45 The unyeilding medium'd not merely endured / it's that upon which Art depends / for who can perform on a tightrope secured / at only one of its ends - Piet Hein 18:54:58 Highly motivational, Tim. 18:56:27 [discussion on timelines] 18:56:50 ACTION-531 Due 2011-12-26 18:56:51 ACTION-531 Draft document on architectural good practice relating to registries due date now 2011-12-26 18:57:23 Larry needs to get back to Noah to give guidance on F2F slots for MIME and/or Registries 18:57:54 Topic: SPDY 18:58:17 +1 18:58:29 +1 18:58:38 Noah: should we invite Mark Nottingham to the TAG f2f if possible for discussion on SPDY? 18:58:39 General agreement that inviting Mark Nottingham to HTTP/SPDY F2F session is a good thing. 18:58:40 +1 18:58:44 +1 18:58:51 ACTION: Noah to invite Mark Nottingham to SPDY/HTTP F2F session 18:58:52 Created ACTION-639 - Invite Mark Nottingham to SPDY/HTTP F2F session [on Noah Mendelsohn - due 2011-12-15]. 18:59:01 http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html 18:59:02 http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html 18:59:05 Noah: Yves drafted an email... 18:59:27 Also see this thread started by Larry: http://lists.w3.org/Archives/Public/www-tag/2011Dec/0042.html 18:59:32 … there are some discussions on email (in www-tag). 19:01:28 Yves: some background - the first thing is about the use of TLS… there are many people that are for it - firesheep is a good example of dangers of putting everything in the clear. There are technical issues though - intermediaries can't work because it can't be cached… Can be important in high-latency situation. 2nd issue - if everything is encrypted then it is more difficult to discover if sensitive data is escaping from your computer... 19:02:13 … so do we need to encrypt everything or not. It impacts on the SPDY discussions. Although it is not mandatory to run over TLS most implementations required that. 19:03:33 Something feels odd about encrypting public resources like the White House home page, or the W3C home page, with the excuse that it buys speed. Authenticating the endpoint and the integrity of the channel seems to be of some value, I.e. using signatures to prevent spoofing when desired, but hiding the content seems weird. Why break caching if the content isn't secret in the first place? 19:03:34 … also - SPDY pipelining enhancement is a way to work around TCP limitation… HTTP over [?] - multiplexing at the TCP level. From an architectural PoV, it's better. But there is a problem with NAT.. 19:04:33 q+ 19:05:25 s/[?]/SCTP/ 19:06:26 ack next 19:06:37 another issue is the number of communication channel that needs to be provisioned in advance, roughly the same issue as pre-opening parallel connections in HTTP right now 19:06:48 Scribe ---> Please make sure that s/[?]/SCTP/ really takes in the formatting script 19:07:09 Ashok: basic question - you spoke about worries that the data might escape and you wouldn't find out. But the data that would get stolen would be encrypted. So what's the real problem with that? 19:07:12 q+ to ask about downsides of encrypting what's not secret anyway 19:08:06 Yves: If you figure out that data is escaping to someone in an encrypted form - if there are no key exchanges then it's easy to decipher…. 19:08:24 … there's always a possibility to hid everything not not the destination for example... 19:08:25 in the web today, the argument might be that you would only open an encrypted connection to a trusted site, and rely on sniffing proxies for monitoring and virus protection for the connections to untrusted sites. Moving to all SSL would disallow sniffing proxies ... 19:09:55 Yves: [continuing] so then you have SPDY - SPDY is trying to make HTTP faster at different levels. First by a multiplexing algorithm. Also compression of almost everything. Body, headers, a special dictionary for often-used headers... 19:10:35 … The fact that you can upgrade from http to spdy is a cool feature but most proxies will not upgrade... 19:10:46 Tim: if you go through a proxy the upgrading will break? 19:11:11 Yves: in most proxies after you use http upgrade the proxy acts like a tcp tunnel after that. 19:11:24 ack next 19:11:25 noah, you wanted to ask about downsides of encrypting what's not secret anyway 19:11:32 Yves: smarter option would be the proxy knowing what's going on and being part of the exchange... 19:12:00 Noah: We're acting like this is a good thing except where it breaks proxies… 19:12:21 … but you shouldn't need to encrypt data if it's not secret... 19:12:35 q+ to make a point about what's secret / not secret... 19:13:00 q+to mention changes of expectations with respect to privacy or people accessing public resources, compared to the old days. 19:13:07 … it seems tempting to me to say in general on the network that encryption should be used to keep things secret. 19:13:35 Yves: tokens are sent in the clear - e.g. when you use Facebook all the info is stored in a cookie... 19:14:19 once auth is done 19:14:33 cookie as session indication 19:15:03 q? 19:15:15 ack timbl 19:15:15 timbl, you wanted to mention changes of expectations with respect to privacy or people accessing public resources, compared to the old days. 19:15:23 q+ to respond to Tim 19:16:42 Tim: when we started [the web] it was reasonable to cache as much as possible and bandwidth was [scarce]. Now, spying software i so ubiquitous that people are more sensitive about being public aout what they read. it's a privacy issue. New expectations about privacy. The attitudes we had 10 years ago about saving cpu power by not using encryption [might need to change]. Maybe I should do everything encrypted. 19:16:49 Tim: There's still an issue of privacy. If you encourage public info to be sent in the clear, then you build a system where it's easy to find out what public info >you< are reading 19:16:58 (that's a paraphrase of what Tim said) 19:17:02 … the fact that caches don't work - that is an issue. 19:17:07 ack next 19:17:09 DKA, you wanted to make a point about what's secret / not secret... 19:17:42 DKA: Two points. 1) These days, even public info such as the weather channel might come with private, secure tokens that are related to your social network. 19:18:46 q+ to summarize themes: encryption everywhere vs. deployed infrastructure. Multiplexing over TCP and HTTP-NG organizational memory. 19:19:04 ...We're all using OAuth to authenticate around the Web. Visiting the NY Times can send a credential to Facebook. 2) Now, to contradict myself, we also cannot assume that we always have instantaneous... 19:19:26 ...low latency, high bandwidth, when more and more devices are on less capable networks. Not all of world has even 2G or 3G. 19:19:49 ...You also have latency to spacecraft (really, I kid you not...worth worrying about). 19:20:02 q? 19:20:08 ack next 19:20:09 noah, you wanted to respond to Tim 19:20:14 +1 19:21:28 Noah: I said we should be hesitant about encrypting things that don't need to be encrypting. What I'm hearing is that more on the Web has a need to be encrypted then I'm thinking. So the constitution of the US is public but the fact that I'm reading it is private... 19:21:49 … But in that case, we end up encrypting the text of the constitution possibly unnecessariliy.... 19:21:53 q+ avoid switching to acceble uses of and respect fro information as to what Noah was reading. 19:21:59 q? 19:22:01 ack next 19:22:02 Larry`, you wanted to summarize themes: encryption everywhere vs. deployed infrastructure. Multiplexing over TCP and HTTP-NG organizational memory. 19:22:10 q+ to talk about switching to acceble uses of and respect fro information as to what Noah was reading.a 19:22:12 … but it may be that in balance we are so close to the need to encrypt everything that let's just do it. 19:22:48 Larry: 2 themes - there are concerns about the costs of encrypting everything - the impact of intermediaries, etc… 19:22:52 I don't think it's just encrytion vs. deployed infrastructure. I think it's "the benefits of encryption vs. the overhead of doing it, and the loss of flexible use of the encrypted information" 19:23:06 … I as pointing out http-ng as a caution sign - where not to go. 19:23:34 … I remember there being some serious problems trying to multiplex multiple connections over a single TCP connection. At the time it was unsolvable. 19:24:37 … maybe this isn't an issue for the use case for which SPDY was designed - all the threads coming from a single managed server. You might have a problem where the endpoints are on the other side of a gateway or a proxy - not so managed. Also I'm having trouble imagining a long tail where http 1.1 disappears. 19:24:56 … http 1.1 and 1.0 seems to be in so many embedded devices and controllers…. 19:25:06 Why are we talking about HTTP 1.1 going away. I think SPDY, if it's a good think is like HTTP 1.0 to 1.1; everyone implements both, but the use of (something similar to) SPDY grows. 19:25:28 … given those two constrains - might be better as an upgrade option rather than a replacement. 19:25:45 Tim: I'm assuming that it's an upgrade and you'd have to keep http 1.1. 19:26:05 Larry: Maybe it's fine that SPDY is used as an upgrade for things that currently use HTTPS. 19:26:30 So, there's also the whole question of "if we do need something >like< SPDY, how close to correct is SPDY in detail? Mike Belshe seemed quite willing to see those questions explored as part of a standardization discussion." 19:27:20 TBL: Some of us may vaguely remember head of line blocking being a practical problem. Google engineers seem to be excited that SPDY does better, and has more real time capability to adjust priorities, e.g. based on what the user is trying to see. 19:29:32 Yves: there is another effort - close to being published as an RFC - One potential issue with web sockets - you are replacing a well defined protocol with a set of libraries that will define the protocol... 19:29:40 ACTION-618? 19:29:40 ACTION-618 -- Yves Lafon to with help from Larry, Noah, and Jeni to prepare analysis on development around HTTP, like spdy, ssl use, websocket... -- due 2011-12-06 -- PENDINGREVIEW 19:29:40 http://www.w3.org/2001/tag/group/track/actions/618 19:29:53 I can't remember who used to say "Cast nasturtiums" for "cast aspersions" ... 19:29:59 Noah: Next steps? 19:31:00 Yves: we need to decide what topics here are most interesting for the TAG. 19:31:34 Noah: Can we give you an action to prepare a session for the f2f - these seem to be the questions that face the community and let's talk about which of these if any should the TAG get involved with? 19:31:49 close ACTION-618 19:31:50 ACTION-618 With help from Larry, Noah, and Jeni to prepare analysis on development around HTTP, like spdy, ssl use, websocket... closed 19:32:25 rrsagent, make minutes 19:32:25 I have made the request to generate http://www.w3.org/2011/12/08-tagmem-minutes.html DKA 19:32:32 rrsagent, make logs public 19:32:39 rrsagent, pointer? 19:32:39 See http://www.w3.org/2011/12/08-tagmem-irc#T19-32-39 19:32:51 http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html 19:33:08 http://www.w3.org/Protocols/HTTP-NG/Activity 19:33:20 ACTION: Yves to frame F2F discussion of SPDY/HTTP futures 19:33:21 Created ACTION-640 - Frame F2F discussion of SPDY/HTTP futures [on Yves Lafon - due 2011-12-15]. 19:33:27 I think it was deliberately invented by someone like Peter Cook or Dudley Moore http://en.wikipedia.org/wiki/Peter_Cook 19:33:33 -Ashok_Malhotra 19:33:37 -JeniT 19:33:38 -noah 19:33:38 -Yves 19:33:40 -DKA 19:33:42 -TimBL 19:33:43 -plinss 19:33:45 adjourned 19:33:48 -Masinter 19:33:49 TAG_Weekly()1:00PM has ended 19:33:51 Attendees were +44.771.520.aaaa, DKA, noah, plinss, Ashok_Malhotra, JeniT, Yves, Masinter, TimBL 19:33:55 rrsagent, write logs 19:33:55 I'm logging. I don't understand 'write logs', DKA. Try /msg RRSAgent help 19:34:03 rrsagent, make minutes 19:34:03 I have made the request to generate http://www.w3.org/2011/12/08-tagmem-minutes.html DKA 19:34:11 timbl: see http://castingnasturtiums.com 19:35:56 zakim, who is here? 19:35:56 apparently TAG_Weekly()1:00PM has ended, DKA 19:35:59 On IRC I see Larry`, Ashok, noah, Zakim, RRSAgent, DKA, timbl, plinss, trackbot, Yves 19:37:02 Interestingly, considering Miller’s comic roots, “casting aspersions” already has a famous malaprop: “casting nasturtiums.” Graphic artist Donald McGill featured it in one of his postcards, and it’s listed as a humorous construct in the OED. The following early examples, quoted by Arnold Zwicky, are given in the OED: 19:37:02 1916 W.L. GEORGE Strangers’ Wedding I. v. 112 All right, ‘Erb, I don’t want to cast any nasturtiums on you! 1933 D. L. SAYERS Murder must Advertise i. 22 He’s been a long time in the firm and doesn’t like any nasturtiums cast at it. 19:37:17 ==> a humourous construct 20:49:16 DKA has joined #tagmem 21:37:43 Zakim has left #tagmem