The CUAP Note was written to track some of the few errors made in the implementations of user agents (browsers, etc.). The first draft version was written by Hugo Haas. It was completed and written jointly with Karl Dubost and Ian Jacobs. The note is not exhaustive, but we try to track the comments and may give a new version in the future. The Note would have not been possible without the help of the whole W3C Team.
The comments address the version: http://www.w3.org/TR/2001/NOTE-cuap-20010206
A French translation of the note is available at http://www.la-grange.net/w3c/cuap/.
We may have bugs in the CUAP Note itself, let us know. But please, double check before.
List of received comments.
http://lists.w3.org/Archives/Public/www-talk/2001JanFeb/0099.html
reference http://www.w3.org/Addressing/schemes instead of referencing RFC 1717 and the IANA registry. I don't mind the reference as such, its just that its never stated very specifically what the processes are.
that seems a bit quick for me : you could add reference to the libwww implementation, which not only do what you are recommending, but check the response time of all ip address and sort all the address to get the best one. http://www.w3.org/Library/src/HTDNS.html linking to our open source implementation is quite a good example about how to use the right way
Point 3.6 in your note says to only list supported media types in an HTTP Accept header rather than just listing '*/*'. While this is a step in the right direction, it conflicts with your point 1.3 (Allow the user to retrieve web resources even if the browser cannot render them).
Often a server will not return an content type if you do not advertise that you handle it. Thus, in your example where a server prefers to send SVG instead of PNG, the user would get nothing if the browser doesn't understand any of the available content types (SVG and PNG in this case).
So, OmniWeb (http://www.omnigroup.com/products/omniweb) sends a Accept header that has '*/*' at the end, after all of the supported content types. This way, the server is free to send us something which we can then allow the user to save to disk to process with some other tool.
Even if you don't agree with this approach, you might want to update your Note to present the problem and whatever approach you prefer.
It might be nice if, in addition to Content-Type, there was an 'Available-Content-Types' header that the server would return allowing the user to bring up a context menu on an item to switch content types in this case. Thus, if they have a PNG viewer as an external program and their browser doesn't understand PNG or SVG, they would have some means to get the PNG representation of the object rather than just getting the SVG version.
http://lists.w3.org/Archives/Public/www-talk/2001JanFeb/0102.html
http://lists.w3.org/Archives/Public/www-talk/2001JanFeb/0086.html
addon: javascripts open window functions should be handled like cookies: always open, ask, never open. this is NOT for links, but for automatic scripting. if a user clicks he usually wan't it open.
I've worked with a number of web sites suffereing from bandwidth overload. By altering their PHP servers to support encoding compression or inserting a compressing proxy we have dramatically reduced their operating costs. The down side is that a number of browsers advertise that they can handle gzip or deflate and they really can't. Both IE and Mozilla have this problem with different versions.
Created: 2001/02/09 - Last modified $Date: 2001/05/10 07:59:22 $ by
$Author: hugo $
http://lists.w3.org/Archives/Public/www-talk/2001JanFeb/0104.html
Koen Holtman <koen@hep.caltech.edu>