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@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@ogf.org
https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/occi-wg