Subject: Re: Fwd: Re: IP: Microsoft breaks Mime specification

From: Einar Stefferud <[email-masked]>
Date: Tue, 22 Jan 2002 10:30:48 -0800

At the minimum, such violations of IETF Standards should be formally 
noted in a letter from the IAB to the offending vendor, whoever that 
might be, when such information becomes available to the IESG or the 
IAB.

Among other things, such notices would result in a formally recorded 
track record for the offending vendor, which should be made public by 
CC to the IETF mailing list, as these are public standards, which are 
of public interest and public record.

This assumes that the IESG or IAB care about such violations, in the 
interests of promoting vendor conformance with their standards.

Of course, if no one cares, then no one cares, though one might 
become curious about what the IETF does care about;-)...

>I am not suggesting that the IETF should mount a conformance police 
>force!  but it should offer more than a simple shrug of their 
>shoulders, such as "ok.  i give.  why?".

   PS:	I apologize profusely to Dave and everyone else for
	violating my own rule against use of the Eudora Redirect
	Command, which always results in confusion when used as I
	did...\s

At 08:53 -0500 22/01/02, David Farber wrote:
From: Randy Bush <[email-masked]>
To: David Farber <[email-masked]> (by way of Einar Stefferud)
Cc: [email-masked]
Subject: Re: IP: Microsoft breaks Mime specification
Date: Tue, 22 Jan 2002 14:40:41 +0100

>  This needs to be given some attention in the IETF...\Stef

ok.  i give.  why?

there are only a few thousand of us, far too few to fix microsoft's
bugs.  and we don't have the source anyway.

---

From: [email-masked]
Date: Tue, 22 Jan 2002 14:30:25 -0500

> 	Command, which always results in confusion when used as I

I have to wonder if the Eudora Redirect command is in violation of a
standard, for its failure to re-write the headers to make the redirection
clear. ;)

/Valdis

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Jan 2002 22:24:07 +0100

> might be, when such information becomes available to the IESG or the 

i think that nichf once printed up some net protocol police traffic
tickets.  i am in amsterdam, and can try to ask rob to get one for me.

> become curious about what the IETF does care about;-)...

producing standards of sufficient technical merit that vendors want
to implement them and users use them.

randy

---

From: "Marshall T. Rose" <[email-masked]>
Date: Tue, 22 Jan 2002 13:15:28 -0800

> ...

stef - i think we can agree that i'm not an apolgist for the company in
question. however, i don't think you fully appreciate the consequences of
your suggestion.

the ietf does standardization, it does not do interoperability testing,
conformance certification, or protocol policing. we rely on other
organizations and the market for those tasks.

setting aside, for the moment, whether the i-architecture-b should be
sending letters about non-conformance to i-engineering-tf standards, the
fact remains that whoever does such a thing has to have a well-defined,
defensible process for making such determinations. this includes a review
process, an appeals process, and so on. none of these things are in place.

the missing word in the paragraph above is "litigation", and i see no reason
why the voluntary i-* organization should willingly undertake an activity
that invites a lot of it, particularly when the market will sort it all out
(as it eventually does).

i would much rather spend my time privately reminding my colleagues at the
company in question of their professional responsibilities, than to have our
attorneys and their attorneys rack up billable hours...

/mtr

---

From: Theodore Tso <[email-masked]>
Date: Tue, 22 Jan 2002 17:26:17 -0500

> organizations and the market for those tasks.

I agree with the general sentiment, although I'll note that apparently
the ISO *does* send some kind of whiny letter to the IAB/IESG whenever
we engage in "felony violations of the ASN.1 spec", to the point where
when the Kerberos wg was exploring playing fast and loose with the
ASN.1 specs to solve an interoperability problem while providing I18N
support in the Kerberos V5 protocol, the response the wg got back from
the IAB/IESG was, "please don't".

So apparently the ISO letters (although I've never seen them myself)
is annoying enough that it's capable of influencing our standards
behaviour.  Maybe someone should just change some of the words and
then send it off to Redmond?  1/2 :-)

							- Ted

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 22 Jan 2002 15:21:59 -0800

Quite likely so!  And I always (except for this properly noted instance)
do what it takes to fix the headers to avoid confusion.

So, in this case the fault was mine, as I certainly know better.

But for those who do not know the consequences, it is the fault of EUDORA.
As it does not offer any warning of the potential embarrassing consequences.

Again, I profusely apologize for committing such a crime...\Stef

At 14:30 -0500 22/01/02, [email-masked] wrote:
>Content-Type: application/pgp-signature
>
>Attachment converted: Macintosh HD:Untitled 1 (????/----) (00081502)

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 22 Jan 2002 15:26:17 -0800

Thanks Randy for clearly stating what looks like a very proper IETF goal.

So, given your stated goal, I do hope that someone outside IETF will 
find good reason to keep score on this stuff with a public 
compilation of the reports.

Cheers...\Stef

At 22:24 +0100 22/01/02, Randy Bush wrote:
[SNIP]...
>Stef wrote:

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 22 Jan 2002 15:35:44 -0800

Thanks Marshall for clarifying that it is the threat of litigation 
that keeps the world from calling a spade a spade.

So be it.  One day, maybe the markets will awaken to reality like it 
awoke to the realities of IBM in 1986 or so.

BTW, there are more than one vendor that is guilty of violating 
standards with impunity.  But, I will accept that this is not the 
responsibility of IETF.

It is the responsibility of the market to deal with the problem, 
which I suggest might be fulfilled with some public dissemination of 
information.

Enjoy;-)...\Stef

---

From: Ed Gerck <[email-masked]>
Date: Tue, 22 Jan 2002 16:58:47 -0800

"Marshall T. Rose" wrote:

> <snip>

Perhaps we all agree that standardization without some sort of conformance
verification is ineffective.  We need a two-prong process: standards and
conformance.  The IETF takes a "hands off" approach to the conformance
issue and MTR points out why -- fear/cost of litigation.

However, suppose that the "lack of conformance note" mentioned by Stef would
not be sent to the "offending vendor" but would be provided publicly, at a
website, by an entity that has no legal status (IETF) and refers to a consensus
decision published in a RFC by a workgroup (also with no legal status) using
the open process of list consensus.  Then, at the very least, the market forces
might receive an incentive to sort it out.

So, what we seem to need is an RFC series dedicated to pointing out non-conformance
issues in implementations of IETF standards.  As an added benefit, we would not
need to talk about it -- just point to the RFC ;-)

Cheers,

Ed Gerck

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2002 21:22:20 -0500

Einar raises an interesting point. 
I would also like to see that letter written. 

The IAB may be reluctant to do that because it may set a precedent of them
caring, and their workload could go up ... A LOT.

That is far from the only problem that is out there.

There are numerous RFC1123 violations in millions of systems out there.

We regularly hear on WG mailing lists that "we can't do that because it would 
break some implementation X"

In the past, this type of thing has been left to consortia (e.g. ICSA has
done firewalls and IPsec, VPNC has done Firewalls, IMC has done SMTP/POP. I
don't know if IMC did MIME as well). While this can work, consortia are
driven by funding members, not standards bodies.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Jan 2002 03:38:19 +0100

> verification is ineffective.

can you read this mail?  consider what it took to get it to you.  how did
that happen?

randy

---

From: Ed Gerck <[email-masked]>
Date: Tue, 22 Jan 2002 19:13:46 -0800

> can you read this mail?  consider what it took to get it to you.  how did

Randy:

Once upon a time when the Internet was something we discussed at the
campus cafeteria, I might have found your questions to be useful. Today,
when much of our economy and future is riding on Internet technology which
is put together with what amounts to be bail wire and chewing gum, I find your
questions to be still useful.  After all, if we had really thought hard about those
questions then we would very probably be in a better position.

Laissez-faire conformance has not worked. Period. IMO, we need to realize that
conformance verification is a fundamental part of the standardization process
and provide ways for it to happen. Publicizing non-conforming implementations
in an RFC would be a way to shine light onto them.

Conformance  does not have to come with enforcement, though -- if that is your
fear.   Just make it clear and public.  As this very discussion is doing in reference to
Microsoft and its broken implementation of MIME.

Cheers,

Ed Gerck

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 22 Jan 2002 22:20:43 -0500

The stuff being spewed out here by some people indicates an ignorance
of how standards work in the IETF.

Even if we wanted to, history indicates that we don't write perfectly
unamibguous and infintely detailed standards for protocols and we
don't try to enforce or even test "conformance".  We develop protocols
by progressive refinement through interoperability of independent
implementations and that interoperability, in effect, defines the
protocol. If, say, there are 10 independent implementations in a
interoperability test and 7 or 8 of them interoperable, the remaining
2 or 3 implementations are irrelevant in most cases no matter
arguments they have that the standard "really" means what they
implemented. The standards documentation is normally clarified to
conform to the interpretation make by the 7 or 8 interoperable
implementations.

Perhaps some will consider this strange or wrong but that is the way
it has been. And people have, in many cases, adopted IETF standards to
get this interoperability even over other organization's standards
that were legally mandated, claimed to be unambiguous, and/or had
massive conformance testing machinery.

If someone wants to start some sort of organization to test
conformance to that organization's interpretation of IETF standards,
that's OK with me, as long as they don't pretend they are testing
anything other than their interpretation of IETF standards. And as
long as they don't claim that successful conformance testing will lead
to successful interoperability, since historic experience disproves
this.

As far as I know, the only official statement by the IETF of its
standards are the standards track RFCs (and approved drafts) that are
in force, not any "confrormance" testing by any organization.

Donald

PS: In my opinion, the oft repeated claim that the IETF "has no legal"
status or existence is hogwash.  The unincorporated non-profit
association is a valid form of legal entity, at least in the USA.

From:  Ed Gerck <[email-masked]>
Message-ID:  <[email-masked]>
Date:  Tue, 22 Jan 2002 16:58:47 -0800
To:  "Marshall T. Rose" <[email-masked]>
CC:  [email-masked], Einar Stefferud <[email-masked]>
References:  <[email-masked]> <v04220813b8735cc508d1@[192.168.1.14]> <039201c1a389$eb0ed770$0301000a@FATORA>

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 22 Jan 2002 23:25:41 -0500

From:  Ed Gerck <[email-masked]>
Message-ID:  <[email-masked]>
Date:  Tue, 22 Jan 2002 19:13:46 -0800
To:  Randy Bush <[email-masked]>
CC:  Ed Gerck <[email-masked]>, [email-masked]
References:  <[email-masked]>
	    		<v04220813b8735cc508d1@[192.168.1.14]>
	    		<039201c1a389$eb0ed770$0301000a@FATORA>
	    		<[email-masked]> <[email-masked]>

>questions then we would very probably be in a better position.

No, the success of the Internet is due to the flexibility of the
protocols on which it is based. The whole concept of "really thinking
hard" and coming up with an 'optimal' design or something was the
death knell of OSI. It is only because a zillion things were thrown
into the Internet, most of them something a grad student could do as a
project, and what worked and interoperated survived, that the Internet
is successful. The Internet is designed so it works to keep it
together with bailing wire and chewing gum.

>Laissez-faire conformance has not worked. Period.

Conformance testing has never been a significant part of the
Internet. It was considered critical in OSI and other protocols
suites. Most people consider the Internet to be a success story and
OSI a failure.

>                                                 IMO, we need to realize that

Conformance testing is mostly an insiginficant waste of
effort. Interoperability testing is what is important.  The success of
the Internet is proof of this.

>Microsoft and its broken implementation of MIME.

True, conformance != enforcement. But it is also true that conformance
!= interoperability. And, quite rightly, what customers generally care
about is interoperability because that is what makes networks
valuable.

Donald

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2002 21:13:29 -0800

>organizations and the market for those tasks.

marshall,

Although I thought your note was wonderfully thorough, concise and 
insightful, it appears that your core message was missed by some.

What I took to be your core message was that if an organization is going to 
claim responsibility for judging the adequacy of implementations, then that 
organization needs to create a thorough and fair process for creating and 
handling those judgements.  Anything informal or incomplete would be 
extremely irresponsible.

The fact that such irresponsibility would likely have legal impact should 
not distract anyone from noting that, first and foremost, anything less 
than a full-blown and fair process would be irresponsible.

As others have noted, the IETF is rather busy doing a different job.  So 
the most the IETF should do is wish someone well if they try to pursue this 
assessment-and-enforcement job.

Alas, it is not possible for the IETF to do everything, as we keep discovering.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2002 21:07:11 -0800

>verification is ineffective.

The only problem with that assessment is 25 years of Internet experience, 
all of which was based of no conformance verification, but quite a bit of 
effectiveness.

d/

ps.  yes, yes.  individual implementors worry quite a lot about conformance 
verification.  however, the topic under discussion has to do with formal, 
community-based efforts, rather than individual actions.

----------

---

From: Ed Gerck <[email-masked]>
Date: Tue, 22 Jan 2002 22:39:06 -0800

"Donald E. Eastlake 3rd" wrote:

> <snip status quo definition, which is what is being questioned>
> ...

When there is more market value in breaking a technology than following it,
what is your answer?  I find it hard to believe that Microsoft implemented
that broken MIME because its engineers can' t read RFCs or did not bother
to.  It seems to me that we do need to put non-conformance on the spotlight.
When a flaw is qualified as a flaw and made public, it may embarass its
creators enough to make them change it.  Left alone, the flaw will probably
become a feature.

Cheers -- Ed Gerck

> association is a valid form of legal entity, at least in the USA.

Hmm, does the IETF pay taxes? Or is it some form of non-taxable US legal
entity?

---

From: Christopher Evans <[email-masked]>
Date: Tue, 22 Jan 2002 22:46:56 -0800

Mime attachments suck when all you are attaching is ASCII TEXT!   dmn.  and
worse is then ppl do it as a MS WORD .doc and with fancy features when it
could  have been conveyed mush more effectivly as a .txt file.

suck up the bandwidth, IMO. I guess they gotta use up that t3 or DSL line
you pay out the nose for huh?

---

From: Ed Gerck <[email-masked]>
Date: Wed, 23 Jan 2002 00:30:35 -0800

> all of which was based of no conformance verification, but quite a bit of

Laissez-faire conformance verification is at odds with  Moore's law. (*)

> community-based efforts, rather than individual actions.

The topic is about community-based efforts -- which can be much more objective.

Cheers,

Ed Gerck

(*) Perhaps we agree that the reason for a standard to exist is to be used. So,
"some sort of conformance verification" always exists, even if it is just by
market forces.  The question (the part that you snipped off from my
paragraph) is how to *improve* upon conformance verification.

---

From: "Marshall T. Rose" <[email-masked]>
Date: Tue, 22 Jan 2002 22:24:48 -0800

> assessment-and-enforcement job.

this is a fair restatement. thanks!

/mtr

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Jan 2002 10:03:57 -0500

> can you read this mail?  consider what it took to get it to you.  how did

and then consider the number of messages that fail to be delivered, 
or messages that cannot be read properly (because they're not properly
tagged by the sender's MUA, or because the recipient's UA doesn't like
one of the headers on the message), or messages that deliver 
viruses to their recipients computer systems, or messages that 
resulted in mail loops or sorcerer's apprentice syndrome -  because 
some MTA or MUA vendor failed to conform to the standards.

as useful as email is, the reliability of email is not even close to 
that of snail-mail.  and that's pretty sad.

Keith

p.s. though mis-configuration of MTAs and DNS servers appears to be
a far larger source of errors than mis-implementation.

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Jan 2002 10:19:02 -0500

> of how standards work in the IETF.

Not necessarily apropos of the rest of that message, but whenever
people say "we don't do things that way in IETF", I wonder if they're
assuming that IETF should not, or cannot, change - even if change
is needed.

Of course, there are limits to what a volunteer organization can do,
and we need to respect those limits.  We can't solve every problem 
that the Internet has, nor even every technical problem that the Internet
has.

I think it's fair to observe that failure of vendors to conform to 
standards has caused numerous problems with Internet operations, 
interoperability of Internet applications, and the ability of the 
Internet to support new applications.  Vendors make implementation 
errors, and vendors sometimes deliberately violate specifications 
if/when they believe it will give them a competitive advantage.  The 
vast majority of customers are not able to evaluate vendors' products 
for standards conformance, and once the investment has been made in 
a particular vendor's hardware/software it is often too late to change. 
In a network where there are 100s of millions of computers, and everyone's 
computer can potentially interact with everyone else's computer, and
failure of any single computer to "behave" can wreak havoc - putting the 
burden on the customer to "do the right thing" simply doesn't scale.

I don't claim to know the answer, or whether it is at all within IETF's 
power to do this.  But the Internet community desperately needs some 
mechanism to hold vendors accountable when they deploy products that do harm.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Jan 2002 10:25:16 -0500

> all of which was based of no conformance verification, but quite a bit of

there's more than one kind of effectiveness.  effectiveness at getting
a technology deployed is quite different from effectiveness of that
technology (once deployed) at supporting reliable operation for a 
variety of applications.

Just to pick a small example: MIME has been out for nearly 10 years and 
I'm still receiving, on a daily basis, MIME attachments that are 
unreadable because they lack proper content-type labelling.
That's not what I would call "effective".

Keith

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 23 Jan 2002 11:16:31 -0500

One system that seems to be work pretty well, without the legal
liabilities, is that of interoperability test events (or b*k*o*fs,
before Pillsbury made that word illegal and threatened to sue us...).
For SIP and RTP, there have been nine so far, taking place at four-month
intervals. While this is no guarantee of interoperability and
robustness, it has greatly helped, with upwards of 50 companies
participating each time. (See http://www.sipforum.org and
http://www.cs.columbia.edu/sip/sipit)

These events also benefit the IETF: The interop events have helped
ferret out a number of ambiguities and corner cases in the spec that
were fed back into the working group. Having a close coupling between
the community that participates in the events and the working group has
been very helpful. Also, there's hope that this activity will greatly
simplify identifying interoperable implementations when elevation to 
Draft standard becomes an issue. As is well-known, the Internet mostly
runs on Proposed Standards, with part of the blame probably belonging to
the pain and suffering required to get vendors to cough up interop
statements.

I don't think the IETF needs to be or should be directly involved in
these events, but I think they are a good tool that ADs and WG chairs
can avail themselves of during the later stages of maturing a standard.
The SIPit events have been done on a not-for-profit basis, with "ticket
prices" of around $100/person to cover direct host expenses, making it
easy for both big and small companies to play.

Keith Moore wrote:
> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Raffaele D'Albenzio.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: [email-masked]
Date: Wed, 23 Jan 2002 11:22:12 -0500

> When there is more market value in breaking a technology than following it,

When your corporate strategy is "We know what you want, and we will do
illegal and questionable things to ram it down your throat and make you think
that's what you wanted", it's a moot point. 

Or maybe it's simply that you as a vendor have been made painfully aware
that you've managed to bork the BGP specs - but actually *fixing* the problem
isn't a 3-line change because it requires re-architecting a large part of
the code base, and your management is telling you to devote your efforts
to writing the code to support the feature that Sales has already sold
to customers(*)....

> that broken MIME because its engineers can' t read RFCs or did not bother

I don't find it hard to believe at all.  In this case, I think it was
a *bug*, pure and simple.  Some code-monkey didn't consider that a certain
set of headers could appear together, and their testing probably didn't
find it because Outlook doesn't create that combination of headers.

I won't discuss some of the comments I got when I was trying to get
the Exmh MUA to generate Content-Disposition: headers for the
various parts of a multipart/signed so if the remote MUA didn't understand
the /signed and degraded it to a /mixed (as per spec), that it wouldn't
do something ugly with the application/pgp-signature (which would almost
certainly be degraded to application/octet-stream).  Yes, I can read the
RFC's.  That doesn't mean that I got the code "right", or that the authors
of the remote MTA had the same reading of the RFCs as I did...

Microsoft's variant implementation of Kerberos however...

> to.  It seems to me that we do need to put non-conformance on the spotlight.

Yes, non-conformance needs to be put in the spotlight.  However, I don't
think we need a formal structure to it..

> creators enough to make them change it.  Left alone, the flaw will probably

I've seen enough of the various trade journals run news articles of the
form "X doesn't play nice with Y".  Amazingly enough, quite often these
are followed by articles of the form "Vendor of X rushes to ship fix".

The system works.  The only thing the IETF as a group needs to do is to
make sure Microsoft *does* eventually issue a fix for bug OfficeQFE:4781,
and that shouldn't be *too* hard to do now that it's acknowledged to be a bug.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

(*) No, I *dont* know how Cisco managed to break the BGP spec, or why/how
it isn't fixed in the field.  But I'll admit *I* have shipped production
code that still had "This is wrong but hopefully will work anyhow" comments
in it.  Yeah, the code is wrong.  Yeah, it mostly works anyhow.  Guess
what the chances are that it will get fixed correctly? ;)

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jan 2002 08:25:49 -0800

>unreadable because they lack proper content-type labelling.

There is a difference between effective and perfect.

In the realm of human activity -- and that is where email resides -- 
effectiveness is probabilistic.  The requirement is that the probabilities 
be high, but rarely that they be 100%.

d/

----------

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 23 Jan 2002 11:31:52 -0500

From:  Ed Gerck <[email-masked]>
Message-ID:  <[email-masked]>
Date:  Tue, 22 Jan 2002 22:39:06 -0800
To:  "Donald E. Eastlake 3rd" <[email-masked]>
CC:  [email-masked]
References:  <[email-masked]>

>Hmm, does the IETF pay taxes? Or is it some form of non-taxable US legal

It has been some years since I studied the relavent parts of the US
Tax Code.  But it used to provide that if an entity would have
qualified for tax exempt status if it had applied and its annual cash
flow was less than $5,000, then it need not file any tax return or pay
taxes. This is a pretty reasonable provision. It is why all kinds of
small informal groups don't need to worry about this stuff. Say, for
example that you and some friends get together once a week and agree
to pay some small amount of money into a pot to pay for refresments
and maybe have a picnic once a year paid for by any surplus. Why
doesn't the unincorporated social organization you have formed have to
file tax returns and pay taxes if it has a surplus in any particular
tax year? The IETF is different and larger but it obviously meets
definitions of non-profit and has pretty much a zero cash flow. I
believe all the meeting fees go through the ISOC, not the IETF.

Donald

PS: The IETF does have separate legal representation.

---

From: Fred Baker <[email-masked]>
Date: Wed, 23 Jan 2002 08:47:20 -0800

At 10:30 AM 1/22/2002, Einar Stefferud wrote:
>At the minimum, such violations of IETF Standards should be formally noted 
>in a letter from the IAB to the offending vendor, whoever that might be, 
>when such information becomes available to the IESG or the IAB.
>
>Among other things, such notices would result in a formally recorded track 
>record for the offending vendor, which should be made public by CC to the 
>IETF mailing list, as these are public standards, which are of public 
>interest and public record.
>

Hi Stef,

I think that this misunderstands the nature of the specifications you're 
referencing. They are not laws, for which a violation merits some form of 
censure. They are specifications for how players are intended to interact 
in a process to process conversation. To quote RFC 1122:

>    These documents are intended to provide guidance for vendors,
>    implementors, and users of Internet communication software.  They
>    represent the consensus of a large body of technical experience and
>    wisdom, contributed by the members of the Internet research and
>    vendor communities.

The fact is that this consensus changes over time, as we learn more about 
the technology, and we do a fair bit of work to keep the current consensus 
documented. For example, RFC 1122 spends a fair bit on the subject of 
all-subnets broadcasts. However (because we subsequently figured out that 
they don't work), RFC 1812 says:

>4.2.2.10 Multi-subnet Broadcasts: RFC 922
>
>    All-subnets broadcasts (called multi-subnet broadcasts in
>    [INTERNET:3]) have been deprecated.  See Section [5.3.5.3].

So what is more important than conformance and conformance testing (which 
you will remember the OSI making a big industry out of and yet failing to 
have interoperable implementations in any meaningful way) is 
interoperability testing. This has traditionally been done in bake-off 
events (apologies to Pillsbury) or in labs back at the ranch. One who is 
concerned about the interoperability of a set of implementations organizes 
it, invites and motivates the various implementors to be involved, works 
out a test plan with them, and conducts the test. This presumes an 
underlying commitment to interoperate.

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Jan 2002 12:42:22 -0500

> There is a difference between effective and perfect.

and there's a difference between requirements analysis and exaggeration.

there's also a difference betweeen 90% (which is where I'd put the 
reliability of internet email, averaged over all users *) and 99.9% or 
99.99%.  of course, even 99.99% is a long way from 'perfect', but we
rarely need for things to perfect.  but for many purposes 90% isn't 
good enough.

Keith

* if you think this figure is too low, consider that the vast majority of
email users are handled by a small number of email providers, not all of
which have exemplary service records.

---

From: Doug Royer <[email-masked]>
Date: Wed, 23 Jan 2002 11:16:56 -0700

Perhaps the thing to do is make the results of interoperability
testing public - only for shipping versions of software.

Developers can then develop and fix their bugs and not get bad
press about not yet shipped products. And when they do ship their
product it seems fair their competitors and the press can broadcast
their noncompliant products. If it is a bug, they will fix it.
If it is not, then they get bad press.

---

From: Getty Verma <[email-masked]>
Date: Wed, 23 Jan 2002 10:46:21 -0800

If we are talking adequacy of implementations I have no comment but if
we are talking here pursuits of characterizing facts through
implementations IETF  has a role since tests alone can shed some light
on any aspect of network topology which directly or indirectly may be
under the specified domain of IETF body.

Thx
getty

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 23 Jan 2002 09:15:25 -0800

> technology (once deployed) at supporting reliable operation for a

keith - may i refer you to don eastlake's earlier reply? viz., the existing
system is quite effective because products that don't play by the concensus
rules have a much harder time thriving or even surviving.

> That's not what I would call "effective".

then ignore it or fix it. obviously, the pain isn't at the point where it
bothers you... for myself, the program that handles my incoming mail dumps
MIME-bad stuff into an audit file and then ignores it. if it was
"important", then whoever sent it can get on the phone... in doing this for
the last 10 years, i've yet to suffer a mishap because of this...

/mtr

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Jan 2002 13:54:32 -0800

> Microsoft's variant implementation of Kerberos however...

is RFC compliant, and includes a set of interoperability notes for the
defacto and predominant implementation. The fact that some people want
to change the RFC to restrict the possible set of implementations to be
exactly = the 10 year old one from MIT, defies the original author's
expectations that the fundamental requirements would change over time as
technology evolves.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Jan 2002 18:55:23 -0500

> rules have a much harder time thriving or even surviving.

sometimes this works.  as a generalization, it doesn't hold up.

> the last 10 years, i've yet to suffer a mishap because of this...

that kind of solution is easy for you or me.  unfortunately, it doesn't 
scale to a user base of 100s of millions of people that's trying to use 
email to ship around attachments and wondering why they don't work.

the reason I don't filter such stuff is because I want to understand the
kinds of problems other folks are having. 

Keith