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", , , "pab", ) 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", ) 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": "", "timestamp": , "card": } 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", , , "pab", ) 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///pab//msg/"] subscribe: ["mocha_v1///pab//*"] 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, . [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Authors' Addresses Cullen Jennings Cisco Email: fluffy@iii.ca Suhas Nandakumar Cisco Email: snandaku@cisco.com Jennings & Nandakumar Expires 7 January 2027 [Page 7]