Re:Quick feedback on draft-nottingham-web-proxy-desc-00

Thanks a lot for trying to move this subject. I assume the 5xx codes error codes the proxies will use are to be defined in another document ? It's a bit weird to see them referenced before they exist.

Anyway, some feedback :

Section 2.

Clients MUST use CONNECT to access https → you remove client choice if the proxy rejects the CONNECT. I don't want to reopen that particular can of worms but in the real world the MUST will become a SHOULD

Section 3.

WPD contains human text. As such RFC7159 is not sufficient by itself for ineroperability (it's not M2M or technical JSON), you need to mandate a single encoding.

Section 3.

Humans will really want a "logo" object in addition to name and desc (as link or data encoding)

Section 3.

The format is nicely parallel with no implicit priority (thank you very much). However in the real world priorities do exist (primary path vs backup path with older equipment for example). Some people will want to assign weights to rules → define a "priority" or "weight" generic attribute ?

Also please clarify that when several proxies with the same priority are available, clients are supposed to choose the ones they use at random. if they all choose the first one WPD will be useless for load balancing.

Section 3.

People will beg for reusable blocks (aka variables). Many PAC file clever ordering tricks are only there to simulate variables.
That or allow host to be an array to avoid duplicating the same conditions over and over (cut and paste is error-prone!)

Section 3.
Why do you mandate port? Can you not define a default port? More compact representation = less room for mistakes

Section 3.

alwaysDirect needs clientNetworks too (in enterprise context you have front and back office access to the same web apps and some populations are never expected to access the direct back office interface. They won't have the correct habilitation and even if they could login they would likely not know how to navigate the back office interface)

Section 3.
Likewise faildirect is likely to need clientNetworks of forReferers → wouldn't it be simpler to define that an array entry contains either host+port, or alwaysDirect, or forReferers ?

Section 3.
Only developpers use CamelCase. Ops usually do not and WPD will be written by ops, so there will be mistakes here. What happens in that case ?

Section 4.1
While proactive content negociation is nice it places the implementation burden proxy-side and many proxy manufacturers will get it wrong. i18n is unfortunately quite misunderstood by many developers. It would be nicer not to depend on the manufacturer i18n priorities and make name/desc/moreinfo an array indexed by locales (and let the client negociate internally the best entry to use)

Anyway on the whole the proposal is refreshingly less byzantine than pacfiles+wpad