[occi-wg] confusion about status of link / headers
alexis.richardson at gmail.com
Mon Oct 19 11:21:05 CDT 2009
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.
On Mon, Oct 19, 2009 at 5:10 PM, Gary Mazz <garymazzaferro at gmail.com> wrote:
> 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
> 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
> 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..
>> On Mon, Oct 19, 2009 at 4:19 PM, Gary Mazz <garymazzaferro at gmail.com>
>>> 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
>>> no single editor and anyone can change the documents anyway they feel
>>> 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
>>> one, driving OCCI to the lowest level of the HTTP protocols, essentially
>>> creating a new technology, untried on multiple levels in the internet
>>> My issue with it is it was placed in the spec at the last second before
>>> 27, other implementations were remove in lieu of this one, it was placed
>>> 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
>>> separating the implementations from reference model (we need one
>>> Interface implementations should fall into adjunct documents. This
>>> specification model has been successfully executed by numerous standards
>>> 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
>>>> I'm a bit confused here.... I thought this was still under discussion.
>>>> What am I missing?
>>>> occi-wg mailing list
>>>> occi-wg at ogf.org
More information about the occi-wg