Martin, I assume in your proposal that ALTO would still leverage the appropriate HTTP error codes as well as add ALTO error codes / information?
I think we want to keep the HTTP error codes so that intermediaries (eg caches) handle errors the right way as well. -- Rich ----- Original Message ----- From: [email protected] <[email protected]> To: [email protected] <[email protected]> Sent: Thu Mar 18 07:29:18 2010 Subject: [alto] Error handling in the ALTO protocol (-03) Hi all, While reading draft-ietf-alto-protocol-03 is stumbled over the error handling. It seems that the error handling of ALTO relies on the http error codes, but does not provide its own error code or proceed. I see this a shortcoming of the current design and also as not favourably. This mixes transport related error messages (e.g., 404 not found, i.e., the general alto resource your asking for isn't here) and errors related the actual ALTO handling (e.g., asking guidance for private or reserved IP addresses that cannot be rated by ALTO, syntax errors, or not understood objects). My proposal: - separate both levels clearly - define an error object for cases where no or only a partial answer can be given - define that the server can deliver some information he has understood (e.g., some IP addresses) within the given semantics, as defined in the draft as is. Martin [email protected] NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
