[Trans] On version expectations of trans participants

Benjamin Kaduk <kaduk@MIT.EDU> Mon, 23 March 2015 02:59 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BA51A8797 for <trans@ietfa.amsl.com>; Sun, 22 Mar 2015 19:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_WaU5dcm7Zk for <trans@ietfa.amsl.com>; Sun, 22 Mar 2015 19:58:59 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BF21A8791 for <trans@ietf.org>; Sun, 22 Mar 2015 19:58:59 -0700 (PDT)
X-AuditID: 1209190f-f79d16d000000d3d-ec-550f8171fd55
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B1.21.03389.1718F055; Sun, 22 Mar 2015 22:58:57 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2N2wvbs005258 for <trans@ietf.org>; Sun, 22 Mar 2015 22:58:57 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2N2wtF8031138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <trans@ietf.org>; Sun, 22 Mar 2015 22:58:56 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2N2wssI015725; Sun, 22 Mar 2015 22:58:54 -0400 (EDT)
Date: Sun, 22 Mar 2015 22:58:54 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: trans@ietf.org
Message-ID: <alpine.GSO.1.10.1503222253110.22210@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixCmqrFvYyB9q8HeyicXaxxdZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0TthE2PBEo6Khx9msjYw3mTrYuTkkBAwkZhy7h6ULSZx4d56 IJuLQ0hgMZPE5uf7GCGcY4wSl162s4BUCQlcZ5J4ej0GItHAKDHjSzcrSIJFQFti58ppjCA2 m4CKxMw3G8HGiggISbSeeMkEYgsLmEl8PnEBLM4r4Cjxfs5hsF5RAR2J1funsEDEBSVOznwC ZjMLaEksn76NZQIj3ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaU bmIEh5Mk/w7GbweVDjEKcDAq8fBWBPCHCrEmlhVX5h5ilORgUhLl9bYDCvEl5adUZiQWZ8QX leakFh9ilOBgVhLhjbUHyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAo SfDKNAA1ChalpqdWpGXmlCCkmTg4QYbzAA23AKnhLS5IzC3OTIfIn2JUlBLnlQBJCIAkMkrz 4Hph8f6KURzoFWHeepAqHmCqgOt+BTSYCWjwuXw+kMEliQgpqQZG/eJ/Vjwnn1h9ui5ddTLT KUT6oHWT1FGfNDtVl00Ln/Yt2yxpP+F53apWJaF1k9eyrP6wPGHK0i+7Oa3Ufmke5Gx98MRv 4raNp/KzdCdcTV45Pz+5YY9T0r3Mm2WNc655slXbf83zFRRR2VSYUpHw54I4T+A/HV/L0x4O eZPOfYgu8Emc/KhdiaU4I9FQi7moOBEANIoNB9ICAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/WPRn5goQqdYIxvux9QDnjIHmH-I>
Subject: [Trans] On version expectations of trans participants
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 02:59:00 -0000

My apologies if we've covered this already; I think I may have mentioned
it in a larger email and it got glossed over.

In at least two documents we have phrases like "a compliant v1
implementation MUST NOT expect this [version field] to be 0 (i.e., v1)."

The word "expect" seems weird to me, somehow -- in a universe where v1 is
the only thin widely deployed, we should "expect" that responses will use
that version, in that it is the most likely occurrence.  What we are
trying to prevent is the case where implementations assume that the
version field (or really, the version of the message they are processing)
matches the version of the implementation without validating that
assumption.  Do we want to say instead something like "compliant v1
implementations MUST validate the version field while processing messages
and handle inputs from versions other than v1" or "a compliant v1
implementation MUST NOT assume this field is 0 (i.e., v1) without
validating the version field"?

Is this too trivial an issue to worry about?

-Ben