tis 2006-04-18 klockan 09:24 -0400 skrev trainier@kalsec.com:
> It's also important to note that the IETF has discontinued efforts to
> standardize WPAD. They did so several years ago.
I am not sure it was ever targeted for standardization.
It was initially submitted to the WREC working group as a solution to
how clients can discover nearby caches, and was discussed briefly. When
the WREC group collapsed due to general lack of interest from the
community to move forward (this was in 2000) work on WPAD continued for
a while in the smaller WEBI working group as an remotely related effort
quite outside the scope of WEBI (was done there only because the same
people were involved..), until that working group collapsed as well..
It is not like IEFT is a third party in this discussion. Anyone with
good knowledge about a subject is welcome and encouraged to participate
in relevant IETF workinggroups. Making Internet standards is a very open
and democratic process. But unfortunately it too often gets sidetracked
due to people requiring something which works with todays clients before
the standard exists and therefore loosing focus on how it should best be
done.. WPAD is a good example of something which got sidetracked because
nobody cared sufficiently about it to focus on getting a good standard
and instead preferred to focus their efforts to work around current
clients (i.e. interception).
There is two major problems with the WPAD draft which also explains why
it never moved forward:
a) It tries to be too "friendly" to the network admins, providing very
many discovery mechanisms to choose from. Would have been better if it
had focused on one or at most two discovery mechanisms. The more
discovery mechanisms there is the less likely clients gets them
implemented properly (if at all). KISS is a golden rule in making
effective standards.
b) The proxy.pac dependency is something many disliked (for good
reasons), and severely restricts which kinds of clients it can be
deployed for. It can not be assumed every HTTP agent has a Javascript
engine.
Note: The biggest problem of restarting standardization of something
like WPAD is to lobby to get support from the major browser vendors.
Without vendor support it isn't likely to get very far. Apart from that
you only need a couple of clever heads with a reasonable understanding
of the related existing standard track protocols such as SLP and SVR.
> I hope you weren't planning on using WPAD. My recommendation is to use an
> autoconfiguration script, then point your clients directly to the script.
WPAD is a good complement to manual configuration of the PAC script path
I would say. It's just one additional layer to make your life easier.
But being non-standard it can not be relied on as the only method of
getting the clients configured.
Regards
Henrik
This archive was generated by hypermail pre-2.1.9 : Mon May 01 2006 - 12:00:02 MDT