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

[Andre Merzky]

Oy, this would only be relevant if the link wasn't included earlier in
the thread -- which it was.  Sorry for the noise.

Best, Andre.


On Tue, Sep 4, 2012 at 11:19 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:
> 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
>>>
>>
>>
>



-- 
Nothing is really difficult...