RE: Only include implemented features in a draft standard

Jacob, you're so close.  If you'd just stop assuming the conclusion you'd
get it.

"How can the contents of that section be interoperability tested? Exactly
why is such a section allowed, even though it cannot be interoperability
tested?"

Two different implementations must be able to correctly parse obsolete
messages.  Implementations should never generate those messages.  The
easiest way to do the test (and hopefully every MUA vendor will do this) is
simply to telnet to port 25 and feed in the obsolete message from the
example.  Thus, the obsolete section would be interoperability tested if
both implementations produced the same parsed message.  There is no
requirement for interoperability on generation, and in fact, MUAs are
required NOT to generate such messages.  Thus, your second sentence doesn't
follow.

If this still seems unclear, I would reread the whole thread and reread
section 4.1.2 in RFC 2026.

		- dan
--
Daniel Kohn <mailto:dan@dankohn.com>
tel:+1-425-602-6222
http://www.dankohn.com

-----Original Message-----
From: Jacob Palme [mailto:jpalme@dsv.su.se]
Sent: Sunday, 2000-06-18 03:01
To: IETF Applications Area Discussion List
Subject: Re: Only include implemented features in a draft standard


At 09.19 -0700 0-06-17, <ned.freed@innosoft.com> wrote:
> You keep coming back to this notion that a conformance
> specification can somehow defeat the interoperability
> requirements. This just isn't true. A protocol can say
> what it likes about what it means for an implementation to
> be conformant. But this has no effect on interoperability 
> requirements at all.

I am just trying to understand the IETF rules for moving a
standard from proposed to draft status.

I do understand that the base requirement is still, that
moving a standard from proposed to draft requires that
there are two implementations based on different code base
which can interoperate using every feature in the standard.

And I do now understand that this rule is only valid for
every single feature, not for any combination of features,
and not for an arbitrary number of recursive application of
the same feature.

But I still have the impression that there are exemptions
from this, that there are certain things you can say in a
standards document which is exempt from the
interoperability requirement. But I do not quite understand
which features are exempt in this way.

In particular, how can a standard ever specify a
requirement only for receipt, if all requirements must be
interoperability tested? Surely interoperability testing
requires that systems can both receive and generate a
certain format?

For example, the drums msgfmt document has a list of things
you should be able to receive but should not generate (the
obsoleted features section). How can the contents of that
section be interoperability tested? Exactly why is such a
section allowed, even though it cannot be interoperability
tested? Is it because the section is labelled "obsolete",
because the section is labelled "for receipt only" or why?

At 23.18 -0700 0-06-17, <ned.freed@innosoft.com> wrote:
> Take ICMP as an example from an entirely different area.
> ICMP defines a bunch of different sorts of messages, quite
> a few of which are only used in very specific
> circumstances. There are lots of agents that generate ICMP
> packets that have no need to ever generate certain sorts
> of ICMP messages. It it then appropriate to claim that
> these features of ICMP don't interoperate merely because
> some agents cannot produce them? I think not.

The interoperability requirement is not for all
implementations, only for two different implementations
based on a different code base. So my understanding is that
there must be at least two different ICMP implementations
which can send and receive every single ICMP message, and
which can interoperate when handling this message, but it
is not necessarily required that every implementation can
handle every ICMP message, not even that there are two
implementations which can handle all the ICMP messages in
just those two implementations.
-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Sunday, 18 June 2000 06:40:05 UTC