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

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Sep 2014 14:14:32 +0200

Mark,

thanks a lot of getting something out. Here's some initial feedback:

Technical:

>    WPD Proxies MUST support HTTP/2 [I-D.ietf-httpbis-http2] over TLS for
>    connections from clients.  Clients that cannot establish a HTTP/2
>    connection to a WPD proxy MUST consider that proxy "failed."

This requirement appears to be unrelated to the goals of the document. 
Do we need it? Why would it be bad to connect using HTTP/1.1?

>    [RFC7230] Section 5.7.2 requires proxies to honour the semantic of
>    the "no-transform" cache-control directive, and append the 214
>    (Transformation Applied) warn-code to other messages that have been
>    transformed; WPD proxies MUST honour these requirements.

I agree with the requirement, and I also like it being called out. That 
being said, I'd prefer to be clear about what requirements are *added* 
for WPD Proxies, and which ones apply to proxies anyway.

>    Proxy objects' members are defined by the following subsections;
>    unrecognized members SHOULD be ignored.

Isn't that a MUST?

Editorial:

- there are some uses of BCP14 keywords in lower case; either rephrase 
or uppercase them....

>    This specification defines:
>
>    o  A simple format for describing a Web proxy ("WPD"; see Section 3)
>       to facilitate configuration, and so that it can be represented to
>       users in a consistent way, and
>
>    o  A way to discover the proxy description using a well-known URL
>       (Section 4), so that direct configuration of a proxy is as simple
>       as entering a hostname, and
>
>    o  A set of additional requirements for proxies described in this
>       fashion, as well as requirements for User Agents connecting to
>       them, designed to improve security, usability and
>       interoperability.  See Section 2.

This reads weird as the sections are introduced in a ordering different 
from document order...

References:

>    [bad-proxy]
>               Chen, S., Mao, Z., Wang, Y., and M. Zhang, "Pretty-Bad-
>               Proxy: An Overlooked Adversary in Browsers' HTTPS
>               Deployments", January 2009, <research.microsoft.com/
>               jump/79323>.

URI should be fixed.

>    [W3C.CR-html5-20140731]
>               Berjon, R., Faulkner, S., Leithead, T., Navara, E.,
>               O&#039;Connor, E., and S. Pfeiffer, "HTML5", World Wide
>               Web Consortium CR CR-html5-20140731, July 2014,
>               <http://www.w3.org/TR/2014/CR-html5-20140731>.

s/&#039;/'/

In general, I recommend using the references from 
<http://greenbytes.de/tech/webdav/rfc2629xslt/w3c-references.html#ref-CR-html5-20140731> 
because they are generated from the W3C pub database and also allow 
mechanical up-to-date checks.

Best regards, Julian

---

From: Nicolas Mailhot <[email-masked]>
Date: Wed, 03 Sep 2014 16:15:28 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Sep 2014 16:21:28 +0200

On 2014-09-03 16:15, Nicolas Mailhot wrote:
> ...
> 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.
> ...

How exactly is RFC7159 insufficient? If this is a problem here, why not 
everywhere also where non-ASCII data is exchanged?

Best regards, Julian