- From: Mike Belshe <mike@belshe.com>
- Date: Sat, 10 Dec 2011 15:14:55 -0800
- To: Daniel Appelquist <dan@bluevia.com>
- Cc: “tag” <www-tag@w3.org>
- Message-ID: <CABaLYCv7Y9egu67XHiSQSsw+Kvw7cHv2jHQ__F8-Ub0nJeOeog@mail.gmail.com>
Hi, folks - I had a couple of comments to add. I hope these are useful. See below: On Fri, Dec 9, 2011 at 3:33 AM, Daniel Appelquist <dan@bluevia.com> wrote: > Draft minutes of the 1 December 2011 TAG teleconference are at > > http://www.w3.org/2001/tag/2011/12/08-minutes.html > > …and in plain text below. > > Dan > > --- > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > Technical Architecture Group Teleconference > > 08 Dec 2011 > > See also: [2]IRC log > [3]Agenda > > [2] http://www.w3.org/2011/12/08-tagmem-irc > [3] http://www.w3.org/2001/tag/2011/12/08-agenda.html > > Attendees > > Present > Jeni Tennison, Ashok Malhotra, Jonathan Rees, Henry Thompson, > Peter Linss, Noah Mendelsohn, Yves Lafon, Tim Berners-Lee > > Regrets > Henry Thompson, Jonathan Rees > > Chair > Noah Mendelsohn > > Scribe > Dan Appelquist > > Contents > > * [4]Topics > 1. [5]Administrative items > 2. [6]Draft on best practices for registries > 3. [7]SPDY > * [8]Summary of Action Items > _________________________________________________________ > > <trackbot> Date: 08 December 2011 > > Noah: any regrets for next week? > > Dan: regrets for next week. > > Yves: I can likely scribe next week. Ask me next week. > > Noah: Approval of minutes from December 1st... > > [no objections heard] > > Minutes of 1 December meeting approved. > > Administrative items > > Noah: We are mostly dependent on people fulfilling out actions for > f2f. there is a link to a local arrangements page on our agenda for > today. this meeting is Wednesday through Friday. > > Dan: I will have to give regrets for Friday, unfortunately, unless I > can switch my flight (unlikely). > > <timbl> depth of ice ... if seriously cold bring skates but looking > warm at the moment > > Noah: TAG election - Ian announced the candidates. 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. any objections? [none heard] > in same note from Ian, I have been reappointed. > > Draft on best practices for registries > > Noah: can you give us an intro, Larry? > > [9]http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draf > t-registries.txt > > [9] > http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt > > <noah> Draft from Larry: > [10]http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/dra > ft-registries.txt > > [10] > http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt > > <noah> ACTION-531? > > <trackbot> ACTION-531 -- Larry Masinter to draft document on > architectural good practice relating to registries -- due 2011-07-30 > -- OPEN > > <trackbot> [11]http://www.w3.org/2001/tag/group/track/actions/531 > > [11] http://www.w3.org/2001/tag/group/track/actions/531 > > 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. > 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. … in a framework of extensibility in > general. > > <noah> Why does this paragraph appear twice, follwed by different > lists? > > <noah> "There are a variety of ways of managing extensibility of > sets of 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. > > <noah> enumerated values, and establishing a mechanism for > introducing > > <noah> private and/or public extensions." > > Tim: The document could be more explicit on that point. > > <timbl> For an RDF scheme, often addingto the exitsing spec is the > best ay to go. > > <timbl> (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. > > Larry: [summarizes some points of the document] > > <timbl> By comparison, exitend 'left, center, right' to 'left, > center, right, justify' is an extension to semantics. > > Larry: [on Findings] a registry needs to be managed in a public, > fair and transparent way… I think this is important. 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. do we want to recommend that you > should use http URIs? This is related to our work on > http-range-14... 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… 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. There is a BCP which is RFC-5226... > > <noah> 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? Section on sniffing… > technical specs that want to override existing registries. some > discussion on prefixes to convey status (e.g. x-) and how this is > ineffective.... this is rough, but contains enough material that we > could massage into a workable document. > > <Zakim> JeniT, you wanted to ask if doc is about registries vs URIs > > 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. > > <timbl> 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. > > Larry: Yes. it does seem to be about that. > > 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...? > > Noah: Proposal: let's cover the bits about registries first. > > <Zakim> 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 > > Tim: I think we should just broaden the scope. > ... 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: 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. for example, [$1\47] a new URI scheme could > cause a lot of extra work. 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. 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. > > Tim: CSS rounded corners another good example... > > <noah> Only tangentially related to registry-based solutions, Mark > Nottingham quotes > ([12]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0049.html) > Roy Fielding as calling mustUnderstand-based approaches "socially > reprehensible" 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. > > [12] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0049.html) > > <Zakim> 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 > > 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 ... > > <noah> Hmm. Can you use your own new scheme in the identifier for > that same new scheme :-)? > > Tim: With URI schemes, you should allow people with very little cost > to block out a name so that nobody else can get it… > > <Zakim> noah, you wanted to talk about how this fits with other TAG > priorities, and Larry's other commitments you could make a list that > you encourage browser vendors to implement - a curated list that > involves serious review. > > 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? > > <noah> 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? > > Larry: this is related to my work on mime and the Web. > > <noah> LM: Well, it's motivated by and related to work on MIME on > the Web. > > <noah> [13]http://www.w3.org/2001/tag/products/mimeweb.html > > [13] http://www.w3.org/2001/tag/products/mimeweb.html > > <noah> 30 September 2011: Draft of final report (e-mail from Larry > Masinter provides outline, but says this is running a bit behind > schedule) > > <noah> 31 December 2011: Final TAG Report on MIME architecture, most > likely in the form of a TAG finding > > <noah> 31 December 2011: TAG achieves success criteria set out on > the product page, and identifies further goals and next steps, if > any > > Noah: In the master list i see these deliverables. Noah: 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. > > Noah: Could you give us the larger issues draft in time for the f2f? > > Larry: I think that they're overlapping - there is a big overlap. > > 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? > > Larry: It seems to me that the scheduling depends on what others' > ideas on priorities are... > > Noah: let's discuss the priority of this... > > <noah> DKA: Seems to me that putting a pause on this while waiting > for the bigger work might be counterproductive. > > <noah> 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. > > Dan: seems like this work has some momentum behind it… Maybe reverse > the order and do this one first? > > Noah: I think we're far enough down the road with the larger > piece... I'd like to finish what we committed. other thoughts? > > <noah> ACTION-531? > > <trackbot> ACTION-531 -- Larry Masinter to draft document on > architectural good practice relating to registries -- due 2011-07-30 > -- OPEN > > <trackbot> [14]http://www.w3.org/2001/tag/group/track/actions/531 > > [14] http://www.w3.org/2001/tag/group/track/actions/531 > > 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... > > <noah> Larry: MIME document is now small. > > <noah> Noah: Right, which is one reason I was reluctant to delay it. > > 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. > > Larry: My pushback - I detect a lot more enthusiasm for this topic > then for the mime topic... > ... I will do what I can on the mine thing. > > Noah: Is there anyone who objects to making the registries work into > a product level effort. > > [no objections heard] > > <noah> . 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. > > <noah> . 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. > > <noah> . 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. > > 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. > > Dan:+1 on the PR > > <noah> . RESOLUTION: The TAG, with Larry in the lead, will prepare a > document (based on > [15]http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/dra > ft-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. > > [15] > http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt > ) > > that's good too. > > <noah> RESOLUTION: The TAG, with Larry in the lead, will prepare a > document (based on > [16]http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/dra > ft-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. > > [16] > http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt > ) > > Noah: Thanks, Larry. > > <noah> ACTION-531? > > <trackbot> ACTION-531 -- Larry Masinter to draft document on > architectural good practice relating to registries -- due 2011-07-30 > -- OPEN > > <trackbot> [17]http://www.w3.org/2001/tag/group/track/actions/531 > > [17] http://www.w3.org/2001/tag/group/track/actions/531 > > <timbl> 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 > > <noah> Highly motivational, Tim. > > [discussion on timelines] > > <noah> ACTION-531 Due 2011-12-26 > > <trackbot> ACTION-531 Draft document on architectural good practice > relating to registries due date now 2011-12-26 > > <noah> Larry needs to get back to Noah to give guidance on F2F slots > for MIME and/or Registries > > SPDY > > <JeniT> +1 > > <Ashok> +1 > > Noah: should we invite Mark Nottingham to the TAG f2f if possible > for discussion on SPDY? > > <noah> General agreement that inviting Mark Nottingham to HTTP/SPDY > F2F session is a good thing. > > Dan:+1 > > <Yves> +1 > > <noah> ACTION: Noah to invite Mark Nottingham to SPDY/HTTP F2F > session [recorded in > [18]http://www.w3.org/2011/12/08-tagmem-minutes.html#action01] > > [18] http://www.w3.org/2011/12/08-tagmem-minutes.html#action01 > > <trackbot> Created ACTION-639 - Invite Mark Nottingham to SPDY/HTTP > F2F session [on Noah Mendelsohn - due 2011-12-15]. > > <Yves> > [19]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html > > [19] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html > > <noah> > [20]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html > > [20] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html > > Noah: Yves drafted an email... > > <noah> Also see this thread started by Larry: > [21]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0042.html > there are some discussions on email (in www-tag). > > [21] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0042.html > > 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… This actually isn't true. The chrome implementation of SPDY supports proxies with hierarchical caching today. Generally, there has been no solution for SSL based hierarchical caching through proxies. This isn't a problem caused or introduced by SPDY. Its a problem due to encrypting the stream end-to-end. However, we did build this into Chrome with SPDY, and it is deployed today. You can do SPDY to your proxy, and provide hierarchical caching on your proxy. Of course, for end-to-end secure configurations (like to your bank), you still can't cache at the proxy. But this the desired behavior - and exactly what we have with SSL today. See also: http://dev.chromium.org/spdy/spdy-proxy-examples Since proxies never before have supported SSL, it is important to start differentiating two different types of proxies: * Transparent proxies * Explicit proxies Transparent proxies, in my opinion and in the opinion of many, are quite problematic. Allowing transparent proxies into the system allows someone to tamper with the data stream in ways which neither the user, nor the origin server intended or authorized. This type of behavior has been documented repeatedly. Explicit proxies are proxies that the browser knows about and has the opportunity to reject. There is nothing inherent to SSL or SPDY which prevents use of explicit proxies. They've never been implemented in browsers before, but as mentioned above, there are existing implementations.. Finally, while I am pointing out that this has been done and works today, I'm still advocating that the entire world move to SSL for all content (see below). If we do this latter step, the proxy work is kinda wasted. > 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... 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. > > <noah> 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? > also - SPDY pipelining enhancement is a way to work around TCP > limitation… HTTP over SCTP - multiplexing at the TCP level. From an > architectural PoV, it's better. But there is a problem with NAT.. > <Yves> 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 > > <noah> Scribe ---> Please make sure that s/[?]/SCTP/ really takes in > the formatting script > > 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? > > 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…. there's always a possibility to hid everything not not > the destination for example... > > 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... The fact that you can upgrade > from http to spdy is a cool feature but most proxies will not > upgrade... > > Tim: if you go through a proxy the upgrading will break? > > Yves: in most proxies after you use http upgrade the proxy acts like > a tcp tunnel after that. > > <Zakim> noah, you wanted to ask about downsides of encrypting what's > not secret anyway > > Yves: smarter option would be the proxy knowing what's going on and > being part of the exchange... > > Noah: We're acting like this is a good thing except where it breaks > proxies… but you shouldn't need to encrypt data if it's not > secret... it seems tempting to me to say in general on the network > that encryption should be used to keep things secret. > > Yves: tokens are sent in the clear - e.g. when you use Facebook all > the info is stored in a cookie... > <Yves> once auth is done > > <Yves> cookie as session indication > > <Zakim> timbl, you wanted to mention changes of expectations with > respect to privacy or people accessing public resources, compared to > the old days. > > 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. > > <noah> 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 > > <noah> (that's a paraphrase of what Tim said) the fact that caches > don't work - that is an issue. > > <Zakim> DKA, you wanted to make a point about what's secret / not > secret... > > <noah> 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. > > <noah> ...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... > > <noah> ...low latency, high bandwidth, when more and more devices > are on less capable networks. Not all of world has even 2G or 3G. > > <noah> ...You also have latency to spacecraft (really, I kid you > not...worth worrying about). > > <Zakim> noah, you wanted to respond to Tim > > <timbl> +1 > > 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... But in that case, we end up encrypting the text of the > constitution possibly unnecessariliy.... > You're nailing it here. The world has changed since 15 years ago in a couple of dramatic ways: a) Its increasingly clear that the users of the internet don't know what it means to be secured, and they can't differentiate secure vs unsecure on their own. b) The use of cookies over HTTP is downright dangerous (witness Firesheep) b) Privacy attacks are going through the roof. We read about them every day. I believe the only solution is for the protocol experts to take a leadership role and make sure we're on path to have users and websites protected always. But, if we really think we want to maintain an unsecured protocol, how about if we work toward a world where we flip the default? By default, the protocol is secure. If they want to opt out, power users can do so. It's like "safety first". > <Zakim> Larry`, you wanted to summarize themes: encryption > everywhere vs. deployed infrastructure. Multiplexing over TCP and > HTTP-NG organizational memory. but it may be that in balance we are > so close to the need to encrypt everything that let's just do it. > > Larry: 2 themes - there are concerns about the costs of encrypting > everything - the impact of intermediaries, etc… > I hear these concerns repeatedly, but I have yet to see them substantiated. First, lets break down the SSL performance issues: a) Impact of the SSL handshake (round trips, cert validation, etc) b) Cost of bulk encryption c) Server CPU impact d) Bad SSL implementations (a) is a problem. The introduction of False Start takes out a round trip, which makes it a lot better. Browsers have also been horrifically bad at caching OCSP responses and adopting things like session tickets. OCSP stapling is new work, but needs to handle multi-level certificate chains better. I can go on for days about this topic :-) SPDY mitigates most of this by just using fewer connections. Once your connection is established, you don't need to handshake anymore. Resources: http://www.belshe.com/2011/05/19/ssl-falsestart-performance-results/ http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html (b) This is a pure myth. The bulk-encryption cypher is just super cheap. I recommend use of RC4, which is literally just a few xors on your data stream. The attached research shows that you can encrypt and decrypt 100KB of data in less than a 3rd of an average round trip (avg RTT is ~100ms)!! Resources: http://www.ijcttjournal.org/volume-1/Issue-3/IJCTT-V1I3P107.pdf c) This is a potential issue, but in practice not often the problem. It is true that SSL uses more CPU. But its pretty small - when Google turned on SSL for all of GMail, how much did CPU increase? 1%. On top of that, for modern websites, CPU often isn't the bottleneck anyway. I haven't seen any recent research which indicates this is a problem. Resources: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html d) SSL implementations are notoriously poor. For the past 15 years very little optimization has been applied. And in virtually every SSL stack I've looked at (including Google's servers, Android, and Chrome's client), there have been major, obvious implementation problems. Troubling as well is that some browsers rely on the SSL stack which is embedded in the OS (e.g. IE, Safari). This means that these browsers are at the mercy of the OS upgrade in order to get more modern SSL implementations. (which is why SNI isn't ubiquitous- thanks WinXP) Resources: http://www.belshe.com/2010/12/17/performance-and-the-tls-record-size/ One last plea to end the SSL performance complaint: It's going to take us ~2 yrs to standardize anything new. Measuring performance with today's CPUs for a protocol that doesn't ship for 2 years is a bit behind the curve. I've already demonstrated that every aspect of SSL performance is acceptable today on today's computers. But if you're still not 100% convinced, remember that Moore's law dictates that we'll have 4x more CPU power for the buck than we have today when any next protocol ships. As a counter argument, I think the mobile arena is an interesting area of study. The good news is that this is happening as we speak. But by the time any new protocol ships, these mobile phones in our pockets will have quad cores. I'm just not worried about it. Reducing the number of round-trips is far more important. > <noah> 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" I as pointing out http-ng as a caution sign - where not > to go. I remember there being some serious problems trying to > multiplex multiple connections over a single TCP connection. At the > time it was unsolvable. 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. http > 1.1 and 1.0 seems to be in so many embedded devices and > controllers…. > > <noah> 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. given those > two constrains - might be better as an upgrade option rather than a > replacement. > I don't see SPDY as a replacement. One of the best arguments for keeping HTTP is video streams. SPDY does nothing to help video today. I hope these comments are helpful, and thank you all your hard work and for advancing the discussion about HTTP futures. Mike > > Tim: I'm assuming that it's an upgrade and you'd have to keep http > 1.1. > > Larry: Maybe it's fine that SPDY is used as an upgrade for things > that currently use HTTPS. > > <noah> 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." > > <noah> 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. > 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... > > <noah> ACTION-618? > > <trackbot> 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 > > <trackbot> [22]http://www.w3.org/2001/tag/group/track/actions/618 > > [22] http://www.w3.org/2001/tag/group/track/actions/618 > > <timbl> I can't remember who used to say "Cast nasturtiums" for > "cast aspersions" ... > > Noah: Next steps? > > Yves: we need to decide what topics here are most interesting for > the TAG. > > 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? > > <noah> close ACTION-618 > > <trackbot> ACTION-618 With help from Larry, Noah, and Jeni to > prepare analysis on development around HTTP, like spdy, ssl use, > websocket... closed > > <noah> ACTION: Yves to frame F2F discussion of SPDY/HTTP futures > [recorded in > [23]http://www.w3.org/2011/12/08-tagmem-minutes.html#action02] > > [23] http://www.w3.org/2011/12/08-tagmem-minutes.html#action02 > > <trackbot> Created ACTION-640 - Frame F2F discussion of SPDY/HTTP > futures [on Yves Lafon - due 2011-12-15]. > > <timbl> I think it was deliberately invented by someone like Peter > Cook or Dudley Moore [24]http://en.wikipedia.org/wiki/Peter_Cook > > [24] http://en.wikipedia.org/wiki/Peter_Cook > > Summary of Action Items > > [NEW] ACTION: Noah to invite Mark Nottingham to SPDY/HTTP F2F > session [recorded in > [25]http://www.w3.org/2011/12/08-tagmem-minutes.html#action01] > [NEW] ACTION: Yves to frame F2F discussion of SPDY/HTTP futures > [recorded in > [26]http://www.w3.org/2011/12/08-tagmem-minutes.html#action02] > > [25] http://www.w3.org/2011/12/08-tagmem-minutes.html#action01 > [26] http://www.w3.org/2011/12/08-tagmem-minutes.html#action02 > > [End of minutes] > _________________________________________________________ > > > Minutes formatted by David Booth's [27]scribe.perl version 1.136 > ([28]CVS log) > $Date: 2011/12/09 11:24:48 $ > > [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [28] http://dev.w3.org/cvsweb/2002/scribe/ > > > > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBAgAGBQJO4fH9AAoJEJtNQ0/3lXn/MoUH/jBc2t5sTw5+67z+pt/H6rIS > 5NFSWSs50L57qmOg9ZQD0X+d08QrJKwnII9EOEIr6ePDpGl4I3dxFb5QwwZmYiK6 > 9M8F6TjjP5Ns3usAluwJg2o86prrk56FBu+osQUMtE/D28hk/LP5R/5cuSTfjwVF > bdZNRuy6dRgL4qWDQSsecBtai2hjJR3V1HJT/yyVuGPrNW/LFWU4ZnzVnkTRunv9 > QqHQN6Vs8VV+l6oyHmyRWRnsal77iM8ElPhD/OrCqc9B64vYeKkpBKFq/i1H60cr > 90G/dxEf7bwHZVmLZjX83ySwI/BnRz1YPEtu0qr8zL5kT2a8x2s53BDVF3Z71lc= > =DVHJ > -----END PGP SIGNATURE----- > >
Received on Monday, 12 December 2011 11:28:41 UTC