Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
royfielding opened this issue Jul 2, 2018 · 8 comments

Comments

@royfielding
Copy link
Member

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
Copy link
Member

mnot commented Jul 2, 2018

SGTM

@duerst
Copy link

duerst commented Jul 10, 2018

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
Copy link
Contributor

+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
Copy link
Member

mnot commented Jul 10, 2018

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
Copy link
Contributor

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

@mcmanus
Copy link

mcmanus commented Jul 11, 2018

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

@MikeBishop
Copy link
Contributor

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
Copy link

duerst commented Jul 11, 2018

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

reschke added a commit that referenced this issue Jul 19, 2018
Define HTTP minor version number default (closes #115)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

6 participants