What protocol contains when a major version doesn't define a minor version

[royfielding]

HTTP defines its own protocol versions as having two numbers "major.minor" regardless of anyone's future opinions on the subject. This is necessary for Via and Upgrade. In the past, it has always been assumed that no document claiming to define a version of HTTP would ignore that fact. Regardless, HTTP/1.1 needs to refer to future versions of HTTP within the scope of its own syntax.

Hence, the following text (currently in crefs) has been suggested for the last paragraph of the section "Protocol Versioning" in Semantics.

When a major version of HTTP does not define any minor versions, the minor version "0" is implied and ought to be used when referring to that protocol within a protocol element that requires sending a minor version.

[mnot]

SGTM

[duerst]

Why "ought to be used"? I understand that you want to avoid MUST/SHOULD,..., but why not just "is used"? That would make it:

When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version.

[MikeBishop]

+1, let's limit the RFC6919 language. You're defining a mapping between formats, not really adding new normative or moral requirements. The "0" is simply how a major-only version is rendered in a major.minor field.

[mnot]

The background here is that we used 'ought' liberally in 723x (e.g., 49 times in 7231) to give implementers guidance towards good behaviour without affecting conformance for existing deployments.

So this is entirely in the spirit of the existing specifications.

[martinthomson]

That use is often appropriate. In this case, the conditions are such that "is" works. It is also more assertive, which works.

[mcmanus]

all: try and do your best to focus on the substance of the question rather than the editorial wrappings. Thanks.

[MikeBishop]

The substance of the question is obvious, in my opinion. I'd question whether there's a need for discussion on that.

However, the editorial wrappings do actually matter in having the final document communicate what we want it to communicate. It's feedback I'd typically give on a PR rather than the issue, but in this case the issue contains proposed text, so the editorial feedback is here too.

[duerst]

Agree with Mike. I came to this issue almost by chance, I thought it was important because Julian wrote a mail to the mailing list. When I had a look at the issue, the only thing that caught my eye was the "ought", because the substance is indeed obvious (at least to me).

If "ought" is used liberally in 723x, there may be good reasons for it, and in many places it may make sense. But I'd ask the editors to go through these 49++ times and see if it wouldn't be possible to replace some of them with "is". "is" just reads so much more easily where it's appropriate than "ought".