Re: Registration request for the Configuration-Context field

Hi Andrii,

Apologies for the delay -- this got temporarily overlooked in the transition to a new registry.

My feedback (as one of the responsible experts for this registry) is that 'Configuration-Context' is a very generic name. Given that your use is in a specific application, it may make more sense to define a more specific name (e.g., 'OSLC-Configuation-Context', as I see someone suggested, or even 'OSLC-Config' or similar). 

If it's intended to be a general field for more applications than just OSLC, we encourage it to be documented in a separate specification, so that it's treated as a standalone artefact, rather than something tied to a specific protocol or application. 

How would you like to proceed?

Cheers,


> On 15 Oct 2021, at 12:53 am, Andrii Berezovskyi <andriib@kth.se> wrote:
> 
> 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
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 1 December 2021 06:23:10 UTC