Re: drums2?

ned+ietf-822@mrochek.com Thu, 15 August 2002 17:49 UTC

Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7FHndb12599 for ietf-822-bks; Thu, 15 Aug 2002 10:49:39 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7FHncw12595 for <ietf-822@imc.org>; Thu, 15 Aug 2002 10:49:38 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KLBKH8JJ280001B1@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-822@imc.org; Thu, 15 Aug 2002 10:49:38 -0700 (PDT)
Date: Thu, 15 Aug 2002 10:44:40 -0700
From: ned+ietf-822@mrochek.com
Subject: Re: drums2?
In-reply-to: "Your message dated Wed, 14 Aug 2002 22:32:40 -0500" <a0520061ab980d00703e2@[216.43.25.67]>
To: Pete Resnick <presnick@qualcomm.com>
Cc: ned+ietf-822@mrochek.com, Tony Hansen <tony@att.com>, ietf-822@imc.org
Message-id: <01KLBOH06IB60001B1@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; format="flowed"
Content-transfer-encoding: 7bit
References: <3D5AB95C.3020103@att.com> <01KLAG31RZ4A0001B1@mauve.mrochek.com> <a0520061ab980d00703e2@[216.43.25.67]>
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>

> > A new version of 2822 may be needed as well.

> It does. I've got a list of small errors that need to be corrected. I
> should be able to come up for air in a few weeks and perhaps start on
> the revision. It really shouldn't take too long.

> > I suspect 2822bis would be able to move to draft.

> I agree. Who gets to do the implementation review for this?

The way this is normally done is to have somebody write down a list of features
specified in the document. Then a call goes out and implementors respond with a
line by line list of the stuff they implement.

Constructing the list is something of an art. Making it too general is bad --
you cannot just say "Yes/No implement everything in the document". But too much
detail is also bad -- you don't want to check for every line of ABNF, for
example.

I'd suggest breaking 2822 down into functional areas and having one entry on
the list for each.

The usual people who do this are the chairs or former chairs of the WG which
produced the specification, but in practice anyone with the necessary expertise
can do it. I did the list for NOTARY, for example.

				Ned