Subject: Re: User Petition on Standards to Netscape and Microsoft

From: "William Allen Simpson" <[email-masked]>
Date: Wed, 31 Dec 97 11:24:15 GMT

> From: Bancroft Scott <[email-masked]>
> On Tue, 30 Dec 1997, William Allen Simpson wrote:
> > ... I'm not sure that I know what those non-backward compatible
> > changes to C were.  I've only been using C since 1980 (maybe '79).
> > Perhaps you are referring to something before that?
>
> There were many changes introduced that broke existing C compilers, such
> as introduction of new keywords like void, const, volatile, enum, signed,
> the introduction of function prototypes, trigraph sequences, the
> concatenation of adjacent string literals, and assignment of structures,
> unions that can be statically initialized.  Shall I go on?
>
OK, OK, I trapped you, but you cannot say that you didn't ask for it....

You have the shoe on the wrong foot.  Yes, there were some "existing"
compilers, never released outside of Bell Labs, prior to ANSI
standardization.  But, ANSI compilers have always been backward
compatible with prior ANSI compilers.  Note my choice of date :-)

You see, we are not talking about whether old K&R _compilers_ were
obsolete; rather, whether new compilers could process old running _code_
correctly.  It has been my experience that new compilers have no problem
compiling and running old code.  That is, they are backward compatible!

Are all ASN.2 compilers completely backward compatible with ASN.1 syntax
and running code?

> And there were many changes that used to work in the first version of C
> that cannot be compiled by C compilers that conform to the current
> version, such as use of the assignment operator =+, the free mixing of
> pointers and integers without the use of casts, external declarations
> without any specifiers or qualifiers.  Shall I go on?
>
Actually, mostly these merely generate warning messages, and even those
can be turned off in all modern compilers.  And most importantly, the
code still links and runs on the original platform.  You chose some bad
examples there, that do not support your case for ASN.1 versus ASN.2.

Exactly what is this PER -- as opposed to BER and DER?

Will currently running ASN.1 implementations correctly interpret all
bits-on-the-wire generated by ASN.2?

> > Good, so there will be no problem with our MIBs?
>
> The syntax of MIBs changes slightly, but the essence of the function
> they play, how they are used, etc., has not changed.
>
And therein lies the rub.

I've got bad news for you.  Nobody is going to go through another syntax
change for MIBs.  And the most important feature of MIBs is that the
bits on the wire do not change in incompatible fashion, so that old bits
will interoperate with newer bits.

Using ASN.1 for MIBs was probably the worst design choice made in the
history of the Internet.  And it was made based on politics, rather than
technical excellence.  We should have learned our lesson.

> > # ASN.1:1994 was anything short of beautiful?
> >
> > With whom does NetMeeting interoperate?
> >
> > With whom does VideoPhone interoperate?
>
> They interoperate with each other, and with IBM, AT&T, PictureTel,
> VideoServer, Compression Labs, and with most of the other International
> Multimedia Teleconferencing Consortium members that have products
> deployed.
>
> > And more importantly, do they interoperate with sd?
>
> Never heard it.
>
(Chuckle)  I'll note that you elided without comment the observation
that "beauty is in the eye of the beholder".

Yeah, I kinda figured that you would not have heard about what we've
been using on the Internet for 4+ years, rather than proprietary
Johnny-Come-Lately.

Are you sure that NetMeeting and VideoPhone interoperate over IP?  On
any BSD or Linux platform?  Maybe you could give a demo at LA?

At least for me, it is time to "put up or shut up".

The consensus of the rest of the us appears to be that ASN.1 and/or
ASN.2 are not good choices for any Internet Standard.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: [email-masked] (Christian Huitema)
Date: Wed, 31 Dec 1997 09:31:09 -0500 (EST)

> any BSD or Linux platform?  Maybe you could give a demo at LA?

NetMeeting uses an Intel compatible H.323 stack. They do interoperate.
However ugly.  H.323 fills more than 400 pages in 4 books to explain 
how to set up a video conference.  At the end of the game, they use
RTP to transmit video and audio, just like your average MBONE tool.

I don't think anyone succeeded in porting this on Unix.  Actually,
H.323 is an example of how ASN.1 can be used to design an overcomplex
solution to a simple problem, a solution with so many options that
implementations that start from the standard text have almost no
chances to interoperate.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 31 Dec 1997 11:20:48 -0500

> > On Tue, 30 Dec 1997, William Allen Simpson wrote:

snip

> examples there, that do not support your case for ASN.1 versus ASN.2.

snip

Bill, 

Not sure about *all* of those "Johnny-Come-Lately" companies. But
in some ten years working off and on at IBM, I've never once seen
them willing to tolerate warning messages in a product that they 
were willing to ship to a customer. Folks I worked with were never
allowed to just switch them off and pretend there was no problem. 

I'd be shocked to find that the same disdain for low quality didn't
exist at the other "Lately"s.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

---

From: "William Allen Simpson" <[email-masked]>
Date: Thu, 5 Mar 98 15:09:03 GMT

I sent Jonathan Clark some examples of worldnet relaying and forged
headers from att subscribers....

In particular, mtigwc04.worldnet.att.net ([204.127.131.33]) seems to be
wide open!

[email-masked]

---

From: Sascha Ignjatovic <[email-masked]>
Date: Thu, 5 Mar 1998 16:50:05 +0100 (MET)

>     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

but anyway  

it is a legal problem hier and not only a technical 

when some companys uses a name from some other company in a abusive way

the abused company hase the RIGHT and DUTY to FIGHT this over

if they dont and just trys to close "holls" it solves so not the real
problem 

the abusive missusing of companys names and trademarks 
this problem remains unsolved with "closing the holls"

they should also close the "juridical holl" by joining a cooperation and
process with some other companys and organisations/states and develope 
policy and jurisdiction wich would prohibite i the future missusing 
and fooling their good names and property

thats the wholle point hier 

after that is solved the technical one may be easyer to solve 

you just have to filter out the fantasie domains who hase no dns entry and
respons 

it musst be ilegal to use other companys domain names to do something
nasty/ilegal and so to cover your the origine of the act
altough on all spam mails you would have adress and bank acount of the 
abuser

pelase exuce me i started the discussion from the point of comon sense and 
i am no a technician  but i hope that in this way i contribute just a
little to handle this broad and dificult topic of spaming 

thanks
sascha

---

From: "Jonathan Clark" <[email-masked]>
Date: Thu, 5 Mar 1998 11:05:40 -0500

He sure did...

Not so, as I explained to him privately. This machine's job is to relay
mail *from our own users* out to other Internet hosts. The examples sent
both came from our own dial-in network, ie from our own users (now ex-users).

If anyone can get to this machine from the general Internet then I would
really appreciate knowing about it.

Jonathan

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 12 May 98 17:15:19 GMT

> From: Dave Crocker <[email-masked]>
> doesn't matter what you or I believe.  what matters is that already 50% of
> the smtp sites on the net have turned off posting from outside their local
> net.  This is killing mobile users.
>
Dave, I am heartily confused by this statement.  Could you please name a
site anywhere that turned off posting from outside the local net, yet
expects outside users to participate and exchange email?

Indeed, should posting from outside a local net be turned off, then
mailing lists such as this one would not be able to operate, as they
require direct access across the net.

Now, it could be you mean _relaying_ has been turned off from outside
the local net, and in that case I agree.  But then, _relaying_ is
entirely unneeded in most cases, even within the local net.

I'm a mobile user.  Exclusively.  For well over a decade.  I have no
problems at all posting directly, using common Unix and MSDOS tools.
Heck, KA9Q NOS has had SMTP since about 1986.

Except for a few misguided MUA (Communicator, Eudora) that _expect_ a
relayer by default in their configurations, and refuse to operate when
leaving that field blank.

For Eudora, I had to get a special POP3 server (SIMS) that opens the
SMTP relay for a few minutes after POPping up my mail.  An annoying
kludge, but commercially available.

Communicator will be fixed just as soon as they release the source :-)

> In any event, I was using that as an indication of heightened concern about
> treating submission as an independent service.
>
I don't understand how submission as an independent service has any
effect on this problem.

The problem is relaying.  Relaying should be eliminated.  Submission
should be direct.  Nothing will ever stop direct submission, as it is
needed to accept ubiquitous incoming mail.

The split between MUA and MTA (assuming I got those acronyms correct --
what in the world is a MSA?) is based on misguided X.400 notions coming
from the bad old days when folks had to telnet into a dedicated host to
read their mail.  We've been beyond that for over a decade.

> The topic lay fallow for about a year.  The current urgency has reminded us
> to finish the work that was already underway.  Finish means finish, not
> start over.
>
There is no urgency.  What we have already works.

Sometimes, it is better to get the requirements right, and start over.

And when you are assigning a new well-known port, then you might as well
design a nice new protocol that is more efficient than good old SMTP
that works over a link emulating punched cards....

[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 May 1998 13:51:41 -0400 (EDT)

> expects outside users to participate and exchange email?

I would expect organizations with such requirements to use IPSEC
tunnelling, L2TP or other means to bring the roaming user "inside" the
firewall.

The problem is different for ISPs that "rent" modems from other providers,
so that they don't have any real notion of "inside."  They could possibly
link the Radius authentication with the sendmail configuration, but that
is kind of hairy.  Some form of authenticated submission looks easier to
implement.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 May 1998 18:04:04 -0000

William Allen Simpson writes:
> Relaying should be eliminated.

Do you expect users to dial in dozens of times if a remote host is down?

I agree that, in principle, the client host can handle all rewriting. An
enterprising ISP could even distribute a client-side SMTP proxy that
rewrites messages, eliminating your complaints about particular MUAs.

But dialup users will continue to demand, and receive, relaying service.

---Dan
50000 new aliases in 6 seconds. http://pobox.com/~djb/fastforward.html