Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update intro to extensions section #515

Merged
merged 1 commit into from
Oct 23, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions draft-ietf-gnap-core-protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -7864,11 +7864,11 @@ Implementations conformant to the Secondary Device profile of GNAP MUST implemen
# Guidance for Extensions {#extensions}

Extensions to this specification have a variety of places to alter the protocol, including many
fields and objects that can have additional values in a [registry](#IANA) established by this
specification. Extensions that add new fields, especially to the grant request and response, should
endeavor to have any new fields be as orthogonal as possible to existing fields. That is to say,
if functionality is sufficiently close to an existing field, the extension should attempt to
use that field instead of defining a new one, in order to avoid confusion by developers.
fields and objects that can have additional values in a registry [registry](#IANA) established by this
specification. For interoperability and to preserve the security of the protocol, extensions should
register new values with IANA by following the specified mechanism. While it may technically be
possible to extend the protocol by adding elements to JSON objects that are not governed by an
IANA registry, a recipient may ignore such values but is also allowed to reject them.

Most object fields in GNAP are specified with types, and those types can allow different but
related behavior. For example, the `access` array can include either strings or objects, as
Expand Down
Loading