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

Hi,

Considering Florian's proposal to use 422 instead of 462, why not. The
(slight) drawback that I can see is that we refer, even if informally,
to one more document, as this code is not native HTTP, but a WEBDAV
extension. I think Yves's suggestion was see how WEBDAV proceeded to
extend HTTP, not necessarily to reuse their return codes.

But eitheway, I agree with Werner: this is really not a critical issue
as we are using those code in HTTP; we are only using HTTP codes as
basis that is easier to understand for web developers than different set
of codes.

Maybe this last point should be explicitly mentioned to Yves as well.

  pa


On 09/28/2011 10:22 AM, Bailer, Werner wrote:
> 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 Thursday, 29 September 2011 13:48:03 UTC