[Agentproto] Re: Implementation evidence for a minimal preservation requirement
Ali Toygar Abak <founder@phionyx.ai> Mon, 31 August 2026 16:03 UTC
Return-Path: <founder@phionyx.ai>
X-Original-To: agentproto@mail2.ietf.org
Delivered-To: agentproto@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6B7C0132579BA for <agentproto@mail2.ietf.org>; Mon, 31 Aug 2026 09:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1788192196; bh=ir/YPG+DQ3Jh3s5o523QEedioj77rcoQFj0pnSnrT+4=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=PfNN0jSOsiPOiQnrPceaqRYdEXDdrNAZjm/qyKWfO9NRhrGRbaCegq5UQ650yoIxk 9OyZoglhPjtisdfWginhxUwSHuURA53AoWJLHilJAt6oXzoW/GEnen+Km3sLYcaXN1 d7JHmIcNBNgcDF1/QP7Dru9CfAIX3C0+YT3pGCKs=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=phionyx.ai
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQhxmdXZX208 for <agentproto@mail2.ietf.org>; Mon, 31 Aug 2026 09:03:15 -0700 (PDT)
Received: from sender-op-o13.zoho.eu (sender-op-o13.zoho.eu [136.143.169.13]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 16886132579AE for <agentproto@ietf.org>; Mon, 31 Aug 2026 09:03:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1788192187; cv=none; d=zohomail.eu; s=zohoarc; b=J0VTZtnAjd2CcBh+bhcMjemFLkPQW82zDNyiNCQFkgYdQ7Ldube82x8iCFI4dfoh2amjCgvLgQ6f7hOXO2acznrrlFeD55X7I1Coq7HIRQE2N8IIQEWQGZkz/6ScMt4Hx8k8PZE9bWTxQIE4bj21RdYmtjST6gIvcrp1gcKyRA4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1788192187; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=ir/YPG+DQ3Jh3s5o523QEedioj77rcoQFj0pnSnrT+4=; b=WRotuo2UY3OJT0ZAeHhOS7Xt2ls2I89Y9Ok0kYHw5qZ3d133Vt28d0OrMo4m5Ecml0PycUIkv8mwvKB5CKx6UdZtpzoQot45Zp20u8yB8bUi2l7qmRzl6+JK1vNtKmwiDfaOnGy32K0FECx4/+aEEZ7kCfvWi9IzFlzUxL2Mu4Y=
ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=phionyx.ai; spf=pass smtp.mailfrom=founder@phionyx.ai; dmarc=pass header.from=<founder@phionyx.ai>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1788192187; s=zmail; d=phionyx.ai; i=founder@phionyx.ai; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:Subject:Subject:MIME-Version:Content-Type:Reply-To; bh=ir/YPG+DQ3Jh3s5o523QEedioj77rcoQFj0pnSnrT+4=; b=Vhw4dpvfumZUM9+2B3GQulshr7bAyBkQrpo5hWfCtr7ubxAZRDO33xOx3bdgYIUT TMP2BID8FA6w7R0DAuZ90jlOYdw1IANGazu3n77HLSWXEULYENROSGvEC3hgbC6QVtT mrM4q3rGdfeYCPtQRddCqBnGm+aKuCaxrGRS31Xg=
Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1788192187383585.7323717466923; Mon, 31 Aug 2026 18:03:07 +0200 (CEST)
Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1788192185507906.4480953781311; Mon, 31 Aug 2026 18:03:05 +0200 (CEST)
Date: Mon, 31 Aug 2026 19:03:05 +0300
From: Ali Toygar Abak <founder@phionyx.ai>
To: Sumit Ahuja <sumit=40mainlabs.ai@dmarc.ietf.org>
Message-Id: <1a0588f5c94.5728bb871654434.3070806160493277113@phionyx.ai>
In-Reply-To: <3B7FC4EE-0A72-448B-8C60-964146D14D2E@mainlabs.ai>
References: <178815806497.92417.4119928643128779643@kriyanative.com> <3B7FC4EE-0A72-448B-8C60-964146D14D2E@mainlabs.ai>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_5096955_993384046.1788192185492"
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Message-ID-Hash: ED44FLJUFBBGNGF6IYKJPE523GQJTWKR
X-Message-ID-Hash: ED44FLJUFBBGNGF6IYKJPE523GQJTWKR
X-MailFrom: founder@phionyx.ai
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: agentproto <agentproto@ietf.org>, nancysahu <nancysahu@kriyanative.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Agentproto] Re: Implementation evidence for a minimal preservation requirement
List-Id: Agent Communication Protocols <agentproto.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/agentproto/Vum-DPI6xfAnHYmv747qqoSHryU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/agentproto>
List-Help: <mailto:agentproto-request@ietf.org?subject=help>
List-Owner: <mailto:agentproto-owner@ietf.org>
List-Post: <mailto:agentproto@ietf.org>
List-Subscribe: <mailto:agentproto-join@ietf.org>
List-Unsubscribe: <mailto:agentproto-leave@ietf.org>
Hi Nancy, Sumit, Thank you both. Nancy — I understand the distinction: the charter bullet should stand or fall on its own wording, while the scenarios below are input to the later requirements work rather than criteria for the charter decision. Sumit — I think the ICMP analogy identifies a real gap in my non-claims sentence. Receipt and preservation of a distinction are not quite the same property: a protocol fact may be emitted with the correct distinction and still be suppressed, transformed, or collapsed before the party interpreting it sees it. I would therefore add the clause you suggested. With that change, the proposed bullet would read: “Identify the information that agent protocols need to preserve when a governance-relevant operation crosses a system or administrative boundary, including an operation or instruction identifier that remains stable for the relevant interaction, a binding to the governed input or action, and a source-attributable disposition or outcome state. The protocol should preserve distinctions among non-success and non-final states — for example, deny, defer, reject, timeout, unresolved, or indeterminate where applicable — rather than collapsing them into a generic result. The requirements will also state what those facts do not establish: preservation at one boundary does not by itself establish receipt or enforcement at another boundary, that the preserved distinction survived to the party reading it, an observed effect, completeness, or that an unrecorded event did not occur.” For the later requirements work, I think the following scenarios exercise the individual preservation properties and their limits without prescribing a receipt format, evidence serialization, audit mechanism, or particular implementation. Stable operation or instruction identity A governance-relevant operation crosses a system or administrative boundary and continues through the relevant interaction. The preserved protocol information should allow the same governed operation or instruction to remain identifiable across that boundary, rather than relying only on a session, agent, task, or workflow identifier that may also cover other operations. Binding to the governed input or action An operation or instruction identifier is preserved, but the governed input, parameters, or requested action are materially changed while retaining that identifier. The preservation requirement is not satisfied if the modified input or action can be treated as the originally governed one solely because the identifier remained unchanged. Source-attributable disposition or outcome Two different protocol participants could produce the same disposition or outcome for an otherwise identical operation. The preserved information should retain enough source attribution to distinguish which participant issued or reported the disposition or outcome. This identifies the source of the protocol fact; it does not by itself establish broader responsibility or accountability for the resulting action. Preservation of non-success and non-final state distinctions A governed operation is denied, deferred, rejected, times out, remains unresolved, or becomes indeterminate. Where those distinctions are applicable to the protocol, crossing the boundary should not collapse them into a generic success, generic failure, or absence of a result in a way that loses governance-relevant information. Preservation of the distinction through the path A source correctly preserves a governance-relevant distinction, such as defer rather than generic failure, but an intermediary suppresses, transforms, or collapses that distinction before it reaches the party interpreting the result. Preservation at the originating boundary alone should not establish that the distinction survived intact to the reader. Preservation at one boundary does not establish downstream receipt or enforcement System A preserves and sends the required information when an operation crosses a boundary, but there is no independent indication that System B received it or acted on it. The information preserved at System A’s boundary alone should not establish receipt by System B, nor that System B enforced the associated governance decision. A preserved disposition or outcome does not establish an observed effect A source-attributable disposition or outcome is preserved for an operation, but no independent observation of the corresponding downstream effect is available. The preserved protocol fact alone should not establish that the downstream or real-world effect occurred. Absence does not establish completeness or non-occurrence No preserved record is available for a particular event, state, or operation. That absence alone should not establish either that the available record is complete or that the unrecorded event did not occur. These are intended only to exercise the proposed information-preservation requirement and the limits stated in the bullet. They deliberately leave receipt semantics, evidence formats, audit semantics, completeness mechanisms, and other proof mechanisms to the appropriate downstream work. Best, Ali Toygar Abak Phionyx https://phionyx.ai From: Sumit Ahuja <sumit=40mainlabs.ai@dmarc.ietf.org> To: <agentproto@ietf.org> Cc: <founder@phionyx.ai>, <nancysahu@kriyanative.com> Date: Mon, 31 Aug 2026 18:42:59 +0300 Subject: [Agentproto] Re: Implementation evidence for a minimal preservation requirement Ali, Nancy, The list of non-success states has a precedent, and it carries a second lesson the text does not yet have. ICMP exists because IP could not say why a packet failed. RFC 792 gives Destination Unreachable a code set: net, host, protocol, port, fragmentation-needed. A sender acts differently on each. That is your bullet, from 1981. The second lesson cost more to learn. ICMP is advisory and can be filtered in transit. Where firewalls drop fragmentation-needed, path MTU discovery fails silently and the sender sees only loss. RFC 2923 documents it. The distinction was made correctly at the emitter and destroyed on the path. So a preserved distinction that is suppressed between emitter and reader is indistinguishable from one never made. Your non-claims list covers receipt, enforcement, observed effect and completeness. It does not cover this. Suggested addition to that sentence: preservation at one boundary does not establish that the preserved distinction survived to the party reading it. That is one clause, it names a failure with thirty years of operational history, and it does not touch the format question. Sumit P. Ahuja Main Labs On Mon, Aug 31, 2026 02:34 AM, Nancy Sahu <nancysahu= mailto:40kriyanative.com@dmarc.ietf.org > wrote: _______________________________________________ Agentproto mailing list -- mailto:agentproto@ietf.org To unsubscribe send an email to mailto:agentproto-leave@ietf.org Ali - short answers. Wording: yes. Placement: yes, and it is the better placement. Your bullet is under Use Cases, Gap Analysis and Requirements, not under the framework deliverable, so it does not depend on the framework evidence line surviving the scope thread. Duplicate of the sentences Nicholas posted: no. Yours says which facts a protocol may not throw away when an operation crosses a boundary. Theirs says that whatever evidence the framework specifies must state its own limits. If one is dropped the other still stands. Test cases: yes, please send them. For the requirements work though, not for the charter decision - the bullet should be accepted or rejected on its own words. Nancy Sahu kriya native _______________________________________________ Agentproto mailing list -- mailto:agentproto@ietf.org To unsubscribe send an email to mailto:agentproto-leave@ietf.org
- [Agentproto] Implementation evidence for a minima… Ali Toygar Abak
- [Agentproto] Re: Implementation evidence for a mi… Nancy Sahu
- [Agentproto] Re: Implementation evidence for a mi… Ali Toygar Abak
- [Agentproto] Re: Implementation evidence for a mi… Nancy Sahu
- [Agentproto] Re: Implementation evidence for a mi… Sumit Ahuja
- [Agentproto] Re: Implementation evidence for a mi… Ali Toygar Abak