Afnic

7 avenue du 8 mai 1945 Guyancourt 78280 FR bortzmeyer+ietf@nic.fr https://www.afnic.fr/

General Internet Engineering Task Force JSON RPP This document proposes a lightweight convention for namespaces in the JSON payloads of RPP: a registry of namespaces plus the convention to write JSON names as namespace.shortname. It is not intended to be published as a RFC, just to stir discussion.

Introduction In the current discussions about RPP (RESTful Provisioning Protocol, see ), there has been a lot of talk about the extensibility of the protocol (see section 13 of the above draft). One of the issues raised by this requirment of extensibility is the fact that JSON (), unlike XML, has no concept of namespaces. In the JSON world, the common way to introduce new members in objects is for the receiver to ignore unknown members (section 7 of the above draft makes that a requirment, see the "strict vs. lenient" discussion). This allows future extensions but, for a provisioning protocol, it is annoying since it means that requests from the client will be partially and silently ignored. Also, the lack of namespaces can create collisions between two extensions using the same name. As an example, if we have this payload describing a contact: { "name": "John Foobar", "date-of-birth": "2025-05-30", "country": "ZZ" } What if we want to extend RPP to add the fact that John Foobar is a physical person, for instance for compliance with data privacy regulations that apply only to physical persons, like the GDPR? { "name": "John Foobar", "date-of-birth": "2025-05-30", "country": "ZZ", "is-a-physical-person": true } How the "is-a-physical-person" member be marked and processed? There have been a lot of proposals to add some form of namespaces in JSON, often as part as an effort to design a schema language for JSON. In the IETF world, see for instance JMAP (), which uses URIs to indicate extensions. Another proposal was , using also URIs. But none has caught, in the sense of being widely recognized as a good way to create namespaces in JSON. For this document, the requirments are:

• Do not try to solve the general problem, a RPP-specific solution is fine, using existing IETF infrastructure such as an IANA registry.
• Ergonomy (ease of typing) is not mandatory (we won't write the JSON manually) but nice (we may have to read the JSON objects).
• Do not use the existing proposed schema languages since there is apparently no consensus on these but also do not try to invent a new one.
• Try to be simple and lightweight.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The proposal Core names are not namespaced (at this stage, it is not decided if mappings for domains, contacts and hosts will be regarded as core, or as extensions). Namespaces have to be registered with IANA, per .

Syntax The syntax follows ABNF (). A namespace is identified by a string in restricted ASCII, just letters and dash: namespace = %x2D / %x41-5A / %x61-7A The name of a member of a JSON object in RPP will be "namespace.shortname": name = [namespace %x2E] shortname Presently, shortname is not defined in RPP but we can assume it will be a (may be restricted?) form of JSON strings. It MUST NOT include dots.

Example { "name": "John Foobar", "date-of-birth": "2025-05-30", "country": "ZZ", "physical-person.status": true }

Towards a full extensibility proposal Of course, this small proposal is far from a complete solution to extend RPP. Such a solution would need to include:

• A way for the RPP clients and servers to advertise their capabilities (which extensions are supported).
• A way to extend non-payload stuff such as HTTP status codes.

IANA Considerations IANA is requested to create a registry of namespaces. These namespaces must conform to the syntax of . The policy to follow is "First Come First Served" as defined in . (Alternative, "Specification Required", because it would be nice to have a spec but I understand that, currently, the actual semantics of "Specification Required" are not clear; for instance, is an Internet Draft sufficient?)

Security Considerations There is probably zero security consequences of this proposal.

References Normative References Informative References

Discussions and alternatives To be deleted before publication. TODO