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).

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




On Mon, Oct 19, 2009 at 5:10 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
> 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 life
> 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, proposal
> 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 the
>>> 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 placed
>>> in
>>> the spec irrespective of a group consensus and SNIA, a strategic partner,
>>> publicly announcing they would NOT support this interface. However, this
>>> 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 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