Hi, On 05/11/11 17:25, Richard Alimi wrote: > Hi All, > > On Wed, May 11, 2011 at 6:46 AM, Vijay K. Gurbani <[email protected]> wrote: >> [As individual contributor.] >> >> On 05/10/2011 05:01 PM, Ben Niven-Jenkins wrote: >>> The question in my mind is therefore do we drop the requirements and >>> leave it to implementers to "be nice" or do we try to keep the >>> original intent I assume above and reword the requirements to reflect >>> the intent more precisely, e.g. something like (it probably needs >>> more wordsmithing) >>> >>> "An ALTO server which is unable to handle a request due to temporary >>> overloading SHOULD inform the client of its overloaded state. >>> Alternatively it MAY redirect them to an alternative ALTO server." >> I think it is always good to be as explicit as possible when >> designing protocols. In no small part, the ambiguity around >> the 503 response code in SIP has lead to uncertainty in >> determining overload for that protocol. >> >> For an ALTO server, I think we keep the original intent and reword >> the requirement to remove any ambiguities. Working off your >> contributed text, here is my suggestion: >> >> An ALTO server that is unable to service a request due to >> temporary overload SHOULD inform the client of its overload >> state through an appropriate response code. Alternatively, the >> overloaded ALTO server MAY redirect the client to an >> alternate location. > This sounds good to me. > >> Plus, Table 1 in draft-ietf-alto-protocol could be updated to >> match the requirement as follows: >> >> | E_OVERLOAD | 503 | ALTO server overloaded | > This is certainly possible, but I'm not sure whether this is a good > idea. Up to now, the status code here was intended to be for the > ALTO-layer only (e.g., problems with the request syntax, asking for an > invalid cost type even though the client was told that it was not > available). It seems to me like the overload case is more of an > server concept that we should handle purely in HTTP if at all > possible.
The protocol draft allows for clients to retry failed requests (7.5.2), but does not specify exponential back-off or any such protective measure on the client side of things. Having a 'back off' error code would allow the server to indicate the client is retrying too hard. This can optionally be coupled with optional redirection, which would allow us to specify the contract explicitly as opposed to relying on HTTP-level contracts matching our intent. Thanks, Robert _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
