[occi-wg] Your Questions...

Tue Jul 12 14:02:07 CDT 2011

+1

On 7/12/2011 7:05 AM, alexander.papaspyrou at 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 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
>>
>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg

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