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. > I don't know the semantics of HTTP at a protocol level enough to > determine whether one can put an alternate location in a 503 response. > If so, then a 503/Location provides an unambiguous view of what to > do. I see no mention that Location can't appear in a 5xx response: http://tools.ietf.org/html/rfc2616#section-14.30 Under the spec for the 5xx error codes (and 503 in particular), I don't see anything that says one can't use a Location header: http://tools.ietf.org/html/rfc2616#section-10.5 Indeed, for 503 it suggests that a server can use the Retry-After header to indicate when it should be retried. It doesn't seem that far of a leap to suggest an alternate location as well. Of course, an opinion from someone more familiar with the intricacies (*cough* Ben, Martin) might be useful here :) > If not, then the HTTP status code of 307 could be used for redirection. > I will leave that to the authors of the protocol draft on whether we > want to include the 307 response code in Table 1 or not. I would tend to think that 307 is more of an HTTP-layer concern, and that we don't need to mention it in the status code table. The dependency on RFC2616 should be enough to advise clients that they should follow redirects. Rich > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / [email protected] > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
