From f07c5b170c1b70598e618339025a78570462e748 Mon Sep 17 00:00:00 2001 From: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com> Date: Thu, 5 Feb 2026 17:13:01 -0800 Subject: [PATCH] Apply suggestion from @igor-sirotin Co-authored-by: Igor Sirotin --- standards/application/chat-framework.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standards/application/chat-framework.md b/standards/application/chat-framework.md index d8fda70..f67ad69 100644 --- a/standards/application/chat-framework.md +++ b/standards/application/chat-framework.md @@ -113,7 +113,7 @@ The core of an initialization protocol is a defined location and procedure for r Many chat protocols choose to define the initialization protocol within the conversation protocol. This tight coupling produces two negative artifacts. - New conversation protocols must define and deploy there own initialization channels. Increasing overhead and adding complexity. -- New protocol upgrades then create partitions in the communication network, as older clients have no means of communicating with new clients. +- Protocol upgrades then create partitions in the communication network, as older clients have no means of communicating with new clients. Separating channel initialization from conversation flow allows multiple conversations to reuse the same initialization channel. This reduces effort for new conversation protocols, and is especially valuable when upgrading existing ones. Being independent the initialization pathway can persist across conversation versions. Even if an older client cannot parse new message types, it can still recognize their presence, adding observability.