RE: Thoughts on HELIUM/HiNT

[Lucas Pardue <[e-mail]>]

Thanks for the feedback Martin and Patrick.

In spending time on this I got the feeling that some aspects of this ecosystem seem a little underrepresented in IETF. For example, simple HTTP forward proxying as used today from the end-user perspective has multiple modes of discovery or configuration (environment variables, Web Proxy Auto-Discover (WPAD), proxy.pac, group policy) [1] [2] that sit at various levels of specification or are defacto standards.

Meanwhile, ongoing progress with HTTP/2 and HTTP/QUIC provides, in theory, new methods of proxy discovery and selection. For example, my local proxy using HTTP Alternative Services to advertise the availability of HTTP/QUIC. In practice I don’t know how much uptake there is in such evolution.

I think HTTPbis has some role to play but agree that the work might be suited to be lead from elsewhere. Part of me wonders if there is some relationship to the work of TAPS or PvD.

Lucas

[1] https://tools.ietf.org/html/draft-ietf-wrec-wpad-01
[2] https://tools.ietf.org/html/draft-nottingham-http-proxy-problem-01

P.S In writing this email I’ve discovered more I-Ds from mnot in this space that are very relevant and are due consideration in further work.


From: Patrick McManus [mailto:[e-mail]]
Sent: 10 July 2018 01:59
To: Ben Schwartz <[e-mail]>
Cc: Martin Thomson <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: Thoughts on HELIUM/HiNT



On Monday, July 9, 2018, Ben Schwartz <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jul 9, 2018 at 6:16 AM Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
This is interesting work and a direction that has some promise.  Its
effect on consolidation [1] is something that needs consideration, but
some of the effects of that consolidation promise to have some
positive outcomes.

However, I don't think that this is an HTTP working group item, and
nor should it be.  I think that this needs to concentrate on
lower-layer primitives than what HTTP currently provides.

I think it's both.

There's definitely a big piece of lower-layer work that probably shouldn't happen in HTTP.  However, the goal is to build something that is firmly embedded in HTTP.  For example, some of our ideas would require defining new HTTP/2 frame types.  At a minimum, I think we need to check whether the HTTP WG is reasonably supportive before we start the work in earnest.

Perhaps the chairs have advice on how to structure these initial discussions.

[he whispers into the air to nobody in particular :)]

Its not clear to me either - and that's ok pre-meeting. While this isn't solely the kind of thing httpbis focuses on, its hard to ignore the introduction of new methods, modification of existing methods, and even frame types.

That's the reason we want to give it air time in Montreal - to get an understanding of the proposal and the reaction of http stakeholders (Martin is the first on the record :).. Basically, exploratory. I'm glad its seeing dispatch air time too.

I do want to urge anyone that develops, maintains, or even regularly interacts with FORWARD proxies to step forward and help us understand what you think of this and how it imapcts your system (that would be interesting feedback from the authors as well). This is a somewhat less common aspect of the ecosystem than at the time the core tunneling semantics were done so I'd like to make sure we're not writing things down in a vacuum.

-Patrick


Discussion of part of this on the DISPATCH agenda, which is good.  I
would prefer to see this taken on in a new working group.

That does seem like a good option.

[1] see https://www.ietf.org/blog/consolidation/



----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------