Re: [qaframe-spec] What is an implementation?

Alex Rousskov writes:
>...RFC 2616 conformance policy defines conformance
>for HTTP "implementations". In RFC 2616 context, I interpret
>"implementation"  as "agent" (client, server, or intermediary).
>However, one could interpret "implementation" in a broad sense and
>include HTTP messages.

This is how SpecGL intends to clear that up (if this were a W3C Rec
rather than an RFC):
The HTTP spec/Rec would say that it defines the behavior of three
classes of product: client, server, and intermediary. If they all
emit HTTP packets, then they have individual requirements that they
emit conformant packets. Furthermore, there may be certain types of
packets that only one class (say, client) should ever emit. Since the
spec is defining a protocol, it can define conformant behavior for
arriving packets of several statuses:
1. acceptable packet
2. packet that this class should never be receiving
3. packet that would be correct at a different stage of the
   interchange, but not now
4. packet that indicates that the other node (presumably of a
   different class) has encountered an error
5. packet that is not correctly formed
...and so on.
Clearly, the specs about how to respond to such inputs will vary by
class of product.

A given real-world software product may be an implementation of any
one class of product from the spec. If it makes sense to be both a
server and an intermediary, the software might even implement two
classes. But the focus remains on the role. For example, the (IBM)
Lotus Domino server can fill the role of an HTTP server, among
other things, and would be subject to the spec provisions that
define conformance for an HTTP server. Presumably, one rule is that
a conformant server never emits non-conformant packets. I don't see
any gain from viewing the packet itself as an "implementation" of
HTTP. Since data can get scrambled on the network, every conformant
packet receiver must take some defined action when receiving an
invalid packet, whether or not the sender is at fault. But QAWG's
aim is to have precise specs accompanied by conformance tests. In
this example, that means that there is a conformance test suite for
an HTTP client that tests how it responds to various inputs,
including invalid packets. There wouldn't be conformance tests for
the packets per se, but for how the software deals with them.
.................David Marston

Received on Friday, 5 September 2003 23:48:56 UTC