Virtualized Conversations D. G Petrie Internet-Draft SIPez LLC Intended status: Standards Track 31 October 2026 Expires: 4 May 2027 The JSON format for vCon - Conversation Data Container draft-ietf-vcon-vcon-core-05 Abstract vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ietf-wg- vcon.github.io/draft-ietf-vcon-vcon-core/draft-ietf-vcon-vcon- core.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-vcon-vcon-core/. Discussion of this document takes place on the Virtualized Conversations Working Group mailing list (mailto:vcon@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/vcon/. Subscribe at https://www.ietf.org/mailman/listinfo/vcon/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-vcon/draft-ietf-vcon-vcon-core. 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/. Petrie Expires 4 May 2027 [Page 1] Internet-Draft JSON vCon October 2026 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 4 May 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Purpose of vCon . . . . . . . . . . . . . . . . . . . . . 6 1.2. Extending the vCon Schema . . . . . . . . . . . . . . . . 6 1.3. Benefits of vCon . . . . . . . . . . . . . . . . . . . . 7 1.4. *Scope of the Document* . . . . . . . . . . . . . . . . . 7 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. JSON Notation . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Inline Files . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. body . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. encoding . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Externally Referenced Files . . . . . . . . . . . . . . . 12 2.4.1. url . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2. content_hash . . . . . . . . . . . . . . . . . . . . 12 2.5. Extending vCon . . . . . . . . . . . . . . . . . . . . . 12 3. vCon JSON Object . . . . . . . . . . . . . . . . . . . . . . 15 4. Unsigned Form of vCon Object . . . . . . . . . . . . . . . . 16 4.1. vCon JSON Object Keys and Values . . . . . . . . . . . . 16 4.1.1. vcon . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2. uuid . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.3. extensions . . . . . . . . . . . . . . . . . . . . . 17 4.1.4. critical . . . . . . . . . . . . . . . . . . . . . . 17 4.1.5. created_at . . . . . . . . . . . . . . . . . . . . . 18 4.1.6. updated_at . . . . . . . . . . . . . . . . . . . . . 18 4.1.7. subject . . . . . . . . . . . . . . . . . . . . . . . 18 Petrie Expires 4 May 2027 [Page 2] Internet-Draft JSON vCon October 2026 4.1.8. redacted_from . . . . . . . . . . . . . . . . . . . . 18 4.1.9. amended_from . . . . . . . . . . . . . . . . . . . . 21 4.1.10. sessions Objects Array . . . . . . . . . . . . . . . 22 4.1.11. parties Objects Array . . . . . . . . . . . . . . . . 25 4.1.12. events Objects Array . . . . . . . . . . . . . . . . 25 4.1.13. dialog Objects Array . . . . . . . . . . . . . . . . 25 4.1.14. analysis Objects Array . . . . . . . . . . . . . . . 25 4.1.15. attachments Objects Array . . . . . . . . . . . . . . 26 4.1.16. redacted_strings Objects Array . . . . . . . . . . . 26 4.2. Session Object . . . . . . . . . . . . . . . . . . . . . 28 4.2.1. start . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2.2. duration . . . . . . . . . . . . . . . . . . . . . . 29 4.2.3. parties . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.4. originator . . . . . . . . . . . . . . . . . . . . . 30 4.2.5. session_id . . . . . . . . . . . . . . . . . . . . . 31 4.2.6. sessions . . . . . . . . . . . . . . . . . . . . . . 31 4.2.7. dialog . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.8. Session_Reference Object . . . . . . . . . . . . . . 31 4.3. Event Object . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1. type . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3.2. time . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.3. sessions . . . . . . . . . . . . . . . . . . . . . . 42 4.3.4. party . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.5. dialog . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.6. channel . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.7. contributors . . . . . . . . . . . . . . . . . . . . 44 4.3.8. button . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.9. transferee . . . . . . . . . . . . . . . . . . . . . 45 4.3.10. transfer_target . . . . . . . . . . . . . . . . . . . 45 4.3.11. consultation . . . . . . . . . . . . . . . . . . . . 45 4.3.12. target_session . . . . . . . . . . . . . . . . . . . 46 4.4. Party Object . . . . . . . . . . . . . . . . . . . . . . 46 4.4.1. tel . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4.2. sip . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.3. stir . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.4. mailto . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.5. name . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.6. did . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.7. validation . . . . . . . . . . . . . . . . . . . . . 48 4.4.8. gmlpos . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.9. civicaddress . . . . . . . . . . . . . . . . . . . . 49 4.4.10. uuid . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.11. type . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.12. org . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.13. dept . . . . . . . . . . . . . . . . . . . . . . . . 51 4.5. Dialog Object . . . . . . . . . . . . . . . . . . . . . . 51 4.5.1. type . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5.2. start . . . . . . . . . . . . . . . . . . . . . . . . 56 Petrie Expires 4 May 2027 [Page 3] Internet-Draft JSON vCon October 2026 4.5.3. duration . . . . . . . . . . . . . . . . . . . . . . 56 4.5.4. parties . . . . . . . . . . . . . . . . . . . . . . . 56 4.5.5. mediatype . . . . . . . . . . . . . . . . . . . . . . 59 4.5.6. filename . . . . . . . . . . . . . . . . . . . . . . 60 4.5.7. Dialog Content . . . . . . . . . . . . . . . . . . . 60 4.5.8. disposition . . . . . . . . . . . . . . . . . . . . . 60 4.5.9. session_id . . . . . . . . . . . . . . . . . . . . . 61 4.5.10. application . . . . . . . . . . . . . . . . . . . . . 62 4.5.11. message_id . . . . . . . . . . . . . . . . . . . . . 62 4.5.12. redacted_segments . . . . . . . . . . . . . . . . . . 62 4.6. Attachment Object . . . . . . . . . . . . . . . . . . . . 63 4.6.1. purpose . . . . . . . . . . . . . . . . . . . . . . . 63 4.6.2. start . . . . . . . . . . . . . . . . . . . . . . . . 64 4.6.3. party . . . . . . . . . . . . . . . . . . . . . . . . 64 4.6.4. dialog . . . . . . . . . . . . . . . . . . . . . . . 64 4.6.5. session . . . . . . . . . . . . . . . . . . . . . . . 64 4.6.6. mediatype . . . . . . . . . . . . . . . . . . . . . . 65 4.6.7. filename . . . . . . . . . . . . . . . . . . . . . . 65 4.6.8. Attachment Content . . . . . . . . . . . . . . . . . 65 4.7. Analysis Object . . . . . . . . . . . . . . . . . . . . . 66 4.7.1. type . . . . . . . . . . . . . . . . . . . . . . . . 66 4.7.2. dialog . . . . . . . . . . . . . . . . . . . . . . . 66 4.7.3. sessions . . . . . . . . . . . . . . . . . . . . . . 67 4.7.4. attachment . . . . . . . . . . . . . . . . . . . . . 67 4.7.5. analysis . . . . . . . . . . . . . . . . . . . . . . 67 4.7.6. mediatype . . . . . . . . . . . . . . . . . . . . . . 68 4.7.7. filename . . . . . . . . . . . . . . . . . . . . . . 68 4.7.8. vendor . . . . . . . . . . . . . . . . . . . . . . . 68 4.7.9. product . . . . . . . . . . . . . . . . . . . . . . . 69 4.7.10. schema . . . . . . . . . . . . . . . . . . . . . . . 69 4.7.11. Analysis Content . . . . . . . . . . . . . . . . . . 69 4.8. Redacted_string Object . . . . . . . . . . . . . . . . . 70 4.8.1. Ref . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.8.2. Type . . . . . . . . . . . . . . . . . . . . . . . . 70 4.8.3. Orig . . . . . . . . . . . . . . . . . . . . . . . . 71 5. Redaction Techniques . . . . . . . . . . . . . . . . . . . . 71 5.1. Recording Content Removal . . . . . . . . . . . . . . . . 72 5.2. Participant Information Hiding . . . . . . . . . . . . . 72 5.3. Audiovisual Content Rewriting . . . . . . . . . . . . . . 72 5.4. String Redaction . . . . . . . . . . . . . . . . . . . . 72 5.5. Regeneration of the vCon . . . . . . . . . . . . . . . . 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 73 6.1. Signing Externally Referenced Files . . . . . . . . . . . 75 6.2. Signed Form of vCon Object . . . . . . . . . . . . . . . 76 6.2.1. Signature Object . . . . . . . . . . . . . . . . . . 76 6.2.2. Header Object . . . . . . . . . . . . . . . . . . . . 77 6.2.3. Long Term Archiving of Signed vCons . . . . . . . . . 77 6.3. Encrypted Form of vCon Object . . . . . . . . . . . . . . 78 Petrie Expires 4 May 2027 [Page 4] Internet-Draft JSON vCon October 2026 6.3.1. Unprotected Object . . . . . . . . . . . . . . . . . 79 6.3.2. Recipient Object . . . . . . . . . . . . . . . . . . 80 6.3.3. Header Object . . . . . . . . . . . . . . . . . . . . 80 6.4. Differentiation of vCon forms . . . . . . . . . . . . . . 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 7.1. JSON Format vCon Mediatype . . . . . . . . . . . . . . . 81 7.2. gzip Format vCon Mediatype . . . . . . . . . . . . . . . 82 7.3. vCon JSON Registry . . . . . . . . . . . . . . . . . . . 83 7.3.1. Object Registry Template . . . . . . . . . . . . . . 84 7.3.2. vCon Object Parameter Names Registry . . . . . . . . 84 7.3.3. Party Object Parameter Names Registry . . . . . . . . 86 7.3.4. Dialog Object Parameter Names Registry . . . . . . . 88 7.3.5. Session Object Parameter Names Registry . . . . . . . 90 7.3.6. Session_Reference Object Parameter Names Registry . . 91 7.3.7. Event Object Parameter Names Registry . . . . . . . . 93 7.3.8. Attachment Object Parameter Names Registry . . . . . 97 7.3.9. Analysis Object Parameter Names Registry . . . . . . 98 7.3.10. Redacted_from Object Parameter Names Registry . . . . 99 7.3.11. Amended_from Object Parameter Names Registry . . . . 99 7.4. vCon Extensions Names Registry . . . . . . . . . . . . . 100 7.4.1. Extensions Registration Template . . . . . . . . . . 100 7.5. JSON Web Signature and Encryption Header Parameters . . . 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 101 8.2. Informative References . . . . . . . . . . . . . . . . . 103 Appendix A. Non-Upward Compatible Changes to the vCon Container . . . . . . . . . . . . . . . . . . . . . . . . 105 A.1. Version 0.4.0 to 0.5.0 . . . . . . . . . . . . . . . . . 105 A.2. Version 0.3.0 to 0.4.0 . . . . . . . . . . . . . . . . . 107 A.3. Version 0.0.2 to 0.3.0 . . . . . . . . . . . . . . . . . 107 A.4. Version 0.0.1 to 0.0.2 . . . . . . . . . . . . . . . . . 107 Appendix B. Example vCons . . . . . . . . . . . . . . . . . . . 107 B.1. Two Party Call vCon With Inline Recording . . . . . . . . 107 B.2. Email Thread Multipart vCon . . . . . . . . . . . . . . . 113 B.3. Email Thread Text vCon . . . . . . . . . . . . . . . . . 116 B.4. Two Party Call vCon With Externally Referenced Recording . . . . . . . . . . . . . . . . . . . . . . . . 118 B.5. Two Party Call vCon with Analysis . . . . . . . . . . . . 121 B.6. Signed vCon . . . . . . . . . . . . . . . . . . . . . . . 144 B.7. Encrypted vCon . . . . . . . . . . . . . . . . . . . . . 147 B.8. Redacted vCon . . . . . . . . . . . . . . . . . . . . . . 151 B.9. Amended Signed vCon . . . . . . . . . . . . . . . . . . . 155 Appendix C. vCon JSON Schema . . . . . . . . . . . . . . . . . . 157 Appendix D. vCon CDDL . . . . . . . . . . . . . . . . . . . . . 194 Appendix E. vCon Extension Template . . . . . . . . . . . . . . 208 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 208 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 209 Petrie Expires 4 May 2027 [Page 5] Internet-Draft JSON vCon October 2026 1. Introduction This document specifies the *vCon* (Conversational Data Exchange) standard, which defines a unified format for representing and exchanging conversational data across different communication platforms and modalities. The goal of *vCon* is to provide a standardized, platform-agnostic structure for capturing and sharing conversational information, allowing for seamless integration between systems, enterprises, and trust boundaries. 1.1. Purpose of vCon The *vCon* standard enables the abstraction of conversation data, making it easier to integrate communication platforms with external services, including post-conversation analysis tools, customer support systems, and business intelligence platforms. By defining a consistent data format, *vCon* ensures interoperability across various platforms, regardless of the communication mode - whether text, audio, video, or other formats. The *vCon* format captures the essential components of a conversation, including metadata, media content, related documents, and post-conversation analysis. This abstraction simplifies data exchange, enables AI-driven analysis, and supports model training and testing. 1.2. Extending the vCon Schema In addition to the core *vCon* schema, this document provides a framework for extending the *vCon* format to support specialized use cases. The *vCon* schema can be customized to address the needs of specific industries or applications, such as: * *Contact Centers*: Adding specific metadata related to customer service interactions, case management, and priority tracking. * *Messaging Platforms*: Supporting the integration of different message formats, including SMS, email, and chat, group concepts, along with platform-specific information. * *ECRIT (Emergency Communication) Centers*: Extending the schema to capture critical data such as location, urgency, and incident details for emergency communications. The ability to add extensions ensure that *vCon* remains flexible and adaptable, enabling its use in a wide range of domains while maintaining a consistent format for data exchange. Petrie Expires 4 May 2027 [Page 6] Internet-Draft JSON vCon October 2026 1.3. Benefits of vCon The *vCon* standard offers several key benefits: * *Interoperability*: A consistent data format for conversational data facilitates integration across diverse platforms and systems. * *AI-Driven Analysis*: By capturing data in a structured format, *vCon* enables the application of AI analysis such as sentiment analysis, categorization, transcription, and decision-making. * *Data Automation*: The *vCon* format simplifies the automation of processes involving conversational data, improving efficiency and reducing the risk of errors. * *Enterprise Integration*: The ability to integrate conversation data with third-party tools and services enhances the value of conversations by providing deeper insights and driving business decisions. 1.4. *Scope of the Document* This document defines the core structure and schema for *vCon* as a JSON format. Detailed specifications for the various parameters and the extension framework will be provided in subsequent sections. The primary focus is on creating a flexible, extensible standard for the exchange of conversational data that can be easily adopted across industries, use cases, and communication technologies. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Terminology * analysis - analysis, transformations, summary, sentiment, or translation typically of the dialog data * contributor - a party that generated, or potentially generated, any part of the Dialog Content of a Dialog Object * conversation - an exchange of communication using text, audio or video medium between at least one human and one or more bots or humans Petrie Expires 4 May 2027 [Page 7] Internet-Draft JSON vCon October 2026 * de-identification - removal of all information that could identify a party in a conversation. This includes PII as well as audio and video recordings. Voice recordings might be re-vocalized with a different speaker. * dialog - the captured conversation in its original form (e.g. text, audio or video) * encrypted form - encrypted JWE document with the JWS signed vCon form contained in the ciphertext * file - a data block either included or referenced in a vCon * object - JSON object containing key and value pairs * parameter - JSON key and value pair * party - an observer, facilitator or participant to the conversation, either passive or active, which may be a contributor, a receiver, both or neither (e.g. the organizer of a conference) * payload - the contents or bytes that make up a file * PII - Personal Identifiable Information * PII masked - may include voice recordings, but PII is removed from transcripts and recordings (audio and video). * receiver - a party to which any part of the dialog in a session was sent and potentially received * regex - a regular expression, a sequence of characters that defines a search pattern used to match, locate or validate strings of text * vCon - container for conversational information * vCon instance - a vCon populated with data for a specific conversation * vCon instance version - a single version of an instance of a conversation, which may be modified to redact or amend additional information forming a subsequent vCon instance version * vCon syntax version - the version for the data syntax used for form a vCon Petrie Expires 4 May 2027 [Page 8] Internet-Draft JSON vCon October 2026 * signed form - JWS signed document with the unsigned vCon form contained in the payload 2.2. JSON Notation For the ease of documentation, the convention for [JSON] notation used in this document is copied from sections 1.1-1.5 of [JMAP]. * Date - A string that MUST have the form of an [RFC3339] date string as defined for the Date type in section 1.4 of [JMAP]. * "*" - The type is undefined; the value can be any JSON type, although permitted values may be constrained by the context of the value, as defined in section 1.1 of [JMAP]. * "String" - a JSON string type. * "UnsignedInt" - a positive JSON integer as defined in section 1.3 of [JMAP]. * "UnsignedFloat" - a positive JSON floating point number containing a decimal point as defined in section 6 of [JSON]. * "Mediatype" - A "String" value that MUST be of the following form as defined in section 5.1 of [MIME]: type "/" subtype Petrie Expires 4 May 2027 [Page 9] Internet-Draft JSON vCon October 2026 * "ContentHash" - The string token value is generated using the same approach used in section 6 of [STIR-PASS]. The relevant text is copied here for convenience and to remove the normative dependency. The hash string token values are formed from combining a string that defines the crypto algorithm used to generate the digest along with the Base64Url Encoded value of the SHA-512 hash, as defined in section 6.3 and 6.4 [SHA-512], of the body of the content at the given url. The hash algorithm is identified by "sha512". SHA-512 is part of the SHA-2 set of cryptographic hash functions [SHA-512] defined by the US National Institute of Standards and Technology (NIST). Implementations MAY support additional recommended hash algorithms in [IANA-COSE-ALG]; that is, the hash algorithm has "Yes" in the "Recommended" column of the IANA registry. Hash algorithm identifiers MUST use only lowercase letters, and they MUST NOT contain hyphen characters. The character following the algorithm string MUST be a hyphen character, "-", or ASCII 45. The subsequent characters are the Base64Url encoded (see Section 2 [JWS]) digest of a canonicalized and concatenated string or binary data based on the JSON pointer referenced elements of "rcd" claim or the URI referenced content contained in the claim. * "SessionId" - An object with the String parameters: "local" and "remote". The String values of these parameters are UUIDs as defined in section 5 of [SESSION-ID] as "local-uuid" and "remote- uuid". This is designed to also work with the H.323 correlated [H-460-27] which refers to them as "Sender-UUID" and "Recipient- UUID". { "local": String, "remote": String } * "A[]" and array of values of type A. All parameters are assumed to be mandatory unless otherwise noted. Objects or arrays with no or null values MAY be excluded from the vCon. 2.3. Inline Files Objects that contain a file or data inline (i.e. within the vCon) MUST have the parameters: body and encoding. JSON does not support binary data values. For this reason inline files MUST be Base64url (see Section 2 [JWS]) encoded to be included as a valid JSON string value if they are not already valid JSON strings. Petrie Expires 4 May 2027 [Page 10] Internet-Draft JSON vCon October 2026 2.3.1. body The body parameter contains the payload of the file to be included inline. Depending upon the data in the file, it may require encoding to be represented as a valid JSON value. * body: "*" 2.3.2. encoding The encoding parameter describes the type of encoding, if any, that was performed to represent the file payload as the value of the body parameter. If the body parameter is provided and is not an empty string, the encoding parameter MUST be provided. In the interest of being tolerant for interoperability, if the encoding value is not provided, applications can attempt to derive the encoding token value based upon the mediatype parameter or filename extension if either is provided. * encoding: "String" The string MUST have the value of one of the following tokens or a value defined in a vCon extension: * "base64url": The payload of the file has been Base64Url encoded and provided as the string value of the body parameter. * "json": The value of the body parameter is a JSON value (object, array, number, string, or one of the literals true, false, or null) as defined in [JSON]. * "none": The payload of the file is a valid JSON string and can be included without modification as the string value to the body parameter. A vCon extension which defines an additional encoding value also defines the form of the body parameter value for that encoding, either a string or another JSON value. An Object with an encoding which is not recognized cannot be decoded and is handled as described in Section 2.5. Such an extension is Incompatible, and its name is listed in the critical parameter, if a vCon cannot be processed correctly when the Object is ignored. Petrie Expires 4 May 2027 [Page 11] Internet-Draft JSON vCon October 2026 2.4. Externally Referenced Files Files and data stored externally from the vCon MUST be "signed" to ensure that they have not been modified. Objects that refer to a file which is externally stored from the vCon MUST have the parameters: url, content_hash. These parameters are defined in the following subsections. The values and format of the hashes are defined in Section 2.2 type: ContentHash. The use of [SHA-512] hash for ensuring that the externally referenced data or file has not been modified, is defined in this document. Other methods of ensuring integrity may be added in the future. 2.4.1. url The url value contains the [HTTPS] URL where the externally referenced file is stored. HTTPS MUST be used for retrieval to protect the privacy of the contents of the file. * url: "String" 2.4.2. content_hash The integrity of externally referenced files are protected using a hash of the external content. The algorithm and hash value are contained in the content_hash parameter. The value of the content_hash can be a single token or an array of tokens if multiple hash algorithms are desired to be provided. The SHA-512 [SHA-512] algorithm MUST be supported. Other algorithms MAY be included. The algorithm used for signing the externally referenced file is defined in section 6.3 and 6.4 of [SHA-512]. * content_hash: "ContentHash" | "ContentHash[]" 2.5. Extending vCon vCon provides a means to extend the schema defined in this document. A vCon extension can define new parameters at any level of the schema. It can also define additional allowed values for an existing parameter, such as a new token for a type parameter. It can also define new Objects, which appear as the value of a new parameter or as the elements of a new array parameter. It can also redefine the semantics of or deprecate existing parameters. A vCon extension is defined in its own document. In addition to the standard sections of an Internet-Draft, a vCon extension document MUST also contain the following sections. Petrie Expires 4 May 2027 [Page 12] Internet-Draft JSON vCon October 2026 * *Extension Name*: State the registered extensions token name for the extension. The name MUST appear in the extensions (Section 4.1.3) parameter of any vCon which uses the extension; state whether and under what conditions the name also appears in the critical (Section 4.1.4) parameter. This is the name registered in the vCon Extensions Names Registry (Section 7.4) and the name against which implementations determine whether they support the extension. * *Parameter Definitions*: Define each new parameter, the level of the schema at which it appears, its value type, and its semantics. For any existing parameter whose meaning or permitted values are redefined, state the new semantics and values. For any value added to the allowed values of an existing parameter, define the value and its semantics and state which parameters apply when the value is used. For each new Object, define the parameters of the Object in the same manner. For each new Object, a new parameter names registry SHOULD be requested from IANA with the parameters of the new Object as its initial values (see Section 7.3). For any deprecated parameter, state what is to be used in its stead and the migration approach. Use the snake case naming convention for all parameter names, as opposed to camel case. Register each new parameter in the appropriate Object registry with IANA. Register each new value in the appropriate registry with IANA, where one exists. * *Compatibility Considerations*: Describe how the extension behaves in the presence of implementations that do not support it. Identify the parameters and semantics the extension introduces or changes, and explain for each why an implementation that does not recognize the extension can continue to process the vCon correctly by ignoring the additions, or state the conditions under which that holds. A value added to the allowed values of an existing parameter is not recognized by an implementation that does not support the extension, and by default the Object which contains it is ignored. For any such value, describe the effect of the Object being ignored and state whether this makes the extension Incompatible. An extension that is *Compatible* under all conditions states so explicitly and justifies that claim. Petrie Expires 4 May 2027 [Page 13] Internet-Draft JSON vCon October 2026 * *Incompatibility Considerations*: Demonstrate either that the extension introduces no incompatibilities, or enumerate each incompatibility that it does introduce. For each incompatibility, state the processing that is affected, for example redaction versus transcription, whether the extension name is therefore required in the critical (Section 4.1.4) parameter, and the behavior required of implementations that do not support the extension. An extension that claims to be *Compatible* uses this section to show why no incompatibility exists. * *Privacy and Integrity Considerations*: Describe how the extension's parameters interact with redaction and de- identification, including whether any of them can carry party- identifying data or PII and how a redactor is expected to handle them. In particular, state whether the string redaction feature of the vCon will work to redact any sensitive information, or if there is additional extension-specific redaction capabilities needed. State whether the extension introduces any new external content references, and if so, the integrity mechanism that protects them, such as Section 2.4.2. A markdown template for a vCon extension document containing these sections is referenced in vCon Extension Template (Appendix E). Extensions to the vCon schema can be classified into two categories: * *Compatible*: These extensions introduce additional data or fields without altering the meaning or structure of existing elements. Implementations that do not recognize these extensions can safely ignore them while maintaining valid processing of the vCon. * *Incompatible*: These extensions modify existing semantics or schema definitions in ways that render a vCon incompatible with implementations that do not support the extension. Interpreting such a vCon correctly requires explicit awareness of the extension. Wherever feasible, extensions *SHOULD* be designed as *Compatible* to preserve compatibility with existing implementations. The question of Compatible vs Incompatible is a little subjective. A transcriber for vCon can be fairly tolerant of changes adding new parameters or objects to a vCon. In these cases a transcriber will likely only need to look at the critical extensions. On the other hand, a redactor must be aware of the implications of all parameters in the vCon to be sure to redact all of the objective information. If an extension adds information which cannot be removed by the vCon string Petrie Expires 4 May 2027 [Page 14] Internet-Draft JSON vCon October 2026 redaction feature, this may make the extension incompatible. A redactor which needs a 100% guarantee that it can redact everything, perhaps should reject vCons with any extension that it does not support. Others, may choose to accept them, assuming the string redaction is sufficient. However, when Incompatible extensions are necessary, the names of all such extensions *MUST* be listed in the critical (Section 4.1.4) parameter of the vCon. This allows implementations to determine whether they are capable of processing the vCon safely and accurately. Implementations that encounter a vCon containing an Incompatible extension listed in the critical parameter, but do not support that extension, *MUST NOT* process the vCon except to reject it or report unsupported content. A parameter may contain a token value which an implementation does not recognize, such as a type defined in an extension which the implementation does not support. If an unsupported extension is listed in the critical parameter, the vCon is not processed as described above. Otherwise, the implementation SHOULD ignore the Object which contains the unrecognized value and continue to process the rest of the vCon. An ignored Object remains in its array so that the indexes which reference Objects in that array are not changed. 3. vCon JSON Object The JSON form of a vCon is contained in a JSON object in one of three forms: * unsigned * signed * encrypted The unsigned form of the vCon has a single top level object. This top level vCon object is also contained as described in the signed (Section 6.2) and encrypted (Section 6.3) forms of the vCon. The selection of the JSON format enables interchange between application and lower layers of the network stack, critical for enablement of analysis of conversations. The signed form of vCon is defined in Section 6.2 using [JWS] to provide integrity and proof of the conversation data. The encrypted form of vCon is defined in Section 6.3 using [JWE] to provide complete privacy of the conversational data. Partial privacy or data minimization can be provided for a vCon using the techniques outlined in Redaction Techniques (Section 5). Petrie Expires 4 May 2027 [Page 15] Internet-Draft JSON vCon October 2026 4. Unsigned Form of vCon Object The unsigned form of the top level vCon object is necessary as in many cases, a vCon will be partially constructed and in process as conversation data is collected. This may change while the conversation is in progress or on-going. The vCon may start with only meta data and party information, then progress to contain dialog information. It may then get analysis added or it could be passed to another security domain for analysis. A vCon in the unsigned form SHOULD contain at least one of the parties, dialog, analysis or attachments parameters. A vCon may be constructed across several security domains. When a vCon is to be exported from one security domain to another, it SHOULD be signed or encrypted by the domain that constructed it. The subsequent domain may have need to redact or amend data to the vCon. Alternatively the originating domain may want to redact the vCon before providing it to another domain. The second or subsequent domain, MAY modify the prior vCon instance version and when complete or exporting to another security domain, it SHOULD sign or encrypt the new vCon instance version. The new vCon instance version SHOULD refer to the prior vCon instance version via the redacted_from (Section 4.1.8) or amended_from (Section 4.1.9) parameters - see Redaction Techniques (Section 5). 4.1. vCon JSON Object Keys and Values The keys and values for the top level vCon JSON object are defined in the following subsections. 4.1.1. vcon The "vcon" parameter is DEPRECATED as of the publication of this document as an RFC. The "vcon" parameter was used to differentiate schema changes to the vCon core container when incompatibilities were created in Internet-Draft versions. The extension mechanism replaces the need for schema versioning. The vcon parameter was used to contain the syntactic version of the JSON format used in the vCon. (see Non-Upward Compatible Changes to the vCon Container (Appendix A)) * vcon: "String" For syntax defined in this document, the string MUST have the value: "0.5.0" Petrie Expires 4 May 2027 [Page 16] Internet-Draft JSON vCon October 2026 4.1.2. uuid The [UUID] for the vCon is used to refer to it when privacy or security may not allow for inclusion or URL reference to a vCon. The UUID value MUST be globally unique. All vCon documents MUST have the uuid parameter and value set. * uuid: "String" The value of the string SHOULD be generated using the version 8 UUID defined in [UUID] which is generated identically to a version 7 UUID with the exception that: * rand_b/custom_c is generated from the high 62 bits of the SHA-1 hash of the FQHN string * the variant and version fields are set as described for version 8 UUID The DNS name string used in generating the uuid value SHOULD be the same FQHN, or a subdomain to allow for more distributed generation of UUIDs, as would used in the signing certificate as they are the same domains of uniqueness. 4.1.3. extensions The vCon schema can be extended through the definition of new extensions. The extensions parameter MUST contain the list of names of all vCon extensions which define any parameters, Objects or parameter values used in the vCon that are not defined in this core vCon schema document. Each extension name listed in the critical parameter MUST also be listed in the extensions parameter (see Section 4.1.4). * extensions: "String[]" (optional, MUST be present if any vCon extension is used) 4.1.4. critical Implementations that include extensions which are incompatible with the core vCon schema MUST list the names of those extensions in the critical parameter. A vCon that includes a critical parameter indicates that correct interpretation of the vCon requires explicit support for the listed extensions. An implementation that does not recognize or support the extensions listed in the critical parameter MUST NOT attempt to process or operate on the vCon, except to reject it or report unsupported content. Petrie Expires 4 May 2027 [Page 17] Internet-Draft JSON vCon October 2026 * critical: "String[]" (optional, MUST be present if any Incompatible vCon extension is used) 4.1.5. created_at The created_at parameter provides the creation time of this vcon, which MUST be present, and should not change once the vcon object is created. * created_at: "Date" 4.1.6. updated_at The updated_at parameter provides the last modified time of this vcon, which MAY be present. For unsigned forms, the updated_at of the vcon object SHOULD be updated as it is modified. For signed forms of the vCon object, the updated_at contains the time when this vcon was last signed. Future updates MUST first set the updated_at to the new signing time as the vcon object is signed again. * updated_at: "Date" 4.1.7. subject The subject or the topic of the conversation is provided in the subject parameter. This parameter is optional as not all conversations have a defined subject. Email threads and prescheduled calls and video conferences typically have a subject which can be captured here. The subject may also be derived from analysis of the dialog. * subject: "String" (optional) The string value of the subject parameter is a free formed JSON string with no constrained syntax. 4.1.8. redacted_from A redacted vCon SHOULD provide a reference to the unredacted or prior, less redacted, vCon instance version of itself. The purpose of the Redacted_from Object (Section 4.1.8.1) is to provide the reference to the unredacted or less redacted version of the vCon from which this vCon was derived. For privacy reasons, it may be necessary to redact a vCon to construct another vCon without the PII. This allows the non-PII portion of the vCon to still be analyzed or used in a broader scope. The Redacted_from Object (Section 4.1.8.1) SHOULD contain the uuid parameter and MAY include the url, content_hash parameters (see Externally Referenced Files Petrie Expires 4 May 2027 [Page 18] Internet-Draft JSON vCon October 2026 (Section 2.4)). If a reference to the unredacted vCon is provided in the url parameter, the access to that URL MUST be restricted to only those who should be allowed to see the identity or PII for the redacted vCon. Redaction techniques are discussed in more detail in Redaction Techniques (Section 5). The assurance of the accuracy of the redaction is made by the entity that creates the redaction which SHOULD sign the redacted version of the vCon. * redacted_from: "Redacted_from" (optional, mutually exclusive with amended_from parameter) 4.1.8.1. Redacted_from Object A Redacted_from Object contains the following parameters: * uuid: "String" The value contains the uuid string value (Section 4.1.2) of the unredacted/prior vCon instance version. The absence of a value for uuid indicates that the less redacted version of this vCon is not available or does not exist. * type: "String" The value of the redacted type parameter is used to indicate the type of redaction that was performed on this vCon relative to the less redacted version referenced by the redacted uuid parameter. This should indicate the type of information that was redacted, and has the same set of values defined for the type field of the redacted_string object. The the location of the referenced vCon MAY be provided as defined in Externally Referenced Files (Section 2.4) by including url and content_hash. content_hash MUST be included if url is provided. * url: "String" * content_hash: "ContentHash" | "ContentHash[]" The following diagram illustrates an example partial JSON object tree for a redacted vCon. The top level object is a JWS signed vCon which contains a vCon in the unsigned form in the payload parameter. The second level object is the redacted vcon which refers to the encrypted unredacted vCon in it's redacted_from parameter. Note that the redacted vCon references the JWE encrypted vCon by UUID and may reference it by URL. The JWE encrypted unredacted vCon contains the Petrie Expires 4 May 2027 [Page 19] Internet-Draft JSON vCon October 2026 signed version of the unredacted vCon in the ciphertext parameter. The signed unredacted vCon contains the unredacted vCon in the unsigned form in it's payload parameter. -------------- Signed | JWS uuid-|-- redacted vCon uuid in header redacted vCon: | | | payload-|-- unsigned redacted vCon in -------------- / payload parameter / ---------------- / vCon which |vCon |<--- has been | | redacted: |redacted_from-|-- Redacted Object ---------------- / refers to JWE / encrypted unredacted vCon / / / / / / / / --------------- signed unredacted vCon ->| JWE uuid-|-- uuid in unprotected Encrypted signed | | unredacted vCon: | cyphertext-|--- JWS signed --------------- / unredacted vCon / in cyphertext /-------------------/ parameter / / ------------- Signed -> |JWS uuid-|-- unredacted vCon uuid in header unredacted vcon: | | | payload-|-- unsigned unredacted vCon ------------- \ in payload \ ---------- -->| vCon | Unsigned unredacted vCon: | | ---------- Figure 1: redacted vCon object tree Petrie Expires 4 May 2027 [Page 20] Internet-Draft JSON vCon October 2026 4.1.9. amended_from A signed or encrypted vCon cannot be modified without invalidating it. In these cases, to allow for adding of additional information a new vCon instance version MUST be created. The prior vCon instance version is referenced by the Amended_from Object (Section 4.1.9.1). The vCon with amended data contains all of the data that is in the referenced vCon with the exception of data that is amended. That is to say that the newer version of the vCon is a deep copy of the prior version with the amended and additional data added to it. The prior vCon instance version SHOULD be referenced via the uuid of the prior vCon instance version, and MAY include the url and content_hash parameters (see Externally Referenced Files (Section 2.4)). * amended_from: "Amended_from" (optional, mutually exclusive with redacted_from parameter) 4.1.9.1. Amended_from Object The Amended_from Object contains the following parameters: * uuid: "String" (optional if external reference provided) The value contains the uuid string value (Section 4.1.2) of the prior vCon instance version, to which this vCon's amendments were applied. The prior vCon instance version may be the original vCon, a redacted vCon, or a previously amended vCon. The location of the referenced vCon MAY be provided, as defined in Externally Referenced Files (Section 2.4) by including url and content_hash. content_hash MUST be provided if url is provided. * url: "String" * content_hash: "ContentHash" | "ContentHash[]" The following figure illustrates an example partial JSON object tree for an amended vCon. The top level object is the JWS signed amended vCon which contains the unsigned form of the vCon in its payload parameter. The second level object is the amended vCon with additional conversational data (e.g. analysis data). It refers to the prior vCon instance version in its amended parameter. Note: the amended_from parameter may refer to the prior vCon instance version via URL. The amended vCon in this figure refers to the JWS signed version of the vCon, which in turn contains the original vCon in unsigned form in its payload parameter. Petrie Expires 4 May 2027 [Page 21] Internet-Draft JSON vCon October 2026 -------------- Signed | JWS uuid-|-- amended vCon uuid in header amended vCon: | | | payload-|-- payload parameter -------------- / contains unsigned / amended vCon --------------- / vCon with |vCon |<- amended | | data: |amended_from-|--- amended_from parameter | analysis-| / refers to JWS --------------- / signed original vCon / along with additional / conversational data / (e.g. analysis) / / / / / ------------ ->| JWS uuid-|-- original vCon uuid in header signed | | original vCon: | payload-|--- payload parameter ------------ / contains unsigned / original vCon ------------- / Original vCon: |vCon |<-- | | | parties | | dialog | ------------- Figure 2: amended vCon object tree 4.1.10. sessions Objects Array A vCon can contain a single conversation, several conversations, sub- conversations or side bar conversations. The Session Object is used to group dialog Objects into sets of dialog to represent those conversations. A Session Object can "contain" other Session Objects by reference. A simple conversation has only 1 Session Object for all of the Dialogs. At least one Session Object MUST exist if the Events array or the Dialog array contain objects. TODO: Session Object required if Attachments is not empty too? * sessions: "Session[]" (optional) Petrie Expires 4 May 2027 [Page 22] Internet-Draft JSON vCon October 2026 The value of the sessions parameter is an array of Session Objects (Section 4.2). Examples of where multiple Session Objects are used to show the topology of the conversation and dialog include: 4.1.10.1. Call Transfer A customer calls into a contact center, which results in a call to a bot, that call gets transferred to an agent, the agent has a consultation with a supervisor, the customer gets transferred to the supervisor. From the customer's perspective this was one call. In reality it was 3 different calls. This may be represented as Session Object which references 3 other Session Object: * The original call with the bot * the call between the agent and the supervisor * The call resulting from the transfer of the customer to the supervisor 4.1.10.2. Dialog per Stream Some call recorders create a separate single channel recording for each leg or stream in the call, each resulting in a Dialog Object. To show that those Dialog Objects are all in the same call or conversation, we create a Session Object which refers to all of the Dialog Objects that were a part of it. 4.1.10.3. Dialog per Talk Spurt Some call recorders create separate single channel recordings for each contiguous talk spurt for a Party or stream. This may result in several Dialogs for some of the parties in the call. In this case we need the Session Object to indicate which Dialogs compose the call or conversation. We also need the Session Object to declare the start and duration of the call, as each Dialog Object only defines the start and duration of its talk spurt. Petrie Expires 4 May 2027 [Page 23] Internet-Draft JSON vCon October 2026 4.1.10.4. Agent Coaching In contact centers, an agent talking to a customer may be monitored by a supervisor. In this scenario, the customer and the agent can hear each other, the agent and the supervisor can hear each other, but the customer cannot hear the supervisor, the supervisor can hear both the customer and the agent. In the simple case, we have 3 Dialog Objects and 2 Session Objects. Dialog Objects containing: * The customer talking * The agent talking * The supervisor talking Session Objects referencing Session and Dialog Objects: * The top level Session Object which references the following Session Objects * The customer Session which references the customer and agent dialog recordings * The supervisor Session which references the customer, the agent and supervisor dialog recordings 4.1.10.5. AI Agent A conversation may occur between an AI agent and a human. That AI agent in turn may converse with other AI agents, to fulfill a response to the human. This can recurse such that the second tier AI agents talk to 3rd tier AI agents or even other humans and so on. The top level Session object might represent the conversation between the human and the top level AI agent. That top level Session Object would refer to other Session Objects for the second tier AI agent conversations. Those Session Objects may refer to Session Objects for the 3rd tier AI agent conversations and so on. This example describes how both human to AI agent as well as AI agent to AI agent conversations can be captured in a vCon. Petrie Expires 4 May 2027 [Page 24] Internet-Draft JSON vCon October 2026 4.1.11. parties Objects Array The name, identity or contact information of all of the parties involved with the conversation are included in the parties object array. Whether the parties were observers, passive or active participants in the conversation, they each are included as a Party Object in the parties array. * parties: "Party[]" (optional) The value of the parties parameter is an array of Party Objects (Section 4.4). 4.1.12. events Objects Array All events which occur related to this vCon are included in this array of Event Objects. Event Objects MAY appear in any order in the events array and are not required to be in chronological order. Events may be in non-chronological order because of network or consolidation delays. The time parameter of each Event Object is used to determine the sequence in which the events occurred. * events: "Event[]" (optional) The value of the events parameter is an array of Event Objects (Section 4.3). 4.1.13. dialog Objects Array The actual conversation which occurred over text, audio or video that was captured, is contained in the dialog Objects Array. * dialog: "Dialog[]" (optional) The value of the dialog parameter is an array of Dialog Objects (Section 4.5). It should be noted that the Dialog Objects may not be sorted in chronological order. They are in the order that they were added. It is the applications responsibility to sort dialog and transcriptions if they are needed in chronological order. 4.1.14. analysis Objects Array Analysis, which is performed on the conversational data, is stored in the analysis Objects array. * analysis: "Analysis[]" (optional) Petrie Expires 4 May 2027 [Page 25] Internet-Draft JSON vCon October 2026 The value of the analysis parameter is an array of Analysis Objects (Section 4.7). 4.1.15. attachments Objects Array Ancillary documents, discussed, presented, referenced or related to the conversation may be stored in the attachments array. It should be noted that the Attachment Objects may not be sorted in chronological order. They are in the order that they were added. * attachments: "Attachment[]" (optional) The value of the attachments parameter is an array of Attachment Objects (Section 4.6). 4.1.16. redacted_strings Objects Array A vCon can contain sensitive information in string values in many places. A text dialog containing chat messages or emails might contain a person's first name, or a street address, or an account number. Events, like a tool call made by an AI agent - can contain an account ID or social security number. The vCon format provides a general purpose solution for redacting sensitive information from any string in the object. Any string which has a substring containing sensitive information can be replaced by "__REDACTED_REF_#", where the value of # is a positive integer which uniquely identifies the substring that was replaced. Within the redacted_strings array there will be a member that contains a matching reference, along with meta-data about the redaction, such as the type of information that was redacted. The redacted_strings array is defined as: * redacted_strings: "Redacted_string[]" (optional) Where the Redacted_string object is defined in Redacted_string Object (Section 4.8). As an example, consider the following simplified event, which contains a tool call that has an account ID in it. Several mandatory parameters have been omitted for ease of understanding: Petrie Expires 4 May 2027 [Page 26] Internet-Draft JSON vCon October 2026 { "events" : [ { "type" : "tool-call", "tool_name" : "close_account_by_id", "input-params" : [ { "input-name" : "account_id", "input-value" : "293827344" } ] } ] } You can see that this contains a sensitive account ID. Here is a version that is now redacted. { "events" : [ { "type" : "tool-call", "tool_name" : "close_account_by_id", "input-params" : [ { "input-name" : "account_id", "input-value" : "__REDACTED_REF_1" } ] } ] } There will then be an entry in the redacted_strings array like this: "redacted_strings" : [ { "ref" : 1, "type" : "FIN_ID_NUM" } ] Implementations created a vCon that perform this kind of string redaction MUST include an entry in the redacted_strings array for every unique substring value they redact. A single vCon MUST NOT have more than 99999 such substrings redacted, to provide an upper bound on the integer value and to allow bounded regex parsing. Petrie Expires 4 May 2027 [Page 27] Internet-Draft JSON vCon October 2026 Furthermore, a processor of the VCON MUST validate that - for each instance of the regular expression "__REDACTED_REF_\d{1,5}$" it finds in the vCon, there is a corresponding entry in the redacted_strings array whose ref value matches the reference digit sequence. If there is no match, then it means the substring was not actually redacted, and the literal substring value is actually whatever matched "__REDACTED_REF_\d{1,5}$" for that reference ID. This can happen if a user were to literally type a chat message or email like, "Yeah I'm going to try to break vcon by typing __REDACTED_REF_3 hah hah hah!". This redaction technique allows vCon to have a way of redacting information from strings anywhere, including future extensions to vCon. This means, unless an extension might convey sensitive information in a way for which string redaction is insufficient, it will not need any specific redaction capability defined. 4.2. Session Object The Session Object is used to show the scope for conversational dialog and events. It provides the ability to group dialog and events into sub-conversation. A Session Object can contain by reference other Session Objects to create a nesting or tree relationship with child session(s). It can also support peer relationships to group in logical sequences of evolution of a conversation. For example a conference may split into break out sessions and then merge back together as one conference again. 4.2.1. start The start parameter indicates when this session was started. The start parameter SHOULD be present. The start of the session may be before or after the start of the Dialog and Event Objects which are part of this session (see Section 4.2.2). For example it could be the scheduled start time for a conference where everyone shows up late. * start: "Date" The value of the start parameter is the date and time at which the session started. Petrie Expires 4 May 2027 [Page 28] Internet-Draft JSON vCon October 2026 4.2.2. duration The duration parameter contains the duration in seconds of the session. The start and duration parameters together define the time period of the session, which includes its start and end. The time period of the session need not include the entire time period of the Dialog and Event Objects that are part of this session. Dialog Content of a Dialog Object which is outside of the time period of the session SHOULD be considered to not be part of that session. Whether or how an application renders Dialog Content outside of the time period of the session is an application choice. This allows a session to be scoped to part of a recording without having to split the recording into separate Dialog Objects. For example, a Session Object may be added to a vCon to mark up the portion of a conversation which is of interest, saving a consumer of the vCon from having to listen to or review the whole conversation. Such a Session Object may be a child or a peer of the Session Object for the whole conversation (see Section 4.2.8.2). Dialog Objects referenced by the session may also be entirely outside of the time period of the session. For example, a recording Dialog Object of the opening of a call may be entirely before the time period of a session which marks up a later portion of that call. A "text" type Dialog Object is part of the session in its entirety if any part of the time period given by its start and duration is within the time period of the session. This is because the Dialog Content of a "text" type Dialog Object has no time stamps by which it could be divided. A vCon extension may define a form of text Dialog Content with time stamps at a finer granularity, such as per word, along with how it is scoped by the time period of a session. An "incomplete" type Dialog Object is likewise part of the session in its entirety if any part of the time period given by its start and duration is within the time period of the session. Event Objects which are part of this session are part of the session even if they are outside of the time period of the session. For example, it may be important to know that a party dropped out of the conversation before the start of the session. If the duration parameter is not present, the time period of the session has no end. In this case, all of the Dialog Content of the Dialog Objects referenced by the session which is at or after the start of the session is part of the session. * duration: "UnsignedInt" | "UnsignedFloat" (optional) The value MUST be the session duration in seconds. Petrie Expires 4 May 2027 [Page 29] Internet-Draft JSON vCon October 2026 4.2.3. parties The Session Object parties parameter references the Party Objects from the parties Array that are the receivers of the dialog in this session. The parties parameter SHOULD be present. A party is a receiver if they potentially received any part of the dialog that was exchanged in this session. This is not a guarantee that they received any part of the dialog, only that some part of any dialog in this session was sent to them. The contributors to the dialog in this session are indicated in the Dialog Object parties parameter (Section 4.5.4) of each of the Dialog Objects that are part of this session. A contributor is not necessarily a receiver. For example, an automated announcement or prompt player contributes to the dialog, but does not receive any of it. A contributor that did not potentially receive any part of the dialog in this session SHOULD NOT be included in the Session Object parties parameter. The originator of the session MAY be included in the Session Object parties parameter even if it is not a receiver (see Section 4.2.4). To determine what part(s) of the dialog that a party potentially heard or received, the Event Objects may provide data as to when a party joined, dropped out, went on or off hold. * parties: "UnsignedInt[]" The value of the parties parameter is an array of the indices into the parties Object array to the Party Objects that are the receivers of the dialog in the session. 4.2.4. originator The originator party for this session. For email and text, this is the sender of the first message. For audio and video calls, this is the calling party. For a scheduled meeting or conference, this is the organizer, the party that scheduled or created the meeting. The organizer may be a party that never joins the conference; such a party may still be included in the parties array. The organizer is distinct from the party acting as host or controller of the conference at any point during the meeting; identifying the host or controller is out of scope for this document. It is implied that the first party in the Session Object parties list is the originator of the session. If the originator is not known, an empty Party Object (see Party Object (Section 4.4)) may be used as the first party or as the party referenced by the originator parameter. The originator parameter is only provided if the first party of the Session Object parties list is NOT the originator. * originator: "UnsignedInt" (optional) Petrie Expires 4 May 2027 [Page 30] Internet-Draft JSON vCon October 2026 The originator value is the index into the parties Objects Array, to the party that originated the session. 4.2.5. session_id The [SESSION-ID] MAY be included for the session if it applies to all of the Dialog Objects in the session. * session_id: "SessionId" (optional) The value of the session_id parameter is a single SessionId Object (see Section 4.5.9). A [SESSION-ID] which applies to only some of the parties or Dialog Objects in the session is captured in the session_id parameter of the Dialog Object. 4.2.6. sessions A Session Object may refer to other Session Objects in one of several different relationships using the Session_Reference Object (Section 4.2.8). * sessions: "Session_Reference[]" (optional) The sessions parameter is an array of Session Reference Objects. The sessions parameter can be used to create a tree or graph of session. A Session Reference Object also labels the relationship between this Session Object and the reference one. Event Objects are not inherited through these relationships; an Event Object applies only to the Session Objects listed in its sessions parameter (see Section 4.3.3). 4.2.7. dialog All Dialog Objects (Section 4.1.13) SHOULD be referenced by at least one of the Session Objects in a vCon. The dialog parameter in the Session Object is an array of Dialog Object indices to the dialog Object array (Section 4.1.13). * dialog: "UnsignedInt[]" (optional) The value of the Session Object dialog parameter is an array of indices to the dialog in the Dialog Object array which are part of this session. 4.2.8. Session_Reference Object A Session Reference Object specifies the relationship from one Session Object to another. Petrie Expires 4 May 2027 [Page 31] Internet-Draft JSON vCon October 2026 4.2.8.1. session The session parameter is used to define a relationship from one session to another. * session: "UnsignedInt" The session parameter value is an index into the sessions Object Array (Section 4.1.10) for the session that is referenced. The session parameter MUST be provided. 4.2.8.2. type The type parameter specifies a specific type of relationship to the reference session. * type: "String" The string MUST have the value of one of the following tokens or a value defined in a vCon extension: * "child" - a session contained within this session * "peer" - a session that occurred in parallel or overlapping this session * "precursor" - a session that occurred before and leading up to this session * "breakout" - a separate session that included some subset of the parties in this session and typically overlapping with this session The handling of a Session_Reference Object with a type which is not recognized is described in Section 2.5. TODO: other types? 4.2.8.3. description The description parameter is used to better describe the relationship to the referenced Session Object. * description: "String" (optional) The value of the description parameter is a free form text description of the relationship. Petrie Expires 4 May 2027 [Page 32] Internet-Draft JSON vCon October 2026 TODO: alternative name: relation? The description parameter is an open text String. 4.3. Event Object Events occur during a conversation which are important to capture in a vCon, but which are not part of the content of the conversation. An Event Object captures one such occurrence. An event is a point in time occurrence, unlike a Dialog Object which captures the actual conversation over some duration. A period of time, such as the time that a party was on hold, is captured by a pair of Event Objects and not by a duration. Every Event Object has a type and the time at which the event occurred. Depending upon its type, an Event Object also references the session(s) in which it occurred, the party to which it relates, or the Dialog Object to which it relates. Each Event Object occurs within the scope of one or more Session Objects, referenced either directly by its sessions parameter, or through the Dialog Object referenced by its dialog parameter. The following types of events are defined in this document: * party event types - a change in the participation of a party in a session (see Section 4.3.1.1) * key event types - a key or button was pressed or released (see Section 4.3.1.2) * transfer event types - a transfer operation and the relationship between the sessions involved (see Section 4.3.1.3) * channel contributors event type - a change in the party(s) contributing to a channel of a recording (see Section 4.3.1.4) Additional event types may be defined in a vCon extension (see Section 2.5). The parameters which are present in an Event Object depend upon the type of the event. The event types are described first in the subsections of the type parameter (see Section 4.3.1). The parameters which apply to each event type are summarized in Section 4.3.1.5. The parameters which are specific to an event type are defined in the subsections which follow. Petrie Expires 4 May 2027 [Page 33] Internet-Draft JSON vCon October 2026 4.3.1. type The type parameter indicates the type of event that occurred. * type: "String" The string token for the event MUST be one of the tokens defined in the following subsections or in a vCon extension. The handling of an Event Object with a type which is not recognized is described in Section 2.5. 4.3.1.1. Party Event Types Participants in a session may not all join and leave at the same time. The party event types support the capturing of the information when parties join, drop, go on hold or mute and unmute. Party events may also be used to determine which parties were present or potentially received dialog from other parties in the conversation. The party parameter references the party that joined, dropped, was put on or taken off hold or was muted or unmuted. The following party event types are defined: * "join" - when the party joins the session * "drop" - when the party drops out of the session * "hold" - when the party is put on hold * "unhold" - when the party is taken off hold * "mute" - when the party is muted * "unmute" - when the party is taken off mute 4.3.1.2. Key Event Types The key event types capture when a party presses or releases a DTMF or application key or button. The party parameter references the party that pressed or released the key or button. The key or button is identified in the button parameter (see Section 4.3.8). The following key event types are defined: * "keydown" - when a DTMF or application key/button was pressed * "keyup" - when a DTMF or application key/button was released Petrie Expires 4 May 2027 [Page 34] Internet-Draft JSON vCon October 2026 4.3.1.3. Transfer Event Types The transfer event types document the roles of three parties and the relationship between two or three sessions. In a transfer operation, the roles of the three parties to a transfer are defined in [SIP-XFER] as: * Transferee * Transferor * Transfer Target There are two or three calls in which the parties are connected: * original call * consultative call (optional as this call may not get created) * target call Each of these calls is represented by a Session Object. The following transfer event types are defined: * "consultation-start" - when the Transferor starts a consultative call with the Transfer Target * "blind-transfer" - when the Transferor transfers the Transferee to the Transfer Target without a consultative call * "consultative-transfer" - when the Transferor transfers the Transferee to the Transfer Target following a consultative call * "transfer-abandoned" - when the Transferor abandons an attempt to transfer the Transferee without completing the transfer The "blind-transfer" and "consultative-transfer" type Event Objects do not indicate that the target call succeeded. The following table summarizes the transfer cases, the Event Objects which capture each case and the results. Petrie Expires 4 May 2027 [Page 35] Internet-Draft JSON vCon October 2026 +======================+=======================+===================+ | Case | Event Objects | Results | +======================+=======================+===================+ | Consultative call | consultation-start, | consultation | | fails or is not | transfer-abandoned | Session Object | | answered | | references an | | | | "incomplete" type | | | | Dialog Object | +----------------------+-----------------------+-------------------+ | Consultative call | consultation-start, | Transferee is not | | succeeds, Transferor | transfer-abandoned | transferred in | | does not transfer | | this attempt | +----------------------+-----------------------+-------------------+ | Consultative call | consultation-start, | target Session | | succeeds, Transferor | consultative-transfer | Object references | | transfers, target | | the Dialog | | call succeeds | | Objects for the | | | | target call | +----------------------+-----------------------+-------------------+ | Consultative call | consultation-start, | target Session | | succeeds, Transferor | consultative-transfer | Object references | | transfers, target | | an "incomplete" | | call fails or is not | | type Dialog | | answered | | Object | +----------------------+-----------------------+-------------------+ | Blind transfer, | blind-transfer | target Session | | target call succeeds | | Object references | | | | the Dialog | | | | Objects for the | | | | target call | +----------------------+-----------------------+-------------------+ | Blind transfer, | blind-transfer | target Session | | target call fails or | | Object references | | is not answered | | an "incomplete" | | | | type Dialog | | | | Object | +----------------------+-----------------------+-------------------+ | Transferor abandons | transfer-abandoned | Transferee is not | | before a | | transferred in | | consultative call or | | this attempt | | transfer | | | +----------------------+-----------------------+-------------------+ Table 1 Petrie Expires 4 May 2027 [Page 36] Internet-Draft JSON vCon October 2026 A "consultative-transfer" or "transfer-abandoned" type Event Object which follows a consultation references the same Session Object in the consultation parameter as the "consultation-start" type Event Object. It is also possible for there to be more than one consultation. This may occur for a number of reasons. Call attempts may fail. The caller may decide the consultation with a party is not the desired transfer target. When a transfer attempt fails or is abandoned, the Transferor may attempt the transfer again. Depending upon the system, a subsequent "consultative-transfer" type Event Object may reference the same consultation Session Object if the consultative call still exists. Alternatively, the Transferor may start another consultative call, which is captured in a new "consultation-start" type Event Object, or may perform a blind transfer. If the target call fails and the Transferor does not attempt the transfer again, no further transfer Event Object is created. More than one transfer may occur in a vCon. After a transfer has completed or failed, additional transfers may be attempted. Each transfer is captured in its own transfer Event Objects. A Session Object may be referenced in more than one transfer event when multiple transfers occur. For example, the Session Object for the target call of one transfer may be the Session Object for the original call of a subsequent transfer. The following figure illustrates the transfer event types and the calls to which they relate. Petrie Expires 4 May 2027 [Page 37] Internet-Draft JSON vCon October 2026 transfer-abandoned +-------+ | | v | +------------------+ +--------------------+ | Original call |----consultation-start--->| Consultation | | (session) |<---transfer-abandoned----| (consultation) | +------------------+ +--------------------+ ^ | | ^ : | consultative-transfer | target call : : | blind-transfer | fails : : | | : : | v : : | +--------------------+ : +-------------------------------->| Target call | :..........................................| (target_session) | target call fails +--------------------+ : : target : call v succeeds +--------------------+ | Transferred | +--------------------+ ---- Event Object .... result determined from the target Session Object Figure 3: transfer event states In the transfer event types, the sessions parameter references the Session Object for the original call and the party parameter references the Transferor. The transferee and transfer_target parameters reference the other two parties to the transfer (see Section 4.3.9 and Section 4.3.10). The consultation and target_session parameters reference the Session Objects for the consultative call and the target call (see Section 4.3.11 and Section 4.3.12). There are scenarios where we know that a transfer has occurred, but we have no information for one or two of the consultation, target or original calls. In this case a placeholder Session Object is created and its index is used for the consultation, target_session or sessions parameter. A placeholder Session Object may contain no parameters or may reference a placeholder Dialog Object. A unique Session Object SHOULD be referenced for each role in the transfer. Petrie Expires 4 May 2027 [Page 38] Internet-Draft JSON vCon October 2026 The transfer event types only capture the roles, operations and events of the parties and the session setup. They do not capture the purpose or reason for the transfer as that is analysis to be captured in the analysis section of the vCon after the conversation has occurred. 4.3.1.4. Channel Contributors Event Type The channel contributors event type indicates the time at which the party(s) contributing to a channel of a recording Dialog Object change. This supports the channel contributor changes recording topology (see Section 4.5.1.1). For example, a conference bridge may create a recording with fewer channels than there are parties in the conference, and select the party(s) captured on each channel based upon which parties it detects as talking. At times a channel may capture no party at all. The dialog parameter references the recording Dialog Object and the channel parameter identifies the channel in that recording (see Section 4.3.5 and Section 4.3.6). The contributors parameter indicates the party(s) contributing to that channel, starting at the time of the event (see Section 4.3.7). These parties contribute to the channel until the time of the next channel-contributors Event Object for the same Dialog Object and channel, or until the end of the recording. The contributors at the start of the recording are indicated in the parties parameter of the Dialog Object (see Section 4.5.4). The time parameter of a channel-contributors Event Object SHOULD be within the time period given by the start and duration parameters of the referenced Dialog Object. Each channel- contributors Event Object applies to exactly one channel. If the contributors to more than one channel change at the same time, a separate channel-contributors Event Object is used for each channel, each with the same time parameter value. The channel-contributors Event Object MAY be used with a recording Dialog Object in any of the recording topologies (see Section 4.5.1.1), although it may not be useful in some of them, such as talk spurt. It indicates which parties are captured on a channel; it does not indicate that a party joined or dropped from the session. A party may be in the session, but not captured on any channel of the recording. The sessions and party parameters MUST NOT be present in the channel-contributors Event Object (see Section 4.3.3 and Section 4.3.4). The following channel contributors event type is defined: * "channel-contributors" - when the party(s) contributing to a channel of a recording change Petrie Expires 4 May 2027 [Page 39] Internet-Draft JSON vCon October 2026 4.3.1.5. Event Object Parameter Applicability by Type The following tables summarize which Event Object parameters apply to each Event Object type. The parameter definitions in the subsections of this document are definitive; these tables are provided as a summary. The symbols used in the tables are: M the parameter MUST be present, O the parameter is optional, SN the parameter SHOULD NOT be present, X the parameter MUST NOT be present. The following table applies to the party and key event types. +=================+======================+==========+ | Parameter | join, drop, hold, | keydown, | | | unhold, mute, unmute | keyup | +=================+======================+==========+ | type | M | M | +-----------------+----------------------+----------+ | time | M | M | +-----------------+----------------------+----------+ | sessions | M | M | +-----------------+----------------------+----------+ | party | M | M | +-----------------+----------------------+----------+ | dialog | SN | SN | +-----------------+----------------------+----------+ | channel | X | X | +-----------------+----------------------+----------+ | contributors | X | X | +-----------------+----------------------+----------+ | button | X | M | +-----------------+----------------------+----------+ | transferee | X | X | +-----------------+----------------------+----------+ | transfer_target | X | X | +-----------------+----------------------+----------+ | consultation | X | X | +-----------------+----------------------+----------+ | target_session | X | X | +-----------------+----------------------+----------+ Table 2 The following table applies to the transfer event types. Petrie Expires 4 May 2027 [Page 40] Internet-Draft JSON vCon October 2026 +=================+=============+========+===============+=========+ | Parameter |consultation-|blind- | consultative- |transfer-| | |start |transfer| transfer |abandoned| +=================+=============+========+===============+=========+ | type |M |M | M |M | +-----------------+-------------+--------+---------------+---------+ | time |M |M | M |M | +-----------------+-------------+--------+---------------+---------+ | sessions |M (1) |M (1) | M (1) |M (1) | +-----------------+-------------+--------+---------------+---------+ | party |M (2) |M (2) | M (2) |M (2) | +-----------------+-------------+--------+---------------+---------+ | dialog |SN |SN | SN |SN | +-----------------+-------------+--------+---------------+---------+ | channel |X |X | X |X | +-----------------+-------------+--------+---------------+---------+ | contributors |X |X | X |X | +-----------------+-------------+--------+---------------+---------+ | button |X |X | X |X | +-----------------+-------------+--------+---------------+---------+ | transferee |M |M | M |M | +-----------------+-------------+--------+---------------+---------+ | transfer_target |M |M | M |O | +-----------------+-------------+--------+---------------+---------+ | consultation |M |X | M |O | +-----------------+-------------+--------+---------------+---------+ | target_session |X |M | M |X | +-----------------+-------------+--------+---------------+---------+ Table 3 (1) A single index which references the Session Object for the original call. (2) References the Transferor. The following table applies to the channel contributors event type. Petrie Expires 4 May 2027 [Page 41] Internet-Draft JSON vCon October 2026 +=================+======================+ | Parameter | channel-contributors | +=================+======================+ | type | M | +-----------------+----------------------+ | time | M | +-----------------+----------------------+ | sessions | X | +-----------------+----------------------+ | party | X | +-----------------+----------------------+ | dialog | M | +-----------------+----------------------+ | channel | M | +-----------------+----------------------+ | contributors | O (3) | +-----------------+----------------------+ | button | X | +-----------------+----------------------+ | transferee | X | +-----------------+----------------------+ | transfer_target | X | +-----------------+----------------------+ | consultation | X | +-----------------+----------------------+ | target_session | X | +-----------------+----------------------+ Table 4 (3) A null value or the absence of the contributors parameter indicates that no party contributes to the channel. 4.3.2. time The time parameter indicates the time at which this event occurred. * time: "Date" The time parameter MUST be provided as it is used to determine the sequence in which events occurred. 4.3.3. sessions The sessions parameter indicates the session(s) in which this event occurred. Petrie Expires 4 May 2027 [Page 42] Internet-Draft JSON vCon October 2026 * sessions: "UnsignedInt" | "UnsignedInt[]" (not used in channel- contributors events) The value of the sessions parameter is the index, or an array of indices, into the sessions Object array to the Session Object(s) in which this event occurred. The sessions parameter MUST be present in all of the Event Object types defined in this document, except "channel-contributors" type Event Objects, in which it MUST NOT be present. An Event Object applies only to the Session Objects listed in its sessions parameter. An Event Object does not apply to the child or parent Session Objects of the Session Objects listed in its sessions parameter, unless they are also listed (see Section 4.2.6). If an Event Object applies to more than one Session Object, each of those Session Objects MUST be listed in its sessions parameter. The session(s) in which a "channel-contributors" type Event Object occurred are the Session Object(s) which reference the Dialog Object referenced by its dialog parameter (see Section 4.3.5). For the transfer event types, the value of the sessions parameter MUST be a single index, which references the Session Object for the original call between the Transferee and the Transferor. 4.3.4. party The party parameter indicates the party for this event. * party: "UnsignedInt" (not used in channel-contributors events) The value of the party parameter is the index into the parties Object array to the party for this event. The party parameter MUST be present in all of the Event Object types defined in this document, except "channel-contributors" type Event Objects, in which it MUST NOT be present. The parties contributing to a channel are indicated in the contributors parameter of the "channel-contributors" type Event Object (see Section 4.3.7). For the transfer event types, the party parameter references the party that played the role of the Transferor. 4.3.5. dialog The dialog parameter indicates the Dialog Object to which this event relates. * dialog: "UnsignedInt" (required for channel-contributors events) The value of the dialog parameter is the index into the dialog Object array to the Dialog Object to which this event relates. The dialog parameter MUST be present in "channel-contributors" type Event Objects and SHOULD NOT be present in the other Event Object types Petrie Expires 4 May 2027 [Page 43] Internet-Draft JSON vCon October 2026 defined in this document. The Dialog Object referenced by a "channel-contributors" type Event Object MUST be of type "recording". Event Object types defined in a vCon extension may use the dialog parameter, and may allow its value to be an array of indices to Dialog Objects. An implementation SHOULD NOT treat an array value for the dialog parameter as an error in an Event Object type defined in a vCon extension. 4.3.6. channel The channel parameter indicates the channel of the recording to which this event relates. * channel: "UnsignedInt" (required for channel-contributors events) The value of the channel parameter is the index of the channel in the recording of the Dialog Object referenced by the dialog parameter, where 0 is the first channel. The channel index corresponds to the index of the channel in the parties parameter of that Dialog Object (see Section 4.5.4). The value MUST be less than the number of channels in the recording. For a single channel recording, the value MUST be 0. The channel parameter MUST be present in "channel- contributors" type Event Objects and MUST NOT be present in the other Event Object types defined in this document. 4.3.7. contributors The contributors parameter indicates the party(s) contributing to the channel, starting at the time of this event. * contributors: "UnsignedInt" | "UnsignedInt[]" | null (optional) The value of the contributors parameter is the index, or an array of indices, into the parties Object array to the Party Objects which contribute to the channel, starting at the time of this event. A null value, or the absence of the contributors parameter, in a "channel-contributors" type Event Object indicates that no party contributes to the channel, starting at the time of this event. The contributors parameter MUST NOT be present in the other Event Object types defined in this document. 4.3.8. button The button parameter indicates the key or button that was pressed or released. * button: "String" (required for keydown and keyup events) Petrie Expires 4 May 2027 [Page 44] Internet-Draft JSON vCon October 2026 The button parameter value is the String value of the DTMF digit, character or string label for the button that was pressed or released. The button parameter MUST be present in "keydown" and "keyup" type Event Objects and MUST NOT be present in other Event Object types. 4.3.9. transferee The transferee parameter indicates the Transferee in the transfer event types. * transferee: "UnsignedInt" (required for transfer event types) The value of the transferee parameter is the index into the parties Object array to the party that played the role of the Transferee. The transferee parameter MUST be present in the transfer event types and MUST NOT be present in other Event Object types. If the Transferee is not known, an empty Party Object (see Party Object (Section 4.4)) is referenced. 4.3.10. transfer_target The transfer_target parameter indicates the Transfer Target in the transfer event types. Other parties may be part of the Session Object for the target call; the transfer_target parameter identifies the party that was the target of the transfer operation. * transfer_target: "UnsignedInt" (required for consultation-start, blind-transfer and consultative-transfer events, optional for transfer-abandoned events) The value of the transfer_target parameter is the index into the parties Object array to the party that played the role of the Transfer Target. The transfer_target parameter MUST be present in "consultation-start", "blind-transfer" and "consultative-transfer" type Event Objects. If the Transfer Target is not known, an empty Party Object (see Party Object (Section 4.4)) is referenced. The transfer_target is optional in "transfer-abandoned" type Event Objects in the case where the transfer is abandoned before the target was identified. The transfer_target parameter MUST NOT be present in Event Object types other than the transfer event types. 4.3.11. consultation The consultation parameter indicates the session for the consultative call in the transfer event types. Petrie Expires 4 May 2027 [Page 45] Internet-Draft JSON vCon October 2026 * consultation: "UnsignedInt" (required for consultation-start and consultative-transfer events, optional for transfer-abandoned events) The value of the consultation parameter is the index into the sessions Object array to the Session Object for the consultative call between the Transferor and the Transfer Target. The consultation parameter MUST be present in "consultation-start" and "consultative- transfer" type Event Objects. The consultation parameter is optional in "transfer-abandoned" type Event Objects in the case where the transfer is abandoned without a consultative call. The consultation parameter MUST NOT be present in "blind-transfer" type Event Objects or in Event Object types other than the transfer event types. 4.3.12. target_session The target_session parameter indicates the session for the target call in the transfer event types. * target_session: "UnsignedInt" (required for blind-transfer and consultative-transfer events) The value of the target_session parameter is the index into the sessions Object array to the Session Object 4.4. Party Object A Party Object contains information about a specific party or participant in the conversation. The information that is available about the party varies with the context, the communication mode and platform. There are times when no information is available for a party either initially or over the entire life of the vCon. In such situations, it is possible to have a Party Object with no parameters in it. A Party Object SHOULD be created for each participant. This may result in more than one empty Party Object. They are distinct by the order or index in the Party Object array. 4.4.1. tel If the tel URL for the party is known, it can be included in the tel parameter. * tel: "String" (optional) The value of the tel parameter SHOULD be a valid [TEL] URL. The URL scheme prefix (i.e. "tel:") is optional. Petrie Expires 4 May 2027 [Page 46] Internet-Draft JSON vCon October 2026 4.4.2. sip The [SIP] URL for the party can be provided in the sip parameter. * sip: "String" (optional) The value of the sip parameter is the addr-spec as defined in section 25.1 of [SIP]. 4.4.3. stir If the STIR [PASSporT] was provided to identify the party, the PASSporT can be included in the stir parameter for the party. * stir: "String" (optional) The string value of the stir parameter contains the [PASSporT] in the JWS Compact Serialization form. 4.4.4. mailto If the mailto URL is known for the party, it can be included in the mailto parameter. * mailto: "String" (optional) The value of the mailto parameter is a string containing an email address for the party. It MAY be provided in any common form, such as a bare address or a [MAILTO] URL; when a [MAILTO] URL is used, the "mailto:" scheme prefix is optional. 4.4.5. name If the party's name is known, it can be included in the name parameter. * name: "String" (optional) Petrie Expires 4 May 2027 [Page 47] Internet-Draft JSON vCon October 2026 The string value of the name parameter is a free form JSON string in which part or all of the party's name can be included. It may be necessary, for privacy reasons, to not identify any information about the party. This MAY be indicated by creating a Party Object with only the name parameter and setting its value to "anonymous". A Party Object SHOULD be create for each anonymous party in the conversation. This is necessary to capture the number of parties and distinction between which party contributed what data or dialog in the conversation. Hence it is possible to have multiple anonymous Party Objects in the vCon. They are distinct by the order or index in the Party Object array. 4.4.6. did If a Decentralized Identifier [DID] is known for the party, it can be included in the did parameter. * did: "String" (optional) The value of the did parameter MUST be a valid DID URI that enables verifiable, decentralized digital identity for the party. DIDs are designed to be decoupled from centralized registries and identity providers, allowing the controller of the DID to prove control without requiring permission from other parties. The DID can refer to any subject (person, organization, thing, etc.) as determined by the controller of the DID. 4.4.7. validation Proof of authorization of the communication channel through STIR, login or possession of a device, is often not sufficient proof of the identity of the person at the other end of the communications channel. It is common in call centers to validate the identity of the person on the communication channel through verification of some sort of personal identification information. The methods used, often varies with the situation and is business practices specific. The purpose of the validation parameter, is to allow the validator to save a label or token which identifies the method of identity validation used to identify the person at the other end of the communication channel. For confidentially reasons, it SHOULD NOT contain the data used to validate the name. However it MAY name the data used to validate the name (e.g. "SSN", "DOB", "user ID and password"). It is up to the domain creating the vCon to define the set of tokens or values to be used for the validation parameter. * validation: "String" (SHOULD be provided if name parameter is provided) Petrie Expires 4 May 2027 [Page 48] Internet-Draft JSON vCon October 2026 The value of the validation string MAY be "none" or enterprise or domain defined token or string values. 4.4.8. gmlpos If the geolocation of the party is known, it can be added in the gmlpos parameter. The gmlpos parameter contains the latitude and longitude of the location of the party at the time of the conversation start. * gmlpos: "String" (optional) The gmlpos parameter value contains a string of the same format as the gml:pos element defined in section 3.2 of the [PIDF-LO] PIDF. 4.4.9. civicaddress The the civicaddress parameter value contains a Civicaddress Object which is optional and contains civic address information about the location for the party. * civicaddress: "Civicaddress" (optional) The Civicaddress Object MAY contain any or all of the following parameters: country, a1, a2, a3, a4, a5, a6, prd, pod, sts, hno, hns, lmk, loc, flr, nam, pc as defined in section 2.2.1 of [GEOPRIV]. The values of all of these parameters are of type String. Note that the parameter names MUST be in lower case when contained in the Civicaddress Object even though they are in upper case in [GEOPRIV]. * country: "String" (optional) * a1: "String" (optional) * a2: "String" (optional) * a3: "String" (optional) * a4: "String" (optional) * a5: "String" (optional) * a6: "String" (optional) * prd: "String" (optional) * pod: "String" (optional) Petrie Expires 4 May 2027 [Page 49] Internet-Draft JSON vCon October 2026 * sts: "String" (optional) * hno: "String" (optional) * hns: "String" (optional) * lmk: "String" (optional) * loc: "String" (optional) * flr: "String" (optional) * nam: "String" (optional) * pc: "String" (optional) 4.4.10. uuid The uuid is a unique identifier for the participant. In a contact center, this is particularly important for the call agent participant, and must be static across interactions to allow correlation with the actual agent configuration provisioned into the systems. The value of the uuid parameter is a free form unique identifier string for the participant. The value is not constrained to the syntax defined in [UUID]. Operators often have existing methods of generating unique participant identifiers and MAY use any unique string value. * uuid: "String" (optional) 4.4.11. type There are different types of parties that participate in or contribute information to a conversation. The type parameter may be used to indicate the type of participant represented by the Party Object. * type: "String" (optional) The value of the type parameter SHOULD be one of the following: "person", "bot", "organization" 4.4.12. org The party may belong to or be an organization. The org parameter is a free form text string for containing the organization identifier. * org: "String" (optional) Petrie Expires 4 May 2027 [Page 50] Internet-Draft JSON vCon October 2026 4.4.13. dept The party may belong to a department with in an organization. The dept parameter is a free form text string for containing the party's department identifier. * dept: "String" (optional) 4.5. Dialog Object The Dialog object references or contains text, audio or video captured from the conversation. Currently five types of dialog objects are defined in this document: * Text based media communications * Audio or Video recorded media communications * Metadata for failed or incompleted communications Media captured in a media-based Dialog Object (type text and recording) SHOULD satisfy two constraints: the media is part of the conversation itself, and the media is transcribable. Media is part of the conversation when it is the communication exchanged between the parties, as opposed to a document or item that is referenced, discussed or presented within the conversation. Media that is transcribable can be converted into a textual representation of sequential communication between parties. Text media is already in textual form and is therefore always transcribable. While images such as sunsets, cows, photographs of documents, or application forms may be describable, they are not transcribable in a concise manner and SHOULD NOT be included as Dialog Objects. They SHOULD be included as Attachment Objects. Text and audio may be subject to interpretation, but they are transcribable to a precise dialog representation. Although transcriptions may not always be accurate, there exists a single correct transcription for any given content. Media that is not transcribable SHOULD be included in the vCon as Attachment Objects rather than Dialog Objects. Whether a fax or photograph of a text-based letter belongs in a Dialog Object depends upon its role in the conversation. A letter faxed to the other party as the communication itself, such as a letter faxed to a doctor, is both transcribable and part of the conversation and MAY be included as a Dialog Object. The same letter shared or discussed within some other conversation is referenced Petrie Expires 4 May 2027 [Page 51] Internet-Draft JSON vCon October 2026 material rather than the conversation itself and SHOULD be included as an Attachment Object, even though it is transcribable. Most other faxes and photographs SHOULD be included as Attachment Objects and SHOULD NOT be included as Dialog Objects. Similarly, a musical recording, even if it is in MP3 audio format, SHOULD be included as an Attachment and SHOULD NOT be included as a Dialog Object. It may not always be known at the time of vCon construction whether an image or recording is transcribable. This distinction is important for interoperability. If it is ambiguous as to what belongs in a Dialog Object versus an Attachment Object, interoperability cannot be achieved, as vCon constructors will not be able to consistently determine where content should be placed and users of vCons will not know where content can be found within the vCon. There are situations when little or no information is available for a dialog either initially or over the entire life of the vCon and yet it is known that the dialog occurred. For example this may occur in some call transfer cases where there is nothing known about the consultative call. In such situations, it is possible to have a placeholder Dialog Object which contains only the type parameter and, for the "incomplete" type, the required disposition parameter. As the consultative call is a call, a placeholder Dialog Object for it MUST be of type "recording" if the call was set up, or of type "incomplete" if it was not. There may be more than one placeholder Dialog Object in the vCon. They are distinct by the order or index in the Dialog Object array. 4.5.1. type * type: "String" (required, unless the Dialog Object is empty) Petrie Expires 4 May 2027 [Page 52] Internet-Draft JSON vCon October 2026 The string MUST have the value of either "recording", "text" or "incomplete", or a value defined in a vCon extension. The handling of a Dialog Object with a type which is not recognized is described in Section 2.5. The type parameter MUST be present in all Dialog Objects, unless the Dialog Object is completely empty. An empty Dialog Object ({}) contains no parameters and has no meaning. An empty Dialog Object may be used to hold a position in the dialog array, such that the indices of the other Dialog Objects, and the references to them, do not change. For example, an empty Dialog Object may be inserted as a placeholder for a Dialog Object that is to be filled in later, or may replace a Dialog Object that is removed when a vCon is redacted (see Redaction Techniques (Section 5)) or edited. The semantics of each Dialog Object type are described in the following subsections. The applicability of each of the Dialog Object parameters to each of the types is summarized in Section 4.5.1.4. 4.5.1.1. recording A dialog of type "recording" has Dialog Content that either contains a body or refers to via url, which is a recording of the video and/or audio of a segment of the conversation. A recording of a conversation may be captured using one of a number of topologies. The following recording topologies are supported by the recording Dialog Object: * single channel - a single recording Dialog Object with one channel, into which the audio of all of the parties is mixed * multi-channel - a single recording Dialog Object with a separate channel for each party or set of parties * per party - a separate single channel recording Dialog Object for each party, which starts when the party joins and ends when the party drops * talk spurt - a separate recording Dialog Object for each party and each contiguous period in which that party talks, with the silence trimmed out * channel contributor changes - a recording Dialog Object in which the party(s) contributing to a channel change over the duration of the recording, for example a conference bridge which records only the parties that it detects as talking (see Section 4.3.1.4) Petrie Expires 4 May 2027 [Page 53] Internet-Draft JSON vCon October 2026 * segmented - any of the other topologies, in which a recording is stopped and a new recording Dialog Object is started for the same party(s), for example when the recording reaches a maximum duration, such that the recording is a sequence of consecutive recording Dialog Objects The per party, talk spurt and segmented topologies use more than one recording Dialog Object, which collectively represent the call or session. In these topologies, the Session Object is important in defining which Dialog Objects are part of a conversation, side bar conversation or call segment (see Section 4.2.7). This allows a single vCon to contain multiple, clearly defined conversations, side bar conversations or call segments (see Section 4.1.10). 4.5.1.2. text A dialog of type "text" has Dialog Content that either contains a body or refers to via url, which contains a single message from one of the parties. 4.5.1.3. incomplete A dialog of type "incomplete" captures a call or conversation that failed to be setup to the point of exchanging any conversation. As no conversation was exchanged, an incomplete Dialog Object does not have Dialog Content (see Section 4.5.7). An incomplete Dialog Object has a required disposition parameter which indicates why the call or conversation failed (see Section 4.5.8). 4.5.1.4. Dialog Object Parameter Applicability by Type The following table summarizes which Dialog Object parameters apply to each Dialog Object type. The parameter definitions in the subsections of this document are definitive; this table is provided as a summary. The symbols used in the table are defined as follows. M The parameter MUST be present. S The parameter SHOULD be present. O The parameter is optional. SN The parameter SHOULD NOT be present. X The parameter MUST NOT be present. Petrie Expires 4 May 2027 [Page 54] Internet-Draft JSON vCon October 2026 +===================+===========+=======+============+ | Parameter | recording | text | incomplete | +===================+===========+=======+============+ | type | M | M | M | +-------------------+-----------+-------+------------+ | start | S | S | S | +-------------------+-----------+-------+------------+ | duration | O | O | O | +-------------------+-----------+-------+------------+ | parties | S | S | O | +-------------------+-----------+-------+------------+ | mediatype | M (1) | M (1) | X | +-------------------+-----------+-------+------------+ | filename | O | O | X | +-------------------+-----------+-------+------------+ | body | S (2) | S (2) | X | +-------------------+-----------+-------+------------+ | encoding | S (3) | S (3) | X | +-------------------+-----------+-------+------------+ | url | S (2) | S (2) | X | +-------------------+-----------+-------+------------+ | content_hash | S (4) | S (4) | X | +-------------------+-----------+-------+------------+ | disposition | SN | SN | M | +-------------------+-----------+-------+------------+ | session_id | O | O | O | +-------------------+-----------+-------+------------+ | application | O | O | O | +-------------------+-----------+-------+------------+ | message_id | O | O | X | +-------------------+-----------+-------+------------+ | redacted_segments | O | SN | X | +-------------------+-----------+-------+------------+ Table 5 (1) MUST be present for inline Dialog Content; optional for externally referenced Dialog Content when the media type is provided in the [HTTPS] Content-Type header; not required when Dialog Content is absent, such as in a placeholder Dialog Object or a redacted vCon. (2) body or url MAY be absent in a redacted vCon. (3) MUST be present when the body parameter is present and is not an empty string (see Inline Files (Section 2.3)). (4) MUST be present when the url parameter is present (see Section 2.4.2). Petrie Expires 4 May 2027 [Page 55] Internet-Draft JSON vCon October 2026 4.5.2. start The start parameter contains the date and time for the beginning of the captured piece of dialog. The start parameter SHOULD be present unless it is not known. For text it is the time that the party started typing or if not available, then it is the time the text was sent. For audio and video recordings, it is the time which corresponds to the beginning of the recording. It should be noted that Dialog Objects may not be ordered by the value of the start parameter. Dialog Objects in the dialog array are in order that they were added to the vCon and cannot be reordered with out correcting the dialog indices which occur in other Objects in the vCon. * start: "Date" 4.5.3. duration The duration parameter contains the duration in seconds of the referenced or included piece of dialog. For text, if known, it is the time duration from when the party started typing to when they completed typing and the text was sent. For recordings, it is the duration of the recording. For an "incomplete" type Dialog Object, the duration parameter may capture the time from the attempt to setup the call or conversation until it failed. * duration: "UnsignedInt" | "UnsignedFloat" (optional) The value MUST be the dialog duration in seconds. 4.5.4. parties The party(s) which generated the text or recording for this piece of dialog are indicated in the parties parameter. These parties are the contributors to the Dialog Object. The receivers of the dialog are indicated in the parties parameter of the Session Object which references this Dialog Object (see Section 4.2.3). The parties parameter SHOULD be present in "recording" and "text" type Dialog Objects. The parties parameter is optional for "incomplete" type Dialog Objects, where it indicates the party that attempted to set up the call or conversation (i.e. the caller or originator). The party(s) to which the call or conversation setup was attempted are indicated in the parties parameter of the Session Object which references the "incomplete" type Dialog Object. * parties: "UnsignedInt" | "UnsignedInt[]" | ("UnsignedInt" | "UnsignedInt[]" | null)[] Petrie Expires 4 May 2027 [Page 56] Internet-Draft JSON vCon October 2026 Single channel recordings should have a parties value of the form: "UnsignedInt" or "UnsignedInt[]" where the integer value or array of integer values are the indices to the Party Object(s) in the parties array that contributed to the mix for the single channel recording. The index for the Party Object SHOULD be included even if the indicated party was silent the entire piece of dialog. Multi-channel recordings MUST have a parties value that is an array of the same size as the number of channels in the recording. The values in that array are either an integer or an array of integers which are the indices to the parties that contributed to the mix for the associated channel of the recording. The index for Party Objects SHOULD be included even if the party was silent the entire conversation. If not all channels are used in a recording, such that no parties are recorded on one or more channels, a null placeholder MUST be inserted into the parties array for the corresponding channel. By default, the party(s) indicated in the parties parameter for a channel are the contributors to that channel for the entire duration of the recording. The contributors to a channel may change over the duration of the recording (see the channel contributor changes recording topology in Section 4.5.1.1). Such changes are indicated by channel-contributors Event Objects which reference the Dialog Object and the channel (see Section 4.3.1.4). When one or more channel-contributors Event Objects exist for a channel, the parties parameter for that channel indicates the contributors at the start of the recording. In that case, a null value for the channel indicates that no party contributes to the channel at the start of the recording. If the contributors to a channel change, but the times at which they change are not known, the parties parameter for that channel SHOULD contain all of the parties which contributed to that channel over the duration of the recording, and no channel- contributors Event Object is provided for that channel. Some recording systems represent a single call or session using multiple recording Dialog Objects. This may occur when recordings are periodically segmented or when separate recordings are created for each party and talk spurt. In these cases, a single recording Dialog Object identifies only the parties captured, or potentially captured, in that recording. Other participants are identified only in the recording Dialog Objects in which they are captured or potentially captured. As a result, no single recording Dialog Object necessarily identifies all parties participating in the conversation. The parties parameter of a Dialog Object only references the parties that contributed, or potentially contributed, to the Dialog Content of that Dialog Object. The complete call or session is represented by a Session Object which references the Dialog Objects that are part Petrie Expires 4 May 2027 [Page 57] Internet-Draft JSON vCon October 2026 of it (see Section 4.2). The parties parameter of the Session Object identifies the receivers of the dialog in the call or session (see Section 4.2.3). The start and duration parameters of the Session Object identify the time period of the call or session, which may differ from the time periods of the Dialog Objects which it references (see Section 4.2.1 and Section 4.2.2). The originator of the call or session is indicated in the Session Object (see Section 4.2.4). In some cases, there may be a separate recording file for each party in a conversation, where only one party is recorded per file. It should be noted that the recordings may be shorter than the collective conference when there is a separate recording per speaker/party. For example the recording(s) of the individual speaker may be trimmed to only the parts where they are actually speaking. In the email context, [SMTP] messages have the headers From, To, Cc and Bcc. The party in the From header is the sender of the message and the contributor to the text Dialog Object. The From header party SHOULD be the only party in the parties parameter for the text Dialog Object. The parties listed in the To, Cc and Bcc [SMTP] headers (if present) are the receivers of the message. The sender is also a receiver of the message, as the sender retains a copy of the message that they sent. The sender and the other receivers SHOULD be included in the parties parameter of the Session Object which references the text Dialog Object (see Section 4.2.3). The Bcc parties are private to the sender. The sender SHOULD be allowed to set a policy, through out of band means, as to whether the Bcc parties are included in the vCon. In the absence of such a policy, the Bcc parties MAY be included in a vCon which is for the use of the sender, and SHOULD NOT be included in a vCon which is for broader use. When the Bcc parties are not included in the vCon, they SHOULD NOT be referenced in the Session Object parties parameter. A Party Object SHOULD NOT be included for a Bcc party, unless that party is also the sender or a To or Cc receiver of another message in the vCon. The Bcc header SHOULD also be removed from the Dialog Content, and the Session Objects SHOULD be constructed as if the Bcc parties were not receivers of that message. A vCon which includes the Bcc parties may be redacted to remove them for broader use (see Redaction Techniques (Section 5)). A text Dialog Object should only contain a single [SMTP] message. Each message in an email thread may have a different set of receivers. The set of receivers of a message includes its sender. If all of the messages in the thread have the same set of receivers, a single Session Object which references all of the text Dialog Objects for the thread is sufficient. Otherwise, the thread is represented by a parent Session Object which references a child Session Object for each set of receivers (see Section 4.2.6). Each time the set of receivers changes from one message to the next, Petrie Expires 4 May 2027 [Page 58] Internet-Draft JSON vCon October 2026 a new Session Object is created as a child of the Session Object for the email thread. That child Session Object references the text Dialog Object(s) for the message(s) sent to that set of receivers. The parties parameter of each child Session Object contains the receivers of the messages referenced by that child Session Object. The parties parameter of the parent Session Object contains the receivers of all of the messages in the thread. 4.5.5. mediatype The media type for the piece of dialog included or referenced is provided in the mediatype parameter. The mediatype parameter MUST be provided for inline dialog files and MUST be provided if the Content- Type header in the [HTTPS] response for the externally referenced URL is not provided. The mediatype parameter is not required when the Dialog Content is absent, such as in a placeholder Dialog Object or when the body and url have been redacted. The mediatype parameter MUST NOT be present in "incomplete" type Dialog Objects as they do not have Dialog Content. * mediatype: "Mediatype" (optional for externally referenced files, if absent, this is provided in the [HTTPS] Content-Type header) The media types SHOULD be one of the following strings: * "text/plain" * "audio/x-wav" * "audio/x-mp3" * "audio/x-mp4" * "audio/ogg" * "video/x-mp4" * "video/ogg" * "multipart/mixed" Note: multi-part will also likely include the boundary parameter Petrie Expires 4 May 2027 [Page 59] Internet-Draft JSON vCon October 2026 4.5.6. filename It is sometimes useful to preserve the name of the file which originally contained this piece of dialog. This can be done in the filename parameter. The filename parameter MUST NOT be present in "incomplete" type Dialog Objects as they do not have Dialog Content. * filename: "String" (optional) 4.5.7. Dialog Content The Dialog Object SHOULD contain the body and encoding parameters or the url and content_hash parameters for all dialog types other than "incomplete" (see Inline Files (Section 2.3) and Externally Referenced Files (Section 2.4)). These parameters MUST NOT be present for the "incomplete" dialog type. The exception to this is that the body or url MAY be absent if it is redacted. For inline included dialog: * body: "*" (optional in a redacted vCon) * encoding: "String" Alternatively, for externally referenced dialog: * url: "String" (optional in a redacted vCon) * content_hash: "ContentHash" | "ContentHash[]" 4.5.8. disposition If the dialog type is "incomplete", it MUST have a disposition parameter. If the reason that the call or conversation failed is not known, such as in a placeholder Dialog Object, the disposition value "failed" SHOULD be used. The value of the disposition parameter provides the reason that the "call control" failed. The term: "call control" is used in a loose sense, as there in not always a call involved, to differentiate from a call disposition that an agent may assign to a call to indicate the reason, issue addressed or outcome of a conversation. This latter definition of call disposition is not dialog, but analysis of the conversation and is not included in the dialog portion. * disposition: "String" (required for incomplete type Dialog Objects, SHOULD NOT be present for other dialog types) Petrie Expires 4 May 2027 [Page 60] Internet-Draft JSON vCon October 2026 The value of the disposition parameter MUST be one of the following strings or a value defined in a vCon extension: * "no-answer" - a call or connection was attempted, but no one answered or accepted the connection * "congestion" - a call or connection was attempted, but was unable to be completed due to system load * "failed" - a call or connection was attempted, but failed * "busy" - a call or connection was attempted, but the party was busy with another conversation * "hung-up" - a call or connection was made, but the party hung-up before any conversation occurred * "voicemail-no-message" - a call or connection was made, the voicemail system answered, but no message was left Note: if a message was left with the voicemail system this is no longer an "incomplete" type dialog, it is a "recording" type and the conversation SHOULD be included in the Dialog Content. The handling of a Dialog Object with a disposition which is not recognized is described in Section 2.5. 4.5.9. session_id The [SESSION-ID] MAY be included for the dialog. If the same [SESSION-ID] applies to all the parties in a dialog, than a single instance of the SessionId Object is provided as the value of session_id. If some parties have a different or no associated [SESSION-ID] for this Dialog Object, then the array structure of the session_id objects MUST correlate to the array structure of the Dialog Object's parties index array. Parties which do not have a [SESSION-ID] associated with this dialog, MUST have an empty object ({}) for the SessionId Object. That an empty Object and not an Object with two "nil UUIDs" as defined in section 7 of [SESSION-ID]. It is also possible that the SessionId Object will not have values for both the local and remote parameters in some conferencing situations (See [SESSION-ID]). In the case that one end of the [SESSION-ID] does not have a UUID, the "nil UUID" String value SHOULD be used as defined in section 7 of [SESSION-ID]. When a call or session is represented by multiple Dialog Objects, each may capture only a leg or subset of the parties of the call or session; the session_id values on those Dialog Objects follow the party correlation rules above. The Session Object is the appropriate place Petrie Expires 4 May 2027 [Page 61] Internet-Draft JSON vCon October 2026 to capture a session identifier that applies to the call or session as a whole (see Section 4.2.5). * session_id: "SessionId" | "SessionId[]" | ("SessionId" | "SessionId[]")[] (optional) 4.5.10. application The application parameter is used to capture the application, communication channel or context over which the conversation was held. The conversation mode can be identified by looking at the dialog type. However that does not different between different communication platform service providers or hosting service. For example, the application parameter can be used to identify the web conference hosting service. * application: "String" (optional) 4.5.11. message_id Some messaging systems assign a unique message identifier to each message. The message_id parameter is applicable to "recording" and "text" type Dialog Objects and MUST NOT be present in "incomplete" type Dialog Objects. The message_id parameter may be used to label the message for either cross referencing back to the messaging system or to prevent the addition of duplicate messages to the vCon. For example SMTP [SMTP] messages have a message-id in the SMTP header. In the SMTP case a message may exist in multiple mailboxes or tags. When exporting these SMTP messages, the message_id parameter may be used to avoid adding the same message, to the vCon containing the email thread, more than once. * message_id: "String" (optional) 4.5.12. redacted_segments One of the ways to perform redaction on audio content is to substitute the segments containing the information with a "beep" sound for audio. For video, specific parts of the video can be blurred out, or the video can be blackened entirely. When this happens, a human can easily discern that redaction has occurred. However, it is not easy for software systems to determine this. There are many cases where we want a piece of software processing a VCON to know that such redaction has happened, where it happened, and which parties content was redacted. For example, a troubleshooting tool might want to call out these segments to a user whose role is to confirm that redaction is working well. Petrie Expires 4 May 2027 [Page 62] Internet-Draft JSON vCon October 2026 The redacted_segments field contains an array of one or more Redacted_segments Objects (Section 4.5.12.1). This field is optional, but SHOULD be included in a redacted vCon. * redacted_segments: "Redacted_segments[]" (optional) 4.5.12.1. Redacted_segments Object The object contains the following parameters: * start: "Date" (required) The start time of the audiovisual redaction. * end: "Date" (required) The end time of the audiovisual redaction. TODO: should use duration instead of end? * parties: "UnsignedInt[]" (optional) An array of indices into the parties Object array to the parties whose content has been redacted. This is useful when the dialog contains a blend of multiple contributors, and it is desired to indicate which one has been redacted. 4.6. Attachment Object Ancillary documents to the conversation are included or referenced in the Attachment Object. There is no constraint on the types files which can be included or referenced. As most modes of communication, that allow the exchange of files, do not constrain the file type, any file type may be included here. 4.6.1. purpose The purpose parameter may be used to provide a text base description of the purpose or point of the attachment. There is no restricted set of values for this description. * purpose: "String" (optional) Petrie Expires 4 May 2027 [Page 63] Internet-Draft JSON vCon October 2026 4.6.2. start The start parameter contains the date and time that the Attachment Object was sent/exchanged. It should be noted that Attachment Objects may not be ordered by the value of the start parameter. Attachment Objects in the attachments array are in order that they were added to the vCon and cannot be reordered with out correcting the attachment indices which may occur in other Objects in the vCon. * start: "Date" 4.6.3. party In most conversations, ancillary documents originate from one of the parties involved in the conversation. This party is not necessarily the document's author, but rather the party that distributed the document. The distributing party is identified by the party parameter in the Attachment Object. To provide provenance for the attachment, the party index MUST be specified. The identified party need not be a participant in the conversation itself. For example, an organization that processes or constructs the vCon may add attachments containing information about the conversation. The organization or entity that adds the attachment SHOULD be represented as a Party Object. * party: "UnsignedInt" The value of the party parameter is the index into the Party Object array to the party that contributed the attachment. 4.6.4. dialog Attachments are added as data related to a dialog or a session. The dialog parameter is used to identify the dialog that the attachment is part of. * dialog: "UnsignedInt" (optional) The value of the dialog parameter is the index into the dialog Object array to the Dialog Object to which this Attachment Object relates. At least one of the dialog or session parameters MUST be present (see Section 4.6.5). 4.6.5. session Attachments may be related to one or more sessions as opposed to a specific dialog. The session parameter is used to identify the sessions that the attachment is part of. Petrie Expires 4 May 2027 [Page 64] Internet-Draft JSON vCon October 2026 * session: "UnsignedInt" | "UnsignedInt[]" (optional) The value of the session parameter is the index to the session or array of indices to the Session Object array to which this Attachment Object relates. The requirement for the dialog or session parameter to be present is defined in Section 4.6.4. 4.6.6. mediatype The media type for the included or referenced attachment file is provided in the mediatype parameter. The mediatype parameter MUST be provided for inline attachment files and MUST be provided if the Content-Type header in the [HTTPS] response for the externally referenced URL is not provided. The mediatype parameter is not required when the Attachment Content is absent, such as when the body and url have been redacted. * mediatype: "Mediatype" (optional for externally referenced files, if absent, this is provided in the [HTTPS] Content-Type header) The mediatype string contains the media type or [MIME] type of the attached file. 4.6.7. filename It is sometimes useful to preserve the name of the file which originally contained this attachment file. This can be done in the filename parameter. * filename: "String" (optional) The file name string contains an optional name for the attachment file referenced in this Attachment Object. 4.6.8. Attachment Content The Attachment Object SHOULD contain the body and encoding parameters or the url and content_hash parameters (see Inline Files (Section 2.3) and Externally Referenced Files (Section 2.4)). The exception to this is that the body or url MAY be absent if it is redacted. For inline included attachments: * body: "*" * encoding: "String" Petrie Expires 4 May 2027 [Page 65] Internet-Draft JSON vCon October 2026 Alternatively, for externally referenced attachments: * url: "String" * content_hash: "ContentHash" | "ContentHash[]" 4.7. Analysis Object Analysis is a broad and in some cases developing field. This document does not attempt to suggest a SHOULD support list of types. Nor are formats for analysis data defined in this document. That is for research and specification outside the scope of this document. For this reason the Analysis Object provides multiple ways to define the media type of the analysis file. If a well known media type is defined, it SHOULD be used. For analysis data or files types for which a media type is not defined, the vendor and schema parameters SHOULD be used. 4.7.1. type The type parameter is used to label the semantic type of analysis data. * type: "String" The string value SHOULD be one of the following: * "report" * "sentiment" * "summary" * "transcript" * "translation" * "tts" 4.7.2. dialog Analysis typically pertains to one or more of the Dialog Objects in the dialog array. The dialog parameter is used to indicate which Dialog Objects this analysis was based upon. * dialog: "UnsignedInt" | "UnsignedInt[]" (optional) Petrie Expires 4 May 2027 [Page 66] Internet-Draft JSON vCon October 2026 The value of the dialog parameter is the index to the dialog or array of indices to the Dialog Object array to which this Analysis Object corresponds. At least one of the dialog, sessions, attachment or analysis parameters SHOULD be present to indicate the scope of what was input to the analysis (see Section 4.7.3, Section 4.7.4 and Section 4.7.5). Analysis may also be based upon data which is not contained in the vCon, in which case none of these parameters may apply. 4.7.3. sessions Analysis may pertain to one or more sessions as a whole, as opposed to specific Dialog Objects. The sessions parameter is used to indicate which Session Objects this analysis was based upon. * sessions: "UnsignedInt" | "UnsignedInt[]" (optional) The value of the sessions parameter is the index to the session or array of indices to the Session Object array to which this Analysis Object corresponds. 4.7.4. attachment The analysis may pertain to one or more of the Attachment Objects in the attachment array. The attachment parameter is used to indicate which Attachment Objects this analysis was based upon. * attachment: "UnsignedInt" | "UnsignedInt[]" (optional) The value of the attachment parameter is the index to the attachment or array of indices to the Attachment Object array to which this analysis object corresponds. 4.7.5. analysis The analysis may be derived from one or more of the other Analysis Objects in the analysis array. The analysis parameter is used to indicate which Analysis Objects this analysis was based upon. * analysis: "UnsignedInt" | "UnsignedInt[]" (optional) The value of the analysis parameter is the index to the analysis or array of indices to the Analysis Object array to which this Analysis Object corresponds. An Analysis Object MUST NOT reference itself in the analysis parameter. Petrie Expires 4 May 2027 [Page 67] Internet-Draft JSON vCon October 2026 4.7.6. mediatype The media type for the included or referenced analysis file is provided in the mediatype parameter. The mediatype parameter SHOULD be provided for inline analysis files and for externally referenced analysis files when the Content-Type header in the [HTTPS] response is not provided. A media type may not be defined for the format of the analysis data; in this case the vendor, product and schema parameters SHOULD be used to identify the data format instead. * mediatype: "Mediatype" (optional) The mediatype string contains the media type or [MIME] type of the analysis file. 4.7.7. filename It is sometimes useful to preserve the name of the file which originally contained this analysis data. This can be done in the filename parameter. * filename: "String" (optional) The file name string contains an optional name for the analysis data file referenced in this Analysis Object. 4.7.8. vendor There may not be a IANA registered media type for the file format containing the analysis data. Even if a media type is defined, it is often useful to keep a record of the vendor that produced the software that produced the analysis. Different implementations perform differently and knowing the implementation can be useful in interpreting the analysis. For this reason, the vendor or product name is provided in the vendor parameter. The vendor parameter is provided even when the mediatype parameter fully identifies the data format, as a record of the implementation that generated or provided the analysis. * vendor: "String" The vendor string value contains the vendor or product name of the software which generated this analysis. Petrie Expires 4 May 2027 [Page 68] Internet-Draft JSON vCon October 2026 4.7.9. product As the vendor may have more than one product, the product parameter may be used to differentiate it from other products which may have different schemas of analysis data. * product: "String" (optional) 4.7.10. schema The same vendor or software product may produce different formats or data for the same analysis. The schema parameter allows the data format, schema or configuration used to generate the analysis to be saved with the included or referenced analysis data. * schema: "String" (optional) The schema string contains a token or label for the data format or schema for the analysis data. As the vendor name may not be specific enough to identify the format of the analysis, the schema value is provide to differentiate from potentially multiple data formats for analysis provided by the same vendor or software. 4.7.11. Analysis Content The Analysis Object SHOULD contain the body and encoding parameters or the url and content_hash parameters (see Inline Files (Section 2.3) and Externally Referenced Files (Section 2.4)). The exception to this is that the body or url MAY be absent if it is redacted. If the Analysis Object contains or references content, sufficient information to interpret the format of that content SHOULD be provided in the Analysis Object. The mediatype parameter identifies the syntax of the content. Some media types, such as "text/vtt", fully identify the data format. Generic media types, such as "application/json" or "text/csv", identify only the syntax and not the schema of the data within it. When the mediatype parameter is absent or does not fully identify the data format, the schema parameter, together with the vendor and product parameters, SHOULD identify the data format. For externally referenced content, the media type may also be provided by the Content-Type header in the [HTTPS] response (see Section 4.7.6). For inline included analysis: * body: "*" * encoding: "String" Petrie Expires 4 May 2027 [Page 69] Internet-Draft JSON vCon October 2026 Alternatively, for externally referenced analysis: * url: "String" * content_hash: "ContentHash" | "ContentHash[]" 4.8. Redacted_string Object The redacted string object provides information about a string which was redacted from the vCon. 4.8.1. Ref * ref: "UnsignedInt" (required) The reference to the string which was redacted, which will be present elsewhere in the document. This is always between 1 and 99999. 4.8.2. Type * type: "String" (optional) The type of string information which was redacted. This is an extensible string enumeration. The following values are defined, representing the most common forms of sensitive information redacted from conversations: * GOVT_ID_NUM: A government issued identifier, such as a social security number, passport number, drivers license number, taxpayer ID, and o on. * FIN_ID_NUM: A financial institution identifier, such as a bank account number, a routing number, a wire number, PIN codes, and so on. * MED_ID_NUM: A medical identifier, such as a patient ID * BIOMETRIC: A string containing biometric data, typically in some encoded form for representation. Examples would include a fingerprint, retina scan, or face geometry. * AUTH_DATA: Data used for a user to authenticate themselves, such as a password, digital certificate, or security questions or answers. * CONTACT_INFO: Full name, email, physical mailing address, phone numbers, and so on. Petrie Expires 4 May 2027 [Page 70] Internet-Draft JSON vCon October 2026 * LOC_INFO: Zip code, GPS location data, IP addresses, MAC addresses * EMPL_INFO: Work information, such as a job title, job code, salary, and so on. * BELIEF_INFO: Religious preference, political party or preference, sexual orientation * UNSPECIFIED: Used when the type is not known, not specified, or not able to be determined. TODO: add IANA registry. Other values can be used, in which case an implementation not familiar with the value treats it as UNSPECIFIED. Absence of this field is also the same as UNSPECIFIED. 4.8.3. Orig * orig: "String" (optional) The original, unredacted value of the string. This is useful in applications of vCons where the desired property is not data redaction, but data identification. This may allow downstream vCon processors to perform the redaction (which is as simple as removing the "orig" field), or to allow redaction in the user interface (for example, a first name in a transcript is not shown to the user unless they right-click and elect to reveal the information). It is also useful for downstream data processing applications which generate analytics and create aggregates off of this information. 5. Redaction Techniques vCon has many ways in which sensitive information can be redacted from a vCon. This section summarizes them. Whenever any of these redaction techniques are employed, the redacted_from element SHOULD be added to the vCon referencing its prior, unredacted version. Data which is to be completely removed from the redacted version, that is contained in a JSON array in the unredacted vCon, SHOULD create an empty placeholder such that object array indices do not change for the rest of the elements of the array. If an element is removed entirely, all indexes to that array MUST be revised. Petrie Expires 4 May 2027 [Page 71] Internet-Draft JSON vCon October 2026 5.1. Recording Content Removal If an audio recording, or a text chat, contains sensitive information, the offending Dialog Content (either the body or the url) can be removed from the vCon. Note that, in this case, the Dialog object itself is still present with its meta-data, such as the start and end times. It is RECOMMENDED that the Dialog Content is removed - rather than removing the entire Dialog object itself. Doing so requires the Dialog array to be reindexed and all references to it updated. It also obscures the fact that redaction was performed, which may confuse downstream processors or players. 5.2. Participant Information Hiding It may be desired to hide the fact that a participant was present in a conversation. In that case, the simplest approach is to remove all of their attributes from their Party object - resulting in an empty but valid party object of {}. This approach is efficient in that it can be done without touching anything else in the vCon. The vCon still indicates that SOMEONE was there, but there is no identifying information for them. Similarly, if a dialog contains emails and the desire is to remove the set of participants who were BCC'd, those parties can be removed from the corresponding parties array in the session object. String redaction can also be used to hide the identity of the party that was BCC'd, while still indicating that someone received the mail. 5.3. Audiovisual Content Rewriting For audio, a "beep" can be added; for video, the video can have blur effects applied or the entire video can be blackened. These all require codec-level operations. If they are done, the fact that they were done SHOULD be signaled with the inclusion of the redacted_segments field in the Dialog object. 5.4. String Redaction The vCon format supports a general purpose string redaction methodology, through the usage of the redacted_strings array. This can be used to remove any sensitive information present in string format anywhere in the vCon. Petrie Expires 4 May 2027 [Page 72] Internet-Draft JSON vCon October 2026 When an audio or video recording has been transcribed, and the transcription is present in the vCon, if a segment of audio or video is redacted, it is RECOMMENDED to also redact the transcript of the transcribed version of that sensitive information, using string redaction. A tempting alternative to using the redacted_strings array is to just perform inline substitution of text, replacing (for example) a social security number with "XXX-XX-XXXX". This is NOT RECOMMENDED. Downstream processors cannot easily differentiate a redacted version of a field with a valid field, potentially breaking them. 5.5. Regeneration of the vCon In some cases, the goal of redaction is to also hide the fact that redaction was ever even done. In that case, the vCon can be regenerated. Regeneration produces a totally new vCon with no connections to the original, all arrays (like Party) reindexed to hide any missing information, and the redacted_from field removed. Similarly, sensitive strings like a social security number can be replaced with valid, but incorrect versions. 6. Security Considerations The security concerns for vCons can put into two categories: making the conversation immutable through integrity verification and protecting the confidentiality of privacy of the parties to the conversation and/or their PII. These requirements along with need to evolve a vCon (e.g. adding analysis, translations and transcriptions) conflict in some ways. To enable this, multiple versions of a vCon may be created. Versions of a vCon may add information (e.g. analysis added to a prior vCon referenced by the amended_from (Section 4.1.9)) and versions that remove information (e.g. redactions of privacy information removed from the vCon referenced in the redacted_from (Section 4.1.8)). Redactions may be at different levels for example: * PII masked to remove PII data in the text, audio, video or transcripts * De-identified to remove segments or whole recordings that might be used for voice printing or facial recognition Petrie Expires 4 May 2027 [Page 73] Internet-Draft JSON vCon October 2026 Different parts and versions of a vCon may be created in different security domains over a period of time. In addition, some conversation data may be referenced externally through an HTTPS URL as opposed to completely contained within the vCon. Typically a conversation of one mode, will be hosted or observed in a single domain. This will likely fall into one of the following hosting situations: * Enterprise Hosted Communications * Software as a Service (SaaS) Hosted Communications * Service Provider Hosted Communications The distinction among these has gotten clouded over recent years. The import consideration is that each is a different security domain. Information about a conversation captured in an enterprise communications system (e.g. meta data and Dialog Object(s) recorded in an IP PBX) is a different security domain from a SaaS transcription service (i.e. an Analysis Object). Before a vCon leaves a security domain, it SHOULD be signed to prevent it from being altered. If the new security domain needs to alter it, a new vCon is created with the removed or added data and the prior version is referenced (i.e. via the redacted_from (Section 4.1.8) or amended_from (Section 4.1.9)). See the redacted vCon object tree figure-1 and amended vCon object tree figure-2. If information is redacted for privacy reasons, the vCon referenced in the redacted_from (Section 4.1.8), if inline, SHOULD be encrypted to protect the privacy information in the unredacted version of the vCon. The secure storage and access of externally referenced conversation data is considered out of scope from this document. Secure mechanisms for HTTPS access and storage of files are well defined. Identity and credentials for accessing externally stored data will be exchanged out of band from the vCon. The one requirement for externally referenced data from the perspective of this document, is proof of integrity of that data. Using the above described approach for redaction and amending of data, we can reduce the security operations on a vCon to signing and encryption. Two approaches to signing are needed as we have data, in JSON format, that is contained within the vCon and may have data (typically media and file formats, often binary) not contained, inline in the vCon, that is externally referenced. Petrie Expires 4 May 2027 [Page 74] Internet-Draft JSON vCon October 2026 Externally referenced data will be "signed" using [SHA-512] hash which along with the URL of the externally referenced data is included in the vCon. [SHA-512] was chosen due to the relatively low cost to generate and verify the signature for what could be very large externally referenced media files. As the hash for each externally referenced file is contained in the vCon which will be signed, the chain of authentication is provided via the signature on the vCon itself. This document specifies the JSON format for vCons. So it seemed the logical solution for signing vCons, is JOSE [JWS] JSON Serialization and likewise for encrypting vCons is JOSE [JWE] JSON Serialization. The solutions are well documents, implementations are readily available and tested. A redacted vCon SHOULD reference it's non-redacted version. The non- redacted version of the vCon referenced from the redacted vCon MUST be encrypted such that only those with permission to view the non- redacted content can decrypt it. Any time a vCon is shared outside its original security domain, it SHOULD be signed and optionally encrypted. Files externally referenced by a vCon SHOULD always be signed with the verification information included in the vCon that references the external file as defined in Externally Referenced Files (Section 2.4) and Signing Externally Referenced Files (Section 6.1). Externally referenced files SHOULD only be transported over [HTTPS] and SHOULD be access controlled to those who are permitted to read the contents of that non-redacted vCon. vCons transported over non-secure channels such as email MUST be in the encrypted form. 6.1. Signing Externally Referenced Files In some deployments, it is not practical to include all of the file contents of a vCon inline. In support of that, a file may be externally referenced. When external files are referenced, the signature on the vCon does not secure the file contents from modification. For this reason any externally referenced files SHOULD also have a signature. vCons use the [SHA-512] hash method for integrity checking of externally referenced file content and include its url and content_hash in the vCon which are included in the integrity signature for the whole vCon. After retrieving externally referenced files, before using its content, the payload of the HTTPS request should be verified using the signature parameter value for the hash for the url body using the procedure defined in section 6.3 and 6.4 of [SHA-512]. Petrie Expires 4 May 2027 [Page 75] Internet-Draft JSON vCon October 2026 6.2. Signed Form of vCon Object A signed vCon uses [JWS] and takes the General JWS JSON Serialization Syntax form as defined in section 7.2.1 of [JWS]. The vCon General JWS JSON Serialization MUST include x5c or x5u in the unprotected header. * payload: "String" The value of the payload is the Base64Url Encoded string containing either: the unsigned form of the JSON vCon; or the gzipped [GZIP] unsigned form of the JSON vCon. The general construction of the payload string value is described in section 7.2.1 of [JWS] * signatures: "Signature[]" The value of signatures is an array of Signature Objects (Section 6.2.1) 6.2.1. Signature Object The Signature Object MUST contain a header and signature parameter as defined in section 7.2.1 of [JWS]. The protected parameter MUST be present when the JWS Protected Header is not empty and MUST be absent otherwise, as defined in section 7.2.1 of [JWS]. * header: "Header" The value of header is defined in Header Object (Section 6.2.2). * protected: "String" (present when the JWS Protected Header is not empty) The string value of protected is the Base64Url encoded JWS Protected Header as defined in section 7.2.1 of [JWS]. * signature: "String" The string value of signature is the Base64Url encoded JWS Signature as defined in section 7.2.1 of [JWS]. Petrie Expires 4 May 2027 [Page 76] Internet-Draft JSON vCon October 2026 6.2.2. Header Object The Header Object and its contents are defined in section 4 of [JWS]. The Header Object for a signed vCon MUST include at least one of x5c or x5u. The alg parameter MUST be present in either the JWS Protected Header or the Header Object. The alg parameter SHOULD be present in the JWS Protected Header so that it is integrity protected. The alg parameter MUST NOT have the value "none". As defined in section 7.2.1 of [JWS], a header parameter MUST NOT be present in both the JWS Protected Header and the Header Object. The x5c or x5u requirement makes the management and use of vCons easier, allowing the certificate chain to be found as the vCon is moved. Other header parameters defined for [JWS] MAY be present in the Header Object. * alg: "String" (MUST be present here or in the JWS Protected Header) The string value of alg is defined in section 4.1.1 of [JWS]. For a signed vCon this value SHOULD be "RS256" to maximize interoperability. * x5c: "String[]" (MUST provide at least one of x5c or x5u) The array of string values for x5c are defined in section 4.1.6 of [JWS]. * x5u: "String" (MUST provide at least one of x5c or x5u) The string value of x5u MUST contain an [HTTPS] URL as defined in section 4.1.5 of [JWS]. * uuid: "String" (SHOULD be provided) The string value of the UUID for the vCon contained in the payload parameter. This is added for convenience to not require verification of the signed vCon to get it's UUID. When the vCon is verified, the value of this uuid parameter SHOULD be verified against the UUID in the signed vCon. 6.2.3. Long Term Archiving of Signed vCons In some use cases, it may be necessary to store or archive signed vCons for compliances or records purposes for as long as 10 years or more. In most cases the keys and certificates used to sign the vCon and construct the [JWS] or signed form of the vCon, will have an expiration on the order of a few years at best. Below is an approach on how integrity may be maintained on the archived vCon. There may Petrie Expires 4 May 2027 [Page 77] Internet-Draft JSON vCon October 2026 be other approaches to this as well. For our example illustrated below, we have a vCon which was signed (labeled as JWS1). The certificate used to sign JWS1 has an expiration date. Before the expiration of the JWS1 signing certificate, the content of JWS1 (the vCon) is verified and then JWS1 is signed as the payload to construct JWS2. Before the expiration of the JWS2 certificate, the contents of JWS2 (JWS1) is verified and then JWS2 is signed as the payload to construct JWS3. The process is continued for the life of the vCon archiving. When it is desired to access the data in the archived vCon, first the outer JWS (JWS3 in diagram) is verified (payload of JWS2), then the vCon (payload in JWS1) is assumed to have valid integrity. ____________ | JWS3 | | __________ | || JWS2 || || ________ || ||| JWS1 ||| ||| ______ ||| |||| vCon |||| ||||______|||| |||________||| ||__________|| |____________| 6.3. Encrypted Form of vCon Object A vCon MUST be signed first using JWS as defined in Signed Form of vCon Object (Section 6.2), then encrypted using JWE as opposed to just encrypted with integrity protection. The rationale is that meta data and dialog will typically be collected in one security domain, then may be stored or exported to another. The signing is likely for the lifetime of the vCon, where the encryption may be shorter term or domain specific. vCons may be stored in unencrypted form, but the signed form MUST be maintained to ensure its integrity. An encrypted vCon uses [JWE] and takes the General JWE JSON Serialization Syntax form as defined in section 7.2.1 of [JWE]. The alg and enc header parameters MUST each be present in one of the header locations permitted by [JWE]. The enc parameter is the same for all recipients and is present in either the JWE Protected Header or the Unprotected Object. The alg parameter is present in the JWE Protected Header, the Unprotected Object or the Header Object of each recipient. As defined in section 7.2.1 of [JWE], a header parameter MUST NOT be present in more than one of these locations. Petrie Expires 4 May 2027 [Page 78] Internet-Draft JSON vCon October 2026 * protected: "String" (optional) The string value of protected is the Base64Url encoded JWE Protected Header as defined in section 7.2.1 of [JWE]. * unprotected: "Unprotected" * recipients: "Recipient[]" * iv: "String" The string value of iv is the Initialization Vector as constructed as defined in section 7.2.1 of [JWE]. * ciphertext: "String" The string value of ciphertext is constructed as defined in section 7.2.1 of [JWE] using the signed form of the vCon as the plaintext input for encryption. * tag: "String" The string value of tag is the Authentication Tag as defined in section 7.2.1 of [JWE]. * aad: "String" (optional) The string value of aad is the Base64Url encoded Additional Authenticated Data as defined in section 7.2.1 of [JWE]. 6.3.1. Unprotected Object * cty: "String" The string value of cty SHOULD be either "application/vcon" or "application/vcon+gzip" * enc: "String" (MUST be present here or in the JWE Protected Header) The string value of enc SHOULD be "A256CBC-HS512" * alg: "String" (MUST be present here, in the Header Object of each recipient or in the JWE Protected Header) The string value of alg is defined in section 4.1.1 of [JWE]. * uuid: "String" (SHOULD be provided) Petrie Expires 4 May 2027 [Page 79] Internet-Draft JSON vCon October 2026 The string value of the UUID for the vCon contained in the ciphertext parameter. This is provided for identification of the encrypted vCon without the need of the key to decrypt the vCon. The value of this uuid parameter SHOULD be verified when the vCon is decrypted. Other header parameters defined for [JWE] MAY be present. 6.3.2. Recipient Object * header: "Header" (optional) The value of header is defined in Header Object (Section 6.3.3). * encrypted_key: "String" (present when the JWE Encrypted Key is not empty) The string value of encrypted_key is defined in section 7.2.1 of [JWE]. 6.3.3. Header Object * alg: "String" (MUST be present here, in the Unprotected Object or in the JWE Protected Header) The string value of alg SHOULD be "RSA-OAEP". Other header parameters defined for [JWE] MAY be present. 6.4. Differentiation of vCon forms vCons in the unsigned, signed and encrypted form are all valid JSON. A vCon in any of these forms may additionally be compressed using [GZIP] as described in Section 7.2. It is necessary to distinguish which form a vCon is in, and whether it is compressed, in order to properly handle it. For example a signed vCon needs to be verified. The following is the recommended approaches to identifying which form a particular vCon is in: * unsigned The presence of one or more of the following parameters indicates that the vCon is in the unsigned form: - parties - dialog - analysis Petrie Expires 4 May 2027 [Page 80] Internet-Draft JSON vCon October 2026 - attachments - sessions - events * signed (JWS) The presence of both of the following parameters indicates that the vCon is in the signed (JWS) form: - payload - signatures * encrypted (JWE) The presence of both of the following parameters indicates that the vCon is in the encrypted (JWE) form: - ciphertext - recipients A gzip compressed vCon is not JSON and is differentiated from the JSON forms before the above parameter based rules can be applied. The gzip compressed vCon SHOULD be identified by the media type "application/vcon+gzip" when a media type is available, such as in the [HTTPS] Content-Type header. When no media type is available, a gzip compressed vCon can be identified by the gzip member header magic numbers defined in section 2.3.1 of [GZIP]. Once decompressed, the contained vCon is in one of the JSON forms and is differentiated using the parameter based rules above. 7. IANA Considerations This section includes the information required for IANA to register the application/vcon media type per [MEDIATYPE]. 7.1. JSON Format vCon Mediatype The JSON format for vCon is mandatory to implement. * Type name: application * Subtype name: vcon * Required parameters: N/A Petrie Expires 4 May 2027 [Page 81] Internet-Draft JSON vCon October 2026 * Optional parameters: N/A; unrecognized parameters should be ignored. * Encoding considerations: 8bit * Additional information: [JSON] format * Security considerations: See Security Considerations section of this document. * Interoperability considerations: The vCon schema is defined in RFC XXXX. The schema may be extended through extensions as defined there. * Published specification: This document: RFC XXXX * Applications that use this media type: * Fragment identifier considerations: N/A * Additional Information: - Deprecated alias names for this type: N/A - Magic number(s): N/A - File extension(s): "vcon" - Macintosh file type code(s): N/A - Windows Clipboard Name: VCON * Author: See the Author's Addresses section of this document. * Change controller: IETF 7.2. gzip Format vCon Mediatype A gzip format vCon is a JSON format vCon that has been compressed using the gzip [GZIP] compression algorithm. The gzip format is used to reduce the size of potentially very large vCons containing audio or video media in dialog objects. Applications SHOULD support the receiving of gzip format vCons, but do not need to use the gzip format when sending. * Type name: application * Subtype name: vcon+gzip Petrie Expires 4 May 2027 [Page 82] Internet-Draft JSON vCon October 2026 * Required parameters: N/A * Optional parameters: N/A; unrecognized parameters should be ignored. * Encoding considerations: binary * Additional information: [GZIP] compression of [JSON] format * Security considerations: See Security Considerations section of this document. * Interoperability considerations: The vCon schema is defined in RFC XXXX. The schema may be extended through extensions as defined there. * Published specification: This document: RFC XXXX * Applications that use this media type: * Fragment identifier considerations: N/A * Additional Information: - Deprecated alias names for this type: N/A - Magic number(s): N/A - File extension(s): "vcon" - Macintosh file type code(s): N/A - Windows Clipboard Name: VCON * Author: See the Author's Addresses section of this document. * Change controller: IETF 7.3. vCon JSON Registry This document defines a number of new IANA registries for the JSON vCon schema. Each Object (i.e. dict, map, dictionary) has its own registry of parameter names. All of those registries have the same registry template which is defined in the following subsection. When registering new entries, the following template should be used. The registration policy for these registries is Specification Required as defined in [RFC8126]. The Designated Experts are expected to verify that the specification is publicly available, that the name follows Petrie Expires 4 May 2027 [Page 83] Internet-Draft JSON vCon October 2026 the naming conventions of this document and that the registration does not duplicate the semantics of an existing registered entry. A registry created for a new Object defined in a vCon extension (see Section 2.5) is named in the same form as the registries defined in this document, for example "Party Object Parameter Names Registry". It is created within the vCon JSON Registry group and uses the same registry template and registration policy as the registries defined in this document. 7.3.1. Object Registry Template Parameter Name: The string name of a parameter to be used within the Object. The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Parameter Description: Brief description of the parameter Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 7.3.2. vCon Object Parameter Names Registry The following defines the initial values for the vCon Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. Petrie Expires 4 May 2027 [Page 84] Internet-Draft JSON vCon October 2026 +==================+=================+============+===============+ | Parameter Name | Parameter | Change | Specification | | | Description | Controller | Document(s) | +==================+=================+============+===============+ | vcon | Schema version | IESG | Section 4.1.1 | | | number | | RFC XXXX | +------------------+-----------------+------------+---------------+ | uuid | vCon instance | IESG | Section 4.1.2 | | | UUID | | RFC XXXX | +------------------+-----------------+------------+---------------+ | extensions | list of | IESG | Section 4.1.3 | | | extensions used | | RFC XXXX | +------------------+-----------------+------------+---------------+ | critical | list of | IESG | Section 4.1.4 | | | incompatible | | RFC XXXX | | | extensions used | | | +------------------+-----------------+------------+---------------+ | created_at | creation date | IESG | Section 4.1.5 | | | | | RFC XXXX | +------------------+-----------------+------------+---------------+ | updated_at | modification | IESG | Section 4.1.6 | | | date | | RFC XXXX | +------------------+-----------------+------------+---------------+ | subject | conversation | IESG | Section 4.1.7 | | | subject | | RFC XXXX | +------------------+-----------------+------------+---------------+ | redacted_from | Redacted Object | IESG | Section 4.1.8 | | | | | RFC XXXX | +------------------+-----------------+------------+---------------+ | amended_from | Amended Object | IESG | Section 4.1.9 | | | | | RFC XXXX | +------------------+-----------------+------------+---------------+ | group | reserved for | IESG | RFC XXXX | | | future | | | | | extension | | | +------------------+-----------------+------------+---------------+ | sessions | Session Objects | IESG | Section | | | array | | 4.1.10 RFC | | | | | XXXX | +------------------+-----------------+------------+---------------+ | events | Event Objects | IESG | Section | | | array | | 4.1.12 RFC | | | | | XXXX | +------------------+-----------------+------------+---------------+ | parties | Party Objects | IESG | Section | | | array | | 4.1.11 RFC | | | | | XXXX | +------------------+-----------------+------------+---------------+ Petrie Expires 4 May 2027 [Page 85] Internet-Draft JSON vCon October 2026 | dialog | Dialog Objects | IESG | Section | | | array | | 4.1.13 RFC | | | | | XXXX | +------------------+-----------------+------------+---------------+ | analysis | Analysis | IESG | Section | | | Objects array | | 4.1.14 RFC | | | | | XXXX | +------------------+-----------------+------------+---------------+ | attachments | Attachment | IESG | Section | | | Objects array | | 4.1.15 RFC | | | | | XXXX | +------------------+-----------------+------------+---------------+ | redacted_strings | Redacted | IESG | Section 4.8 | | | Strings array | | | +------------------+-----------------+------------+---------------+ Table 6 7.3.3. Party Object Parameter Names Registry The following defines the initial values for the Party Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. Petrie Expires 4 May 2027 [Page 86] Internet-Draft JSON vCon October 2026 +================+===================+============+================+ | Parameter Name | Parameter | Change | Specification | | | Description | Controller | Document(s) | +================+===================+============+================+ | tel | tel URL | IESG | Section 4.4.1 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | sip | SIP URL | IESG | Section 4.4.1 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | stir | STIR token | IESG | Section 4.4.3 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | mailto | mailto URL | IESG | Section 4.4.4 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | name | participant name | IESG | Section 4.4.5 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | validation | validation method | IESG | Section 4.4.7 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | gmlpos | participant | IESG | Section 4.4.8 | | | geolocation | | RFC XXXX | +----------------+-------------------+------------+----------------+ | civicaddress | civic address | IESG | Section 4.4.9 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | uuid | participant | IESG | Section 4.4.10 | | | unique identifier | | RFC XXXX | +----------------+-------------------+------------+----------------+ | type | participant type | IESG | Section 4.4.11 | | | | | RFC XXXX | +----------------+-------------------+------------+----------------+ | org | participant | IESG | Section 4.4.12 | | | organization | | RFC XXXX | +----------------+-------------------+------------+----------------+ | dept | participant | IESG | Section 4.4.13 | | | department | | RFC XXXX | +----------------+-------------------+------------+----------------+ | did | decentralized | IESG | Section 4.4.6 | | | identifier | | RFC XXXX | +----------------+-------------------+------------+----------------+ Table 7 Petrie Expires 4 May 2027 [Page 87] Internet-Draft JSON vCon October 2026 7.3.4. Dialog Object Parameter Names Registry The following defines the initial values for the Dialog Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. +===================+==================+============+===============+ | Parameter Name | Parameter | Change | Specification | | | Description | Controller | Document(s) | +===================+==================+============+===============+ | type | dialog type | IESG | Section 4.5.1 | | | name | | RFC XXXX | +-------------------+------------------+------------+---------------+ | start | dialog start | IESG | Section 4.5.2 | | | time | | RFC XXXX | +-------------------+------------------+------------+---------------+ | duration | dialog duration | IESG | Section 4.5.3 | | | period | | RFC XXXX | +-------------------+------------------+------------+---------------+ | parties | dialog parties | IESG | Section 4.5.4 | | | list | | RFC XXXX | +-------------------+------------------+------------+---------------+ | mediatype | dialog content | IESG | Section 4.5.5 | | | media type | | RFC XXXX | +-------------------+------------------+------------+---------------+ | filename | dialog content | IESG | Section 4.5.6 | | | filename | | RFC XXXX | +-------------------+------------------+------------+---------------+ | body | dialog inline | IESG | Section 4.5.7 | | | content | | RFC XXXX | +-------------------+------------------+------------+---------------+ | encoding | dialog inline | IESG | Section 4.5.7 | | | content | | RFC XXXX | | | encoding | | | +-------------------+------------------+------------+---------------+ | url | dialog | IESG | Section 4.5.7 | | | referenced | | RFC XXXX | | | content URL | | | +-------------------+------------------+------------+---------------+ | content_hash | dialog content | IESG | Section 4.5.7 | | | hash | | RFC XXXX | +-------------------+------------------+------------+---------------+ | disposition | dialog | IESG | Section 4.5.8 | | | disposition | | RFC XXXX | +-------------------+------------------+------------+---------------+ | session_id | RFC7989 session | IESG | Section 4.5.9 | | | ID | | RFC XXXX | Petrie Expires 4 May 2027 [Page 88] Internet-Draft JSON vCon October 2026 +-------------------+------------------+------------+---------------+ | application | dialog source | IESG | Section | | | application | | 4.5.10 RFC | | | | | XXXX | +-------------------+------------------+------------+---------------+ | message_id | dialog message | IESG | Section | | | id | | 4.5.11 RFC | | | | | XXXX | +-------------------+------------------+------------+---------------+ | redacted_segments | redacted | IESG | Section | | | segments | | 4.5.12 RFC | | | | | XXXX | +-------------------+------------------+------------+---------------+ Table 8 7.3.4.1. Dialog Type Name Registry This document defines a new registry for the token name values that are permitted as values to the dialog type (Section 4.5.1) parameter. 7.3.4.1.1. Dialog Type Name Registration Template Dialog Type Name: The string token name of a Dialog Object Type The name is case sensitive. Names may not match other registered names in a case- insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Dialog Type Description: Brief description of the Dialog Object type Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. Petrie Expires 4 May 2027 [Page 89] Internet-Draft JSON vCon October 2026 7.3.4.1.2. Dialog Type Name Registration Initial Values The following table defines the initial values for the Dialog Object Types Registry. +==================+=============+============+===============+ | Dialog Type Name | Dialog Type | Change | Specification | | | Description | Controller | Document(s) | +==================+=============+============+===============+ | text | text dialog | IESG | Section 4.5.1 | | | | | RFC XXXX | +------------------+-------------+------------+---------------+ | recording | recording | IESG | Section 4.5.1 | | | dialog | | RFC XXXX | +------------------+-------------+------------+---------------+ | incomplete | incomplete | IESG | Section 4.5.1 | | | dialog | | RFC XXXX | +------------------+-------------+------------+---------------+ Table 9 7.3.5. Session Object Parameter Names Registry The following defines the initial values for the Session Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. Petrie Expires 4 May 2027 [Page 90] Internet-Draft JSON vCon October 2026 +================+===================+============+===============+ | Parameter Name | Parameter | Change | Specification | | | Description | Controller | Document(s) | +================+===================+============+===============+ | start | session start | IESG | Section 4.2.1 | | | time | | RFC XXXX | +----------------+-------------------+------------+---------------+ | duration | session duration | IESG | Section 4.2.2 | | | period | | RFC XXXX | +----------------+-------------------+------------+---------------+ | parties | session parties | IESG | Section 4.2.3 | | | list | | RFC XXXX | +----------------+-------------------+------------+---------------+ | originator | session | IESG | Section 4.2.4 | | | originator party | | RFC XXXX | +----------------+-------------------+------------+---------------+ | session_id | RFC7989 session | IESG | Section 4.2.5 | | | ID | | RFC XXXX | +----------------+-------------------+------------+---------------+ | sessions | Session_Reference | IESG | Section 4.2.6 | | | Objects array | | RFC XXXX | +----------------+-------------------+------------+---------------+ | dialog | session dialog | IESG | Section 4.2.7 | | | index list | | RFC XXXX | +----------------+-------------------+------------+---------------+ Table 10 7.3.6. Session_Reference Object Parameter Names Registry The following defines the initial values for the Session_Reference Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. Petrie Expires 4 May 2027 [Page 91] Internet-Draft JSON vCon October 2026 +=============+======================+============+=================+ | Parameter | Parameter | Change | Specification | | Name | Description | Controller | Document(s) | +=============+======================+============+=================+ | session | referenced | IESG | Section 4.2.8.1 | | | session index | | RFC XXXX | +-------------+----------------------+------------+-----------------+ | type | session | IESG | Section 4.2.8.2 | | | relationship type | | RFC XXXX | +-------------+----------------------+------------+-----------------+ | description | session | IESG | Section 4.2.8.3 | | | relationship | | RFC XXXX | | | description | | | +-------------+----------------------+------------+-----------------+ Table 11 7.3.6.1. Session_Reference Type Name Registry This document defines a new registry for the token name values that are permitted as values to the Session_Reference Object type (Section 4.2.8.2) parameter. 7.3.6.1.1. Session_Reference Type Name Registration Template Session_Reference Type Name: The string token name of a Session_Reference Object type. The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Session_Reference Type Description: Brief description of the Session_Reference Object type Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. Petrie Expires 4 May 2027 [Page 92] Internet-Draft JSON vCon October 2026 7.3.6.1.2. Session_Reference Type Name Registration Initial Values The following table defines the initial values for the Session_Reference Type Name Registry. +===================+===================+==========+===============+ | Session_Reference | Session_Reference |Change | Specification | | Type Name | Type Description |Controller| Document(s) | +===================+===================+==========+===============+ | child | contained session |IESG | Section | | | | | 4.2.8.2 RFC | | | | | XXXX | +-------------------+-------------------+----------+---------------+ | peer | parallel or |IESG | Section | | | overlapping | | 4.2.8.2 RFC | | | session | | XXXX | +-------------------+-------------------+----------+---------------+ | precursor | preceding session |IESG | Section | | | | | 4.2.8.2 RFC | | | | | XXXX | +-------------------+-------------------+----------+---------------+ | breakout | breakout session |IESG | Section | | | with a subset of | | 4.2.8.2 RFC | | | the parties | | XXXX | +-------------------+-------------------+----------+---------------+ Table 12 7.3.7. Event Object Parameter Names Registry The initial values for the Event Object Parameter Names Registry are listed in the following table. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. Petrie Expires 4 May 2027 [Page 93] Internet-Draft JSON vCon October 2026 +=================+===================+============+===============+ | Parameter Name | Parameter | Change | Specification | | | Description | Controller | Document(s) | +=================+===================+============+===============+ | type | event type name | IESG | Section 4.3.1 | | | | | RFC XXXX | +-----------------+-------------------+------------+---------------+ | time | time event | IESG | Section 4.3.2 | | | occurred | | RFC XXXX | +-----------------+-------------------+------------+---------------+ | sessions | event session | IESG | Section 4.3.3 | | | indices | | RFC XXXX | +-----------------+-------------------+------------+---------------+ | party | event party index | IESG | Section 4.3.4 | | | | | RFC XXXX | +-----------------+-------------------+------------+---------------+ | dialog | event dialog | IESG | Section 4.3.5 | | | index | | RFC XXXX | +-----------------+-------------------+------------+---------------+ | channel | recording channel | IESG | Section 4.3.6 | | | index | | RFC XXXX | +-----------------+-------------------+------------+---------------+ | contributors | recording channel | IESG | Section 4.3.7 | | | contributor party | | RFC XXXX | | | indices | | | +-----------------+-------------------+------------+---------------+ | button | button label | IESG | Section 4.3.8 | | | character or | | RFC XXXX | | | string | | | +-----------------+-------------------+------------+---------------+ | transferee | transferee party | IESG | Section 4.3.9 | | | index | | RFC XXXX | +-----------------+-------------------+------------+---------------+ | transfer_target | transfer target | IESG | Section | | | party index | | 4.3.10 RFC | | | | | XXXX | +-----------------+-------------------+------------+---------------+ | consultation | consultation | IESG | Section | | | session index | | 4.3.11 RFC | | | | | XXXX | +-----------------+-------------------+------------+---------------+ | target_session | target session | IESG | Section | | | index | | 4.3.12 RFC | | | | | XXXX | +-----------------+-------------------+------------+---------------+ Table 13 Petrie Expires 4 May 2027 [Page 94] Internet-Draft JSON vCon October 2026 7.3.7.1. Event Type Name Registry This document defines a new registry for the token name values that are permitted as values to the Event Object type (Section 4.3.1) parameter. 7.3.7.1.1. Event Type Name Registration Template Event Type Name: The string token name of an Event Object type. The name is case sensitive. Names may not match other registered names in a case- insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Event Type Description: Brief description of the Event Object type Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 7.3.7.1.2. Event Type Name Registration Initial Values The following table defines the initial values for the Event Type Name Registry. +=======================+===============+==========+===============+ | Event Type Name | Event Type |Change | Specification | | | Description |Controller| Document(s) | +=======================+===============+==========+===============+ | join | party join |IESG | Section | | | event | | 4.3.1.1 RFC | | | | | XXXX | +-----------------------+---------------+----------+---------------+ | drop | party drop |IESG | Section | | | event | | 4.3.1.1 RFC | | | | | XXXX | Petrie Expires 4 May 2027 [Page 95] Internet-Draft JSON vCon October 2026 +-----------------------+---------------+----------+---------------+ | hold | party on hold |IESG | Section | | | event | | 4.3.1.1 RFC | | | | | XXXX | +-----------------------+---------------+----------+---------------+ | unhold | party off |IESG | Section | | | hold event | | 4.3.1.1 RFC | | | | | XXXX | +-----------------------+---------------+----------+---------------+ | mute | party on mute |IESG | Section | | | event | | 4.3.1.1 RFC | | | | | XXXX | +-----------------------+---------------+----------+---------------+ | unmute | party off |IESG | Section | | | mute event | | 4.3.1.1 RFC | | | | | XXXX | +-----------------------+---------------+----------+---------------+ | keydown | DTMF/app key/ |IESG | Section | | | button press | | 4.3.1.2 RFC | | | event | | XXXX | +-----------------------+---------------+----------+---------------+ | keyup | DTMF/app key/ |IESG | Section | | | button | | 4.3.1.2 RFC | | | release event | | XXXX | +-----------------------+---------------+----------+---------------+ | consultation-start | transfer |IESG | Section | | | consultation | | 4.3.1.3 RFC | | | start event | | XXXX | +-----------------------+---------------+----------+---------------+ | blind-transfer | blind |IESG | Section | | | transfer | | 4.3.1.3 RFC | | | event | | XXXX | +-----------------------+---------------+----------+---------------+ | consultative-transfer | consultative |IESG | Section | | | transfer | | 4.3.1.3 RFC | | | event | | XXXX | +-----------------------+---------------+----------+---------------+ | transfer-abandoned | transfer |IESG | Section | | | abandoned | | 4.3.1.3 RFC | | | event | | XXXX | +-----------------------+---------------+----------+---------------+ | channel-contributors | recording |IESG | Section | | | channel | | 4.3.1.4 RFC | | | contributors | | XXXX | | | change event | | | +-----------------------+---------------+----------+---------------+ Table 14 Petrie Expires 4 May 2027 [Page 96] Internet-Draft JSON vCon October 2026 7.3.8. Attachment Object Parameter Names Registry The following defines the initial values for the Attachment Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. +==============+=======================+============+===============+ | Parameter | Parameter | Change | Specification | | Name | Description | Controller | Document(s) | +==============+=======================+============+===============+ | purpose | attachment object | IESG | Section 4.6.1 | | | purpose description | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | start | attachment start | IESG | Section 4.6.2 | | | time | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | party | sending party index | IESG | Section 4.6.3 | | | | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | dialog | associated dialog | IESG | Section 4.6.4 | | | index | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | session | associated session | IESG | Section 4.6.5 | | | index | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | mediatype | attachment body | IESG | Section 4.6.6 | | | media type | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | filename | attachment content | IESG | Section 4.6.7 | | | filename | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | body | attachment inline | IESG | Section 4.6.8 | | | content | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | encoding | attachment inline | IESG | Section 4.6.8 | | | content encoding | | RFC XXXX | +--------------+-----------------------+------------+---------------+ | url | attachment | IESG | Section 4.6.8 | | | referenced content | | RFC XXXX | | | URL | | | +--------------+-----------------------+------------+---------------+ | content_hash | attachment content | IESG | Section 4.6.8 | | | hash | | RFC XXXX | +--------------+-----------------------+------------+---------------+ Table 15 Petrie Expires 4 May 2027 [Page 97] Internet-Draft JSON vCon October 2026 7.3.9. Analysis Object Parameter Names Registry The following defines the initial values for the Analysis Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. +==============+=====================+============+================+ | Parameter | Parameter | Change | Specification | | Name | Description | Controller | Document(s) | +==============+=====================+============+================+ | type | analysis type | IESG | Section 4.7.1 | | | | | RFC XXXX | +--------------+---------------------+------------+----------------+ | dialog | associated dialog | IESG | Section 4.7.2 | | | index | | RFC XXXX | +--------------+---------------------+------------+----------------+ | sessions | associated session | IESG | Section 4.7.3 | | | indices | | RFC XXXX | +--------------+---------------------+------------+----------------+ | attachment | associated | IESG | Section 4.7.4 | | | attachment index | | RFC XXXX | +--------------+---------------------+------------+----------------+ | analysis | associated analysis | IESG | Section 4.7.5 | | | index | | RFC XXXX | +--------------+---------------------+------------+----------------+ | mediatype | analysis body media | IESG | Section 4.7.6 | | | type | | RFC XXXX | +--------------+---------------------+------------+----------------+ | filename | analysis content | IESG | Section 4.7.7 | | | filename | | RFC XXXX | +--------------+---------------------+------------+----------------+ | vendor | vendor producing | IESG | Section 4.7.8 | | | content | | RFC XXXX | +--------------+---------------------+------------+----------------+ | product | vendor product | IESG | Section 4.7.9 | | | producing content | | RFC XXXX | +--------------+---------------------+------------+----------------+ | schema | product schema of | IESG | Section 4.7.10 | | | content | | RFC XXXX | +--------------+---------------------+------------+----------------+ | body | analysis inline | IESG | Section 4.7.11 | | | content | | RFC XXXX | +--------------+---------------------+------------+----------------+ | encoding | analysis inline | IESG | Section 4.7.11 | | | content encoding | | RFC XXXX | +--------------+---------------------+------------+----------------+ | url | analysis referenced | IESG | Section 4.7.11 | Petrie Expires 4 May 2027 [Page 98] Internet-Draft JSON vCon October 2026 | | content URL | | RFC XXXX | +--------------+---------------------+------------+----------------+ | content_hash | analysis content | IESG | Section 4.7.11 | | | hash | | RFC XXXX | +--------------+---------------------+------------+----------------+ Table 16 7.3.10. Redacted_from Object Parameter Names Registry The following defines the initial values for the Redacted_from Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. +==============+===============+==========+=========================+ | Parameter | Parameter |Change | Specification | | Name | Description |Controller| Document(s) | +==============+===============+==========+=========================+ | uuid | less |IESG | _#redacted_from_-object | | | redacted | | RFC XXXX | | | vCon UUID | | | +--------------+---------------+----------+-------------------------+ | type | redaction |IESG | Section 4.1.8.1 RFC | | | type or | | XXXX | | | reason | | | +--------------+---------------+----------+-------------------------+ | url | referenced |IESG | Section 4.1.8.1 RFC | | | less | | XXXX | | | redacted | | | | | vCon URL | | | +--------------+---------------+----------+-------------------------+ | content_hash | less |IESG | Section 4.1.8.1 RFC | | | redacted | | XXXX | | | vCon hash | | | +--------------+---------------+----------+-------------------------+ Table 17 7.3.11. Amended_from Object Parameter Names Registry The following defines the initial values for the Amended_from Object Parameter Names Registry. Use the template in Object Registry Template (Section 7.3.1) when registering additional entries to this table. Petrie Expires 4 May 2027 [Page 99] Internet-Draft JSON vCon October 2026 +================+==================+============+=================+ | Parameter Name | Parameter | Change | Specification | | | Description | Controller | Document(s) | +================+==================+============+=================+ | uuid | prior vCon | IESG | Section 4.1.9.1 | | | version UUID | | RFC XXXX | +----------------+------------------+------------+-----------------+ | url | referenced prior | IESG | Section 4.1.9.1 | | | version vCon URL | | RFC XXXX | +----------------+------------------+------------+-----------------+ | content_hash | prior version | IESG | Section 4.1.9.1 | | | vCon hash | | RFC XXXX | +----------------+------------------+------------+-----------------+ Table 18 7.4. vCon Extensions Names Registry This document defines and new registry for the token name values that are permitted as values to the Section 4.1.3 parameter. However it does not define any values for this registry. Values for this registry are to be defined in subsequent documents which define extensions to the vCon schema. The registration policy for this registry is Specification Required as defined in [RFC8126]. 7.4.1. Extensions Registration Template Extension Name: The string token name of an extension to the vCon JSON schema. The name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Extension Description: Brief description of the vCon extension Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Specification Document(s): Petrie Expires 4 May 2027 [Page 100] Internet-Draft JSON vCon October 2026 Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 7.5. JSON Web Signature and Encryption Header Parameters This document registers the following new parameter in the [JWS] JSON Web Signature and Encryption Header Parameters registry. * Header Parameter Name: "uuid" * Header Parameter Description: UUID of the signed object * Header Parameter Usage Location(s): JWS, JWE * Change Controller: IESG * Specification Document(s): Header Object (Section 6.2.2), Unprotected Object (Section 6.3.1) of RFC XXXX 8. References 8.1. Normative References [DID] W3C, "Decentralized Identifiers (DIDs) v1.0", July 2022, . [GEOPRIV] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, . [GZIP] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . [H-460-27] "End-to-End Session Identifier for H.323 Systems", H.460.27, November 2015, . [HTTPS] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [IANA-COSE-ALG] "COSE Algorithms", n.d., <>. Petrie Expires 4 May 2027 [Page 101] Internet-Draft JSON vCon October 2026 [JMAP] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, . [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, . [MEDIATYPE] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [PASSporT] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [PIDF-LO] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, DOI 10.17487/RFC5491, March 2009, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Petrie Expires 4 May 2027 [Page 102] Internet-Draft JSON vCon October 2026 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SESSION-ID] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7989, DOI 10.17487/RFC7989, October 2016, . [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [TEL] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, . [UUID] Peabody, B. and K. R. Davis, "New UUID Formats", Work in Progress, Internet-Draft, draft-peabody-dispatch-new-uuid- format-04, 23 June 2022, . 8.2. Informative References [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [CDR] ITU, "Recommendation Q.825: Specification of TMN applications at the Q3 interface: Call detail recording", n.d., . Petrie Expires 4 May 2027 [Page 103] Internet-Draft JSON vCon October 2026 [ISOBMFF] "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/IEC 14496-12:2022, January 2022, . [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [PY-VCON] "Python open source vCon command line interface, library and workflow server", n.d., . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [SHA-512] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [SIP] 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, July 2002, . [SIP-XFER] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, . [STIR-PASS] Wendt, C. and J. Peterson, "PASSporT Extension for Rich Call Data", Work in Progress, Internet-Draft, draft-ietf- stir-passport-rcd-26, 5 June 2023, . [vCard] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . Petrie Expires 4 May 2027 [Page 104] Internet-Draft JSON vCon October 2026 [vCon-white-paper] Howe, T., Petrie, D., Lieberman, M., and A. Quayle, "vCon: an Open Standard for Conversation Data", n.d., . Appendix A. Non-Upward Compatible Changes to the vCon Container This appendix outlines the changes between versions of the vCon container which are not upward compatible, and the high level operations needed to migrate a vCon from one version to the next. It does not describe every detail of the migration. A.1. Version 0.4.0 to 0.5.0 * The "vcon" parameter value was changed from "0.4.0" to "0.5.0". * The Session Object and the "sessions" array were added. A 0.4.0 vCon is migrated by adding a Session Object which references all of its Dialog Objects. * The "party_history" Dialog Object parameter was replaced by the Event Object and the "events" array. Each Party_History Object becomes an Event Object, with "event" renamed to "type", whose sessions parameter references the Session Object for the Dialog Object from which it came. The converted Event Object does not reference the Dialog Object, as the dialog parameter SHOULD NOT be present in the party and key event types. * The "transfer" type Dialog Object was replaced by the transfer Event Object types. Each "transfer" type Dialog Object becomes one or two Event Objects in which "transferor" becomes "party", and the Dialog Objects referenced by "original", "consultation" and "target_dialog" are each referenced through a Session Object. * The "originator" Dialog Object parameter was moved to the Session Object. Petrie Expires 4 May 2027 [Page 105] Internet-Draft JSON vCon October 2026 * The Dialog Object "parties" parameter contains only the contributors, and the receivers are in the Session Object "parties" parameter. In 0.4.0, the parties parameter of a "text" type Dialog Object contained the sender and all of the receivers of the message, with the first party being the sender unless originator was set. A 0.4.0 "text" type Dialog Object is migrated by reducing its parties to the sender, and by including all of its parties, including the sender, in the parties of the Session Object for that message. Similarly, the parties of a 0.4.0 "incomplete" type Dialog Object are reduced to the originator, or the first party if originator is not set, and the remaining parties are included in the parties of the Session Object. * The "redacted" parameter was renamed to "redacted_from", and the Redacted Object was renamed to the Redacted_from Object. * The "amended" parameter was renamed to "amended_from", and the Amended Object was renamed to the Amended_from Object. * The "recording-set" type Dialog Object, and the "recordings" and "recording_set" Dialog Object parameters, were replaced by the Session Object. A 0.4.0 "recording-set" type Dialog Object is migrated by creating a Session Object which references the Dialog Objects listed in its recordings parameter, and by removing the recording_set parameter from the recording Dialog Objects which referenced it. * Each removed "transfer" and "recording-set" type Dialog Object is replaced by an empty Dialog Object (see Section 4.5.1), so that the indices of the other Dialog Objects, and the references to them, do not change. * The alg parameter MUST NOT have the value "none". A 0.4.0 signed vCon which uses the alg value "none" is migrated by signing the vCon again with a permitted algorithm. * The extensions parameter MUST, rather than SHOULD, list the names of all vCon extensions used in the vCon. A 0.4.0 vCon which uses an extension that is not listed in its extensions parameter is migrated by adding the extension name. * Some implementations of version 0.4.0 repeated header parameters, with identical values, in more than one header of the signed and encrypted forms. Implementations which read vCons produced by those implementations may choose to accept them. Petrie Expires 4 May 2027 [Page 106] Internet-Draft JSON vCon October 2026 A.2. Version 0.3.0 to 0.4.0 * The "appended" Object was renamed to "amended" * The "must_support" parameter was renamed to "critical" to be consistent with other IETF JSON schema extension mechanisms. * The "session_id" Dialog Object parameter was changes from a String to a SessionId Object. A.3. Version 0.0.2 to 0.3.0 * "transfer-target" parameter was renamed to "transfer_target" to be consistent with other compound names that use the underscore ("_"). * "target-dialog" parameter was renamed to "target_dialog" to be consistent with other compound names that use the underscore ("_"). A.4. Version 0.0.1 to 0.0.2 * "mimetype" parameters were renamed to "mediatype" * "alg" and "signature" were combined into "content_hash" Appendix B. Example vCons This appendix contains example vCons in the unsigned, signed and encrypted form. The JSON has been indented for readability. The vCons have been formatted such that long text lines have been wrapped with a left hand white space indent for readability purposes. Links for unformatted versions of the vCons are provided for each of the examples. The example vCons in this document were generated using the [PY-VCON] command line interface. B.1. Two Party Call vCon With Inline Recording This example vCon is for a simple 2 party PSTN call. It has a single Dialog Object which contains a single channel wav format recording with the two parties audio mixed into the single channel. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_call_int_rec.vcon Petrie Expires 4 May 2027 [Page 107] Internet-Draft JSON vCon October 2026 Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. { "vcon": "0.5.0", "created_at": "2022-06-21T13:53:00-04:00", "parties": [ { "tel": "+12345678901", "name": "Alice" }, { "tel": "+19876543210", "name": "Bob" } ], "dialog": [ { "type": "recording", "start": "2022-06-21T17:53:26.000+00:00", "duration": 4.72, "parties": [ 0, 1 ], "mediatype": "audio/x-wav", "filename": "ab_call.wav", "encoding": "base64url", "body": "UklGRioeAABXQVZFZm10IBQAAAAxAAEAQB8AAFkGAABBAAAAAg BAAWZhY3QEAAAAgJMAAGRhdGH2HQAAoxjXHYXCRekuye4gK4Tsiv4wZeN htuvu3RMkgyPXme4NeahQLG0yeLayx5HCIiRWK7psbQrQTFm57NwQJvIb q1aNxk6VpMYAXSm5Bb1rgStIStvEzmCaOIabxs2gjReJ02Rk0BQtOxHkh UTIZd4VGKoq1KuoCGhrZTx1vRZICuZEcgkGjdH2jiCU1a0NMW6BE8lVHN -OYFPHcZspr0CSl1aeo2hOWUx3CbovpGqKsApWteunk8gMPMOdynRVFWR 5o0l2BvaQDcWugGRHrQa9NcEbG1LWQq_AWLpsXKdMQefGrZu4ZE2ZSDIR GJLTKpIzDybqSyZishQmjuVGztMKNlcyt2vW546JsutgllyppQWroAtHb kyrrGAx3bIiX81g1sR-oVaBbtkobA08fpJYscQSlHHcGm7hDriuWTRm8A 6GKQ1Fbcn10M30DcHctnEchwaAI7dxI2knYCQ5biNHB2Djxm3bFmyU5TA 3ALZt3DaSeABIkiRJcm0AxpEkSZI7AEiSJEmSwUYZ1mQLYNu2bdumPWDb tm3b9gOAJEmSJFkFgCRJkiQZbHRhTccDtm3btm0qAEaOJEmSPABIkiRJk jAASJIkSZLBRhfW9CKAJEmS49gCgCRJkiQ5P2Dbtm3bZgSAJEmSJClkcm VNLgBIkiRJkm8ASJIkSZIvAkiSJEmOswM2btu2bcMVmd3kIoDkyJEkySO AJEmS3AgGgCRJkhypC2DjuG3j9mxOWQiyEUQ1DAtyvQJS9aTWWc4KuFqL Petrie Expires 4 May 2027 [Page 108] Internet-Draft JSON vCon October 2026 O9F4CCJX4yeFkMaSUWSLYMkYinzGa4HzyrEi6-pgHVdXe6mugKzW7VqHY OzcDDsXWnJkeVXHFKpuLDZSrAroZOQohtASpE4dyZSRxozJQC6hJE2OLG iNYLM1ruIWzsCcRhEW6c3AJhq6bmp9cZ0IvAy2a5xJVcUMNE8Qq3G0CEJ y30SNxwrUqUy5NczWkI3S7UCk4iyrBM3AzCvJqkisQPQkcekWjYDoJk4D pWiPmUzXCtKFMkuy1g7MtWnrqLwMSqpjR8vXDipSKzk1D-bOjdLzgNQol lapqqCUmjChmctA6jRmYPOLYJtHbatocTAZCfAQ3LHs6O2zDuCC_LyStA gkklFHZesUspXsSr0S5lCRYg-hXc2tKqMsgeqYkNzSVmLc9mk08zbhzUK O3fhkzJQsvBTCcNk2s-oUxO5zpatkETyFn-xtrxRaTR0hZk3WDo5ELiFW Oq7hmMxgKjdcY0SO4Fk7cijHC6EYNXEZI6oDUQz2EeJMMh1orxSOup04u UUjOtyjwVQ3HdhpuSRyJv0WzpRTo-so7pMpdgKWUk0jlEwjiqBJAwcuw5 lca39VznGdMLAg6o-EEenbKEQxgkeS0xxEteISQcQUNPm8KxaV1xKKIq- BFEpsm_bjIFPLiJwpRoEoSZEuqWuBJLuu1oxZC8ksQB0Wkt_IqrwaSMq8 p4mzEPrFksdx9i9KZVv36AvGkMmyKsHI864U2eThk-iNKRsvgRsqL1vMT UHbPK2ZqVwNHW3oEIay3EaN7xJGgV4mmK8Q1k0O4jHPCFpRzHYxBtbOEZ FMQeMoOVQ2F8GTOXvh9-qARmvOaH9MYaOpdTIFaS-ZJO4OGmZOvo3fEig 5M8lQvwxinfXKhc4QrPGM0pIJthKKkixBYjvlZJlNwXTljSW8VWFex6ts hg7BUiVuU8VoDtlMwRBEkqXknPYWWNFMRtW_FMhsVIpV4RDESZlqtFXHV I3GSmHZyNFMV24h48qsHAdLYeumkSKhTYG1Qp0LpWhr1UitEmaJ1DxuXw gGEe62VbkIUKKbdkv2CFhIZMdnkebSjRKzoCG7Uc32ywDkqkauEsuAzOq K1vnNoKFOtloMaa5YBWwbZI_aPtKzFMpyqx7WNBXEqt43TasSiiaAKW8U 2NSFxMuA6htzZ8ougZAbtgLVamHcwpHZgq6B40DSETuvriVpKyFIUpxog TQvwrBFaY5MScRRE6GFMFGqYp5L26r4Eo2kooM941UsSSRC6NVuXVFmol 1pueTN7sLdPY-uiHbuECmzJFAvywh-KivWrRRtmK4u4p1Va666LNhrFMt F3tZKlTDvgdOFlqN-zUGbWLWajishIrY5DTNLYovSDJJ2co6MCCwrxmmd 6u0wU-CtiptRtUQohlesWT1X0I4kR-NrCEmIIFRGelq51TpDpN2jnuxFr UWfaop44QqkpsixOkeSsFwpyiIoHV4IN-NAtFJboRbtIqoILbeS0SJe1i 2_tl8Xi4xizaGMTbVg3w4C6biZ8LrTot8bmqK5TWIKQWqUWloIyQhHJaA MTQaq4SQWNzTeTaoc5MHEkWrWHEY8moxcmLeQkQStoV9lsiM7S6HlKE6n LKfAJK3GVq0WQeK8fmKNcascCXElWJJd9iwvNSi9mNvGsRwsvvxyHsw0O qqptnxsWafZojyKIykTLXobrtrgcAoryw9tNE7TVstKaCBBmEJ2LMUsXJ KCCBk1kWpsul1ZnZRgWoSnleyJ9njK9VrZXCrYFojg6ofqqAam-jOFbEv QIIcLJF9f-quNDsQiS9ac_ljMEE30OjQXKrmVeCxG7iE3UmIcLO4g0zVP FXAN5biakMaMydRuQRlJ2NuaTOEqKabgJg8hc8KNG6PLgDxn1fDGZAzRL OsMhnEGF6--CEZJU6ly4hJmqiXpha4Wumlis26U5hAVtMxgmpVUIzPOoF gpsVVLLOHiSOrKysoBq0Zx4xZZTVFJOwqozvXM7WEQtpmkq7GqF-ZKnqo 2YBGysVvsSJPm0I1kDMHOdHEkN09hm8NtJWnmgA1HDhVoL2ENW6odeXkN 2SjJCmjxotduUws-l3OyDu8KtGUMMc7ICrJu6XpMSsdQkSTuwEC3ddtk1 sBUQyktmMqA8Ti6G-crYSsVVlmFXE5VLeQOtC5kuFCrCEaqTeuJWQu662 W5sr4KQGcrRVjLFlHVdK1AV8Wt23ivgJmLsuU8TcEjG_ZdREvB1iiaHKh cz1xJMxPOah1FhvcK8lOaK1nSFjSPk8iRxghUySuliw230olEzwCfOKfz Wq1gbFMH82iPYAk3rlNhzICdTIYblWwvYSnWDliN3TRvLwcmQhMcPlYJ2 G0NuYpJD0KtVEqpSuaU1fJLgdp0aRyn1kAzM6_jW-6Ab1vxovqtwJTZzm Z3YM0gTVgRVm-zNm61DvaQaqVr1A4IUsQ8LLkMJpXarHRIxlLSNK3Akqh uGv2uQA6pcuSkrmCpllETvY4g4sgt3IZgbhUtSQ3orOouknUJ1taUPXRI Dbq5EVeuvgzEsQQ5jgvmTk10zaCg2G2Tm9ZAzCJO3ZSLwN3M9XWerUD9y motaWDvHEm_DMyQrMou9w7OsB05t1MLNLZrvBlRCyiKjkSNicYUzuazIJ WzclQ3ziAtZVVs5a6Azhg6GYPKYGHFPaTKYO5ULdIIuIVksabFDJrRRdw 9tAxEiUvZpcIOmrAj69TTtpaJsMpgneyUu9ZtweRYk6l2zKDS5JJsq0xh Petrie Expires 4 May 2027 [Page 109] Internet-Draft JSON vCon October 2026 JBfulMtcL5kscBlAcSNHUsIK9qirs87yELpvrLnOzBCklpo5lYvGlJFUj IBTKTkkcU2BGheP1KqrgF1TrSljrYDcpm5KK2RSYU1nAERu3LaNXQDIce RIjmMASHIjSZI0AkiS5EiSgUcX1gQDgCRJkiR5B2Akx5EkqQOAJEmSJJk FgOQ4kiQZcJQhMbwENm7bxnHnBLZx3MaRbwBIkiTJcTcAOHIkSZLBNhvW xiSAJEmS5DgFYBxJkiRpB4AkSZIkeTxg27Zt28ZoLB1FqA84qpop2DMPx B3yyHWxCEq-fmsS1w4YUjo9rZTHlFH0q2AdUZIptdIgy0RuGddqgdyotU Kb6kDbE4ukV4FunQyxDEpOHKgiUSHekezIka8Kys0TR3PlCFqPHrR10te OkYSnQKOlepQdzQALJTqbhIqAomiNxIiNQFTXZWWneXHhSPESVm4lyc1O EahpnMKFsBQojionS9MISIq9u9dX59iNgu2gpbd5mlatoGmpjpyqjmBt5 mp0Za5gpVZzpUR17lgp0gqgLVIIdvMIpMbktErBDJqS65hy7ApUjiOjsZ jXVtnitEDxJq5aG66ApGvxHWmugByp0ds4LmGdNmmEymntVCmzCtSY5M1 qUBO8kizbWc8NqLsw9nW0Gs7tY1vtFaiWTVDsoGVNdfvy7EFD0zJMJMuh I8etAzstQSK9TqvpdEzdBMUeNm5USi3YDuxszZiSWgyyWeoovtoMyHWWq 2ZV91RVoMpgpZpQ1zgMgaS7rZxLzEDtpK2trKygm6OGJjhtTtkkxQyorh vXclcNUm6s1VLtDlhq1joy3Qo2RpWU-ZK3zs1CNSH1RJqjWGsho6Zx2oS sgGJIcZs6ziDMOLLqmo20XU34CDxWFAlOzAwIclQXst8MptWj3tLfCOz1 7dx5VMYMkhLXgCU1Tg1GjMAbNW7bZkNg47Zt2-bugBtDMS63bTCdKbESG k7cNHK5EMBNJbmW4hLKcq0pfkQL4lCtJpZcZ5lRYExhk0XS7spt4ROnLe TaHEJbJykFmkoBhLVwfG1lDRkpRBIW0aM6dXgKONwlc6IpD-5YTcW9ySC 6cTwpkhfWUFbUi2AfdLNotAyhFTuqiuqzQF43RreH1EHc2G2famXv3GQz EbaFWyWKvA54ay1HF-0WaJMjq906C-JtlpSGDtaOkSItYVtKktMmrGCT1 qEbaSxh1DZOJObUoCBLiW2dhTBZSboKOn4bOVnLCsim9Vyu6wioklaqLM wMRpELrXJT15RJUHWB4zRiZbPWgFzGEW1m7GCjCpoi6w7ArGdeWR1xUdV E4AhQkiPNbtYLqG2e6JS1CkRf_tqZwgo4U6xWhpT3lokwzIBRsy3tVIsg WTSNDUusYBTn6eN4rWCcrBCVxGDNVEXBCm6R5sZ2KBO2buNHk98WyK7DX HWwCsQ1pNVVy-YUSnKsYVypCiTXrkDsqC4TR61A2aJ02vjOIJ2ujquiZO -cSL4MSpGOSs3HCiZxVDdx8hbGiZS5qekUStXiHI5P1o5N0sqA6vpMc_u tIDWYcuJI7GB2uf5jpa2A1k7O2hJ1S50MvwjebFu4sckMmFXwNDJdC2gP GbeqYB24bSA5bg7XWI0ky2DTiDPkIu6A4WapZRrtoJu8rhnJy4CktZkdm 2QuWUj0CnjWs1anShG4kiTXnKkQFnggS42-DhS-8spVTOYSjjIvgZtOSi QV7IC9NHYYg8yAy-Sq4mduYeU4rsSaXE-dSdsI1MmiVVS8ErZp3kBO5wj EUZ4litUKhlYLm5QIFtPFgkxBVCWnInXNoIVYldbH66DrRk768I6gWceU HbhsbZ1MuBLKqaPWZtUSumrm0pKsEkSW8bZx9gzKVdvYjBkIn41UzoBFK 3LyJsuA6kZz3MUuQeU0DhvnbYEcW5bdqWANoUQrDbibYg2RxwykcQtFxu oKIuEcw871DDhunD4tzhWRiZKuwORIrt6cHWGatkIUN7RA5GRSnbytgA2 mUh5lce5QSPAOVI1y5IjtErKQGbd1vwxM0p1FrtcMZJIdtTLS1s6NgKxA tkKwi3lMgWQ3umtJ7EAdaSMlRayAXbdarDp5LxEpxAgMd4zJkKwMhp4iu TKzDKaQSkOh3w7Gkde4udP2zowSzGDUzMPuSMvAJUlVLASPgOSocix9s4 DzYFbqOmlN2Si5CDBPTUeN3AyiSASTj_gKQrGctqdxE0QupVatDbeMTdK KQCOVhgu562BiGc8kqZSgbmtJFpWswNs2N6N8cTEdLcAIqLKKN2nHDKay FL-VSAtmrgY5caoKppCbxnRPxkzJ4IxAzLamG0dPweK2jp0WzCAUF4lmu GuB5PqpZGWxi-Tdu83IkRu58bvpIpTjyo49xVau11BOPq_Mb1I30pTKhu LbE-qCppVr1bMoG5MWofRNaO9FTtUULKkcxK1se60u4PnCSpYeriVaxor WtSTbT3ZK-p8kPe3OUiL2Y0mSV6vGnamuo-xkacV8jGIsCdadKA_ipsBK XQamggPJeduCoXCctcQSaILpxDhsIvSya1mXrwzUEtw0g9UKyjCDNMmYF xWa1G6BBUWGlK_WoJooLVmiBGHikq3TOO9AEUt8yriBEt1F5gjCrW17ll gN6E7bRoi2FDau7PaxcRMsVt5Wr9go19VEzaBf2C4UUY5gmjI1SF2MQJU 7ZWVKrUDpFujiln1R4UivHsaQmzSNxgpGtiM9t9kSpn4bzbHvCnaKZmWq Petrie Expires 4 May 2027 [Page 110] Internet-Draft JSON vCon October 2026 2AfTjebrYBCpdao7zaCoRVZr8-pgwzgwjVDtAJ0mjdKkiRBhRbsKSrXlN KtbD-aKFDROcw1Ehiq5jtAIKHooV3bV9lCVdKsge8N14oiuIJm0ccukra AjR32iF89grKzNdamJcSEltQ7aTZpjxc0KIillx5XHCHysPSmv5gx4W2O 7Nxf4EFLybMEchVUcy81g-kryZoEsoRzLTe5Iz2DuuJGTo4TWsS7EEqZq ZPWVzwm8cSfnTlMNZnTdRBWqLFRO0FhyCwrNsgWL4WWmlaQNfAKyp7a_o iJiLDOWg3KsAU5ZdmQWsYhsm3Ua6JUbian3EvyU9yIn9BBIfVv4gU81SF F9pZFK-RRuGcuho3tJyUIEIdS4jUsJZ2ElNbAWKI9ApOJ10yWFL91xwha ia6MmSbQUVIm9V4avEEx1c5up0g7a8M1AJlYnF9pUb4H7NrZay2vBJrc2 k2XXIB0rbxGVbEHSTPLkdHVP3SiyFkrSfMuqxxSoUywTl7IK1nkqWR3qF NigHFmJWfeOTZKu4OsYU5RWNWLaxG3QKsxAH0Xr5MYsgRRlrRxdeTFZKP QOWKXeYsHHFFSVOiuy4xLmktxOiccSTLEdt06UeF2KVM1gajRx2oivgNS oT9Uo1WEamTIm9CohXLeNQMbUdBiaxp2WflvGlTgayFeymZpJEhaXJbvJ bhY-6rEiNo1q35r2NWEeGLEiFZUh7qBmzS6rAtsoEfP2qgIqN07jV62KJ L5mJ8xvQMXyuSqOmKTZmr0gILnRjZnWLNy3E6apVcqEmXur4e1Ezc0Mhk FCmGVjYezBbFiQqsRKoZqj4hX5pCtSP8sQhnUaqW1RJSqSNgF3q6VIkts 6gbI6OvI3h4nQmlz1ozQkau0juIS0Qiw7auE3tEEvYXRsZuaB2jJr6uOY LyWaxR4Y1iR7T2sS6u4Z3ULmGNjN21tO7hS4nJs8rxUoT9HUi6Ds6-5mx y1BJLdNZmZPgc7IbpV61UCqx7FkV4FwUSi1CpI5kpRt8Agwbx1liMIIYg vVuNbBCKTsXsSQmQeVyYQ0IV2XedKKrSAvabkyS-5gMV0WNe3twGuVgdy kiZNZTb8MQkvFX_GvDiqZ7Jqx6Qy4kc0YieoUxlCMptKYB1WRQO_AZunS 7XqsYBZOkdyUruCy6A2gRc6A21apH0mB9Slu2wbkbbohLvQWuEnhBE2qF qZQlXpJsBRaRZ4qzkyZ5SIjVEHMJknKsq1BI7RtG_eKABbHbKrC7kCkWI dGQ4GyoUnzCjItYBipvAq8yFbt7WcMKI5j6s3iDkRSmwxGV-cOlub0oNv Y0poFzYBrV5kx60thYpm17IgtARLGrKsJfdFYkcIUJrr1mHrzCMLzKzV9 xgy6Vh1Hpe0SuDYd125Nm9hzUw-hHjlS3JiNQJ1Ijdu2fWbj2CcZ14pk8 msp48awbTU3Vhr-TrTvKFIcJPojF333KkjyGUaSZTV6aQ3L1U5roOuwHE eaE3BkySIiTaBS7LYsgZnfdoSZBqHdpK1LJ6nQXJpwFchNZ-vv8xp4cqv Lqa0cGpWl9XayEpCRW4nNE_pKXYuXQZRLUfXLKmFox06kAmxhaUUlY2rP QBndZc5KgVBZVccIYtqqta31CDpUHcdw6hTWRcLIlSsKUoKsXoqS1xKRs q3AEDV1YXdNQVsLcavky2BUuV3TLK2A5BI-god9seFE9A6yU9tW2-oKUq Z0RZLgCjw5p0l25BC4kZnYadDW1I1grKALt9LbprSAbMalGvUuQSahbhP JagGlRHEktWixXCXhDOQRDBlSVh0mU7LYCU0RTgM_Q7Y6EtCuUUuyS_aO ldRNYTI30c12jsDe9orzdy2Bs1qyYl1X4TtVsuuqWM4YTasUyMbarHYtE byJ3Bo12BWYivAUrq0sGlIcSajNGBOaV83iXSaO2orMgR1LTvvmbqIkV1 bqhycBO6edpup4cqVNsBKorPfKk-kQVj4uOb2vFDR71CiSzRK2yQu9bRk 2U5GA74Bmmc-a3Duh2wt71OqKId1YaORWTKF70pIrx4lS3SjKDFAtoq5N RBOoUKRmaXYWRJGeyNbGFNphZDhQSOeQyWBtYUOViaKmq4Ds5tTbOi1hV D-ObJWqoF3EMeuQZM0kSbIUxka8to7uDEI22iqLLA1GVqU1kdkKUm7juL HMxtBJwoygoxXHHceqgNI0coPGksAkukX7kCphGrtuXkWBENVIzxI-MSU nUrAIukf69lHJDDYvE0teUQ1Y1V9IUo3mzkVUz6AUtQccy8pgLSQ5BXnL IBYzmirr7WBhyUVr9WjuHE0rCwhyWueNtw5IbfpWqrgUNnoiaXLDCiy50 lvsjtdQkWKLAKNekZZirKCnaDVvVu3gHNlVYX3MQLIoSq6KgTCdRPIO0I 2jusa2CmbG5uautQ5Ipl3WT64IOLVbW9PQKNcZZ8-A7Dp3pswbQdQ6PYG NK6HaxUDiVs2AZRnOzRaRUJ1Z6RRI0iTHyfYKRI4cOjrxEqgqospuKyO4 VZK_1lMokw2JQ2EolrXkqIzAI9wynWjn4FHvUqacrIC0RnZac4WPmUzNE CZOpSgqWw2qbCREedIMNFu0NS7rDCQRm5iOledUzULLgCLLkIOJzyDaI6 6hO--g3DQi01zLYCJHtJ2biVHhKPYMtKkxqW7hDEp1K9Uh1g6aTE04qTY AYJ3fXApcCBWS5MWA3OSpIoePwJXFTVo2rGAVRlHst8tgbmeSpDZxUJUk Petrie Expires 4 May 2027 [Page 111] Internet-Draft JSON vCon October 2026 sA6kcd4lkuUIso2UtZG9ClrW79RZ6QpmbuLiclb31E2k7CAqw45ki60A4 6rW27Yq4D2fkhOizUDkok4SxYkyWSmyCFauWgc2xgT6dKJu7dAIqpENKQ bnCDROpEfX1vfUiXK1YHY3fvRXzGD8yJUhCY0A3TJtU4XvgNpMip1KbQ- VLPQMwoxUJ1rIDDQuKyN5qg5Ek_28smIPSHotx9XY9lJF5MxAqi4uJffq QLS4qSZr12BVG3lb7q1gmRdtnJiNcF0kyAqGNkw5KuoOyG3XXJbpCMxxZ zuZ9A7IjBzXzRQHk4Xi66Ciak0sa9ZAk7uQJJmtIBrDQhIZDCCisukrYW 2QWUj1CrhUGrmp9grYb-oYUuwMOGlkzJLUCMht7lzQHpubADSzYJ1ftv4 KrIGVNW4YtUphGyv65IpeYkaXigzfwRxbJK4eULOsuofVTeKhI0V7rVx6 syVN58RFipMWLcXb7HWa0ool1tVSbRerw1U13_R970Yst2rTUDSHiqJEk dDB3u8tLXXEZRi3iLuKOJJsq89gTZ4TTUs9wXJSZIUvXR-7sZUYe8uDt1 KkJhPJMc6uUfVsadMGMupEzmqFtXHdstEeH4X3qL6u60iO3kZOOfwyo_K eppGj8RXzk2zV00dWW80n0QTMxLbTfSB8jmdFp02aKlNlK1l97XheSYTX kOLGwR4faduDnqHCOE2_ZLbx6rq35oJe0p26lepuXOWTt7Ie_DmLNi4ID SZom4YzSEtD47tmVUra4GERBpUJACE0Uua5njuKvpK2ddy599W22r4k_U 2rbBguUz2dY6tWrvTZuZr9sdZE7-olvZu1lUrIGj9QIfauaCtaeXRZr4k fW5Hlxb0fr3U2lWqt6sOSaYEyZJEIdkWdSu89fZvqdnrVNRmum_xp2jTn h2ISAYJiKwN0oNFtnSyD5Eiyw3dPBAY5diql0b9ecXVDBo2Rs63nWNr6t fuyXTmu8nIabShdNojSNGobq52IxMKBgybmG60GIeX0pUNWh0AA9KxbRY yBJnluZH2Jc4hI2iigbuXGkTgINqqeKLVUDKTR2dQt6gpWMhzXTRd4B2B ULCDiSHXDgy8AnTuMqiROgCsJsYs4tGAjt1WcVdE2SATnCLSKbNhtyAJQ ciPHaL0Eyo0bWcX0DiZu29hwFntXxIIy4KuVckrtDCD4tGYSHctAFDmNz VbPQCvDauJGqTgafrcINDGcNGnZR7Zt3PoALxSCUqY0wbyrSHmTIZc" } ], "analysis": [], "attachments": [], "sessions": [ { "start": "2022-06-21T17:53:26.000+00:00", "duration": 4.72, "parties": [ 0, 1 ], "dialog": [ 0 ] } ], "uuid": "01a16b86-9a63-8346-b9a2-279e0d16bc46", "events": [ { "type": "join", "time": "2022-06-21T17:53:26.000+00:00", "sessions": 0, "party": 0 }, { Petrie Expires 4 May 2027 [Page 112] Internet-Draft JSON vCon October 2026 "type": "join", "time": "2022-06-21T17:53:26.000+00:00", "sessions": 0, "party": 1 }, { "type": "drop", "time": "2022-06-21T17:53:30.720+00:00", "sessions": 0, "party": 0 }, { "type": "drop", "time": "2022-06-21T17:53:30.720+00:00", "sessions": 0, "party": 1 } ] } B.2. Email Thread Multipart vCon The following is an unsigned form of an vCon for a 2 message email thread between 2 parties. The email messages are multipart MIME message bodies. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_email_acct_prob_thread.vcon Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. { "vcon": "0.5.0", "parties": [ { "mailto": "b@example.com", "name": "Bob" }, { "mailto": "a@example.com", "name": "Alice" Petrie Expires 4 May 2027 [Page 113] Internet-Draft JSON vCon October 2026 } ], "dialog": [ { "type": "text", "start": "2022-09-23T21:44:25.000+00:00", "duration": 0, "parties": [ 0 ], "mediatype": "multipart/mixed; boundary=\"----=_Part_388314 _1108189513.1663969465698\"", "encoding": "none", "body": "------=_Part_388314_1108189513.1663969465698\r\nCo ntent-Type: multipart/alternative;\r\n\tboundary=\"----=_ Part_388313_805631480.1663969465697\"\r\n\r\n------=_Part _388313_805631480.1663969465697\r\nContent-Type: text/pla in; charset=UTF-8\r\nContent-Transfer-Encoding: 7bit\r\n\ r\nAlice:Please find the image attached.\r\n\r\nRegards,B ob\r\n\r\n------=_Part_388313_805631480.1663969465697\r\n Content-Type: text/html; charset=UTF-8\r\nContent-Transfe r-Encoding: 7bit\r\n\r\n
Alice:
Please find the image attached.

Regards,
Bob

\r\n--- ---=_Part_388313_805631480.1663969465697--\r\n\r\n------= _Part_388314_1108189513.1663969465698\r\nContent-Type: im age/png\r\nContent-Transfer-Encoding: base64\r\nContent-D isposition: attachment; filename=\"=?UTF-8?b?c2NyZWVuc2hv dC5wbmc=?=\"\r\nContent-ID: \r\n\r\niVBORw0KGgoAAAANSUhEUgAAACYAAA AeCAIAAADPdvs5AAAAA3NCSVQICAjb4U/gAAAAGXRFWHRT\r\nb2Z0d2F yZQBnbm9tZS1zY3JlZW5zaG907wO/PgAAALpJREFUSInl1t0NgzAMBOC7 qPvP1gW6Qjdo\r\nj4f0J4qAJI6NROvniE8+mwCvtzv6imTnyf1K/UclH UFWjIvaIL3CHCABSPKKtJckWfY6zw+sj5dq\r\nISdVIzmj2klzTZG2Rm e7NKgOwY6qPrMcUs+2PqchL14P+oyz+fHx77K5Sv8xyxAyZ0uBaxn/Spc Petrie Expires 4 May 2027 [Page 114] Internet-Draft JSON vCon October 2026 U\r\n8NxcosAut1Y3NtjVX7UjZlmpgWTSFyvVQPKB16tSqW53bFnKtyyZ vYT3rSsAWADWAlOjseYFfwAA\r\nAABJRU5ErkJggg==\r\n\r\n----- -=_Part_388314_1108189513.1663969465698--\r\n", "message_id": "<1126698042.388315.1663969465698@mail.yahoo. com>" }, { "type": "text", "start": "2022-09-23T21:44:59.000+00:00", "duration": 0, "parties": [ 1 ], "mediatype": "multipart/alternative; boundary=\"----=_Part_ 390234_811845464.1663969499935\"", "encoding": "none", "body": "------=_Part_390234_811845464.1663969499935\r\nCon tent-Type: text/plain; charset=UTF-8\r\nContent-Transfer- Encoding: 7bit\r\n\r\n Hi Bob:Got it. Thanks.\r\n\r\n On Friday, September 23, 2022, 9:44:40 PM UTC, Bob wrote: \r\n \r\n Alice:Please find the image a ttached.\r\n\r\nRegards,Bob\r\n \r\n------=_Part_390234_ 811845464.1663969499935\r\nContent-Type: text/html; chars et=UTF-8\r\nContent-Transfer-Encoding: 7bit\r\n\r\n
\r\n
Hi B ob:
Go t it. Thanks.


\r\n \r\n
\r\n
\r\n \r\n
\r\n On Friday, September 23, 2022, 9:44:40 PM UTC, Bo b <b@example.com> wrote:\r\n
\ r\n

\r\n
\r\n
Alice:
Please find the image attached.
< Petrie Expires 4 May 2027 [Page 115] Internet-Draft JSON vCon October 2026 /div>

Regards,
Bob< /div>

\r\n
\r\n
\r\n------=_Par t_390234_811845464.1663969499935--\r\n", "message_id": "<2031327240.390235.1663969499936@mail.yahoo. com>" } ], "analysis": [], "attachments": [], "created_at": "2026-10-24T01:29:10.590+00:00", "subject": "Account problem", "sessions": [ { "start": "2022-09-23T21:44:25.000+00:00", "duration": 34, "parties": [ 0, 1 ], "dialog": [ 0, 1 ] } ], "uuid": "01a16b86-acc8-8c6d-b9a2-279e0d16bc46" } B.3. Email Thread Text vCon The following is an unsigned form of an vCon for a 3 message email thread between 2 parties. The email messages are plain text message bodies. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ ab_email_prob_followup_text_thread.vcon Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. Petrie Expires 4 May 2027 [Page 116] Internet-Draft JSON vCon October 2026 The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. { "vcon": "0.5.0", "parties": [ { "mailto": "a@example.com", "name": "Alice" }, { "mailto": "b@example.com", "name": "Bob" } ], "dialog": [ { "type": "text", "start": "2022-09-23T23:24:59.000+00:00", "duration": 0, "parties": [ 0 ], "mediatype": "text/plain", "encoding": "none", "body": "Hi Bob:\nI just wanted to follow up to see that yo ur account is ok now.\n\nRegards,\nAlice\n\n", "message_id": "<1402576211.401234.1663975499936@mail.yahoo. com>" }, { "type": "text", "start": "2022-09-23T23:34:32.000+00:00", "duration": 0, "parties": [ 1 ], "mediatype": "text/plain; charset=UTF-8", "encoding": "none", "body": "Hi Alice:\nAll is fine. Thanks.\n\n On Friday, September 23, 2022, 23:24:59 PM UTC, Alice wrote: \n \n Hi Bob:\n I just wanted to follow up to see that your account is ok now.\n \n Regards,\n Alic e\n", "message_id": "<1879233410.402112.1663976072118@mail.yahoo. com>" }, Petrie Expires 4 May 2027 [Page 117] Internet-Draft JSON vCon October 2026 { "type": "text", "start": "2022-09-23T23:38:12.000+00:00", "duration": 0, "parties": [ 0 ], "mediatype": "text/plain", "encoding": "none", "body": "Awesome!\n\n On Friday, September 23, 2022, 23: 34: PM UTC, Bob wrote: \n\n Hi Alice:\n All is fine. Thanks.\n \n On Friday, September 23 , 2022, 23:24:59 PM UTC, Alice wrote: \n \n Hi Bob:\n I just wanted to follow up to see t hat your account is ok now.\n \n Regards,\n Alic e\n", "message_id": "<1535873320.402417.1663976292034@mail.yahoo. com>" } ], "analysis": [], "attachments": [], "created_at": "2026-10-24T01:29:12.007+00:00", "subject": "Account issue followup", "sessions": [ { "start": "2022-09-23T23:24:59.000+00:00", "duration": 793, "parties": [ 0, 1 ], "dialog": [ 0, 1, 2 ] } ], "uuid": "01a16b86-b24d-8057-b9a2-279e0d16bc46" } B.4. Two Party Call vCon With Externally Referenced Recording This example vCon is for a simple 2 party PSTN call. It has a single Dialog Object which reference a single channel wav format recording with the two parties audio mixed into the single channel. Petrie Expires 4 May 2027 [Page 118] Internet-Draft JSON vCon October 2026 The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_call_ext_rec.vcon Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. Petrie Expires 4 May 2027 [Page 119] Internet-Draft JSON vCon October 2026 { "vcon": "0.5.0", "created_at": "2022-06-21T13:53:00-04:00", "parties": [ { "tel": "+12345678901", "name": "Alice" }, { "tel": "+19876543210", "name": "Bob" } ], "dialog": [ { "type": "recording", "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, 1 ], "url": "https://github.com/ietf-wg-vcon/draft-ietf-vcon-vco n-core/raw/refs/heads/main/examples/ab_call_2ch.ogg", "mediatype": "audio/ogg", "filename": "ab_call_2ch.ogg", "content_hash": "sha512-Y-Q9eclT6b5hFyIfLtnFAAXgqFzN5_Cjr3J Q3DMmcnpXHkGMgtvaxrLW2R2OhFTzR-DinyrngBG2w9lTZXr1EQ" } ], "analysis": [], "attachments": [], "sessions": [ { "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, 1 ], "dialog": [ 0 ] } ], "uuid": "01a16b86-96e7-80a8-b9a2-279e0d16bc46" } Petrie Expires 4 May 2027 [Page 120] Internet-Draft JSON vCon October 2026 B.5. Two Party Call vCon with Analysis The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_call_ext_rec_analysis.vcon Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. { "vcon": "0.5.0", "created_at": "2022-06-21T13:53:00-04:00", "parties": [ { "tel": "+12345678901", "name": "Alice" }, { "tel": "+19876543210", "name": "Bob" } ], "dialog": [ { "type": "recording", "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, 1 ], "url": "https://github.com/ietf-wg-vcon/draft-ietf-vcon-vco n-core/raw/refs/heads/main/examples/ab_call_2ch.ogg", "mediatype": "audio/ogg", "filename": "ab_call_2ch.ogg", "content_hash": "sha512-Y-Q9eclT6b5hFyIfLtnFAAXgqFzN5_Cjr3J Q3DMmcnpXHkGMgtvaxrLW2R2OhFTzR-DinyrngBG2w9lTZXr1EQ" } ], "analysis": [ { "type": "transcript", "dialog": 0, Petrie Expires 4 May 2027 [Page 121] Internet-Draft JSON vCon October 2026 "body": { "metadata": { "transaction_key": "deprecated", "request_id": "01a16b9c-30a8-7941-9b74-a9c73124938a", "sha256": "460145629244a6c72d4f0b94707ec3ca4e92da1ae11f e1d04a3fc88143795c63", "created": "2026-10-24T01:52:40.996Z", "duration": 32.925938, "channels": 2, "models": [ "2187e11a-3532-4498-b076-81fa530bdd49" ], "model_info": { "2187e11a-3532-4498-b076-81fa530bdd49": { "name": "general-nova-3", "version": "2025-07-31.0", "arch": "nova-3" } }, "diarize_info": { "model_uuid": "a9f85c2b-5afb-4b9d-b49b-492c43a01cfb", "arch": "v1" } }, "results": { "channels": [ { "alternatives": [ { "transcript": "Hi. I'd like to add Foo to my se rvice. My name is Alice and my number is 1234 567890. No. Thank you. Goodbye.", "confidence": 0.99609375, "words": [ { "word": "hi", "start": 5.52, "end": 6.16, "confidence": 0.8781738, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "Hi." }, { "word": "i'd", "start": 6.24, "end": 6.56, "confidence": 0.9951172, Petrie Expires 4 May 2027 [Page 122] Internet-Draft JSON vCon October 2026 "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "I'd" }, { "word": "like", "start": 6.56, "end": 6.72, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "like" }, { "word": "to", "start": 6.72, "end": 6.7999997, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "to" }, { "word": "add", "start": 6.7999997, "end": 7.12, "confidence": 1, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "add" }, { "word": "foo", "start": 7.12, "end": 7.52, "confidence": 0.6496582, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "Foo" }, { "word": "to", "start": 7.52, "end": 7.8399997, "confidence": 0.9902344, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "to" Petrie Expires 4 May 2027 [Page 123] Internet-Draft JSON vCon October 2026 }, { "word": "my", "start": 7.8399997, "end": 8, "confidence": 1, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "my" }, { "word": "service", "start": 8, "end": 8.4, "confidence": 0.99560547, "speaker": 0, "speaker_confidence": 0.93691725, "punctuated_word": "service." }, { "word": "my", "start": 13.695001, "end": 13.935, "confidence": 0.99609375, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "My" }, { "word": "name", "start": 13.935, "end": 14.175, "confidence": 0.9980469, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "name" }, { "word": "is", "start": 14.175, "end": 14.255, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "is" }, { "word": "alice", Petrie Expires 4 May 2027 [Page 124] Internet-Draft JSON vCon October 2026 "start": 14.255, "end": 14.815001, "confidence": 0.9902344, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "Alice" }, { "word": "and", "start": 14.815001, "end": 15.215, "confidence": 0.7080078, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "and" }, { "word": "my", "start": 15.215, "end": 15.455, "confidence": 0.99609375, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "my" }, { "word": "number", "start": 15.455, "end": 15.695, "confidence": 0.9970703, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "number" }, { "word": "is", "start": 15.695, "end": 16.335, "confidence": 0.9970703, "speaker": 0, "speaker_confidence": 0.9877569, "punctuated_word": "is" }, { "word": "1234567890", "start": 16.335, "end": 20.255001, "confidence": 0.9845703, Petrie Expires 4 May 2027 [Page 125] Internet-Draft JSON vCon October 2026 "speaker": 0, "speaker_confidence": 0.98775685, "punctuated_word": "1234567890." }, { "word": "no", "start": 27.820936, "end": 28.380938, "confidence": 0.8015137, "speaker": 0, "speaker_confidence": 0.89424765, "punctuated_word": "No." }, { "word": "thank", "start": 28.380938, "end": 28.700937, "confidence": 0.9941406, "speaker": 0, "speaker_confidence": 0.89424765, "punctuated_word": "Thank" }, { "word": "you", "start": 28.700937, "end": 29.180937, "confidence": 0.98657227, "speaker": 0, "speaker_confidence": 0.89424765, "punctuated_word": "you." }, { "word": "goodbye", "start": 29.180937, "end": 29.500937, "confidence": 0.85009766, "speaker": 0, "speaker_confidence": 0.89424765, "punctuated_word": "Goodbye." } ], "paragraphs": { "transcript": "\nSpeaker 0: Hi. I'd like to a dd Foo to my service. My name is Alice and my number is 1234567890. No. Thank you.\n\n Goodbye.", "paragraphs": [ { Petrie Expires 4 May 2027 [Page 126] Internet-Draft JSON vCon October 2026 "sentences": [ { "text": "Hi.", "start": 5.52, "end": 6.16 }, { "text": "I'd like to add Foo to my se rvice.", "start": 6.24, "end": 8.4 }, { "text": "My name is Alice and my numb er is 1234567890.", "start": 13.695001, "end": 20.255001 }, { "text": "No.", "start": 27.820936, "end": 28.380938 }, { "text": "Thank you.", "start": 28.380938, "end": 29.180937 } ], "speaker": 0, "num_words": 21, "start": 5.52, "end": 29.180937 }, { "sentences": [ { "text": "Goodbye.", "start": 29.180937, "end": 29.500937 } ], "speaker": 0, "num_words": 1, "start": 29.180937, "end": 29.500937 } ] Petrie Expires 4 May 2027 [Page 127] Internet-Draft JSON vCon October 2026 } } ] }, { "alternatives": [ { "transcript": "Hello. This is example.com. My n ame is Bob. How can I help you? Okay. Can you give me your name and phone number so I can look up your account? Thank you. Okay. I've a dded food to your service. Is there anything else I can help you with? Goodbye. Have a nic e day.", "confidence": 1, "words": [ { "word": "hello", "start": 1.12, "end": 1.68, "confidence": 0.9790039, "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "Hello." }, { "word": "this", "start": 1.68, "end": 2.08, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "This" }, { "word": "is", "start": 2.08, "end": 2.24, "confidence": 0.9951172, "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "is" }, { "word": "example.com", "start": 2.24, "end": 3.28, "confidence": 0.939209, Petrie Expires 4 May 2027 [Page 128] Internet-Draft JSON vCon October 2026 "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "example.com." }, { "word": "my", "start": 3.28, "end": 3.4399998, "confidence": 1, "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "My" }, { "word": "name", "start": 3.4399998, "end": 3.6, "confidence": 1, "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "name" }, { "word": "is", "start": 3.6, "end": 3.6799998, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "is" }, { "word": "bob", "start": 3.6799998, "end": 4.16, "confidence": 0.99853516, "speaker": 0, "speaker_confidence": 0.5035404, "punctuated_word": "Bob." }, { "word": "how", "start": 4.16, "end": 4.4, "confidence": 1, "speaker": 0, "speaker_confidence": 0.24978054, "punctuated_word": "How" Petrie Expires 4 May 2027 [Page 129] Internet-Draft JSON vCon October 2026 }, { "word": "can", "start": 4.4, "end": 4.56, "confidence": 1, "speaker": 0, "speaker_confidence": 0.24978054, "punctuated_word": "can" }, { "word": "i", "start": 4.56, "end": 4.64, "confidence": 1, "speaker": 0, "speaker_confidence": 0.24978054, "punctuated_word": "I" }, { "word": "help", "start": 4.64, "end": 4.88, "confidence": 1, "speaker": 0, "speaker_confidence": 0.24978054, "punctuated_word": "help" }, { "word": "you", "start": 4.88, "end": 5.36, "confidence": 1, "speaker": 0, "speaker_confidence": 0.24978054, "punctuated_word": "you?" }, { "word": "okay", "start": 9.04, "end": 9.759999, "confidence": 0.99853516, "speaker": 0, "speaker_confidence": 0.42573488, "punctuated_word": "Okay." }, { "word": "can", Petrie Expires 4 May 2027 [Page 130] Internet-Draft JSON vCon October 2026 "start": 10.08, "end": 10.32, "confidence": 1, "speaker": 0, "speaker_confidence": 0.42573488, "punctuated_word": "Can" }, { "word": "you", "start": 10.32, "end": 10.4, "confidence": 1, "speaker": 0, "speaker_confidence": 0.42573488, "punctuated_word": "you" }, { "word": "give", "start": 10.4, "end": 10.559999, "confidence": 1, "speaker": 0, "speaker_confidence": 0.42573488, "punctuated_word": "give" }, { "word": "me", "start": 10.559999, "end": 10.719999, "confidence": 1, "speaker": 0, "speaker_confidence": 0.42573488, "punctuated_word": "me" }, { "word": "your", "start": 10.719999, "end": 10.88, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49732846, "punctuated_word": "your" }, { "word": "name", "start": 10.88, "end": 11.12, "confidence": 1, Petrie Expires 4 May 2027 [Page 131] Internet-Draft JSON vCon October 2026 "speaker": 0, "speaker_confidence": 0.49732846, "punctuated_word": "name" }, { "word": "and", "start": 11.12, "end": 11.28, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49732846, "punctuated_word": "and" }, { "word": "phone", "start": 11.28, "end": 11.5199995, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.49732846, "punctuated_word": "phone" }, { "word": "number", "start": 11.5199995, "end": 11.679999, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.49732846, "punctuated_word": "number" }, { "word": "so", "start": 11.679999, "end": 11.92, "confidence": 0.9350586, "speaker": 0, "speaker_confidence": 0.49732846, "punctuated_word": "so" }, { "word": "i", "start": 11.92, "end": 12.08, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.49732846, "punctuated_word": "I" Petrie Expires 4 May 2027 [Page 132] Internet-Draft JSON vCon October 2026 }, { "word": "can", "start": 12.08, "end": 12.16, "confidence": 1, "speaker": 0, "speaker_confidence": 0.2417295, "punctuated_word": "can" }, { "word": "look", "start": 12.16, "end": 12.32, "confidence": 1, "speaker": 0, "speaker_confidence": 0.2417295, "punctuated_word": "look" }, { "word": "up", "start": 12.32, "end": 12.48, "confidence": 0.9921875, "speaker": 0, "speaker_confidence": 0.2417295, "punctuated_word": "up" }, { "word": "your", "start": 12.48, "end": 12.639999, "confidence": 1, "speaker": 0, "speaker_confidence": 0.2417295, "punctuated_word": "your" }, { "word": "account", "start": 12.639999, "end": 13.04, "confidence": 0.9980469, "speaker": 0, "speaker_confidence": 0.2417295, "punctuated_word": "account?" }, { "word": "thank", Petrie Expires 4 May 2027 [Page 133] Internet-Draft JSON vCon October 2026 "start": 20.635, "end": 20.955, "confidence": 1, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "Thank" }, { "word": "you", "start": 20.955, "end": 21.435, "confidence": 1, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "you." }, { "word": "okay", "start": 22.795, "end": 23.515, "confidence": 0.9995117, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "Okay." }, { "word": "i've", "start": 23.994999, "end": 24.395, "confidence": 0.99853516, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "I've" }, { "word": "added", "start": 24.395, "end": 24.715, "confidence": 0.99902344, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "added" }, { "word": "food", "start": 24.715, "end": 24.955, "confidence": 0.9580078, Petrie Expires 4 May 2027 [Page 134] Internet-Draft JSON vCon October 2026 "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "food" }, { "word": "to", "start": 24.955, "end": 25.115, "confidence": 0.96435547, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "to" }, { "word": "your", "start": 25.115, "end": 25.275, "confidence": 1, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "your" }, { "word": "service", "start": 25.275, "end": 25.595001, "confidence": 0.99560547, "speaker": 0, "speaker_confidence": 0.492307, "punctuated_word": "service." }, { "word": "is", "start": 25.595001, "end": 25.755001, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "Is" }, { "word": "there", "start": 25.755001, "end": 25.915, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "there" Petrie Expires 4 May 2027 [Page 135] Internet-Draft JSON vCon October 2026 }, { "word": "anything", "start": 25.915, "end": 26.154999, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "anything" }, { "word": "else", "start": 26.154999, "end": 26.395, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "else" }, { "word": "i", "start": 26.395, "end": 26.635, "confidence": 0.97314453, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "I" }, { "word": "can", "start": 26.635, "end": 26.795, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "can" }, { "word": "help", "start": 26.795, "end": 26.955, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "help" }, { "word": "you", Petrie Expires 4 May 2027 [Page 136] Internet-Draft JSON vCon October 2026 "start": 26.955, "end": 27.035, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "you" }, { "word": "with", "start": 27.035, "end": 27.275, "confidence": 1, "speaker": 0, "speaker_confidence": 0.49394125, "punctuated_word": "with?" }, { "word": "goodbye", "start": 30.320875, "end": 30.960875, "confidence": 0.99121094, "speaker": 0, "speaker_confidence": 0.21964735, "punctuated_word": "Goodbye." }, { "word": "have", "start": 30.960875, "end": 31.200874, "confidence": 1, "speaker": 0, "speaker_confidence": 0.21964735, "punctuated_word": "Have" }, { "word": "a", "start": 31.200874, "end": 31.360876, "confidence": 1, "speaker": 0, "speaker_confidence": 0.21964735, "punctuated_word": "a" }, { "word": "nice", "start": 31.360876, "end": 31.520876, "confidence": 1, Petrie Expires 4 May 2027 [Page 137] Internet-Draft JSON vCon October 2026 "speaker": 0, "speaker_confidence": 0.21964735, "punctuated_word": "nice" }, { "word": "day", "start": 31.520876, "end": 31.760876, "confidence": 1, "speaker": 0, "speaker_confidence": 0, "punctuated_word": "day." } ], "paragraphs": { "transcript": "\nSpeaker 0: Hello. This is ex ample.com. My name is Bob. How can I help y ou? Okay.\n\nCan you give me your name and phone number so I can look up your account? Thank you. Okay. I've added food to your s ervice. Is there anything else I can help y ou with?\n\nGoodbye. Have a nice day.", "paragraphs": [ { "sentences": [ { "text": "Hello.", "start": 1.12, "end": 1.68 }, { "text": "This is example.com.", "start": 1.68, "end": 3.28 }, { "text": "My name is Bob.", "start": 3.28, "end": 4.16 }, { "text": "How can I help you?", "start": 4.16, "end": 5.36 }, { "text": "Okay.", "start": 9.04, Petrie Expires 4 May 2027 [Page 138] Internet-Draft JSON vCon October 2026 "end": 9.759999 } ], "speaker": 0, "num_words": 14, "start": 1.12, "end": 9.759999 }, { "sentences": [ { "text": "Can you give me your name an d phone number so I can look up you r account?", "start": 10.08, "end": 13.04 }, { "text": "Thank you.", "start": 20.635, "end": 21.435 }, { "text": "Okay.", "start": 22.795, "end": 23.515 }, { "text": "I've added food to your serv ice.", "start": 23.994999, "end": 25.595001 }, { "text": "Is there anything else I can help you with?", "start": 25.595001, "end": 27.275 } ], "speaker": 0, "num_words": 34, "start": 10.08, "end": 27.275 }, { "sentences": [ { Petrie Expires 4 May 2027 [Page 139] Internet-Draft JSON vCon October 2026 "text": "Goodbye.", "start": 30.320875, "end": 30.960875 }, { "text": "Have a nice day.", "start": 30.960875, "end": 31.760876 } ], "speaker": 0, "num_words": 5, "start": 30.320875, "end": 31.760876 } ] } } ] } ], "paragraphs": { "transcript": "\nChannel 1: Speaker 0: Hello. This is example.com. My name is Bob. How can I help you?\n \nChannel 0: Hi. I'd like to add Foo to my service. \n\nChannel 1: Okay. Can you give me your name and phone number so I can look up your account?\n\nChan nel 0: My name is Alice and my number is 1234567890 .\n\nChannel 1: Thank you. Okay. I've added food to your service. Is there anything else I can help yo u with?\n\nChannel 0: No. Thank you. Goodbye.\n\nCh annel 1: Goodbye. Have a nice day.", "paragraphs": [ { "sentences": [ { "text": "Hello.", "start": 1.12, "end": 1.68 }, { "text": "This is example.com.", "start": 1.68, "end": 3.28 }, { "text": "My name is Bob.", "start": 3.28, Petrie Expires 4 May 2027 [Page 140] Internet-Draft JSON vCon October 2026 "end": 4.16 }, { "text": "How can I help you?", "start": 4.16, "end": 5.36 } ], "speaker": 0, "channel": 1, "num_words": 13, "start": 1.12, "end": 5.36 }, { "sentences": [ { "text": "Hi.", "start": 5.52, "end": 6.16 }, { "text": "I'd like to add Foo to my service.", "start": 6.24, "end": 8.4 } ], "speaker": 0, "channel": 0, "num_words": 9, "start": 5.52, "end": 8.4 }, { "sentences": [ { "text": "Okay.", "start": 9.04, "end": 9.759999 }, { "text": "Can you give me your name and phone number so I can look up your account?", "start": 10.08, "end": 13.04 } ], "speaker": 0, Petrie Expires 4 May 2027 [Page 141] Internet-Draft JSON vCon October 2026 "channel": 1, "num_words": 17, "start": 9.04, "end": 13.04 }, { "sentences": [ { "text": "My name is Alice and my number is 12 34567890.", "start": 13.695001, "end": 20.255001 } ], "speaker": 0, "channel": 0, "num_words": 9, "start": 13.695001, "end": 20.255001 }, { "sentences": [ { "text": "Thank you.", "start": 20.635, "end": 21.435 }, { "text": "Okay.", "start": 22.795, "end": 23.515 }, { "text": "I've added food to your service.", "start": 23.994999, "end": 25.595001 }, { "text": "Is there anything else I can help yo u with?", "start": 25.595001, "end": 27.275 } ], "speaker": 0, "channel": 1, "num_words": 18, "start": 20.635, Petrie Expires 4 May 2027 [Page 142] Internet-Draft JSON vCon October 2026 "end": 27.275 }, { "sentences": [ { "text": "No.", "start": 27.820936, "end": 28.380938 }, { "text": "Thank you.", "start": 28.380938, "end": 29.180937 }, { "text": "Goodbye.", "start": 29.180937, "end": 29.500937 } ], "speaker": 0, "channel": 0, "num_words": 4, "start": 27.820936, "end": 29.500937 }, { "sentences": [ { "text": "Goodbye.", "start": 30.320875, "end": 30.960875 }, { "text": "Have a nice day.", "start": 30.960875, "end": 31.760876 } ], "speaker": 0, "channel": 1, "num_words": 5, "start": 30.320875, "end": 31.760876 } ] } } Petrie Expires 4 May 2027 [Page 143] Internet-Draft JSON vCon October 2026 }, "encoding": "json", "vendor": "deepgram", "schema": "deepgram_prerecorded", "product": "transcription" } ], "attachments": [], "sessions": [ { "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, 1 ], "dialog": [ 0 ] } ], "uuid": "01a16b86-96e7-80a8-b9a2-279e0d16bc46" } B.6. Signed vCon This example vCon is the signed form of the Two Party Call vCon With Externally Referenced Recording (Appendix B.4) example. The private key used to sign this can be found at: https://raw.githubusercontent.com/vcon-dev/vcon/main/certs/fake_grp.key The certificate chain is included in the x5c parameter of the header Object. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_call_ext_rec_signed.vcon Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. Petrie Expires 4 May 2027 [Page 144] Internet-Draft JSON vCon October 2026 { "payload": "eyJ2Y29uIjoiMC41LjAiLCJjcmVhdGVkX2F0IjoiMjAyMi0wNi0 yMVQxMzo1MzowMC0wNDowMCIsInBhcnRpZXMiOlt7InRlbCI6IisxMjM0NTY3 ODkwMSIsIm5hbWUiOiJBbGljZSJ9LHsidGVsIjoiKzE5ODc2NTQzMjEwIiwib mFtZSI6IkJvYiJ9XSwiZGlhbG9nIjpbeyJ0eXBlIjoicmVjb3JkaW5nIiwic3 RhcnQiOiIyMDIyLTA2LTIxVDE3OjUzOjI2LjAwMCswMDowMCIsImR1cmF0aW9 uIjozMi45MzIzOTYsInBhcnRpZXMiOlswLDFdLCJ1cmwiOiJodHRwczovL2dp dGh1Yi5jb20vaWV0Zi13Zy12Y29uL2RyYWZ0LWlldGYtdmNvbi12Y29uLWNvc mUvcmF3L3JlZnMvaGVhZHMvbWFpbi9leGFtcGxlcy9hYl9jYWxsXzJjaC5vZ2 ciLCJtZWRpYXR5cGUiOiJhdWRpby9vZ2ciLCJmaWxlbmFtZSI6ImFiX2NhbGx fMmNoLm9nZyIsImNvbnRlbnRfaGFzaCI6InNoYTUxMi1ZLVE5ZWNsVDZiNWhG eUlmTHRuRkFBWGdxRnpONV9DanIzSlEzRE1tY25wWEhrR01ndHZheHJMVzJSM k9oRlR6Ui1EaW55cm5nQkcydzlsVFpYcjFFUSJ9XSwiYW5hbHlzaXMiOltdLC JhdHRhY2htZW50cyI6W10sInNlc3Npb25zIjpbeyJzdGFydCI6IjIwMjItMDY tMjFUMTc6NTM6MjYuMDAwKzAwOjAwIiwiZHVyYXRpb24iOjMyLjkzMjM5Niwi cGFydGllcyI6WzAsMV0sImRpYWxvZyI6WzBdfV0sInV1aWQiOiIwMWExNmI4N i05NmU3LTgwYTgtYjlhMi0yNzllMGQxNmJjNDYifQ", "signatures": [ { "header": { "x5c": [ "MIID0TCCArkCAQEwDQYJKoZIhvcNAQELBQAwgasxCzAJBgNVBAYTAl VTMQswCQYDVQQIDAJNQTERMA8GA1UEBwwIRmFrZXRvd24xETAPBgN VBAoMCEZha2VWY29uMREwDwYDVQQLDAhEaXZpc2lvbjEYMBYGA1UE AwwPZGl2LmZha2V2Y29uLmlvMSEwHwYJKoZIhvcNAQkBFhJhZG1pb kBmYWtldmNvbi5vcmcxGTAXBgNVHREMEGRpdi5mYWtldmNvbi5vcm cwHhcNMjIwNjA0MDE0MzI1WhcNMzIwNjAxMDE0MzI1WjCBsDELMAk GA1UEBhMCVVMxCzAJBgNVBAgMAk1BMREwDwYDVQQHDAhGYWtldG93 bjERMA8GA1UECgwIRmFrZVZjb24xDjAMBgNVBAsMBUdyb3VwMRwwG gYDVQQDDBNncnAuZGl2LmZha2V2Y29uLmlvMSEwHwYJKoZIhvcNAQ kBFhJhZG1pbkBmYWtldmNvbi5vcmcxHTAbBgNVHREMFGdycC5kaXY uZmFrZXZjb24ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAtMtTCxeIROb1FmWIexe7Op95qYIVNEqn+fDghxWqoYm6T 75BGsl4rB9txFQeef3Q5SJIzeqffJDssXDsyREuwQ2iTcOrZaZxs8 h1NX9NjVD6MMAwx7tw0Cgmu8rj6+/Kjs0KI8OzCuDXZGTGf/bH6EQ W85qYh9IF0Pvijf3uq+HCke6WApusx76LpUp36IzvYEuTbWBFeoLo +dyUdWmXpj0ghHiWZtT5zxJn9VrUhJX5KlaI0palWd0fOnr7mkdq7 9sFsKjEOcr1lanceAicCpD3/zRW+7AS8atGKAMfe2CcXEABucI7Dt tLMXcDIJM6EOkyW7n4due1RXGuNgnjeQIDAQABMA0GCSqGSIb3DQE BCwUAA4IBAQAQLjhKomSx1OqThhcO+aK0rzX6RjKh0eM0X7O7pPC8 1HxZKCDLhDvnUO9++17U6ba0bTnznKYKKG7HnDcB4dKBbH8XP2u3E nDskyoMrKpYRsRKwwJa8+RwOS7JEg+OtXYCRbWZvPjAC/z6o6OZK+ QPTyK5Grw2Px2mTr6BAdBQv7XsYWBRwOZyvSGnKyK60jcPlYUnu6Q t0fYXiYp6qF5l956fuT0d2UyDkM7S/Z7K+OC9+aIBNKH32B3nfXqZ PuP8WuiTOxcMwnefPwjxaqndFUkyk2Y+i6nXU8oN/DGUOTfY4xbm3 s3q7Dq5QPtq5kljB9yYkvcOULCSAmWBZl+G", "MIIEyTCCArECAQEwDQYJKoZIhvcNAQELBQAwgagxCzAJBgNVBAYTAl VTMQswCQYDVQQIDAJNQTERMA8GA1UEBwwIRmFrZXRvd24xFTATBgN Petrie Expires 4 May 2027 [Page 145] Internet-Draft JSON vCon October 2026 VBAoMDEZha2VWY29uIEluYzESMBAGA1UECwwJQ29ycG9yYXRlMRQw EgYDVQQDDAtmYWtldmNvbi5pbzEhMB8GCSqGSIb3DQEJARYSYWRta W5AZmFrZXZjb24ub3JnMRUwEwYDVR0RDAxmYWtldmNvbi5vcmcwHh cNMjIwNTI5MjEzOTMxWhcNMzIwNTI2MjEzOTMxWjCBqzELMAkGA1U EBhMCVVMxCzAJBgNVBAgMAk1BMREwDwYDVQQHDAhGYWtldG93bjER MA8GA1UECgwIRmFrZVZjb24xETAPBgNVBAsMCERpdmlzaW9uMRgwF gYDVQQDDA9kaXYuZmFrZXZjb24uaW8xITAfBgkqhkiG9w0BCQEWEm FkbWluQGZha2V2Y29uLm9yZzEZMBcGA1UdEQwQZGl2LmZha2V2Y29 uLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM81 SKie1S78VAOBDc3LflYNSL9phecmjQs/9P+iqDXSVm3xpoqszGoLn 7w21aUAxl++F9Z80Tc70URn2qqUcVTYcx3SmgHuYgspEmJsMRor/m n3HpHr2ajh+26RKgDGPBrtebeH1si8mX15a/ICzHxrUaE2Y/6DZ/2 wGTXrAE4bYAOUaYft5GGSZl6yP6dXg3EJy2bK2cUTdMIZG/Y7Ny1D 3N4V7MBirDd5FU7k6pMbyr3d/xoi8VL8F1mRCf6zxfFOjaMFT0atE iTp3M0rw6iS08hy0cDFsPJzIcPgXEitUgGPo/NLgeb8ZmL1kg9B2v MgaanbuZB6il79A4GgDIUCAwEAATANBgkqhkiG9w0BAQsFAAOCAgE AWOJJlvSQDsDROQZNdX3kMkAH3HYyAlE7LHNtIYHVhyt7I7WuqS6Z GvSoxSfkT0GdAN7cV+jchdZpAnpCXGX+yHuSvrw4oSqigdSLeSUMx 2zaSv4wLAvydC/zDkHIRObyuDEKyy/pa4Na0aunPU3E1Bg0V+JqQ3 RUJIy1v6AGLrliwaEIgP3Clzi/u640dWBHabOEjxFj9bX73+FRWhi t4EzOJYKvti1EXlmRjMbj3SmsrcbGMrpu4WipEG5S05VlMhXXSyQq 9IScFho5CFtamDgI3jL49lyrx0+CcjDkw0nW9fXdAtB3BhSYEXdLu JAvLRQixUQFwH23doumPi1uW8euEhHTRo1pEFWQ5U59NOTUA5Ghuu po0aM2CnDD5Re8uO3ChilCUb0FlwgMD/7ABSd1LChU8iluhKy9CEB R2zc8uTqW43Gcv/psBaejgOKJlxZuusGVvuV1nTHRa4hmFYxxPel7 ogeZzGQqFjBlb35CE+BcGYY0ViaHefy+fmi/fN6NrrN6pBOPjVZbp CFn+wFTUyrMU5Vq/FaPe0us7i3paQcwIz9wyide5OztpxebY8UnXm y22X+6PkHB0jnL35Qe8xl7Z0nMZNdy4xkzGgaa6talRDPhKkY1lId w+KdCXJuUc7rkLKa5po9SPdvVLhEPu26SHkI0I+d5hz+gMp8=", "MIIGMzCCBBugAwIBAgIUHk/6QbzjDZ9AONAFvwYJqB/jbvowDQYJKo ZIhvcNAQELBQAwgagxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJNQTE RMA8GA1UEBwwIRmFrZXRvd24xFTATBgNVBAoMDEZha2VWY29uIElu YzESMBAGA1UECwwJQ29ycG9yYXRlMRQwEgYDVQQDDAtmYWtldmNvb i5pbzEhMB8GCSqGSIb3DQEJARYSYWRtaW5AZmFrZXZjb24ub3JnMR UwEwYDVR0RDAxmYWtldmNvbi5vcmcwHhcNMjIwNTI5MjEzOTMxWhc NMzIwNTI2MjEzOTMxWjCBqDELMAkGA1UEBhMCVVMxCzAJBgNVBAgM Ak1BMREwDwYDVQQHDAhGYWtldG93bjEVMBMGA1UECgwMRmFrZVZjb 24gSW5jMRIwEAYDVQQLDAlDb3Jwb3JhdGUxFDASBgNVBAMMC2Zha2 V2Y29uLmlvMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBmYWtldmNvbi5 vcmcxFTATBgNVHREMDGZha2V2Y29uLm9yZzCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBAMIeaqkm8pn6mwUzWBgnQiY9Jr3Vy VamxBc9/duT8eCN9mmANGzX5zGj86KtGjlDcoAzANrtsr2Dpz4zra 29HWbwbOa1ZTOOaR93QgifkS802zp+zHGGRaKlq3euDqDVzyXinhs vXOVlEwkOrAvV6kUcTIzcxVibrFfHttzv/hXUNxjCouAE7MIG6wO8 y+E2bBkg7R5ydfeU4Q9npBefwtiQ8oWf0C46mDYFQ8l31goae17Vp iyS3t4h5HL+1yqdYJSWms5Qh0vp9req5AjwuHIDBxNLpO2gY1SQmS dO03oLcZwBglGKlpQSwYgr9J5uo2B+NV9aYKEO51bySinSF8T4D/o 4cq6oyJLXBwmSsLbjjVIQBoSdRBmWh8zE2ZzFNaaBlYO9ikIaWXwb Petrie Expires 4 May 2027 [Page 146] Internet-Draft JSON vCon October 2026 tkbsE+4QpOaOj/kUIHLFI9iOhOidsInaOfgYzw12FtGE1Wq5x5Xsz wWpPWU8NQw8gzTzFzVObxrfcsXrs0s6feuTCDMt5Zht2HCWFr9TmY DFAfOB05kFWTi5sE5KYaP54iJvjAFmuTDjlif7Z8ZWVal9XB+g3sM yQ8DVEj/0dXS+nRVuJQlUH4ql9SUIwK63RKdedALYC6X1j2lgK9aT uL+cyNJ5SbuNA95CxNgvWtBrcO6HxlbmIDxKrAAo5aj4hnlQcY4RR bNwppCAjK+zcASlpyvRAgMBAAGjUzBRMB0GA1UdDgQWBBSSDtfqU6 +DEyYPCar08yVnnZSFzTAfBgNVHSMEGDAWgBSSDtfqU6+DEyYPCar 08yVnnZSFzTAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUA A4ICAQC8JDxTdmc86YFdKElWQnWxoPMsPeRyDYQoVTC2wydZsdJ5d GbkAhYlPPxK+zypP18fGry5PHAHl9mZYz+FdGjNTwllcfN9/G0Sdo y4kU9eN9KfC9OUIkBIq8D0r7ANT3l3XmGbnIxWJEtb0SyTcqk3dwW cNTqGguhQ03jUKW5yUpVoQjN4TtmHyweoYTNi+HKsCUvEXGdA9wdh 4jVOqYeepmsax5eTUJsKuCKqQ3+xB7JONw85imfVotySCXsoMe7lu SRYuldn8SBIpKYUGJlpWIi6Gr0mLwHarrYoi9bwtcKAxRNXZiGQgh iUw2Zsw+jmgBrEtI4Iarg8wWqJ5Mov7MsTVpnoZ5Xywr0GznDlgcN tyqMibOULeM8yLPQrHn/tQjSiP3eUPz6+Zb9FqzQJCCi2UiauD4mO gzBSCCbew9PDYb2QeMZqNZmN3eVNMV4hh7t9jTc0zqPF5jluddVmp dHxLx/T9XZuSV21p8clNprJNQxprtHpxDxjhNMIrcV39rzi9tNikw mzRMf0r40f/JWnaV668sekDXtvIj8pZwyE4FNuaiJwojkQxDfjqk6 7Qs5NUQsFcaIwMes8It74ASHm8DUKEhDT2ASgMtUDwKWrOBefrSPq jY7+EMh2yVZnQhMwpx4s7CH0za32Yq+KC8GotHdI6jisDEom7aHgl g==" ], "uuid": "01a16b86-96e7-80a8-b9a2-279e0d16bc46" }, "signature": "HJA8mITP_gPp5FjIA2qw982rnUP44vDSeJRYGNXCxZhWm 1c5dGRTlpbssDFBweCE_eOHpi8O2GhIulx9XBod3NgColJu2FDBC6mmk7 5ke37A2AmSBuIl6AhQpEkfs6FRunG9OQ3I-r6dok9WHYI7JmgqcZY-2GH vzCIMW3LgaJZ1Vdt7TK3vqMR_Nn8Cpo3jkodtwMAuXivUtHWz4oldkScz uVqUMKtawLIU0GvPMfShR1C7ayuWgXkg7f1yiU9cKNtQM-biEyvIfGe_3 tSPl6G09IToJRo-17Ji1qmm1eTaMwudG4hWvFmlvWnQCq-QRFi30gfBYV EYyrAJj7p_Bg", "protected": "eyJhbGciOiJSUzI1NiJ9" } ] } B.7. Encrypted vCon This example vCon is the encrypted form of the Signed vCon (Appendix B.6) example. The private key to decrypt it can be found at: https://raw.githubusercontent.com/vcon-dev/vcon/main/certs/fake_grp.key The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_call_ext_rec_encrypted.vcon Petrie Expires 4 May 2027 [Page 147] Internet-Draft JSON vCon October 2026 Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. { "protected": "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZDQkMtSFM1M TIifQ", "iv": "2LXY42Qg-9NPezg9KrThkQ", "ciphertext": "tntDlZelgX_ECWMNDZ_gV14bCDhEPlBJS84xDDN_7P2jpyi0 EzWZWIQyhomCGVI-doUnVEbWRi3dfkF3t_uOOZIZ4F5-2ebiE94E6_JgJKHj0 ow92cO_l5jGcnt_U8nNWJU2m1gm0E_TyAkbGvoGWeBcvfunof5YbnQFVC0WZ9 Jns-JnY3mEKF18Z_ZKUyDrd9Q-b_MDDfrgfnVbCToGAupX7t26cgTFcEBudRX xeDbe-YJ2BaIN5GEPXT2Jeu4Aamq82hIdog8woW_QPpWGr6R44TjKLxz7n0AB ny2mHy6vNbpyzG3_EpTqGWbfsDlM11ObJR2sViKVb18u1-bEGFbRQgL9NlLkt B3QsK-j8j9Lc4hNqlCLLYE5cfSqkATPQJWevOdNuvri1FUZSlwo165_Gqu812 Fl94UcL0YHDStPZILL0b-G2CxAq-mcwoQXW6-ZlSj5aFIJAQuMl5KlEPSzIno kHr7Uuzr1sQofGIKfsw6nLCnP4N1Ijr6ulxNmKVn6TXa2koWYhUoTFx8iPMeV iXoIIAwkljQytXSVOOw8cGh3SrKEVSIsoKwFQpL0S5N_MWVBcZhhUmHF0BfOI M0pxevJYdA7T2rAiKgCDer-ofPe1l3bS21joWsHrRcxhNEHYddZL4FwgZV14X 6Nf9IglGLjo-iihenziSoE9njdBGwoctcGNosH_PvEmP1snfUjAZ81cdC9khw JIevVR6YU8liub7QOrI6vgFhoYDJVIO-d8fCNAL5Bx7Yh_--pPP2uTd6USTY4 KGJhncbmT0YOqmY2ccwvrU4C395Lj-ZncDjbs0GKF8FawIGiP7KYT_ndsje_5 _HdMCgkatrudRiNw8NGwQyt1idwF8aY5jVkI_RTg5i5tBs_PV3CT3-2oHCaKz fSvMvuwKR1cWJava7sh6G4EFNWo8FAjAhsUVNLkXySh0o6TI96MEFJPsspXeA nf9rtZmQ1o2CCbYrXlmtr7eB4G2BhRzmxENFWA7EGBK6WG8KwxvQ3WRsXkmt4 cybNAFVIe9Juhw3IpMLXhwSWQFWfqzU53bz856b6pC5IBMcdZ2AcwW3wjfEWA XvI56V4rTLtqF2rcHxoO2D_goTL2G6r4zuPHn2anJd7j-WlEBdpBTGYLwdlB3 42xAu49G1J04i2pqnkp1MGL43C6-RqFhyg5V1iYDySTRJIR057zku7ch4Fn7U T_GOVnXxLZHjFZHNLwEvbicj8s6UaQWrsCoL3_KwB8hoZYM7SEXp37KApRI2b 4BqnIs3OEDnXRmv3Mr5IDXqBTMq7i7WCW1vikF5YvwPljhDZO05wC7t647435 FVz8-bssvSJRPz973HD2u7aJc8Cm_i0HXz3iIto7xx10c9QNXtHs_QPeQ8omQ C8PpGDW09F6vgJY6VV6LkunFtRxmEpnA72F0oK4n7QxwRBe8I5a_wUot0RyQD z5j6PpdWe-vv9dfzm7uskZbTQCugM_NOqq3AqLndtDcUYUVUIAN9bienC--dM DuevNHyeMCUuF01X_EoLglcD6UMKyrZsPOIU9OpOyd1t_xNIRObQKk6Crahzl Md-Wa5bBJ6PT4eZtIT-3S8r9ucF6ZM2IeSZBPRxxLiGnTygKtVVfI5nwDSloR l1PFzR4A9YHY4mQcWB796eyP9l62cMtdRKveM5sh4CzPNdoIjgI-V-_YdV27L UJW3UMO5VXXEBF0mHmCvHZ_dJvxvTrXtqyG7uFICvfm6Pq_fjJ5pJUQwicLgJ JhJrPZldyvMIinh_nJgbDTeg_QM0xsxoavVGggaqktlQDOOJTLwODugi_9T87 pUNUGR2LKW8XQVbXZIk_3G--AA6fvFh5rNZk5h5R589SDTodDI6URlt0KSKKX xI7KO2NIXRIHzSOsTdENv2p4O4D8faWREYs8P8QYSvnKcHMpYTr3jVYOIEDuP Ypi3p25dmc7mUfDR_GzybN1APK9WbjLQ67u46ie8jUEBpSqMBNw5JW_UJn-ju 29mw8NCfJIl1I-BIb4x-CvYGKK1oNqVsymXy68mNcqSajHUnI3-fD_WbMYlmY mG35RxA8Z_IiueuOiM_MY6NkpSVClp6_e0ho7UbgcOfb4X4pngNHhDR6MyqP7 j5Li6anHVGODh3n6-EKxr4jDsGdZzw740uGoKQeqI0PcuOMO4nUQUXyUWwAQU Petrie Expires 4 May 2027 [Page 148] Internet-Draft JSON vCon October 2026 RtJ4_zfz2DIYET4Hi8VuQCp6NH6Gzt-mjYwKxKuRvjYUOCnJQWqeb66J5acuY zfUjCil4sLgQoalAFwN0x8jgB0QOQsFEE1YW-KHdkBNN7TKntz9jY-awL6-ue UBMs6w2LmuRzx1Mxb-Sxi8dZMhHC2F6FgEeHU1No2CGGTg3ab1tjCQaTBGuFg -YVlsWee_GLDPivX8YXD5fFu59mtS7e_ybpn2nq0OKgktzFuV2f9P8Mr62z9M yDYEXm9222-146-Z_z9CI3SzfL5oh_pF4UCKigHCrtEhiogrCe_1GcDYstUdN gY3ynQ6NGovi3KfkepQH9EkOkTS4sumUayT5X2Umy3jIPsKeyDL3vNzvaMJ6h dJRLTbEs8n2l8KHslXm22pFRqRTx-04vw49KANvikMStuCT3Mb8GodSs7f9xr nST0wjlVs1w3EHxcN3y5WJzj5LgeliPxQcDTbnnGY8AM-KET3qQ2jBv4uMwCk fh6TZxhTeIqizj7ER04qFfCITmZoYykSOpcZpO47O9hehRfgtqJDgi_nPZGUe C2xNiDT5QMJP6JOUaYW6W5-0Zl-KbtMKRc_Dtl_lKL2gflUPq63ABPYZO0EEi pzyq3boaULteaX65tv9v6fnE-o8exnRmlUbwbZCRl3b4OvAe90krnKttS8GC1 mUBn_PFQdbZeI0iFWcNIUnfpq7QLMNnx_j0V33wHlA8qYeAP9uEUuswtdot7m bKumZ_2T23_QuKFO-VbBxUQ8Uu1hiyPwEzDPVg8ZjLlFKYiYSST5pEIA202Kn rLbRZzWV5d43o-5nBJP9PIVh6bz7nbYYhTMffSZRdZsj2kehIhE3M2rvVBVDk OVXESX0g1rEmT4teL7sNKjfO4i9h3AM-uwQm5TJW5-0UMYn_t5kdDOy02PSeX 06vgKOIeUanwtdmLfFFM77JSielGHrrCGrjWPHEqO8s5yQMZxxEtr7exk2Zxq BCfCdgpJf-uNsLScYhHmixXOtc9XdWXXC9Uy6nVIBIbetrHmySUWYM4Vomxcn ywu6pCIfQqadB3LKNHnreN4WcMf9qoh1GRzQci_H7B8mpQj7QG8kgHNSLzqZd qQjlVZUxwTAPikhRoGoFlDDBZQPdjt7iNHJtm1JCVtKBK6ix3M8vn86KJ0koR M2uysbBKIIwYRL7Y1tyB10zEuT4qVi6p50w1h7qEmRC7rdnGc523n5aQN07wm JyhhgilJ6B4XkXf-dwEHGjczgztS1FWS6uD8C7TCWKQn9EUOz2ZvD4NyEolWO HtzmjWi2Wxozaf-ucZ7dyc_cPNT_UF761lhsgtbmoodAZqZoGSrtMX6EpKTgn DEDlMThw2xnuGFZXwFoCJqGytwOyFCyYNyC4AibyPz86n6Hdg_wli-_Bt5ipq oARee0inWXiun4gjXc8vUmFKzvQiM4b_6MoloJ4XX984Nc3i-N9NPzwZ2WSZw x0RTYH6hb9a7fG_NYw_08-P56BRQXv9X325RLIjwSbjSIogHANafLLUtm8rjj cGlBwNwlRy-HMj1bcR_axhfTXLVXwMKLKovPHTP1YRoGFVHKHoypaZrP0gd_p d8WLzHzmhG5rsB0utWP4PK6JSIlMd9Ua_32Ujf1dSg_FD6qFPKF-TDqgd9hTE k7oP2KP90piE1bHobxE3-HwXUlyBcnYJOKEwTlUpnCW_QkV4qiKwmJEt8tsMB effisR4tTablF0ReE-EsDEm7OVRYig6IGKYsPmqHyytSyjSTLnWNkflMfDARa -vykTWUXI4mVJCSWn4dRstPYLOL87YOol6VKA_R6PjSBguPb_xbYDadKOfpWO Rm2FshHaYkC8MJyaAAn679Ae-CDQosQKEjmk1N63te2kx628mvFhpxUVv9orB Zw65ldjL5UGHvIuamQVAFSL0lcUABLxq-mNAwwuIGNEW31keGZm9J41SvmO_P uoa3aJsipiq2xPrDFiODEjUceWyFzMnynByVO6cid8cksYIpG0DkePfJVfJ2A VsW1f34XbICw5YDCo8kNYynMS354E7fLSAq1dxQjbE1UgNF3pyq15zUcuJhMf ldtOZVOO5lL8be1bRiPwF7UrCmcD-_92DE10VJ3lfkvHRSSwMz0-a0jcMjALr hV_qYTJqtNiFDhiWCaklJSJ78LbHnm6khf0stb3HbvpwqL4tkfjWl_p2Sba7I 6WJqAbHtPnd0OZE_eD4R8tHWe_tgU4CVM_mbFhnSJkiAMEgGRSH7zRFymwCUL zoO5w-cAi6HJoL4atY_KmsVAnt2tAeuzlQ7ONOrHvhGa3oGFK01wERTHbdqI_ XVun7c8cWA1m-fyKke7lgp_BTj9Qu93KmyFUYai_doFxnxXqvihuC7nT2mm1t D4IK0pRB1fkM4xjwMJps-eWupL_-xCP_5HTlHd2fPtNpTlMaRqyN7DjG1pdCs MASWIxo22RKZRcW5WjB7D7c7hnEFPb1JxPZuUjn1yFBUKtKXzl85nXm0_wnW3 bp2NwO05wJDAzLJG1OIy0w2tOkWhySBv0s8hIDaixQpdcQOEPGw5gcHwCFOP4 0hsPnjtvaIUC80uhS1lhm38oAT90qs2s6JtqEVHE0PF2hoMWbKLMGUXRUdL4d 4w_HxD0pY2IywQhFy1SpGNAs5uvhxIySFcRv4DUQU02aF3G8bwHEcWBcrOzbw mUE0ugaqllknpiN_lu-Dk94FudPJUAL4Ckzd0xi0IOv8Y5bWfiggPBt4K20CF kMpCMROTSnTcX_rsHxUp1pMrbp2QsbOfealVIq-jzaLXs7Q8Fr8TlTkIQj7Is WzS4cVt9o6id9CvfaD_ykERw1cc2zkAf3RwGYdS--9TiQL8xsw2nhqCqEEkN8 G2ZWsbu-jt8LcQ3BZFUHjfgZeO5o5oYhPLV5-j8--XQeXoY6BY___eX8Ur0iB Petrie Expires 4 May 2027 [Page 149] Internet-Draft JSON vCon October 2026 G3Q4Ev9GhwNtDqrJCFvcq8YXNrN0cJRM9PlJgHQAWreZBKegq9uVR4ZTIufqX gheiVGS4VmYBCgUam4McC20qOVAltqdc154BzwoJgiWHgqu2MJ24yt1_1r_ay LI8aX6UIqBcGAFZKDkjLnzlvlWDhD7ZL5hd_3hu24mF5QM6XG8fZupwSS0kY7 XYeqAuOOoRvV52k3ajYtxtghWXhxwKwZ8Luf03B-N5Jopd7wMZC3zhMXYUBv2 yjn3adGIvRqFtm-GY7W0PecYDwbx0XILJDoakGXbIyXeqSmN_gVVNPQ9AsGZT UnLVwiJkwIdtgTXPyKwuJTrAHAo3in24iATKLbACFvOqOhQ4ac3sne1fy1b1O EwZMTX-SchuPsNucrM-VZJkHtdcrpACJ-d1B7hWKvCONcYtwnkoNMdEjihKMs 2XjmjbM8u7qMco1j0B8FTOX0T497WWPPwQpjXeueR0AKJIaOl6C-w9O0vihCY fHB-ep8FDWnnMv9O10q6oG9fcX3iNPcGHskPEW9AdnIAYsgRCs3Bs9Ju9c-aO RRVNzvngs8Q0oB-ZI-p1DWUcw8lzfFUfMoiG1JlrQrTtmAABz51_ZKc9B46wC pxQRNlBYYDjAzZbZyn2Z7c0tKs3UHa3865-VxEVqRgDkOljRmOgt2bCTwCKQb f73Yszq1RQfyhoTf9NiU3k90FdZUYzm8UYzTnQBJSP7TLz4hbAREGGTfR1QF9 Z1l5X9iPNEArh9RnW2NP8aiyES8Wt9MVaVO5I9CQDntef2cluOPNM2SRc8KgW g3ORIKP7X_R1tFBTyawaetdkt2B5MQq8S9CG1t43eLMP2Y1RXkqYFUHb10dbE -rB2UGqHRxIDscCXUBuz-zG01fyIOtaBTrQJSnodaPl-A3pCC0hx-KJ6FT5mC vkqf71j29IDNTtb07XKFUboZ29N5QnQIkqxlMUDJbxRPuqyyhDH2oCNr8dvzB p5Gf3ykljPZzjyzOeEkQwLoe0dAqcNnVj_EXLt-pOl9EbhqxPwNL4OEqt-qGD r5AKoDLWcDYEcjkY-10wHouY6f9DO7BtNceO8ZZg9VvEuC4Bf4341tpF_sMY8 vi0EUMd86F8HE8Vwjxql__WDB_T3rTGm6lr_7Cibtk_upaxN6nQgwfHMgT1CV gBfbh4NlYZ9lc4HQAKXL80F0-xafW4d05pXoHCnuANktWmJQ_8HgrPuWqv_C8 Qt3pfzaFeEgsErLb9yndbpu4HEty33fs9Q0ZVgINjvA4pniw9vP6md3PV2lDK h1w-Cu71c63gHIW9UnLW2xWll1Zgv2vNTOzsmI8g4wZWV33P0wUsHkDh6NjHR SUT1olkIrevpNJ56sHKHijPSUy9meRXkiFIN0B0Q9by-zCAayiNS7lB1tw7rU RFKAJV7HRnE6FdaIWcI_8XwVtNh6VS460qGWKJ-g_Mhktw3CCFZ8HZkBzhRNc x1rVTykoMMaYbe3TLTl5kql4y5PRXfIiTFytjCIRLLt9dtgeUfMfMxYRLoPbK YmDso385cmFeHIfvlxeyoF_NASXmf0tOhCqbRT45WI1BUmqH3EHhYAzlAspY7 D7Ur5l8_VrbWSlVaq1x095SajyEoNNL7qjADeppjlBsNPNqlpUwU8_VXJDrah l4dE40zptNer-ST2PLRPqrBlRB59ehYFBUxzI_Ap8_Is7HtfjGcvYcGHQ1kmM CJJDtRgG4FSV2pA10bzBsfWTlJGTbAgqf0kQEyxuD516GY3ydPZZ9-E3Q_rgw kYQci_0zlwTrErI-lBQkvyp27O3_9hjhO_dKYxqeBjiFZGOo3BhJz4D0d-68H _BNQIakLvyoL_FQWCSeBnQee-HRsPRd-qrFGpLwSrTCumeEhm8b9m82MvbABm NS0YmyAIaykiwyiUTnrwoxsCszArX4AtwurMHSImKVyv8JX_wdb4Arp16QTjN bBGmxt_SAEVnBUWi0gtKQ_-iylcjkVAnDY1SOqRa5FNVHfF49SeDgYzW-78C9 Y74RJLWZRApSfMKeG0tN8mKcVk3qZruX3cbw1WuUnmZXl-OQEoNbyJxt2e9T8 Kqw66Ds8XYzJxtpzKQMDQyeEYMM8-QSOq27FkGn3C3zkwJPvU8ajEC7UcFbAy 8VFHFV7t2Crr8zgnOpMtvN5T80nkANiQ9x6ZFwQfd7EHOXGMC8S-f9SqId4Mh 6fT_Og19bmFeDgvJjULNvkDMuQ2IjMFb-c2qiRIUnluah1jzYq_WdrR1M9aVL EzvkqNFlHLZ9ZmIxmjFoGQnC9hMclrHqhhox5Ydip0SJsP7a-slbf2M5ti3Nm vCuw3F9ZzgRc6UNKla3V8J5QQ1gNfXh3nS8JbqV226LFKKnI9JwPIbuK3fsS- u0kkqTf483_s6U151yydWWp0XXF7l0kWnJC6pyuf-STLBDt66Emg6zIsgc55o FHl-3KCqtRRK6oVkZHiWW5E7l8DeTgDrN5si_2i1Q-QaBr3cCbfvi405aXvAV Z6FYN4rbFcc1VluMOfVaiFzww56D_c7WFZ-JXS3CClHK9gL_tOrvsVScQACre j0oycGjfJ9U2TDX0fxtOblC2nsOKk88LuxqTN5LfjMf7FdqKCCWHykIaIf954 J03poSH_dc4nQuWwPEaIa29INMGK2zvPT_2lU-HOPqwPWGZffgym44yyvbWG8 Rixp-lat5LI9byCT12M6zZapCydqUlnxUs8GcLfg_w1_HvErv_MV0BxiF9W9i Ii7t4U8B2uvxSqpQtageMybDlz69CobbXLWhgakXnY1iRpE9906vM4BfqaUzq 7Wnj6q9iH3L6e4IunE2vXPK7jgW605ws66dYf7Pyo4ayn60R6mQMdbTL-3_UC pmLyCHFLv8LhT-Vn6yVY7H_bUN4d_d0HB5ohOiUHzT_BGqWx85o8oHEkMDp2W Petrie Expires 4 May 2027 [Page 150] Internet-Draft JSON vCon October 2026 N05qof81g9kMzE3nqGfwgRE5l1PBmlxwLLgosqGY02q5f4ls6-4GFBZruIcj2 YYXgNsKwVMnQ0V9E6_VlSfFDvv6y46EOIJsu4DBwQHNrCmZArSXDZ_XXruxwM -w6ZwszOW1gThfSf_FHs1XXS6rliC_MXu_hZsqsSv7mwh6uHMhRUAVKfxGFj1 a1FJlM8Ppyn_qAj3zaVaISYVTxHdK0dSQ6vZ-XGm46S7wIXaeTEse4E_cWZhH _tMlhUbQHA2y-aZZnQamgNiGhD_r8_-7wWtLr0Y1xspp4UQq5AdvseQA9rsCO WHT19nuFKTTTtfLjjgI68_yeRmKwMk2cXFbyg_ilOnGWuPEJPeFuXLAxRMgMY teSdIj_nI8SvJ6t0f0xlfWTPbhXezZcpWrj2ZdE8agQGGOw5I_Vf1TYj1eJ_l ZEz5X03Z7XdOqJawddYCTfcefMeOUIgnSXV4h7Cz-FLLKBAeWiOllU2i88kFL f4wm07LiTeh6v8NGL3xhxsMja4piZASkexICYHHgZvNqeqY18j-o4IFnNPgJq MvTMisflnUinWYIdgHu-CNZE6ZO-c3iEcOR-UVDgv9dt2w4vmk_7h-JvJtlQ- Mk9wgRr3Ef0mnrYVxZzxgt6uIuqJlRjP_FFyjzzWgaL9QlQg8-sHoAUQ8JDRO 555sdMFQCpHiTrhQ", "tag": "hyXd3meC4V_SRrDsobgH4f8skmb0R1XQUD1dNz268FI", "recipients": [ { "encrypted_key": "Sm_D7ScQI9hhTknxXnSeg5ph2WugCTVUxmxJX-jmr GuxFdnLsJO2ww7hczEVsfdCPXXu2WjS2_nGBKr5T8YqfJnGqgvnoeddWC nlhnFDARrQCaj-Ra0rLADoCukdwubwsVnCuVaS1uuLRh0BGLq7GOSug5A NoXDyylfscaGO_2m2Jp1R8fk0G08SZ78SGRexkOhnpDAPFX1kOpVMWzS1 ZYmYVTkZxjtv3Sm7YABnhvDhxdxHZFR_n83EYVSjIfenJOPnJ7M_hyWh2 eStg2n-V6dpqc_PC9cHB-bGYey_Lnx4kDOiGeqjvg5yo_qYK0PYn-pr59 Su0q0qZkp_3g80vQ" } ], "unprotected": { "uuid": "01a16b86-96e7-80a8-b9a2-279e0d16bc46", "cty": "application/vcon" } } B.8. Redacted vCon This is an example redaction of the vCon in the example Two Party Call vCon With Externally Referenced Recording (Appendix B.4). Most notable is the Redacted_from object (Section 4.1.8) which references the lesser redacted version of this vCon. In addition the *url* parameter has been redacted from the Dialog Object (Section 4.5), but the rest of the Dialog Object (Section 4.5) was left in the redaction. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_call_ext_rec_redacted.vcon Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. Petrie Expires 4 May 2027 [Page 151] Internet-Draft JSON vCon October 2026 The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. TODO: need a better conversation/recording to demonstrate redaction { "vcon": "0.5.0", "created_at": "2022-06-21T13:53:00-04:00", "parties": [ { "name": "Alice" }, { "name": "Bob" } ], "dialog": [ { "type": "recording", "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, 1 ], "mediatype": "audio/ogg", "filename": "ab_call_2ch.ogg", "content_hash": "sha512-Y-Q9eclT6b5hFyIfLtnFAAXgqFzN5_Cjr3J Q3DMmcnpXHkGMgtvaxrLW2R2OhFTzR-DinyrngBG2w9lTZXr1EQ" } ], "analysis": [ { "type": "transcript-redacted", "dialog": 0, "body": [ { "parties": 0, "start": "2022-06-21T17:53:31.520000+00:00", "duration": 0.6400000000000006, "text": "Hi." }, { "parties": 0, "start": "2022-06-21T17:53:32.240000+00:00", "duration": 2.16, "text": "I'd like to add Foo to my service." Petrie Expires 4 May 2027 [Page 152] Internet-Draft JSON vCon October 2026 }, { "parties": 0, "start": "2022-06-21T17:53:39.695001+00:00", "duration": 6.5600000000000005, "text": "My name is Alice and my number is {{BAN}}." }, { "parties": 0, "start": "2022-06-21T17:53:53.820936+00:00", "duration": 0.5600020000000008, "text": "No." }, { "parties": 0, "start": "2022-06-21T17:53:54.380938+00:00", "duration": 0.7999989999999997, "text": "Thank you." }, { "parties": 0, "start": "2022-06-21T17:53:55.180937+00:00", "duration": 0.3200000000000003, "text": "Goodbye." }, { "parties": 1, "start": "2022-06-21T17:53:27.120000+00:00", "duration": 0.5599999999999998, "text": "Hello." }, { "parties": 1, "start": "2022-06-21T17:53:27.680000+00:00", "duration": 1.5999999999999999, "text": "This is {{URL}}." }, { "parties": 1, "start": "2022-06-21T17:53:29.280000+00:00", "duration": 0.8800000000000003, "text": "My name is Bob." }, { "parties": 1, "start": "2022-06-21T17:53:30.160000+00:00", "duration": 1.2000000000000002, "text": "How can I help you?" Petrie Expires 4 May 2027 [Page 153] Internet-Draft JSON vCon October 2026 }, { "parties": 1, "start": "2022-06-21T17:53:35.040000+00:00", "duration": 0.7199990000000014, "text": "{{US_STATE}}." }, { "parties": 1, "start": "2022-06-21T17:53:36.080000+00:00", "duration": 2.959999999999999, "text": "Can you give me your name and phone number so I can look up your account?" }, { "parties": 1, "start": "2022-06-21T17:53:46.635000+00:00", "duration": 0.7999999999999972, "text": "Thank you." }, { "parties": 1, "start": "2022-06-21T17:53:48.795000+00:00", "duration": 0.7199999999999989, "text": "{{US_STATE}}." }, { "parties": 1, "start": "2022-06-21T17:53:49.994999+00:00", "duration": 1.600002, "text": "I've added food to your service." }, { "parties": 1, "start": "2022-06-21T17:53:51.595001+00:00", "duration": 1.6799989999999987, "text": "Is there anything else I can help you with?" }, { "parties": 1, "start": "2022-06-21T17:53:56.320875+00:00", "duration": 0.6400000000000006, "text": "Goodbye." }, { "parties": 1, "start": "2022-06-21T17:53:56.960875+00:00", "duration": 0.8000009999999982, Petrie Expires 4 May 2027 [Page 154] Internet-Draft JSON vCon October 2026 "text": "Have a nice day." } ], "encoding": "json", "vendor": "CapitalOne", "schema": "data_labeler_schema", "product": "dataprofiler" } ], "attachments": [], "sessions": [ { "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, 1 ], "dialog": [ 0 ] } ], "uuid": "01928e10-193e-8231-b9a2-279e0d16bc46", "redacted_from": { "uuid": "01a16b86-96e7-80a8-b9a2-279e0d16bc46", "type": "PII Redaction" } } B.9. Amended Signed vCon This is an example vCon with an Amended_from Object (Section 4.1.9.1) referencing the vCon that it amends or adds additional content. In this case it is referencing the signed vCon example above. An example text Dialog Object (index 1) is the amendment. The unformatted version of the following example can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon- vcon-core/refs/heads/main/examples/ab_call_ext_rec_amended.vcon Note to the RFC Editor: This example, and its unformatted version at the URL above, contain the vcon parameter (see Section 4.1.1), which is included in the Internet-Draft versions of this document to indicate the version of the schema upon which the example is based. The vcon parameter is to be removed from the example and its unformatted version before publication as an RFC. Please remove this note before publication. Petrie Expires 4 May 2027 [Page 155] Internet-Draft JSON vCon October 2026 { "vcon": "0.5.0", "created_at": "2022-06-21T13:53:00-04:00", "parties": [ { "tel": "+12345678901", "name": "Alice" }, { "tel": "+19876543210", "name": "Bob" } ], "dialog": [ { "type": "recording", "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, 1 ], "url": "https://github.com/ietf-wg-vcon/draft-ietf-vcon-vco n-core/raw/refs/heads/main/examples/ab_call_2ch.ogg", "mediatype": "audio/ogg", "filename": "ab_call_2ch.ogg", "content_hash": "sha512-Y-Q9eclT6b5hFyIfLtnFAAXgqFzN5_Cjr3J Q3DMmcnpXHkGMgtvaxrLW2R2OhFTzR-DinyrngBG2w9lTZXr1EQ" }, { "type": "text", "start": "2022-06-21T17:53:26.000+00:00", "parties": [ 1 ], "mediatype": "text/plain", "body": "Good day!", "encoding": "none" } ], "analysis": [], "attachments": [], "sessions": [ { "start": "2022-06-21T17:53:26.000+00:00", "duration": 32.932396, "parties": [ 0, Petrie Expires 4 May 2027 [Page 156] Internet-Draft JSON vCon October 2026 1 ], "dialog": [ 0, 1 ] } ], "uuid": "01a16b86-9ea3-8a32-a20f-d188127fad29", "amended_from": { "uuid": "01a16b86-96e7-80a8-b9a2-279e0d16bc46" } } Appendix C. vCon JSON Schema This JSON schema is provided as informational. The text in sections 1-6 of this document define the normative definition of the vCon schema. If the JSON schema provided below differs from that in the text of the above sections, the text should be taken as the definitive definition and the JSON Schema below should be consider incorrect. The JSON Schema is permissive: parameters and type values which are not defined in this document do not cause validation to fail. The JSON Schema definition below has been formatted with line breaks to print nicely on the page. The unformatted version of the JSON schema can be downloaded from: https://raw.githubusercontent.com/ ietf-wg-vcon/draft-ietf-vcon-vcon-core/refs/heads/main/ vcon_json_schema.json { "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://ietf.org/vcon/schemas/unsigned-vcon.json", "title": "vCon - Unsigned Form", "description": "JSON schema for the unsigned form of vCon (Conv ersational Data Container) as defined in RFCXXXX", "type": "object", "required": [ "uuid", "created_at" ], "properties": { "vcon": { "type": "string", "description": "DEPRECATED: Syntactic version of the JSON f ormat. This was used to indicate schema changes in the In ternet-Draft versions", Petrie Expires 4 May 2027 [Page 157] Internet-Draft JSON vCon October 2026 "const": "0.5.0" }, "uuid": { "type": "string", "description": "Globally unique identifier for the vCon. SH OULD be a version 8 UUID", "format": "uuid" }, "extensions": { "type": "array", "description": "List of names of all vCon extensions used b y this vCon", "items": { "type": "string" } }, "critical": { "type": "array", "description": "List of extension names that a consumer MUS T support to safely process this vCon", "items": { "type": "string" } }, "created_at": { "type": "string", "description": "Creation time of this vCon in RFC3339 forma t", "format": "date-time" }, "updated_at": { "type": "string", "description": "Last modified time of this vCon in RFC3339 format", "format": "date-time" }, "subject": { "type": "string", "description": "Subject or topic of the conversation" }, "redacted_from": { "type": "object", "description": "Reference to the unredacted or less redacte d vCon prior instance (Redacted_from Object); mutually ex clusive with amended_from", "required": [ "type" ], Petrie Expires 4 May 2027 [Page 158] Internet-Draft JSON vCon October 2026 "properties": { "uuid": { "type": "string", "description": "UUID of the unredacted or less redacted vCon prior instance", "format": "uuid" }, "type": { "type": "string", "description": "Type of redaction performed; same set o f values as the type parameter of the Redacted_string Object" }, "url": { "type": "string", "description": "HTTPS URL where the referenced vCon is stored", "format": "uri" }, "content_hash": { "oneOf": [ { "type": "string" }, { "type": "array", "items": { "type": "string" } } ], "description": "Hash(es) of the external content using format: algorithm-base64url_encoded_hash" } }, "dependencies": { "url": [ "content_hash" ] } }, "amended_from": { "type": "object", "description": "Reference to the prior vCon instance versio n that this vCon amends (Amended_from Object); mutually e xclusive with redacted_from", "properties": { "uuid": { Petrie Expires 4 May 2027 [Page 159] Internet-Draft JSON vCon October 2026 "type": "string", "description": "UUID of the prior vCon instance version ", "format": "uuid" }, "url": { "type": "string", "description": "HTTPS URL where the referenced vCon is stored", "format": "uri" }, "content_hash": { "oneOf": [ { "type": "string" }, { "type": "array", "items": { "type": "string" } } ], "description": "Hash(es) of the external content (requi red if url is provided)" } }, "dependencies": { "url": [ "content_hash" ] }, "if": { "not": { "required": [ "url" ] } }, "then": { "required": [ "uuid" ], "$comment": "uuid is optional only if an external referen ce is provided" } }, "redacted_strings": { Petrie Expires 4 May 2027 [Page 160] Internet-Draft JSON vCon October 2026 "type": "array", "description": "Array of Redacted_string Objects, one for e ach unique substring replaced by __REDACTED_REF_# in the vCon", "items": { "$ref": "#/definitions/RedactedString" } }, "sessions": { "type": "array", "description": "Array of Session Objects, each grouping the Dialog and Event Objects of one session of the conversat ion", "items": { "$ref": "#/definitions/Session" } }, "parties": { "type": "array", "description": "Array of Party Objects representing all par ties involved in the conversation", "items": { "$ref": "#/definitions/Party" } }, "events": { "type": "array", "description": "Array of Event Objects; order is not signif icant, Event Objects are sequenced by their time paramete r", "items": { "$ref": "#/definitions/Event" } }, "dialog": { "type": "array", "description": "Array of Dialog Objects containing the capt ured conversation content", "items": { "$ref": "#/definitions/Dialog" } }, "analysis": { "type": "array", "description": "Array of Analysis Objects containing analys is performed on the conversational data", "items": { "$ref": "#/definitions/Analysis" Petrie Expires 4 May 2027 [Page 161] Internet-Draft JSON vCon October 2026 } }, "attachments": { "type": "array", "description": "Array of Attachment Objects for ancillary d ocuments related to the conversation", "items": { "$ref": "#/definitions/Attachment" } } }, "definitions": { "Session": { "type": "object", "description": "Represents one session of the conversation and references the Dialog Objects which are part of it; a Session Object with no parameters is permitted", "properties": { "start": { "type": "string", "format": "date-time", "description": "Start time of the session in RFC3339 fo rmat; SHOULD be present" }, "duration": { "anyOf": [ { "type": "integer", "minimum": 0 }, { "type": "number", "minimum": 0 } ], "description": "Duration of the session in seconds" }, "parties": { "type": "array", "items": { "type": "integer", "minimum": 0 }, "description": "Indices of the parties that are the rec eivers of the dialog in the session; SHOULD be presen t; the first party is the implied originator" }, "originator": { Petrie Expires 4 May 2027 [Page 162] Internet-Draft JSON vCon October 2026 "type": "integer", "minimum": 0, "description": "Index of the originating party; only pr ovided if the first party in parties is not the origi nator" }, "session_id": { "$ref": "#/definitions/SessionId" }, "sessions": { "type": "array", "items": { "$ref": "#/definitions/SessionReference" }, "description": "Relationships to other Session Objects" }, "dialog": { "type": "array", "items": { "type": "integer", "minimum": 0 }, "description": "Indices of the Dialog Objects which are part of the session" } } }, "SessionReference": { "type": "object", "description": "Session_Reference Object: the relationship of another Session Object to the Session Object which con tains this reference", "required": [ "session", "type" ], "properties": { "session": { "type": "integer", "minimum": 0, "description": "Index of the referenced Session Object in the sessions array" }, "type": { "type": "string", "description": "Type of relationship: child, peer, prec ursor, breakout, or a value defined in a vCon extensi on" Petrie Expires 4 May 2027 [Page 163] Internet-Draft JSON vCon October 2026 }, "description": { "type": "string", "description": "Free form text description of the relat ionship" } } }, "Party": { "type": "object", "description": "Represents a party involved in the conversa tion", "properties": { "tel": { "type": "string", "description": "TEL URL (RFC3966) for the party" }, "sip": { "type": "string", "description": "SIP URL for the party" }, "stir": { "type": "string", "description": "STIR PASSporT in JWS Compact Serializat ion form" }, "mailto": { "type": "string", "description": "Email address for the party in any comm on form, including a bare address or a MAILTO URL" }, "name": { "type": "string", "description": "Name of the party" }, "did": { "type": "string", "description": "Decentralized Identifier (DID) URI for the party" }, "validation": { "type": "string", "description": "Label or token identifying the method o f identity validation used" }, "gmlpos": { "type": "string", "description": "Geographic location in GML pos format ( Petrie Expires 4 May 2027 [Page 164] Internet-Draft JSON vCon October 2026 latitude longitude)" }, "civicaddress": { "$ref": "#/definitions/Civicaddress" }, "uuid": { "type": "string", "description": "Free form unique identifier for the par ticipant; not constrained to UUID syntax" }, "type": { "type": "string", "description": "Participant type" }, "org": { "type": "string", "description": "Organization to which the party belongs " }, "dept": { "type": "string", "description": "Department to which the party belongs" } } }, "Civicaddress": { "type": "object", "description": "Civic address information for a party's loc ation", "properties": { "country": { "type": "string" }, "a1": { "type": "string", "description": "National subdivision (state/province)" }, "a2": { "type": "string", "description": "County/parish/district" }, "a3": { "type": "string", "description": "City/township" }, "a4": { "type": "string", "description": "City division/borough" Petrie Expires 4 May 2027 [Page 165] Internet-Draft JSON vCon October 2026 }, "a5": { "type": "string", "description": "Neighborhood/block" }, "a6": { "type": "string", "description": "Street" }, "prd": { "type": "string", "description": "Leading street direction" }, "pod": { "type": "string", "description": "Trailing street suffix" }, "sts": { "type": "string", "description": "Street suffix" }, "hno": { "type": "string", "description": "House number" }, "hns": { "type": "string", "description": "House number suffix" }, "lmk": { "type": "string", "description": "Landmark" }, "loc": { "type": "string", "description": "Additional location info" }, "flr": { "type": "string", "description": "Floor" }, "nam": { "type": "string", "description": "Name/occupant" }, "pc": { "type": "string", "description": "Postal code" Petrie Expires 4 May 2027 [Page 166] Internet-Draft JSON vCon October 2026 } } }, "Event": { "type": "object", "description": "Represents an event which occurred in a ses sion, such as a party joining, a key press or a transfer" , "required": [ "type", "time" ], "properties": { "type": { "type": "string", "description": "Type of event: join, drop, hold, unhold , mute, unmute, keydown, keyup, consultation-start, b lind-transfer, consultative-transfer, transfer-abando ned, channel-contributors, or a value defined in a vC on extension" }, "time": { "type": "string", "format": "date-time", "description": "Time of the event in RFC3339 format" }, "sessions": { "oneOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", "items": { "type": "integer", "minimum": 0 } } ], "description": "Index or indices of the Session Objects in which the event occurred; the event applies only to the listed Session Objects; for transfer event typ es, a single index to the Session Object for the orig inal call; MUST NOT be present for channel-contributo rs" }, "party": { Petrie Expires 4 May 2027 [Page 167] Internet-Draft JSON vCon October 2026 "type": "integer", "minimum": 0, "description": "Index of the party to which the event a pplies; for transfer event types, the Transferor; MUS T NOT be present for channel-contributors" }, "dialog": { "type": "integer", "minimum": 0, "description": "Index of the Dialog Object to which the event relates; required for channel-contributors, wh ere it references a recording Dialog Object; SHOULD N OT be present for the other event types defined in RF CXXXX; an event type defined in a vCon extension may allow an array of indices" }, "channel": { "type": "integer", "minimum": 0, "description": "Index of the channel of the recording, where 0 is the first channel (channel-contributors on ly)" }, "contributors": { "anyOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", "items": { "type": "integer", "minimum": 0 } }, { "type": "null" } ], "description": "Index or indices of the parties contrib uting to the channel starting at the time of the even t; null or absent means no party contributes (channel -contributors only)" }, "button": { "type": "string", "description": "DTMF digit, character or string (requir Petrie Expires 4 May 2027 [Page 168] Internet-Draft JSON vCon October 2026 ed for keydown and keyup events)" }, "transferee": { "type": "integer", "minimum": 0, "description": "Party index of the Transferee (transfer event types)" }, "transfer_target": { "type": "integer", "minimum": 0, "description": "Party index of the Transfer Target (tra nsfer event types; optional for transfer-abandoned)" }, "consultation": { "type": "integer", "minimum": 0, "description": "Session index of the consultative call (consultation-start and consultative-transfer; option al for transfer-abandoned)" }, "target_session": { "type": "integer", "minimum": 0, "description": "Session index of the target call (blind -transfer and consultative-transfer)" } }, "allOf": [ { "if": { "properties": { "type": { "enum": [ "join", "drop", "hold", "unhold", "mute", "unmute", "keydown", "keyup", "consultation-start", "blind-transfer", "consultative-transfer", "transfer-abandoned" ] } Petrie Expires 4 May 2027 [Page 169] Internet-Draft JSON vCon October 2026 }, "required": [ "type" ] }, "then": { "required": [ "sessions", "party" ], "not": { "anyOf": [ { "required": [ "channel" ] }, { "required": [ "contributors" ] } ] } } }, { "if": { "properties": { "type": { "enum": [ "consultation-start", "blind-transfer", "consultative-transfer", "transfer-abandoned" ] } }, "required": [ "type" ] }, "then": { "properties": { "sessions": { "type": "integer", "minimum": 0 } Petrie Expires 4 May 2027 [Page 170] Internet-Draft JSON vCon October 2026 } } }, { "if": { "properties": { "type": { "enum": [ "join", "drop", "hold", "unhold", "mute", "unmute" ] } }, "required": [ "type" ] }, "then": { "not": { "anyOf": [ { "required": [ "button" ] }, { "required": [ "transferee" ] }, { "required": [ "transfer_target" ] }, { "required": [ "consultation" ] }, { "required": [ "target_session" ] Petrie Expires 4 May 2027 [Page 171] Internet-Draft JSON vCon October 2026 } ] } } }, { "if": { "properties": { "type": { "enum": [ "keydown", "keyup" ] } }, "required": [ "type" ] }, "then": { "required": [ "button" ], "not": { "anyOf": [ { "required": [ "transferee" ] }, { "required": [ "transfer_target" ] }, { "required": [ "consultation" ] }, { "required": [ "target_session" ] } ] } } Petrie Expires 4 May 2027 [Page 172] Internet-Draft JSON vCon October 2026 }, { "if": { "properties": { "type": { "const": "consultation-start" } }, "required": [ "type" ] }, "then": { "required": [ "transferee", "transfer_target", "consultation" ], "not": { "anyOf": [ { "required": [ "button" ] }, { "required": [ "target_session" ] } ] } } }, { "if": { "properties": { "type": { "const": "blind-transfer" } }, "required": [ "type" ] }, "then": { "required": [ "transferee", Petrie Expires 4 May 2027 [Page 173] Internet-Draft JSON vCon October 2026 "transfer_target", "target_session" ], "not": { "anyOf": [ { "required": [ "button" ] }, { "required": [ "consultation" ] } ] } } }, { "if": { "properties": { "type": { "const": "consultative-transfer" } }, "required": [ "type" ] }, "then": { "required": [ "transferee", "transfer_target", "consultation", "target_session" ], "not": { "anyOf": [ { "required": [ "button" ] } ] } } }, Petrie Expires 4 May 2027 [Page 174] Internet-Draft JSON vCon October 2026 { "if": { "properties": { "type": { "const": "transfer-abandoned" } }, "required": [ "type" ] }, "then": { "required": [ "transferee" ], "not": { "anyOf": [ { "required": [ "button" ] }, { "required": [ "target_session" ] } ] } } }, { "if": { "properties": { "type": { "const": "channel-contributors" } }, "required": [ "type" ] }, "then": { "required": [ "dialog", "channel" ], "not": { Petrie Expires 4 May 2027 [Page 175] Internet-Draft JSON vCon October 2026 "anyOf": [ { "required": [ "sessions" ] }, { "required": [ "party" ] }, { "required": [ "button" ] }, { "required": [ "transferee" ] }, { "required": [ "transfer_target" ] }, { "required": [ "consultation" ] }, { "required": [ "target_session" ] } ] } } } ], "$comment": "The rules for each known type follow the Event Object Parameter Applicability by Type tables. SHOULD NO T statements, such as dialog in the event types other tha n channel-contributors, are not enforced. An Event Object with a type which is not listed is only checked for the parameters common to all types." }, Petrie Expires 4 May 2027 [Page 176] Internet-Draft JSON vCon October 2026 "Dialog": { "type": "object", "description": "Represents a segment of captured conversati on; an empty Dialog Object holds a position in the dialog array", "anyOf": [ { "required": [ "type" ] }, { "maxProperties": 0, "$comment": "An empty Dialog Object has no type and no meaning" } ], "properties": { "type": { "type": "string", "description": "Type of dialog: recording, text, incomp lete, or a value defined in a vCon extension" }, "start": { "type": "string", "format": "date-time", "description": "Start time of the dialog in RFC3339 for mat; SHOULD be present unless not known" }, "duration": { "anyOf": [ { "type": "integer", "minimum": 0 }, { "type": "number", "minimum": 0 } ], "description": "Duration in seconds" }, "parties": { "anyOf": [ { "type": "integer", "minimum": 0 }, Petrie Expires 4 May 2027 [Page 177] Internet-Draft JSON vCon October 2026 { "type": "array", "items": { "type": "integer", "minimum": 0 } }, { "type": "array", "items": { "anyOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", "items": { "type": "integer", "minimum": 0 } }, { "type": "null" } ] } } ], "description": "Index/indices of the parties that contr ibuted to the dialog content; SHOULD be present for r ecording and text types" }, "mediatype": { "type": "string", "description": "Media type of the dialog content; MUST be present for inline content; not required when Dial og Content is absent" }, "filename": { "type": "string", "description": "Original filename of the dialog content " }, "body": { "description": "Inline content of the dialog (for inlin e files). Any type for encoding json; a string for e ncoding base64url or none." Petrie Expires 4 May 2027 [Page 178] Internet-Draft JSON vCon October 2026 }, "encoding": { "type": "string", "description": "Encoding type for inline content: base6 4url, json, none, or a value defined in a vCon extens ion" }, "url": { "type": "string", "format": "uri", "description": "HTTPS URL for externally referenced con tent" }, "content_hash": { "oneOf": [ { "type": "string" }, { "type": "array", "items": { "type": "string" } } ], "description": "Hash(es) of external content" }, "disposition": { "type": "string", "description": "Reason the call or conversation failed (required for incomplete type, SHOULD NOT be present for other types): no-answer, congestion, failed, busy , hung-up, voicemail-no-message, or a value defined i n a vCon extension; \"failed\" SHOULD be used when th e reason is not known" }, "session_id": { "anyOf": [ { "$ref": "#/definitions/SessionId" }, { "type": "array", "items": { "$ref": "#/definitions/SessionId" } }, { Petrie Expires 4 May 2027 [Page 179] Internet-Draft JSON vCon October 2026 "type": "array", "items": { "oneOf": [ { "$ref": "#/definitions/SessionId" }, { "type": "array", "items": { "$ref": "#/definitions/SessionId" } } ] } } ], "description": "Session ID(s) for the dialog, correlate d with the parties parameter" }, "application": { "type": "string", "description": "Application, communication channel or c ontext of the conversation" }, "message_id": { "type": "string", "description": "Unique message identifier from the mess aging system" }, "redacted_segments": { "type": "array", "description": "Redacted_segments Objects for the audio visual segments which were redacted; SHOULD NOT be pr esent for text; MUST NOT be present for incomplete", "items": { "$ref": "#/definitions/RedactedSegments" } } }, "dependencies": { "url": [ "content_hash" ] }, "allOf": [ { "if": { "properties": { Petrie Expires 4 May 2027 [Page 180] Internet-Draft JSON vCon October 2026 "type": { "const": "incomplete" } }, "required": [ "type" ] }, "then": { "required": [ "disposition" ], "not": { "anyOf": [ { "required": [ "mediatype" ] }, { "required": [ "filename" ] }, { "required": [ "body" ] }, { "required": [ "encoding" ] }, { "required": [ "url" ] }, { "required": [ "content_hash" ] }, { "required": [ "message_id" ] Petrie Expires 4 May 2027 [Page 181] Internet-Draft JSON vCon October 2026 }, { "required": [ "redacted_segments" ] } ] } } }, { "if": { "required": [ "body" ], "properties": { "body": { "not": { "const": "" } } } }, "then": { "required": [ "encoding" ] } }, { "if": { "required": [ "body" ], "properties": { "body": { "not": { "const": "" } } } }, "then": { "required": [ "mediatype" ] } }, Petrie Expires 4 May 2027 [Page 182] Internet-Draft JSON vCon October 2026 { "if": { "properties": { "encoding": { "enum": [ "base64url", "none" ] } }, "required": [ "encoding" ] }, "then": { "properties": { "body": { "type": "string" } } } } ], "$comment": "The rules for each known type follow the Dialo g Object Parameter Applicability by Type table. A Dialog Object with a type which is not listed is only checked fo r the rules common to all types." }, "SessionId": { "type": "object", "description": "Session identifier with local and remote UU IDs", "properties": { "local": { "type": "string", "description": "Local UUID for the session" }, "remote": { "type": "string", "description": "Remote UUID for the session" } } }, "Attachment": { "type": "object", "description": "Represents an ancillary document related to the conversation", "required": [ Petrie Expires 4 May 2027 [Page 183] Internet-Draft JSON vCon October 2026 "start", "party" ], "properties": { "purpose": { "type": "string", "description": "text description of what the attachment is for" }, "start": { "type": "string", "format": "date-time", "description": "Time the attachment was sent/exchanged in RFC3339 format" }, "party": { "type": "integer", "minimum": 0, "description": "Index of the party that contributed the attachment" }, "dialog": { "type": "integer", "minimum": 0, "description": "Index of the dialog this attachment is part of (optional; at least one of dialog or session MUST be present)" }, "session": { "oneOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", "items": { "type": "integer", "minimum": 0 } } ], "description": "Index/indices of the Session Object(s) this attachment is related to" }, "mediatype": { "type": "string", "description": "Media type of the attachment content; M Petrie Expires 4 May 2027 [Page 184] Internet-Draft JSON vCon October 2026 UST be present for inline content; not required when Attachment Content is absent" }, "filename": { "type": "string", "description": "Original filename of the attachment" }, "body": { "description": "Inline content of the attachment (for i nline files). Any type for encoding json; a string f or encoding base64url or none." }, "encoding": { "type": "string", "description": "Encoding type for inline content: base6 4url, json, none, or a value defined in a vCon extens ion" }, "url": { "type": "string", "format": "uri", "description": "HTTPS URL for externally referenced att achment" }, "content_hash": { "oneOf": [ { "type": "string" }, { "type": "array", "items": { "type": "string" } } ], "description": "Hash(es) of external content" } }, "dependencies": { "url": [ "content_hash" ] }, "anyOf": [ { "required": [ "dialog" Petrie Expires 4 May 2027 [Page 185] Internet-Draft JSON vCon October 2026 ] }, { "required": [ "session" ] } ], "allOf": [ { "if": { "required": [ "body" ], "properties": { "body": { "not": { "const": "" } } } }, "then": { "required": [ "encoding" ] } }, { "if": { "required": [ "body" ], "properties": { "body": { "not": { "const": "" } } } }, "then": { "required": [ "mediatype" ] } }, { Petrie Expires 4 May 2027 [Page 186] Internet-Draft JSON vCon October 2026 "if": { "properties": { "encoding": { "enum": [ "base64url", "none" ] } }, "required": [ "encoding" ] }, "then": { "properties": { "body": { "type": "string" } } } } ] }, "Analysis": { "type": "object", "description": "Represents analysis performed on the conver sational data", "required": [ "type", "vendor" ], "properties": { "type": { "type": "string", "description": "Semantic type of analysis (e.g., report , sentiment, summary, transcript, translation, tts)" }, "dialog": { "oneOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", "items": { "type": "integer", "minimum": 0 Petrie Expires 4 May 2027 [Page 187] Internet-Draft JSON vCon October 2026 } } ], "description": "Index/indices of dialog objects this an alysis is based on (optional)" }, "sessions": { "oneOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", "items": { "type": "integer", "minimum": 0 } } ], "description": "Index/indices of Session Objects this a nalysis is based on (optional)" }, "attachment": { "oneOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", "items": { "type": "integer", "minimum": 0 } } ], "description": "Index/indices of attachment objects thi s analysis is based on (optional)" }, "analysis": { "oneOf": [ { "type": "integer", "minimum": 0 }, { "type": "array", Petrie Expires 4 May 2027 [Page 188] Internet-Draft JSON vCon October 2026 "items": { "type": "integer", "minimum": 0 } } ], "description": "Index/indices of other Analysis Objects this analysis is based on (optional); MUST NOT refer ence itself" }, "mediatype": { "type": "string", "description": "Media type of the analysis content; SHO ULD be provided for inline content and for external c ontent without an HTTPS Content-Type header; when no media type is defined for the data format, the vendor , product and schema parameters SHOULD identify the f ormat instead" }, "filename": { "type": "string", "description": "Original filename of the analysis data" }, "vendor": { "type": "string", "description": "Vendor or product name that generated t he analysis" }, "product": { "type": "string", "description": "Product name to differentiate from othe r vendor products" }, "schema": { "type": "string", "description": "Token or label for the data format/sche ma of the analysis" }, "body": { "description": "Inline content of the analysis (for inl ine files). Any type for encoding json; a string for encoding base64url or none." }, "encoding": { "type": "string", "description": "Encoding type for inline content: base6 4url, json, none, or a value defined in a vCon extens ion" Petrie Expires 4 May 2027 [Page 189] Internet-Draft JSON vCon October 2026 }, "url": { "type": "string", "format": "uri", "description": "HTTPS URL for externally referenced ana lysis" }, "content_hash": { "oneOf": [ { "type": "string" }, { "type": "array", "items": { "type": "string" } } ], "description": "Hash(es) of external content" } }, "dependencies": { "url": [ "content_hash" ] }, "allOf": [ { "if": { "required": [ "body" ], "properties": { "body": { "not": { "const": "" } } } }, "then": { "required": [ "encoding" ] } }, { Petrie Expires 4 May 2027 [Page 190] Internet-Draft JSON vCon October 2026 "if": { "properties": { "encoding": { "enum": [ "base64url", "none" ] } }, "required": [ "encoding" ] }, "then": { "properties": { "body": { "type": "string" } } } } ], "$comment": "At least one of the dialog, sessions, attachme nt or analysis parameters SHOULD be present. An Analysis Object MUST NOT reference itself in the analysis paramete r; this is not enforced by this schema." }, "RedactedString": { "type": "object", "description": "Information about a substring of the vCon w hich was replaced by __REDACTED_REF_#", "required": [ "ref" ], "properties": { "ref": { "type": "integer", "minimum": 1, "maximum": 99999, "description": "Reference number of the redacted substr ing" }, "type": { "type": "string", "description": "Type of information redacted: GOVT_ID_N UM, FIN_ID_NUM, MED_ID_NUM, BIOMETRIC, AUTH_DATA, CON TACT_INFO, LOC_INFO, EMPL_INFO, BELIEF_INFO, UNSPECIF IED or another value; absent means UNSPECIFIED" Petrie Expires 4 May 2027 [Page 191] Internet-Draft JSON vCon October 2026 }, "orig": { "type": "string", "description": "Original, unredacted value of the subst ring" } }, "$comment": "That each __REDACTED_REF_# substring has a Red acted_string Object with a matching ref is not enforced b y this schema." }, "RedactedSegments": { "type": "object", "description": "An audiovisual segment of a recording which was redacted", "required": [ "start", "end" ], "properties": { "start": { "type": "string", "format": "date-time", "description": "Start time of the redaction in RFC3339 format" }, "end": { "type": "string", "format": "date-time", "description": "End time of the redaction in RFC3339 fo rmat" }, "parties": { "type": "array", "items": { "type": "integer", "minimum": 0 }, "description": "Indices of the parties whose content wa s redacted" } }, "$comment": "TODO: should use duration instead of end?" } }, "not": { "required": [ "redacted_from", Petrie Expires 4 May 2027 [Page 192] Internet-Draft JSON vCon October 2026 "amended_from" ], "$comment": "The redacted_from and amended_from parameters ar e mutually exclusive" }, "allOf": [ { "if": { "anyOf": [ { "required": [ "dialog" ], "properties": { "dialog": { "minItems": 1 } } }, { "required": [ "events" ], "properties": { "events": { "minItems": 1 } } } ] }, "then": { "required": [ "sessions" ], "properties": { "sessions": { "minItems": 1 } }, "$comment": "At least one Session Object MUST exist if th e events array or the dialog array contain Objects" } } ], "$comment": "This schema is permissive: parameters and type val ues which are not defined in RFCXXXX do not cause validation to fail. At least one of the parties, dialog, analysis or att Petrie Expires 4 May 2027 [Page 193] Internet-Draft JSON vCon October 2026 achments parameters SHOULD be present. SHOULD-level statement s are not enforced by this schema. Index values are not check ed against the size of the array which they reference." } Appendix D. vCon CDDL This CDDL for vCon core is provided as informational. The text in sections 1-6 of this document define the normative definition of the vCon CDDL. If the CDDL provided below differs or conflicts from that in the text of the above sections, the text should be taken as the definitive definition and the CDDL below should be consider incorrect. The CDDL is strict: parameters and type values which are not defined in this document cause validation to fail unless the CDDL for the vCon extension which defines them is also used. Failing validation against this CDDL is not by itself a reason to reject a vCon (see Section 2.5). ; CDDL for the JSON vCon - Conversation Data Container ; Generated from the prose of draft-ietf-vcon-vcon-core ; (syntax version 0.5.0). ; The prose of the draft is normative. ; This CDDL is informative. ; Constraints that cannot be expressed in CDDL are stated in ; comments. ; ; This CDDL follows the text of the draft at commit 7f1fee9. ; ; This CDDL is strict. A parameter or value which is not defined ; here does not validate, unless the CDDL of the vCon extension ; which defines it is used together with this CDDL. Failing ; validation against this CDDL is not by itself a reason to ; reject a vCon. The draft defines how parameters and values ; which are not recognized are handled (see Extending vCon). ; ; Extension points ; ---------------- ; The extension points are CDDL sockets (RFC 8610, Section 3.9). ; ; 1. Adding parameters to an Object. ; ; Each Object ends with a group socket named for that Object. ; A vCon extension adds parameters to that Object only, with for ; example: ; ; $$party-ext //= ( ? example_parameter: tstr ) ; ; The "*" before each of these sockets allows the socket to match Petrie Expires 4 May 2027 [Page 194] Internet-Draft JSON vCon October 2026 ; nothing, so that this CDDL can be used with no extensions, and ; allows more than one extension to add to the same Object. ; ; 2. Adding a value which selects other parameters. ; ; The dialog-type-ext socket adds a Dialog Object type along with ; the parameters which apply to that type. The event-type-ext ; socket does the same for an Event Object type. An Event Object ; type defined in a vCon extension may allow the value of its ; dialog parameter to be an array of Dialog Object indices ; (dialog_index_or_list_type). The encoding-ext ; socket adds an encoding value along with the form of the body ; parameter for that encoding. For example: ; ; $$dialog-type-ext //= example_dialog_type ; example_dialog_type = ( ; type: "example", ; dialog_common_type, ; ? example_parameter: tstr, ; * $$example-dialog-ext ; ) ; ; $$encoding-ext //= ( encoding: "example", body: tstr ) ; ; A group which defines a new type is best given a rule name and ; ended with a socket of its own, as above, so that another ; extension can add parameters to that type. ; ; 3. Adding a value to a list of values. ; ; The disposition-ext socket adds a disposition value. The ; session-reference-type-ext socket adds a Session_Reference ; Object type value. For example: ; ; $disposition-ext /= "example" ; ; The sockets in 2 and 3 are alternatives in a choice. They have ; no "*" and are not to be given one. ; ; The header objects of the signed and encrypted forms have no ; socket. They are open, as any JWS or JWE header parameter MAY ; be present in them. ; A vCon JSON object is in one of three forms: unsigned, signed ; (JWS) or encrypted (JWE). vcon = unsigned_vcon_type / signed_vcon_type / encrypted_vcon_type Petrie Expires 4 May 2027 [Page 195] Internet-Draft JSON vCon October 2026 ; Unsigned Form of vCon Object ;_____________________________ ; Not enforced by this CDDL: ; - At least one Session Object MUST exist if the events array or ; the dialog array contain Objects. ; - An index MUST refer to an Object which exists in the array ; that it indexes. unsigned_vcon_type = { ; DEPRECATED ? "vcon": "0.5.0", uuid: uuid_value_type, ? extensions: [* tstr], ? critical: [* tstr], created_at: date_type, ? updated_at: date_type, ? subject: tstr, ; redacted_from and amended_from are mutually exclusive ? ( redacted_from: redacted_from_object_type // amended_from: amended_from_object_type ), ? redacted_strings: [* redacted_string_object_type], ; at least one of parties, dialog, analysis or attachments ; SHOULD be present ? sessions: [* session_object_type], ? parties: [* party_object_type], ? events: [* event_object_type], ? dialog: [* dialog_object_type], ? analysis: [* analysis_object_type], ? attachments: [* attachment_object_type], * $$vcon-ext } ; Object and multi-parameter types ;_________________________________ ; Redacted_from Object ; uuid SHOULD be provided. ; content_hash MUST be provided if url is provided. ; type has the same set of values as the type parameter of the ; Redacted_string Object. redacted_from_object_type = { ? uuid: uuid_value_type, type: tstr, ? ( url: url_value_type, content_hash: content_hash_type ), * $$redacted-from-ext } Petrie Expires 4 May 2027 [Page 196] Internet-Draft JSON vCon October 2026 ; Amended_from Object ; uuid is optional only if an external reference is provided. ; content_hash MUST be provided if url is provided. amended_from_object_type = { ? uuid: uuid_value_type, ? ( url: url_value_type, content_hash: content_hash_type ), * $$amended-from-ext } ; Redacted_string Object ; Not enforced by this CDDL: ; - Each "__REDACTED_REF_#" substring in the vCon has a ; Redacted_string Object with a matching ref value. redacted_string_object_type = { ref: 1..99999, ; type is an extensible string enumeration: "GOVT_ID_NUM", ; "FIN_ID_NUM", "MED_ID_NUM", "BIOMETRIC", "AUTH_DATA", ; "CONTACT_INFO", "LOC_INFO", "EMPL_INFO", "BELIEF_INFO", ; "UNSPECIFIED" or another value; absent is "UNSPECIFIED" ? type: tstr, ? orig: tstr, * $$redacted-string-ext } ; Session Object ; A Session Object with no parameters is permitted. ; start and duration define the time period of the session, ; which need not include the entire time period of its Dialog ; and Event Objects. session_object_type = { ; start SHOULD be present ? start: date_type, ? duration: duration_type, ; parties SHOULD be present; the first party is the implied ; originator of the session ? parties: [* party_index_type], ; only provided if the first party in parties is not the ; originator ? originator: party_index_type, ; a single SessionId Object ? session_id: session_id_object_type, ? sessions: [* session_reference_object_type], ? dialog: [* dialog_index_type], * $$session-ext } ; Session_Reference Object Petrie Expires 4 May 2027 [Page 197] Internet-Draft JSON vCon October 2026 session_reference_object_type = { session: session_index_type, type: session_reference_type_value_type, ? description: tstr, * $$session-reference-ext } session_reference_type_value_type = "child" / "peer" / "precursor" / "breakout" / $session-reference-type-ext ; Event Object ; The type selects which parameters apply (see Event Object ; Parameter Applicability by Type). ; A vCon extension adds an Event Object type through the ; event-type-ext socket and adds parameters to all Event Object ; types through the event-ext socket. ; Not enforced by this CDDL: ; - An Event Object applies only to the Session Objects listed in ; its sessions parameter, and not to their child or parent ; Session Objects unless they are also listed. event_object_type = { ( event_party_type // event_key_type // event_consultation_start_type // event_blind_transfer_type // event_consultative_transfer_type // event_transfer_abandoned_type // event_channel_contributors_type // $$event-type-ext ), * $$event-ext } ; Parameters common to the party and key event types event_common_type = ( "time": date_type, sessions: session_index_or_list_type, party: party_index_type, ; dialog SHOULD NOT be present ? dialog: dialog_index_type ) ; Parameters common to the transfer event types ; sessions is a single index which references the Session Object ; for the original call, and party references the Transferor. event_transfer_common_type = ( "time": date_type, sessions: session_index_type, party: party_index_type, Petrie Expires 4 May 2027 [Page 198] Internet-Draft JSON vCon October 2026 ; dialog SHOULD NOT be present ? dialog: dialog_index_type ) ; Party event types event_party_type = ( type: "join" / "drop" / "hold" / "unhold" / "mute" / "unmute", event_common_type ) ; Key event types event_key_type = ( type: "keydown" / "keyup", event_common_type, button: tstr ) ; Transfer event types ; transferee and transfer_target reference Party Objects. ; consultation and target_session reference Session Objects. event_consultation_start_type = ( type: "consultation-start", event_transfer_common_type, transferee: party_index_type, transfer_target: party_index_type, consultation: session_index_type ) event_blind_transfer_type = ( type: "blind-transfer", event_transfer_common_type, transferee: party_index_type, transfer_target: party_index_type, target_session: session_index_type ) event_consultative_transfer_type = ( type: "consultative-transfer", event_transfer_common_type, transferee: party_index_type, transfer_target: party_index_type, consultation: session_index_type, target_session: session_index_type ) event_transfer_abandoned_type = ( type: "transfer-abandoned", event_transfer_common_type, Petrie Expires 4 May 2027 [Page 199] Internet-Draft JSON vCon October 2026 transferee: party_index_type, ? transfer_target: party_index_type, ? consultation: session_index_type ) ; Channel contributors event type ; sessions and party MUST NOT be present. The sessions of the ; event are the Session Objects which reference its Dialog ; Object. ; Not enforced by this CDDL: ; - dialog MUST reference a "recording" type Dialog Object. ; - channel MUST be less than the number of channels in the ; recording. event_channel_contributors_type = ( type: "channel-contributors", "time": date_type, dialog: dialog_index_type, channel: uint, ; absent or null: no party contributes to the channel ? contributors: party_index_type / [* party_index_type] / null ) ; Party Object ; A Party Object with no parameters is permitted. party_object_type = { ? tel: tstr, ? sip: tstr, ? stir: tstr, ? mailto: tstr, ? name: tstr, ? did: tstr, ? validation: tstr, ? gmlpos: tstr, ? civicaddress: civicaddress_type, ; a free form unique identifier for the participant; ; not constrained to UUID syntax ? uuid: tstr, ; type SHOULD be "person", "bot" or "organization" ? type: tstr, ? org: tstr, ? dept: tstr, * $$party-ext } ; Civicaddress Object civicaddress_type = { ? country: tstr, Petrie Expires 4 May 2027 [Page 200] Internet-Draft JSON vCon October 2026 ? a1: tstr, ? a2: tstr, ? a3: tstr, ? a4: tstr, ? a5: tstr, ? a6: tstr, ? prd: tstr, ? pod: tstr, ? sts: tstr, ? hno: tstr, ? hns: tstr, ? lmk: tstr, ? loc: tstr, ? flr: tstr, ? nam: tstr, ? pc: tstr, * $$civicaddress-ext } ; Dialog Object ; The type selects which parameters apply (see Dialog Object ; Parameter Applicability by Type). ; A placeholder Dialog Object contains only the type parameter and, ; for the "incomplete" type, the required disposition parameter. ; A placeholder Dialog Object MUST be of type "recording" if the ; call was set up, or of type "incomplete" if it was not. ; An empty Dialog Object has no type and no meaning; it holds a ; position in the dialog array. ; A vCon extension adds a Dialog Object type through the ; dialog-type-ext socket and adds parameters to all Dialog Object ; types through the dialog-ext socket. dialog_object_type = { ( dialog_recording_type // dialog_text_type // dialog_incomplete_type // $$dialog-type-ext ), * $$dialog-ext } / empty_dialog_object_type empty_dialog_object_type = {} ; Parameters common to all Dialog Object types dialog_common_type = ( ; start SHOULD be present; MAY be omitted if not known ? start: date_type, ? duration: duration_type, ? session_id: session_id_parameter_type, ? application: tstr Petrie Expires 4 May 2027 [Page 201] Internet-Draft JSON vCon October 2026 ) dialog_recording_type = ( type: "recording", dialog_common_type, dialog_media_based_type ) dialog_text_type = ( type: "text", dialog_common_type, dialog_media_based_type ) ; Parameters of the "recording" and "text" type Dialog Objects dialog_media_based_type = ( ; parties SHOULD be present ? parties: dialog_parties_type, ; mediatype MUST be present for inline content; not required ; when Dialog Content is absent ? mediatype: media_type_value_type, ? filename: tstr, ? message_id: tstr, ; disposition SHOULD NOT be present ? disposition: disposition_value_type, ; redacted_segments SHOULD NOT be present in "text" type ; Dialog Objects ? redacted_segments: [* redacted_segments_object_type], ; Dialog Content SHOULD be present; ; body or url MAY be absent if redacted ? file_content_type ) ; Redacted_segments Object ; TODO: should use duration instead of end? redacted_segments_object_type = { start: date_type, end: date_type, ? parties: [* party_index_type], * $$redacted-segments-ext } ; mediatype, filename, message_id, redacted_segments and Dialog ; Content MUST NOT be present in "incomplete" type Dialog ; Objects. dialog_incomplete_type = ( type: "incomplete", dialog_common_type, Petrie Expires 4 May 2027 [Page 202] Internet-Draft JSON vCon October 2026 ? parties: dialog_parties_type, ; "failed" SHOULD be used when the reason is not known disposition: disposition_value_type ) ; Attachment Object attachment_object_type = { ? purpose: tstr, start: date_type, party: party_index_type, ; at least one of dialog or session MUST be present ( ( dialog: dialog_index_type, ? session: session_index_or_list_type ) // session: session_index_or_list_type ), ; mediatype MUST be present for inline content; not required ; when Attachment Content is absent ? mediatype: media_type_value_type, ? filename: tstr, ; Attachment Content SHOULD be present; ; body or url MAY be absent if redacted ? file_content_type, * $$attachment-ext } ; Analysis Object ; At least one of dialog, sessions, attachment or analysis SHOULD ; be present. ; An Analysis Object MUST NOT reference itself in the analysis ; parameter. This is not enforced by this CDDL. analysis_object_type = { ; type SHOULD be one of: "report", "sentiment", "summary", ; "transcript", "translation", "tts" type: tstr, ? dialog: dialog_index_or_list_type, ? sessions: session_index_or_list_type, ? attachment: attachment_index_or_list_type, ? analysis: analysis_index_or_list_type, ; mediatype SHOULD be present for inline content; when no ; media type is defined for the analysis data format, the ; vendor, product and schema parameters SHOULD identify the ; format instead ? mediatype: media_type_value_type, ? filename: tstr, vendor: tstr, ? product: tstr, ? schema: tstr, ; Analysis Content SHOULD be present; ; body or url MAY be absent if redacted Petrie Expires 4 May 2027 [Page 203] Internet-Draft JSON vCon October 2026 ? file_content_type, * $$analysis-ext } ; Inline Files and Externally Referenced Files ;_____________________________________________ ; When the url of externally referenced content has been ; redacted, the content_hash MAY remain without the url. file_content_type = ( inline_content_type // external_content_type // redacted_content_type ) ; body is any JSON value when encoding is "json"; ; otherwise body is a string. ; A vCon extension which adds an encoding value also defines the ; form of body for that encoding. inline_content_type = ( ( encoding: "json", body: any ) // ( encoding: "none" / "base64url", body: tstr ) // $$encoding-ext ) external_content_type = ( url: url_value_type, content_hash: content_hash_type ) redacted_content_type = ( content_hash: content_hash_type ) ; SessionId Object ; The empty object is the placeholder for a party with no session id. session_id_object_type = { ? "local": uuid_value_type, ? "remote": uuid_value_type } session_id_parameter_type = session_id_object_type / [* ( session_id_object_type / [* session_id_object_type] )] ; Basic types and single parameter types ;_______________________________________ ; RFC3339 date string Petrie Expires 4 May 2027 [Page 204] Internet-Draft JSON vCon October 2026 ; The pattern is in two parts only to keep the lines short. The ; first 19 characters are the date, "T" and the time. The rest is ; the optional fraction of a second and the time zone offset. date_type = date_and_time_type .and date_offset_type date_and_time_type = tstr .regexp "[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt][0-9]{2}:[0-9]{2}:[0-9]{2}.*" date_offset_type = tstr .regexp ".{19}([.][0-9]+)?([Zz]|[+-][0-9]{2}:[0-9]{2})" ; String token of the form: hash algorithm, "-", Base64Url encoded ; digest, e.g. "sha512-..." content_hash_value_type = tstr .regexp "[a-z0-9]+-[A-Za-z0-9_-]+" content_hash_type = content_hash_value_type / [* content_hash_value_type] ; Duration in seconds; MUST be non-negative duration_type = uint / float ; Dialog Object disposition values disposition_value_type = "no-answer" / "congestion" / "failed" / "busy" / "hung-up" / "voicemail-no-message" / $disposition-ext ; Media type of the form: type "/" subtype media_type_value_type = tstr .regexp "[A-Za-z0-9!#$&^_.+-]+/[A-Za-z0-9!#$&^_.+-]+(;.*)?" party_index_type = uint dialog_index_type = uint dialog_index_or_list_type = dialog_index_type / [* dialog_index_type] attachment_index_type = uint attachment_index_or_list_type = attachment_index_type / [* attachment_index_type] session_index_type = uint session_index_or_list_type = session_index_type / [* session_index_type] analysis_index_type = uint analysis_index_or_list_type = analysis_index_type / [* analysis_index_type] Petrie Expires 4 May 2027 [Page 205] Internet-Draft JSON vCon October 2026 ; Index or indices of parties; the nested array form is used for ; multi-channel recordings with one entry per channel; null is the ; placeholder for an unused channel. dialog_parties_type = party_index_type / [* ( party_index_type / [* party_index_type] / null )] ; UUID string uuid_value_type = tstr .regexp "[0-9a-fA-F]{8}(-[0-9a-fA-F]{4}){3}-[0-9a-fA-F]{12}" ; HTTPS URL url_value_type = tstr .regexp "https://.+" ; Signed Form of vCon Object ;___________________________ signed_vcon_type = { payload: base64url_value_type, signatures: [+ signature_object_type], * $$signed-ext } ; Signature Object signature_object_type = { header: signed_header_object_type, ; present when the JWS Protected Header is not empty ? protected: base64url_value_type, signature: base64url_value_type, * $$signature-ext } ; Header Object of the signed form ; MUST include at least one of x5c or x5u. ; Other JWS header parameters MAY be present. ; Not enforced by this CDDL, as the JWS Protected Header is an ; opaque string here: ; - alg MUST be present here or in the JWS Protected Header, and ; SHOULD be in the JWS Protected Header. ; - alg MUST NOT be "none" in the JWS Protected Header. ; - A header parameter MUST NOT be present in both the JWS ; Protected Header and the Header Object. signed_header_object_type = { ; SHOULD be "RS256"; MUST NOT be "none" ? alg: tstr .ne "none", ( ( x5c: [+ tstr], ? x5u: url_value_type ) // x5u: url_value_type ), ? uuid: uuid_value_type, ; SHOULD be provided Petrie Expires 4 May 2027 [Page 206] Internet-Draft JSON vCon October 2026 * tstr => any } ; Encrypted Form of vCon Object ;______________________________ ; Not enforced by this CDDL, as the JWE Protected Header is an ; opaque string here: ; - enc MUST be present in the JWE Protected Header or the ; Unprotected Object. ; - alg MUST be present in the JWE Protected Header, the ; Unprotected Object or the Header Object of each recipient. ; - A header parameter MUST NOT be present in more than one of ; those locations. encrypted_vcon_type = { ? protected: base64url_value_type, unprotected: unprotected_object_type, recipients: [+ recipient_object_type], iv: base64url_value_type, ciphertext: base64url_value_type, tag: base64url_value_type, ? aad: base64url_value_type, * $$encrypted-ext } ; Unprotected Object ; Other JWE header parameters MAY be present. unprotected_object_type = { ; cty SHOULD be "application/vcon" or "application/vcon+gzip" cty: tstr, ; enc SHOULD be "A256CBC-HS512" ? enc: tstr, ? alg: tstr, ? uuid: uuid_value_type, ; SHOULD be provided * tstr => any } ; Recipient Object ; A Recipient Object with no parameters is permitted. recipient_object_type = { ? header: recipient_header_object_type, ; present when the JWE Encrypted Key is not empty ? encrypted_key: base64url_value_type, * $$recipient-ext } ; Header Object of a recipient in the encrypted form ; Other JWE header parameters MAY be present. Petrie Expires 4 May 2027 [Page 207] Internet-Draft JSON vCon October 2026 recipient_header_object_type = { ? alg: tstr, ; SHOULD be "RSA-OAEP" * tstr => any } ; Base64Url encoded string base64url_value_type = tstr .regexp "[A-Za-z0-9_-]+" Appendix E. vCon Extension Template A template for writing a vCon extension Internet-Draft is provided in kramdown-rfc markdown. It contains the sections required of an extension document in Extending vCon (Section 2.5), along with JSON Schema and CDDL appendices. The template can be downloaded from: https://raw.githubusercontent.com/ietf-wg-vcon/draft-ietf-vcon-vcon- core/refs/heads/main/template-draft-vcon-xxxx-extension.md Acknowledgments * Thank you to Thomas McCarthy-Howe for inventing the concept of a vCon and the many discussions that we had while this concept was developed into reality. * Thank you to Jonathan Rosenberg and Andrew Siciliano for their input to the vCon container requirements in the form of I-D: draft-rosenberg-vcon-cc-usecases and for the data structure ideas to create Session Objects instead of recording-sets type Dialogs and elevating party_history event Objects into the Event Object array at the top level and the contribution for tagging redactions and enumerating the vCon redaction techniques possible in vCon. * Thank you to Rohan Mahy for his help in exploring the CDDL schema and CBOR format for vCon and testing out the extension framework with MIME. * The examples in this document were generated using the command line interface (CLI) from the py-vcon [PY-VCON] python open source project. * Thank you to Steve Lasker for formatting and spelling edits. * Thank you to Mike Jones for input and help media types, version and helping to form the extension framework. * Thank you to Jonathan Lennox for numerous inputs including separate single channel recordings per party and the extension framework. Petrie Expires 4 May 2027 [Page 208] Internet-Draft JSON vCon October 2026 * Thank you to Marc Petit-Huguenin for sorting out session_id. * Thank you to Rob Sliwa for helping to review and test the JSON Schema. * Thank you to Mike Jones, Richard Barnes and Mike Ounsworth for their help with providing an approach to maintaining integrity for long term storage of signed vCons. * Thank you to Scott Godin for several thorough reviews and the idea and help on designing the multi-segment recording metadata concept for recording-set. * Thank you to Henk Birkholz for identifying a few ambiguities in the syntax and a few missing IANA entries. * Thank you to Eugene Tcipnjatov for pushing me to solve the recording topology case where the contributors change over time. Author's Address Daniel G Petrie SIPez LLC Email: dan.ietf@sipez.com Petrie Expires 4 May 2027 [Page 209]