Date:         Tue, 23 Dec 2003 15:16:01 -0500
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "Ray Denenberg, Library of Congress" <[log in to unmask]>
Subject:      Re: requirements and expectations
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

>  This is how things work
> in IEFT RFC and ISO standards.

IETF standards include a whole lot of  formalism that I am sure we don't
want, for example, they define "shoulda/coulda/woulda", "shall" etc.  ISO
(protocol) standards include a conformance section. If/when  we eventually
take this to NISO or ISO we'll probably have to include a conformance
section. I'm trying to lighten this up for now and I think we save ourselves
alot of trouble if we avoid a conformance section (because, for one,
conformance sections beg the question of conformance testing).

But if we say "require" we have to define "require", that is we have to
answer the question  "require, in order to do what?"  whose answer is "in
order to claim conformance to the protocol" and that means we have to
include a conformance section.

On the other hand  we absolutely need either a conformance section or
something along the lines of a "base profile" (which we all know is a
euphemism for "conformance section"). We want to encourage vendors to
implement this protocol and we'll have more success if customers can point
them to a concise document that lists what they need to implement.  Telling
them "read the spec", with its dozens of files, isn't going to satisfy them.

> specification should damned well tell people what to implement.
Absolutely! And that's why we need a base profile.

--Ray