Hey Cyril, I saw some of your comments [1] [2] on twitter about OCCI. It'd be great if you could elaborate on them on the list as everyone here really values useful and constructive comments and critique. BTW: you might have been viewing older OCCI specs. The latest published are here [3]. Cheers, Andy andy.edmonds.be [1] https://twitter.com/#!/crohr/status/89318560417067008 [2] https://twitter.com/#!/crohr/status/89320097755312128 [3] http://ogf.org/gf/docs/
Hi Andy, all, It's hard to be constructive in 140 characters, so thanks for letting me elaborate on this list. My concerns are related to the "RESTful HTTP Rendering" spec [1], which views HTTP headers as the primary mean of transferring resource representations between a user-agent and an OCCI server. I can see how you you may have ended there (no need to define a media type, "universality" of the HTTP protocol, new RFC drafts about `Category` [4] and `Link` [5] headers popping up, etc.), but that just looks wrong to me for the following reasons: * The most obvious, and a point that you raise in the spec [1], is that the HTTP header max size is often limited by intermediaries (for instance, default limit on Squid is 20KB [2]), while body max size is not. The spec warns: "Space in the HTTP header section of a HTTP request is a limited resource. By this, it is noted that many HTTP servers limit the number of bytes that can be placed in the HTTP Header area. Implementers MUST be aware of this limitation in their own implementation and take appropriate measures so that truncation of header data does NOT occur." You can't assume that there won't be intermediaries between the user-agent and the server (proxies, caches, etc.), therefore I don't see how an implementer can do anything about the header size limit, which means it is safe to assume that the HTTP Rendering via `text/occi` is broken (unless you have already thought about a possible solution, in which case it should be included in the spec). You can't even use the `Content-MD5` [3] header to provide an end-to-end message integrity check. And the message header is not compressible, contrary to the message body. * More generally, methods and headers are there to indicate the purpose of a request, not the resource representation itself. * Finally, you define a `text/occi` content-type, which looks like an empty shell. I mean, if I understand correctly, the only payload you'll ever have is "OK" on successful operations. AFAIK, a media type definition [6] is mainly about the structure and semantics of the message body. It's not about defining custom HTTP headers to replace the message body. I also have some concerns about the filtering mechanism, linking mechanism and the way you define actions, but if I had to sum up my position it would be that I have the feeling that you went extreme with the REST concept, and tried to put in the spec as much novelty (in terms of recent HTTP-related specs/drafts) as you could. Nothing wrong with that, but the result is somewhat convoluted. Also, the decision to put everything in the header part of the message renders a lot of standard HTTP header fields useless. I appreciate the effort and time it takes to build a spec like this. From a standardization body though, I would have expected that you properly define a new media type for the rendering, not custom header extensions. I recall a (now dead?) XHTML based rendering doc, which had some flaws but was going more in that direction. I can see that you plan on specifying new content types in the future: I think it would be good to shift the attention back to the body. Thank you for your time. Best Regards, Cyril -- http://crohr.me [1] <http://ogf.org/documents/GFD.185.pdf> [2] <http://www.squid-cache.org/Versions/v2/2.6/cfgman/request_header_max_size.html> [3] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html> [4] <http://tools.ietf.org/html/draft-johnston-http-category-header-01> [5] <http://tools.ietf.org/rfc/rfc5988.txt> [6] <http://www.ietf.org/rfc/rfc1521.txt> On 8 Jul 2011, at 18:03, Andy Edmonds wrote:
Hey Cyril, I saw some of your comments [1] [2] on twitter about OCCI. It'd be great if you could elaborate on them on the list as everyone here really values useful and constructive comments and critique.
BTW: you might have been viewing older OCCI specs. The latest published are here [3].
Cheers,
Andy andy.edmonds.be
[1] https://twitter.com/#!/crohr/status/89318560417067008 [2] https://twitter.com/#!/crohr/status/89320097755312128 [3] http://ogf.org/gf/docs/
Hi, Thanks for your reply - much appreciated. Just a quick note from me: The default rendering of OCCI is text/plain and than the content goes in the body. The reason for the text/occi rendering are mostly historical :-) Or because of filtering we don't want to have something in the body of an GET request... There are also some efforts going on to create JSON renderings for OCCI...just FYI. Cheers, -Thijs -----Original Message----- From: occi-wg-bounces@ogf.org on behalf of Cyril Rohr Sent: Mon 11.07.2011 11:32 To: Andy Edmonds Cc: occi-wg Subject: Re: [occi-wg] Your Questions... Hi Andy, all, It's hard to be constructive in 140 characters, so thanks for letting me elaborate on this list. My concerns are related to the "RESTful HTTP Rendering" spec [1], which views HTTP headers as the primary mean of transferring resource representations between a user-agent and an OCCI server. I can see how you you may have ended there (no need to define a media type, "universality" of the HTTP protocol, new RFC drafts about `Category` [4] and `Link` [5] headers popping up, etc.), but that just looks wrong to me for the following reasons: * The most obvious, and a point that you raise in the spec [1], is that the HTTP header max size is often limited by intermediaries (for instance, default limit on Squid is 20KB [2]), while body max size is not. The spec warns: "Space in the HTTP header section of a HTTP request is a limited resource. By this, it is noted that many HTTP servers limit the number of bytes that can be placed in the HTTP Header area. Implementers MUST be aware of this limitation in their own implementation and take appropriate measures so that truncation of header data does NOT occur." You can't assume that there won't be intermediaries between the user-agent and the server (proxies, caches, etc.), therefore I don't see how an implementer can do anything about the header size limit, which means it is safe to assume that the HTTP Rendering via `text/occi` is broken (unless you have already thought about a possible solution, in which case it should be included in the spec). You can't even use the `Content-MD5` [3] header to provide an end-to-end message integrity check. And the message header is not compressible, contrary to the message body. * More generally, methods and headers are there to indicate the purpose of a request, not the resource representation itself. * Finally, you define a `text/occi` content-type, which looks like an empty shell. I mean, if I understand correctly, the only payload you'll ever have is "OK" on successful operations. AFAIK, a media type definition [6] is mainly about the structure and semantics of the message body. It's not about defining custom HTTP headers to replace the message body. I also have some concerns about the filtering mechanism, linking mechanism and the way you define actions, but if I had to sum up my position it would be that I have the feeling that you went extreme with the REST concept, and tried to put in the spec as much novelty (in terms of recent HTTP-related specs/drafts) as you could. Nothing wrong with that, but the result is somewhat convoluted. Also, the decision to put everything in the header part of the message renders a lot of standard HTTP header fields useless. I appreciate the effort and time it takes to build a spec like this. >From a standardization body though, I would have expected that you properly define a new media type for the rendering, not custom header extensions. I recall a (now dead?) XHTML based rendering doc, which had some flaws but was going more in that direction. I can see that you plan on specifying new content types in the future: I think it would be good to shift the attention back to the body. Thank you for your time. Best Regards, Cyril -- http://crohr.me [1] <http://ogf.org/documents/GFD.185.pdf> [2] <http://www.squid-cache.org/Versions/v2/2.6/cfgman/request_header_max_size.html> [3] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html> [4] <http://tools.ietf.org/html/draft-johnston-http-category-header-01> [5] <http://tools.ietf.org/rfc/rfc5988.txt> [6] <http://www.ietf.org/rfc/rfc1521.txt> On 8 Jul 2011, at 18:03, Andy Edmonds wrote:
Hey Cyril, I saw some of your comments [1] [2] on twitter about OCCI. It'd be great if you could elaborate on them on the list as everyone here really values useful and constructive comments and critique.
BTW: you might have been viewing older OCCI specs. The latest published are here [3].
Cheers,
Andy andy.edmonds.be
[1] https://twitter.com/#!/crohr/status/89318560417067008 [2] https://twitter.com/#!/crohr/status/89320097755312128 [3] http://ogf.org/gf/docs/
Hi Thijs, I didn't talk about `text/plain` because IMO it's even worse than `text/occi`. How a user-agent is supposed to know that it's receiving a payload containing OCCI attributes? Looking at the `Content-Type` header it'll just assume that it is receiving free-form text from the server. Unless it has out-of-band knowledge of which <HTTP verb/URI> tuple is supposed to return OCCI-formatted content. Which is not something you would expect from a "RESTful" spec. I'm actually a bit surprised that this has been made the default content-type. Regarding your comment about filtering, I must say I don't see how this relates to the media type discussion. Filtering is usually achieved using query strings, or (what you're already doing) the use of `Category` headers. If you had a proper media type, you could also define URI templates for this. My point being that I don't understand the relationship between not putting a body in the `GET` request (which is indeed wrong), and the need for `text/occi` in addition to `text/plain`. I may have misunderstood your comment though ;-) Cheers, Cyril -- http://crohr.me On 11 Jul 2011, at 11:36, Thijs Metsch wrote:
Hi,
Thanks for your reply - much appreciated.
Just a quick note from me: The default rendering of OCCI is text/plain and than the content goes in the body. The reason for the text/occi rendering are mostly historical :-) Or because of filtering we don't want to have something in the body of an GET request...
There are also some efforts going on to create JSON renderings for OCCI...just FYI.
Cheers,
-Thijs
-----Original Message----- From: occi-wg-bounces@ogf.org on behalf of Cyril Rohr Sent: Mon 11.07.2011 11:32 To: Andy Edmonds Cc: occi-wg Subject: Re: [occi-wg] Your Questions...
Hi Andy, all,
It's hard to be constructive in 140 characters, so thanks for letting me elaborate on this list.
My concerns are related to the "RESTful HTTP Rendering" spec [1], which views HTTP headers as the primary mean of transferring resource representations between a user-agent and an OCCI server. I can see how you you may have ended there (no need to define a media type, "universality" of the HTTP protocol, new RFC drafts about `Category` [4] and `Link` [5] headers popping up, etc.), but that just looks wrong to me for the following reasons:
* The most obvious, and a point that you raise in the spec [1], is that the HTTP header max size is often limited by intermediaries (for instance, default limit on Squid is 20KB [2]), while body max size is not. The spec warns:
"Space in the HTTP header section of a HTTP request is a limited resource. By this, it is noted that many HTTP servers limit the number of bytes that can be placed in the HTTP Header area. Implementers MUST be aware of this limitation in their own implementation and take appropriate measures so that truncation of header data does NOT occur."
You can't assume that there won't be intermediaries between the user-agent and the server (proxies, caches, etc.), therefore I don't see how an implementer can do anything about the header size limit, which means it is safe to assume that the HTTP Rendering via `text/occi` is broken (unless you have already thought about a possible solution, in which case it should be included in the spec). You can't even use the `Content-MD5` [3] header to provide an end-to-end message integrity check. And the message header is not compressible, contrary to the message body.
* More generally, methods and headers are there to indicate the purpose of a request, not the resource representation itself.
* Finally, you define a `text/occi` content-type, which looks like an empty shell. I mean, if I understand correctly, the only payload you'll ever have is "OK" on successful operations. AFAIK, a media type definition [6] is mainly about the structure and semantics of the message body. It's not about defining custom HTTP headers to replace the message body.
I also have some concerns about the filtering mechanism, linking mechanism and the way you define actions, but if I had to sum up my position it would be that I have the feeling that you went extreme with the REST concept, and tried to put in the spec as much novelty (in terms of recent HTTP-related specs/drafts) as you could. Nothing wrong with that, but the result is somewhat convoluted. Also, the decision to put everything in the header part of the message renders a lot of standard HTTP header fields useless.
I appreciate the effort and time it takes to build a spec like this. From a standardization body though, I would have expected that you properly define a new media type for the rendering, not custom header extensions. I recall a (now dead?) XHTML based rendering doc, which had some flaws but was going more in that direction. I can see that you plan on specifying new content types in the future: I think it would be good to shift the attention back to the body.
Thank you for your time. Best Regards,
Cyril -- http://crohr.me
[1] <http://ogf.org/documents/GFD.185.pdf> [2] <http://www.squid-cache.org/Versions/v2/2.6/cfgman/request_header_max_size.html> [3] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html> [4] <http://tools.ietf.org/html/draft-johnston-http-category-header-01> [5] <http://tools.ietf.org/rfc/rfc5988.txt> [6] <http://www.ietf.org/rfc/rfc1521.txt>
On 8 Jul 2011, at 18:03, Andy Edmonds wrote:
Hey Cyril, I saw some of your comments [1] [2] on twitter about OCCI. It'd be great if you could elaborate on them on the list as everyone here really values useful and constructive comments and critique.
BTW: you might have been viewing older OCCI specs. The latest published are here [3].
Cheers,
Andy andy.edmonds.be
[1] https://twitter.com/#!/crohr/status/89318560417067008 [2] https://twitter.com/#!/crohr/status/89320097755312128 [3] http://ogf.org/gf/docs/
I think that Cyril is right, and we should address this. Frankly, I never understood the purpose of the text/plain rendering, for exactly the reasons Cyril stated in his e-mail, and I very much doubt the idea of text/occi. Actually, both make implementing the spec quite a pain. Personally, I like the idea of using the headers for transporting REST resource metadata, as long as we don't overdo it -- I think the Link headers are a good example of doing the right thing. Regarding categories, I am quite confident that, for indicating the "kind" of a resource (clearly being metadata), the "Category" header is a good way of doing it. For filtering, I'd support Cyril in so far that query strings have been made for exactly this purpose. Just my two cents to keep the fire burning ;-) -Alexander Am 11.07.2011 um 12:20 schrieb Cyril Rohr:
Hi Thijs,
I didn't talk about `text/plain` because IMO it's even worse than `text/occi`. How a user-agent is supposed to know that it's receiving a payload containing OCCI attributes? Looking at the `Content-Type` header it'll just assume that it is receiving free-form text from the server. Unless it has out-of-band knowledge of which <HTTP verb/URI> tuple is supposed to return OCCI-formatted content. Which is not something you would expect from a "RESTful" spec. I'm actually a bit surprised that this has been made the default content-type.
Regarding your comment about filtering, I must say I don't see how this relates to the media type discussion. Filtering is usually achieved using query strings, or (what you're already doing) the use of `Category` headers. If you had a proper media type, you could also define URI templates for this. My point being that I don't understand the relationship between not putting a body in the `GET` request (which is indeed wrong), and the need for `text/occi` in addition to `text/plain`. I may have misunderstood your comment though ;-)
Cheers,
Cyril -- http://crohr.me
On 11 Jul 2011, at 11:36, Thijs Metsch wrote:
Hi,
Thanks for your reply - much appreciated.
Just a quick note from me: The default rendering of OCCI is text/plain and than the content goes in the body. The reason for the text/occi rendering are mostly historical :-) Or because of filtering we don't want to have something in the body of an GET request...
There are also some efforts going on to create JSON renderings for OCCI...just FYI.
Cheers,
-Thijs
-----Original Message----- From: occi-wg-bounces@ogf.org on behalf of Cyril Rohr Sent: Mon 11.07.2011 11:32 To: Andy Edmonds Cc: occi-wg Subject: Re: [occi-wg] Your Questions...
Hi Andy, all,
It's hard to be constructive in 140 characters, so thanks for letting me elaborate on this list.
My concerns are related to the "RESTful HTTP Rendering" spec [1], which views HTTP headers as the primary mean of transferring resource representations between a user-agent and an OCCI server. I can see how you you may have ended there (no need to define a media type, "universality" of the HTTP protocol, new RFC drafts about `Category` [4] and `Link` [5] headers popping up, etc.), but that just looks wrong to me for the following reasons:
* The most obvious, and a point that you raise in the spec [1], is that the HTTP header max size is often limited by intermediaries (for instance, default limit on Squid is 20KB [2]), while body max size is not. The spec warns:
"Space in the HTTP header section of a HTTP request is a limited resource. By this, it is noted that many HTTP servers limit the number of bytes that can be placed in the HTTP Header area. Implementers MUST be aware of this limitation in their own implementation and take appropriate measures so that truncation of header data does NOT occur."
You can't assume that there won't be intermediaries between the user-agent and the server (proxies, caches, etc.), therefore I don't see how an implementer can do anything about the header size limit, which means it is safe to assume that the HTTP Rendering via `text/occi` is broken (unless you have already thought about a possible solution, in which case it should be included in the spec). You can't even use the `Content-MD5` [3] header to provide an end-to-end message integrity check. And the message header is not compressible, contrary to the message body.
* More generally, methods and headers are there to indicate the purpose of a request, not the resource representation itself.
* Finally, you define a `text/occi` content-type, which looks like an empty shell. I mean, if I understand correctly, the only payload you'll ever have is "OK" on successful operations. AFAIK, a media type definition [6] is mainly about the structure and semantics of the message body. It's not about defining custom HTTP headers to replace the message body.
I also have some concerns about the filtering mechanism, linking mechanism and the way you define actions, but if I had to sum up my position it would be that I have the feeling that you went extreme with the REST concept, and tried to put in the spec as much novelty (in terms of recent HTTP-related specs/drafts) as you could. Nothing wrong with that, but the result is somewhat convoluted. Also, the decision to put everything in the header part of the message renders a lot of standard HTTP header fields useless.
I appreciate the effort and time it takes to build a spec like this. From a standardization body though, I would have expected that you properly define a new media type for the rendering, not custom header extensions. I recall a (now dead?) XHTML based rendering doc, which had some flaws but was going more in that direction. I can see that you plan on specifying new content types in the future: I think it would be good to shift the attention back to the body.
Thank you for your time. Best Regards,
Cyril -- http://crohr.me
[1] <http://ogf.org/documents/GFD.185.pdf> [2] <http://www.squid-cache.org/Versions/v2/2.6/cfgman/request_header_max_size.html> [3] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html> [4] <http://tools.ietf.org/html/draft-johnston-http-category-header-01> [5] <http://tools.ietf.org/rfc/rfc5988.txt> [6] <http://www.ietf.org/rfc/rfc1521.txt>
On 8 Jul 2011, at 18:03, Andy Edmonds wrote:
Hey Cyril, I saw some of your comments [1] [2] on twitter about OCCI. It'd be great if you could elaborate on them on the list as everyone here really values useful and constructive comments and critique.
BTW: you might have been viewing older OCCI specs. The latest published are here [3].
Cheers,
Andy andy.edmonds.be
[1] https://twitter.com/#!/crohr/status/89318560417067008 [2] https://twitter.com/#!/crohr/status/89320097755312128 [3] http://ogf.org/gf/docs/
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
+1 On 7/12/2011 7:05 AM, alexander.papaspyrou@tu-dortmund.de wrote:
I think that Cyril is right, and we should address this.
Frankly, I never understood the purpose of the text/plain rendering, for exactly the reasons Cyril stated in his e-mail, and I very much doubt the idea of text/occi. Actually, both make implementing the spec quite a pain.
Personally, I like the idea of using the headers for transporting REST resource metadata, as long as we don't overdo it -- I think the Link headers are a good example of doing the right thing.
Regarding categories, I am quite confident that, for indicating the "kind" of a resource (clearly being metadata), the "Category" header is a good way of doing it. For filtering, I'd support Cyril in so far that query strings have been made for exactly this purpose.
Just my two cents to keep the fire burning ;-)
-Alexander
Am 11.07.2011 um 12:20 schrieb Cyril Rohr:
Hi Thijs,
I didn't talk about `text/plain` because IMO it's even worse than `text/occi`. How a user-agent is supposed to know that it's receiving a payload containing OCCI attributes? Looking at the `Content-Type` header it'll just assume that it is receiving free-form text from the server. Unless it has out-of-band knowledge of which<HTTP verb/URI> tuple is supposed to return OCCI-formatted content. Which is not something you would expect from a "RESTful" spec. I'm actually a bit surprised that this has been made the default content-type.
Regarding your comment about filtering, I must say I don't see how this relates to the media type discussion. Filtering is usually achieved using query strings, or (what you're already doing) the use of `Category` headers. If you had a proper media type, you could also define URI templates for this. My point being that I don't understand the relationship between not putting a body in the `GET` request (which is indeed wrong), and the need for `text/occi` in addition to `text/plain`. I may have misunderstood your comment though ;-)
Cheers,
Cyril -- http://crohr.me
On 11 Jul 2011, at 11:36, Thijs Metsch wrote:
Hi,
Thanks for your reply - much appreciated.
Just a quick note from me: The default rendering of OCCI is text/plain and than the content goes in the body. The reason for the text/occi rendering are mostly historical :-) Or because of filtering we don't want to have something in the body of an GET request...
There are also some efforts going on to create JSON renderings for OCCI...just FYI.
Cheers,
-Thijs
-----Original Message----- From: occi-wg-bounces@ogf.org on behalf of Cyril Rohr Sent: Mon 11.07.2011 11:32 To: Andy Edmonds Cc: occi-wg Subject: Re: [occi-wg] Your Questions...
Hi Andy, all,
It's hard to be constructive in 140 characters, so thanks for letting me elaborate on this list.
My concerns are related to the "RESTful HTTP Rendering" spec [1], which views HTTP headers as the primary mean of transferring resource representations between a user-agent and an OCCI server. I can see how you you may have ended there (no need to define a media type, "universality" of the HTTP protocol, new RFC drafts about `Category` [4] and `Link` [5] headers popping up, etc.), but that just looks wrong to me for the following reasons:
* The most obvious, and a point that you raise in the spec [1], is that the HTTP header max size is often limited by intermediaries (for instance, default limit on Squid is 20KB [2]), while body max size is not. The spec warns:
"Space in the HTTP header section of a HTTP request is a limited resource. By this, it is noted that many HTTP servers limit the number of bytes that can be placed in the HTTP Header area. Implementers MUST be aware of this limitation in their own implementation and take appropriate measures so that truncation of header data does NOT occur."
You can't assume that there won't be intermediaries between the user-agent and the server (proxies, caches, etc.), therefore I don't see how an implementer can do anything about the header size limit, which means it is safe to assume that the HTTP Rendering via `text/occi` is broken (unless you have already thought about a possible solution, in which case it should be included in the spec). You can't even use the `Content-MD5` [3] header to provide an end-to-end message integrity check. And the message header is not compressible, contrary to the message body.
* More generally, methods and headers are there to indicate the purpose of a request, not the resource representation itself.
* Finally, you define a `text/occi` content-type, which looks like an empty shell. I mean, if I understand correctly, the only payload you'll ever have is "OK" on successful operations. AFAIK, a media type definition [6] is mainly about the structure and semantics of the message body. It's not about defining custom HTTP headers to replace the message body.
I also have some concerns about the filtering mechanism, linking mechanism and the way you define actions, but if I had to sum up my position it would be that I have the feeling that you went extreme with the REST concept, and tried to put in the spec as much novelty (in terms of recent HTTP-related specs/drafts) as you could. Nothing wrong with that, but the result is somewhat convoluted. Also, the decision to put everything in the header part of the message renders a lot of standard HTTP header fields useless.
I appreciate the effort and time it takes to build a spec like this. From a standardization body though, I would have expected that you properly define a new media type for the rendering, not custom header extensions. I recall a (now dead?) XHTML based rendering doc, which had some flaws but was going more in that direction. I can see that you plan on specifying new content types in the future: I think it would be good to shift the attention back to the body.
Thank you for your time. Best Regards,
Cyril -- http://crohr.me
[1]<http://ogf.org/documents/GFD.185.pdf> [2]<http://www.squid-cache.org/Versions/v2/2.6/cfgman/request_header_max_size.html> [3]<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html> [4]<http://tools.ietf.org/html/draft-johnston-http-category-header-01> [5]<http://tools.ietf.org/rfc/rfc5988.txt> [6]<http://www.ietf.org/rfc/rfc1521.txt>
On 8 Jul 2011, at 18:03, Andy Edmonds wrote:
Hey Cyril, I saw some of your comments [1] [2] on twitter about OCCI. It'd be great if you could elaborate on them on the list as everyone here really values useful and constructive comments and critique.
BTW: you might have been viewing older OCCI specs. The latest published are here [3].
Cheers,
Andy andy.edmonds.be
[1] https://twitter.com/#!/crohr/status/89318560417067008 [2] https://twitter.com/#!/crohr/status/89320097755312128 [3] http://ogf.org/gf/docs/
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Thanks for the useful feedback Cyril! :-) There has been quite some discussion both here on the mailing list, in F2Fs and also on the IRC about the use of headers. In fact, I think what you raise here is quite a good summary of those discussions that were had. Using the OCCI text syntax within the header, from my POV, is now largely historical and for the those related comments I can't disagree. What should be noted is that the HTTP rendering spec details how a text-based syntax can be relayed between client and service. It does note that the content can be in the header but the default is in the body. To other aspects - yes filtering in my view is simple and there has been talk about making it a little more encompassing (e.g. addition of logical operators). The origins of actions are from this detailed conversation [1] over on Tim Bray's blog. We'd love to know more about any reservations about the linking scheme. Also do you see anything that could be brought to the spec to improve it? Regards, Andy andy.edmonds.be [1] http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry On Mon, Jul 11, 2011 at 10:32, Cyril Rohr <contact@crohr.me> wrote:
Hi Andy, all,
It's hard to be constructive in 140 characters, so thanks for letting me elaborate on this list.
My concerns are related to the "RESTful HTTP Rendering" spec [1], which views HTTP headers as the primary mean of transferring resource representations between a user-agent and an OCCI server. I can see how you you may have ended there (no need to define a media type, "universality" of the HTTP protocol, new RFC drafts about `Category` [4] and `Link` [5] headers popping up, etc.), but that just looks wrong to me for the following reasons:
* The most obvious, and a point that you raise in the spec [1], is that the HTTP header max size is often limited by intermediaries (for instance, default limit on Squid is 20KB [2]), while body max size is not. The spec warns:
"Space in the HTTP header section of a HTTP request is a limited resource. By this, it is noted that many HTTP servers limit the number of bytes that can be placed in the HTTP Header area. Implementers MUST be aware of this limitation in their own implementation and take appropriate measures so that truncation of header data does NOT occur."
You can't assume that there won't be intermediaries between the user-agent and the server (proxies, caches, etc.), therefore I don't see how an implementer can do anything about the header size limit, which means it is safe to assume that the HTTP Rendering via `text/occi` is broken (unless you have already thought about a possible solution, in which case it should be included in the spec). You can't even use the `Content-MD5` [3] header to provide an end-to-end message integrity check. And the message header is not compressible, contrary to the message body.
* More generally, methods and headers are there to indicate the purpose of a request, not the resource representation itself.
* Finally, you define a `text/occi` content-type, which looks like an empty shell. I mean, if I understand correctly, the only payload you'll ever have is "OK" on successful operations. AFAIK, a media type definition [6] is mainly about the structure and semantics of the message body. It's not about defining custom HTTP headers to replace the message body.
I also have some concerns about the filtering mechanism, linking mechanism and the way you define actions, but if I had to sum up my position it would be that I have the feeling that you went extreme with the REST concept, and tried to put in the spec as much novelty (in terms of recent HTTP-related specs/drafts) as you could. Nothing wrong with that, but the result is somewhat convoluted. Also, the decision to put everything in the header part of the message renders a lot of standard HTTP header fields useless.
I appreciate the effort and time it takes to build a spec like this. From a standardization body though, I would have expected that you properly define a new media type for the rendering, not custom header extensions. I recall a (now dead?) XHTML based rendering doc, which had some flaws but was going more in that direction. I can see that you plan on specifying new content types in the future: I think it would be good to shift the attention back to the body.
Thank you for your time. Best Regards,
Cyril -- http://crohr.me
[1] <http://ogf.org/documents/GFD.185.pdf> [2] < http://www.squid-cache.org/Versions/v2/2.6/cfgman/request_header_max_size.ht...
[3] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html> [4] <http://tools.ietf.org/html/draft-johnston-http-category-header-01> [5] <http://tools.ietf.org/rfc/rfc5988.txt> [6] <http://www.ietf.org/rfc/rfc1521.txt>
On 8 Jul 2011, at 18:03, Andy Edmonds wrote:
Hey Cyril, I saw some of your comments [1] [2] on twitter about OCCI. It'd be great if you could elaborate on them on the list as everyone here really values useful and constructive comments and critique.
BTW: you might have been viewing older OCCI specs. The latest published are here [3].
Cheers,
Andy andy.edmonds.be
[1] https://twitter.com/#!/crohr/status/89318560417067008 [2] https://twitter.com/#!/crohr/status/89320097755312128 [3] http://ogf.org/gf/docs/
participants (6)
-
alexander.papaspyrou＠tu-dortmund.de -
Andy Edmonds -
Cyril Rohr -
Gary Mazz -
Michael Behrens -
Thijs Metsch