[occi-wg] Agenda for OCCI TelCo tomorrow 18h (RFC 6648)

[Gary Mazz]

Hi Andre,

Outside of the points made below, why is this relevant to OCCI ? If you 
can please join today's meeting.

cheers
gary


On 9/4/2012 2:23 AM, Andre Merzky wrote:
> Relevant:  http://tools.ietf.org/html/rfc6648
>
> A.
>
>
> On Tue, Sep 4, 2012 at 3:31 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:
>> Hi
>>
>> I want to open the first volley in the discussion, I have one a minute...
>> sorry for any typos and poor grammar.
>>
>> "Historically, designers and implementers of application protocols have
>> often distinguished between standardized and unstandardized parameters by
>> prefixing the names of unstandardized parameters with the string "X-" or
>> similar constructs (e.g., "x."), where the "X" is commonly understood to
>> stand for "eXperimental" or "eXtension". Under this convention, the name of
>> a parameter not only identified the data, but also embedded the status of
>> the parameter into the name itself: a parameter defined in a specification
>> produced by a recognized standards development organization (or registered
>> according to processes defined in such a specification) did not start with
>> "X-" or similar constructs, whereas a parameter defined outside such a
>> specification or process started with "X-" or similar constructs.
>>
>> In short, although in theory the "X-" convention was a good way to avoid
>> collisions (and attendant interoperability problems) between standardized
>> parameters and unstandardized parameters, in practice the benefits have been
>> outweighed by the costs associated with the leakage of unstandardized
>> parameters into the standards space."
>>
>>
>> This is a problem with the IETF's handling their own laundry. There is no
>> process or organization to guide the maturity of HTTP header labels.
>> Removing the "X-" nomenclature provides little technical value.  Removal may
>> appear to prematurely "legitimize" some applications by removing the
>> "experimental" branding from the application's protocols. Until, the IETF
>> can setup a formal registry (similar to  ICCAN and IANA guided by WIPO) to
>> "legitimize" http header definitions, this seems more like an exercise in
>> futility, not correcting any potential collisions of http header labels or
>> reconciling  the pedigree separating standardized http headers from the
>> experimental headers.
>>
>> Today, I see no direct value of RFC 6648 to OCCI. Until a formal registry is
>> created to "legitimize" http header definitions, the OCCI standard working
>> group can change HTTP header labels any time we want! Additionally since
>> most RFCs are not standards, a common belief is they are, we need to
>> classify non-standardized RFCs as advisements and recommendations under
>> discussion in some communities. I believe OCCI working groups participants
>> can remove any "X-" notation from OCCI http headers any time this group sees
>> it necessary.
>>
>> We should consider policy implications for future works and impact to other
>> OGF work products.
>>
>> b/r
>> Gary Mazzaferro
>>
>>
>> On 9/3/2012 3:24 PM, Andy Edmonds wrote:
>>
>> Let's include http://tools.ietf.org/html/rfc6648 into the agenda.
>>
>> On 3 Sep 2012, at 11:36, "Feldhaus, Florian" <florian.feldhaus at gwdg.de>
>> wrote:
>>
>> Hi all,
>>
>> to get a better attendance than last week, I would like to encourage
>> everyone to join the OCCI TelCo tomorrow. I would like to propose the
>> following agenda:
>> - JSON rendering
>> - Core updates
>> - OCCI and AMQP
>> - roadmap for publishing new OCCI documents
>>
>> Cheers,
>> Florian_______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg
>>
>
>