Re: [oslc-core] Proposal for HTTP header Configuration-Context (was: [oslc-core] Agenda for 15 May 2014)

[John Arwe <johnarwe@us.ibm.com>]

+1 for Configuration-Context over the OSLC-prefixed alternative,
assuming we keep it.

If "communicating the configuration
context to be used for the request" means that the header value is
a URI, then you might re-use the existing Link header instead [1].  A
very low overhead way to do so is to use your own URI as the link relation
type; that path requires zero interaction with IANA and IETF.  If
you want a "token" as a link relation type (e.g. configuration-context,
like meta, or type, [2]) then there is a registration process described
in [1] that nets out to IETF expert review via email.  If you go the
token path, fair warning that "context" has an existing meaning
in [1] so it's likely to cause at least some confusion; many of the tokens
in [2] contain 'context' in their description for that reason.

If you proceed with the original option
of minting a new header, *and* if OASIS is a standards body that IETF recognizes
(does not seem like a scary list [3] -> [4] but would need due diligence;
Chet might know if this has already a well-trodden path at the .org level),
there is a registration and review process similar to registering a link
relation type.  It might get a bit more scrutiny, but that's just
a feeling on my part from the LDP-related IETF work.  If OASIS does
not "count", you'd need an RFC in IETF as I read [3].




[1] http://tools.ietf.org/html/rfc5988
[2] http://www.iana.org/assignments/link-relations/link-relations.xml
[3] http://tools.ietf.org/html/rfc3864#section-4.3
[4]  http://tools.ietf.org/html/rfc2026#section-7
and http://tools.ietf.org/html/rfc2026#section-10

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead