Closed berezovskyi closed 3 years ago
Template:
Header field name:
The name requested for the new header field. This MUST conform to
the header field specification details noted in Section 4.1.
Applicable protocol:
Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
"netnews" (RFC 1036), or cite any other standards-track RFC
defining the protocol with which the header is intended to be
used.
Status:
Specify "standard", "experimental", "informational", "historic",
"obsoleted", or some other appropriate value according to the type
and status of the primary document in which it is defined. For
non-IETF specifications, those formally approved by other
standards bodies should be labelled as "standard"; others may be
"informational" or "deprecated" depending on the reason for
registration.
Author/Change controller:
For Internet standards-track, state "IETF". For other open
standards, give the name of the publishing body (e.g., ANSI, ISO,
ITU, W3C, etc.). For other specifications, give the name, email
address, and organization name of the primary specification
author. A postal address, home page URI, telephone and fax
numbers may also be included.
Specification document(s):
Reference to document that specifies the header for use with the
indicated protocol, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant
sections MAY also be included, but is not required.
Related information:
Optionally, citations to additional documents containing further
relevant information. (This part of the registry may also be used
for IESG comments.) Where a primary specification refers to
another document for substantial technical detail, the referenced
document is usefully mentioned here.
Our submission:
Header field name: OSLC-Core-Version
Applicable protocol: "http" (RFC 2616 and newer)
Status: standard
Author/Change controller: OASIS Open
Specification document(s): https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-core.html (§4.2, Part 1) and https://archive.open-services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning
Related information: https://github.com/oslc-op/oslc-specs/issues/459
ABNF definition:
SP = " "
HTAB = %x09
WSP = SP / HTAB
DIGIT = %x30-39
header = oslc-version
oslc-version = "OSLC-Core-Version:" *WSP DIGIT "." DIGIT
checked with https://github.com/fenner/bap (you may use https://tools.ietf.org/tools/bap/abnf.cgi); definitions reused from https://docs.oasis-open.org/odata/odata/v4.01/os/abnf/odata-abnf-construction-rules.txt (cleaned up to remove unnecessary layers of abstraction)
@jamsden this ABNF is required for registration. I suggest we put it into the spec to avoid adding an Additional Artifact like oData did (they have a large ABNF file) in https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#ABNF
if someone knows how to test ABNF above with input, I will be very glad
OData version header definition for reference: https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#_Toc31358862
This is the email draft to https://mailarchive.ietf.org/arch/browse/ietf-message-headers/
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 newer)
Status: standard
Author/Change controller:
OASIS
Specification document(s):
https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-core.html (§4.2, Part 1)
https://archive.open-services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning
Related information:
https://github.com/oslc-op/oslc-specs/issues/459
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).
Best regards,
Andrew Berezovskyi
OSLC OP PGB co-chair
I think we should make a PR to add ABNF to the spec judging from the examples I saw on the mailing list.
ABNF shall be cited in the spec as https://tools.ietf.org/html/rfc5234. Example https://www.w3.org/TR/resource-timing-1/#timing-allow-origin
That ABNF doesn't admit multi-digit version parts, eg "43.4". Is that intentional?
Good catch, will fix!
ABNF was fixed in #474 and merged to master for the IETF reviewers to see the draft.
The request was submitted with the IETF https://mailarchive.ietf.org/arch/msg/ietf-message-headers/k3PGnmAAr6JyPCAJVrXIR7JYCQY/
Two weeks from now we should be able to proceed with an IANA application if no objections are received: https://tools.ietf.org/html/bcp90#section-4.3
No objections received over 2 weeks on the IETF list. The reg template was forwarded to IANA adminitrator today.
https://www.iana.org/assignments/message-headers/message-headers.xhtml
closing as complete
Requested a permanent registration via https://github.com/protocol-registries/http-fields/issues/30
Filed in connection with #458. I don't think we shall wait #144, Core spec is more mature and will allow us to get a faster allocation.
TODOs: