A disturbing taste of the "Digital Wild West"

Dodgy dealings happen all the time but it's not often you get to see it boiling over into the public arena as we have today. I saw in my newsfeed this morning that GrokLaw had picked up on (Darl, Norris, Bryan Cave Named as Defendants in IP Litigation - The Pelican Brief) a Courthouse News article (Ex-Partner Accused of AIP Trade Secret Theft) about a recently filed complaint by Pelican Equity, LLC against Talos Partners, Darl McBride (of SCO Group fame), Robert V. Brazell (of Overstock.com fame), Stephen L. Norris, Rama Ramachandran and lawfirm Bryan Cave LLP.

It claims a conspiracy to "steal AIP's proprietary stock loan product" (EQUITAP™, [which] helps investors achieve their financial goals by structuring non-recourse loans using the securities in their portfolio as collateral) and "virtually API's entire business from API and its founder, Mark Robbins" (Pelican claim to own the relevant rights). It then goes on to explain the whole sorry story of a techie (Robbins) investing four years and apparently all of his money into development of a product, being approached by seasoned businessmen (Brazell & McBride) as potential partners, the subsequent formation of a new business (Talos) and theft of everything from AIP's products to website to employees (Ramachandran) with the help of AIP's own lawyers (Bryan Cave LLP) who ultimately blew the whistle with an "astonishing" conflict of interest waiver.

The truly mindblowing part of the whole story though is the Skyline Cowboy site they claim is run by McBride and Brazell: "Finally, in a heinous effort to obliterate AIP's business and deflect their misdeeds [they] have over approximately the last 60 days littered the Internet with scurrilous postings on www.skylinecowboy.com, a website they used primarily for that purpose, and on Yahoo, Twitter and other message boards."

If that's true it's like coming back to stab the guy in the carpark after you've robbed him of everything he owns. Not only have they posted a video of the guy's wife being served what they claim is a $109,627 check fraud judgment following a $1,000 bounty as well as a $20,000 reward for arrest and $1,000,000 reward for "full restitution" (save that both appear to be impossible - and likely a result of the claimed highway robbery), but now they've offered $30,000 for the true identity of GrokLaw's Pamela Jones (PJ) who they claim is a "Secret IBM Shill Blogger". Let's not be too quick to forget the relationship to SCO Group and their apparently Microsoft funded attacks on IBM, Novell and Linux in general.

Anyway you can see the juicy details for yourself in the filings and if you're a GrokLaw member, the article and associated discussion (the article has since been updated "Now that I've read it, I've made the article Members Only for now." and unfortunately "creation of new accounts has been temporarily disabled"). I have but one question: Who the %!#$ do these cowboys think they are? It's amazing to think that our society routinely jails people for petty theft while leaving [what appear to be] career conmen free to enrich themselves at others' expense. Anyway at least Bernie Madoff got his comeuppance... you've heard my opinion - what's yours?

Gartner: VMware the next Novell? Cloud to save the world?

There's been two more-interesting-than-usual posts over at the Gartner blogs today:

Just a Thought; Will VMware become the next Novell?

"VMware owns the market, well above 90%, and continues to come out with more and more innovative products.  VMware has a loyal following of customers who see no reason to change direction – after all, the product works, the vision is sound, and the future is clear.  But lurking in the background is this little thing called hyper-V;  not as robust, or as tested as VMware, with almost no install base, and certainly not ready for prime time in most peoples minds.  However, it will be an integral part of Windows 7, Windows Server 2008 and Windows Server 7 in 2010."

 And here's my response:

Thanks for an insightful post - I definitely think you’re onto something here, and it’s not the first time I’ve said it either.


The thing is that the hypervisor is already commoditised. Worse, it’s free and there are various open source alternatives like Sun’s VirtualBox (which just released another major version yesterday). Then you’ve got Xen, KVM, etc. competing directly as well as physical hardware management tools coming down from above and containers/VPS’s eroding share from below. VMs may be all the rage today but the OS is overhead so there’s cloud platforms to think about too…


VMware’s main advantage is having a serious solution today which it can roll out to the large base of enterprise clients they have developed over the last decade. You can bet they’re busy making hay while the sun’s shining as it won’t be long before people realise they’re not the only show in town.


As you say it’s their market to keep, but I’m sure our enterprise clients will be happy to have a thriving competitive marketplace.

And the second:

The Cloud Will Save The World

"So, how does this all add up to the Cloud saving the world? My (admittedly clumsy) interpretation of Tainter is that as the world grows more complex, the only chance we have to head off the disintegration of modern society under the weight of complexity comes through technological leaps in the form of disruptive innovation. The hype around the Cloud provides some justification for the idea that it is disruptive. Yefim Natis and I (mostly Yefim) developed a research note in June that describes what we see as the Killer App - Application Platform-as-a-Service (APaaS) - on the horizon that will result in accelerated disruption."

And my response:

Cloud computing is set to change the world at least as much as the Internet on which it is based did a few decades ago. Things we never would have imagined possible already are, and we’re just getting started.


That said, proponents of the precautionary principle will be fast to ask whether “disruptive innovation” is in fact “destructive innovation” and whether “accelerated disruption” is in fact “accelerated destruction”.


With accelerating change comes a raft of new risks - I for one would rather live in blissful ignorance than be interrupted by the discovery that the Large Hadron Collider was in fact capable of creating creating a black hole.

I, for one, welcome our new cloud computing overlords... now if only I had a spare $25k to sign up for the 9-week Graduate Student Program at the Singularity University which is "Preparing Humanity For Accelerating Technological Change".

Organising the Internet with Web Categories

In order to scratch an itch relating to the Open Cloud Computing Interface (OCCI) I submitted my first Internet-Draft to the IETF this week: Web Categories (draft-johnston-http-category-header).

The idea's fairly simple and largely inspired by the work of others (most notably the original HTTP and Atom authors, and a guy down under who's working on another draft). It defines an intuitive mechanism for web servers to express flexible category information for any resource (including opaque/binary/non-HyperText formats) in the HTTP headers, allowing users to categorise web resources into vocabularies or "schemes" and assign human-friendly "labels" in addition to the computer-friendly "terms".

This approach to taxonomies was lifted directly from (and is thus 100% compatible with) Atom and is another step closer to being able to render individual resources natively over HTTP rather than encoded and wrapped in XML (which gets unwieldly when you're dealing with multi-gigabyte virtual machines, as we are with OCCI).

It's anybody's guess where the document will go from here - it's currently marked "Experimental" but with any luck it will pique the interest of the standards and/or semantic web community and go on to live a long and happy life.

Internet Engineering Task Force                              S. Johnston
Internet-Draft                               Australian Online Solutions
Intended status: Experimental                               July 1, 2009
Expires: January 2, 2010


                             Web Categories
                 draft-johnston-http-category-header-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies the Category header-field for HyperText
   Transfer Protocol (HTTP), which enables the sending of taxonomy
   information in HTTP headers.



Johnston                 Expires January 2, 2010                [Page 1]

Internet-Draft              Abbreviated Title                  July 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Categories  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The Category Header Field . . . . . . . . . . . . . . . . . . . 4
     3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Category Header Registration  . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Internationalisation Considerations . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Appendix A.  Notes on use with HTML . . . . . . . . . . . . . . . . 7
   Appendix B.  Notes on use with Atom . . . . . . . . . . . . . . . . 7
   Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . . . 8
   Appendix D.  Document History . . . . . . . . . . . . . . . . . . . 8
   Appendix E.  Outstanding Issues . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9































Johnston                 Expires January 2, 2010                [Page 2]

Internet-Draft              Abbreviated Title                  July 2009


1.  Introduction

   A means of indicating categories for resources on the web has been
   defined by Atom [RFC4287].  This document defines a framework for
   exposing category information in the same format via HTTP headers.

   The atom:category element conveys information about a category
   associated with an entry or feed.  A given atom:feed or atom:entry
   element MAY have zero or more categories which MUST have a "term"
   attribute (a string that identifies the category to which the entry
   or feed belongs) and MAY also have a scheme attribute (an IRI that
   identifies a categorization scheme) and/or a label attribute (a
   human-readable label for display in end-user applications).

   Similarly a web resource may be associated with zero or more
   categories as indicated in the Category header-field(s).  These
   categories may be divided into separate vocabularies or "schemes"
   and/or accompanied with human-friendly labels.

   [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list,
   although this is NOT a work item of the HTTPBIS WG. ]]

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119], as
   scoped to those conformance targets.

   This document uses the Augmented Backus-Naur Form (ABNF) notation of
   [RFC2616], and explicitly includes the following rules from it:
   quoted-string, token.  Additionally, the following rules are included
   from [RFC3986]: URI.


2.  Categories

   In this specification, a category is a grouping of resources by
   'term', from a vocabulary ('scheme') identified by an IRI [RFC3987].
   It is comprised of:

   o  A "term" which is a string that identifies the category to which
      the resource belongs.

   o  A "scheme" which is an IRI that identifies a categorization scheme
      (optional).





Johnston                 Expires January 2, 2010                [Page 3]

Internet-Draft              Abbreviated Title                  July 2009


   o  An "label" which is a human-readable label for display in end-user
      applications (optional).

   A category can be viewed as a statement of the form "resource is from
   the {term} category of {scheme}, to be displayed as {label}", for
   example "'Loewchen' is from the 'dog' category of 'animals', to be
   displayed as 'Canine'".


3.  The Category Header Field

   The Category entity-header provides a means for serialising one or
   more categories in HTTP headers.  It is semantically equivalent to
   the atom:category element in Atom [RFC4287].

   Category           = "Category" ":" #category-value
   category-value     = term *( ";" category-param )
   category-param     = ( ( "scheme" "=" <"> scheme <"> )
                      | ( "label" "=" quoted-string )
                      | ( "label*" "=" enc2231-string )
                      | ( category-extension ) )
   category-extension = token [ "=" ( token | quoted-string ) ]
   enc2231-string     = 
   term               = token
   scheme             = URI

   Each category-value conveys exactly one category but there may be
   multiple category-values for each header-field and/or multiple
   header-fields per [RFC2616].

   Note that schemes are REQUIRED to be absolute URLs in Category
   headers, and MUST be quoted if they contain a semicolon (";") or
   comma (",") as these characters are used to separate category-params
   and category-values respectively.

   The "label" parameter is used to label the category such that it can
   be used as a human-readable identifier (e.g. a menu entry).
   Alternately, the "label*" parameter MAY be used encode this label in
   a different character set, and/or contain language information as per
   [RFC2231].  When using the enc2231-string syntax, producers MUST NOT
   use a charset value other than 'ISO-8859-1' or 'UTF-8'.

3.1.  Examples

   NOTE: Non-ASCII characters used in prose for examples are encoded
   using the format "Backslash-U with Delimiters", defined in Section
   5.1 of [RFC5137].




Johnston                 Expires January 2, 2010                [Page 4]

Internet-Draft              Abbreviated Title                  July 2009


   For example:
   Category: dog

   indicates that the resource is in the "dog" category.
   Category: dog; label="Canine"; scheme="http://purl.org/net/animals"

   indicates that the resource is in the "dog" category, from the
   "http://purl.org/net/animals" scheme, and should be displayed as
   "Canine".

   The example below shows an instance of the Category header encoding
   multiple categories, and also the use of [RFC2231] encoding to
   represent both non-ASCII characters and language information.
   Category: dog; label="Canine"; scheme="http://purl.org/net/animals",
             lowchen; label*=UTF-8'de'L%c3%b6wchen";
             scheme="http://purl.org/net/animals/dogs"

   Here, the second category has a label encoded in UTF-8, uses the
   German language ("de"), and contains the Unicode code point \u'00F6'
   ("LATIN SMALL LETTER O WITH DIAERESIS").


4.  IANA Considerations

4.1.  Category Header Registration

   This specification adds an entry for "Category" in HTTP to the
   Message Header Registry [RFC3864] referring to this document:
   Header Field Name: Category
   Protocol: http
   Status: standard
   Author/change controller:
       IETF (iesg@ietf.org)
       Internet Engineering Task Force
   Specification document(s):
       [ this document ]


5.  Security Considerations

   The content of the Category header-field is not secure, private or
   integrity-guaranteed, and due caution should be exercised when using
   it.


6.  Internationalisation Considerations

   Category header-fields may be localised depending on the Accept-



Johnston                 Expires January 2, 2010                [Page 5]

Internet-Draft              Abbreviated Title                  July 2009


   Language header-field, as defined in section 14.4 of [RFC2616].

   Scheme IRIs in atom:category elements may need to be converted to
   URIs in order to express them in serialisations that do not support
   IRIs, as defined in section 3.1 of [RFC3987].  This includes the
   Category header-field.


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, November 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC4287]  Nottingham, M. and R. Sayre, "The Atom Syndication
              Format", RFC 4287, December 2005.

   [RFC5137]  Klensin, J., "ASCII Escaping of Unicode Characters",
              RFC 5137, February 2008.

7.2.  Informative References

   [OCCI]     Open Grid Forum (OGF), Edmonds, A., Metsch, T., Johnston,
              S., and A. Richardson, "Open Cloud Computing Interface
              (OCCI)", .

   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",



Johnston                 Expires January 2, 2010                [Page 6]

Internet-Draft              Abbreviated Title                  July 2009


              RFC 2068, January 1997.

   [W3C.REC-html401-19991224]
              Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
              Specification",
              .

   [W3C.WD-html5-20090423]
              Hyatt, D. and I. Hickson, "HTML 5", April 2009,
              .

   [draft-nottingham-http-link-header]
              Nottingham, M., "Web Linking",
              draft-nottingham-http-link-header-05 (work in progress),
              April 2009.

   [rel-tag-microformat]
              Celik, T., Marks, K., and D. Powazek, "rel="tag"
              Microformat", .


Appendix A.  Notes on use with HTML

   In the absence of a dedicated category element in HTML 4
   [W3C.REC-html401-19991224] and HTML 5 [W3C.WD-html5-20090423],
   category information (including user supllied folksonomy
   classifications) MAY be exposed using HTML A and/or LINK elements by
   concatenating the scheme and term:
   category-link = scheme term
   scheme        = URI
   term          = token

   These category-links MAY form a resolveable "tag space" in which case
   they SHOULD use the "tag" relation-type per [rel-tag-microformat].

   Alternatively META elements MAY be used:

   o  where the "name" attribute is "keywords" and the "content"
      attribute is a comma-separated list of term(s)

   o  where the "http-equiv" attribute is "Category" and the "content"
      attribute is a comma-separated list of category-value(s)


Appendix B.  Notes on use with Atom

   Where the cardinality is known to be one (for example, when
   retrieving an individual resource) it MAY be preferable to render the



Johnston                 Expires January 2, 2010                [Page 7]

Internet-Draft              Abbreviated Title                  July 2009


   resource natively over HTTP without Atom structures.  In this case
   the contents of the atom:content element SHOULD be returned as the
   HTTP entity-body and metadata including the type attribute and atom:
   category element(s) via HTTP header-field(s).

   This approach SHOULD NOT be used where the cardinality is guaranteed
   to be one (for example, search results which MAY return one result).


Appendix C.  Acknowledgements

   The author would like to thank Mark Nottingham for his work on Web
   Linking [draft-nottingham-http-link-header] (on which this document
   was based) and to the authors of [RFC2068] for specification of the
   Link: header-field on which this is based.

   The author would like to thank members of the OGF's Open Cloud
   Computing Interface [OCCI] working group for their contributions and
   others who commented upon, encouraged and gave feedback to this
   draft.


Appendix D.  Document History

   [[ to be removed by the RFC editor should document proceed to
   publication as an RFC. ]]

      -00

      *  Initial draft based on draft-nottingham-http-link-header-05


Appendix E.  Outstanding Issues

   [[ to be removed by the RFC editor should document proceed to
   publication as an RFC. ]]

   The following issues are oustanding and should be addressed:

   1.  Is extensibility of Category headers necessary as is the case for
       Link: headers?  If so, what are the use cases?

   2.  Is supporting multi-lingual representations of the same
       category(s) necessary?  If so, what are the risks of doing so?

   3.  Is a mechanism for maintaining Category header-fields required?
       If so, should it use the headers themselves or some other
       mechanism?



Johnston                 Expires January 2, 2010                [Page 8]

Internet-Draft              Abbreviated Title                  July 2009


   4.  Does this proposal conflict with others in the same space?  If
       so, is it an improvement on what exists?


Author's Address

   Sam Johnston
   Australian Online Solutions
   GPO Box 296
   Sydney, NSW  2001

   Email: samj@samj.net
   URI:   http://samj.net/






































Johnston                 Expires January 2, 2010                [Page 9]

The browser is the OS (thanks to Firefox 3.5, Chrome 2, Safari 4)

Almost a year ago I wrote about Google Chrome: Cloud Operating Environment and [re]wrote the Google Chrome Wikipedia article, discussing the ways in which Google was changing the game through new and innovative features. They had improved isolation between sites (which is great for security), improved usability (speed dial, tear off tabs, etc.) and perhaps most importantly for SaaS/Web 2.0 applications, vastly improved the JavaScript engine.

Similar features were quickly adopted by competitors including Opera (which Chrome quickly overtook at ~2%) and Firefox (which still has an order of magnitude more users at ~20-25%). Safari is really making waves too at around 1/3-1/2 of the share of Firefox (~8%) and with the recent release of Safari 4 it's a compelling alternative - especially given it passes the Acid 3 test with flying colours while Firefox 3.5 bombs out at 93/100.

HTML 5 features such as local storage and the video and audio elements are starting to make their way into the new breed of browsers too, though it's still often necessary to install Google Gears to get advanced offline functionality (e.g. most of the Google Apps suite) up and running. Google have drawn fire by missing the Firefox 3.5 launch and users finding Gears disabled are flocking to the gears-users Google Group to vent their frustrations, some going so far as claiming that "Google is trying to do what it can to push users to Chrome" and asking "Are we watching a proccess of Google becoming customer-deaf Microsoft?". Let's just hope it's ready in time for my travel later this week...

The point is that after the brutal browser wars which stagnated the web for some time (right up until Microsoft opened the floodgates by introducing Ajax), we're now starting to see some true competition again. Granted Internet Explorer is still a 1,000 pound gorilla at ~65% of market share, but even with a silk shirt in the form of IE 8 and a handful of lame ads it's still a pig and the target of the vast majority of security exploits on the web. This makes it an an easy sell for any competitor who manages to get a foot in the door (which is unfortunately still the hardest part of the sale).

The decision not to ship IE with Windows 7 in Europe will be interesting as it should draw mainstream attention to the alternatives which will flow on to other markets (as we've seen with adoption of "alternative" technology like Linux in the past - not to mention the whole Netbook craze started by OLPC in the third world). However, with the browser being where most of the action is today the operating system has become little more than a life support system for it - an overly thick interface layer between the browser and the hardware. Surely I'm not the only one who finds it curious that while the software component of a new computer is fast approaching 50% of the cost (up from around 10% a decade ago), the heart of the system (the browser) is both absent from Windows 7 and yet freely available (both in terms of beer and freedom)? Something's gotta give...

Anyway it's time to stop looking at the features and performance of the underlying operating system, rather the security and scalability of the browser. When was the last time you turned to the operating system anyway, except to fix something that went wrong or do some menial housekeeping (like moving or deleting files)?

An open letter to the CAcert.org board and members

This is an open letter to the CAcert.org board and membership (including my fellow 20-30 official "Association Members" (copied) as well as the 150,000 or so account holders we effectively represent) concerning recent events that could affect the ongoing viability of the organisation. Bearing in mind that this is an organisation built on trust, I implore you to follow my example in exercising extreme caution when we are called to necessarily intervene in resolving the deadlock. Despite claims to the contrary there is no urgency and the last thing we need now is an Iran style election (whether or not legitimate, perception is everything).

The Problem

It appears (from my perspective as an outsider, albeit with the benefit of various insider accounts) that the board has split into two factions. On one hand we have the "old school" who have been on the board for a while (some would say too long) and the other "reformist(s)" who seek change, yesterday. They are now on a crash course that will invariably result in the loss of committed contributors, or worse, loss of trust from the community. In any case a confrontation poses a serious risk to the organisation's future, and with it the community's access to an alernative to commercial certification authorities.

In requesting and receiving the official member list as well as proposing a number of new members (who are presumably sympathetic to their position and will vote for any motion they submit) it was already clear that plans were afoot for a "coup d'état". Now that an SGM has been proposed to "get this over with" complete with a clear agenda there is absolutely no doubt about it:

1. Acceptance of new members. (E.Schwob, A.Bürki, I.Grigg)
2. Vote that the committee of management no longer enjoys the confidence of the members.
3. Vote that the committee is hereby removed from office and election of a committee shall immediately follow adoption of this resolution.
4. Election of a new committee of management. 

It is no wonder that the existing board feel they are under attack - they effectively are - and given the "soonest this could be done is in 7 days" they are no doubt starting to feel the pressure. I don't buy it. Yes, the auditor recently resigned and yes we will eventually need to get the audit back on track, but right now the number one issue is restoring stability to an unstable structure and minimising collateral damage. This needs to be done slowly and carefully and those promoting panic are perhaps deserving of the suspicion they have raised.

It is not my intent to start (yet another) discussion, rather to propose a safe and sensible way forward that will ensure CAcert's ongoing viability while protecting our most valuable asset: the trust of the community. Should the SGM proceed as planned (whether or not it is successful) I will be the first to admit that the trust is lost.

The Solution

The very first thing we need to do is expand the membership base by one or two orders of magnitude, as Patrick explains:

Increasing the number of members, will increase the stability of your organization. It is more difficult to try a Coup d'Etat or a revolution when you have to convince 200 voting members than 20. On the other hand, major changes will be slower for the same reason.

Any structure with a broad base is far more stable than the top heavy structure we have today (the subversion of which requires a mere THREE new members to be proposed at SGM!).

The two main obstacles to becoming a member today are:

• A convoluted process requiring a "personally known" proposer and seconder as well as an explicit vote from the committee
• A token USD10 annual fee, the proceeds of which (around €200) are a drop in the ocean

Fortunately the committee has the power to require "some other amount" (including zero) at least until such time as the organisation's rules can be updated accordingly (see CAcertIncorporated and the Associations Incorporation Act for more details). Accordingly the membership fees for 2009/2010 should be immediately suspended as members are far more important than money right now.

The process for becoming a member should also be streamlined, if not completely overhauled. Surely I'm not the only one who considers it ironic that an open, community driven organisation should in fact be closed. Building the broadest possible membership base offers the best protection against attacks like this (and yes, I consider this an attack and urge the attackers to back off while the structure is stabilised). Associations are typically limited by guarantee - which means that becoming a member involves a commitment to pay a certain (usually token) amount in the event that the organisation should be would up (as opposed to companies limited by shares, where the liability is limited to the value of the shares themselves). People are far more likely to agree to this than reach into their own pockets (even if only due to laziness) so this change alone should make a huge difference.

The invitation to become a member should then be extended to some (e.g. assurers, assured, active cert holders, etc.) or all of the existing users, whose membership applications should be processed as efficiently as possible. Ideally this would be able to be done online as [an optional] part of the signup process (perhaps relying on Australia's Electronic Transactions Act to capture electronic signatures) but for now the rules require writing or digitally signed email. A temporary "pipeline" consisting of one or more dedicated proposers and seconders could be set up, processing digitally signed applications from members as they arrive. The proposer and seconder requirement (who must be "personally known" to the applicant) should be eventually dropped and the "default deny" committee vote be dropped or replaced with a "default accept" [after 7 days?] veto. In any case only those with an existing interest in CAcert (e.g. a user account) will be eligible at this time so there is little risk of outsider influence.

Once we have a significantly larger membership base (at least 100 members but ideally more like 200-2000) we can proceed to an orderly election of a new board with each candidate providing a concise explanation of their experience and why they (individually) should be selected as representatives. The resulting board would likely be a mix of the two factions (who would hopefully have agreed to work together) as well as some "new blood".

I hope that you will agree that this is the best way forward and that those of you who have offered support to the revolutionary(s) reconsider in the presence of this far safer alternative. Should they press on with the SGM I for one will be voting against the motions (and encourage you to do the same), not because I don't agree "it's time for change" but because of the way it has been effected.

Thanks for your time and attention,

Sam

CloudBurst Trademarked?

It's no secret that "CloudBurst" is one of my least favourite cloud computing buzzwords. Its intended meaning is something like when you run out of room in your own datacenters you can "CloudBurst" into a public service like EC2. Not only is that somewhat the pipedream today (you want an enterprise app to do what?), but it is a significant deviation from the real world meaning of the term which according to Wikipedia is:

A cloudburst is an extreme form of rainfall, sometimes mixed with hail and thunder, which normally lasts no longer than a few minutes but is capable of creating minor flood conditions.

Fortunately it seems I may not have to put up with it for much longer because the guys at Ythos (a "Technology and Business Development Consultancy") have gone and registered it with the USPTO (Trademark #77736577).

That said, it seems the USPTO have learnt some lessons from last year's "cloud computing" trademark debacle, citing Dell's ill-fated trademark in denying Q-Layer^W Sun^W Oracle's application for NephOS. They should probably deny this one too, but I'm saying that through gritted teeth and would be quite happy to see it removed from the public lexicon.

Update: Interestingly LogMeIn, Inc. got in a scuffle over the trademark a few years back but unfortunately it was "Abandoned after an inter partes decision by the Trademark Trial and Appeal Board."

The Intercloud is a global cloud of clouds

 Few of us will dispute that:

The Internet is a global network of networks

So it logically follows that:

The Intercloud is a global cloud of clouds

It's amazing to think that the Internet kept us busy for two decades or so just by delivering the ability to pass messsages between any two (or more) clients, and to consider all the things we've managed to achieve with this seemingly simple advance. It seems only yesterday I had one of the first private Internet connections in Australia (courtesy DIALix - the country's first commercial ISP) and was able to communicate with others around the globe (in real-time courtesy [y]talk - responsiveness we still haven't managed to faithfully replicate with today's instant messaging networks!). But now it's time to take the Internet to the next level.

While the servers scaled up as the masses poured in it wasn't long before we reached a glass ceiling - clearly vertical scalability wasn't the way forward. Sure you can build big machines (after all, mainframes and minicomputers were fresh in our minds) but it's like driving a boat - after a certain point you'll use an order of magnitude more fuel to go only a fraction faster (think of the cost of big iron vs commodity white boxes).

By now I was a university sysadmin and the dot-com bust was still a few years away. Officially I was busy setting up Aurema's Share II (since acquired by Citrix) on a pair of SGI Origin servers so as UNSW's Maths Department and the Australian Graduate School of Management (AGSM) could "fair share" the hardware they'd purchased together. Unofficially I was experimenting with making ~150 overpowered but under-used Pentium-II workstations appear as one (using Debian GNU/Linux, bpbatch aka Rembo aka IBM Tivoli and tools like PVM). I knew which approach I preferred but unfortunately the machines lived out their lives idling as X terminals and I went to work on dot-coms and the Sydney 2000 Olympics.

Enter Google, Amazon and others (e.g. the entire grid community) who worked out how to make horizontal scalability work properly with toys like BigTable (A Distributed Storage System for Structured Data) and MapReduce (Simplified Data Processing on Large Clusters). It was finally possible to build services that could scale endlessly, allowing these pioneers to innovate without looking over their shoulders after becoming victims of their own success. We know how that worked out for them (after all the world only needs five computers, right?) - today we have computing powerhouses sprinkled around the Internet run by companies like Google and Amazon while everyone else is playing musical chairs and hoping they won't wind up without a seat.

To use the electricity grid analogy, the Internet is like the grid itself - that is, the network of wires and power stations that connect everything together. One can poke electrons in one side and know ekectrons will pop out the other, even if various links are severed. Indeed that's all we've needed for email, instant messaging, media streaming and of course the web itself. The problem is that a grid without power stations isn't so interesting. Useful, yes, but certainly not exploiting the technology to the fullest extent possible. Enter cloud computing with various cloud providers (and the underlying Internet) forming the Intercloud.

So who invented the term? Who knows. Who cares. I didn't (I'm not even the first to say it's a "cloud of clouds") but I have been using it pretty much since I first started talking about cloud computing and I've heard others like Rich Miller using it too... it was first mentioned in the press (outside of Trend Micro's "InterCloud" security service) back in 2007 in Head in the clouds? Welcome to the future:

Although vendors talk as though there is only one Internet cloud each vendor will be running its own set of data centres that customers can use to access Internet-based information and resources which may complicate matters

Cisco have been busy popularising the term lately, presenting a "blueprint" and whipping up A Hitchhiker's Guide to the Inter-Cloud that unsurprisingly focuses on private cloud and finds a place for their Unified Computing System. Gartner have been getting in on the action too and it seems likely that before long a bunch of other people will as well.

Although I think it's got a snowflake's chance in hell of displacing the Internet moniker, it may be useful for framing discussions about cloud computing interoperability and unlike many of the other terms that have popped up may actually serve some purpose (surely IBM of all people should know that whenever someone says "CloudBurst" $GOD kills a kitten).

If we're to realise the full value of cloud computing it will be by loosely coupled "aggregation" (as distinct from integration) of various offerings rather than putting all our eggs in one basket with a single provider. We don't expect Microsoft to provide the best software for every task (hence products like Adobe Photoshop and Autodesk's AutoCAD) so why expect less heterogeneity in the cloud?

"as a Service" moniker considered harmful (IOW: Say NO to *aaS!)

This is a humble (possibly overdue) call for the community to start thinking about adopting sensible cloud computing nomenclature - it's going to happen eventually anyway so we may as well get started now.

While toiling away putting lines on the road for cloud computing at 3am on a weekday (which is to say, writing cloud standards) I saw something which nearly made me lose my beer via my nose: a straight-faced proposal for the community to adopt "Data Storage as a Service (DaaS)" as the "formal term" for what we currently call "Cloud Storage" (courtesy SNIA's "Cloud Storage" technical working group no less). Perhaps they missed the memo (or nobody bothered to write it), but I doubt I'm the first to observe the "as a Service (aaS)" moniker has done its job and is now well past its use by date.

Sure, yesterday we used to buy software, platforms and infrastructure as products, but you never saw anyone advertising "Software as a Product", "Platform as a Product" or "Infrastructure as a Product" now, did you? It sounds silly because it is. We used to buy electricity as a product too you know (in the form of a generator) but now it's just plain old electricity. I can hardly imagine Thomas Edison standing on Pearl Street, NY trumpeting "Electricity as a Service", but it's hard not to conjure up the same image when hearing vendors sprouting off about it.

Fortunately there's a simple solution - just drop the superfluous "as a" which is sandwiched in the middle and optionally add a dash of cloud to taste (all lowercase where possible per CMOS, and resist the urge to abbreviate):

• "Software as a Service" becomes [cloud] software services
• "Platform as a Service" becomes [cloud] platform services
• "Infrastructure as a Service" becomes [cloud] infrastructure services

We'll know we've been successful when cloud fades off into the background (it's already optional above), and even more so when it's not necessary to differentiate between products and services (that is, when it's just "software", "platform" and "infrastructure" again because nobody in their right mind would use products when better/faster/cheaper services are available).

Anyway before I hit the hay, here's what I had to say on the proposal (which as it turns out has more serious problems in the form of existing registered trademarks):

Morning all,

First, congratulations for promptly getting some deliverables out the door.

Please though, for the love of $GOD, find a more sensible name for it than "Data Storage as a Service (DaaS)".

I'm sure I'm not the only one here who's had enough of all the unnecessary *aaS and to that end propose the following transitions as the technology matures (we'll know we've been successful when the "cloud" moniker fades away):

• Software as a Service -> cloud software services -> cloud software -> software
• Platform as a Service -> cloud platform services -> cloud platform -> platform
• Infrastructure as a Service -> cloud infrastructure services -> cloud infrastructure -> infrastructure
  

For storage then it would go something like:

• Data Storage as a Service -> cloud storage services -> cloud storage -> storage
  

I have solid basis for this too, from my Sanity as a service: marketing gone mad post last year:

DaaS is a hive of activity too - AServer will tell you it stands for Datacenter as a Service™ but Q-Layer already tried that. Too bad for Desktone who are on the road to registering Desktops as a Service™

The A-Server guys are having another crack at the trademark after abandoning the first one, and have been told that Desktone already beat them to it. In any case, for many it means "Data as a Service" in reference to the actual data itself (think Amazon Public Data Sets).

Hope this helps avoid some trouble down the road,

Sam

Now please, go forth and do your bit to make the world a better place.

A Clear[er] Future for CloudCamp (and cloud computing in general)

Earlier today Reuven Cohen posted about A Bright Future for CloudCamp in which he publicly stated that he "will happily transfer all related IP, domains, etc to the control of the [CloudCamp] organization" in response to (if not necessarily as a result of) my Enomaly, Inc. owns CloudCamp™ - has it jumped the shark? post. The details of the organisation were light and there was indeed some confusion over the trademark but Dave Nielsen confirmed that "CloudCamp will be turned into a for-profit ... OVER MY COLD, DEAD BODY! Also, as you know, I have spent a lot of time researching the formation of CloudCamp as a non-profit (which is only fitting, since no-one has received any compensation ;-)."

Some key details are missing, such as how or indeed if the official(s) will be elected and what form of non-profit will be formed - a section 503(c)(3) created on the basis of educational and/or scientific services may also offer tax exemptions for sponsors in the US for example. I'm expecting these to be clarified at the anniversary CloudCamp event on 24 June 2009 and with lots of eyes on the details there will be no room whatsoever for shenanigans - as I won't be there be sure to ask plenty of questions if anything still seems out of place. In particular it should be burnt into the memorandum and articles of association that the organisation cannot be sold or have its assets transferred to another entity that is not similar in spirit (e.g. non-profit), and that the objective of the organisation should be to educate about cloud computing rather than promotion of commercial interests (e.g. the infamous trade association). The officials should also be elected by organisers and/or participants (within say the first year if not immediately at launch) who should be true members of/subscribers to the organisation and thus able to vote; that way if our illustrious leaders lose interest (or their minds) then the community can continue. These requirements remove all temptation and make us less of a target for subversion, thus guaranteeing CloudCamp's continued viability (at least until we're so successful that it's no longer relevant and "cloud" fades into the background like "client-server" did a few decades ago).

In order to further improve transparency relating to the handling of money I will set a good example by being 100% transparent with CloudCampParis. That is, I commit to make available all details of money received and spent for public scrutiny. So far we have a number of €250 and €500 sponsorships confirmed or in the works and quotes for €1,200 and €1,500 in catering (depending whether we go for bags or buffet - I'd still prefer beer & pizza though), as well as something like €750 in flights to get Dave there for this first French event - we're on track to break even. I have already committed to sponsors to ensure that all funds raised will be spent on the event itself and encourage other organisers to follow suit. For those who raised concerns about potential improprieties I encourage you to challenge the organisers to justify their expenses with receipts and hope that they will do so proactively in future; with complete transparency there is no need for trust (and angst when trust is lost).

The real news of the day though follows on from my being (again) silenced by a "consensus" (which included many of those implicated by my earlier allegations) and then immediately after flat out accused of "only becom[ing] involved for one reason -- to try to fork the community" (only now deprived the right of reply). This is clearly BS as if I wanted to fork the community I just would have done so by feeding the growing unrest rather than pushing the committee to put its cards on the table; I have about as much interest in being at the "top" of what I believe should be a completely flat structure as I do in contributing to something which I believe could/will be eventually subverted for the enrichment of a few individuals. Although I've been sharply critical at times (more often than I would like), everything I post is [believed to be] true and almost always links back to a primary source; this was a flat out lie and it resulted in a flat out threat should it not promptly be proven or retracted with an apology.

Immediately after Reuven forwarded my message clearly marked CONFIDENTIAL to the public list, he and I got on the phone for half an hour (the first time we've actually spoken) and discussed our differences. He does a good job of summarising it so I'll just quote him:

I just got off the phone with Sam. After almost a year of public feuding, we finally actually spoke in person. First let me say that email probably isn't the best method for dispute resolution. I probably should have called Sam long ago. It's clear we share the same passions for open cloud computing. In regards to my previous statements about Sam's intention to fork CloudCamp, he has assured me that isn't the case and he is committed to making the Paris CloudCamp event a success we can all share. I believe him.

Going forward we agreed that continuing our feud is childish and does more harm then good. We are going to actively work to strengthen our relationship and put this ridiculous feud behind us. My request to Sam is that in the future is if he does have a grievance he call me directly before we take our frustrations public, we both agree this is a better approach then a public battle.

Unfortunately those of you who found all this rather entertaining will have to go back to watching WWF as we're finally going to get on with furthering the interests of cloud computing rather than [in]fighting (which makes no sense whatsoever given we're not even competitors) or "inside baseball" according to one article. As TheOtherSam pointed out:

Reuven recently wrote about two watershed epochs in the development of the cloud industry. Given the energy and passion of these two individuals, this event might mark a third!

Given things like the ill-fated Open Cloud Alliance now have some chance of seeing the light of day, duplicate initiatives like the Unified Cloud Interface (UCI) and Open Cloud Computing Interface (OCCI) can work together and fiascos like the Open Cloud Manifesto are less likely to occur behind closed doors this may well prove correct - one thing you can be sure of is that where I'm involved there will be NoBullshit™

So let's close this chapter and get on with it...

Enomaly, Inc. owns CloudCamp™ - has it jumped the shark?

So Reuven Cohen's company, Enomaly, Inc. effectively owns CloudCamp... you heard it here first:

Here's the backstory:

As you're no doubt already aware I recently stepped up to bring CloudCamp to Paris on 11 June 2009, which seemed like a good idea at the time and a nice opportunity to kickstart the community over here (we already have almost 100 registrations!). You also likely followed my coverage of previous Enomaly-related fiascos including the CCIF goat rodeo and appreciate that I have a very low tolerance for bulls--t in anything I'm involved with (I still can't for the life of me work out why Enomaly insists on involving itself in this stuff rather than focusing on its fledgling business). What you probably don't know is that the CCIF and CloudCamp organisations are (or at least were to be) one and the same, were it not for backlash from local organisers and my premature uncovering of the ill-fated [Open] Coud [Computing] Alliance just in the nick of time. I figured the shenanigans and tomfoolery were in the past and that we'd moved on but apparently not...

So we held our first organisers' meeting a few weeks back hit the ground running with an agenda, venue, sponsors and a handful of registrations in an Eventbrite site that we set up. As we expect a mixed audience and bearing in mind we're in Central Europe rather than the US we went for a more formal structure than usual with a combination of set talks and an "unpanel". This apparently wasn't the CloudCamp approved format so the agenda was overhauled only to be rejected by the venue and restored to something more like what we started with. The Eventbrite site was also handed over without question to Dave Nielsen, who claimed it would be better on his account for cross-marketing purposes. That was fine until we wanted to offer sponsorship slots to a few specific registrants but were denied access to our own list on the basis of a "no-spam policy" (if we can't trust our own organisers then who can we trust, bearing in mind BarCamp lists are public, albeit obfuscated). Needless to say my patience was already being tested because things I needed (documentation and a sponsorship kit) were absent while things I didn't (interference) were plentiful.

Naturally cynical and somewhat unsettled by our brushes with the self-appointed CloudCamp committee (which obnoxiously lists Reuven as "instigator" while failing to acknowledge any of the European contributors including Alexis Richardson, Chris Purrington and Simon Wardley who were equally critical to its' success, not to mention BarCamp itself on which the whole thing is based) I took advantage of being at the Cloud Computing Expos in Prague and London to discuss candidly with some of the other European organisers. Sure enough I'm not the only one who's anxious about the future (of course the future of cloudcamp is looking bright when you know you own the thing!) and it seems there is some well-earned and deep-seated distrust going around. I'm also not the only one concerned about the hard work of the many potentially resulting in the unjust enrichment of the few and my attempts to convince Dave (in a 3 hour call no less) that everyone who's ever organised or even attended a CloudCamp event is both stakeholder and benefactor have thus far fallen on deaf ears. It's becoming increasingly clear to me that the view from above is that a small group of people I've previously referred to as the Mighty Morphin' Power Rangers believe they "own" the community (more "pwn" than "own" if you ask me).

Everyone I spoke to agreed that the best way forward would be to take care of registering the trademark (something that should have been done long ago anyway), to be handed over to a suitable non-profit organisation run by elected representative(s). This mail was drafted to announce the contribution, which should really have been the end of the story:

Afternoon all,

As you know I've been active in protecting all things cloud computing w.r.t trademarks, for example:

• discovering and ultimately scuttling Dell's "Cloud Computing" trademark
• exposing Psion's [ab]use of the "Netbook" trademark via Save the Netbooks
  
• registering "Open Cloud" as a certification trademark and establishing the Open Cloud Initiative

I've just discovered the term CloudCamp is not protected and as one of a large and growing list of stakeholders (on which I include everyone from participants to organisers, sponsors and "instigators") I am concerned that we are unnecessarily (significantly) exposed. I bumped into Tom Leyden at the Cloud Computing Expo in Prague (who's organised a bunch more CloudCamps than I have) and he shares my concerns, as do a handful of other organisers I have spoken to.

As such (given the significant lead times and expenses usually associated with trademark registration) I've taken the liberty of registering the trademark with the USPTO which I will gladly transfer to a 503(c)3 non-profit, established to further the interests of cloud computing and run by elected officials. If we're not (eventually) reimbursed then Tom and I will cover the costs personally as a donation/sponsorship.

Sam

The problem was when we did a worldwide search last week with a view to registering the trademark we found that Reuven Cohen (with the help of Deeth Williams Wall lawyers) had already done so in March in the name of his own company, Enomaly, Inc. Even more curiously, when I raised the trademark issue on my recent call with Dave he knew nothing about it so either he's being taken for a ride along with the rest of us or he's telling fibs too. Naturally the excuse will be that this was done to protect the community while waiting for the formation of CloudCamp, Inc. but I don't buy it - the application curiously occurred contemporaneously with a brash attempt by a vendor to buy the whole lot and I don't believe for one second that this was a coincidence.

I don't plan to dwell on this point (I don't have the time anyway) and my primary/only concern is the ongoing viability and stability of the community we have all contributed to in some way (even if just as a participant). The last thing I want to see is a for-profit company being formed and run by self-appointed dictators only to be sold to a vendor - such a thing would be the antithesis of BarCamp, on which the group is based and whatever is setup should be structured so as to make this impossible (e.g. a non-profit democracy).

I'm not the first to accuse CloudCamp of jumping the shark, and we've seen it all before (right down to the silly puff pieces promoting individuals and obnoxious "instigator" title) when MashupCamp jumped the shark a few years back. However I believe it's not yet too late to avoid forking the community (and yes, if the organisers don't come to the party then everyone I've spoken to agrees there will be a fork) as I'm fairly sure they plan to announce the new regime they've been busy nutting out with their lawyers at the anniversary CloudCamp on 24 June 2009.

As a starting point for the "Future of CloudCamp" here's a mail I wrote at the start of the month, only to have it moderated and deleted. Let's try to work out what we need from any central CloudCamp organisation (and indeed if we need one at all) and then take it from there:

---------- Forwarded message ----------
From: Sam Johnston
Date: Mon, May 4, 2009 at 7:28 PM
Subject: Future of CloudCamp
To: cloudcamp@googlegroups.com

Evening all,

There was apparently a "future of cloudcamp" call with European organisers a few weeks back and putting aside the question as to why I and the other CloudCampParis organisers I've spoken to weren't invited, was someone planning to at least post some minutes to the list?

So far as I am concerned CloudCamp is a good (albeit blatantly obvious) idea and is essentially a franchise shared between anyone who has contributed to its growth (from "instigators" to organisers to sponsors to attendees). Those of you entangled in the CCIF goat rodeo will be acutely aware of my fervour for transparency and as such I don't like having to ask for it, but I know I'm not the only one who wants to see more of it.

That in mind, by kicking off this thread I'm hoping we (the stakeholders of CloudCamp) can collaboratively and openly define the direction of the organisation. First thing's first (as I'm busy organising CloudCampParis as we speak) I'd like to get Dave some ideas as to how he can best assist local organisers. Here's some ideas to get the ball rolling:

• Sponsorship Kit to facilitate selling of sponsorships (maybe just a PDF and/or web page explaining why it's a good idea), probably offering a basic level (@ ~ $350/€250) including mentions on the event minisite, at the event, etc. and a more advanced level including a lightning talk. For bonus points offer a "bronze" level for cashed up attendees. Details TBD but you get the idea - makes it an easier sell.
• Branding Kit with logos, colours, PDFs, etc. which local organisers can use to have some sort of consistency (even a PDF of a sign with an arrow on it saves time).
  
• Global Sponsors who commit to pay a certain amount per event (say €100-500 or around €5-20k/annum) and who get a mention on the main site and at each event for it. Currently cloudcamp.com has a laundry list of sponsors including pretty much anyone who's ever had anything to do with cloud computing and their mothers - that makes it essentially worthless and difficult to sell... bronze/silver/gold/platinum sponsors would be a better idea.
  
• Organisation to take money, issue invoices, etc. but only if it's a 503(c)(3) as it's too easy to take the piss with other forms and this has significant tax advantages (read: easier to sell sponsorships and everything is cheaper). Regional organisers should be organisation members and the direction should be set by them democratically. Among other things that would save people like me having to bother our accountants about collecting money on behalf of the organisation.
  
• Support in terms of joining conference calls, mailing lists and even attending the events where possible/feasible. This is a two way street though so I guess local organisers should offer accommodation/entertainment/etc. where possible to reduce costs.
• Web Site optimised for creating and advertising individual events. This should probably be something like the Drupal CMS and organisers should be able to create and edit events without having to bother anyone else. It doesn't need to be fancy - a Wiki would probably do too (this works rather nicely for BarCamp). This is something I'd be more than happy to help out with, especially if we could get it in place quickly (in time for Paris).
  

I'm sure there's plenty of other things we could do but the point is to get some sort of discussion underway and get people involved in the governance rather than provide an exhaustive list.

Cheers,

Sam

Update: Forgot to mention that Canadian Trademark Application #1431094 has a priority date of 4 March 2009, which likely means that for an additional expense it can be extended to other Madrid protocol countries at any time in the next 6 months (e.g. until 4 October 2009). Just because it doesn't show up in USPTO yet doesn't mean it won't in due course.

Is HTTP the HTTP of cloud computing?

Ok so after asking Is OCCI the HTTP of cloud computing? I realised that the position may have already been filled and that the question was more Is AtomPub already the HTTP of cloud computing?

After all my strategy for OCCI was to follow Google's example with GData by adding some necessary functionality (a search interface, caching directives, resource-specific attributes, etc.). Most of the heavy lifting was actually being done by AtomPub, thus avoiding a huge amount of tedious and error-prone protocol writing (around 20,000 words of it) - something which OGF and the OCCI working group isn't really geared up for anyway. This is clearly a workable and well-proven approach as it as been adopted strategically by both Microsoft and Google and also tactically by Salesforce and IBM, among others. Best of all adding things like queries and versioning is a manageable workload while starting from scratch is most certainly not.

But what if there were an easier way? Recall that the problem we are trying to solve is exposing a flexible interface to an arbitrarily large collection of interconnected compute, storage and network resources. We need to be able to describe and manipulate the resources (CRUD), associate them with each other via rich links (e.g. links with attributes like local identifiers - eth0, sda, etc.) and change their state (start, stop, restart, etc.), among other things.

Representational State Transfer (REST)

Actually we're not talking about exposing the resources themselves (that would be impossible) but various representations of those resources - like Plato's shadows on the cave walls - this is the "REpresentational" in "REpresentational State Transfer (REST)". There's an infinite number of possible representations so it's impossible to try to capture them all now, but here's some examples:

• An Open Virtualisation Format (OVF) serialisation of a compute resource
• A platform-specific descriptor file (e.g. VMX)
  
• A complete archive of the virtual machine with its dependencies (OVA)
• A graphical image of the console at a given point in time ('snapshot')
• A video stream of the console for archiving/audit purposes (ala Citrix's Project Iris)
• The console itself (e.g. SSH, ICA, RDP, VNC)
• Build documentation (e.g. PDF, ODF)
• Esoteric enterprise requirements (e.g. NMS configuration)
  

It doesn't take a rocket scientist to spot the correlation between this and HTTP's existing content negotiation functionality (whereby a client can ask for a specific representation of a given resource - e.g. HTML vs PDF) so this is already pretty much solved for us (see HTTP's Accept: header for the details). For bonus points this information should be exposed in the URI as it's not always possible or convenient to set headers ala:

• http://example.com/.atom (using filename extensions)
  
• http://example.com/;content-type=text/html (using the full Internet media type)
  

Web Linking

But what about the links? As I explained yesterday the web is built on links embedded in HTML documents using the A tag. Atom also provides enhanced linking functionality via the LINK element, where it is also possible to specify content types, languages, etc. In this case however we want to allow resources to be arbitrary types and more often than not we won't have the ability to link within the payload itself. This leaves us with two options: put the links in the payload anyway by relying on a meta-model like Atom (or one we roll ourselves) or find some way to represent them within HTTP itself.

Enter HTTP headers which are also extensible and, as it turns out, in the process of being extended (or at least refined) to handle this very requirement by fellow down under, Mark Nottingham. See the "Web Linking" IETF Internet-Draft (draft-nottingham-http-link-header, at the time of writing version 05) for the nitty gritty details and the ietf-http-wg list for some current discussions. Basically it clarifies the existing Link: headers and the result looks something like this:

Link: <http://example.com/TheBook/chapter2>; rel="previous"; title="previous chapter"

The Link: header itself is also extensible so we can faithfully represent our model by adding e.g. the local device name when linking storage and network resources to compute resources and other requisite attributes. It would be helpful if the content-type were also specified (Atom allows for multiple links of the same relation provided the content-type differs for example) but language is already covered by HTTP (it doesn't seem useful to advertise French links to someone who already asked to speak English).

It's also interesting to note that earlier versions of the HTTP RFCs actually [poorly] specified both the Link: headers as well as LINK and UNLINK methods for maintaining links between web resources. John Pritchard had a crack at clarification in the Efficient HyperLink Maintenance for HTTP I-D but like most I-Ds this one seems to have died after 6 months, and with it the methods themselves. It seems to me that adding HTTP methods at this time is a drastic (and almost certainly infeasible) action, especially for something that could just as easily be accomplished via headers ala Set-Cookie: (too bad the I-D doesn't specify how to add/delete/modify links!). In the simplest sense a Link: header appearing in a PUT or POST could replace the existing one(s) but something more elegant for acting on individual links would be nice - probably a discussion worth having on the ietf-http-wg list.

Organisation of Information

Looking back to Atom for a second we're still missing some key functionality:

• Atom id -> HTTP URL
• Atom updated -> HTTP Last-Modified: Header
  
• Atom title and summary -> Atom/HTTP Slug: Header or equivalent
• Atom link -> HTTP Link: Header
• Atom category -> ???
  

Houston, we have a problem. OCCI use cases range from embedded hypervisors exposing a single resource to a single entry-point for an entire enterprise or the "Great Global Grid" - we need a way to organise, categories and search for the information, likely including:

• Free text search via a Google-style "?q=firewall" syntax
• Taxonomy via categories (already done for Atom) for things like "Operating System" and "Data Center"
  
• Folksonomy via [user] tags (already done for Atom and bearing in mind that tag spaces are cool) for things like "testlab"

Fortunately the good work already done in this area for Atom would be realatively easy to port to a Category: HTTP header, following the Link: header example above. In the mean time a standard search interface (including category support) is trivial and thanks to Google, already done.

Structured Data Formats

HTML also resolves another pressing issue - what format to use for submitting key-value pairs (which constitutes a large part of what we need to do with OCCI). It gives us two options:

• application/x-www-form-encoded which is simple but quickly gets messy with encoding and non-ASCII characters
  
• multipart/form-data which is less efficient but will handle pretty much whatever you throw at it (including large files)

The advantages of being able to create a resource from a web form simply by POSTing to the collection of resources (e.g. http://example.com/compute), and with HTML 5 by PUTting the resource in place directly (e.g. http://example.com/compute/<uuid>) are immediately obvious. Not only does this help make the human and programmable web one and the same (which in turn makes it much easier for developers/users to kick the tyres and understand the API) but it means that scripting even advanced tasks with curl/wget would be trivial. Plus there's no place for time-wasting religious arguments about angle brackets (XML) over curly braces (JSON).

RESTful State Machines

Something else which has not sat well with me until I spent the weekend ingesting RESTful Web Services book (by Leonard Richardson and Sam Ruby) was the "actuator" concept we picked up from the Sun Cloud APIs. This breaks away from RESTful principles by exposing an RPC-style API for triggering state changes (e.g. start, stop, restart). Granted it's an improvement on the alternative (GETting a resource and PUTting it back with an updated state) as Tim Bray explains in RESTful Casuistry (to which Roy Fielding and Bill de hÓra also responded), but it still "feels funky". Sure it doesn't make any sense to try to "force" a monitored status to some other value (for example setting a "state" attribute to "running"), especially when we can't be sure that's the state we'll get to (maybe there will be an error or the transition will be dependent on some outcome over which we have no control). Similarly it doesn't make much sense to treat states as nouns, for example adding a "running" state to a collection of states (even if a resource can be "running" and "backing up" concurrently). But is using URLs as "buttons" representing verbs/transitions the best answer?

What makes more sense [to me] is to request a transition and check back for updates (e.g. by polling or HTTP server push). If it's RESTful to POST comments to an article (which in addition to its own contents acts as a collection of zero or more comments) then POSTing a request to change state to a [sub]resource also makes sense. As a bonus these can be parametrised (for example a "resize" request can be accompanied with a "size" parameter and a "stop" request sent with clarification as to whether an "ACPI Off" or "Pull Cord" is required). Transitions that take a while, like "format" on a storage resource, can simply return HTTP 201 Accepted so we've got support for asynchronous actions as well - indeed some requests (e.g. "backup") may not even be started immediately. We may also want to consider using something like Post Once Exactly (POE) to ensure that requests like "restart" aren't executed repeatedly and that we can cancel requests that the system hasn't had a chance to deal with yet.

Exactly how this should look in terms of URL layout I'm not sure (perhaps http://example.com/<resource>/requests) but being able to enumerate the possible actions as well as acceptable parameters (e.g. an enum for variations on "stop" or a range for "resize") would be particularly useful for clients.

Collections

This is all well and good for individual resources, but collections are still a serious problem. There are many use cases which involve retrieving an arbitrarily large number of resources and making a HTTP request for each (as well as requests for enumeration etc.) doesn't make sense. More importantly, it doesn't scale - particularly in enterprise environments where requests via proxies and filters can suffer from high latency (if not low bandwidth).

One potential solution is to strap multiple HTTP message entities together as a multipart document, but that's hardly clean and results in some hairy coding on the client side (e.g. manual manipulation of HTTP messages that would otherwise be fully automated). The best solution we currently have for this problem (as evidenced by widespread deployment) is AtomPub so I'm still fairly sure it's going to have to make an appearance somewhere, even if it doesn't wrap all of the resources by default.

Is AtomPub already the HTTP of cloud computing?

A couple of weeks ago I asked Is OCCI the HTTP of cloud computing? I explained the limitations of HTTP in this context, which basically stem from the fact that the payloads it transfers are opaque. That's fine when they're [X]HTML because you can express links between resources within the resources themselves, but what about when they're some other format - like OVF describing a virtual machine as may well be the case for OCCI? If I want to link between a virtual machine and its network(s) and/or storage device(s) then I'm out of luck... I need to either find an existing meta-model or roll my own from scratch.

That's where Atom (or more specifically, AtomPub) comes in... in the simplest sense it adds a light, RESTful XML layer to HTTP which you can extend as necessary. It provides for collections (a 'feed' of multiple resources or 'entries' in a single HTTP message) as well as a simple meta-model for linking between resources, categorising them, etc. It also gives some metadata relating to unique identifiers, authors/contributors, caching information, etc., much of which can be derived from HTTP (e.g. URL <-> Atom ID, Last-Modified <-> updated).

Although it was designed with syndication in mind, it is a very good fit for creating APIs, as evidenced by its extensive use in:

• Google's GData
• Microsoft's Live Services
• IBM's Lotus Connections
• SalesForce.com's Google Apps Integration
  

I'd explain in more detail but Mohanaraj Gopala Krishnan has done a great job already in his AtomPub, Beyond Blogs presentation:

The only question that remains is whether or not this is the best we can do... stay tuned for the answer. The biggest players in cloud computing seem to think so (except Amazon, whose APIs predate Google's and Microsoft's) but maybe there's an even simpler approach that's been sitting right under our noses the whole time.

Bragging rights: Valeo's 30,000 Google Apps users announced

It's been a long time in coming but I can finally tell you all about what originally brought me to France. Back in 2007 as a strategic consultant I designed, delivered and demonstrated a proof of concept of a complete cloud computing user environment (before it was even called cloud computing) to Valeo in a competitive tender, before handing over to CapGemini for deployment later that year.

What's particularly noteworthy (aside from the sheer scale) is that while many cloud computing deployments are tactical, with a view to reaching a specific goal (e.g. mail scanning, web security, shared calendaring, video hosting, etc.), this one was a high level strategy to replace as much of the existing infrastructure as possible. I also installed three Google Search Appliances as part of the solution and integrated same with a complex Active Directory and Lotus Notes infrastructure.

Granted this hasn't been a big secret for a while now but it's the first time the full details have officially emerged. Sergey Brin first bragged about it on Google's Q2 earnings call last year while talking about Google Apps' successes:

Just to give you color on what some of these businesses include, in this past quarter Valeo, one of the world’s leading automotive suppliers now has 32,000 users using Google Apps, including of course Gmail, Calendar, Docs and so forth.

Congratulations to everyone at CapGemini, Google and of course Valeo for making this a success.

Valeo launches an innovative initiative with Google to reduce administrative expenses
Wednesday, 13 May 2009

Valeo today announced that the Group's 30,000 Internet-connected employees now have access to a new communication and collaborative working platform based on Google Apps Premier Edition and supported by Capgemini.

The progressive roll-out of the new system is giving employees access to a suite of online products which will increase administrative efficiency and improve collaboration between the 193 Valeo entities in 27 countries.

"We were searching for an innovative way to reduce significantly our office infrastructure costs while simultaneously improving user collaboration and productivity," said André Gold, Valeo's Technical Senior Vice-President. "Our pilot projects demonstrate that this target is achievable."

Valeo is deploying Google Apps, supported by Google’s partner Capgemini, in a phased approach throughout 2009. As a first step, users are being given access to Google sites, on-line documents, video management and instant messaging, including voice and video chat, in order to improve teamwork. The new system will then offer applications to further enhance the company's efficiency, such as an Enterprise directory and workflow tools to automate administrative processes. In the final stage, users will benefit from Google mail, calendar, search and on-line translation solutions to reinforce personal efficiency. They will be able to access the applications from a desktop, laptop or other mobile device.

"The cost savings and innovation made possible by cloud computing help businesses better respond to a global and mobile workforce – especially in today's difficult economic environment," said Dave Girouard, President, Google Enterprise. "We're thrilled Valeo has selected Google."

Valeo is an independent industrial Group fully focused on the design, production and sale of components, integrated systems and modules for cars and trucks. Valeo ranks among the world's top automotive suppliers. The Group has 122 plants, 61 R&D centers, 10 distribution platforms and employs around 49,000 people in 27 countries worldwide.

For additional information, please contact:
Antoine Balas, Valeo Corporate Communications, Tel.: +33.1.40.55.29.36
Malgosia Rigoli, Corporate Communications, Google Enterprise EMEA, Tel.: +44207881 4537, malgosia@google.com

For more information about the Group and its activities, please visit our web site www.valeo.com

Update 1: Google France's Laurent Guiraud (who worked closely with me on the proof of concept and who I have to thank for most of what I know about the Google Search Appliance) has written about it on the Official Google Blog: 30,000 new Google Apps business users at Valeo.

Update 2: The story is now featured on the Official Google Enterprise Blog as well.

Update 3: Said to be Google's "biggest enterprise deal yet".

Update 4: ReadWriteWeb have picked up the story: Google Apps Continues Push Into Enterprise: 30,000 New Users at Valeo.

Update 5: So have TechCrunchIT: Google Cloud:1. MS Office: 0. 

Update 6: ComputerWeekly report Google Apps gets first global customer

Update 7: BusinessWeek talk about it while asking What's Holding Back Google Apps?

Update 8: InfoWeek report that Google's Cloud Evangelism Converts Enterprise Customers

Update 9: The Register (incorrectly) report that "Cap Gemini has sold what it believes is the largest ever contract for Google's online suite of software products", only the deal was as good as done by the time they got it.

Update 10: Computer Business Review writes Google secures biggest ever apps contract

Update 11: CNET states With Valeo deal, Google Apps gains business cred

Is OCCI the HTTP of Cloud Computing?

The Web is built on the Hypertext Transfer Protocol (HTTP), a client-server protocol that simply allows client user agents to retrieve and manipulate resources stored on a server. It follows that a single protocol could prove similarly critical for Cloud Computing, but what would that protocol look like?

The first place to look for the answer is limitations in HTTP itself. For a start the protocol doesn't care about the payload it carries (beyond its Internet media type, such as text/html), which doesn't bode well for realising the vision of the [Semantic] Web as a "universal medium for the exchange of data". Surely it should be possible to add some structure to that data in the simplest way possible, without having to resort to carrying complex, opaque file formats (as is the case today)?

Ideally any such scaffolding added would be as light as possible, providing key attributes common to all objects (such as updated time) as well as basic metadata such as contributors, categories, tags and links to alternative versions. The entire web is built on hyperlinks so it follows that the ability to link between resources would be key, and these links should be flexible such that we can describe relationships in some amount of detail. The protocol would also be capable of carrying opaque payloads (as HTTP does today) and for bonus points transparent ones that the server can seamlessly understand too.

Like HTTP this protocol would not impose restrictions on the type of data it could carry but it would be seamlessly (and safely) extensible so as to support everything from contacts to contracts, biographies to books (or entire libraries!). Messages should be able to be serialised for storage and/or queuing as well as signed and/or encrypted to ensure security. Furthermore, despite significant performance improvements introduced in HTTP 1.1 it would need to be able to stream many (possibly millions) of objects as efficiently as possible in a single request too. Already we're asking a lot from something that must be extremely simple and easy to understand.

XML

It doesn't take a rocket scientist to work out that this "new" protocol is going to be XML based, building on top of HTTP in order to take advantage of the extensive existing infrastructure. Those of us who know even a little about XML will be ready to point out that the "X" in XML means "eXtensible" so we need to be specific as to the schema for this assertion to mean anything. This is where things get interesting. We could of course go down the WS-* route and try to write our own but surely someone else has crossed this bridge before - after all, organising and manipulating objects is one of the primary tasks for computers.

Who better to turn to for inspiration than a company whose mission it is to "organize the world's information and make it universally accessible and useful", Google. They use a single protocol for almost all of their APIs, GData, and while people don't bother to look under the hood (no doubt thanks to the myriad client libraries made available under the permissive Apache 2.0 license), when you do you may be surprised at what you find: everything from contacts to calendar items, and pictures to videos is a feed (with some extensions for things like searching and caching).

OCCI

Enter the OGF's Open Cloud Computing Interface (OCCI) whose (initial) goal it is to provide an extensible interface to Cloud Infrastructure Services (IaaS). To do so it needs to allow clients to enumerate and manipulate an arbitrary number of server side "resources" (from one to many millions) all via a single entry point. These compute, network and storage resources need to be able to be created, retrieved, updated and deleted (CRUD) and links need to be able to be formed between them (e.g. virtual machines linking to storage devices and network interfaces). It is also necessary to manage state (start, stop, restart) and retrieve performance and billing information, among other things.

The OCCI working group basically has two options now in order to deliver an implementable draft this month as promised: follow Amazon or follow Google (the whole while keeping an eye on other players including Sun and VMware). Amazon use a simple but sprawling XML based API with a PHP style flat namespace and while there is growing momentum around it, it's not without its problems. Not only do I have my doubts about its scalability outside of a public cloud environment (calls like 'DescribeImages' would certainly choke with anything more than a modest number of objects and we're talking about potentially millions) but there are a raft of intellectual property issues as well:

• Copyrights (specifically section 3.3 of the Amazon Software License) prevent the use of Amazon's "open source" clients with anything other than Amazon's own services.
  
• Patents pending like #20070156842 cover the Amazon Web Services APIs and we know that Amazon have been known to use patents offensively against competitors.
  
• Trademarks like #3346899 prevent us from even referring to the Amazon APIs by name.
  

While I wish the guys at Eucalyptus and Canonical well and don't have a bad word to say about Amazon Web Services, this is something I would be bearing in mind while actively seeking alternatives, especially as Amazon haven't worked out whether the interfaces are IP they should protect. Even if these issues were resolved via royalty free licensing it would be very hard as a single vendor to compete with truly open standards (RFC 4287: Atom Syndication Format and RFC 5023: Atom Publishing Protocol) which were developed at IETF by the community based on loose consensus and running code.

So what does all this have to do with an API for Cloud Infrastructure Services (IaaS)? In order to facilitate future extension my initial designs for OCCI have been as modular as possible. In fact the core protocol is completely generic, describing how to connect to a single entry point, authenticate, search, create, retrieve, update and delete resources, etc. all using existing standards including HTTP, TLS, OAuth and Atom. On top of this are extensions for compute, network and storage resources as well as state control (start, stop, restart), billing, performance, etc. in much the same way as Google have extensions for different data types (e.g. contacts vs YouTube movies).

Simply by standardising at this level OCCI may well become the HTTP of Cloud Computing.

Apple iPad to be Steve Jobs' welcome back gift?

You may recall the Crystal Ball: Apple's $599 "iPad Touch" Netbook (with pictures) article last year in which I mocked up the forthcoming Apple iPad. Although it turns out I wasn't the first with this idea (further proof it's got legs) I wasn't the last either, with the Wall Street Journal claiming that "people privy to the company's strategy say Apple is working on new iPhone models and a portable device that is smaller than its current laptop computers but bigger than the iPhone or iPod Touch" in Jobs Maintains Grip at Apple. Add to that the mysterious 10-inch touchscreen order and you arrive at something not too far from what you see above.

When will all this happen? Well Steve Jobs is due back in June, coincidentally the same time as the Worldwide Developer Conference (WWDC) 2009 which runs June 8-12 in San Francisco. In addition to Snow Leopard then it looks like us Mac junkies will have a[t least one] new toy to play with. This is great news even if only because while surfing the Internet on the iPhone is possible, it's hardly pleasurable.