AW: our own status code 562 in HTTP ...

Dear Florian, all,

thanks for this analysis.

I think what we need to make clear in both the spec and the documentation regarding the resolution of the LC comment is that - in contrast to WebDAV - we are not using these codes as return values of an HTTP request, but as a status in the methods of our API. I think this makes a difference.

But in general I think that WebDAV is an example that defines new status codes beyond those of the original HTTP 1.1 spec (e.g. 507 in [6]). 

RFC 2616 states in section 1.1:

"HTTP status codes are extensible. HTTP applications are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable. However, applications MUST
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 status code of that class, with the exception that an
   unrecognized response MUST NOT be cached. For example, if an
   unrecognized status code of 431 is received by the client, it can
   safely assume that there was something wrong with its request and
   treat the response as if it had received a 400 status code. In such
   cases, user agents SHOULD present to the user the entity returned
   with the response, since that entity is likely to include human-
   readable information which will explain the unusual status."

I think that our extension would confirm to this even if it was a real response to an HTTP  request. As it is not, the issue is even less critical in my opinion.

Best regards,
Werner

[6] https://tools.ietf.org/html/rfc4918#section-9.3.1
________________________________________
Von: public-media-annotation-request@w3.org [public-media-annotation-request@w3.org] im Auftrag von Florian Stegmaier [stegmai@dimis.fim.uni-passau.de]
Gesendet: Dienstag, 27. September 2011 09:47
An: public-media-annotation@w3.org
Betreff: Fwd: our own status code 562 in HTTP ...

Dear all,

i had a look into the RFC4918 (WebDAV) as Yves proposed. As far as i
understand, they follow several different ways of defining their
status/error codes:

a) Usage of HTTP/1.1 status codes with different semantics
"[...] These HTTP codes are not redefined, but their use is somewhat
extended by WebDAV methods and requirements. In general, many HTTP
status codes can be used in response to any request, not just in cases
described in this document. Note also that WebDAV servers are known to
use 300-level redirect responses (and early interoperability tests
found clients unprepared to see those responses). A 300-level response
MUST NOT be used when the server has created a new resource in
response to the request. [...]" (see [1])
-> We could follow this way and "somehow extend" an appropriate HTTP/
1.1 status code

b) Status Code Extensions to HTTP/1.1 (section 11)
-> From my point of view, maybe "11.2. 422 Unprocessable Entity" could
be used instead of 462. But the semantics of it are not quiet the
same. The definition is as follows:
The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained
instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions. (see [1])

c) Different semantics for a status code due to its use in different
domains (e.g., 403 Forbidden in [3] vs. 403 Forbidden in [4])

Inside the PROPFIND [5] method, they specify several different status
codes. It seems, they have not covered the case if a property is
called which is not implemented. Maybe the following would fit?

404 Not Found - The property does not exist. (section 9.1.2.) -> Maybe
we should use 404 and use our own more specific description?

These are the findings i can provide until now.

Best,
Florian

[1] https://tools.ietf.org/html/rfc4918#section-12
[2] https://tools.ietf.org/html/rfc4918#section-11.2
[3] https://tools.ietf.org/html/rfc4918#section-9.1.1
[4] https://tools.ietf.org/html/rfc4918#section-9.1.2
[5] https://tools.ietf.org/html/rfc4918#section-9.1

Anfang der weitergeleiteten E-Mail:

> Von: Thierry MICHEL <tmichel@w3.org>
> Datum: 26. September 2011 08:13:07 GMT+02:00
> An: Florian Stegmaier <stegmai@dimis.fim.uni-passau.de>,  "public-media-annotation@w3.org
> " <public-media-annotation@w3.org>
> Betreff: Fwd: Re: our own status code 562 in HTTP ...
> Antwort an: tmichel@w3.org
>
> Florian,
>
> Could you please take a look at Yves's proposal
>
> We could dicuss it tomorrow during the MAWG telecon.
>
> Thierry.
>
>
>
> -------- Message original --------
> Sujet: Re: our own status code 562 in HTTP ...
> Date : Sun, 25 Sep 2011 02:27:01 -0400 (EDT)
> De : Yves Lafon <ylafon@w3.org>
> Pour : Thierry MICHEL <tmichel@w3.org>
> Copie à : public-media-annotation@w3.org <public-media-annotation@w3.org
> >
>
> On Thu, 22 Sep 2011, Thierry MICHEL wrote:
>
>> Today during the call of the Request for a Transition to CR: API
>> for Media
>> Resources 1.0
>> http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/CR/
>>
>>
>> The Director has rejected the Transition due to the MAWG response
>> to the
>> following comment sent during Last Call: use of HTTP 501
>> http://lists.w3.org/Archives/Public/public-media-annotation/2011Aug/0031.html
>>
>> The MAWG response:
>> http://lists.w3.org/Archives/Public/public-media-annotation/2011Sep/0043.html
>> ------------
>>
>> We have discussed this issue during the 12th Face-to-Face meeting
>> and agreed
>> that the 501 status code does not fit our needs. In order to have a
>> clear
>> semantic, we have decided to declare our own status code, as follows:
>> - Numerical Code: 562
>> - Textual description: Property not supported
>> - Example: only a subset of GET methods for properties implemented
>
> I'd like to understand clearly what is the intended meaning of this.
> I noted as well a 462 "Property not defined in Source Format" which
> seems
> to be really a 404.
> You should take a look at WebDAV, RFC4918 and the way they retrieve
> properties <https://tools.ietf.org/html/rfc4918> .
>
> You should also take a look at RFC5988 for HTTP linking.
> https://tools.ietf.org/html/rfc5988
>
>
>
>> ---------------------------------
>>
>> as defined in our API spec
>> http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/CR/Overview.html#api-status-codes
>>
>>
>>
>> The Director said that we should have your agreement Yves, as HTTP
>> spec
>> editor, for this declaration of our own status code 562.
>>
>> This is not part of the main HTTP 1.1 protocol, are there
>> guidelines anywhere
>> for implementing proprietary HTTP error codes?
>> If you agree we can proceed the Transition.
>>
>> Or would you suggest another solution ?
>>
>> We must solve this issue before moving the API spec forward.
>>
>> Thanks for your help,
>>
>> Thierry.
>>
>>
>>
>>
>>
>>
>
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves

Received on Wednesday, 28 September 2011 08:23:21 UTC