Global Lookup and Discovery of Services (GLADOS)
draft-rosenberg-mimi-glados-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Jonathan Rosenberg | ||
| Last updated | 2023-07-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosenberg-mimi-glados-00
Network Working Group J. Rosenberg
Internet-Draft Five9
Intended status: Informational 10 July 2023
Expires: 11 January 2024
Global Lookup and Discovery of Services (GLADOS)
draft-rosenberg-mimi-glados-00
Abstract
This document proposes a solution for the discovery problem in MIMI
(More Instant Messaging Interoperability). The discovery problem is
the technique by which a user in one messaging provider can determine
the preferred messaging provider for a target user identified by an
email address or phone number. The discovery problem has been the
subject of numerous - largely failed - standardization attempts at
the IETF. This document outlines these attempts and hypothesizes the
reasons for their failure, using that to define a set of requirements
to avoid these failures in a next attempt. The new proposed
solution, called the Global Lookup and Discovery of Services (GLADOS)
protocol, is a centralized internet-wide provider that interfaces
with application providers.
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 11 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Rosenberg Expires 11 January 2024 [Page 1]
Internet-Draft MIMI GLADOS July 2023
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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Prior Efforts . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Core Requirements . . . . . . . . . . . . . . . . . . . . . . 5
5. GLADOS Overview . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Creation . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Mapping Query . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Mapping Creation . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Mapping Exists on Other Provider . . . . . . . . . . 11
5.4.2. Phone Number Moves . . . . . . . . . . . . . . . . . 11
5.5. Bulk Registration . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Spam Prevention . . . . . . . . . . . . . . . . . . . . . 13
6.2. Stolen Provider Credentials . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The More Instant Messaging Interoperability (MIMI) working group is
chartered to enable federated messaging, voice, and video service
between application providers, such as WhatsApp, Facebook Messenger,
and other vendors. The MIMI protocols cover the exchange of
encrypted content [I-D.ietf-mimi-content] through transfer protocols
[I-D.ralston-mimi-linearized-matrix]. These protocols allow a user
in one provider to initiate 1-1 and group messaging with a user in a
second provider. The protocol requires that the originator of the
communication know two things about the target user - their messaging
provider, and a unique identifier for that user within that provider.
The specifications recognize that the originator will not always know
the provider for the target user, or the provider-specific identifier
for that user on that provider. The problem is further complicated
by the fact that a users often make use of multiple messaging
applications, in which case the preferences of the target user need
to be taken into account as well. These preferences are even less
likely to be known by the originator of communications.
Rosenberg Expires 11 January 2024 [Page 2]
Internet-Draft MIMI GLADOS July 2023
The MIMI framework hypothesizes the existence of a discovery or
directory service to solve this problem. The discovery service would
allow the originator to take a servide independent identifier for a
target - such as a mobile phone number or email address - and perform
a lookup to determine the preferred service of the target user, along
with their identifier within that service.
This document proposes a specific solution for the discovery service,
a new protocol called the Global Lookup and Discovery of Services
(GLADOS). GLADOS is a centralized internet service, serving the
common good of Internet users. It provides REST-based APIs that
support the registration and lookup of mappings. GLADOS is not meant
to be directly accessed by consumers. Rather, it is accessed by
communications applications operating on a user's behalf.
2. Definitions
* Service Independent Identifier (SII): A type of identifier for a
user that is unique (such that an SII is associated to only a
single user), and independent of any specific communications
service. There are two specific identifiers in this case - a
mobile phone number, or an email address.
* Unique, Service Specific Identifier (SSI): A type of identifier
for a user that is unique (such that an SSI is associated to only
a single user), and achieves its uniqueness by being composed of
two parts - a user part, scoped to a provider of communication
services, and a unique identifier for the communication service
provider. In some services, the user part is not globally unique
across services. Examples of this case are Wire, Twitter and
Skype, where user handles are flat - @jdrosen2 on Twitter, for
example. In other services, the user part is globally unique, and
corresponds to the email address or mobile phone number for the
recipient. Examples of this case are WhatsApp, iMessage, and
Facetime.
* Personally Identifying Information (PII): Information about a
target user that is not unique, but can be used to facilitate a
search for the target user. Typically this would be the first
name and/or last name of the recipient. The search would provide
a list of possible matches, along with additional information,
such as display names and avatars, which help the initiator find
the specific person to which communications is desired.
3. Prior Efforts
Discovery services are far from new on the Internet.
Rosenberg Expires 11 January 2024 [Page 3]
Internet-Draft MIMI GLADOS July 2023
The whois protocol, originally specified in [RFC0954] and later
revised by [RFC3912], was largely focused on the mapping of domain
names, to services associated with those domain names, and was one of
the first discovery services deployed on the Internet. The DNS SRV
record was specified in [RFC2782] and allows a similar discovery
process - given a domain name, allows a querier to learn the set of
services, such as VOIP based on the Session Initiation Protocol (SIP)
[RFC3261] [RFC3263]. Whois and DNS SRV records both assumed that the
lookup was keyed by a domain name, and thus they were not that useful
for looking up an identifier that is not domain scoped, such as a
mobile phone number.
This was first addressed through the specification of ENUM [RFC3761]
in 2004. ENUM defined the usage of DNS to lookup phone numbers, by
convering a phone number to a DNS name by reversing the digits and
adding the suffix "e164.arpa". This allowed portions of the
namespace to be delegated to telco providers that owned the number
prefix in question. Though technically simple to define, its
deployment was hampered by the challenges of establishing authority
for the prefixes. It also had a network effects challenge - its
utility was limited until there was a critical mass of numbers in the
system. It thus became hard to justify the investment of
contributing numbers to ENUM. It also suffered from an incentive
problem - what was the business value for the telcos to participate
in the activity? These challenges resulted in a failure of ENUM
adoption.
Another attempt was made with ViPR (Verification Involving PSTN
Reahability) [I-D.rosenberg-dispatch-vipr-overview]
[I-D.petithuguenin-vipr-pvp]. VIPR made used of a peer-to-peer
network based on RELOAD (Resource Location and Discovery) [RFC6940],
running between enterprises. It solved the problem of authority
problem by authorizing records based on proof of forward routability.
However, it had the same network effects problem as ENUM. It also
addressed the incentive problem, by focusing on enterprises for which
bypassing the phone network would provide cost savings. However, the
network effects problem proved insurmountable (amongst other
challenges unrelated to the protocol), and it was never widely
deployed.
Discovery and lookup services are now common place on the Internet
but are scoped entirely within large providers, such as Facebook,
Twitter, WhatsApp and other providers.
The MIMI discovery service requires a solution that spans across
providers.
Rosenberg Expires 11 January 2024 [Page 4]
Internet-Draft MIMI GLADOS July 2023
4. Core Requirements
There are four key requirements:
1. Mapping: The service must provide a way to map from a SII to a
SSI.
2. Validity: The mappings provided by the service must be represent
the wishes of the user associated with the SII, mapping to an
application they are a user of, and the mapped SSI must be the
one associated with this user. The core issue is one of trust,
and how to determine that the mappings provided by the service
are accurate.
3. Critical Mass: The network effects problem is perhaps the hardest
to solve. But, to be viable, any solution must be able to reach
a critical mass of mappings so that it becomes useful to consume,
and thus useful to further populate.
4. Incentive Alignment: There must be an incentive structure which
motivates the population of mappings into the service, and for
the consumption of those mappings.
Beyond these, there are many other requirements related to security
and information privacy.
5. GLADOS Overview
Global Lookup and Discovery of Services (GLADOS) involves a central
provider - simply called glados - that provides the needed mapping
function. This mapping function is provided by a REST API. The most
important idea behind glados is that this mapping function is not
accessed directly by consumers. Instead, it is accessed indirectly -
via communications applications that act on the user's behalf - the
same providers that would participate in MIMI. In addition to
providing a mapping API, glados provides two sets of APIs for
registering mappings. The first is a bulk API, enabling a messaging
provider to register mappings it already has. The second is an API
by which glados can construct the mapping through forwarding
routability - sending an SMS or an email - on behalf of the provider.
A high level view of it can be seen in the following figure:
Rosenberg Expires 11 January 2024 [Page 5]
Internet-Draft MIMI GLADOS July 2023
+--------+
| glados |
+--------+
|
+----------+----------+
| | |
+--------+ +--------+ +--------+
| App | | App | | App |
|Provider| |Provider| |Provider|
| 1 | | 2 | | 3 |
+--------+ +--------+ +--------+
| | | | |
| | | | |
+----+ +----+ +----+ +----+ +----+
|User| |User| |User| |User| |User|
| 1 | | 2 | | 3 | | 4 | | 5 |
+----+ +----+ +----+ +----+ +----+
Figure 1: GLADOS Architecture
The end users never see glados. No end user has an account on it;
they dont see it as a brand or know of it. It is rather a service
largely invisible to end users, similar to the DNS.
The entities that access glados are application providers. Through
an enrollment process, an app provider obtains authorization to
access glados for mappings, and to register mappings through either
the bulk API or the mapping creation API. As part of this process,
an OAuth ClientID and secret are generated, and provided to the app
provider. The app provider can uses these to obtain access tokens
needed for accessing the glados APIs. Glados APIs are accessed via
server-to-server communications, and make use of mutual TLS to
provide an additional layer of authentication as well as ensuring
that the glados client ID, secret and access tokens remain on servers
and dont make their way to the clients provided by the providers.
5.1. Creation
GLADOS is meant to be a singleton provider - there is only one on the
entire Internet. GLADOS would be established as new non-profit
organization, or perhaps established as a new division of an existing
non-profit (for example, LetsEncrypt). The IETF would publish an RFC
which defines a set of requirements and processes for selection of a
corporation to act as the GLADOS provider, and then an IETF
administrative function would perform that RFP process and select a
vendor.
Rosenberg Expires 11 January 2024 [Page 6]
Internet-Draft MIMI GLADOS July 2023
There are multiple techniques for funding, including having ISOC fund
it, having it be its own charity, or by having it charge the
providers for its services. The strawman proposal is that it would
charge providers for its service, with pricing that is set just
enough to cover costs. Any profit would be given to ISOC as charity.
The benefit of charging for access is that the costs would scale with
the size of the provider, so that larger providers (like a Facebook
or Google) would pay more, while smaller providers (like Wire), would
pay less.
The vendor would then run the glados service globally, implementing
the protocols and processes defined by the IETF.
An alternative model is one that is closer to domain name
registrations. There can be multiple vendors who provide APIs for
creation of mappings, and then all of these vendors share their
mappings with each other. The sharing process is of course
complicated, and it runs the risk of malicious providers that dont
respect the privacy, security or other aspects of the specifications.
With the singleton provider model, the IETF can establish processes
for audit and reporting, which are enforced by the IETF
administrative function and required for continued approval of that
vendor to act as the single glados provider.
5.2. Enrollment
An application provider that wishes to participate in the mimi
federation enrolls with glados.
This enrollment is a manual process, and as part of it, the glados
provider will provide a series of audit and validation steps to make
sure the app provider is legitimate. This validation process would
involve verifying that the app provider is a legitimate business,
verifying that their applications are available to consumers on
mobile platforms and/or web, validating that the application is
indeed a messaging app by creating an account and using it, verifying
that it has other users and has reasonable reviews and ratings within
app stores. Most importantly, it will try to validate that the
application provider is not a source of spam. The glados vendor
would define these processes, and they would be made publically
available to all.
Why are these checks needed?
The main problem they are trying to solve, is to reduce the risk of
the mapping APIs being used for malicious purposes, including spam.
Once fully populated, the glados database will contain entries for a
significant percentage of the users on the planet, indicating what
Rosenberg Expires 11 January 2024 [Page 7]
Internet-Draft MIMI GLADOS July 2023
providers they are using for various communications services. This
is valuable information, and could be used for ill. For example, a
malicious provider might iterate through the mapping APIs using
databases of user email addresses and phone numbers, to build its own
directory of users and what apps they are on. It might then send
those users spam messages on the various providers. Validating the
app providers is one way this is prevented.
Once glados has approved the application vendor, they are provided a
traditional OAuth ClientID and Secret, which can be used to obtain
access tokens for using the glados APIs.
5.3. Mapping Query
The mapping Query API is a simple REST API that takes, as input, an
SII. This is looked up in the glados database, and mapped to the
preferred SSI for the user. The means by which preferences are
established, is discussed below. The resulting SSI is returned to
the requesting application provider.
The mapping API would include the access token from the provider,
allowing it to know which provider is requesting the mapping.
A key requirement for glados is that it will impose rate controls to
help prevent against the APIs being used maliciously. Glados knows,
for any provider, how many users it has, because that provider will
have to register its own users as described below. With knowledge of
how many users the provider has, along with statistics on the typical
number of messages sent between providers (and thus the number of
mapping requests typically made), glados can dynamically create
reasonable rate limits to make sure that the volume of mapping API
requests is reasonable for the provider. This is a second way in
which glados prevents the mapping APIs being used for malicious
purposes.
Note that the mapping query API is not an enumeration API. It is not
possible for a provider to list users. It requires the SII to be
provided, and for that SII, it returns the mapped SSI. It is also
important to note that the mapping query API is not a batch API
either; it is one mapping request at a time. All of these help
mitigate against spam and enumeration attacks.
5.4. Mapping Creation
The primary way in which mappings are created in glados are created,
is via the mapping creation flow. This flow is shown below:
Rosenberg Expires 11 January 2024 [Page 8]
Internet-Draft MIMI GLADOS July 2023
+-------+ +-----------+ +---------+
| user | | provider | | glados |
+-------+ +-----------+ +---------+
| | |
| access app | |
|---------------------------->| |
| | |
| enter email or number | |
|<----------------------------| |
| | |
| SII | |
|---------------------------->| |
| | ---------------\ |
| |-| create unique| |
| | | userID | |
| | |--------------| |
| | |
| | create map( |
| | userID, SII) |
| |----------------->|
| | |
| | email or SMS |
| | with code |
|<-----------------------------------------------|
| | |
| enter code | |
|---------------------------->| |
| | |
| | validation code |
| |----------------->|
| | | ----------\
| | |-| store |
| | | |---------|
| | |
| | registered |
| |<-----------------|
| | |
Figure 2: Mapping Operation
Rosenberg Expires 11 January 2024 [Page 9]
Internet-Draft MIMI GLADOS July 2023
The mapping operation is best understood by considering the case of a
brand new user creating an account on the provider. As part of the
new user onboarding process in the app, the user will be prompted to
enter their email or mobile number. The provider can choose whether
to request email or phone number or both, as a matter of provider
policy and design. This is something users are already used to doing
as part of application onboarding. The flow described here replaces
that flow, with one performed via glados instead whatever SMS or
email provider the application provider would have used previously.
The application provider will create its own unique ID for the user,
scoped within its own application. This ID need only be unique
within the application provider. Once the application provider has
collected the SII and generated this ID - they are sent to glados.
Using the acccess token, glados will know who the application
provider is, and thus be able to construct the SSI by combining the
provider userID, with the providerID implied by the access token.
Glados will then construct a short live code, and either email or SMS
it to the user. THe user will receive this text or email, and then
copy the code into the app. It is important for the security of this
solution that the provider - who is only partially trusted here -
does not know this prior to the user entering it. Once the user has
entered the code, the provider invokes another API on glados,
providing the code along with the userID provided previously. Glados
matches the code with what it had previously sent. If there is a
match, it considers the mapping validated, and stores it. It informs
the app provider that the code has been confirmed. This allows the
app provider to retain its own mapping too, as they do today.
This flow is meant to protect against a malicious provider trying to
register mappings that do not actually correspond to their own users.
Consider a malicious provider who makes up a set of userIDs, and then
tries to register made-up phone numbers or email addresses for those
users. They might do this in order to steal messaging or calls
targeted to users with those numbers or emails. Consider for
example, a malicious provider that tries to register the emails of
wealthy CEOs or political leaders, in order to receive messages
targeted for them. Should a malicious provider do this, glados will
send en email or SMS to that user with the code. The malicious
provider does not have that code, and thus would not be able to
complete the mapping creation operation.
There are several subcases worth considering.
Rosenberg Expires 11 January 2024 [Page 10]
Internet-Draft MIMI GLADOS July 2023
5.4.1. Mapping Exists on Other Provider
Consider the case where provider 1 establishes a mapping for an SII,
but a mapping already exists for that SII on a different provider.
In that case, glados needs to establish a preference, including
termination of the prior mapping. To facilitate that, in the
response provided to the new provider, it will include an indication
that there is already a mapping in the old provider, and include that
provider ID and name. The new provider would then render to the end
user a choice - whether to invalidate the prior mapping, or to keep
it and make this new application the preferred one. Using another
REST API call, the new provider can then instruct glados to delete
the old mapping or make the new one the preferred choice.
Through a webhook, the old provider will be notified that the mapping
has been removed and/or preference established for the new provider.
This will allow the old provider to update there databases, and also
inform the user of this change in the old application.
The notification in the old application also helps deal with the case
of a malicious provider that always promotes its own app as the
preferred app and/or removes the old mapping, against the user's
wishes. The old provider will be notified, and this can be shown to
the user. If done malicisously, the user can request their old app
to re-establish the mapping, change the preference back, or to report
the change as malicious. All of those operations would be available
to the old provider via API. In the case where the user reports the
change as malicious, this would be a strike against the reputation of
the new provider. With sufficient strikes, glados can further rate
limit that provider or remove their access entirely.
5.4.2. Phone Number Moves
In this case, user A had a particular phone number, and a
registration was made using their app provider. User A then gives up
this phone number, and a few months later, it is allocated to user B.
User B goes and enters this same phone number - with either the same
or a different provider.
In practice, this case is indistinguishable from the prior one. User
B would see, in the UI of their app, that a previous registration
exists for a different provider. They would then select the option
to remove that old mapping for user A.
At the point where user B has obtained the number from their telco,
and begun to give it out to friends and family, but has NOT used it
with any messaging application, new contact requests for that number
Rosenberg Expires 11 January 2024 [Page 11]
Internet-Draft MIMI GLADOS July 2023
will continue to be delivered to user A via their current
application. This is definitely not a good thing, and is one of the
main limitations of this proposal. It can be somewhat remediated by
periodic refresh of the mapping, but this is bothersome to users and
is not current practice.
That said, this same limitation exists within existing messaging
providers. Glados doesnt make the problem worse, but it doesnt make
it better.
5.5. Bulk Registration
A key problem that glados needs to solve is the network effect
problem. The mapping creation API above works well, but if we were
to depend on that, glados would begin day one with zero phone
numbers.
To resolve this, glados will provide a bulk API that allows selected
providers to upload mappings, and glados will just trust them without
sending confirmation emails or SMS messages. This API would be made
available selectively, only to the handful of known, large providers
- Facebook Messenger, WhatsApp, iMessage - and perhaps that's it.
With just those three, glados would have critical mass of mappings to
bootstrap the ongoing registration process described above, which
would be used by all of the other smaller providers.
The bulk registration process provides full trust in the provider,
that they are only registering numbers and email addresses that they
have actually verified. This is why it can only be done with the
handful of highly known vendors.
The final piece of the puzzle is incentive. What is the incentive
for the largest providers to do this? They are, in essence, giving
up their crown jewels - a set of validated phone numbers and emails.
The answer is the same as mimi as a whole. They would be compelled
to do so through the regulatory actions of the EU or other bodies.
WIthout that, it is unlikely that this proposal would work.
6. Security Considerations
Security is paramount and is at the center of this proposal.
Rosenberg Expires 11 January 2024 [Page 12]
Internet-Draft MIMI GLADOS July 2023
6.1. Spam Prevention
The main security worry is that of a malicious messaging provider
whose primary interest is the generation of spam. To generate that
spam to different users, this malicious messaging provider would take
a list of email addresses and phone numbers - all of which are
readily obtained - and run a high volume of mapping request
operations to obtain an SSI for those users. Using the MIMI
protocols, the malicious provider would then spam the user.
This attack is partly mitigated by the MIMI protocols themselves,
whih require a user to agree to a connection request from a new user
(NOTE: this is not yet finalized as a feature of the protocols).
However, this still enables the spamming of connection requests.
These connection requests do convey content - a display name, a user
identifier, and sometimes an avatar or perhaps even an initial
message. More than enough to deliver content and thus an appealing
vehicle. The glados protocols provide additional protection from
this.
The protection is accomplished through the several aspects of the
glados system. First, providers cannot invoke mapping request APIs
unless they've enrolled. The enrollment process includes an audit
and validation process which ensures the app is a legitimate
messaging app. Should a malicious application anyway pass this gate,
there is another protection via rate limiting of mapping request
invocations. These are rate limited based on the number of enrolled
users in the application. A malicious app would need to fake a large
number of enrollments to obtain enough rate to usefully spam
connection requests. Glados can additionally use analytics to look
for odd patterns in registrations, including clearly fake or
genreated email addresses, overlaps with existing email addresses and
so on.
The spam prevention aspects of glados also make it attractive for app
providers to enroll, as another form of incentive.
6.2. Stolen Provider Credentials
In this attack, a malicious provider has obtained credentials -
clientiD and secret, or access token, for a valid provider.
This is prevented in part through normal techniques - encrypted
connections for all glados REST API calls for example.
There is an additional risk - that the clientID and secret and/or
access tokens are placed onto the mobile or web application for that
provider. A malicious user might try to reverse engineer the client,
Rosenberg Expires 11 January 2024 [Page 13]
Internet-Draft MIMI GLADOS July 2023
or inspect memory or disk, in order to get access to these secrets.
Given the high privelege associated with these APIs, that is a real
risk.
To prevent that, glados adds a requirement for MTLS between the
provider and glados. This makes it impossible to use from a web
application. Though technically possible in a mobile client, it is
unlikely that a legitimate provider would ever place such a
certificate on a mobile device. (NOTE: not sure this is really an
issue).
7. Informative References
[I-D.ietf-mimi-content]
Mahy, R., "More Instant Messaging Interoperability (MIMI)
message content", Work in Progress, Internet-Draft, draft-
ietf-mimi-content-00, 20 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mimi-
content-00>.
[I-D.petithuguenin-vipr-pvp]
Petit-Huguenin, M., Rosenberg, J., and C. F. Jennings,
"The Public Switched Telephone Network (PSTN) Validation
Protocol (PVP)", Work in Progress, Internet-Draft, draft-
petithuguenin-vipr-pvp-04, 12 March 2012,
<https://datatracker.ietf.org/doc/html/draft-
petithuguenin-vipr-pvp-04>.
[I-D.ralston-mimi-linearized-matrix]
Ralston, T. and M. Hodgson, "Linearized Matrix", Work in
Progress, Internet-Draft, draft-ralston-mimi-linearized-
matrix-02, 26 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ralston-mimi-
linearized-matrix-02>.
[I-D.rosenberg-dispatch-vipr-overview]
Rosenberg, J., Jennings, C. F., and M. Petit-Huguenin,
"Verification Involving PSTN Reachability: Requirements
and Architecture Overview", Work in Progress, Internet-
Draft, draft-rosenberg-dispatch-vipr-overview-04, 25
October 2010, <https://datatracker.ietf.org/doc/html/
draft-rosenberg-dispatch-vipr-overview-04>.
[RFC0954] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/
WHOIS", RFC 954, DOI 10.17487/RFC0954, October 1985,
<https://www.rfc-editor.org/info/rfc954>.
Rosenberg Expires 11 January 2024 [Page 14]
Internet-Draft MIMI GLADOS July 2023
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002,
<https://www.rfc-editor.org/info/rfc3263>.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761,
DOI 10.17487/RFC3761, April 2004,
<https://www.rfc-editor.org/info/rfc3761>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
January 2014, <https://www.rfc-editor.org/info/rfc6940>.
Author's Address
Jonathan Rosenberg
Five9
Email: jdrosen@jdrosen.net
Rosenberg Expires 11 January 2024 [Page 15]