RE: draft-montenegro-httpbis-multilegged-auth-01

Hi Mark,



>The problem is that they may be deployed and working, but only at the cost of lots of pain and by other implementers (especially intermediaries). I.e., they're only "working" because people have worked around them.



It would be great if you (and the WG) can provide feedback with suggestions on how the proposal can be extended or modified to make sure implementers do not end up in a worst place once multiplexing is introduced.



>That's your interpretation. The charter doesn't require HTTP 2.0 to accommodate *every* use of HTTP, especially when it's being used -- or extended -- in a non-conformant way.



This would break millions of users in existing deployments. We are not advocating that every use of HTTP be accommodated for, rather ensuring mainstream scenarios continue to work.



>If we can satisfy these use cases by making some changes to them, that's great, but let's not call it "fixing HTTP."



Correct, the proposal is not fixing in HTTP in any way. The goal of our proposal is to ensure that clients in environments requiring multi-legged authentication schemes, continue to work in the presence of multiplexing, while addressing issues introduced by Kerberos' ability to authenticate a connection or individual requests.



Thanks



-Jonathan Silvera



-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net]
Sent: Monday, July 9, 2012 6:10 PM
To: Jonathan Silvera
Cc: 'Alexey Melnikov'; 'Yutaka OIWA'; 'HTTP Working Group'
Subject: Re: draft-montenegro-httpbis-multilegged-auth-01





On 10/07/2012, at 7:16 AM, Jonathan Silvera wrote:



> Dear Yutaka

>

> Supporting legacy authentication schemes, should not be the question to ask ourselves. While these schemes are labeled as "broken" in HTTP 1.1, in reality they are deployed and working. If multiplexing  becomes a part of HTTP 2.0, as it is likely to be, these will be 'broken' not just in label, but in reality.



The problem is that they may be deployed and working, but only at the cost of lots of pain and by other implementers (especially intermediaries). I.e., they're only "working" because people have worked around them.





> The compatibility requirement of the HTTP 2.0 WG charter does not allow us to eliminate legacy schemes, as previous applications are supposed to keep on working, regardless of whether they are labeled as 'broken" for HTTP 1.1 or not.



That's your interpretation. The charter doesn't require HTTP 2.0 to accommodate *every* use of HTTP, especially when it's being used -- or extended -- in a non-conformant way.



If we can satisfy these use cases by making some changes to them, that's great, but let's not call it "fixing HTTP."



Regards,





--

Mark Nottingham   http://www.mnot.net/