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

[Gary Mazz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120903/bf79f268/attachment.html>