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/[email protected]/thread/6SIZ2AVFPD2ZXAGPZ7YI344RAMA6TCRR/
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-message-to-specified-user
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
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
