Subject: Re: [alto] Error handling in the ALTO protocol (-03)

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 09:38:10 -0400

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-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
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-masked]

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-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Thu, 18 Mar 2010 10:15:26 -0400

BTW, I've created a ticket in the Issue Tracker related to Error codes in the 
protocol to track this discussion.

I agree that we still need to use HTTP status codes for exactly the reason you 
mentioned.

-- 
Richard Alimi
Department of Computer Science
Yale University

On Thursday 18 March 2010 9:38:10 am Woundy, Richard wrote:
> 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
> 
> 
> It seems that the error handling of ALTO relies on the http error codes,
> but does not provide its own error code or proceed.
> 
> 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:
> - 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
>

---

From: "Martin Stiemerling" <[email-masked]>
Date: Sat, 27 Mar 2010 11:54:07 +0100

Hi Rich,

Yes, you're understanding is right.

  Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Woundy, Richard
> Sent: Thursday, March 18, 2010 2:38 PM
> To: Martin Stiemerling; [email-masked]
> Subject: Re: [alto] Error handling in the ALTO protocol (-03)
> 
> It seems that the error handling of ALTO relies on the http error
> codes, but does not provide its own error code or proceed.
> 
> 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:
> - 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
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
>