Subject: New draft-loreto-httpbis-proxy20-00.txt

From: Salvatore Loreto <[email-masked]>
Date: Tue, 8 Oct 2013 21:03:16 -0700

Hi there,

we have just submitted a draft draft
that advocates the importance and the benefits that proxies can provide 
for HTTP/2.0
and aims to start a discussion on this topic within the HTTPBis wg

comments, suggestions and feedback are welcome

best regards
Salvatore

-------- Original Message --------
Subject: 	New Version Notification for draft-loreto-httpbis-proxy20-00.txt
Date: 	Tue, 8 Oct 2013 20:59:43 -0700
From: 	<[email-masked]>
To: 	Hans Spaak <[email-masked]>, Salvatore Loreto 
<[email-masked]>, Salvatore Loreto 
<[email-masked]>, Mohammad Hafeez <[email-masked]>, 
"Robert Skog" <[email-masked]>, Dan Druta <[email-masked]>

A new version of I-D, draft-loreto-httpbis-proxy20-00.txt
has been successfully submitted by Salvatore Loreto and posted to the
IETF repository.

Filename:	 draft-loreto-httpbis-proxy20
Revision:	 00
Title:		 Addressable Trusted Proxy in HTTP/2.0
Creation date:	 2013-10-09
Group:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-loreto-httpbis-proxy20-00.txt
Status:          http://datatracker.ietf.org/doc/draft-loreto-httpbis-proxy20
Htmlized:        http://tools.ietf.org/html/draft-loreto-httpbis-proxy20-00

Abstract:
    This document defines and clarifies the role of proxies (aka
    intermediaries) in HTTP 2.0.  It aims to assure that HTTP 2.0
    contains the same proxy features present in HTTP 1.1.  It also
    defines HTTP 2.0 proxies and advocates the importance and the
    benefits that they can provide for HTTP 2.0.  This document aims to
    start the discussion within the HTTPBis wg.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 9 Oct 2013 14:01:14 +0200

> Hi there,

Hi

> and aims to start a discussion on this topic within the HTTPBis wg

Thank you for this draft

I fear the terminology does not quite cover one of the most common
use-case for intermediaries right now, which is security/caching
intermediaries. This use case is present in Enterprise gateways and but
also more and more on end-user systems (either via built-in browser
functionalities of via extensions like ad block plus which are
semantically a security proxy that happens to be deployed on the same
system).

Unlike a transforming proxy a security intermediary/caching does not aim
to transform messages in any semantic way. The intent is to relay as much
stuff unchanged as possible.

However, unlike a tunnel proxy a security/caching intermediary is party to
the http connexion because it may block some elements for security
reasons, or relay elements that still exist in its cache but have been
changed server-side.

Also, it does need to convey its actions (typically, why some element has
been blocked or how to unblock by authenticating for example) to
endpoints. And it does not want at all for this communication to
masquerade as something else.

I think one of the root reasons proxies does not work correctly now is
this erroneous terminology. People want to think about them as transparent
tunnels (which they are not), and when they diverge from transparent
tunnels they complain about transformations (which is *not* the intent at
all, the few transformations that do occur only exist to simulate the
communication channel that security/caching gateways need and which has
been completely forgotten in http specs)

Making this use case explicit in the specs and fixing the intermediary
communication problem would go a long way to remove proxies as a hate
object.

-- 
Nicolas Mailhot

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 16 Oct 2013 18:17:27 +0000

Hi Nicolas

thanks for the comments
see more inside

br
/Salvatore

On Oct 9, 2013, at 3:01 PM, Nicolas Mailhot <[email-masked]> wrote:

> intermediaries.

well we explicitly stated in the draft that in this initial version we have not
considered caching.
We recognise that it is an important part of the all web architecture and
that it should stay in 2.0 as well as plain HTTP

> This use case is present in Enterprise gateways and but

good point!

> reasons,

we tried to include this aspect in the draft,
but if you think is not maybe we have to make more explicitly 

> or relay elements that still exist in its cache but have been
> changed server-side.

not sure why it should server a staled content?

> masquerade as something else.

that is a good point, the user should become always aware of any changes 
made by a proxy

> been completely forgotten in http specs)

yes terminology is part of the problem for sure

---

From: <[email-masked]>
Date: Thu, 17 Oct 2013 14:08:33 +0000

Hi Salvatore,
You say that the “actual discovery mechanism is not discussed in this draft”.  Is it definitively out of scope of the document ?
Regards
Emile

De : Salvatore Loreto [mailto:[email-masked]]
Envoyé : mercredi 9 octobre 2013 06:03
À : HTTP Working Group
Objet : New draft-loreto-httpbis-proxy20-00.txt

Hi there,

we have just submitted a draft draft
that advocates the importance and the benefits that proxies can provide for HTTP/2.0
and aims to start a discussion on this topic within the HTTPBis wg

-------- Original Message --------
Subject:

New Version Notification for draft-loreto-httpbis-proxy20-00.txt

Date:

Tue, 8 Oct 2013 20:59:43 -0700

From:

<[email-masked]><mailto:[email-masked]>

To:

Hans Spaak <[email-masked]><mailto:[email-masked]>, Salvatore Loreto <[email-masked]><mailto:[email-masked]>, Salvatore Loreto <[email-masked]><mailto:[email-masked]>, Mohammad Hafeez <[email-masked]><mailto:[email-masked]>, "Robert Skog" <[email-masked]><mailto:[email-masked]>, Dan Druta <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:       00

Number of pages: 8

Abstract:

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 17 Oct 2013 17:30:56 +0000

Hi Emile,

the intent of this draft is not to discuss the actual mechanisms
but to advocate the need to have in 2.0 almost the same proxy features present in HTTP 1.1,
of course improved on all the different angles (i.e. security, performance, user benefits etc)

coming to the actual discovery mechanisms, the discovery has at least two aspects
- on one side the user has to be able to fetch all the info necessary to explicitly configure a Proxy when this is
present in the network; that means the user have to be able to explicitly consent to use the Proxy or eventually
bypass it.
For this we can work on fixing and improving proxy.pac and wpad; and/or we can also provide an ad-hoc mechanism
for mobile terminals attached to a telephone network

- on the other side the end user has to become aware, somehow, of the fact that the data have traversed a proxy;

br
Salvatore

On Oct 17, 2013, at 5:08 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi Salvatore,

De : Salvatore Loreto [mailto:[email-masked]<http://ericsson.com>]
Envoyé : mercredi 9 octobre 2013 06:03
À : HTTP Working Group
Objet : New draft-loreto-httpbis-proxy20-00.txt

Hi there,

-------- Original Message --------
Subject:

Date:

From:

To:

Hans Spaak <[email-masked]><mailto:[email-masked]>, Salvatore Loreto <[email-masked]><mailto:[email-masked]>, Salvatore Loreto<[email-masked]><mailto:[email-masked]>, Mohammad Hafeez <[email-masked]><mailto:[email-masked]>, "Robert Skog" <[email-masked]><mailto:[email-masked]>, Dan Druta <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:       00

Number of pages: 8

Abstract:

until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: <[email-masked]>
Date: Fri, 18 Oct 2013 09:18:41 +0000

Hi Salvatore

IMO, you might define the main categories of discovery mechanisms.

Cdt
Emile

De : Salvatore Loreto [mailto:[email-masked]]
Envoyé : jeudi 17 octobre 2013 19:31
À : STEPHAN Emile IMT/OLN
Cc : HTTP Working Group
Objet : Re: New draft-loreto-httpbis-proxy20-00.txt

Hi Emile,

br
Salvatore

Hi Salvatore,
You say that the "actual discovery mechanism is not discussed in this draft".  Is it definitively out of scope of the document ?
Regards
Emile

Hi there,

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:       00

Number of pages: 8

Abstract:

The IETF Secretariat

Thank you.