October 2009 - occi-wg - lists.ogf.org

Weekly conf call: consensus on the formats issue
by Sam Johnston 29 Oct '09

29 Oct '09

Afternoon all, Though the main call was shorter than usual yesterday afternoon, Gary, Shlomo, Andre and myself pressed on for 3 hours to see if consensus could be found (again) on the formats issue. This is clearly something people feel strongly about so it's unsurprising that it's taken us this long to get this far, but I think we've finally found a happy medium (touch wood). Here's my take (3 hours condensed into 3 lines): - Our number one priority is machines (rather than users) so we want native representations defined by existing standards (e.g. OVF) over home-grown (POX) and/or human-friendly ([X]HTML) representations. - Resources are "enhanced" by metadata which consists of links to other resources, categories, attributes, etc. and HTTP provides a perfectly good metadata channel in the form of HTTP headers so we'll use these to expose this information. - We'll also define a single, XHTML5 based representation that is usable by both users and machines. All of the information that appears in the headers will also appear within the XHTML5 rendering such that "enterprise applications" can extract it with XPath/XSLT/etc. without having to look at the headers. I'm very happy with this compromise, which basically involved elevating both existing documents to the "must" requirement level. The load for implementors is minimised and both simple and complex clients are supported. Furthermore it does not restrict the roadmap and enables us to trivially add support for semantic web technologies including microformats and RDFa which I know will make some people on this list very happy. Thanks everyone for your perseverance with this issue. Please speak now if there's any comments, questions or concerns about this (or forever hold your peace :) Sam

2 1

Fwd: OCCI JavaScript libarary
by Sam Johnston 29 Oct '09

29 Oct '09

Putting this thread back on the list - see some interesting suggestions from Andrew below: ---------- Forwarded message ---------- From: Andrew de Andrade <andrew(a)deandrade.com.br> Date: Mon, Oct 26, 2009 at 2:33 PM Subject: Re: [occi-wg] OCCI JavaScript libarary To: Sam Johnston <samj(a)samj.net> ahh, doh! go ahead. i'm working at home today and I'm using gmail and i forgot to do reply all. On Mon, Oct 26, 2009 at 11:24 AM, Sam Johnston <samj(a)samj.net> wrote: > Andrew, > Great suggestion - do you have a problem with my putting this back on the > list? > Sam > > On Mon, Oct 26, 2009 at 2:13 PM, Andrew de Andrade < andrew(a)deandrade.com.br> > wrote: >> >> true. >> >> There's a bunch of open source management consoles that it may be >> worth reaching out to in order tog et them on board if they aren't >> already: >> >> http://www.openqrm.com/ >> http://virt-manager.et.redhat.com/ >> http://ovirt.org/ >> >> there was a fourth I knew of, but I can't remember the name of it at the >> moment. >> >> Projects such as Puppet could also be included. >> >> Andrew >> >> On Mon, Oct 26, 2009 at 10:24 AM, Sam Johnston <samj(a)samj.net> wrote: >> > On Mon, Oct 26, 2009 at 1:14 PM, Andrew de Andrade >> > <andrew(a)deandrade.com.br> >> > wrote: >> >> >> >> I wouldn't too much about standardizing user experience interfaces. If >> >> a standard API interface is created, an open source interface that >> >> works with any standard API cloud is sure to come about. >> > >> > True - it's not even so much about standardising the interface as >> > lowering >> > the barrier to entry. If you can "explore" it as a developer or power >> > user >> > via a web browser and then it behaves the same way for your code (same >> > URLs, >> > relationships, etc. - just different as in native renderings) that's a >> > big >> > win for lowering the barrier to entry. >> > It's also one less thing for providers to build separately, and means >> > that >> > web consoles will have both the freedom to innovate/differentiate while >> > also >> > looking & feeling somewhat similar. Currently there's a mishmash of >> > flash, >> > ajax & html consoles that present a [human] barrier to migration. >> > I agree that this should be a distant second priority, but if we can >> > have it >> > for free then we may as well (and it ought to keep the XML camp happy >> > too). >> > Sam >> > > >

4 8

please read: OCCI F2F meeting
by Thijs Metsch 29 Oct '09

29 Oct '09

Hi, I'm very happy to announce our first OCCI hands-on meeting. We (the chairs) picked November 20, 2009 for our first OCCI F2F meeting. If a lot of people cannot make it: the backup date is December 4, 2009. Although we would prefer Nov. 20 over Dec. 4. This meeting will take place in Amsterdam, Netherlands. I will send around details soon. Assuming that the F2F meeting will be a full-day meeting (9am till 5pm) we could do the following during the day: 1 get together 2 hands-on working session for the OCCI specification 3 open discussions/issues walktrough 4 format/rendering discussions Goal is to get the Specification ready and to reach consensus on the the rendering/format. We will provide a dial-in for the afternoon part (3&4). Also feel free to suggest more agenda topics! Thanks to Thilo Kielmann from UvA and Andre Merzky who are helping organizing this. All the best, -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

4 6

Terminology: containers, workloads, templates and instances
by Sam Johnston 29 Oct '09

29 Oct '09

Evening all, I've attached some notes Andy took from a call at the weekend as well as a diagram I whipped up today which I hope will help us to use common terminology and avoid the ambiguous term "virtual machine" (which can refer both to the host and the guest, or both together - as distinct from what we mean when we say "java virtual machine"). The proposed terminology is also generic and thus compatible with any work we do in the future at the platform and/or application layers (as deployed applications look just like virtual machines in that they can be started, stopped, etc.). - *Container* refers to the host of an individual workload (e.g. an empty virtual machine [host], runtime, interpreter, etc.) - *Workload* refers to a generic load that the user wishes to execute in the cloud (e.g. virtual machine files [guest], RoR app, JAR/WAR, etc.) - *Template* refers to a COPYable workload that cannot be run (e.g. a public AMI) - *Instance* refers to a workload that is currently allocated and consuming resources (e.g. a running or suspended virtual machine) Some of you may recall similar terminology back when we were writing the charter but our model ended up going in a different direction. The reason it's come back up now is that we're getting down to the details (like running instances vs the [possibly immutable] template from which they were started) and not using common language causes confusion from time to time. In terms of how we model these things for cloud infrastructure: - *Containers* are like reservations (though the resources may or may not be actually reserved). If you create a blank server in VMware vCloud express for example there's an entity that you will be billed for regardless of whether you start it or even point it at an image. Similarly you can pay Amazon for a "reserved instance" and then get cheaper hourly rates for it. Think of it like a virtual dedicated server. These can be modeled via "empty" compute resources - that is, ones which have metadata such as allocated cores and memory, but no entity-body (e.g. OVF payload). - *Workloads* are whatever the user wants to run in your cloud. This could be anything from a script to a complex, multi-VM OVF file ("vApp" in VMware parlance). These are generally referred to as templates or instances: - *Templates* are resources that cannot be directly started (e.g. don't advertise start, stop, restart, etc. actions), rather needing a COPY to a new location as an "instance" first. Rather than having to reverse engineer the available actions these are identified by a predetermined "template" category. - *Instances* are resources that are allocated (e.g. can be started, stopped, restarted, etc.). These are the default and can be identified by the presence of an entity-body (e.g. OVF payload) and absence of the "template" category. We discussed this on the call today and it wasn't contentious but if you have feedback then fire away, Sam

2 2

HTML5 at Last Call (and what this has to do with OCCI)
by Sam Johnston 28 Oct '09

28 Oct '09

Morning all, Many of you will have seen that HTML 5 is now in Last Call (at least at the WHATWG, who work with the W3C on different issues). This is great news as it's one of the specifications we reference at a number of points and it is currently my proposal for the user interface component (e.g. users can point their browsers directly at the API and get a web console). Here's a quick history lesson on HTML from my perspective (I'm one of a bunch of [self-]invited experts @ W3C but have been more focused here than there): - Once upon a time there was HTML4 and a bunch of browsers implemented it reasonably well for quite a few years - HTML looks like XML, but it's not always/usually/ever compliant (which is OK because the browsers aren't fussy, accept pretty much anything and each make sense of it in different, weird and wonderful ways) - XHTML on the other hand *is* XML and depending on the mime-type, browser and direction of the wind will be parsed as such (or not!). - XHTML 2.0 was a wander off into the wilderness, shedding backwards compatibility and with it any chance of seeing daylight (it was recently taken out the back and shot by W3C after a few years withering away) - HTML5 is the next major release of HTML which introduces a bunch of interesting & useful features that push the boundaries even further, while remaining largely backwards compatible. - XHTML5 is pretty much just a strict XML rendering of HTML5. That is, HTML4 ~= XHTML1, XHTML2 is dead and HTML5 ~= XHTML5. IMO (can't be too careful these days). Remember XHTML is valid XML so it's a suitable candidate for APIs and indeed the demonstration API in the RESTful Web Services book uses it exclusively: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>Planet List</title> </head> <body> <ul class="planets"> <li><a href="/Earth">Earth</a></li> <li><a href="/Venus">Venus</a></li> ... </ul> </body> </html> Once you've parsed it you can easily extract the planet names with an expression like ul[class="planets"]/li/a/text() (granted XPath is not my area of expertise and there's a bunch of other ways to do it). Anyway the point is that this single (currently optional) rendering can be used for both humans and machines if we want. While I am reasonably convinced that we want users to be able to access the API directly (it doesn't cost us anything to give implementors the option) I'm still not sold on the case for an XML rendering, especially when headers are better/faster/cheaper and require basically no parsing. Anyway it's 4am already so I'll leave it at that for today... Sam HTML5 at Last Call October 27th, 2009 by Ian Hickson <http://ln.hixie.ch/> For a brief period today, there were no outstanding e-mails or bugs on the specs, and so I took that opportunity to transition us here at the WHATWG to the next stage of HTML5's development: Last Call! This affects three specs at the WHATWG: - HTML5 <http://www.whatwg.org/specs/web-apps/current-work/multipage/> - Web Workers <http://www.whatwg.org/specs/web-workers/current-work/> - Microdata vocabularies<http://www.whatwg.org/specs/vocabs/current-work/> There's also a version of the spec called Web Applications 1.0<http://www.whatwg.org/specs/web-apps/current-work/complete.html> (for nostalgic reasons) that has all of the above as well as a number of other specs, namely Web Storage, Web Database, Server-sent Events, and the Web Sockets API and protocol, all together in one document. With the exception of the Web Database spec, they're all now in last call at the WHATWG. So if you've been waiting to see if someone else would report the problem that you had seen, well, if it's not fixed, they didn't! So you should now send that feedback in yourself. There's two ways to send feedback. If your feedback is something short and simple, you can just load up the spec in your browser, click on the section with the problem, then type in your message using the review comments box that appears at the bottom of the window, and hit the "Submit Review Comments" button. This works for the HTML5 and Web Applications 1.0 specs. (Thanks to the W3C HTML Working Group for making their bug database available to us for this purpose.) If your feedback is more elaborate, then you should subscribe to the mailing list <http://www.whatwg.org/mailing-list#specs>and then send your feedback there. *Note: Lest there be any confusion, the W3C HTML WG has not yet transitioned HTML5 to Last Call at the W3C. HTML5 is a joint effort of W3C and WHATWG groups, but we have different issues lists and different criteria for going to Last Call. For more details on the W3C HTML WG's processes, see the W3C HTML WG charter <http://www.w3.org/2007/03/HTML-WG-charter.html>.*

2 1

Reminder: concall today: 4pm CET,
by Thijs Metsch 28 Oct '09

28 Oct '09

Hi, Today's concall will be at 4pm CET (Berlin). Be careful: Europe changed back to winter time so the times in other timezones may vary since e.g. the US did not change... So please have a look here: http://www.timeanddate.com/worldclock/meetingtime.html?month=10&day=28&year… The agenda will be something like: - current status discussion - open issues We (the chairs) are currently working on organizing a F2F - I hope I can give you some more details during the concall. Hope the hear from all of you soon, -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

Fwd: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to Proposed Standard
by Sam Johnston 27 Oct '09

27 Oct '09

The HTTP PATCH method (recall earlier discussion about REST "shortcuts") is finally proceeding towards standard status. This is interesting for OCCI as well as any other application that needs to update server-side resources but doesn't want to send the whole entity every time. Implementations can use their preferred diff mechanism (as identified by Internet media type) - from plain diff for text files to XML diffs for XML, XDelta for binaries, etc. Sam (who's hanging out for rsync-over-HTTP!) ---------- Forwarded message ---------- From: Julian Reschke <julian.reschke(a)gmx.de> Date: Tue, Oct 27, 2009 at 6:09 PM Subject: Re: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to Proposed Standard To: WebDAV <w3c-dist-auth(a)w3.org>, HTTP Working Group <ietf-http-wg(a)w3.org> (FYI) The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > > - 'PATCH Method for HTTP ' > <draft-dusseault-http-patch-15.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf(a)ietf.org mailing lists by 2009-11-24. Exceptionally, comments may be > sent to iesg(a)ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=111… > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce(a)ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > >

1 0

What Language Does the Cloud Speak, Now and In the Future?
by Sam Johnston 27 Oct '09

27 Oct '09

Thanks Shlomo for this<http://clouddevelopertips.blogspot.com/2009/10/what-language-does-cloud-spe…>great review of communicating in the cloud. I particularly like the quadrants (and not just because OCCI's alone in the top right corner). It makes a clear separation between APIs and protocols which is something we need to do a lot more of. What is increasingly clear to me is that while HTTP was the lingua franca of the Internet, an evolution of it will be the lingua franca of the cloud. That is, whoever deviates the least from HTTP while still delivering the additional functionality we require for organising resources (e.g. linking, categorising, animating, annotating, etc.) will "win" the standards war/race/game/etc. because it will be most accessible by developers and users alike. That's why I love hearing feedback like "the [OCCI] spec<http://code.google.com/p/occi/source/browse/#hg/docs>is extremely straightforward and intuitive for anyone familiar with the usual HTTP verbs" - as we did from the CTO of a popular Web 2.0 startup this week. It's also great to see other initiatives validating our approach by adopting similar technology (e.g. VMware vCloud<http://www.vmware.com/go/vcloudapi>'s use of link relations<http://tools.ietf.org/html/draft-nottingham-http-link-header> ). Sam P.S. Apologies to those of you on both lists for the cross-post... I figured this was relevant for both audiences. If you're not you can join the CCIF and OCCI lists here <http://groups.google.com/group/cloudforum> and here<http://www.ogf.org/mailman/listinfo/occi-wg>respectively. What Language Does the Cloud Speak, Now and In the Future?<http://clouddevelopertips.blogspot.com/2009/10/what-language-does-cloud-spe…> You're a developer writing applications that use the cloud. Your code manipulates cloud resources, creating and destroying VMs, defining storage and networking, and gluing these resources together to create the infrastructure upon which your application runs. You use an API to perform these cloud operations - and this API is specific to the programming language and to the cloud provider you're using: for example, for Java EC2 applications you'd use typica <http://code.google.com/p/typica/>, for Python EC2 applications you'd use boto <http://code.google.com/p/boto/>, etc. But what's happening under the hood, when you call these APIs? How do these libraries communicate with the cloud? What language does the cloud speak? I'll explore this question for today's cloud, and touch upon what the future holds for cloud APIs. Java? Python? Perl? PHP? Ruby? .NET? It's tempting to say that the cloud speaks the same programming language whose API you're using. Don't be fooled: it doesn't. "Wait," you say. "All these languages have Remote Procedure Call (RPC) mechanisms. Doesn't the cloud use them?" No. The reason why RPCs are not provided for every language is simple: would you want to support a product that needed to understand the RPC mechanism of many languages? Would you want to add support for another RPC mechanism as a new language becomes popular? No? Neither do cloud providers. So they use HTTP. HTTP: It's a Protocol The cloud speaks HTTP. HTTP is a protocol<http://www.blogger.com/HTTP%20is%20a%20protocol:%20it%20prescribes%20a%20sp….>: it prescribes a specific on-the-wire representation for the traffic. Commands are sent to the cloud and results returned using the internet's most ubiquitous protocol, spoken by every browser and web server, routable by all routers, bridgeable by all bridges, and securable by any number of different methods (HTTP + SSL/TLS being the most popular, a.k.a. HTTPS). RPC mechanisms cannot provide all these benefits. Cloud APIs all use HTTP under the hood. EC2 actually has two different ways of using HTTP: the SOAP API and the Query API. SOAP uses XML wrappers in the body of the HTTP request and response. The Query API places all the parameters into the URL itself and returns the raw XML in the response. So, the lingua franca of the cloud is HTTP. But EC2's use of HTTP to transport the SOAP API and the Query API is not the only way to use HTTP. HTTP: It's an API HTTP itself can be used as a rudimentary API<http://en.wikipedia.org/wiki/Application_programming_interface>. HTTP has methods (GET, PUT, POST, DELETE) and return codes and conventions for passing arguments to the invoked method. While SOAP wraps method calls in XML, and Query APIs wrap method calls in the URL (e.g. http://ec2.amazonaws.com/?Action=DescribeRegions) HTTP itself can be used to encode those same operations. For example: GET /regions HTTP/1.1 Host: cloud.example.com Accept: */* That's a (theoretical) way to use raw HTTP to request the regions available from a cloud located at cloud.example.com. It's about a simple as you can get for an on-the-wire representation of the API call. Using raw HTTP methods we can model a simple API as follows: - HTTP GET is used as a "getter" method. - HTTP PUT and POST are used as "setter" or "constructor" methods. - HTTP DELETE is used to delete resources. All CRUD <http://en.wikipedia.org/wiki/Create,_read,_update_and_delete> operations can be modeled in this manner. This technique of using HTTP to model a higher-level API is called Representational State Transfer<http://en.wikipedia.org/wiki/Representational_State_Transfer>, or REST. RESTful APIs are mapped to the HTTP verbs and are very lightweight. They can be used directly by any language (OK, any language that supports HTTP - which is every useful language) and also by browsers directly. RESTful APIs are "close to the metal" - they do not require a higher-level object model in order to be usable by servers or clients, because bare HTTP constructs are used. Unfortunately, EC2's APIs are not RESTful. Amazon was the undisputed leader in bringing cloud to the masses, and its cloud API was built before RESTful principles were popular and well understood. Why Should the Cloud Speak RESTful HTTP? Many benefits can be gained by having the cloud speak RESTful HTTP. For example: - The cloud can be operated directly from the command-line, using curl, without any language libraries needed. - Operations require less parsing and higher-level modeling because they are represented close to the "native" HTTP layer. - Cache control, hashing and conditional retrieval, alternate representations of the same resource, etc., can be easily provided via the usual HTTP headers. No special coding is required. - Anything that can run a web server can be a cloud. Your embedded device can easily advertise itself as a cloud and make its processing power available for use via a lightweight HTTP server. All these benefits are important enough to be provided by any cloud API standard. Where are Cloud API Standards Headed? There are many cloud API standardization efforts. Some groups are creating open standards, involving all industry stakeholders and allowing you (the developer) to use them or implement them without fear of infringing on any IP. Some of them are not open, where those guarantees cannot be made. Some are language-specific APIs, and others are HTTP-based APIs (RESTful or not). The following are some popular cloud APIs: jClouds <http://code.google.com/p/jclouds/> libcloud <http://libcloud.org/> Cloud::Infrastructure <http://www.cloud-framework.org/> Zend Simple Cloud API <http://www.simplecloud.org/> Dasein Cloud API <http://dasein-cloud.sourceforge.net/> Open Cloud Computing Interface (OCCI) <http://www.occi-wg.org/doku.php> Microsoft Azure <http://www.microsoft.com/windowsazure/> Amazon EC2 <http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/> VMware vCloud <http://www.vmware.com/go/vcloudapi> deltacloud <http://deltacloud.org/> Here's how the above products (APIs) compare, based on these criteria: Open: The specification is available for anyone to implement without licensing IP, and the API was designed in a process open to the public. Proprietary: The specification is either IP encumbered or the specification was developed without the free involvement of all ecosystem participants (providers, ISVs, SIs, developers, end-users). API: The standard defines an API requiring a programming language to operate. Protocol: The standard defines a protocol - HTTP. <http://3.bp.blogspot.com/_waT4NVCQkNE/SuOns6bqSYI/AAAAAAAAAEo/63fuz3GojlE/s…> This chart shows the following: - There are many language-specific APIs, most open-source. - Proprietary standards are the dominant players in the marketplace today. - OCCI is the only completely open standard defining a protocol. - Deltacloud was begun by RedHat and is currently open, but its initial development was closed and did not involve players from across the ecosystem (hence its location on the border between Open and Proprietary). What Does This Mean for the Cloud Developer? The future of the cloud will have a single protocol that can be used to operate multiple providers. Libraries will still exist for every language, and they will be able to control any standards-compliant cloud. In this world, a RESTful API based on HTTP is a highly attractive option. I highly recommend taking a look at the work being done in OCCI<http://www.occi-wg.org/doku.php>, an open standard that reflects the needs of the entire ecosystem. It'll be in your future.

2 1

Horizontal & vertical scalability in the cloud
by Sam Johnston 26 Oct '09

26 Oct '09

Morning all, So I'm looking at how best to handle horizontal & vertical scalability following an hour or two on the phone with Andy earlier which got me thinking. Currently scaling in services like Amazon EC2 involves having a service like RightScale monitor your application (e.g. response time, load average, etc.) and start new instances when (or ideally before) the figures reach unacceptable levels, track them while they're running, and kill them off again when the load returns to the baseline. This is pretty inefficient because each instance is its own first-class citizen and there is no connection between them (aside from the fact that they were started from the same image) - you have to handle them individually which in itself generates flurries of unnecessary API calls. A better approach to scalability is to have a single object which you can both adjust the resources of (vertical scalability) and adjust the number of instances of (horizontal scalability). That is, you start a single instance with 1 core and 1Gb, then while it's running you crank it up to 2 cores and 2Gb. Eventually you max out at say 8 cores and 16Gb so you need to go horizontal at some point. Rather than create new unlinked instances the idea is that you would simply adjust the number of requested instances and let the infrastructure take care of making reality match the request (if the available resources allow for it). When things calm down you can back off the number of requested instances and watch the (immutable) number of actual instances fall back as machines are gracefully shut down. Similarly one can tweak the allocated resources (RAM, CPU, etc.) and, provided the infrastructure supports it, the changes will be applied to all the "shadow" instances. Ultimately the "governor" (e.g. RightScale) could constantly tune the application based on the amount and type of load (a fair amount of artificial intelligence could go into these decisions but that's a subject for a different forum) and wouldn't have to worry about the mechanics of managing the resources (which arguably should be done locally anyway). Of course the infrastructure would also have the option of creating many separate instances if it wanted to (e.g. so providers like Amazon can still use OCCI if they want to). If anyone has any thoughts about this then I'd be interested to hear them... Sam

4 12

Test suite for OCCI
by Sam Johnston 26 Oct '09

26 Oct '09

Morning all, Last for tonight I promise... I (well, and a bunch of people much smarter than myself) figure the best way to make sure that implementations are interoperable is to develop a comprehensive test suite from the specification. Accordingly I've been looking at the various options and having written the earlier reference implementation in Python (for Google App Engine) I figure PyUnit is as good a candidate as ever. It helps that virtually all systems have python either preinstalled or at least available for download nowadays and that there's a Google App Engine harness for it ( gaeunit.py <http://code.google.com/p/gaeunit/>). This should allow anyone (including end users) to point it at their implementations and test compliance without having to download anything. I say "should" because I'm not sure if GAE supports custom HTTP methods yet (e.g. PUT, OPTIONS and more obscure ones like COPY and MOVE), but I'll soon find out. Before I spend too much more time looking into this I wanted to give you all an opportunity to comment, particularly if you have better ideas? Do any of you think this (and test suites in general) are a particularly good or bad idea? Sam

4 5