Network Working Group M. Wullink Internet-Draft SIDN Labs Intended status: Standards Track P. Kowalik Expires: 7 January 2027 DENIC 6 July 2026 JSContact Profile for RESTful Provisioning Protocol (RPP) draft-wullink-rpp-jscontact-profile-01 Abstract This document defines a JSContact usage profile, conforming to the rules described in [I-D.ietf-calext-jscontact-profiles], for the RESTful Provisioning Protocol (RPP). The JSContact Profile for RPP specifies how the JSContact format defined in [RFC9982] can be used as a standardized representation of contact information within RPP operations, enabling interoperability and consistency across RPP implementations that manage contact data. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Wullink & Kowalik Expires 7 January 2027 [Page 1] Internet-Draft JSContact Profile for RPP July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Relationship to the RDAP JSContact Profile . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 4. Using JSContact in RPP . . . . . . . . . . . . . . . . . . . 3 4.1. JSContact Profile for RPP . . . . . . . . . . . . . . . . 4 4.1.1. Version . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Kind . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.3. Language . . . . . . . . . . . . . . . . . . . . . . 4 4.1.4. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.5. Organizations . . . . . . . . . . . . . . . . . . . . 4 4.1.6. Addresses . . . . . . . . . . . . . . . . . . . . . . 4 4.1.7. Emails . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.8. Phones . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.9. Links . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.10. Map Keys . . . . . . . . . . . . . . . . . . . . . . 5 4.1.11. Localizations . . . . . . . . . . . . . . . . . . . . 5 4.1.12. Profile Properties . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. JSContact Profile Registry . . . . . . . . . . . . . . . 8 6. Internationalization Considerations . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Change History . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Version 00 to 01 . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction JSContact [RFC9982] 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. Wullink & Kowalik Expires 7 January 2027 [Page 2] Internet-Draft JSContact Profile for RPP July 2026 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. 1.1. Relationship to the RDAP JSContact Profile The Registration Data Access Protocol (RDAP) [RFC9083] 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 [I-D.ietf-regext-rdap-jscontact] 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. 2. 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 [RFC3986]. 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. 3. 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 [RFC2119]. 4. Using JSContact in RPP Wullink & Kowalik Expires 7 January 2027 [Page 3] Internet-Draft JSContact Profile for RPP July 2026 4.1. 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 [I-D.ietf-calext-jscontact-profiles]. The profile properties are formally listed in Section 4.1.12. All types mentioned in this section refer to the JSContact specification [RFC9982]. 4.1.1. Version The Card "version" member value MUST be "2.0". 4.1.2. Kind The Card "kind" member value MUST be "individual" (default) or "org" to represent an individual or an organization, respectively. 4.1.3. Language The Card "language" member SHOULD be set when localizations are specified (i.e., when the "localizations" member is present and non- null). 4.1.4. Name The Card "name" member MUST include only the "full" member and MUST NOT include the "components" member. 4.1.5. Organizations The Organization type MUST include only the "org" member. 4.1.6. 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 [BCP47] language tag. Wullink & Kowalik Expires 7 January 2027 [Page 4] Internet-Draft JSContact Profile for RPP July 2026 4.1.7. Emails The EmailAddress type MUST include only the "address" member. 4.1.8. 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. 4.1.9. 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". 4.1.10. Map Keys A JSContact map key MUST comply with the Id type definition in [RFC9553]. 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 Section 4.1.11. 4.1.11. 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. Wullink & Kowalik Expires 7 January 2027 [Page 5] Internet-Draft JSContact Profile for RPP July 2026 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 [BCP47] language tag as the key in the "localizations" map. The following example of a Card includes a localized version of the postal address: { "@type": "Card", "version": "2.0", "language": "en", "name": { "full": "Joe User" }, "organizations": { "org": { "name": "Example Org" } }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "Main Street 1" }, { "kind": "locality", "value": "Ludwigshafen am Rhein" }, { "kind": "region", "value": "Rhineland-Palatinate" }, { "kind": "postcode", "value": "67067" } ], "countryCode": "DE" } }, "localizations": { "de": { "addresses": { "addr": { "components": [ { "kind": "name", "value": "Hauptstraße 1" }, { "kind": "locality", "value": "Ludwigshafen am Rhein" }, { "kind": "region", "value": "Rheinland-Pfalz" }, { "kind": "postcode", "value": "67067" } ], "countryCode": "DE" } } } } } Figure 1: Example of handling localizations in JSContact Wullink & Kowalik Expires 7 January 2027 [Page 6] Internet-Draft JSContact Profile for RPP July 2026 4.1.12. Profile Properties The properties of the JSContact profile for RPP registered in the JSContact Profile registry as described in Section 5.1 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 | Wullink & Kowalik Expires 7 January 2027 [Page 7] Internet-Draft JSContact Profile for RPP July 2026 +---------------+------------------+------------+------------------+ | uri | Link | | | +---------------+------------------+------------+------------------+ | localizations | Card | | yes | +---------------+------------------+------------+------------------+ Table 1 Client validation MUST return an error if any JSContact properties other than those listed above are present. 5. IANA Considerations 5.1. 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 6. Internationalization Considerations TODO 7. Security Considerations TODO 8. Change History 8.1. Version 00 to 01 * Fixed duplicate text (Issue #14) 9. Normative References [BCP47] Best Current Practice 47, . At the time of writing, this BCP comprises the following: Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, . Wullink & Kowalik Expires 7 January 2027 [Page 8] Internet-Draft JSContact Profile for RPP July 2026 Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [I-D.ietf-calext-jscontact-profiles] Stepanek, R. and M. Loffredo, "Protocol-Specific Profiles for JSContact", Work in Progress, Internet-Draft, draft- ietf-calext-jscontact-profiles-14, 17 February 2026, . [I-D.ietf-regext-rdap-jscontact] Loffredo, M. and G. Brown, "Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses", Work in Progress, Internet-Draft, draft-ietf-regext-rdap- jscontact-25, 30 April 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . [RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON Representation of Contact Data", RFC 9553, DOI 10.17487/RFC9553, May 2024, . [RFC9982] Stepanek, R., "JSContact Version 2.0: A JSON Representation of Contact Data", RFC 9982, DOI 10.17487/RFC9982, May 2026, . Acknowledgements TODO Wullink & Kowalik Expires 7 January 2027 [Page 9] Internet-Draft JSContact Profile for RPP July 2026 Authors' Addresses Maarten Wullink SIDN Labs Email: maarten.wullink@sidn.nl URI: https://sidn.nl/ Pawel Kowalik DENIC Email: pawel.kowalik@denic.de URI: https://denic.de/ Wullink & Kowalik Expires 7 January 2027 [Page 10]