- occi-wg - lists.ogf.org

Fwd: [rest-discuss] hateoas - draft #1
by Sam Johnston 16 Oct '09

16 Oct '09

This thread on rest-discuss<http://tech.groups.yahoo.com/group/rest-discuss/>discusses the relationship between a *resource* and its *representations*. It's a core REST tenet and it's important that it's well understood: Modeled resources e.g. people, bank accounts, computers, etc. (generally) can't be transferred over HTTP. As such we rely on "representations" which convey information describing the resource - for a person it might be a photo, XML descriptor, rendering of a drivers license or other ID, fingerprints, DNA sequence, etc. - none of these are the actual person but they all describe some characteristic(s) of them. Updating the person's name by posting a representation of their drivers license should result in updates to the person's passport and XML descriptor. In relation to OCCI it may be possible to create a VM by PUTting an OVF file and it may also be possible to GET representations in other formats - e.g. Xen, Hyper-V, VMware. Just because you can render a representation doesn't guarantee that you can read it however so updates using an unsupported format should trigger a 415 Unsupported Media Type error. Sam ---------- Forwarded message ---------- From: Sam Johnston <samj(a)samj.net> Date: Fri, Oct 16, 2009 at 1:34 PM Subject: Re: [rest-discuss] hateoas - draft #1 To: Mike Kelly <mike(a)mykanjo.co.uk> Cc: Jan Algermissen <algermissen1971(a)mac.com>, Will Hartung < willh(a)mirthcorp.com>, "rest-discuss(a)yahoogroups.com List" < rest-discuss(a)yahoogroups.com> On Fri, Oct 16, 2009 at 1:05 PM, Mike Kelly <mike(a)mykanjo.co.uk> wrote: > > >> PUT /resource.xml > >> > >> what does that mean for > >> > >> /resource.json > >> /resource.atom > >> > >> .. How would intermediaries know that the state of the json and atom > >> resources (that are really just representations of the same > >> resource) have also changed? > > > > Well, if you PUT some XML to a resource and it response with 2xx then > > there will not be any json or atom anymore because you told the server > > to explicitly replace whatever state the resource has with the XML. > > I believe this to be a fundamental misinterpretation of what it means to > PUT a representation. The significance of the request is to update the > *resource* state by transfering an XML representation - this should not > cause other the other representations to cease to exist. That doesn't > make sense to me if they are simply representations of the resource that > has been updated - regardless of which specific representation caused > the update. > Exactly. As another example, if an OCCI <http://www.occi-wg.org/>implementation supports multiple formats for virtual machines (say, OVF, Xen and Hyper-V) then PUTting (or PATCHing<http://tools.ietf.org/html/draft-dusseault-http-patch>) any one of these formats will update the *resource* and with it all of its representations. If the support is export-only (that is, it is able to render the resource to it but not parse and update the resource from it) then such requests should be rejected with e.g. 415 Unsupported Media Type. Sam

1 0

Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
by Sam Johnston 16 Oct '09

16 Oct '09

Afternoon all, The HTTP PATCH verb is interesting in that it allows you to update a representation without having to transfer the entire thing. It's a space-time tradeoff in that it's a smaller transfer but you then have to generate and apply the patch, but for large/complex representations and remote (e.g. iPhone) users it could provide significant benefit. I wouldn't suggest that it be required at this time given lack of implementation (e.g. Apache) support but I've added a reference to it to OCCI as it will be useful for some applications and I'd rather provide the functionality than have people invent it. It's worth noting that PATCH first made an appearance (along with LINK and UNLINK) in the first HTTP RFCs but wasn't included in more recent releases due to lack of implementations. Sam ---------- Forwarded message ---------- From: Mark Nottingham <mnot(a)mnot.net> Date: Fri, Oct 16, 2009 at 1:48 AM Subject: Fwd: New Version Notification - draft-dusseault-http-patch-15.txt To: HTTP Working Group <ietf-http-wg(a)w3.org> > > New version (-15) has been submitted for draft-dusseault-http-patch-15.txt. > http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt > Sub state has been changed to AD Follow up from New Id Needed > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-15 > > IETF Secretariat. > -- Mark Nottingham http://www.mnot.net/

1 0

Re: [occi-wg] Reminder first OCCI session starts in 2 hours
by Adrian Cole 14 Oct '09

14 Oct '09

Here's a write-up on the second topic below: http://anyweight.blogspot.com/2009/10/rest-be-nice-no-entities-please.html Cheers, -Adrian On Tue, Oct 13, 2009 at 11:33 AM, Adrian Cole <adrian(a)jclouds.org> wrote: > I enjoyed the session and really like the idea of keeping domain-specific > data as-is. For example, using gets to obtain the native format of a > machine image for example. > > I think we have an ideal moment to consider again impact to tools and > production realities. I'll bring up two brief items to start the > conversation. > > 1. The open cloud tools manifesto blog logged a bunch of considerations > appropriate to review to ensure we make this as dev friendly as possible. > While I haven't the experience to do a line-by-line evaluation of OCCI to > it, here's the link where we can do that [1]. > > 2. In working with clouds, redirects due to resource moves, or normal > global concerns are a reality to be dealt with. Commands that use query or > matrix params are a bit easier to deal with because they are inherently > redirect friendly. We should avoid as much as possible using anything that > accidentally requires entities, as it short-circuits some http clients from > being able to transparently resolve redirects. > > I'm glad to have such a short list of concerns. Well done, all. > > Cheers, > -Adrian > founder jclouds > > [1] > http://www.1060.org/blogxter/entry?publicid=12CE2B62F71239349F3E9903EAE9D1F0 > > On Tue, Oct 13, 2009 at 6:33 AM, Sam Johnston <samj(a)samj.net> wrote: > >> Thanks Thijs. >> Corporate apartment has shared Internet so I'll send mine through >> shortishly and "see" you in a few hours. Looking forward to 100Mbit fiber in >> the new place next week :P >> >> Sam >> >> On Tue, Oct 13, 2009 at 3:04 PM, Thijs Metsch <Thijs.Metsch(a)sun.com>wrote: >> >>> >>> Hi guys, >>> >>> Attached are the slides for the sessions later on. You can dial-in using >>> the following conference bridge. Please go on mute when you are >>> connected :-) We have just on microphone and are connected through Skype >>> so the sound quality will probably not be the best :-) >>> >>> All the best, >>> >>> -Thijs >>> >>> >>> Passcode: >>> Participant: 9032568 >>> >>> >>> Dial in numbers: >>> >>> Country Toll Numbers >>> Freephone/Toll Free Number >>> >>> ARGENTINA >>> 0800-777-0463 >>> AUSTRALIA ADELAIDE: 61-8-8121-4868 >>> 1-800-249-288 >>> AUSTRALIA BRISBANE: 61-7-3102-0970 >>> 1-800-249-288 >>> AUSTRALIA CANBERRA: 61-2-6100-1970 >>> 1-800-249-288 >>> AUSTRALIA MELBOURNE: 61-3-9010-7739 >>> 1-800-249-288 >>> AUSTRALIA PERTH: 61-8-9467-5249 >>> 1-800-249-288 >>> AUSTRALIA SYDNEY: 61-2-8205-8125 >>> 1-800-249-288 >>> AUSTRIA 43-1-92-86-506 >>> 0800-005-029 >>> BELGIUM 32-1-150-0314 0800-4-8680 >>> BRAZIL >>> 0800-7610674 >>> CHILE >>> 1230-020-2867 >>> CHINA* 86-400-810-4766 >>> 10800-712-1433 >>> >>> 10800-120-1433 >>> COLOMBIA >>> 01800-9-156430 >>> CZECH REPUBLIC 420-2-25-98-56-54 800-700-173 >>> DENMARK 45-7014-0280 8088-6132 >>> ESTONIA >>> 800-011-1089 >>> FINLAND Land Line: 106-33-146 >>> 0-800-1-10100 >>> FINLAND Mobile: 09-106-33-146 >>> 0-800-1-10100 >>> FRANCE LYON: 33-4-26-69-12-81 >>> 080-563-9647 >>> FRANCE MARSEILLE: 33-4-86-06-00-81 >>> 080-563-9647 >>> FRANCE PARIS: 33-1-70-70-74-20 >>> 080-563-9647 >>> GERMANY 49-69-2222-2566 >>> 0800-000-3441 >>> GREECE 30-80-1-100-0683 >>> 00800-12-6973 >>> HONG KONG 852-2286-5731 800-930-705 >>> HUNGARY >>> 06-800-18013 >>> INDIA >>> 000-800-852-1266 >>> INDONESIA >>> 001-803-011-3787 >>> IRELAND 353-1-247-5253 >>> 1800-932-145 >>> ISRAEL >>> 1-80-9214916 >>> ITALY 39-02-3600-3642 800-986-570 >>> JAPAN OSAKA: 81-6-7739-4769 >>> 0034-800-400828 >>> JAPAN TOKYO: 81-3-5539-5189 >>> 0034-800-400828 >>> LATVIA 8000-3025 >>> LUXEMBOURG 352-27-000-1360 >>> MALAYSIA >>> 1-800-80-2812 >>> MEXICO >>> 001-866-627-0574 >>> NETHERLANDS 31-20-718-8533 >>> 0800-020-1392 >>> NEW ZEALAND 64-9-970-4769 >>> 0800-449-823 >>> NORWAY 47-21-59-00-59 800-15414 >>> PANAMA >>> 011-001-800-5072129 >>> PERU 0800-53733 >>> PHILIPPINES 63-2-858-3715 >>> POLAND >>> 00-800-1212021 >>> PORTUGAL 8008-14061 >>> RUSSIA >>> 8-10-8002-9683011 >>> SINGAPORE 65-6883-9228 >>> 800-120-4662 >>> SLOVAK REPUBLIC 421-2-322-422-21 >>> SOUTH AFRICA >>> 080-09-80416 >>> SOUTH KOREA 82-2-6744-1081 >>> 00798-14800-6860 >>> SPAIN 34-91-414-62-98 800-099-810 >>> SWEDEN 46-8-505-78-524 >>> 0200-890-106 >>> SWITZERLAND 41-44-580-4389 >>> 0800-001-523 >>> TAIWAN 886-2-2795-7377 >>> 00801-137-766 >>> THAILAND >>> 001-800-1206-65656 >>> UNITED KINGDOM BIRMINGHAM: 44-121-210-9021 >>> 0808-238-6025 >>> UNITED KINGDOM GLASGOW: 44-141-202-3221 >>> 0808-238-6025 >>> UNITED KINGDOM LEEDS: 44-113-301-2121 >>> 0808-238-6025 >>> UNITED KINGDOM LONDON: 44-20-7075-3246 >>> 0808-238-6025 >>> UNITED KINGDOM MANCHESTER: 44-161-601-1421 >>> 0808-238-6025 >>> URUGUAY >>> 000-413-598-3415 >>> USA 1-203-418-3122 >>> 866-692-3163 >>> VENEZUELA >>> 0800-1-00-3733 >>> >>> -- >>> Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) >>> http://blogs.sun.com/intheclouds >>> http://www.twitter.com/befreax >>> Software Engineer Cloud, Grid and Virtualization >>> Sun Microsystems GmbH >>> Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com >>> D-93049 Regensburg http://www.sun.com >>> >>> _______________________________________________ >>> occi-wg mailing list >>> occi-wg(a)ogf.org >>> http://www.ogf.org/mailman/listinfo/occi-wg >>> >>> >> >> _______________________________________________ >> occi-wg mailing list >> occi-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/occi-wg >> >> >

1 0

feedback from OGF
by Thijs Metsch 14 Oct '09

14 Oct '09

Hi, I just wanted to say thanks to all of you here. I got some great feedback on OCCI. Many positive; some related to question about our Roadmap; but not really any negative feedback. So thanks to you all for the work, and lets keep on rolling... -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

Sam Johnston - OCCI Presentation
by Sam Johnston 13 Oct '09

13 Oct '09

Starting now...

1 0

second session
by Thijs Metsch 13 Oct '09

13 Oct '09

Hi guys, sorry for the problems with the conference bridge. We will reconnect soon for the second session. So please stay tuned... Sorry for the inconvenience, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

Reminder first OCCI session starts in 2 hours
by Thijs Metsch 13 Oct '09

13 Oct '09

Hi guys, Attached are the slides for the sessions later on. You can dial-in using the following conference bridge. Please go on mute when you are connected :-) We have just on microphone and are connected through Skype so the sound quality will probably not be the best :-) All the best, -Thijs Passcode: Participant: 9032568 Dial in numbers: Country Toll Numbers Freephone/Toll Free Number ARGENTINA 0800-777-0463 AUSTRALIA ADELAIDE: 61-8-8121-4868 1-800-249-288 AUSTRALIA BRISBANE: 61-7-3102-0970 1-800-249-288 AUSTRALIA CANBERRA: 61-2-6100-1970 1-800-249-288 AUSTRALIA MELBOURNE: 61-3-9010-7739 1-800-249-288 AUSTRALIA PERTH: 61-8-9467-5249 1-800-249-288 AUSTRALIA SYDNEY: 61-2-8205-8125 1-800-249-288 AUSTRIA 43-1-92-86-506 0800-005-029 BELGIUM 32-1-150-0314 0800-4-8680 BRAZIL 0800-7610674 CHILE 1230-020-2867 CHINA* 86-400-810-4766 10800-712-1433 10800-120-1433 COLOMBIA 01800-9-156430 CZECH REPUBLIC 420-2-25-98-56-54 800-700-173 DENMARK 45-7014-0280 8088-6132 ESTONIA 800-011-1089 FINLAND Land Line: 106-33-146 0-800-1-10100 FINLAND Mobile: 09-106-33-146 0-800-1-10100 FRANCE LYON: 33-4-26-69-12-81 080-563-9647 FRANCE MARSEILLE: 33-4-86-06-00-81 080-563-9647 FRANCE PARIS: 33-1-70-70-74-20 080-563-9647 GERMANY 49-69-2222-2566 0800-000-3441 GREECE 30-80-1-100-0683 00800-12-6973 HONG KONG 852-2286-5731 800-930-705 HUNGARY 06-800-18013 INDIA 000-800-852-1266 INDONESIA 001-803-011-3787 IRELAND 353-1-247-5253 1800-932-145 ISRAEL 1-80-9214916 ITALY 39-02-3600-3642 800-986-570 JAPAN OSAKA: 81-6-7739-4769 0034-800-400828 JAPAN TOKYO: 81-3-5539-5189 0034-800-400828 LATVIA 8000-3025 LUXEMBOURG 352-27-000-1360 MALAYSIA 1-800-80-2812 MEXICO 001-866-627-0574 NETHERLANDS 31-20-718-8533 0800-020-1392 NEW ZEALAND 64-9-970-4769 0800-449-823 NORWAY 47-21-59-00-59 800-15414 PANAMA 011-001-800-5072129 PERU 0800-53733 PHILIPPINES 63-2-858-3715 POLAND 00-800-1212021 PORTUGAL 8008-14061 RUSSIA 8-10-8002-9683011 SINGAPORE 65-6883-9228 800-120-4662 SLOVAK REPUBLIC 421-2-322-422-21 SOUTH AFRICA 080-09-80416 SOUTH KOREA 82-2-6744-1081 00798-14800-6860 SPAIN 34-91-414-62-98 800-099-810 SWEDEN 46-8-505-78-524 0200-890-106 SWITZERLAND 41-44-580-4389 0800-001-523 TAIWAN 886-2-2795-7377 00801-137-766 THAILAND 001-800-1206-65656 UNITED KINGDOM BIRMINGHAM: 44-121-210-9021 0808-238-6025 UNITED KINGDOM GLASGOW: 44-141-202-3221 0808-238-6025 UNITED KINGDOM LEEDS: 44-113-301-2121 0808-238-6025 UNITED KINGDOM LONDON: 44-20-7075-3246 0808-238-6025 UNITED KINGDOM MANCHESTER: 44-161-601-1421 0808-238-6025 URUGUAY 000-413-598-3415 USA 1-203-418-3122 866-692-3163 VENEZUELA 0800-1-00-3733 -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

2 1

Save the dates: 2-3.12.2009 IGT2009 – The World Summit of Cloud Computing
by IGT 11 Oct '09

11 Oct '09

<http://www.grid.org.il/_pics/NewsLetterHeader.jpg> Save the dates: 2-3.12.2009 IGT2009 – The World Summit of Cloud Computing <http://events.myreg.co.il/IGT2009> <http://events.myreg.co.il/IGT2009/> <https://secure.mynetreg.com/UserFiles/Image/MSM/IGT/new11_10/banner%20g rid%20new.jpg> http://events.myreg.co.il/IGT2009 <http://events.myreg.co.il/IGT2009> ________________________________________________________________________ ______________________ Last year on Dec 2008, we had a very successful annual event, The World Summit of Cloud Computing with Key cloud leaders from Google, Salesforce, Amazon, eBay, yahoo, IBM, HP, SUN, MerrilLynch, Intel, etc. with more than 500 people: http://video.new-app.com/customers/grid/IGT2008/main.html <http://video.new-app.com/customers/grid/IGT2008/main.html> This year, IGT2009 will take place on Dec 2-3, 2009: http://events.myreg.co.il/IGT2009/ <http://events.myreg.co.il/IGT2009/> Twitter Updates http://twitter.com/IGTCloud <http://twitter.com/IGTCloud> See you at IGT2009! <http://www.grid.org.il/_uploads/imagesgallery/magnet2.png> מחק אותי מתפוצת אימייל זה <http://www.grid.org.il/?pg=subscr_un> | כניסה לאתר <http://www.grid.org.il>

1 0

Re: [occi-wg] Issue 13
by Michael Behrens 11 Oct '09

11 Oct '09

Will do. ---------------------------------------- From: Gary Mazz <garymazzaferro(a)gmail.com> Sent: Saturday, October 10, 2009 1:35 AM To: Michael Behrens <michael.behrens(a)r2ad.com> Subject: Re: [occi-wg] Issue 13 Hi Michael, Can you put item 13 in a deferred (if that's possible) ? I would like to revisit this issue in the next draft. -g Michael Behrens wrote: > I'm fine with closing issue 13 then. I think the material is covered > in 2.2 Getting Started and in table 4. > It may be good to replace /compute/123 in other parts of the > specification with /node123 to avoid confusion. > Thanks. > > Gary Mazz wrote: >> Sam, >> >> Are you saying you are changing the concepts of buckets ? for an >> ambiguous URL path ? where the management of the path is out of >> scope and control of occi api ? . So in the case of this >> configuration from the same provider: >> http://node01/web01: OCCI-STUFF >> http://node03/web02 : OCCI-STUFF >> http://node04/web03 : OCCI-STUFF >> http://node02/web04 : OCCI-STUFF >> >> We do not have a way of aggregating those "nodes" in the occi >> interface. The reason for the buckets following the domain name and >> socket number was to eliminate the requirement for this type of >> additional management complexity, at least for the first draft of the >> occi spec. I was an advocate of a more flexible scheme from the >> beginning, I'm not sure if its wise to change this without a >> management api. >> >> -gary >> >> Sam Johnston wrote: >>> Ok so to further explain this requirement, early versions of the >>> spec talked about dumping similar resources into buckets or >>> "collections" - e.g. /compute, /storage, /network. The problem is >>> that the web today doesn't tell you that images need to live in >>> /images (even if they often do). Once you add the type of resource >>> to its metadata you no longer need to encode it into the URL (which >>> is fugly btw, and not particularly RESTful) and the result is that >>> users have much more freedom as to how they lay out their resources. >>> >>> Unfortunately many APIs restrict you to certain (generally legacy) >>> terminology like "virtual data centers" and "virtual racks" which is >>> something I very much wanted to avoid - even if only to be able to >>> cater for the various perspectives on this issue rather than >>> (unsuccessfully) trying to force our view down everyone's throats. >>> >>> That is to say that said URLs are informative rather than normative, >>> and perhaps even belong in the walkthrough. I was thinking more >>> along the lines of: >>> >>> http://cloud.example.com/us-east/webapp/web02 >>> >>> For a burnt-in hypervisor this might be simply: >>> >>> http://node01/web01 >>> >>> Sam >>> >>> On Fri, Oct 9, 2009 at 5:33 AM, Michael Behrens >>> > wrote: >>> >>> For paragraph 2.2 Basics, under the URL Namespace paragraph, is >>> this the sort of >>> table desired/accurate? >>> >>> The following table is a list of recommended URLs and their >>> purpose: >>> http://example.com/ >>> Define and >>> configure machines >>> http://example.com/myresource/network Network configuration >>> http://example.com/myresource/storage Storage services (SANs, >>> etc) >>> http://example.com/myresource/application Application control >>> >>> -- Michael Behrens >>> >>> >>> >>> _______________________________________________ >>> occi-wg mailing list >>> occi-wg(a)ogf.org >>> http://www.ogf.org/mailman/listinfo/occi-wg >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> occi-wg mailing list >>> occi-wg(a)ogf.org >>> http://www.ogf.org/mailman/listinfo/occi-wg >> >> > >

1 0

Consolidated list of editorial changes from issues list
by Gary Mazz 10 Oct '09

10 Oct '09

Hi, This is a consolidated list of editorial changes originated in the 0cci issues list found on http://code.google.com/p/occi/issues/list This list is to act as a guide for occi-wg editors writing the occi specification. This list attempts to place the recommendations in sequence in the document. cheers, gary ================================================================================ Section: Overall ***Comment:* - move table of contents after abstract - use MUST, SHOULD, MAY, CAN... should be uppercase - "Each implementation has a single OCCI end-point URL" should be 'each deployment' or 'each service'? - TIP, WARNING: are they normative? Like, the tip after Par. 54 contains a SHOULD. But I am asking about tips in general, not about this particular one. - "A simple peer review process is available for extending the registries" That process is not described, not referenced. - "This scalable approach..." not relevant, really - can go into footnote Section: Document-wide 1. The character set use in communications should be specified 2. Header Capitalisation of "OCCI working group" -> "OCCI Working Group" 4. Lacking/Inconsistent normatives throughout 5. What is the minimum set of requirements/features (a profile) that needs to be implemented so that one is OCCI compliant? 6. Format of references - should be enclosed by '[' and ']' e.g. [REF22 <http://code.google.com/p/occi/source/detail?r=EF22>] 7. Use appropriate page breaks 8. Revise use of round bracketing 9. Ensure consistency of dot or dash attribute notation in all examples 10. There is no consideration in the spec for the states that a resource can have 11. All extensions should be placed and grouped under a Section named "Extensions" 12. Aspects of security are dealt with in 3.3.1 and 3.7. It would be better for these to be placed together for context and ease of reading. 13. For numerical attributes it might be useful to state their numerical base e.g. if these should be Base-2 or Base-10. 14. Would be useful to introduce the notion of OCCI extensions in the walk through. ==================================================================================== Section: abstract *Paragraph:* Comment: first sentence should move to --> status; 'note' in walkthrough is misleading... ===================================================================================== Section: OCCI Core Pages: 5-14 41. P13 "Collection" link relation 1. Is a self-referiental reference appropriate? 1. Paragraph 26 "A "Resource Oriented Architecture (ROA)"" * Supply reference 2. P26 "Each resource (identified by a canonical URL)" 1. Bracket usage - suggestion "Each resource, identified by a canonical URL, 3. P26 "has zero or more representations" 1. If a resource has no representation then to all intents it does not exist within the system. Suggest "1 or more" 4. P26 "Metadata including associations between resources is exposed via HTTP headers (e.g. the Link: header), except in the case of collections where Atom is used as the meta- model." 1. Which is normative? Are there other ways? 5. P26 Comment 1. Is the supplied tip of relevance in the context? If so give an example to explain. 6. P27 "The interface" 1. What interface? Also the interface is defined in _part_ by the URL - consider rephrasing this paragraph 7. P27 "in-band/out-of-band" 1. Easier to supply a definition of this here and then later in the doc refer to the definition in glossary. Better way to introduce the concept to "newbies". 8. P28 "HATEOAS" 1. Expand the acronynm 9. P29 "WebDAV definitions are used for MOVE and COPY" 1. COPY is a valid operation on the external interface of an infrastructure provider. MOVE however is not and something that might be implemented optionally. Suggest to have MOVE as an extension and not part of core. Motivation not obvious to have in core. 10. P29 Comment 1. I can PUT to create and POST to update - would be worth explaining which to use (normative) 11. P29 "DELETE" - "and everything "under" it" 1. Better worded as "and all it's child resources" Lars pointed this out also 12. Section 3.3.1 Authentication 1. Needs to be extensible and adaptable - might consider it part of OCCI extensions also? E.g. SAML support 13. P33 Comment 1. An example should be given 14. P34 Comment 1. Ever seen a working model that did not include links between entities? 15. P34 "without regard to how they interrelate." 1. Surely this should be "with regard to how they interrelate." Both meta-model and model define links in general 16. P34 "the objects" 1. change to "infrastructure resources (objects)" 17. P36 "http://purl.org/occi/kind/ namespace" 1. Who controls this? 18. P36 Comment - "Warning" 1. These are repeated through out - rather than warn, insert a section on how to extend the specification including a note on this warning, how the peer process works etc. Then refer to the section from various parts of the doc 19. P37 "Internet media types" 1. Better to call this "Internet MIME types"? 20. P39 "dash character (“-”)" 1. Why the dash over the dot? Where's the motivation, reason is a little unclear. If all representations are UTF8 compliant then should this matter? 21. P40 Warning is repeated 1. Repeated: Use a dedicated section on extending OCCI and ref to it 22. Table 1 "Common Attributes" 1. "OCCI-Updated" - is the HTTP "Last-Modified" header sufficient? 2. Normative - are all these to be supported? 23. P43 Comment 1. It is noted that a list of actions are available - where? There's none in the spec doc 24. P34 Warning 1. Repeated: Use a dedicated section on extending OCCI and ref to it 25. P44 "An action is triggered via an HTTP POST" 1. Normative and possibly give the reason as to why POST is used. 26. P46 Tip 1. Usefulness of this in the context? 27. P47 Tip 1. Usefulness of this in the context? 28. P48 "The meta-model defines how objects interrelate." 1. Not a normative definition. Some include: http://bit.ly/gwCA5 Consider revising. 29. Section 3.5.1 1. What happened to the useful OCCI-text examples of categories? 30. P51 Tip 1. More than just a tip. This is a feature (tagging via categories) that Atom gives for free. Suggest making it a paragraph. 32. P53 Tip "O(n+1)" 1. Should this not be O(n^2)? - for every resource rendering (1 operation) there is the rendering of its details (1 operation). Therefore in a list of 4 resources we have to perform a constant 2 operations per resource, hence n^2 operations. 33. P55 Comment on examples 1. Should the example show the encoded ';' character? 34. Section 3.5.3 1. What happened to the useful OCCI-text examples of linking? 35. Table 2 1. What are the normative? 2. "help" - appropriate and useful in core section? 3. "icon" - appropriate and useful in core section? 36. P58 "public peer review" 1. Point to an extension section detailing this process 37. Section 3.6.1 Comment 1. Explain what "foreign markup" is 38. P59 Comment 1. Example needed 39. Section 3.8 "Registration" Comment 1. Place in an appendix Page 10, paragraph 52 "Where an operation returns multiple resources ..." to be replaced with "Where an operation COULD return multiple resources..." to make it clear that a collection is always returned, even if there is a single result. ========================================================================================== Infrastructure: 1. Table 3 1. Suggest to move it after introducing kinds - better logical flow 2. P77 "Cloud infrastructure can be modeled using three primary kinds: compute, network and storage." 1. Rephrase to: "Cloud infrastructure can be modeled using the following three primary kinds:" 3. Table 4 "Recorded information resources" 1. reword to "Information recording resources" 4. Table 5 1. Suggest to include boot volume attribute (Richard) 2. "Enum (standard, checksum)" -> "Enum (none, checksum)" 3. How to extend enumerations? Should we just use text field instead? 5. Section 8.1.2 Comment 1. These are mostly network client attributes. Are they sufficient to model a pool of static IPs? 6. Table 6 1. OCCI-Network-Address - unclear description - is it a gateway IP or node IP address? 2. OCCI-Network-Allocation - how is manual allocation performed, by who? 1. Section 9 1. What is the relevance of the date? 2. P83 OpenSearch 1. Give example for context/relevance 4. Section 10 "OCCI Status Extension" 1. Better named as "OCCI Task Reporting", especially as there's the "OCCI Tasks Extension"? 2. Isn't this extension just a specialisation of Monitoring (Lars noted this too) and should be reflected as such? 3. Very much related to the "OCCI Task Extension" - is it better combined? 4. An example of the extensions usage would be helpful 5. Table 8 1. Uses dot notation for attribute naming - consistency 7. Section 11 1. What is the relevance of the date? 2. An example of the extensions usage would be helpful 8. Table 9 1. Uses dot notation for attribute naming - consistency 10. Section 12 "OCCI Registries" 1. What are the normative HTTP status codes? 11. Table 11 1. We should also mention mailing list contributors as this IS a community effort and not just that of a few. ============================================================================== 7. Bibliography 1. Move to a dedicated section at the end of the whole document 40. Page 13 Bibliography 1. Move to a dedicated section at the end of the whole document 3. Section 9 Bibliography 1. Move to a dedicated section at the end of the whole document 2. What is the relevance of the date? 6. Section 10 Bibliography 1. Move to a dedicated section at the end of the whole document 9. Section 11 Bibliography 1. Move to a dedicated section at the end of the whole document

5 10