tis 2006-04-18 klockan 09:24 -0400 skrev trainier@xxxxxxxxxx: > 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
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
