Worst Bug or Shortcomings in a Standard?

Alastair asks: "Just curious what the Slashdot crowd thinks are the worst bugs ever to creep into a standard? For mine, the various security vulnerabilities in WEP would make the grade. Also perhaps the lack of a protocol field in HDLC, and which most implementations added in a non-compatible way. I'm thinking here about bugs which result in partial or total irrelevance of the standard itself, as opposed to just a lack of interest in adopting it."

Comments

SMTP has no sender authentication.

[OneDeeTenTee]

'Nuff said.

Re:SMTP has no sender authentication.

[Homology]

'Nuff said.

Not really. SMTP was designed a long time ago where there was little need for sender authentication. At that time the "Internet" (ARPAnet) was much smaller and friendlier than todays predatory Internet. Few at that time could imagine what Internat has become today. No need to blame those designers for lack of sender authentication.

Now, the design of WEP is an entirely different matter. It was very well known that a design process of a new encryption protocoll should be public, but the designers decided to do this in secret. This was a bad decision going agains best practices.

Re:SMTP has no sender authentication.

[squiggleslash]

Why should it have had?

SMTP is merely a transport system. Authentication, if wanted, was supposed to be part of the bodies of email messages according to whatever standard a user wanted.

SMTP's lack of sender authentication is a modern-day fetish of the anti-spam crowd, and that anti-spam crowd only wants it because back when ISPs were deciding between giving users dedicated IP addresses or dynamically providing them, a debate that raged in the mid-nineties, they ended up going for the relatively anonymous dynamic IP addresses for the most part, which meant it became impossible to track email back to its original sender. Everything we've seen since with the explosion in spam and the more and more extreme methods of dealing with it really goes back to the fact that we no longer can associate an abusive user with an IP address.

SMTP was designed at a time when the entire internet was peer to peer. In the process of turning it into a consumer product, many decisions have been made that while understandable (dynamic IP was seen as easier to maintain, roaming became seamless and efficient) nonetheless sat uneasily with how the Internet had been built thus far.

"Referer"

[typhoonius]

This is stupid, but it bugs me that we're stuck with "Referer" in HTTP.

Re:"Referer"

[Anonymous Coward]

The "teens" are a relict of the old way to count (fourteen = four-and-ten), the way it still is in German and partly also in the Scandinavian languages. (26 = sechsundzwanzig (German) = seks og tyve (Norwegian, old) = tjue-seks (Norwegian, new) = twenty-six)

twelve = (old English) twa leofan which basically means two-ten
eleven = end leofan

Re:"Referer"

[Haeleth]

When you're counting something, for example days, you need to put a suffix on the number like '1st, 2nd, 3rd'. Suffixes by itself wouldn't be so bad, but the way it's determined is quite wierd. . . . In Japanese, you write it without suffixes, and even without plural forms, making it much easier to code incremental counts.

Sure, Japanese is so logical.

Let's consider the days of the month. "One" is "ichi", and "day" is "hi", so we put them together and get "tsuitachi". Then for the second, "two" is "ni", so we put that together with "hi" and naturally that produces "futsuka". Observe the transparency and regularity. Could Spock himself have come up with a more logical system?

And what about the teens themselves, anyway? Why don't you just write it as ten-one, ten-two, ten-three, like you do for twenties and beyond? That's how it's done for Japanese, and I find it much simpler.

Er, what did you think "fourteen" was, other than "four-ten"?

Sorry, but Japanese is no more logical than English. And numbers are one of the worst features of Japanese, not the best. (Did you forget about counters? You know, where you count books by the volume, pens by the book, and rabbits by the wing?)

XML. For existing at all.

[baadfood]

Sure a well defined markup language is nice but really, people seem to loose all rational sense when it comes to XML - It cannot be used in a project without the project becomming "XML"? Scripting languages have been capable of processing all manner of free form text files in the past but somehow XML is necessary for interoperation? Why do people somehow think that XML encapsulated data will be small and quick to parse and are then suprised when it isn't? Why are they so fucking proud when their server can generate some trivial number of XML packets per second? What nutjob actually thought XML is easy to read? And what is the difference between a node an an attribute? Really?

Re:XML. For existing at all.

[Anonymous Coward]

Config file in XML:

<?xml .... ?>
<config>
<connections>
<connection>
<type>mysql</type>
<host>foo.bar.com</host>
<username>bob</username>
<password>2sekret4u</password>
</connection>
<connection>
<type>mysql</type>
<host>db.host.com</host>
<username>jane</username>
<password>flower</password>
</connection>
</connections>
</config>

Config file in (example) YAML:

connections:
- type: mysql
host: foo.bar.com
username: bob
password: 2sekret4u
- type: mysql
host: db.host.com
username: jane
password: flower

Which is easier to read? to type from scratch? to quickly edit (add another connection entry for instance)? And this is just a *simple* example. Ever work with an Ant build file? *shiver*

XML is almost always the wrong solution. Not that it isn't useful for some things, but I'd rather never see XML again than have to deal with systems like the above.

Re:XML. For existing at all.

[Anonymous Coward]

What XML gets you is a single, formalised syntax with very clear, precise rules about what characters are allowed where, how to escape special characters, and so on.

Oh. That.

You're allowed to write, say,

foo&#000a;

but not

beep&#0007;

But since it's useful to do -- the alternatives being to add a non-human-readable encoding layer, or an additional application-specific escape convention -- some software does it anyway. And then more anal-retentive software chokes.

This is solved once.

Where "solved" means "it's not going to be fixed".

Ceterum censeo, XML delenda est.

Use of floating point for date/time

[AndroidCat]

Microsoft, in their infinite wizzbang, uses a floating point representation for date/time in their OLE types, with the date (days from x) in the integer and time in the fraction. That's fine until you have to do math like timezone conversions. If you convert a local time to GMT then to someplace else and back, frequently your time is now off by 0.0000000001 seconds. That adds excitement to comparing two times, especially when only one has been converted to and from.

It's not a huge problem to avoid, but unless you're draconian about using standard safe time math routines, it'll bite you .. eventually .. when you least expect it .. at a customer site running Martian Standard Time at local midnight. (Which will still be a bad hour for you to get a call no matter where it is.)

And all because someone thought it would be pretty nifty to use floating point. Don't they teach the inherent dangers of round off or truncation errors in school these days? (And before someone automatically jumps on MS, with all the UNIX standards, what are you using? Is it safe?)

Re:Linux Installation

[dpilot]

Just "emerge quake3"

Actually, I *almost* agree with you. The real problem is that Windows Wizards work most of the time. But when they don't, they work against you - even worse than not being there. They get in your way and make it hard to do things manually.

I began preparing to leave RedHat when RH8.1 never happened, and they went staight to RH9. After looking for a while, and evaluating various distributions on their maintainability, etc, I came to a different realization: For home use, this is supposed to be a hobby. What the heck am I doing looking at maintainability as a prime criteria, when I should be looking at fun and the learning experience?

So I ended up going with Gentoo. But far from being merely 133t, I find it incredibly maintainable, and I have never had such an easy time installing more, and more varied, software on any system. That includes Linux and Windows. I'll agree that Gentoo is still too intense for a novice, but with a little experience it brings a LOT to the table.

C++

[Grab]

The overloading of the bit-shift operators > for streams in C++. Kludge city! And C++'s templates don't exactly come out smelling of roses either.

Grab.

IMAP

[Anonymous Coward]

IMAP should be a powerful idea in principle but it looks like it has been implemented by people who haven't had much experience with programming concurrent systems. I've learn about this the hard way while writing an IMAP server.

Using IMAP it should be possible for several clients to connect to the same account simultaneously. Changes made by one are reflected in the others as they happen, since the server sends updates describing these changes. Think model-view-controller. (Some clients ignore these updates, but that's another problem.) This is great in theory, but I'll mention two ways in which it's broken.

First, each client connection can receive updates for only one mailbox at a time. There is no fundamental reason why this has to be, but that's how IMAP works. So you can't be notified when new messages arrive in mailboxes other than the one you're viewing. Clients have to poll to work around this.

Second, messages have message numbers and these change when a mailbox is expunged. But there is a race condition: if one client expunges and another fetches, the second may get the message as numbered before or after the expunge. There is no way to work around this apart from disabling expunge.

The conclusion that I came to in the end was that for something as complex as what IMAP is trying to be it would be much better to build a standard on top of an abstraction layer like CORBA. CORBA provides an efficient binary over-the-wire protocol, rather than the ASCII of IMAP, and has been developed by people who really understand the concurrency issues inherent in the problem.

EIDE

[Deliveranc3]

Reversable cables? Come on that is so unnessecary! And making them wide and flat come on!

Plus the whole master/slave system is kinda fun.

Basically it's the only thing a novice couldn't figure out on their own when doing an install :(

Re:DCE and DTE i RS232

[cow-orker]

Luckily, RS232 are dying ;-)

Yeah, but Ethernet repeated the same mistake and is sure to stay for a while.

Session Initiation Protocol

[Bookwyrm]

Beyond basing a standard for managing stateful telecommunications sessions on a protocol for stateless bulk data transport, the most blatant silliness in the SIP standard was the original "Alert-Info" header. The Alert-Info header allowed the calling party to specify the ring tone/sound by listing a URL that the receiving device would automatically attempt to fetch and play without waiting on the recipient user to allow/disallow it.

Others:
List of Evil SIP ideas

Oh, and never updating the SIP version string despite syntax changes in the standard is evil.

NFS

[tedgyz]

NFS is inherently flawed in it's transaction acknowledgement and retry behavior.

Back before M$ had Linux to kick around, there was the UNIX-Haters Handbook. I worked at Apollo/HP with a UNIX-Hater zealot. He enlightened me on the serious flaws in NFS, which I had experienced first-hand on a few occasions.

A quote from the book: (page 287)
So even though NFS builds its reputation on being a "stateless" file system, it's all a big lie. The server is filled with state--a whole disk worth. Every single process on the client has state. It's only the NFS protocol that is stateless. And every single gross hack that's become part of the NFS "standard" is an attempt to cover up that lie, gloss it over, and try to make it seem that it isn't so bad.

Re:DCE and DTE i RS232

[ClosedSource]

The problem is that RS232 is (was) being used for things it was not designed for. It was never meant to be a general purpose serial communications standard.

SQL

[TheLink]

Plenty of stupid stuff in SQL.

Why a different format for update and insert?

update table set field1=value1,field2=value2 where rowid=x

vs

insert into table (field1,field2) values (value1,value2).

--
I don't know about "worst" but could the SQL standard be partly to blame for why porting data from one DB to another is hard in most cases...

e.g. not covering stuff that most people find useful or even vital? And thus letting Oracle etc each define their own ways of doing things.

SQL !!!

[Anonymous Coward]

Many years ago Edgar Codd presented up a complete model for storing data: the relational model. It was complete and sound, which no other data model is. It is based on predicate logic (to give meaning to the data) and set theory. You can store any kind of data in a relational database.

To implement the relational model you just have to implement a number of set operators and relational operators (project, join, etc), and you have to enforce arbitrary constraints on the data.

Much like arithmetic (add, subtract, multiply), all you have to do is implement these concepts in a computer and you'd have a system that works very much like the model describes.

Yet, somehow, the standard that emerged, SQL, seems to be from an alien planet, bearing only fleeting similarity to the relational model.

Example: If you're working with *sets*, you should use set notation. Not "SELECT * FROM Customer", but just "Customer". Not "SELECT * FROM Customer JOIN CustomerDetails ON Customer.id = CustomerDetails.id" but "Customer JOIN CustomerDetails".

Example: SQL doesn't enforce the idea that relations are sets. So it allows columns with the same name, it allows positional specification of columns (ORDER BY 2 is allowed, but not the same as ORDER BY 1+1 by the way), it allows *duplicate rows*!! Argh. The relational model requires all rows to have a candidate key.

Example: SQL doesn't allow you to compare query results. You can't say "give me a list of customers who purchased every book by author X" without bending over backwards. In a relational expression, you can just say, roughly, "Customers WHERE (Customer JOIN Purchases) = (Books WHERE Author = 'Joe')".. notice that the first "=" is comparing two SETS.

Example: SQL has NULLs. Anybody who has worked with an SQL database knows exactly what a pain NULLs are. Quick, why does COUNT(*) count NULLs but SUM(*) doesn't? I don't know either. Certainly has nothing to do with the relational model. And to add insult to injury, SQL makes NULLable columns the default.

Example: SQL differentiates between views and tables. You can't usually update a view. However the relational model says, you should be able to interchange views and tables completely. This means the most powerful abstraction feature of the relational model is completely missing! It's like programming in a language without subroutines or functions. (Yes some DBs allow a limited subset of updateable views, and some allow you to specify your own SQL triggers to update them, but that's not exactly the same as having the DB *infer* the constraints and rules itself for any view).

Example: SQL doesn't allow arbitrary relational expressions. In fact there is a special name for nested expressions in SQL: "subselects" or "subqueries". As if this is something special. How often to do you use parenthesis in your math statements "2 * (a+4)". If math was SQL, that would be "OPERATE ON (OPERATE ON a WITH 4 USING ADD) WITH 2 USING MULTIPLY" or some nonsense.

Example: SQL makes it difficult to create new types. So objects have to be "decomposed" into columns, and we have to have junk like "ORM layers" whose purpose is to splatter and unsplatter objects over and over again, instead of just being able to say "Customers" and getting a list of objects directly.

The list goes ON AND ON. When people talk about the limitations of the relational model, they are talking about the limitations of SQL!

So, yeah, SQL is the big suck. I don't know why other parts of programming have so much innovation (how many programming languages are there? Programming paradigms?), but SQL is stuck in this bizarro backwards world.

Please, if any open source programmers out there want to make something really useful, please create a truly relational database system! Just pick up any DB textbook and implement what you read, it's all there waiting for somebody to *do* it!!! I know it will happen someday....