When URLs are used for payment method identifiers they MUST be absolute URLs including, at most, a scheme, host, port and path. The URL must be a potentially trustworthy URL as defined in the [SECURE-CONTEXTS] specification. Identifier URLs MUST have null query and fragment values.
The first thing that's odd here is that there are three uses of "must", but only 2 of them are marked up as RFC2119 "must"s (the middle one is not).
But the slightly larger point here is that it's imposing a normative requirement on a URL. While RFC2119 does allow this, what I see as modern Web specification style, described well in a blog post Hixie wrote in 2006 tends to avoid this usage of "must".
In particular, it's seen as preferable to either:
turn these musts into a definition, by excluding URLs that don't meet these requirements from the definition, and then elsewhere using that definition to write other conformance requirements that apply to user agents or content producers (I suspect this is the best choice here)
turn these musts into conformance requirements that apply to the actions of a particular party, e.g., that a user agent must ignore URLs that don't meet these requirements in a certain context
marcoscaceres
commented
7 years ago
The section on Syntax of URLs as Payment Method Identifiers currently says:
The first thing that's odd here is that there are three uses of "must", but only 2 of them are marked up as RFC2119 "must"s (the middle one is not).
But the slightly larger point here is that it's imposing a normative requirement on a URL. While RFC2119 does allow this, what I see as modern Web specification style, described well in a blog post Hixie wrote in 2006 tends to avoid this usage of "must".
In particular, it's seen as preferable to either:
(I got here from https://github.com/w3ctag/spec-reviews/issues/152.)