-
Notifications
You must be signed in to change notification settings - Fork 3
Chat Definitions #80
Chat Definitions #80
Changes from 11 commits
cd581a8
58bfa54
da323c9
f9b9464
c02bdb3
6a62b71
540607c
cf24695
1dd9740
b3a724a
8e832ee
887318e
cb5f1b6
2c69efa
10ff3a3
2ef001f
538e116
b1b7237
3d1d425
a28cc5b
ace239b
2c325f5
d3b5740
d2a3f0e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,92 @@ | ||||||||||
| --- | ||||||||||
| title: CHAT-DEFINITIONS | ||||||||||
| name: Shared definitions for Chat Protocols | ||||||||||
| category: Informational | ||||||||||
| tags: definitions, terminology, reference | ||||||||||
| editor: | ||||||||||
| contributors: | ||||||||||
| --- | ||||||||||
|
|
||||||||||
| ## Abstract | ||||||||||
|
|
||||||||||
| This specification establishes a common vocabulary and standardized definitions for terms used across chat protocol specifications. It serves as a normative reference to ensure consistent interpretation of terminology across application level specifications. | ||||||||||
|
|
||||||||||
| ## Background / Rationale / Motivation | ||||||||||
|
|
||||||||||
| Chat protocol specifications often employ similar terminology with subtle but important semantic differences. The absence of standardized definitions leads to ambiguity in specification interpretation and implementation inconsistencies across different protocol variants. | ||||||||||
|
|
||||||||||
| Establishing a shared definitions document provides several benefits: | ||||||||||
|
|
||||||||||
| 1. **Semantic Consistency**: Ensures uniform interpretation of common terms across multiple specifications | ||||||||||
| 2. **Implementation Clarity**: Reduces ambiguity for protocol implementers | ||||||||||
| 3. **Specification Quality**: Enables more precise and concise specification language through reference to established definitions | ||||||||||
| 4. **Ecosystem Coherence**: Promotes consistent understanding within the chat protocol ecosystem. | ||||||||||
|
|
||||||||||
| This specification provides normative definitions that other chat protocol specifications MAY reference to establish precise semantic meaning for common terminology. | ||||||||||
|
|
||||||||||
| ## Theory / Semantics | ||||||||||
|
|
||||||||||
| ### Definition Categories | ||||||||||
|
|
||||||||||
| Terms are organized into the following categories for clarity and ease of reference: | ||||||||||
|
|
||||||||||
| - **Roles**: Defined entity types that determine how a participant behaves within a communication protocol. | ||||||||||
| - **Message Types**: Classifications and categories of protocol messages | ||||||||||
| - **Transports**: Abstract methods of transmitting payloads | ||||||||||
| ## Definitions | ||||||||||
|
jazzz marked this conversation as resolved.
|
||||||||||
|
|
||||||||||
| ### Accounts + Identity | ||||||||||
|
jazzz marked this conversation as resolved.
Outdated
|
||||||||||
|
|
||||||||||
| ### Roles | ||||||||||
|
|
||||||||||
| **Sender**: A client which is pushing a payload on to the network, to one or more recipients. | ||||||||||
|
|
||||||||||
| **Recipient**: A client which is the intended receiver of a payload. In a group context there maybe multiple recipients | ||||||||||
|
|
||||||||||
| **Participant**: A generic term for the rightful members of a conversation. Senders and Recipients are roles that participants can hold. | ||||||||||
|
|
||||||||||
| ### Message Types | ||||||||||
|
|
||||||||||
| **Payload**: The encoded bytes as produced by a chat protocol. The term `message` is avoided due to conflicts with other layers. | ||||||||||
|
|
||||||||||
| **Frame**: A data structure which is required to implement a chat protocol. Frames are used to disambiguate the objects defined by chat protocols from transport 'messages' and application `content`. | ||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would be good to have some examples about
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Absolutely - Examples though are provided in the conversation specifications. This definitions spec is intended to only define the terms used to provide consistent vocabulary. Frames definitions are arbitrary, and defined by their use case. The different in the 3 terms is the intent and purpose of the "Message".
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Updated |
||||||||||
|
|
||||||||||
| **Content**: The data that is intended for end-users or applications. Chat protocols transmit and route content between clients. | ||||||||||
|
|
||||||||||
| **Content Type**: The structured format of content. These data structures represent specific encodings of Text, Image, Audio data. | ||||||||||
|
jazzz marked this conversation as resolved.
Outdated
|
||||||||||
|
|
||||||||||
| **Delivery Acknowledgement**: A notification from a receiving client to sender that their message was successfully received. While similar to a read-receipt delivery acknowledgements differ in that the acknowledgement originates based on the client, where read-receipts are fired when they are displayed to a user. | ||||||||||
|
jazzz marked this conversation as resolved.
Outdated
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An Invite requires a dedicated frame to be a sent which contains all the required information. A delivery acknowledgement does not. It is a state change - rather than a "message" type. Is this any better? Suggestions @osmaczko ?
Suggested change
|
||||||||||
|
|
||||||||||
| **Invite**: An protocol message from one client to another to establish a communication channel. Invites notify a client that someone wants to communicate with them, and provides the required information to do so. | ||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe use |
||||||||||
|
|
||||||||||
|
|
||||||||||
| ### Transports | ||||||||||
|
|
||||||||||
| **Out-of-Band**: The transfer of information using a channel separate from the defined protocol channel. Data sent Out-of-Band is transmitted using an undefined mechanism. This is used when protocols requires information to be shared with another entity, but it does not describe how that should occur. The responsibility to define how this occurs is the implementer or other protocols in the suite. | ||||||||||
|
jazzz marked this conversation as resolved.
Outdated
|
||||||||||
|
|
||||||||||
|
|
||||||||||
| ### Software Entities | ||||||||||
|
|
||||||||||
| **Client**: Software that implements a chat protocol. It is responsible for establishing and maintaining communication with the underlying network, performing protocol operations (e.g., encryption, key management, frame generation), and exposing an interface for higher-level software. A Client serves as the technical component that provides messaging capabilities to Applications. | ||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The term client seems not clear, maybe just use chat-sdk implementation here.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ChatSDK Implementation is a different concept. The Implementation is a library, the Client is an "Component" of an architecture. I'll reword the definition to reflect that. |
||||||||||
|
|
||||||||||
| **Application**: Software that integrates with a Client in order to send and receive content. | ||||||||||
|
|
||||||||||
|
|
||||||||||
|
|
||||||||||
| ## Wire Format Specification / Syntax | ||||||||||
|
|
||||||||||
| This specification does not define wire format elements. All definitions are semantic and apply to the interpretation of terms used in other specifications that do define wire formats. | ||||||||||
|
|
||||||||||
| ## Security/Privacy Considerations | ||||||||||
|
|
||||||||||
| This specification defines terminology only and does not introduce security or privacy considerations beyond those present in specifications that reference these definitions. | ||||||||||
|
|
||||||||||
| The definitions provided in this specification do not alter the security or privacy properties of implementations that adopt the defined terminology. | ||||||||||
|
|
||||||||||
| ## Copyright | ||||||||||
|
|
||||||||||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||||||||||
|
|
||||||||||
| ## References | ||||||||||
|
|
||||||||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||||||||
Uh oh!
There was an error while loading. Please reload this page.