- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Tue, 03 Apr 2012 10:30:29 +0100
- To: Mike Belshe <mike@belshe.com>
- CC: Robert Collins <robertc@squid-cache.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 04/03/2012 07:32 AM, Mike Belshe wrote: > On Tue, Apr 3, 2012 at 1:30 AM, Stephen Farrell > <stephen.farrell@cs.tcd.ie>wrote: > >> >> >> On 04/03/2012 12:22 AM, Robert Collins wrote: >> >>> This seems rather timely: >>> >>> http://www.telegraph.co.uk/**technology/news/9179087/** >>> Internet-activity-to-be-**monitored-under-new-laws.html<http://www.telegraph.co.uk/technology/news/9179087/Internet-activity-to-be-monitored-under-new-laws.html> >>> >> >> And not timely but relevant: >> >> http://tools.ietf.org/html/**rfc2804<http://tools.ietf.org/html/rfc2804> > > > So from my reading of this, what we're discussing as a https trusted proxy > does not classify under RFC 2804's definition of wiretapping in any way. Probably. That'll depend on what goes in an I-D I guess. But yes, while 2804 is relevant for the Daily Telegraph link above, I would hope its not relevant for HTTP/2.0. S. > > Section 3 defines 4 definitions of wiretapping, and we are not hitting any > of them: > > 1) Not wiretapping because what we're talking about here is explicitly > known to the sender. > > 2) Not wiretapping because the receivers would see that this was done by a > proxy user agent, in the same way that a standard proxy today identifies > itself in the middle (note, however, that transparent proxies today are > considered wiretaps by this definition! so by removing transparent > proxies, we're removing a common class of wiretap!) > > 3) Not wiretapping because the sender can be told of the exact consequence > and also be able to configure out of it. > > 4) Not applicable - we aren't proposing this at all. > > Any disagreement? > > Mike > > > >> >> >> S >> >> -Rob >>> >>> >>> >> >
Received on Tuesday, 3 April 2012 09:30:59 UTC