Re: [tap] [offlist] Re: Parse error vs failure

Aristotle Pagaltzis <pagaltzis@gmx.de> Sun, 01 February 2009 08:58 UTC

Return-Path: <tap-bounces@ietf.org>
X-Original-To: tap-archive@ietf.org
Delivered-To: ietfarch-tap-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DB33A67B0; Sun, 1 Feb 2009 00:58:16 -0800 (PST)
X-Original-To: tap@core3.amsl.com
Delivered-To: tap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1133A6994 for <tap@core3.amsl.com>; Sun, 1 Feb 2009 00:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpE-1oAmhmgt for <tap@core3.amsl.com>; Sun, 1 Feb 2009 00:58:14 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 67E713A67B0 for <tap@ietf.org>; Sun, 1 Feb 2009 00:58:13 -0800 (PST)
Received: (qmail invoked by alias); 01 Feb 2009 08:57:53 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp009) with SMTP; 01 Feb 2009 09:57:53 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX18dGOoG5GMd9A00ZVvcca1gX9w/OJQll+njdDz3ff ogygZdgXcAb6Ll
Date: Sun, 01 Feb 2009 09:57:41 +0100
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
To: tap@ietf.org
Message-ID: <20090201085741.GA18834@klangraum.plasmasturm.org>
Mail-Followup-To: tap@ietf.org
References: <20090131213720.GB30031@klangraum.plasmasturm.org> <4984D8F4.1080806@pobox.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4984D8F4.1080806@pobox.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.71
Subject: Re: [tap] [offlist] Re: Parse error vs failure
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/pipermail/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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: tap-bounces@ietf.org
Errors-To: tap-bounces@ietf.org

* Michael G Schwern <schwern@pobox.com> [2009-02-01 00:05]:
> Aristotle Pagaltzis wrote:
> > Basically. I think we should differentiate between
> > syntactical and semantic errors.
>
> Assuming a semantic error is treated as a failure, I'll take
> that as a yes.

Yes. :-)

I just didn’t quite like the “failure-with-warning” term: it
feels a bit too prescriptive. In practice most processors will
treat semantic errors that way, but I’d prefer to do the same as
the Atom WG, where we said we just tell you *exactly* what the
bits mean but what to do with them is up to you.

Although I guess “failure” can be seen as merely a meaning for
the stream as a whole, in which case “failure with warning” would
be another, in which case this all would be mere nitpicking. I
don’t care about the precise terminology though, as long as the
principle is kept in mind: don’t prescribe processor behaviour,
just describe document meaning.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
_______________________________________________
tap mailing list
tap@ietf.org
https://www.ietf.org/mailman/listinfo/tap