[Ietf-message-headers] OSLC-Core-Version header registration request

[Andrii Berezovskyi <[e-mail]>]

Hello,

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)

Status:
    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)

Author/Change controller:
    OASIS (can be Chet Ensign or the OASIS OSLC OP Project Governing Board (PGB) itself)

Specification document(s):
    https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-core.html (§4.2, Part 1, approved Project Specification 01)
    https://oslc-op.github.io/oslc-specs/specs/core/oslc-core.html (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)
    https://archive.open-services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning (spec that introduced the header)

Related information:
    OSLC-Core-Version header has been in active use by OSLC implementations since 2009.
    https://github.com/oslc-op/oslc-specs/issues/459
    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 https://tools.ietf.org/html/rfc7231#section-8.3:

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 own. 

Thank you kindly for your time and the consideration of our application.

Best regards,
Andrew Berezovskyi

OSLC OP PGB co-chair