[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