[APPS-REVIEW] IETF Review of rfc2446bis-07
Reinhold Kainhofer <reinhold@kainhofer.com> Mon, 08 September 2008 01:14 UTC
Return-Path: <apps-review-bounces@ietf.org>
X-Original-To: apps-review-archive@optimus.ietf.org
Delivered-To: ietfarch-apps-review-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3333A68EE; Sun, 7 Sep 2008 18:14:43 -0700 (PDT)
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F245A3A68EE for <apps-review@core3.amsl.com>; Sun, 7 Sep 2008 18:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 ifrWP+jHokZm for <apps-review@core3.amsl.com>; Sun, 7 Sep 2008 18:14:41 -0700 (PDT)
Received: from server.kainhofer.com (server.kainhofer.com [88.198.35.52]) by core3.amsl.com (Postfix) with ESMTP id 2777B3A6806 for <APPS-REVIEW@ietf.org>; Sun, 7 Sep 2008 18:14:36 -0700 (PDT)
Received: from einstein.lan (chello062178130194.6.13.tuwien.teleweb.at [62.178.130.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.kainhofer.com (Postfix) with ESMTP id C35B16EF16; Mon, 8 Sep 2008 03:14:34 +0200 (CEST)
From: Reinhold Kainhofer <reinhold@kainhofer.com>
Organization: Vienna University of Technology
To: Eric Burger <eburger@standardstrack.com>, ietf-calsify list <ietf-calsify@osafoundation.org>, APPS-REVIEW@ietf.org, Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 08 Sep 2008 03:14:35 +0200
User-Agent: KMail/1.9.10
MIME-Version: 1.0
Content-Type: Multipart/Mixed; boundary="Boundary-00=_7xHxICeqGLWTPkk"
Message-Id: <200809080314.35791.reinhold@kainhofer.com>
Subject: [APPS-REVIEW] IETF Review of rfc2446bis-07
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Applications Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
Sender: apps-review-bounces@ietf.org
Errors-To: apps-review-bounces@ietf.org
Dear Calsify group, dear apps-review team, Eric Burger asked me if I could review the latest draft of rfc2446bis, which I agreed to. I tried to read the draft very carefully and with utmost diligence, trying to be extremely picky. I found lots of issues, obvious typos and contradictions, or simply things that should/might be explained a little better. There are also some things that I've not completely understood from the draft. Attached is my review, where I mention all issues / questions sequentially, ordered as they appear in the draft (thus mixing errors with open questions and suggestings). I wrote it in LaTeX, mainly because of its size and to make cross-references and automatic numbering easier. I'm attaching the PDF file, the LaTeX source document and a HTML-representation produced by hyperlatex (with some tweaks to achieve the consecutive item numbering for the lists). I know that some of the things might sound like nitpicking. However, from my experience with RFC 2445, if there is anything that can possibly be misunderstood, it will probably be misunderstood by some implementor. Thus, I strived to find also all the spots where things could be spelled out a little more detailled. In my eyes, a standards document should be unambiguous and still easy to understand. Please view my comments in this light. On the other hand, I really wonder how things like the following could have survived in a public RFC for more than a decade: DTSTART:19980101T100000-0700 or STATUS:IN-PROGRESS for a todo or RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU for an event that should recur every week for 20 weeks or DTSTART:19970701T200000Z DTEND:19970701T2000000Z for an event or completely messed-up timezone conversions (Sec. 4.4.1). Most of my points do not change the meaning of the RFC draft at all and can probably be included with only very little discussion / controversy. While cross-checking some issues, I also came across some things in rfc2445bis-08, which might be changed there. These are listed at the end of my review. Cheers, Reinhold PS: Sorry (well, not really...) for all the work that my review will bring to the ietf calsify team, but well, you asked for it ;-) -- ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
_______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www.ietf.org/mailman/listinfo/apps-review
- [APPS-REVIEW] IETF Review of rfc2446bis-07 Reinhold Kainhofer
- Re: [APPS-REVIEW] IETF Review of rfc2446bis-07 Cyrus Daboo
- Re: [APPS-REVIEW] IETF Review of rfc2446bis-07 Cyrus Daboo