Public comments are a very important part of the OGF document approval process. Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful. Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document. The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.
Thank you for making public comments on this document!
Comments for Document: Open Cloud Computing Interface - RESTful HTTP Rendering
| Author(s): | T. Metsch, A. Edmonds |
| Type: | P-REC |
| Area: | Infrastructure |
| Group: | OCCI-WG |
| Public Comment End: | 28 Mar, 2011 |
Comments:
Posted by: nyren 2011-02-02 03:22:15Additional (optional) filtering mechanism
Section 3.4.2 and 3.4.3 describe a filtering mechanism using category identifiers to limit the set of Entities returned by a GET request, either on an arbitrary path in the namespace or a location path of a specific Kind/Mixin.
I would like to see an additional filtering mechanism based on OCCI-attribute values. I.e. a combination of the Kind/Mixin category id which defines the attribute and a filter value for the attribute. E.g.:
GET /compute/ HTTP/1.0
Category: compute; scheme="..."
X-OCCI-Attribute: occi.compute.memory="2.0"
The necessary changes to the specification would be minimal.
With this addition it would be possible to implement user credentials as a Mixin. For example (using HTTP rendering syntax):
Category: owner; scheme=".../credentials#"; class="mixin";
attributes="occi.cred.user occi.cred.groups"
Then it would be possible to find all resource instances owned by user 'foo' through the following request:
GET / HTTP/1.0
Category: owner; scheme=".../credentials#"
X-OCCI-Attribute: occi.cred.user="foo"
I would like to see an additional filtering mechanism based on OCCI-attribute values. I.e. a combination of the Kind/Mixin category id which defines the attribute and a filter value for the attribute. E.g.:
GET /compute/ HTTP/1.0
Category: compute; scheme="..."
X-OCCI-Attribute: occi.compute.memory="2.0"
The necessary changes to the specification would be minimal.
With this addition it would be possible to implement user credentials as a Mixin. For example (using HTTP rendering syntax):
Category: owner; scheme=".../credentials#"; class="mixin";
attributes="occi.cred.user occi.cred.groups"
Then it would be possible to find all resource instances owned by user 'foo' through the following request:
GET / HTTP/1.0
Category: owner; scheme=".../credentials#"
X-OCCI-Attribute: occi.cred.user="foo"
Posted by: nyren 2011-02-02 09:38:47Only display mutable attributes in Query/Discovery Interface
The list of attribute names displayed for each Category in the query interface is used by clients to determine what attributes to submit when creating a new resource instance. Therefore it only makes sense to display _mutable_ attributes.
I propose to change the spec so that only mutable attributes are listed in the query interface.
Another solution would be to add some flagging system which tells whether an attribute is required and/or mutable but that would complicate the syntax.
/Ralf
I propose to change the spec so that only mutable attributes are listed in the query interface.
Another solution would be to add some flagging system which tells whether an attribute is required and/or mutable but that would complicate the syntax.
/Ralf
Posted by: AndyEdmonds 2011-02-02 11:50:42adoption of RFC5785
Advertise the query interface using the /.well-known mechanism as described in RFC5785 [1].
[1] http://tools.ietf.org/html/rfc5785
[1] http://tools.ietf.org/html/rfc5785
Posted by: AndyEdmonds 2011-03-10 11:47:21Rendering of OCCI Core attributes
For consistency OCCI Core attributes should be rendered with "occi.core." prepended. For example 'summary' would be rendered as 'occi.core.summary'.
Posted by: AndyEdmonds 2011-03-10 11:47:48IANA Registration
The content type 'text/occi' should be registered with the IANA registry
login
RSS