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

"SHOULD" vs "should" #412

Open
jernst opened this issue Jan 7, 2024 · 6 comments
Open

"SHOULD" vs "should" #412

jernst opened this issue Jan 7, 2024 · 6 comments
Assignees
Labels
Next version Normative change, requires new version of spec

Comments

@jernst
Copy link

jernst commented Jan 7, 2024

This is a bit nitpicky, but "SHOULD" is part of the controlled vocabulary for the spec, and thus spelled in uppercase.

There are many places in the spec where the lower-case "should" is used instead.

Probably a distinction without an intended difference, but confusing.

Example from section 3 where the two are used right next to each other.

Servers SHOULD validate the content they receive to avoid content spoofing attacks. (A server should do something at least as robust as checking that the object appears as received at its origin, but mechanisms such as checking signatures would be better if available).

A similar comment can be made about "shall" and perhaps other terms like it.

@nightpool
Copy link
Collaborator

When used in uppercase, SHOULD creates a new conformance requirement for servers to follow. When used in lowercase, it's just a normal english word and should be interpreted as such. For example, in the section you quote, the parenthetical is simply elaborating on the "SHOULD validate" requirement, not creating a brand new requirement on its own)

@TallTed
Copy link
Member

TallTed commented Jan 8, 2024

Widespread confusion persists about how to interpret the lowercase "should", even with the RFC 2119 and RFC 8174 citations early in the spec.

Contrary to what is found in those RFCs, best practice today is to avoid use of the lowercase "should", etc., and to use different wording to get the intended meaning across, e.g., to change A server should do something... to A server is expected to do something....

@evanp evanp self-assigned this Jan 31, 2024
@evanp
Copy link
Collaborator

evanp commented Jan 31, 2024

All right. Thanks for bringing this up. I think the next step is to identify "should" lowercase and determine if they are intended to be normative and ought to be "SHOULD" or if they are non-normative and ought to be converted to another phrased ("are expected to", etc.).

For each of these, I'll create an ERRATA entry.

I'm counting about 38 uses of "should". I think it's OK to exempt the ones in non-normative sections.

I see about 5 uses of "must", and about 40 uses of "may".

This seems like a big task. At worst, we're looking at about 83 ERRATA.md entries for text.

@evanp evanp added the Needs errata We need to add errata for this label Jan 31, 2024
@TallTed
Copy link
Member

TallTed commented Jan 31, 2024

I think it's OK to exempt the [uses of "should"] in non-normative sections.

It's OK, but I recommend not. Again, it is common for readers to read the lowercase "should" as the uppercase "SHOULD", even when encountered in non-normative sections. Often enough, it leads to readers thinking those sections (or at least, sub-sections) were erroneously labeled as non-normative.

This seems like a big task.

Yeah, it can be painful to make this transition. Fortunately, it's not so painful to maintain once existing docs are converted.

@nightpool
Copy link
Collaborator

I could see the benefit of addressing this in the editor's draft if we're working towards a new TR update, but I don't think it's worth errata, they would just be too numerous to be helpful.

@evanp evanp added the Next version Normative change, requires new version of spec label Dec 13, 2024
@evanp
Copy link
Collaborator

evanp commented Dec 13, 2024

Adding 83 errata for this is a lot. I am wiling to come back to this and find the most confusing, but I wonder if the best next step is to address this in a future version. I'm going to leave this ticket open, but I probably won't generate all the errata, at least for a while.

@evanp evanp removed the Needs errata We need to add errata for this label Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Next version Normative change, requires new version of spec
Projects
None yet
Development

No branches or pull requests

4 participants