W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

Re: Registration request for the Configuration-Context field

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 2 Dec 2021 10:25:26 +1100
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "oslc-op@lists.oasis-open-projects.org" <oslc-op@lists.oasis-open-projects.org>
Message-Id: <0874AFD5-D9C3-41C7-8C1D-8CBE3BA90075@mnot.net>
To: Andrii Berezovskyi <andriib@kth.se>
Hi Andrii,

That's fine, we can approve this as-is. In the future, feel free to request registration earlier in the process. See also:
  https://github.com/protocol-registries/http-fields

Cheers,
  

> On 2 Dec 2021, at 12:36 am, Andrii Berezovskyi <andriib@kth.se> wrote:
> 
> Hello Mark,
> 
> Thank you for getting back to us! 
> 
> OSLC-Configuration-Context was suggested in the ticket by me. Unfortunately, there are many applications in wide use today (e.g., IBM Jazz engineering tools) with many integrations developed that use the Configuration-Context already (since ca. 2009). In the end, I took my suggestion back.
> 
> I would like to kindly ask you to consider the possibility of proceeding with the examination of our application without changing the header name, please. If you insist on only going ahead with OSLC-Configuration-Context, we'd still need to register Configuration-Context provisionally for the foreseeable future to prevent potentially conflicting use by other protocols (at least until an RFC for the Configuration-Context header comes, I don't think I am in a position to take on that challenge now). This is because we will reword a MUST on the Configuration-Context header support to a MUST on the OSLC-Configuration-Context and add a SHOULD on the Configuration-Context header to maintain backward compatibility with all the existing implementations.
> 
> /Andrew
> 
>> On 2021-12-01, at 07:22, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> 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/
>> 
> 

--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 1 December 2021 23:25:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 1 December 2021 23:25:48 UTC