Dear colleagues, As discussed at the DB-WG session at RIPE 91, following is a draft solution definition and impact analysis from the RIPE NCC for NWI-20: "adjusting contact method requirements and adding new methods". Please let me know any questions or comments. Regards Ed Shryane RIPE NCC --- Introduction ------------ Following discussion of the NWI proposal “adjusting contact method requirements and adding new methods” on the DB-WG mailing list [1], the Co-chairs declared the problem statement as NWI-20 and asked the RIPE NCC for further input on potential solutions. Following is a Solution Definition from the RIPE NCC including an impact analysis. Requirements ------------ The following requirements are proposed in NWI-20 [1]: * Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all such contact methods optional for the public RIPE Database as long as one is chosen. * Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. * Add support for RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) and show the HTTPS intermediary and/or private URI where one is available. * E-mail is a mandatory attribute in role and person objects (additional requirement identified during discussion) This proposal is limited to admin-c and tech-c contact types. Existing RIPE Policy -------------------- The NWI-20 proposal is not a proposal to change policy requirements for contact methods, and has no impact on current RIPE policy. Current RIPE policy documents are listed on the RIPE NCC website [2]. Object Template Changes ----------------------- The RIPE NCC proposes the following changes to the object templates in the RIPE database to satisfy NWI-20 requirements: • The “e-mail” attribute becomes mandatory on person. • The “address” attribute becomes optional on both person and role. • The “phone” attribute becomes optional on person. • Add a new “contact:” as an optional attribute type on person, role, organisation, irt (see below). With these changes, the person object template becomes identical to the role template. E-mail Address is Mandatory in Administrative and Technical Contacts -------------------------------------------------------------------- The participants in the NWI discussion agreed that an e-mail address should be mandatory in “admin-c” and “tech-c” contacts. The “e-mail:” attribute is currently mandatory on organisation and role object types, but optional for person. We propose to change the “e-mail:” attribute to mandatory for person also. Creating or updating person objects will require at least one “e-mail:” attribute to be present. Address is Optional in Person and Role -------------------------------------- We propose to make the “address:” attribute optional in both person and role object types, to satisfy the requirement to make all contact types optional, so long as one is chosen. It will be up to the user to choose which of the available contact methods suits best their needs while ensuring that at least one contact method is available. Phone is Optional in Person --------------------------- We propose to make the “phone:” attribute optional in person to match the role type, to satisfy the requirement to make all contact types optional, so long as one is chosen. It will be up to the user to choose which of the available contact methods suits best their needs while ensuring that at least one contact method is available. Adding New Contact Types ------------------------ To support new contact types, we recommend adding a new “contact:” attribute type, that is optional and can appear multiple times on ORGANISATION, PERSON, ROLE and IRT object types. We will not change the definition of existing attributes already used as contacts. The RIPE NCC is not responsible for “contact:” attributes. All “contact:” attributes are maintained by the resource holder maintainer and are not managed or validated by the RIPE NCC. In particular it is the responsibility of the maintainer to ensure they have the right to insert the contact information in this attribute and ensure they will keep it correct and up-to-date. The syntax of a “contact:” attribute value is a URI. Any valid URI value will be accepted. If the specific application URI is recognised by Whois then it is further validated to be correct. We will add support for recognising more applications in the future. Initially, Whois will recognise and validate Whatsapp, Signal, Telegram and SIP contact URIs. Whatsapp A WhatsApp contact URI [3] uses the format https://wa.me/<number> or https://api.whatsapp.com/send?phone=<number>, where <number> is the full international phone number with country code, omitting any plus signs, parentheses, dashes, or leading zeros. You can also add a pre-filled message using ?text=urlencodedtext after the phone number. SIP A SIP contact URI [4] is a Session Initiation Protocol Uniform Resource Identifier used to identify a user or device on a SIP-based network, allowing for real-time communication sessions like voice and video calls. It follows a format similar to an email address, with the general syntax being sip:username@host[:port] Signal The Signal messaging app launched signal.me URls for this purpose back in 2021 [5]. It allows you to share a link like https://signal.me/#p/+447700900123 and have your signal client open up a chat with that person. Then, towards the end of 2022 they added support for their own sgnl scheme (although it doesn't appear to have been submitted as an IETF draft, and isn't listed on IANA). It has exactly the same layout as it's https sibling: sgnl://signal.me/#p/+447700900123. There is also support for usernames instead of the telephone number. Telegram A Telegram URI [6][7] can consist of any of the following formats : * https://t.me/share/url?url={url}&text={text} * https://telegram.me/share/url?url={url}&text={text} * tg://msg_url?url={url}&text={text} Adding New Contact Types to RDAP -------------------------------- A “contact:” attribute value will be represented in an RDAP entity object vCard “tel” element, as follows: * “type” element is set to both “voice” and “text”. * The “uri” element is set to the “contact:” attribute value. * “pref” is set according to the order of the “contact:” attribute in the object. According to RFC 6350 “vCard Format Specification”, section 6.4.1., it is expected that the “tel” value will be a “tel: URI scheme, but other schemes MAY be used. If a HTTP or HTTPS URI value is provided in the “contact:” attribute value, then we will add a contact vCard as defined in the Contact URI RDAP extension [8], as according to the RFC, at least one "mailto", "http", or "https" URI value MUST be provided for CONTACT-URI. The contact attribute type can be represented using the existing RDAP protocol so we do not need any new extension for it. Impact Analysis --------------- We foresee the following impacts on the RIPE database from these changes. * Creating person objects will require the “e-mail” attribute to be present. About 10,000 person objects are created monthly, by a few hundred maintainers. This change will cause the creation of person objects to fail if “e-mail” is missing. However, a descriptive error message in the update response will explain the cause of the failure, which can be used to resolve the issue. * Updating person objects will require the “e-mail” attribute to be present. There are about 2 million person objects in the database, and about half of them already have an “e-mail:” attribute. This change will cause updates of person objects to fail if “e-mail:” is missing. However, a descriptive error message in the update response will explain the cause of the failure, which can be used to resolve the issue. Also, about half of all person objects are never updated after they are created, so we expect a limited impact on existing objects. * Existing person objects may not conform to the new template. This can be mitigated by notifying maintainers of existing objects that the template has changed, so they can update objects accordingly. * Making mandatory attributes optional may cause some contact information not to be added and existing data to be removed. This information may be useful to other users. However, this may have the benefit of reducing the amount of unnecessary personal information in the database overall. Also it may reduce the amount of incorrect information just to satisfy the validation. There is no point adding contact information that is not useful. * Making an “admin-c” or “tech-c” reference to a person requires a mandatory contact. All contact methods besides the mandatory “e-mail” address will be optional so long as one is chosen. * A new, optional, “contact:” attribute will be added to person, role and organisation types. Client software that does not recognise this attribute should ignore it. However a “contact:” containing a telephone number should be considered equivalent to the “phone:” attribute. References ---------- 1. NWI-20 Proposal https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/6SIZ2AVFPD2ZXAG... 2. RIPE Policies https://www.ripe.net/publications/docs/ripe-policies/ 3. Whatsapp “How to use Click to Chat” https://faq.whatsapp.com/5913398998672934 4. SIP URI Scheme https://en.wikipedia.org/wiki/SIP_URI_scheme 5. Signal URI Scheme https://shkspr.mobi/blog/2023/02/signals-newish-uri-scheme/ 6. Telegram URI Scheme https://stackoverflow.com/questions/56971172/telegram-uri-scheme-to-send-mes... 7. Telegram Deep Links https://core.telegram.org/api/links 8. RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) https://datatracker.ietf.org/doc/html/rfc8605