-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarification of weak validators #163
Comments
Mailing list thread: https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0041.html |
Not sure any change is necessary here. |
Discussed in Singapore; agreed to close this with no action, but @martinthomson offered to check if the text around validators could be clarified. |
Just to close the loop on this, the document is entirely precise and perfectly obtuse at the same time. It says that the validator applies to the selected representation. So following the reference to Section 6 I find that the definition of selected representation correctly captures all the nuance, but fails to provide the easy cognitive shortcut of "selected representation =~ message body". It manages to effectively obfuscate things by not clearly distinguishing between serialization and the abstract concept of what the resource state is. I believe that selected representation is the specific projection of the platonic resource into bytes. However, it doesn't really say that, it says that you interpret "bits" through the dual filters of content type and content coding. Using "bits" is unfortunate. XML schema has the dual notions of "value space" (the abstract form) and "lexical space" (the encoded form) and is very careful about being clear about which applies in which context. This is not clear in the same way. For instance, the idea that a representation is an abstraction (as stated) is something I find quite confusing. The selected representation is a concrete form, expressed as a sequence of bytes. That representation might be conveyed on the wire (a GET response sometimes, a PUT request) or it might be acted on or referred to. Some methods operate exclusively on the bytes of a selected representation, even if those bytes don't hit the wire. In short, the spec is correct, but it doesn't do a great job of teaching the protocol. |
As that's a more general issue, closing in favour of #294. |
So should we reject https://www.rfc-editor.org/errata/eid5236 then? |
See https://www.rfc-editor.org/errata/eid5236
The text was updated successfully, but these errors were encountered: