MOCHA Personal Address Book
draft-jennings-moq-mocha-pab-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.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Cullen Fluffy Jennings , Suhas Nandakumar | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-jennings-moq-mocha-pab-00
Media Over QUIC C. Jennings
Internet-Draft S. Nandakumar
Intended status: Standards Track Cisco
Expires: 7 January 2027 6 July 2026
MOCHA Personal Address Book
draft-jennings-moq-mocha-pab-00
Abstract
This document defines how a set of devices owned by a common user
synchronize a Personal Address Book (PAB) over MOQT. The address
book maps identities to human-readable names and contact information,
enabling users to maintain a trusted contact list that is consistent
across all their devices.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-jennings-moq-mocha-pab/.
Discussion of this document takes place on the Media Over QUIC
Working Group mailing list (mailto:moq@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at
https://www.ietf.org/mailman/listinfo/moq/.
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 7 January 2027.
Jennings & Nandakumar Expires 7 January 2027 [Page 1]
Internet-Draft mocha-pab July 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Namespace and Track Structure . . . . . . . . . . . . . . . . 3
3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Track Name . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Group and Object Organization . . . . . . . . . . . . . . . . 4
4.1. Groups . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Contact Card Format . . . . . . . . . . . . . . . . . . . . . 4
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Operation Types . . . . . . . . . . . . . . . . . . . . . 5
5.3. Example: Adding a Contact . . . . . . . . . . . . . . . . 5
5.4. Example: Deleting a Contact . . . . . . . . . . . . . . . 5
6. Synchronization Model . . . . . . . . . . . . . . . . . . . . 5
6.1. Device Publishing . . . . . . . . . . . . . . . . . . . . 5
6.2. Device Subscribing . . . . . . . . . . . . . . . . . . . 6
6.3. Conflict Resolution . . . . . . . . . . . . . . . . . . . 6
6.4. Initial Sync . . . . . . . . . . . . . . . . . . . . . . 6
7. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
MOCHA users need to maintain a personal directory of contacts —
mapping user identities (e.g., alice@provider.example) to display
names and other metadata they trust. This address book must
synchronize across all devices belonging to the same user without
requiring a centralized contacts server.
Jennings & Nandakumar Expires 7 January 2027 [Page 2]
Internet-Draft mocha-pab July 2026
This document specifies:
* The MOQT namespace and track structure for address book data
* The contact card format (based on jCard [RFC7095])
* The synchronization model across a user's devices
* Group and object organization for efficient retrieval
2. Conventions and Definitions
See BCP 14 [RFC2119] [RFC8174].
This document uses terminology defined in [MOCHA-ARCH], including
Provider, Organization, UserID, and Device. HDevID is defined in
[MOCHA-IDENTITY].
The following additional terms are used:
Personal Address Book (PAB): A per-user collection of contact cards
synchronized across all of the user's devices via MOQT.
Contact Card: A single entry in the address book, encoded as a jCard
[RFC7095] object. Each card maps an identity to a human-readable
name and optional metadata.
3. Namespace and Track Structure
3.1. Namespace
The MOQT tracks carrying address book contact cards use the following
namespace tuple:
("mocha_v1", <Provider>, <OrgID>, "pab", <UserID>)
Where:
* Provider: The user's home provider domain
* OrgID: The organization the user belongs to
* pab: Literal string identifying this as a Personal Address Book
namespace
* UserID: The identity of the user who owns this address book
Jennings & Nandakumar Expires 7 January 2027 [Page 3]
Internet-Draft mocha-pab July 2026
3.2. Track Name
Each device publishes its address book updates on its own track:
Track Name: ("msg", <HDevID>)
Where HDevID identifies the publishing device. Each device maintains
its own track to avoid write conflicts between devices.
3.3. Example
Namespace: ("mocha_v1", "example.com", "acme", "pab", "alice")
Track: ("msg", "device-a3f2")
This represents the address book updates published by Alice's device
"device-a3f2" within the "acme" organization on provider
"example.com".
4. Group and Object Organization
4.1. Groups
There is one group per calendar month. This provides a natural time-
based partitioning that allows devices to efficiently fetch recent
changes without downloading the entire history.
Groups are numbered sequentially, with the group ID derived from the
month:
Group ID = (year - 2024) * 12 + (month - 1)
Example: June 2026 = (2026 - 2024) * 12 + (6 - 1) = 29
4.2. Objects
Each object within a group represents a single contact card operation
(add, update, or delete). Objects are sequentially numbered within
each group.
Namespace: ("mocha_v1", "example.com", "acme", "pab", "alice")
Track: ("msg", "device-a3f2")
Group: 29 (June 2026)
Object: 0, 1, 2, ... (sequential operations)
5. Contact Card Format
Jennings & Nandakumar Expires 7 January 2027 [Page 4]
Internet-Draft mocha-pab July 2026
5.1. Overview
Each object payload is a JSON [RFC8259] document containing a contact
card operation. The card data follows the jCard format defined in
[RFC7095].
5.2. Operation Types
{
"op": "add" | "update" | "delete",
"id": "<contact identity>",
"timestamp": <unix timestamp>,
"card": <jCard object (for add/update)>
}
5.3. Example: Adding a Contact
{
"op": "add",
"id": "bob@example.com",
"timestamp": 1751000000,
"card": ["vcard", [
["version", {}, "text", "4.0"],
["fn", {}, "text", "Bob Smith"],
["email", {}, "text", "bob@example.com"]
]]
}
5.4. Example: Deleting a Contact
{
"op": "delete",
"id": "bob@example.com",
"timestamp": 1751100000
}
6. Synchronization Model
6.1. Device Publishing
Each device publishes contact card operations to its own track. When
a user adds, modifies, or deletes a contact on any device, that
device publishes a new object to the current month's group on its
track.
Jennings & Nandakumar Expires 7 January 2027 [Page 5]
Internet-Draft mocha-pab July 2026
6.2. Device Subscribing
Each device subscribes to the tracks of all other devices belonging
to the same user. This is achieved by subscribing to the PAB
namespace:
SUBSCRIBE_NAMESPACE ("mocha_v1", <Provider>, <OrgID>,
"pab", <UserID>)
The relay delivers objects from all device tracks within this
namespace, allowing each device to learn of changes made on other
devices.
6.3. Conflict Resolution
When multiple devices publish conflicting operations (e.g., both
update the same contact), the operation with the latest timestamp
wins. If timestamps are equal, the operation from the
lexicographically greater HDevID takes precedence.
6.4. Initial Sync
A newly added device subscribes starting from the earliest available
group to reconstruct the full address book state. The device applies
all operations in group and object order, with later operations
overriding earlier ones for the same contact identity.
7. Authorization
Access to a user's PAB namespace is restricted to that user's own
devices. The Token Service issues C4M tokens (or Privacy Pass
tokens) scoped to the user's PAB namespace:
publish: ["mocha_v1/<provider>/<org>/pab/<user_id>/msg/<own-device>"]
subscribe: ["mocha_v1/<provider>/<org>/pab/<user_id>/*"]
Each device can only publish to its own track but can subscribe to
all tracks within the user's PAB namespace.
8. Security Considerations
TODO
9. IANA Considerations
This document makes no requests of IANA.
10. Normative References
Jennings & Nandakumar Expires 7 January 2027 [Page 6]
Internet-Draft mocha-pab July 2026
[MOCHA-ARCH]
"*** BROKEN REFERENCE ***".
[MOCHA-IDENTITY]
Jennings, C. F. and S. Nandakumar, "MOCHA Identity:
Authentication, Authorization, and Federation", Work in
Progress, Internet-Draft, draft-jennings-moq-mocha-
identity-00, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-jennings-moq-
mocha-identity-00>.
[MoQTransport]
Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
"Media over QUIC Transport", Work in Progress, Internet-
Draft, draft-ietf-moq-transport-18, 12 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
transport-18>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/rfc/rfc7095>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
Authors' Addresses
Cullen Jennings
Cisco
Email: fluffy@iii.ca
Suhas Nandakumar
Cisco
Email: snandaku@cisco.com
Jennings & Nandakumar Expires 7 January 2027 [Page 7]