[tap] Capture, not chatter [was: Weird thought for the day: "skip 71 - reason"]

Aristotle Pagaltzis <pagaltzis@gmx.de> Mon, 15 March 2010 13:06 UTC

Return-Path: <pagaltzis@gmx.de>
X-Original-To: tap@core3.amsl.com
Delivered-To: tap@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 9E9323A6765 for <tap@core3.amsl.com>; Mon, 15 Mar 2010 06:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.649
X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7WratlxzNwbF for <tap@core3.amsl.com>; Mon, 15 Mar 2010 06:06:49 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net []) by core3.amsl.com (Postfix) with SMTP id 2B03D3A6A0F for <tap@ietf.org>; Mon, 15 Mar 2010 06:02:33 -0700 (PDT)
Received: (qmail invoked by alias); 15 Mar 2010 13:02:39 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [] by mail.gmx.net (mp055) with SMTP; 15 Mar 2010 14:02:39 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1/CRP9s2o/CMF6hxe9+e+UEdq04YORsEdkfqtLkVg NodzjLJfllmLJC
Date: Mon, 15 Mar 2010 14:02:15 +0100
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
To: tap@ietf.org
Message-ID: <20100315130215.GE27881@klangraum.plasmasturm.org>
Mail-Followup-To: tap@ietf.org
References: <411886.95806.qm@web65707.mail.ac4.yahoo.com> <D9F21163-EC5A-4023-BD5D-9FCF60A86FBE@hexten.net> <91241.45851.qm@web65716.mail.ac4.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <91241.45851.qm@web65716.mail.ac4.yahoo.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.68000000000000005
Subject: [tap] Capture, not chatter [was: Weird thought for the day: "skip 71 - reason"]
X-BeenThere: tap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Test Anything Protocol WG discussions <tap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tap>, <mailto:tap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tap>
List-Post: <mailto:tap@ietf.org>
List-Help: <mailto:tap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tap>, <mailto:tap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2010 13:06:50 -0000

* Ovid <publiustemp-tapx@yahoo.com> [2010-03-05 17:05]:
> I think a TAP consumer could conceivably indicate to the
> producer which version of TAP it supports. The produce is not
> bound by this and should produce TAP compatible with version
> 13. If not version is specified, again, 13 (if 14 is not
> backwards compatible). Otherwise, if the producer and consumer
> can produce/understand richer TAP levels, we have a win.

I really dislike the idea of introducing any sort of handshake.

TAP works in environments where emitter and consumer are removed
far enough from each other that no handshake is possible, and it
should continue to be able to work in those. It also works for
environments where it is too difficult to implement any sort of
protocol in the emitter (eg. on a microcontroller).

TAP should let the emitter be as near braindead as possible. The
consumer is the place to burden with any resulting complexity.
The consumer can be assumed to run in such an environment lavish
with CPU and memory resources that the emitter cannot.

This is connected with the “desciptive not prescriptive” point
too, in that TAP should leave the consumer’s job to the consumer,
providing pure data capture, as comprehensive as the emitter can
manage and afford.

Aristotle Pagaltzis // <http://plasmasturm.org/>