OASIS Open Services for Lifecycle Collaboration (OSLC) Open Project (OP) would like to submit the following registration request:
Header field name: OSLC-Core-Version
Applicable protocol: http (RFC 2616 and its successors)
standard (Project Specification 01 as per OASIS classification, has all the statements from the implementers to progress to the Candidate OASIS Standards once PS02 is published with the changes related to this registration request)
OASIS (can be Chet Ensign or the OASIS OSLC OP Project Governing Board (PGB) itself)
(§4.2, Part 1, approved Project Specification 01)
(latest draft that will have to be voted on again once this registration request has been considered by IETF,
contains ABNF as per the registration requirements)
(spec that introduced the header)
OSLC-Core-Version header has been in active use by OSLC implementations since 2009.
This submission is made in preparation to progressing OSLC Core specification to the OASIS Standard stage (currently Project Specification stage has passed and Candidate OASIS Specification stage is next).
Answers to the considerations in
1) Field is a single value.
2) The field can be used for both requests and responses; the spec defines the expected behaviour.
3) The header is not to be stored by the origin servers on PUT requests.
4) The semantics of the header only depend on whether a server or a client is sending it.
5) The header field is not hop-by-hop.
6) Intermediaries between OSLC servers and OSLC clients shall not insert or alter this header unless they are themselves OSLC servers or OSLC clients.
7) Yes, the header may be listed in the Vary header because the server may serve different content depending on the OSLC-Core-Version capability of the client.
8) No, the header is not generated dynamically and is not useful as a chunked trailer.
9) Yes, the header is to be preserved across redirects.
10) No private data is disclosed in the header. No security implications arise from this header alone as it only guides clients and servers on the version of the high-level protocol and is independent of the protocols that constitute a larger attack surface
such as HTTP, TLS, oAuth. The attacker may infer from a value of a header that a certain feature is not supported by an old client or server (e.g. OSLC 2 uses oAuth 1.0 and OSLC 3 recommends OIDC 1.0). The attacker may also indirectly try to guess that an
old client or server may run old software such as JDK 7 and use insecure settings due to a lack of new TLS version support etc. We don't think, however, that this header introduces any significant information for the attacked they could not gather on their
Thank you kindly for your time and the consideration of our application.
OSLC OP PGB co-chair
Ietf-message-headers mailing list