Subject: Registration request for the Configuration-Context field

From: Andrii Berezovskyi <[email-masked]>
Date: Thu, 14 Oct 2021 13:53:08 +0000

Dear experts,

OASIS Open Services for Lifecycle Collaboration (OSLC) Open Project (OP) would like to submit the following registration request:

Field name: Configuration-Context

Status:
    provisional (in active use since ca. 2009, OASIS OSLC Configuration Management specification is standards-track, standard status will be requested for the header once OASIS Standard version is reached for the specification)

Specification document(s):
    https://docs.oasis-open-projects.org/oslc-op/config/v1.0/psd01/config-resources.html#configcontext (ABNF definition in §4, Part 3; Project Specification Draft 01 approved by a vote on 2021-10-02)

Comments:
    https://github.com/oslc-op/oslc-specs/issues/144 for tracking this request on the OSLC side.

Answers to the considerations in https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.16.3.2 :

1) The header field is to be used for requests.
2) Field semantics do not change depending on context, the field itself defines a context.
3) The field expands the scope of request, the server may use it to determine which resource "version" to serve in response. The field does not affect content negotiation (OSLC is built on top of W3C RDF and W3C LDP specifications and fully supports content negotiation).
4) Intermediaries SHALL NOT modify or delete this field, it's inseparable from the request body. In rare cases, intermediaries (proxies) may set a default value for compatibility reasons.
5) This header is not useful in trailers.
6) The field does not affect the HTTP connection, no need to include it in the 'Connection' header.
7) The header does not introduce additional security considerations. However, its nature is to denote a context and it may be used to correlate the belonging of multiple resources to a single context.

Additional considerations for the request fields:

1) Yes, it makes sense to include this header in the Vary response header field.
2) Servers do not store the header on PUT requests. However, server PUT behavior may vary under different header values.
3) The header is ought to be preserved in redirects.

Thank you kindly for your time and the consideration of our application. The request was prepared in accordance with the instructions under https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#fields.registry 

Best regards,
Andrew Berezovskyi

OSLC OP PGB co-chair