Agenda for OCCI TelCo tomorrow 18h
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
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
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
Relevant: http://tools.ietf.org/html/rfc6648 A. On Tue, Sep 4, 2012 at 3:31 AM, Gary Mazz <garymazzaferro@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@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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is really difficult...
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@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@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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
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@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@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@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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is really difficult...
Sorry, I cannot be with you for the confcall tonight. Interested in the last point in agenda, though... Bye Augusto Ciuffoletti 2012/9/3 Feldhaus, Florian <florian.feldhaus@gwdg.de>
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
-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)
participants (5)
-
Andre Merzky -
Andy Edmonds -
Augusto Ciuffoletti -
Feldhaus, Florian -
Gary Mazz