[occi-wg] Your Questions...

Cyril Rohr contact at crohr.me
Mon Jul 11 05:20:05 CDT 2011 

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

--
http://crohr.me



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20110711/c84a36f8/attachment.html

More information about the occi-wg mailing list