Re: [Geopriv] draft-ietf-geopriv-http-location-delivery-00 - ErrorReporting

From: Henning Schulzrinne ^lt;>
Date: Thu Jun 28 2007 - 05:49:55 EDT

I think it makes sense to have a common model between LoST and HELD,
as the issues are relatively similar. For what it's worth, the LoST
author team decided to follow the layering advice given below - all
LoST responses are in an HTTP 200 OK message, as that indicates that
HTTP was able to handle the request, even if LoST (or other protocol
layered on top) had difficulties. In addition to the layering reasons
given, I think it tends to make the implementation cleaner and avoids
strange programming errors, where an implementor gets the response
code for a particular HELD or LoST condition wrong. The HTTP status
code adds no additional information, and only means that the
implementation has to cope with a "HTTP says bad thing X happened,
but next-layer says Y, which do I believe?". This seems to mainly
result in more test cases. (FWIW, the 06 revision of LoST will make
this behavior a bit clearer, but it's really just a one-sentence


On Jun 27, 2007, at 4:18 PM, Lisa Dusseault wrote:

>> On Jun 19, 2007, at 12:14 AM, Winterbottom, James wrote:
>> In so far as it makes sense to do this mapping I don't see a problem.
>> I notice for example that in the current LoST specification only one
>> HTTP error code is mapped, and this is for the Forbidden case. Is
>> there
>> a plan to add other mapping, say for the timeout case, to LoST also?
> I don't know about LoST but I'd probably make the same
> recommendation in either case: be clear about what HTTP error codes
> mean in the context of an application extending HTTP.
> Since I have reviewed HELD, my specific recommendations for HELD
> status codes are:
> 1. For each internal status code, specify what HTTP response status
> code goes with it. Otherwise you'll end up seeing 200 OK
> encapsulating HELD errors, or PIDF-LO objects inside 403 Forbidden
> codes, and not know whether this is intended or a bug or what the
> interpretation ought to be.
> A more cleanly layered model is that any status code other than 200
> indicates a response generated at the HTTP layer rather than by the
> LCS. A 500 response code would indicate that the HTTP server was
> having problems and the LCS didn't even see the request. Any
> answer generated by the LCS implementation could arrive inside a
> 200 OK response body -- the outer status message meaning "The
> request was successfully delivered to the layered application and
> the response is from the layered application". That means that a
> non-compliant "application/held+xml" request document would result
> in a 200 OK message -- the LCS received the request -- but inside
> the 200 OK response the LCS would put some kind of "bad HELD
> request" error message.
> 2. I suggest using something that doesn't look exactly like a HTTP
> status code, otherwise you'll see HTTP status codes used where HELD
> status codes ought to be. E.g. a response with 402 in the HTTP
> status line when the intended meaning is "Authentication
> Error" (from HELD) rather than "Payment Required" (what HTTP 402
> status really means). It's particularly bad that authentication
> errors are different in HTTP and HELD. See point 5.
> This doesn't have to be very different to be differentiable.
> - You could simply prefix each HELD error code with a letter like
> 'L' for Location, then have L200, L400, L401 etc.
> - You could use letters instead of number ranges to indicate class
> of status code: 's' for success, 'ec' for error by client and 'es'
> for error by server, and 'ep' for private errors. (e.g. s00, ec00,
> ec01, es00, ep05).
> 3. Are all the other HTTP status codes not mentioned in this
> document legal or illegal? MUST the client support redirects, or
> are servers REQUIRED NOT to use redirects? 102 Processing? 412
> Precondition Failed?
> 4. Since the set of error codes is explicitly extensible for
> private use, what is the client supposed to do with unrecognized
> HELD error codes?
> 5. Why is there an authentication error at the HELD layer?
> Authentication does not appear to be done at the HELD layer. OTOH
> it is not clear whether it can be done at the HTTP layer either
> (whether HELD clients are required to support HTTP authentication
> challenges). This may be a layering violation.
> Lisa
>> Cheers
>> James
>>> -----Original Message-----
>>> From: Henning Schulzrinne []
>>> Sent: Tuesday, 19 June 2007 4:46 PM
>>> To: Cullen Jennings
>>> Subject: Re: [Geopriv] draft-ietf-geopriv-http-location-
>>> delivery-00 -
>>> ErrorReporting
>>> I'm not sure I understand your comment. As written, HELD uses 3-
>>> digit
>>> numeric status codes that look like HTTP codes and have some
>>> resemblance in the first digit, but otherwise have nothing to do
>>> with
>>> the HTTP number space. I consider that another reason not to do
>>> that.
>>> (RELO was able to avoid this by relying only on HTTP status codes,
>>> but I digress.)
>>> A separate issue, left unaddressed currently, is which HTTP status
>>> codes go along with which HELD error messages, however coded.
>>> On Jun 18, 2007, at 10:23 PM, Cullen Jennings wrote:
>>>> (splitting thread)
>>>>> We should probably revisit some of the discussions we've had for
>>>>> LoST, which have led us to abandon the concept of status codes in
>>>>> favor of "real" XML. I won't repeat the arguments (Andy can chime
>>>>> in...), but the basic idea was that this makes debugging and
>>>>> validation easier and seems much more in the spirit of XML. Using
>>>>> codes that are almost, but not quite, the same as HTTP (or SIP)
>> seems
>>>>> to be an invitation for confusion or creative extensions where
>>>>> HTTP
>>>>> codes are "borrowed".
>>>>> [MB] It does seem reasonable to consider the approach you suggest.
>>>>> But,
>>>>> unless someone
>>>>> strongly disagrees, we can make that change. [/MB]
>>>> Webdav has a model where some of the error codes end up in the HTTP
>>>> response and some in an XML body. As an ex-chair of that wg, I can
>>>> say that this was hard to get right. I'm not sure what advice to
>>>> give but I think it is well worth careful attention to figuring out
>>>> the semantics of if you need two places for errors, how to keep
>>>> them from contradicting, and the semantics of what type of error
>>>> gets reported where.
>>>> _______________________________________________
>>>> Geopriv mailing list
>>> _______________________________________________
>>> Geopriv mailing list
>> ---------------------------------------------------------------------
>> ---------------------------
>> This message is for the designated recipient only and may
>> contain privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender
>> immediately and delete the original. Any unauthorized use of
>> this email is prohibited.
>> ---------------------------------------------------------------------
>> ---------------------------
>> [mf2]
>> _______________________________________________
>> Geopriv mailing list

Geopriv mailing list
Received on Thu, 28 Jun 2007 05:49:55 -0400

This archive was generated by hypermail 2.1.8 : Thu Jun 28 2007 - 12:12:56 EDT