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

[Andre Merzky]

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...