[occi-wg] confusion about status of link / headers

Mon Oct 19 11:51:45 CDT 2009

Guys,

I am interested in one thing only here -- a simple model for reaching
consensus here, that grows the community and adoption.

Once I have canvassed opinion on this I shall have a chat with the
other chairs about it.

I am NOT calling into question anyone's intentions or agenda.  I do
wish to AVOID discussion of specific technical points at this time.

alexis

On Mon, Oct 19, 2009 at 5:44 PM, Sam Johnston <samj at samj.net> wrote:
> 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 at 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 at 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 at 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 at ogf.org
>> >>>> http://www.ogf.org/mailman/listinfo/occi-wg
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
>