RFC 2604

Wireless Device Configuration (OTASP/OTAPA) via ACAP

📅 published June 1999, from ietf

Wireless Device Configuration (OTASP/OTAPA) via ACAP 💖

Okay bestie, let's start with the basics 🎀. This is RFC 2604, written by R. Gellens from Qualcomm 💅 and dated June 1999. It's in the Informational category ✨ and comes from the Network Working Group 🦋. The title block doesn't list anything it obsoletes or updates, so no drama there 🙈.

Status of this Memo 🌈

This memo is just here to provide information for the Internet community 📚. It does not specify an Internet standard of any kind, so it isn't one 🙅. Distribution is unlimited, so you can share it with everyone 🫶.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract ✨

Wireless carriers are juggling a lot rn 🤹. They need more efficient distribution channels, happier customers 😭, and better margins and profitability 💰. Handsets keep moving further into the retail channel 🛍️, and the cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms 🧚. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required 🎀.

One option is to buy EIA/TIA/IS-683A (Over-the-air Service Provisioning of Mobile Stations in Spread Spectrum Systems) equipment 📱, but that cost has pushed carriers to look for other routes 💸. A very viable way to do over-the-air (OTA) provisioning is to ride the rollout of IS-707 data services equipment, which most carriers are already deploying 🚀. This paper presents an approach that uses the IS-707 rollout to deliver OTA provisioning and parameter upgrading 🦋.

IS-707 data services already offers several ways to do OTA provisioning and parameter updating 🌸. A well thought-out approach built on Internet-based open standard mechanisms can give carriers an extensible platform for more service offerings, better interoperability among back-end services, and vendor independence 👑.

This paper describes a viable and attractive way to provide OTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol 💅.

Table of Contents 🧚

1.  Terms  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Feature Descriptions  . . . . . . . . . . . . . . . . . . .   6
    2.1.  OTASP Feature Description  . . . . . . . . . . . . . . .  6
    2.2.  OTAPA Feature Description . . . . . . . . . . . . . . .   6
  3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . .  7
    3.1.  Initial Provisioning Activity . . . . . . . . . . . . .   7
    3.2.  OTASP for Authorized Users . . . . . . . . . . . . . . .  8
    3.3.  OTAPA Activity  . . . . . . . . . . . . . . . . . . . .   8
  4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . .  9
    4.1.  General Requirements  . . . . . . . . . . . . . . . . .   9
    4.2.  OTASP Requirements  . . . . . . . . . . . . . . . . . . . 9
    4.3.  OTAPA Requirements  . . . . . . . . . . . . . . . . . .  10
    4.4.  Provisioning Server Requirements . . . . . . . . . . . . 10
    4.5.  Security Requirements . . . . . . . . . . . . . . . . .  11
  5.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
    5.1.  ACAP over TCP/IP  . . . . . . . . . . . . . . . . . . .  11
      5.1.1.  Mobile Authentication and A-Key Generation . . . . . 12
      5.1.2.  Mobile Identification . . . . . . . . . . . . . . .  12
      5.1.3.  ACAP Server  . . . . . . . . . . . . . . . . . . . . 12
      5.1.4.  Overview of ACAP Structure  . . . . . . . . . . . .  13
      5.1.5.  Data Organization and Capabilities . . . . . . . . . 13
        5.1.5.1.  Structure . . . . . . . . . . . . . . . . . . .  14
        5.1.5.2.  Conventions  . . . . . . . . . . . . . . . . . . 15
      5.1.6.  Dataset . . . . . . . . . . . . . . . . . . . . . .  15
        5.1.6.1.  Entries and Attributes . . . . . . . . . . . . . 15
        5.1.6.2.  NAM Records . . . . . . . . . . . . . . . . . .  16
        5.1.6.3.  Server Roaming Lists . . . . . . . . . . . . . . 17
        5.1.6.4.  Requested-Data Record . . . . . . . . . . . . .  18
        5.1.6.5.  Sample Server Entry  . . . . . . . . . . . . . . 18
      5.1.7.  Administrative Client . . . . . . . . . . . . . . .  19
      5.1.8.  Mobile Client  . . . . . . . . . . . . . . . . . . . 20
    5.2.  WAP with ACAP . . . . . . . . . . . . . . . . . . . . .  22
    5.3.  Network-Resident vs. Configuration Data  . . . . . . . . 23
    5.4.  Intellectual Property Issues  . . . . . . . . . . . . .  23
  6.  Handset Protocol Suites  . . . . . . . . . . . . . . . . . . 23
    6.1.  ACAP over TCP/IP  . . . . . . . . . . . . . . . . . . .  23
  7.  IS-683A Compatibility  . . . . . . . . . . . . . . . . . . . 24
    7.1.  OTASP Operations  . . . . . . . . . . . . . . . . . . .  24
    7.2.  OTASP Call Flow  . . . . . . . . . . . . . . . . . . . . 24
    7.3.  OTAPA Operations  . . . . . . . . . . . . . . . . . . .  24
    7.4.  OTAPA Call Flow  . . . . . . . . . . . . . . . . . . . . 25
  8.  Alternative Methods . . . . . . . . . . . . . . . . . . . .  25
    8.1.  IS-683A over TCP/IP  . . . . . . . . . . . . . . . . . . 25
      8.1.1.  OTAF Server . . . . . . . . . . . . . . . . . . . .  25
      8.1.2.  Interface Application  . . . . . . . . . . . . . . . 26
      8.1.3.  Protocol Handset Suite  . . . . . . . . . . . . . .  26

    8.2.  Browser-Based Forms  . . . . . . . . . . . . . . . . . . 26
  9.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . .  27
  10.  References . . . . . . . . . . . . . . . . . . . . . . . .  28
  11.  Security Considerations . . . . . . . . . . . . . . . . .   28
  12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  28
  13.  Author's Address  . . . . . . . . . . . . . . . . . . . .   28
  14.  Full Copyright Statement . . . . . . . . . . . . . . . . .  29

1. Terms ✨

okay bestie, vocab first 📖 these terms are the foundation for everything else, so no skipping 🫶

Application Configuration Access Protocol (ACAP) 💖 An Internet protocol (RFC-2244) that gives you remote storage and access to configuration and preference info. ✨

Activation 🌸 A process where a mobile station and the network get programmed so the mobile station becomes operable and can be used for cellular service once the service provider authorizes it.

Authentication 🔐 A procedure used to validate a mobile station's identity.

Authentication Center An entity that manages the authentication info related to the mobile station.

Authentication Key (A-key) A secret 64-bit pattern stored in the mobile station. It's used to generate and update the mobile station's shared secret data, and it's used in the authentication process.

Authorization An action by a service provider to make cellular service available to a subscriber.

Call A temporary communication between telecommunications users for the purpose of exchanging information. A call includes the sequence of events that allocates and assigns the resources and signaling channels needed to set up a communications connection.

Cellular Service Provider A licensee of the responsible government agency (in the U.S., a licensee of the Federal Communications Commission) that is authorized to provide Cellular Radiotelephone Service.

Challenge/Response Authentication Mechanism using Message Digest 5 (CRAM-MD5) An authentication mechanism that's easy to implement and gives reasonable security against various attacks, including replay. It's supported in a variety of Internet protocols and is the baseline mechanism specified in ACAP. CRAM-MD5 is published as RFC 2195.

Code Division Multiple Access A technique for spread-spectrum multiple-access digital communications that creates channels through the use of unique code sequences.

Customer Service Center An entity of a service provider that gives user support and assistance to subscribers.

Customer Service Representative A person who works from a customer service center and gives user support and assistance to subscribers.

Diffie-Hellman Algorithm A public-key cryptography algorithm for exchanging secret keys. It uses the equation , where k is the secret key. Each party of the session runs the equation based on the exchange of independently generated public values.

Digits Digits are the decimal integers 0,1,2,3,4,5,6,7,8, and 9.

Dual-mode Mobile Station A mobile station that's capable of both analog and digital operation.

Electronic Serial Number (ESN) A 32-bit number assigned by the mobile station manufacturer to identify a mobile station. The ESN is unique for each legitimate mobile station.

Home Location Registry (HLR) The location register or database to which a MIN is assigned for record purposes, such as subscriber information.

Message Digest 5 (MD5) A one-way cryptographic hash function. Widely deployed in Internet protocols. Published as RFC 1321.

Mobile Identification Number (MIN) The 10-digit number that represents a mobile station's directory number.

Mobile Station (MS) A station, fixed or mobile, that serves as the end user's wireless communications link with the base station. Mobile stations include portable units (e.g., hand-held personal units) and units installed in vehicles.

Mobile Switching Center (MSC) A configuration of equipment that provides cellular radiotelephone service.

Mobile Terminal Authorizing System (MTAS) A control system that provides the capability to load the CDMA network HLR with mobile station profile information.

Number Assignment Module (NAM) The mobile station's electronic memory module where the MIN and other subscriber-specific parameters are stored. Mobile stations that have multi-NAM features let users operate their units in several different markets by registering with a local number in each location.

Over-the-air Service Provisioning Function (OTAF) A configuration of network equipment that controls OTASP functionality and messaging protocol.

Over-the-air Parameter Administration (OTAPA) Network-initiated OTASP process of provisioning mobile station operational parameters over the air interface.

Over-the-air Service Provisioning (OTASP) A process of provisioning mobile station operational parameters over the air interface.

Quick-Net-Connect (QNC) An IS-707 data service capability that uses the Async Data Service Option number but bypasses the modem connection for a direct connection to an IP-based internet.

Roamer A mobile station operating in a cellular system or network other than the one from which service was subscribed.

Simple Authentication and Security Layer (SASL) An Internet protocol (RFC-2222) that provides a framework for negotiating authentication and encryption mechanisms.

Service Provider A company, organization, business, etc. that sells, administers, maintains, and charges for the service. The service provider may or may not be the provider of the network.

Shared Secret Data (SSD) A 128-bit pattern stored in the mobile station (in semi-permanent memory) and known by the network. The A-key is used to generate the SSD at the network and in the mobile station for comparison.

Wireless Application Protocol (WAP) A set of network and application protocols, including a datagram protocol (WDP), Transport Layer Security (WTLS), Transaction Protocol (WTP), Session Protocol (WSP), and Application Environment (WAE), which use carrier-based gateways to enable wireless devices to access Web resources. See <http://www.wapforum.org> for specifications and details.

2. Feature Descriptions 💅

2.1. OTASP Feature Description

The Over the Air Service Provisioning (OTASP) feature allows a potential wireless service subscriber to activate new wireless services, and allows an existing wireless subscriber to make service changes without a third party getting involved. OTASP includes the following:

  • A way to establish a user profile.
  • "Over-The-Air" programming of a Number Assignment Module (NAM), IMSI and Roaming Lists, including Data option parameters, and optionally, service provider or manufacturer specific parameters (e.g., lock code, call timer).
  • An Authentication Key (A-key) Generation procedure.
  • A-key storage

2.2. OTAPA Feature Description

The Over-the-Air Parameter Administration (OTAPA) feature lets wireless service providers update a NAM, IMSI, and Roaming List info in the mobile station remotely, no third party needed. This boosts flexibility and cuts costs for carriers handling mass changes that hit every handset, like area-code splits.

OTAPA includes the following:

  • Update a user's Number Assignment Module (NAM)
  • Update Data option parameters
  • Update service provider or manufacturer specific parameters (e.g., Server address(es), lock code, call timer).
  • Update roaming lists

3. Operation 🎀

3.1. Initial Provisioning Activity

okay so the new subscriber has to give the intended service provider enough info (name, address, etc.) to prove they're credit-worthy and get a record in the provider's billing system. The ESN of the mobile station also needs to be given to the provider. This can happen in three ways:

Voice scenario -- A customer care representative collects credit info during a voice conversation. This call is made from a different phone (e.g., wired service) or is initiated using the IS-683A OTASP dialing scheme (i.e., *228xx).

Once the user has been authorized, the customer care rep creates a record in the CDMA network HLR, which allows use of the CDMA network. In addition, a limited-time N-digit password is created which is tied to the ESN. The choice of N (how many digits) is up to the carrier, as a trade-off between security and user inconvenience. All required provisioning info (including the limited-time password) is loaded into the provisioning server.

The user is then told to hang up and call a special number, of the form *228 XX <N-digit password> SEND (the XX code is the same as used in the initial voice call). This causes the mobile station to initiate a provisioning session.

The mobile station and the provisioning server authenticate, and all required provisioning info is downloaded into the mobile station. The user receives some form of notification once the activity is complete. This notification can be an audible tone or a text message on the mobile station display. (The form and content of this notification can be part of the provisioning data downloaded by the mobile station.) Once this initial provisioning activity is complete, the user has a fully authorized mobile station ready for use. 🎉

Forms scenario -- An interactive user interface is presented via a browser on the mobile station. The subscriber fills in the requested info. (Note that entering non-numeric data presents some user interface challenges on many mobile devices.) 🙈

A back-end server validates the info, and if possible, the customer is authorized, a limited-time password is generated, HLR and provisioning server records are created and the actual OTASP operation begins. Otherwise, a voice call is made to a customer care representative.

Desktop scenario -- The subscriber uses a desktop (or in-store kiosk) web browser to contact the carrier, and enters the usual personal info.

The carrier's server validates the info, and if possible, the customer is authorized, a limited-time password is generated, HLR and provisioning server records are created, and the subscriber is told to dial a special number on the handset. Once this code is entered, the actual OTASP operation begins. Otherwise, the user is asked to make a voice call to a customer care representative.

3.2. OTASP for Authorized Users

Users already authorized for use of the CDMA network can also initiate provisioning activity. This could happen after being directed to do so by a Customer Care representative, either from a phone conversation or via mail notification. This type of OTASP activity is needed in cases where the carrier wants to upgrade CDMA parameters in the mobile stations, or in cases where mobile station troubleshooting is needed.

This type of OTASP occurs in a similar fashion to the initial OTASP activity. The mobile station downloads the new provisioning info in the same way. 💜

3.3. OTAPA Activity 🦋

okay so bestie, OTAPA is all about upgrading a huge pile of mobile stations at once 📱✨ and the whole point is that it has to happen without getting in the way of the revenue-bearing CDMA network traffic 💅 nobody wants their network lagging during prime time 😭 OTAPA operations get kicked off at the customer care center 🎀. The move here is to queue up a notification to the mobile station (through 1-way SMS or a special caller-ID thing) once the provisioning server has the updated configuration data 💖. And OTAPA won't actually happen until the mobile has grabbed CDMA service on the carrier's network and the notification has landed 🫶

Another option is to put a recheck interval right into the set of data used to provision the mobile station 🌸 when you're using a low-overhead protocol like ACAP [ACAP], it totally makes sense for a mobile to check in every so often to see if anything has changed ✨ The time of day and/or day of week for those rechecks could also live in the provisioning data 🧚

Also, OTAPA activity can be terminated at any time because of user call activity 🙈 the user always comes first, periodt 👑

4. Requirements ✨

4.1. General Requirements 🌈

okay so IS-683A OTASP stuff happens between a mobile station and an over-the-air service provisioning function (OTAF) using IS-95A traffic channel data burst messages 📡 and OTASP/OTAPA via data services needs the CDMA carrier to have an IS-707 data services capable network 💅. The IS-707 service has to be either Packet Data Service (IS-707.5) or Quick-Net-Connect (QNC) 🦋

The mobile station MUST support:

  • IS-707 Data Service capability 💖
  • Packet/QNC RLP protocol 🌸
  • PPP protocol to peer to the IS-707 IWF 🧚
  • IP protocol to provide the network layer for routing to the provisioning server 🌐
  • A transport layer for end-to-end communication (such as TCP) 🫶
  • Authentication and optionally encryption 🔐
  • Application software to handle the provisioning protocol and memory access ✨
  • Domain Name System (DNS) query capabilities sufficient to obtain the (IP) address of the provisioning server (or the provisioning server's address could be provided during PPP negotiation) 💜

Lastly, the ability MUST exist for the mobile to make a data call (optionally) a voice call without a MIN 🎀

ngl the big takeaway here is that the mobile needs a whole toolkit, bestie 🧰💀

4.2. OTASP Requirements 💅

The OTASP function requires the mobile station to originate an IS-707 data call and (optionally) a voice call using a completely unprovisioned mobile station 📞 The CDMA network MUST support this capability 🔥

OTASP via data services uses a provisioning server that holds the parameter information for mobile stations 🗂️ The authorizing agent (or software) at the customer care center MUST be able to add user and mobile station information into both the CDMA network HLR and the provisioning server during the initial authorizing process 🎀 And the provisioning server MUST be capable of servicing a mobile as soon as its record is created 💖

4.3. OTAPA Requirements 🦋

IS-683A OTAPA is performed by a mobile-terminated call that downloads parameters to the mobile station 📲 OTAPA calls happen without any user interaction 🙈

To run OTAPA via data services, the network needs to direct the mobile station to start a special-purpose data call 🚀 There are a few existing methods for this, like a mobile-terminated one-way SMS message 💌 The SMS content can hold any info the mobile station needs 🧚 The mobile station would need a simple SMS parser so it knows when to originate an OTAPA call instead of doing normal SMS processing ✨ The OTAPA call would work similarly to a registration call, and more specifically, the user would not be informed of the call activity 🤫

There are other ways to kick off OTAPA too, like a mobile-terminated voice call with caller-ID using a specialized telephone number 📱 Another option is for mobile stations to check in with the provisioning server every so often to look for updated info 🌸 ACAP, for example, is built for that kind of model 💜 The recheck interval, plus the time of day and/or day of week those checks should happen, can be part of the provisioning data sent to the mobile stations 🫶

4.4. Provisioning Server Requirements 🖥️

IS-683A uses an over-the-air service provisioning function (OTAF) for the network-side provisioning work 📡 OTASP/OTAPA via data services swaps the OTAF out for a provisioning server 💅 The provisioning server lives on an IP network inside the carrier's controlled walls 🏰 It MUST perform all the service provisioning and parameter administration functions that the OTAF provides 💪 It MUST also have an interface to the carrier's Mobile Terminal Authorizing System (MTAS) 🔗 This interface keeps the provisioning server in sync with the MTAS info 🔄 What exactly this interface needs depends on the capabilities and interfaces of the carrier's customer care center system(s) 🎀 The provisioning server MUST be able to receive dynamic updates from the MTAS and have the provisioning info ready to download into the chosen mobile station immediately ⚡ A standard ACAP server is an excellent way to meet these requirements 🌟

The provisioning server MUST be capable of performing an authentication procedure with the mobile station 🔐 That authentication mechanism MUST be capable of authenticating both the mobile station and the provisioning server 🫶

4.5. Security Requirements 🔐

OTASP requires an authentication procedure to validate the mobile station to the provisioning server 📱 while OTAPA requires a mechanism where the mobile validates the server 🛡️

The provisioning server MUST be capable of either:

  • OTAF A-key generation using a Diffie-Hellman mechanism 🔑

Or:

  • Receiving A-keys from the carrier network 📡

Since data OTASP/OTAPA runs over IP within the carrier's network, end-to-end encryption between the mobile station and the provisioning server SHOULD be considered as a future enhancement 🔮 End-to-end encryption protects against attacks from within a carrier's network 🚫 and safeguards the provisioning data (for example, roaming lists) 💎

5. Architecture 🏗️

5.1. ACAP over TCP/IP 🌐

Figure 1 shows a provisioning server in the carrier's intranet that supports the Application Configuration Access Protocol (ACAP, RFC 2244) 📖 An administrative client in the customer care domain updates this server using ACAP 💻 Handsets get provisioned and configured using a small ACAP client 📱

                [Figure 1 -- see PostScript version]

ACAP is an open Internet protocol designed to solve the problem of client access to configuration and related data 🌸 Among its primary goals are protocol simplicity, support for thin clients, and ease of operation over limited bandwidth 🦋 ACAP provides a high degree of extensibility, especially in authentication mechanisms, specialized attribute handling, and data management 🧩

5.1.1. Mobile Authentication and A-Key Generation 🔑

The mobile client authenticates with the ACAP server before doing any activities 🔐 Authentication uses the mobile's ESN and a shared secret 🤝 Provisioned mobiles derive the shared secret from the A-Key, while unprovisioned mobiles use a limited-time password as the secret ⏳

The limited-time password is given to the user by the Customer Care representative during the initial call (as instructions to dial a specific number) 📞 This code is N digits long 🔢 The carrier picks the number of digits, as a trade-off between security and user convenience ⚖️

The baseline ACAP authentication mechanism uses the shared secret plus a random challenge from the server as input to a one-way cryptographic hash function (specifically, keyed-MD5) 🧮 This is analogous to the existing IS-683A authentication mechanism, which uses a random challenge and the CAVE algorithm 💜

An A-Key is generated using a Diffie-Hellman exchange, just like in IS-683A 🗝️

5.1.2. Mobile Identification 🪪

Provisioning records are identified using the ESN and the current NAM in use 📇

5.1.3. ACAP Server 🖥️

As a standard ACAP server, the provisioning server includes configurable datasets and dataset inheritance for managing the data stores 🗃️

The administrative client can use the same simple ACAP protocol to load and modify the ACAP server that the mobile stations use for provisioning 🔁 While any implementation-specific mechanisms from the server vendor could be used for this instead, being able to use ACAP can greatly simplify the administrative client and make it independent of the server 🙌

ACAP includes an authentication framework (Simple Authentication and Security Layer, SASL, RFC 2222)[SASL] 🛡️ SASL allows any standard or custom authentication and encryption mechanism to be used 🔓 One of the most important features of SASL is that it's designed for a world where what's "good enough" security today isn't good enough tomorrow ⏩ As the threat model changes, SASL lets higher-strength mechanisms be added easily while still supporting already deployed clients and servers 💪 SASL is seeing widespread deployment across a bunch of Internet protocols 🌍

Strongpoints: ACAP was designed for exactly this type of provisioning activity, so adopting it can greatly reduce the cost, time to market, and support needed for the provisioning server 💰 It also gives mobile stations and other systems an open standard method to access the provisioning server 🔓 Commercial ACAP servers are being built by lots of companies 🏢 The ACAP client code is very small and simple, so it can be put into virtually any mobile device at minimal cost 📉 And as an open standard, ACAP has benefited from years of review and experience 🎓

5.1.4. Overview of ACAP Structure

okay so ACAP organizes everything into datasets 📁✨ and the shape of a dataset is defined by its dataset class. The really iconic part is that ACAP servers usually don't need to know anything about dataset classes 🙈 So you can expand a dataset without touching the server at all. A dataset is basically an instance of the dataset class, which is the logical definition of what's inside it and how it gets used. 💅

Datasets hold entries, and entries hold attributes and values. Those attributes and values are really just metadata, like a name, a length, and a value 🎀 And here's the plot twist: any entry can also be a dataset, so datasets are hierarchical. Dataset inside dataset inside dataset, it's giving nesting doll energy 🪆

Let's make it concrete with the ACAP addressbook dataset class 📇 It's built to hold names, email addresses, phone numbers, and related info for a person's contacts. One user can have one or more addressbook datasets. Each entry is about one person or entity, and the attributes inside it hold the specific bits, like given name, surname, a bunch of email addresses, phone numbers, and so on 💖 If an entry is a list of people, like a mailing list or a group, it becomes a subdataset with its own entries inside. Some clients only care about a few attributes 🦋 For example, a mobile handset client might only download the alias (nickname), name, primary phone number, and email address for each entry, while a desktop client can grab every attribute. Different vibes, same data 🌸

5.1.5. Data Organization and Capabilities

ACAP gives you custom hierarchical datasets, so the server data can be arranged however the apps using it need 🧚

In OTASP/OTAPA over ACAP, the data on the server is set up to do two things at once: use ACAP's capabilities, and use items that are identical to IS-683A. That means IS-683A handset engines can be reused, which is honestly so smart 👑

ACAP servers also support data inheritance 🌳 Any data item that physically lives in the inherited dataset, and isn't also in the inheriting dataset, logically exists in the inheriting dataset too. It's recursive, because the inherited dataset can inherit from yet another dataset. This is a huge deal, because it lets potentially massive groups of mobile stations inherit items from one shared common entity 🔥 For example, preferred roaming lists can live in datasets based on geographic areas, and an individual mobile station in that area automatically inherits them. The roaming lists could even be split further, like by tiers of free NVRAM in the mobile 🤯 The mobile client doesn't have to know any of this, because it all happens on the server. Zero effort on the handset, maximum slay 💅

ACAP uses trees for its data hierarchy 🌲 You can think of them like the directory/file structure every common operating system uses. The built-in inheritance plus the hierarchy makes it super easy to update general data without disturbing the specific stuff 🫶

Datasets live inside the user, group, and host hierarchies. The user hierarchy holds datasets that belong to individual users. The group hierarchy holds datasets that belong to groups, like the "Region." groups in section 5.1.6.3 (Server Roaming Lists). The host hierarchy holds datasets for specific machines or systems 🖥️

On top of customizable data trees, ACAP also ships several standard datasets for every client 🎁 There's a capabilities dataset with info on custom functionality and enhanced features that are available to a specific client or to the site overall. This lets a server advertise any protocol extensions, specialized attribute handling, or other enhanced functionality it supports. So a client that wants to use those features can check what's available before trying to use them. No guessing, no vibes-based debugging 🙌

5.1.5.1. Structure

We split the data the client accesses into provisioning items, group items, and client state items 🗂️ Provisioning data holds NAM items and requested-data items. Group items, like preferred roaming lists, aren't tied to any specific mobile device. They physically live in their own datasets, but through inheritance they logically show up in client datasets ✨

The mobile stations always read from provisioning entries and write to client state entries 🎯 This structure keeps both the mobile clients and the server configuration easy and simple, while still leaving room for extensive custom and diagnostic capabilities. Clean, bestie 💜

5.1.5.2. Conventions

"" is the empty string, and it's used here for ACAP entries 🫧

~ is shorthand for "user/<userid>". It's part of the ACAP protocol, so you'll be seeing it a lot 🦋

5.1.6 Dataset

Provisioning info lives in the "OTAP" dataset class 📦 (The full spec for this dataset is going to be published in a later document, so stay tuned 👀) Items with the "Provision." prefix are the ones that get downloaded to the mobile, and items with the "Client." prefix are the ones the client stores on the server 🎀

Provisioning data inside the OTAP dataset is a series of items, and each item gets its own entry. The entry name is the item name, and the "OTAP.VALUE" attribute holds the item value. This setup lets you get change notifications on a per-item basis, which is so satisfying 🔔

We picked the "Provision" and "Client" names to make various operations simpler 💁‍♀️ For example, the mobile client can grab every changed provisioning item by running a search that returns the "OTAP.VALUE" attribute of every entry whose name starts with "Provision" and whose modtime is later than the last time the client retrieved data. An admin client can also make a report of every client that hasn't gotten the latest update, by searching for entries named "Client" whose "OTAP.modtime" attribute is less than the value you want 📊

A partial list of items follows 📝

5.1.6.1. Entries and Attributes

dataset.inherit

This is a standard ACAP attribute that tells you where the inherited data lives. It sits in the "" entry (the entry with the empty name) inside each dataset 🧚

5.1.6.2. NAM Records

The OTAP dataset class has an entry for each provisioned mobile 📱 The standard location for provisioning records is:

/OTAP/USER/<esn>/<nam>/

This tree format lets you have multiple NAMs per ESN, which is giving flexibility 🙌 The specific entries hold data in IS-683A parameter block types.

For example, the CDMA NAM would be stored in an entry called:

/OTAP/USER/<esn>/<nam>/Provision.CDMA-NAM/

Here's how the NAM records get organized on the ACAP server 🗂️

CDMA/Analog NAM

Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.CDMA-AMPS-NAM/

OTAP.Value: {17} xx xx xx ... xx

The CDMA/Analog NAM entry from IS-683A (section 4.5.2.1) is at least 129 information bits, depending on how many SID NID list entries there are. It's stored as 17 (or more) octets of binary data, with padding used so you end up with a whole number of octets 💜

Mobile Directory Number

Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.MOBILE-DN/

OTAP.Value: {10} nnnnnnnnnn

The Mobile Directory Number from IS-683A has BCD-encoded digits that represent the phone number. It's stored as a string of 10 or more ASCII digits, like "6195551212" 📞

CDMA NAM

Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/

OTAP.Value: {13} xx xx xx ... xx

The CDMA-NAM entry from IS-683A (section 4.5.2.3) is at least 100 information bits, depending on how many SID-NID list entries there are. It's stored as 13 (or more) octets of binary data, with padding so it comes out to a whole number of octets 🌈

IMSI_T

Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.IMSI_T/

OTAP.Value: {7} xx xx xx xx xx xx xx

The IMSI_T entry from IS-683A (section 4.5.2.4) is 55 bits of info split across five fields. It's stored left-justified in 7 octets of binary data 🦋

5.1.6.3. Server Roaming Lists

The ACAP Server gets an entry for each different roaming list configuration for a carrier 🗺️ The example below assumes the roaming list differs by geography, with subdivisions for tiers of mobile free NVRAM. So for each region, there's a set of roaming lists for each free NVRAM range 💖

Also, a carrier can totally implement different or extra differentiation (like by phone vendor or product type) just by changing the dataset tree and assigning the right value to the "dataset.inherit" attribute in the provisioning records 🍓

/OTAP/GROUP/region.NorthEast/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthEast/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value

5.1.6.4. Requested-Data Record

Inside the OTAP dataset is an entry named "Provision.Requested-Data", and it has one attribute called "OTAP.Requested-Data" 📋 That attribute is multi-valued. It's either NIL or a list of strings, and each string is the name of one piece of data the server wants the client to supply.

After authenticating, the ACAP client sends a SEARCH command to get the values of the "OTAP.Requested-Data" attribute from the "Provision.Requested-Data" entry 🔍 Then the client handles whatever comes back (if anything) by sending a STORE command to set one or more attributes in the "Client" entry. Each attribute's value is either the matching mobile value (which can be an empty string if the item has no value), or the special value "[N/A]" if the item doesn't exist or isn't known on the mobile 🫶

This mechanism is super general 🌟 It can be used in the normal OTASP case to change the mobile's dataset to fit the mobile's condition. For example, inheritance could be set based on how much NVRAM is available, so one set of preferred roaming list data or another gets used. It can also come in handy in other situations, like pulling a complete set of mobile configuration parameters for diagnostic reasons 🔬✨

5.1.6.5. Sample Server Entry 🎀

okay so here's a sample ACAP server dataset entry for one mobile station 💅 the ESN is FB9876E and it's using NAM 1:

/OTAP/USER/FB9876E/1/

   entry              =   ""
   dataset.inherit    =   "/OTAP/GROUP/region.NorthEast/
                           free-nv.128-512/preferred.roaming.list/
                           OTAP.Value/"

   entry               =   "Provision.Requested-Data"
   OTAP.Requested-Data =   ("Phone-Make" "Phone-Model" "SW-Rev"
                            "Free-NVRAM")

   entry               =   "Client"
   OTAP.Phone-Make     =   "Qualcomm"
   OTAP.Phone-Model    =   "pdQ1900"
   OTAP.SW-Rev         =   "001.030.0908"
   OTAP.Free-NVRAM     =   "65536"
   OTAP.Last-Modtime   =   "199812181703"
   entry               =   "Provision.Mobile-DN"
   OTAP.Value          =   {10} 619 555 1234

   entry               =   "Provision.CDMA-NAM"
   OTAP.Value          =   {13} xx xx xx xx xx xx xx xx xx xx xx
                                       xx xx

this dataset is giving full transparency 👀 it shows the provisioning data that got downloaded into the phone, plus the client data the server asked for (the Requested-Data attribute) and the values for those items (the "Client" entry) ✨ it also proves the client successfully stored everything tied to the modtime "199812181703" 🙌 and ngl the best part is that this client inherits its data (aka the roaming lists) from the "NorthEast" region 🌸

5.1.7. Administrative Client 📋

the administrative client is the one loading the initial provisioning info into the server, including picking which roaming list to inherit 💼 it also keeps provisioning records updated as needed and pulls data for reports (like a list of clients that haven't been updated yet) 👀

data gets loaded into provisioning records with the ACAP STORE command 🫶 the admin client authenticates to the ACAP server with credentials that let it access datasets for mobiles.

when a new mobile gets authorized for service, the admin client creates the dataset by storing values that are specific to that device 💖 it also sets the "dataset.inherit" attribute so that anything not tied to the specific mobile gets inherited where it makes sense 🧚

  • Updates to user records

existing user records may need updating from time to time 🔄 like, a user might switch service plans or buy an extra or replacement mobile device, or the carrier might need to change some part of the provisioned data 💅

  • Perusal and editing of provisioning records

the admin client can provide general browse and edit capability for user records 👀

  • Report generation

the admin client can pull data from the ACAP server to make reports 📊 for example, after OTAPA activity, a carrier might want to find out which mobiles haven't been updated yet 🥺

  • Queuing of OTAPA sessions

depending on which OTAPA update procedures get picked (like SMS, CLID, or periodic recheck), the admin client may be the one kicking off the activity 🚀 this may or may not use an interface to the provisioning server 🤷‍♀️

5.1.8. Mobile Client 📱

the ACAP mobile client is a state machine that does the equivalent of IS-683A provisioning parameter information exchange and non-volatile memory storage 🧠 the ACAP Client state machine diagram (Figure 2) and descriptions are below 👇

                [Figure 2 -- see PostScript version]
  • Establish Transport Layer/Authenticate

authentication and/or encryption can happen at the application layer and/or at the network/transport layer 🔐

basic ACAP authentication happens in the application layer (aka within the ACAP session), and in its baseline form it uses the CRAM-MD5[CRAM-MD5] mechanism 🗝️ if you want, other mechanisms can be used that give more protection and encryption ✨ this all happens after the transport layer is established, as shown in the client state machine diagram above 💜

Figure 3 shows the CRAM-MD5 authentication mechanism for an unprovisioned mobile 📖 for provisioned mobiles, the shared secret is derived from the A-Key instead of the limited-time N-digit code used for unprovisioned devices 🔑

basic ACAP authentication is the preferred route for initial data-OTASP implementations 🙌 it's simple, easy to implement, and all the procedures and methods are already in place 💯 stronger SASL mechanisms and/or IPSec can roll out later without disrupting the deployed base 🌈

                [Figure 3 -- see PostScript version]
  • Requested-data SEARCH

the mobile ACAP client sends a search command asking the server to return the attribute "OTAP.Requested-Data" in the entry "Requested-Data" 🔍

  • Receive requested-data values

the server tells the client what to store by returning one or more values of requested-data in response to the Requested-Data SEARCH 📬

for example, the attribute "OTAP.Requested-Data" in the entry "Requested-Data" might contain four values: "phone-make", "phone-model", "SW-Rev", and "Free-NVRAM" 💖

  • STORE attribute list

if the response to the requested-data SEARCH returns any values, the client issues a STORE command 💌 each attribute in the STORE command matches one item of requested-data 🧩 if the client doesn't recognize an item, it stores the string "[n/a]" 🤷‍♀️

continuing with our example, the client uses this STORE command to write four attributes into the "Client" entry 📝 each attribute name is identical to one value of the OTAP.Requested-Data" attribute (with the prefix "OTAP." added) 🎀 each attribute value is determined by the respective mobile value 💅

in our example, this STORE command sets these attributes and values:

  • "OTAP.Phone-Make" = "Qualcomm
  • "OTAP.Phone-Model" = "pdQ1900
  • "OTAP.SW-Rev" = "001.030.0908"
  • "OTAP.Free-NVRAM" = "65536"
  • Provisioning data SEARCH

the mobile ACAP client sends a search command to grab any provisioning data that changed since it last checked in 🔄 (in the initial session, that means all of it 🤯)

this SEARCH command asks the server to return the "OTAP.Value" attribute of any entries whose name starts with "provision." (case-insensitive) and whose modtime is greater than the supplied value (which is zero for an unprovisioned mobile) 🧚

  • Receive provisioning data and modtime

the server sends back the provisioning items, each as one entry name and one attribute value 📦 the server's response to the SEARCH command includes the modtime of the latest entry returned ⏰

  • Save values

the mobile writes the returned values into NVRAM 💾

  • STORE modtime

the ACAP client stores the returned modtime on the server as an acknowledgement that the data was received and NVRAM got updated 🫶 receipt confirmed, periodt 💅

  • LOGOUT

the client issues the LOGOUT command 👋

  • Close transport layer

the client closes the TCP connection 🔚

  • End call

the data call is terminated 📴

5.2. WAP with ACAP 🦋

ACAP's big advantage is that it can easily coexist with a WAP-based mechanism, which gives carriers more options 💖

a carrier can deploy handsets into its service area that use WAP-based provisioning, if it wants, alongside handsets that use ACAP provisioning 🌸 all that's required is for the WAP server to contain a small ACAP client (or an interface to an ACAP server) ✨

Figure 4 shows how mobile stations can be configured using a WAP browser 🌐 by using an ACAP server for provisioning, carriers are free to deploy mobile stations that use WAP or ACAP at the same time, whichever they like 🙌 either way, the ACAP server is the source for provisioning data 👑

                [Figure 4 -- see PostScript version]

5.3. Network-Resident vs. Configuration Data 🧠

it's useful to recognize that wireless devices access two different types of carrier-provided data: network-resident and configuration 🫧 network-resident data lives primarily inside the carrier's network 🏢 examples include account status, billing detail, service plan options, etc 💳 mobiles may access this info for user display, but it resides in the network 🌐 configuration data, on the other hand, affects how the handset operates, is usually not shown to the user, and must persist in the device 🔧

for network-resident data, the obvious choice is the web 🕸️ the data is highly interactive and time-variant, which makes web browsers a reasonable solution 🌈 any appropriate web browser can be used, and there are lots of good reasons to put a web browser in a wireless device that has a display and can handle user interaction 💅

for configuration data, the best solution is ACAP 🎯 ACAP is optimized for the job, can be implemented quickly, needs a very small amount of memory, and doesn't depend on a display or any user interaction capability 💖

trying to use the same access method for both types of data unnecessarily complicates things 😩 it leads to more design, development, and debug time and expense, and makes it harder to offer low-cost devices 💸 since the two types of data fundamentally differ, it's good engineering practice to pick the optimal code and protocols for each one 🧚‍♀️

5.4. Intellectual Property Issues ⚖️

there are no known intellectual property issues with the ACAP solution ✨ the ACAP specification was developed within the IETF, and no ownership, patent, or other IP claims have been asserted 🙌 multiple independent vendors are building ACAP clients and servers, on top of the existing usage in deployed products 🔥

6. Handset Protocol Suites 🎀

6.1. ACAP over TCP/IP 📡

Figure 5 depicts the mobile station protocol suite for the ACAP over TCP/IP solution 🗺️ the mobile station can support both IS-683A OTASP and OTASP over ACAP 💜

                [Figure 5 -- see PostScript version]

7. IS-683A Compatibility 🦋

7.1. OTASP Operations ✨

okay so bestie, to keep things compatible and let handset devs reuse their existing IS-683A code 💅, the data formats used in OTASP over ACAP are identical to the ones in IS-683A 🎀. Section 5.1.5 Data Organization and Capabilities goes deeper on this 🧠

OTASP via IS-683A needs custom design and dev for each carrier's specific CDMA setup 🙄 which can seriously limit data management and makes the whole thing way less extensible 💀 Meanwhile OTASP over data can run on a generic IP network using an Internet standards-based capability that gives carriers extensible provisioning activities. it's giving flexibility 🦋

OTASP over data uses a traffic channel, whereas IS-683A OTASP runs over the limited-bandwidth signaling channel 📡

IS-683A OTASP is inherently simultaneous voice and data 🫶 which means the customer care rep can pull info from the mobile station while chatting with the user. OTASP over data is a data-only solution (at least for now) 🥺 so it's slightly more sequential and potentially problematic. Simultaneous voice and data will fix that issue ✨

7.2. OTASP Call Flow 🧚

The call flow diagram (Figure 6) shows the message sequence and operations for a typical IS-683A OTASP (provisioning) call 📊 Any data-OTASP solution has to perform all the functions of the IS-683A OTASP call. The proposed solution meets these requirements 💖

                [Figure 6 -- see PostScript version]

7.3. OTAPA Operations 🌸

Data-OTAPA needs the ability to instruct mobiles to originate a data call to the provisioning server 📞 Several viable approaches are discussed in sections 3.3 OTAPA Activity and 4.3 OTAPA Requirements 📚

OTAPA over data has the potential to need way fewer channel resources to download new info to mobile stations 🙌 The ACAP server only ever communicates changes to the clients, so only the changed information needs to be downloaded to the mobile stations using OTAPA over data via ACAP 🔥

7.4. OTAPA Call Flow 🦋

The call flow diagram (Figure 7) shows the message sequence for a typical IS-683A OTAPA operation 📈 Any data-OTAPA solution has to perform all the functions of the IS-683A OTAPA call. The proposed solution meets these requirements 👑

                [Figure 7 -- see PostScript version]

8. Alternative Methods 🌈

8.1. IS-683A over TCP/IP 🍓

one option is to port IS-683A to TCP 💅 staying as close as possible to the IS-683A protocol exchange 🎀

Figure 8 shows the architecture and communications backbone for supporting OTASP/OTAPA via IS-707 data services, with a provisioning server based on the IS-683A OTAF function 🧩

                [Figure 8 -- see PostScript version]

8.1.1. OTAF Server 👑

This provisioning server is modeled after the IS-683A OTAF 💖 The OTAF server does the specific operations and messaging of IS-683A OTAF, including A-key reauthentication procedures 🔐

Strongpoints:

(1) OTAF and mobile station behavior mirrors IS-683A, which means reduced duplicate software in the mobile station ✨ Nearly all procedures are fully defined 💯

Drawbacks:

(1) The OTAF server would need to be custom-designed and built 😩

(2) The OTAF server has no inherent data manipulation capabilities 🙈 All required or desired data management would have to be built from scratch 💀

(3) The interface application would need a non-standard (and therefore proprietary) interface to the OTAF server 🚫

(4) An end-to-end encryption scheme is still needed for full security 🔒

8.1.2. Interface Application 🧚

This function loads all required provisioning-related information from the CDMA network information system to the OTAF server 📥 It also handles queuing of provisioning transactions and data 🗂️

8.1.3. Protocol Handset Suite 📱

Figure 9 shows the mobile station protocol suite for the IS-683A over TCP/IP solution 🌟 The OTASP client can support both IS-683A OTASP activities and OTASP activities over the data transport 🫶

                [Figure 9 -- see PostScript version]

8.2. Browser-Based Forms 🌐

Another option is to use forms embedded in web pages 📝

Stuffing the provisioning data into custom tags inside a web form sounds super attractive at first 😍 There are a lot of perks to having a browser in the handset, web servers are everywhere, and everyone kinda knows the web already 🕸️

BUT a meta-protocol would need to be designed, and a fully detailed specification written 📜 This solution needs custom software on the provider side to handle the meta-protocol 🛠️ It also needs handset vendors to add custom software to the handset browser so it can handle the protocol 😬

This would mean every phone needs a provisioning-capable browser 📲 Having a browser can be desirable, but the decision to require one should be thought through carefully, especially given the memory requirements it would put on all devices 🧠

It would also complicate the handset browser, since it would have to handle provisioning as well as browsing 🤯 Provisioning and browsing are functionally dissimilar, so this code isn't a natural fit in the browser 🙅‍♀️ Implementing it would take a big jump in dev and debug resources, which hurts time-to-market and cost 💸

Also, because the web is functionally dissimilar, it would need a high level of carrier-side customization 🔧 That leads to reduced vendor choice and higher deployment costs 📉

This approach would layer custom data on top of a standard protocol 🥴 That means design work, not much time for open review before deployment, and a greatly increased risk ⚠️ ACAP, by contrast, has had years of open review and refinement 🏆

This approach also limits extensibility. ACAP is very extensible 🦋 Because it's such a simple protocol, it can be added to a wide variety of applications at low cost 💅 That lets more and more applications on the mobile device share information with servers as well as desktop applications 🌸

9. Conclusion 💜

ACAP gives a high degree of extensibility, especially in authentication mechanisms, custom attribute handling, and data management ✨ Since it's an Internet standard protocol, interoperability and integration with a variety of equipment is possible, and carriers aren't locked into any one vendor 🔓 It's also easier to add new levels of service and capabilities, especially integration with future subscriber devices and applications (e.g., email) 📧

An ACAP client is so small that it can be built into basically any device, even low-end ones without displays, and it can be added without sacrificing other features 🤏 The simplicity of the client and protocol directly translates to shorter development cycles and faster time-to-market 🚀

The ACAP protocol was designed for exactly this kind of provisioning activity, so adopting it can greatly reduce the cost, time to market, and support needed for both the provisioning server and the handsets 💖 As an open standard, ACAP has benefited from years of review and experience 🎓

Another perk: ACAP can easily coexist with a WAP-based mechanism 🥰 That gives carriers more options and reduces the minimal requirement burden on mobile devices 🌈

A carrier can deploy handsets into its service area that use WAP-based provisioning, if it wants, right alongside handsets that use ACAP provisioning 🎀 By using an ACAP server for provisioning, carriers are free to deploy mobile stations that use either WAP or ACAP at the same time, as desired 👑

And the lack of intellectual-property issues makes ACAP even more appealing 💅✨

10. References 📚

[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.

[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.

[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

11. Security Considerations 🔐

Okay, this one is SERIOUS bestie 😭🚨 Security is discussed in many sections of this document. In particular, it covers the need for, and methods of, guarding against unauthorized updating of handsets, usurpation of newly-created accounts, compromise of handset security values, and disclosure of carrier proprietary data and handset parameters 💀🛡️

12. Acknowledgments 🫶

Jim Willkie and Marc Phillips contributed hugely to this document 💖 Their help is very much appreciated 🌷

13. Author's Address 🎀

   Randall Gellens
   QUALCOMM Incorporated
   6455 Lusk Boulevard
   San Diego, CA  92121-2779

   Phone: +1 619 651 5115
   EMail: randy@qualcomm.com

The legal text below stays word-for-word, because copyright language can't be reworded 🙏

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💌

Funding for the RFC Editor function is currently provided by the Internet Society 🌸✨

📦 where this page comes from