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

here is Yves' response to my earlier email

-------- Message original --------
Sujet: Re: Fwd: Re: AW: our own status code 562 in HTTP ...
Date : Tue, 4 Oct 2011 16:33:13 -0400 (EDT)
De : Yves Lafon <ylafon@w3.org>
Pour : Thierry MICHEL <tmichel@w3.org>

On Thu, 29 Sep 2011, Thierry MICHEL wrote:

See comments inline:

> -------- Message original --------
> Sujet: Re: AW: our own status code 562 in HTTP ...
> Date de renvoi : Thu, 29 Sep 2011 13:48:05 +0000
> De (renvoi) : public-media-annotation@w3.org
> Date : Thu, 29 Sep 2011 15:47:25 +0200
> De : Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
> Pour : Bailer, Werner <werner.bailer@joanneum.at>
> Copie à : Florian Stegmaier <stegmai@dimis.fim.uni-passau.de>,
> "public-media-annotation@w3.org" <public-media-annotation@w3.org>
>
> 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.

WebDAV uses a 404 when a PROPFIND is issues on a inexistent property, it
seems that you are doing roughly the same thing (querying a potentially
inexistent property), but you want to define a 562 (or 462) for that, and
there is no real reason to consume an HTTP status code.

> 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.

You can signal fine-tune information through the body of the error
message returned back, or even through extra http headers...


>  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
>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 5 October 2011 06:10:53 UTC