Alexis, Agreed. Gary that's an incredible amount of bureaucracy you've managed to squeeze into one email, and all over a debate as to which side of the CRLF character the metadata belongs on (following a religious war over <> vs {} no less). At this stage finishing the document must be our number one priority (having just watched our final deadline sail by with OGF 27) and reverting anything (in this case months of my work) cannot be considered going forward however you look at it. If I understand well you have implemented an ancient version of the spec in a commercial product and will stop at nothing to prevent *any* changes being made, despite my having discussed this issue at length both on- and off-list starting August/September. Conversely, as a representative of end users I assure you I have no agenda beyond releasing the highest quality protocol possible in a timely fashion so as to remain relevant (something we are already struggling with <http://twitter.com/littleidea/status/4979754002>). How about we focus on the technical merits of the alternative(s)? HTTP provides a perfectly good metadata channel that is *extremely* well tested (claims to the contrary are FUD, per above) and means we can delicately sidestep the entire issue of creating our own representations (with the associated interoperability problems and the additional cost of having to implement multiple formats). Bear in mind that there are existing (generally open) standards for representations of everything from virtual machines to calendar entries and users can choose the most appropriate for the task - if we stray in-band then we'll need to do work for each and every object that we ever intend to represent (note that HTTP does no such thing). Sam On Mon, Oct 19, 2009 at 6:21 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
Gary
Thanks. That strikes me as a fairly complex process.
Does anyone have any alternative suggestions? We need a simple model for reaching consensus here, that grows the community and adoption.
alexis
Alexis,
I do not believe we can set aside the OGF27 unapproved unilateral change to the document. It is a fundamental problem in operation.
These are my suggestions:
1) Place the document in a format where each interface can have its own
cycle. 2) Create a template for adjunct documents 3) Limit check-in to the repository to two people and one backup. 4) Recruit an editor and a backup editor. This spec isn't that big. 5) Provide an incubator for emerging technologies and proposals for inclusion in the specification. 6) Form a public mailing list purposed for emerging technologies,
discussions and voting 7) Provide a proposal document number for each submitted document 8) Before the document can be considered for review, it must be in the adjunct documents template
-gary
Alexis Richardson wrote:
Leaving aside the when and how in relation to OGF 27 specifically, we cannot claim that unilateral changes are supported by the group if they are not supported by the group. I am very concerned about this. We of course don't want to ignore innovative proposals, but we need to build consensus around them before inclusion in the spec.
Suggestions for a good way forward are solicited..
alexis
On Mon, Oct 19, 2009 at 4:19 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
That is a good point, a better question would be how did it get into
spec presented like it was the preferred method. Probably because there is no single editor and anyone can change the documents anyway they feel fit.
I don't think what Sam is working on is out of scope for OCCI, it was unintended to support multiple interfaces. Sam seems to be running with this one, driving OCCI to the lowest level of the HTTP protocols, essentially creating a new technology, untried on multiple levels in the internet infrastructure.
My issue with it is it was placed in the spec at the last second before OGF 27, other implementations were remove in lieu of this one, it was
in the spec irrespective of a group consensus and SNIA, a strategic
publicly announcing they would NOT support this interface. However,
does not preclude the rest of this group to continue with the original concept of OCCI information in HTTP entities (content body). For maintainability, this does force the document to take on a new
On Mon, Oct 19, 2009 at 5:10 PM, Gary Mazz <garymazzaferro@gmail.com> wrote: life proposal the placed partner, this format
of separating the implementations from reference model (we need one first). Interface implementations should fall into adjunct documents. This specification model has been successfully executed by numerous standards bodies.
cheers,
Gary
Alexis Richardson wrote:
Sam & group,
I just saw this tweet: http://twitter.com/samj/statuses/4991958514
You say that "HTTP has an out-of-band metadata channel in the form of headers. #occi's using Link: as a flexible, lightweight RDF alternative".
I'm a bit confused here.... I thought this was still under discussion. What am I missing?
alexis _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg