
Hi, A while back Cynthia, Dmitry and I looked at the possibility of adding new contact methods. Dmitry presented this at RIPE 88: https://ripe88.ripe.net/archives/video/1347/ I've tried to put this into a more complete NWI and offer it for discussion. The TLDR is: 1) Align the requirement levels for contact methods 2) Let people use new contact methods, like Signal We hope that by offering the methods people want to use, the contact data in the RIPE Database can be as useful as is possible. Kind regards, Leo ## Problem statement The requirement level for contact methods for person and role objects are inconsistent. This is both confusing and inconvenient. This is a proposal to add flexibility to the contact methods offered at the database level. It is not a proposal to change policy requirements for contact methods. This proposal is limited to admin-c and tech-c contact types. Our world offers more contact methods than were available when the currently supported methods were chosen for the RIPE Database. User acceptance of these methods differ by country and generation. Whether this proposal is accepted or not, it is good to review the rationale for these rules and have an updated rationale published. 1. Person and role objects have four contact methods. A postal address is mandatory for both. A phone is mandatory for person objects but not role objects. E-mail is mandatory for role but not person objects. 2. Postal mail is less useful than it was 20 years ago. Some countries are reducing the frequency of postal deliveries. And geographically distributed teams find postal mail less useful. 3. The telephone is becoming less useful, too. Call volumes are dropping and popular psychology publications explain why calls are less likely to be answered: - https://www.statista.com/statistics/551035/finland-call-volume-by-type-of-co... - https://www.bbc.com/news/articles/ckg8jllq283o - https://www.psychologytoday.com/intl/blog/un-numb/202405/why-gen-zers-keep-t... ## Proposal We should provide contacts with more flexibility. We should also add new options that were not available when the RIPE Database's contact methods were last reviewed. The three elements below follow on from NWI-15, which is based on the RIPE Database Requirements Task Force recommendations for what should be published about resource holders. The registry needs to retain the full set of required data. The DBTF report did not mention contacts methods for the resources. 1. Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all contact methods optional for the public RIPE Database as long as one is chosen. There is no point publishing a contact method that will not be used. That would just waste the time of people trying to make contact. 2. Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. 3. 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. Making these changes will require updates to the RPSL and RDAP publication methods. The RIPE NCC should manage the specifics of the design and implementation. ## Recommendation for Impact Assessment The impact assessment provided by the RIPE NCC should note any contact method requirements specified in policy. It should also note where the policy does not specify a contact method requirement. The RIPE NCC might want to note the impact of enforcing policy requirements when more user choice is offered at the database layer.