[occi-wg] Agenda for OCCI TelCo tomorrow 18h (RFC 6648)
Gary Mazz
garymazzaferro at gmail.com
Mon Sep 3 21:31:11 EDT 2012
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>
More information about the occi-wg
mailing list