-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Migration
"Utilities and other entities frequently change their organizational structures,"
"frequently change" is not particularly helpful. You're designing the system to facilitate service organizational restructuring to split or merge domains. Or is it only merge/move? This design only seems to account for moving and merging. There is no splitting mentioned. What is the expected behavior of a redirect when there's a choice? Is that 301 instead of 302? We wouldn't want to require location-based routing.
Editorial
reference still present. Thanks for changing to RFC3339.
Coverage Entry Types 🔗
Accessibility faux pas. Links should surround the describing text.
e.g.
These abbreviations should be followed by a ,
" if a coverage entry object requires cookie-based authentication to access, then and linked the GeoJSON object"
then and? What does that mean?
"Server metedata is provided"
metadata
"Many utilities have"
Weasel words. Use "to account for the case"
" the utility itselfis"
itself is
"An entity that provides customer, utilty,"
utility
"redirected to the overriding."
The overriding what?
" utility or other entity"
Isn't "utility or entity" as previously noted.
"Servers MUST offer
S256and MUST NOT offerplaincode verifier methods."
Deleted. What happened? "Contain a union" doesn't rule out "plain".
Self-referential with "code_challenge_methods_supported"
"notificatiosn"
Spelling
"this field value is and empty list (
[])."
In code_challenge_methods_supported section. This "is" seems like it needs MUST normative language.