Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id WAA09549; Sat, 22 Aug 1998 22:49:52 -0400 (EDT) Received: by cs.cs.utk.edu (bulk_mailer v1.11); Sat, 22 Aug 1998 22:47:39 -0400 Received: by CS.UTK.EDU (cf v2.9s-UTK) id WAA09474; Sat, 22 Aug 1998 22:47:38 -0400 (EDT) Received: from a4.jck.com ([206.99.215.40]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id WAA09462; Sat, 22 Aug 1998 22:47:33 -0400 (EDT) Received: from p6.jck.com ("port 3466"@[206.99.215.34]) by a4.jck.com (PMDF V5.1-11 #28836) with SMTP id <0EY40094JFR8TH@a4.jck.com> for DRUMS@cs.utk.edu; Sat, 22 Aug 1998 22:47:32 -0400 (EDT) Date: Sat, 22 Aug 1998 22:47:27 -0400 (Eastern Daylight Time) From: John C Klensin Subject: Re: VRFY discussion - SUMMARY In-reply-to: To: Philip Hazel Cc: DRUMS@cs.utk.edu, Robert Elz Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.5 Build (42) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Priority: NORMAL X-Authentication: none List-Unsubscribe: On Sat, 22 Aug 1998 15:21:16 +0100 (BST) Philip Hazel wrote: > I am under the impression that RFCs define Internet interworking > standards, and as such they are concerned with what gets sent along the > wire. If this is right, then how can one formally determine whether a > given program is compliant with RFC 821bis or not? As far as I can see, >... I am in complete agreement with kre's response to this, just wanted to add one observation... If IETF ever went into the "certification of conformity" business --something I'd personally oppose-- the presence of an information-returning VRFY would be rather easily tested "on the wire". One would need only to perform a test in which one tried to VRFY a known address to determine whether, under some configuration arranged by the server software's vendors, that software could return full information. Similarly, one could test for the ability of the program to produce restricted information in the same way. In the information technology area, conformity certification tests were, I believe, first developed in the programming languages area, and such "test twice and verify that the program can produce different answers with the same inputs but different configurations" testing has been nearly routine almost since the beginning. Configurability requirements of the "this functionality must be in the code, but the user site can turn it on or off" (with or without a specified default) may be a good idea or a bad one, but let's not get distracted either by claims about what is or is not testable on the wire or about what IETF can or cannot require in a standard if doing so otherwise makes sense and has consensus behind it. john