Rich,
I also would like not to replicate and, for the sake of discussion, say, return
(-1) or bytes read to the ALTO layer.
But the current status is more complicated. We already have a mixed bag of
things crossing layers.
We already replicate ALTO error codes into HTTP (ALTO->HTTP direction)
" The HTTP status codes corresponding to each ALTO Error Code are
defined to provide correct behavior with HTTP intermediaries and
clients. When an ALTO Server returns a particular ALTO Error Code,
it MUST indicate one of the corresponding HTTP status codes in
Table 1 in the HTTP response. "
And we ask clients to interpret HTTP status codes (HTTP->ALTO direction)
" o Return an HTTP 503 ("Service Unavailable") status code to the ALTO
Client. As indicated by [RFC2616<http://tools.ietf.org/html/rfc2616>], a
the Retry-After HTTP header
may be used to indicate when the ALTO Client should retry the
request."
As far as your last point…
"My difference in opinion is that I think that should be an implementation
detail hidden behind the API an ALTO Client exposes."
If something does not change the on the wire protocol or reaction to it (such
as, e.g., congestion control) would be okay to categorize it as an
implementation issue. But in this case it does, and that's why we are having
this discussion. Otherwise, yes, I agree with you.
Let's find some wording.
Thanks,
Reinaldo
From: Richard Alimi <[email protected]<mailto:[email protected]>>
Date: Fri, 15 Mar 2013 07:34:53 -0700
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: [alto] Error codes in ALTO
There is a discussion as to whether the ALTO client needs to interpret HTTP
status codes. I've started this thread to discuss that.
Here's my view:
We now have a REST-ful protocol and made a conscious decision to go this way.
REST-ful protocols are built upon making requests and following links to other
resources. (This is why we restructured the existing protocol to remove all
references to "ALTO Request" and "ALTO Response".)
Therefore, the ALTO protocol is *not* a traditional client-server protocol like
TCP, but is instead an encoding for HTTP resources that allow clients to
discover the type of information described in the initial problem statement.
Replicating HTTP status codes to the ALTO layer sounds like we are replicating
a lot of what HTTP does already.
I understand that someone using ALTO should not be burdened with HTTP status
codes. My difference in opinion is that I think that should be an
implementation detail hidden behind the API an ALTO Client exposes.
Thanks,
Rich
_______________________________________________ alto mailing list
[email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
