.PAC files

[Mark Nottingham]

After the London IETF, httpbis had a (pretty big) “design team meeting.”

One of the issues we talked about there was the proxy.pac file format, which is still not a standard, and which causes both browser folks and operators a fair amount of pain.

There was a significant amount of interest there in improving that situation, especially from the (network-oriented) browser folks in the room. However, we weren’t sure if it would be more appropriate in the IETF, the W3C or elsewhere, since it’s basically a couple of JavaScript functions.

Any thoughts here? My inclination would be to do it in the IETF, either as part of httpbis, appsawg or an independent submission.

Cheers,

--
Mark Nottingham http://www.mnot.net/

[Dan Wing]

Post by Mark Nottingham
After the London IETF, httpbis had a (pretty big) “design team meeting.”
One of the issues we talked about there was the proxy.pac file format, which is still not a standard, and which causes both browser folks and operators a fair amount of pain.
There was a significant amount of interest there in improving that situation, especially from the (network-oriented) browser folks in the room. However, we weren’t sure if it would be more appropriate in the IETF, the W3C or elsewhere, since it’s basically a couple of JavaScript functions.
Any thoughts here? My inclination would be to do it in the IETF, either as part of httpbis, appsawg or an independent submission.

There are two things needed:

1. finding the .PAC file: This would standardize how to find the file -- deployed or ideas around this include DHCP (e.g., option 252), DNS, default router.
2. processing the .PAC file: This would standardize the file's contents, and likely extend what it can configure (e.g., TURN server configuration).

The first (finding a PAC file) is pretty much an IETF problem to solve. The second (processing the PAC file) is probably more a W3C problem. Splitting the standardization of PAC between two standards organizations may be worse than simply doing it all together in one place, but there seems little overlap between finding the file and processing the file.

-d

[Mark Nottingham]

Hi Dan,

Post by Dan Wing

Post by Mark Nottingham
After the London IETF, httpbis had a (pretty big) “design team meeting.”
One of the issues we talked about there was the proxy.pac file format, which is still not a standard, and which causes both browser folks and operators a fair amount of pain.
There was a significant amount of interest there in improving that situation, especially from the (network-oriented) browser folks in the room. However, we weren’t sure if it would be more appropriate in the IETF, the W3C or elsewhere, since it’s basically a couple of JavaScript functions.
Any thoughts here? My inclination would be to do it in the IETF, either as part of httpbis, appsawg or an independent submission.

1. finding the .PAC file: This would standardize how to find the file -- deployed or ideas around this include DHCP (e.g., option 252), DNS, default router.
2. processing the .PAC file: This would standardize the file's contents, and likely extend what it can configure (e.g., TURN server configuration).
The first (finding a PAC file) is pretty much an IETF problem to solve. The second (processing the PAC file) is probably more a W3C problem. Splitting the standardization of PAC between two standards organizations may be worse than simply doing it all together in one place, but there seems little overlap between finding the file and processing the file.

Based on the discussion we had in London, I’d say there’s strong implementer (i.e., browser) interest in #2, but not #1 — primarily because it’s fraught with security issues that appear to be very difficult to solve, and they don’t want to encourage adoption of the existing mechanisms.

If a secure, automatic configuration mechanism were to drop out of the sky, the answer might be different, of course.

Cheers,


--
Mark Nottingham http://www.mnot.net/