- From: Florian Stegmaier <stegmai@dimis.fim.uni-passau.de>
- Date: Tue, 4 Oct 2011 08:29:27 +0200
- To: public-media-annotation@w3.org
Hi PA! Thank you very much for your comments. I respond to them inline. Am 29.09.2011 um 15:47 schrieb Pierre-Antoine Champin: > 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. I share the same feeling. > 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. That´s right. We should have an agreement of how to proceed in today´s teleconf. > 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 _____________________________ Dipl. Inf. Florian Stegmaier Chair of Distributed Information Systems University of Passau Innstr. 43 94032 Passau Room 248 ITZ Tel.: +49 851 509 3063 Fax: +49 851 509 3062 https://www.dimis.fim.uni-passau.de/iris/ http://twitter.com/fstegmai _____________________________
Received on Tuesday, 4 October 2011 06:30:07 UTC