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
- [tap] Parse error vs failure Michael G Schwern
- Re: [tap] Parse error vs failure Aristotle Pagaltzis
- Re: [tap] Parse error vs failure David E. Wheeler
- Re: [tap] Parse error vs failure Michael Peters
- Re: [tap] Parse error vs failure Steffen Schwigon
- Re: [tap] [offlist] Re: Parse error vs failure Aristotle Pagaltzis
- Re: [tap] Parse error vs failure Ovid
- Re: [tap] Parse error vs failure Steffen Schwigon
- Re: [tap] Parse error vs failure Aristotle Pagaltzis
- Re: [tap] Parse error vs failure Andy Armstrong
- Re: [tap] Parse error vs failure Andy Armstrong
- Re: [tap] Parse error vs failure Michael G Schwern
- Re: [tap] Parse error vs failure Steffen Schwigon