Original text:
8.1. Instead of sending an resource-access-rights, access rights MAY be <del> communicated as a string known to the AS or RS representing the access being requested.  Each string SHOULD correspond to a specific expanded object representation at the AS. </del>  This value is opaque to the client instance and MAY be any valid JSON string, and therefore could include spaces, unicode characters, and not easily confused by a developer, such as by limiting the strings to easily disambiguated characters.  This functionality is similar in practice to OAuth 2.0's "scope" parameter RFC6749, where a single string represents the set of access rights requested by the client instance.  As such, the reference

Reviewer comments:
Removes the normative suggestion that access right string values be always expandable to objects, but instead adds an example of one way to do it.
To edit notification comments on pull requests, go to your .
We say: But then we give examples like "some other thing" that clearly do not correspond to anything. We also don't specify any kind of semantics, such as if I request the reference string, I might get back the expanded access right representation. I suggest to remove or weaken that sentence:
I don't see a reason for it not being a SHOULD -- it provides guidance to API developers that the strings a short-hand for the expanded objects. And since it's only a SHOULD, the AS is still free to treat it differently.
No, this would be a MAY. With a SHOULD, you're supposed to have a good, documented reason to do something else. Quoting the original, may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. If we keep the SHOULD, our examples in the text should reflect that.
Probably we could improve the examples. But as an implementer, I wouldn't understand what you mean by MAY. Because then it suggests there can be reasonable alternatives to something known to the AS, which I don't think we have.
NAME I've proposed a change to the text in question in . Also, please note that the example string of is intended to be an actual value, with spaces and all. If it's not clear that this is a real and valid value in this context, please suggest an alternative that might fit here. We don't want people to assume that it has the same restrictions as OAuth scopes (which can't have spaces).

Revised text:
8.1. Instead of sending an resource-access-rights, access rights MAY be  <ins> communicated as a string known to the AS representing the access being requested.  Just like access rights communicated as an object, access rights communicated as reference strings indicate a specific access at a protected resource.  In the following non-normative example, three distinct resource access rights are being requested. </ins> This value is opaque to the client instance and MAY be any valid JSON string, and therefore could include spaces, unicode characters, and not easily confused by a developer, such as by limiting the strings to easily disambiguated characters. <ins> In order to facilitate the use of both object and reference strings to access the same kind of APIs, the API designer can define a clear mapping between these forms.  One possible approach for choosing reference string values is to use the same value as the "type" parameter from the fully-specified object, with the API defining a set of default behaviors in this case.  For example, an API definition could declare the following string: As being equivalent to the following fully-defined object: The exact mechanisms for relating reference strings is up to the API designer.  These are enforced by the AS, and the details are out of scope for this specification. </ins> This functionality is similar in practice to OAuth 2.0's "scope" parameter RFC6749, where a single string represents the set of access rights requested by the client instance.  As such, the reference