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

[Sam Johnston]

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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091019/ea53058d/attachment.html