Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-256 - -gnap - core - protocol - editors- 
 within ( and likely other sections ) , the property names are plural , but the text sometimes refers to the singular property names . This should be cleaned up to be consistent one way or another .
Paragraph (version A):
The focus of this protocol is to provide interopability between the
different parties acting in each role, and is not to specify
implementation details of each.  Where appropriate, GNAP may make
recommendations about internal implementation details, but these
recommendations are to ensure the security of the overall deployment
rather than to be prescriptive in the implementation.
Paragraph (version B):
The focus of this protocol is to provide interoperability between the
different parties acting in each role, and is not to specify
implementation details of each.  Where appropriate, GNAP may make
recommendations about internal implementation details, but these
recommendations are to ensure the security of the overall deployment
rather than to be prescriptive in the implementation.
Paragraph (version A):
This document contains non-normative examples of partial and complete
HTTP messages.  Some examples use a single trailing backslash '' to
indicate line wrapping for long values, as per RFC8792.  The "\"
character and leading spaces on wrapped lines are not part of the
value.
Paragraph (version B):
This document contains non-normative examples of partial and complete
HTTP messages, JSON structures, URLs, query components, keys, and
other elements.  Some examples use a single trailing backslash '' to
indicate line wrapping for long values, as per RFC8792.  The "\"
character and leading spaces on wrapped lines are not part of the
value.
Paragraph (version A):
Additional interaction modes are defined in IANA.
Paragraph (version B):
Additional interaction start modes, finish modes, and hints are
defined in IANA.
Paragraph (version A):
The access requested for a given object when using these fields is
the cross-product of all fields of the object.  That is to say, the
object represents a request for all "action" values listed within the
object to be used at all "location" values listed within the object
for all "datatype" values listed within the object.  Assuming the
request above was granted, the client instance could assume that it
would be able to do a "read" action against the "images" on the first
server as well as a "delete" action on the "metadata" of the second
server, or any other combination of these fields, using the same
access token.
Paragraph (version A):
To request a different combination of access, such as requesting one
"action" against one "location" and a different "action" against a
different "location", the client instance can include multiple
separate objects in the "resources" array.  The following non-
normative example uses the same fictitious "photo-api" type
definition to request a single access token with more specifically
targeted access rights by using two discrete objects within the
request.
Paragraph (version B):
The access requested for a given object when using these fields is
the cross-product of all fields of the object.  That is to say, the
object represents a request for all "actions" listed to be used at
all "locations" listed for all possible "datatypes" listed within the
object.  Assuming the request above was granted, the client instance
could assume that it would be able to do a "read" action against the
"images" on the first server as well as a "delete" action on the
"metadata" of the second server, or any other combination of these
fields, using the same access token.
Paragraph (version B):
To request a different combination of access, such as requesting one
of the possible "actions" against one of the possible "locations" and
a different choice of possible "actions" against a different one of
the possible "locations", the client instance can include multiple
separate objects in the "resources" array.  The following non-
normative example uses the same fictitious "photo-api" type
definition to request a single access token with more specifically
targeted access rights by using two discrete objects within the
request.
Paragraph (version A):
This functionality is similar in practice to OAuth 2's "scope"
parameter RFC6749, where a single string represents the set of access
rights requested by the client instance.  As such, the reference
string could contain any valid OAuth 2 scope value as in example-
oauth2.  Note that the reference string here is not bound to the same
character restrictions as in OAuth 2's "scope" definition.
Paragraph (version B):
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
string could contain any valid OAuth 2.0 scope value as in example-
oauth2.  Note that the reference string here is not bound to the same
character restrictions as in OAuth 2.0's "scope" definition.