SIDN Labs

maarten.wullink@sidn.nl https://sidn.nl/

DENIC

pawel.kowalik@denic.de https://denic.de/

Internet Network Working Group This document defines a JSContact usage profile, conforming to the rules described in , for the RESTful Provisioning Protocol (RPP). The JSContact Profile for RPP specifies how the JSContact format defined in can be used as a standardized representation of contact information within RPP operations, enabling interoperability and consistency across RPP implementations that manage contact data.

Introduction JSContact is a flexible, JSON-based format for representing contact information. Its flexibility allows the same data to be expressed in multiple valid ways, which can hinder interoperability in a provisioning context where data must be stored and interpreted consistently. This document defines a JSContact usage profile for the RESTful Provisioning Protocol (RPP), restricting the set of JSContact constructs that RPP clients and servers are required to support when provisioning contact information.

Relationship to the RDAP JSContact Profile The Registration Data Access Protocol (RDAP) provides read-only access to registration data managed by RPP. Both protocols use JSContact for contact representation, but with profiles suited to their respective roles. The RDAP JSContact profile defines the constructs used when serving registration data to read-only consumers. The RPP profile defined in this document is a superset: all JSContact constructs permitted by the RDAP profile are also permitted in RPP. The converse does not hold. RPP supports additional JSContact constructs required for provisioning that have no meaningful equivalent in a read-only The RDAP JSContact profile defines the constructs used when serving registration data to read-only consumers. The RPP profile, defined in this document, is a subset of these constructs. All JSContact constructs permitted by the RPP profile can be used for RDAP. The converse does not hold. RDAP supports additional JSContact constructs that are useful in the read-only context of RDAP responses but that may hinder interoperability. These constructs are not present in RPP requests and responses.

Terminology In this document, the following terminology is used. RESTful Provisioning Protocol or RPP - The protocol described in this document. URL - A Uniform Resource Locator as defined in . RPP client - An HTTP user agent performing an RPP request. RPP server - An HTTP server responsible for processing requests and returning results in any supported media type.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Using JSContact in RPP

JSContact Profile for RPP Since JSContact is a generalized representation of contact data, many of its capabilities are not optimized for interoperable use in RPP payloads. This document therefore defines a usage profile for JSContact that simplifies implementation for both RPP clients and RPP servers. The JSContact profile for RPP is compliant with the rules described in . The profile properties are formally listed in . All types mentioned in this section refer to the JSContact specification .

Version The Card "version" member value MUST be "2.0".

Kind The Card "kind" member value MUST be "individual" (default) or "org" to represent an individual or an organization, respectively.

Language The Card "language" member SHOULD be set when localizations are specified (i.e., when the "localizations" member is present and non-null).

Name The Card "name" member MUST include only the "full" member and MUST NOT include the "components" member.

Organizations The Organization type MUST include only the "org" member.

Addresses The Address type MUST only use the "components" member. The AddressComponent MUST include only the "kind" and "value" members. The "kind" member value MUST only use "name", "locality", "region", or "postcode". When both an internationalized and a localized version of an address are used, the localized version MUST be placed in the localizations map keyed by an appropriate language tag.

Emails The EmailAddress type MUST include only the "address" member.

Phones The Phone type MUST include the "number" member and MAY include the "features" member. When the "features" member is present, its values MUST be "voice" or "fax". When the "features" member is absent, the phone number is assumed to be a voice number.

Links The Link type MUST include the "uri" member and MAY include the "kind" member. When the "kind" member is present, its value MUST be "contact".

Map Keys A JSContact map key MUST comply with the Id type definition in . RPP implementations MUST use the following predefined keys:

• "org" in the "organizations" map for a single preferred organization.
• "addr" in the "addresses" map for a single preferred postal address.
• "email" in the "emails" map for the preferred email address.
• "voice" in the "phones" map for the preferred voice number.
• "fax" in the "phones" map for the preferred fax number.
• "url" in the "links" map for a preferred contact URL; the "kind" member of the Link object MUST NOT be set.
• "contact-uri" in the "links" map for a contact URI; the "kind" member of the Link object MUST be set to "contact".

When internationalized and localized versions of an organization, postal address, or email exist, the internationalized version MUST be included under the predefined map key, while the localized version MUST be placed in the "localizations" map as described in .

Localizations If present, localized variants of name, organization, postal address, and email MUST be added to the "localizations" map. RPP implementations MUST expand all localizations, meaning a nested PatchObject key of the form "{key1}/{key2}/.../{keyN}" MUST NOT be used. The number of provided localizations MUST NOT exceed the number of languages supported by the RPP server. The language of each localization MUST be indicated by a language tag as the key in the "localizations" map. The following example of a Card includes a localized version of the postal address:

Example of handling localizations in JSContact

Profile Properties The properties of the JSContact profile for RPP registered in the JSContact Profile registry as described in are: | Property | Context | Restricted | Restricted Enum |

		Attributes	Values
language	Card
kind	Card		individual, org
name	Card
full	Name	mandatory
organizations	Card
name	Organization
addresses	Card
full	Address
countryCode	Address
components	Address
kind	AddressComponent		name, locality, region, postcode
value	AddressComponent
emails	Card
address	EmailAddress
phones	Card
features	Phone		voice, fax
number	Phone
links	Card
kind	Link		contact
uri	Link
localizations	Card		yes

Client validation MUST return an error if any JSContact properties other than those listed above are present.

IANA Considerations

JSContact Profile Registry IANA is requested to register the following entry in the "JSContact Profile" registry [I-D.ietf-calext-jscontact-profiles]: Name: rpp Profile Version: 1.0 Reference: This document TODO

Internationalization Considerations TODO

Security Considerations TODO

Normative References

Acknowledgements TODO