[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.
Plus, Table 1 in draft-ietf-alto-protocol could be updated to
match the requirement as follows:
| E_OVERLOAD | 503 | ALTO server overloaded |
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.
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.
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
