Confusing reference to RPT in Protection API context

[andihindle]

In §1.3.1, we have the following wording:

Note: When a client attempts access to a presumptively protected resource without an RPT, the
resource server needs to derive the authorization server and resource set identifier associated with that
resource from some other aspect of the client's request. This effectively means that the resource
server’s API needs to be structured in such a way that the client's RPT-free request uniquely identifies
the resource set. In practice, this information likely needs to be passed through the URI, headers, or
body of the request.

This is confusing, because §1.3.1 is all about the Protection API and the 'Protect a Resource' flow, but the note is about RPT/AAT flow. If you are reading the spec from top-to-bottom, with no particular foreknowledge of the spec, then the potential relevance of the RPT is entirely unclear.

Suggest the following alternative wording (edits in bold):

Note: as described in Section 3.2, if a client attempts access to a presumptively protected resource
without an RPT, the resource service may need to register the requested permission with the protection
API at the authorization servers. In order to do this, the resource server needs to derive the
authorization server and resource set identifier associated with that resource from some other aspect of
the client's request. This effectively means that the resource server’s API needs to be structured in
such a way that the client's RPT-free request uniquely identifies the resource set. In practice, this
information likely needs to be passed through the URI, headers, or body of the request.

[xmlgrrl]

In UMA ad hoc telecon 2015-09-08 (which had quorum), this was the discussion and conclusion:

"Andi’s new issue suggests seating the “presumptively protected resource” note more firmly into the Sec 1.3.1 context. Eve likes it so much that she suggests doing this with each of the instances.

Okay, let’s give her an editorial instruction to do so."