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."

UTF-8 email headers

[dimss]

Standards are very unclear when you have to encode utf-8 'subject' header. Looks like there is no distinction between bytes and characters. I had to write automatic UTF-8 mailer last year. There were many, many issues with UTF-8 headers in different MUA. Especially with mix of english and non-neglish words in 'Subject'. Finally we decided to send two separate messages in two different 8-bit encodings.

Re:MSIE & XHTML

[Anonymous Coward]

That's not a bug/shortcoming in a specification. That's a bug/shortcoming in an application.

Funnily enough, I thought of sending XHTML as text/html when this story popped up. There is a problem with the specification.

The latest RFC for text/html claims that the XHTML 1.0 specification defines a profile that is compatible with HTML, and that you are allowed to label this as text/html.

The first shortcoming is that it doesn't bother mentioning this "profile" by name. Most people take it to mean Appendix C.

Here's the kicker though: Appendix C XHTML is not compatible with HTML. No form of XHTML is. XHTML can be compatible with most HTML user-agents, but only because most HTML user-agents don't fully support HTML.

You see, HTML allows an SGML short cut. Instead of writing, say, <h1>My Heading</h1>, you can write <h1/My Heading/, and it will mean the same thing. Or at least it should.

Only a few user-agents implement this though. Emacs/W3. The W3C validator. A couple of search engines. The rest, including every browser you are likely to have heard of, uniformly ignore this part of the specification.

Here lies the trouble. XHTML uses a slash inside a tag to mean something completely different - that it is an empty element. The HTML for a a meta element might be <meta name="author" content="foo">.

Since HTML, based on SGML, expects a fairly smart parser that can figure out from context and the document type where an element ends, this can be an empty element without explicitly marking it as such or using an end tag.

XHTML, on the other hand, had a design goal of allowing parsers to be a bit more stupid. One of the results of this was that you have to explicitly mark empty elements with a slash as the last character inside a tag. So the XHTML equivalent of the above HTML is <meta name="author" content="foo" />.

Of course, because they used a slash, instead of practically any other character, this made XHTML fundamentally incompatible with HTML. Because if you read the XHTML version as if it were HTML, it means <meta name="author" content="foo">>. Note the trailing >.

HTML user-agents that implement the shortcut will break when they encounter XHTML that is labelled as text/html. This could have been avoided by simply picking a different character to signify empty elements. Of course, because neither of the two biggest browsers ever bothered to implement this part of HTML (Mozilla still doesn't, for everybody who claims it is "standards compliant" [sic]), nobody much cares - niche browsers can go screw themselves, right?

Somebody else mentioned the Referer misspelling, but another problem I dislike in HTTP is that language tags don't generalise. For instance, if your browser sends Accept-Language: en-US;q=1.0, de;q=0.5 to signify that the user prefers American English, but can make do with German, according to the specification, a server with English (note: English, not American English) and German resources is supposed to supply the German resource to the user.

Of course, Internet Explorer and Safari come preconfigured with en-US without en as a fallback, which means that anybody who is content negiotiating can either follow the specification and be broken for these clients, or follow Internet Explorer and Safari, and be broken for any client that follows the specification.

Another problem I dislike is that of underscores in CSS 2. CSS 2 doesn't allow unescaped underscores in selectors. CSS 2 does allow unescaped underscores in selectors.

What's that? I've just contradicted myself? Not me - the CSS 2 specification. The W3C sneaked in a change to CSS under the guise of "errata". This results in people getting an error when they try and validate their CSS that contains un

Re:DCE and DTE in RS232

[Anonymous Coward]

You can't do this in general because RS232 is not symetrical. All of those modem control pins - "ring indicator", for example - have one explicit direction.

Of course we don't often use those pins any more, and the ones we do use (two data and two handshaking signals) are symetrical, so for that subset the proposal [one pinout, all cables cross over] is sensible. I think that there may even be another unused standard along those lines (RS4xx?).

Re:XML. For existing at all.

[Anonymous Coward]

Sure a well defined markup language is nice but really, people seem to loose all rational sense when it comes to XML

So in other words, there isn't a problem with the standard at all?

Scripting languages have been capable of processing all manner of free form text files in the past

And you've got to write a new parser for every new format.

somehow XML is necessary for interoperation?

Necessary? No. The best option? Usually.

Why do people somehow think that XML encapsulated data will be small and quick to parse

I see people claiming that XML is easy to parse, on account of every major language having at least one XML parser already available for free.

I do not see people claim that using XML results in small documents (except where the other format under consideration is unusually large). I do not see people claiming that XML results in quicker parsing (except in relation to SGML).

I often see people claiming that XML doesn't perform very well directly after they use the wrong tool for the job (e.g. DOM vs SAX).

Why are they so fucking proud when their server can generate some trivial number of XML packets per second?

There's no such thing as an "XML packet".

What nutjob actually thought XML is easy to read?

XML, for documents and config files, is very easy to read. It's only when you use XML for things it is unsuited for that it becomes difficult to read.

And what is the difference between a node an an attribute?

Generally speaking, nodes contain content and attributes contain metadata. There are grey areas because what people consider to be "content" and "metadta" has grey areas.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:DCE and DTE i RS232

[Anonymous Coward]

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

Luckily most of the current ethernet chipsets support auto-detection of crossover. I wont buy a switch that doesn't.

Re:Album/Track information on CDs

[belg4mit]

They do, CD Text [gnu.org] is almost never used though.

Networking in .Net / Mono

[szyzyg]

The Socket class is astonishingly broken
IPAddresses are frequently imported/exported at Longs - 8 bytes with a sign bit
Port numbers are 4 byte signed integers.

Sure, Java doesn't have a signed int or long but .Net does.

Now they introduced a way to get the IP address as an array of bytes, so that you can support IPv6, problem is the constructor that takes a byte array will only accept a 16 byte address, not a 4 byte one for us IPv4 users. On top of this they've deprecated the only other method that can get you an ip address in binary format.

So if you want to serialize an IP address you have to either get it as a Long and cast it to an unsigned int - this generates all sorts of compiler warnings, so forget about clean compiles. Or you can get the address as a byte array and then on reception you have to turn it into an unsigned long.

Oh yeah, there's no documentation on what the environment does about the endianess of IP addresses converted into longs.

Now... we''ve also got the alarmingly bad Select() method which requires you to build lists of the sockets you're interested in and then proceeds to prune these to only leave the ones where activity has happened. Problem is that you can't reuse these lists so you need to construct them every time so you end up spending more CPU on building lists than you do on simply scanning the list of open sockets. Not that it matters, .Net throws and exception if you try to Select() on a list of more than about 30 sockets.

Another retarded design decision is the implementatino of non-blocking IO and EAGAIN, they decided that this should be implemented as an exception. And we all know how fast exceptions are.

Grrrrrrrrr

I could go on and on.