Firefox 5 in W2K under windows 7 x64

Now that is really something new (for me) in Windows 7 x64:

What you see is the bottom of a 1152×768 virtual Windows 2000 SP4 desktop with quick links for Firefox 5, IE6, KeditW 1.6, etc.  The host system is a Windows 7 x64 SP1 home premium Sony VAIO (1600×900, ATI mobile Radeon catalyst 11.6).  Sadly XP mode is not supported for home premium, or rather, I couldn't test a manual XP activation, because I have no XP license key.

Some invisible details:

• VPC does not really work for guests older than XP SP3, you have to install the virtual machine additions 2004.
• Virtual PC guy posted a picture of the real network card virtualized in VPC for up to four networks.  For my purposes "internal NAT" allows me to share an existing mobile broadband WWAN connection.  This is not the VPC default, change it in the VM settings while the VM is not running — hibernating might be good enough.
• Without the VPC integration features I found yet no simple way to exchange guest and host files (including simple things like the clipboard), WebDAV on a remote hoster clearly doesn't qualify as simple.
• Using virtual floppies (VFD) is a major pain with Windows 7 VPC, but once you have attached a VFD to a VM it sticks.  You can even format the VFD.
• I didn't know how to "capture" (if that's the correct term) a W2K VHD from a genuine system, and used a public VHD.  That beast required a lot of work (tons of missing updates, removal of obscure "bars" installed by the publisher, adding A/V-software, full scan with the latest MSRT, Firefox, Flash, Silverlight, 7Zip, XnView, DirectX, Secunia PSI 1.5x, etc.).
• Just in case: Yes, WU still works for W2K — only up to June, 2010 for OS + IE6 updates, but still for any MS Office stuff.  Sadly the still working monthly MSRT requires manual downloads.  Avira announced that they'll stop to support Avira A/V Personal 10 under W2K in July 2011, which is kind of stupid: Anything better than W2K can and IMO should use MSE.
• Somewhat unrelated, normally you cannot get ATI Catalyst 11.6 for Sony VAIO from AMD, but I found an unrestricted official download link in an obscure forum.  Same procedure as for direct Flash AX downloads without Adobe's GetPlusPlus malAdware.
• The latest Intel PIU fails to install under W2K, and an older version (working for W2K) died with an obscure error in VPC.  FWIW installing DirectX 9 in the virtual W2K worked, but of course there isn't much to accelerate in a VPC.  My real W2K is far slower than the virtual W2K: The real box has 256 MB RAM, the virtual box has 512 MB, and the windows 7 host has about 3950 MB.
• Sometimes the virtual W2K hangs and needs a hard reset (= close VM).  I'm not sure when this started, among my suspects are Firefox 5, Avira Personal 10, and Secunia PSI 1.5x.  It's also possible that my (failed) attempts to install the VPC integration features, or my inconclusive attempts to install the VPC 2007 VMA screwed up the VHD.  There is a suspicious unknown device in the device manager, claiming to be working, and using IRQ7 — is this some kind of time synchronization?  To break out of a restart hanging VM loop modify the VM settings to "unconditional close" or "always ask".  Normally I'd prefer "auto-hibernate on close", but that doesn't help if the VM hangs.
• While a VHD is not running or hibernating it is relatively simple to mount it as a virtual disk in Windows 7.  Unmounting can be slightly tricky, but it's necessary to start any VM using the VHD.
• Having fun with VMs I stumbled over a simple VFD-driver and virtual CD control panel for Windows x86 platforms.  Check out Elby Clonedrive for serious virtual CD applications.  Apparently the MS XP virtual CD controlpanel 21 works also under W2K.
• At some point in time I'll have to grok the diskpart manual — it would be nice to associate .vhd with a simple attach/detach (mount or unmount) script without going to a command line or the device manager.

Shortcut icon mysteries

Tweak My Blogger proposes to use three link relations to replace the default Blogger favicon with a custom favicon. Historical background:

There can be various link relations in the <head> element of HTML or XHTML pages, e.g., <link rel="search" … /> for OpenSearch descriptions. For favicons IE originally used the old Windows .ico format. That's a kind of container for related Windows .bmp images in various sizes and with different numbers of colours. A favicon .ico should include an image with size 16×16 and up to 256 colours, and it is not required to offer other sizes. If compatibility with say IE5 is not your main problem 32×32 or 64×64, and more than 256 colours, might also work: Applications are supposed to pick the best image offered in an .ico for their needs, and scale it up or down if necessary. If an automatically scaled down image does not work for your icon the .ico format allows to include optimized smaller versions, notably 16×16.

Years ago there was no proper MIME type for these beasts, but type="image/x-icon" was widely supported. Later Microsoft registered type="image/vnd.microsoft.icon for this purpose, and modern browsers are supposed to know this type as far as they support the odd .ico format at all.

Web servers might be still configured to associate .ico with image/x-icon, but that does not affect a correct image/vnd.microsoft.icon in the <head> of pages. Without a link relation IE simply tried to fetch a file favicon.ico from the relevant directory. For various reasons that was a bad idea, and modern browsers rely on explicit link relations instead of default locations for favicons and other purposes.

Other browsers and other platforms were not eager to support the odd Microsoft .ico format, but liked the idea of shortcut icons. A much better format is .png, but some old browsers including IE did not support it, or had issues with certain PNG-features. Somehow these differences resulted in two link relations, rel="icon" and rel="shortcut", for in essence the same purpose. Only rel="link" is registered at the moment. It is possible to list more than one relation as in rel="shortcut icon", and today that should be good enough if the favicon is an .ico.

If you seriously hate this image format try rel="icon" type="image/png". GIF instead of PNG is also okay, of course excluding animated GIFs. Other formats are either unsuited for a favicon, e.g., JPEG and WebP, or still less widely supported, e.g., SVG, which will be an ideal solution for most kinds of icons.

So far for the theory of the favicon business. The practice on Blogger and other sites can be slightly more complex. IIRC you can't use the name favicon.ico, just pick something else, e.g., href="http://example.org/my-icon.ico" if this really is an .ico with MIME type="image/vnd.microsoft.icon". Whatever Blogger does, the type="icon/ico" recommended in Tweak My Blogger makes no sense, and at least in theory (not tested) more than one link relation is unnecessary. My Blogger template contains the following line immediately before the <title>:

<link href='http://purl.net/xyzzy/xyzzy.ico' rel='shortcut icon' type='image/vnd.microsoft.icon' />

Sadly Google reader still shows the Blogger icon for the feed, and unsurprisingly a Google profile still shows the Blogger icon for a Blogger profile, but otherwise it works as expected. Maybe create a 57×57 PNG for I-Phones and I-Pads, and use the (unregistered) link relation rel="apple-touch-icon", it can't get odder. I have no I‑Panything to test this.

URL fragment vs. query part

Has Google finally reached the ultimate Microsoft state, "breaking standards for fun and for profit" ? In a recent entry on the Google Operating System blog (not affiliated with Google) two screen shots show #fragments instead of ?queries. My attempt to post a comment had no visible effect, maybe comments are moderated or the blogger template is broken or whatever the problem might be, zero feedback to users is just wrong. Google Chrome lost the content of the comment form before I could reproduce it verbatim here, in essence it said:

In URLs a hash mark "#" introduces the optional fragment at the end of the URL, and a question mark "?" introduces the optional query part — also at the end of the URL, but before any fragment.

Fragments are the local business of the client (browser) and depend on the document (MIME type). Queries are the business of the server, e.g., many servers expect name=value pairs separated by ampersands "&", other severs also permit semicolons ";" as separator, and so on.

The query syntax depends on the scheme, here http:, the details depend on the server, but in both cases the overall URL syntax would require to percent-encode "#" if it is a part of the query not intended to start the fragment.

Notably fragments do not participate in redirections from one scheme or server to another scheme or server, the target location never sees the source fragment — browsers are not expected to transmit a fragment in requests such as HTTP GET.

In other words, something is wrong in the googlesystem screen shots.

Google - you get what you paid for

With a few exceptions Google services have the unacceptable feature to be associated with an account forever. So if you test say "feedburner" once, and then decide that this is yet another data kraken and never use it again (for years), it will still be listed in the Google accounts dashboard. In theory you could delete the complete account including blogs, mails, images, videos, docs, sites, etc. — in practice folks trying this often show up in the blogger help forum whining about their lost blog and images.

Episode 1: I sent a complaint about "google moderator" to Google's privacy officer. This is actually an obscure HTML form creating no confirmation mail and no ticket number. After weeks my privacy complaint still got no reply. I'll test it again when I get around to it, complete with screenshots of the HTML form, as this isssue might require an intervention by Hamburg's privacy officer.

Episode 2: My entry in "places" is associated with an off by two photo in "maps". After a considerable amount of time I figured out how to report this issue. This actually resulted in a timely mail answer, but the mail came from a noreply bounce address offering no way to answer. My report was that they swapped the photos for house X and X+2. Sh*t happens, this was incorrect, they systematically show X+2 for X for the given street. I have no way to fix my semi-erroneous report, this is stupid. Never send noreply mail if you are not a mail-bot, this infuriates customers and users. Why should they use valid and valuable mail-addresses, when the other side uses bounce-addresses?

Episode 3: The new Chrome "apps" store apparently records all installed apps, even after they were removed. I submitted a complaint about this, because I do not recall where or when I permitted this violation of my privacy, and I certainly do not know how to withdraw this permission.

mailto: URLs

If you think that mailto: URLs are rather boring in comparison with http: you have a point, most mailto: URLs in the wild are straight forward and simple. But the syntax specified in RFC 2368 was based on

1. the RFC 1738 URL specification (1994),
2. the old STD 11 in RFC 822 (1982).

Updating the mailto: specification therefore had to replace the old (and tricky) RFC 822 syntax by the new RFC 5234 ABNF in STD 68 published 26 years later (2008). The actual content of RFC 822 is the Internet Message Format as used in e-mail and now specified in RFC 5322, the successor of RFC 2822. For URIs we are now at STD 66 in RFC 3986 (2005) with various subtle differences from the eleven years older RFC 1738. You won't often see these differences, but clearly there was no such thing as IPv6 in URIs back in 1994. UTF-8 was rarely used, supported 31bit Unicode points, and permitted "overlong" encodings — not exactly the STD 63 rules in RFC 3629 (2003) we use today.

The general syntax for URIs in STD 66 and the specific syntax of e-mail addresses in RFC 5322 are not directly compatible, some characters permitted in addresses are not permitted "as is" in URIs and have to be "percent-encoded" based on the hex. UTF-8 encoding. It's a miracle that the new mailto: URI specification in RFC 6068 managed to close these gaps in 2010, twelve years after RFC 2368. There are lots of interesting examples in RFC 6068, my favourite is a clever use of In-Reply-To e-mail header fields. The complicated examples are also fascinating. If you create a complicated e-mail address your chances that it works anywhere in a mailto: URLs are now better. Well, at least it is specified, implementing it at the interface of browsers and mail user agents is another story. Well done, one "like" from me to RFC 6068.

Service Status Feeds

My favourite tool for 2009 and 2010 — while I was mostly offline — is Google Reader, the feed reader offered by Google for "popular browsers" (read: IE6, FF2, or better), because it dutifully kept all my subscriptions, and still works like a charme.

In a Gmail blog article Google reported a bug in the Gmail service, apparently my account belongs to the 99.98% not affected by this issue.  The article mentions an Apps Status Dashboard showing the published issues for various Google services including Gmail.  Some years ago I would have added this page to my bookmarks, and checked it when something went wrong.  Today it is much simpler to subscribe to the relevant RSS feed — hopefully this results in no updates when there are no known issues.

Two other examples of status feeds are Blogger and DynDNS.

RFC 6055: IAB Thoughts on Encodings for Internationalized Domain Names

The new RFC 6055 is quite interesting, it discusses issues of IDNA vs. UTF-8 encodings in the DNS and other namespaces.

By definition any valid IDNA A-label, i.e., an ASCII compatible label starting with xn-- and following the IDNA rules specified in RFC 5890 and RFC 5891 (among others), has a corresponding Unicode U-label, i.e., a label containing non-ASCII characters. The IDNA encoding mechanism punycode tries hard to create short A-labels, because there is an upper limit of 63 octets per label, and another upper limit of 255 octets per FQDN DNS query consisting of zero or more labels.

RFC 6055 does not propose to use redundant UTF-8 DNS entries for raw U-labels in addition to the IDNA A-labels, so I guess there are too many cases where this would anyway not work, e.g., when an otherwise valid U-label consists of more than 63 UTF-8 octets.

When I get "a round tuit" I'll look into a now long expired EAI SPF draft, where using raw UTF-8 labels was the only viable solution for an EAI extension of SPF. Even if nobody implements this draft and/or if EAI never really makes it the last "tombstone" version should reference RFC 5321 (SMTP), RFC 5890, RFC 5891, and RFC 6055.

John Klensin is the author or a co-author of all RFCs mentioned here. I should check what else he published between RFC 5321 and RFC 6055, but it is nice to see that for at least one person in the world "RFC" still works as a "Request For Comments". :-)

MD5 1.7: verified errata

All pending errata for the MD5 test suite are now verified by the IESG; thanks to Alexey Melnikov. The oldest erratum 749 about an MD5 example in RFC 2069 was submitted 2005-02-06 and verified 2010-07-11. Now I feel less bad about dropping out for two years.

For historical reasons the MD5 test suite is one of my REXX scripts still published as cmd-file instead of a rex-file. On an OS/2 box REXX is the default scripting language using file extension cmd. An ordinary OS/2 cmd.exe-shell script never starts with "/*"; any script starting with "/*" is interpreted as REXX.

Good old PC DOS 7 uses extension bat for command.com-shell scripts, and the text editor KEDIT uses kex for its macros; both also identify REXX by "/*" in line 1.

Please do not feed OS/2 REXX cmd-scripts to the Windows NT cmd.exe-shell; you would get numerous errors. For NT simply rename md5.cmd to md5.rex and let ooREXX interpret it.

WebHop DDoS

DynDNS reports a DDoS attack against their Webhop services. This also affects xyzzy.webhop.info and xn--80akhbyknj4f.boldlygoingnowhere.org. The first address used to be a HTTP redirection to my mirror site, at the moment it is a redundant redirection to xyzzy.

The second address is used in some IDNAbis experiments with IRIs; the actual content are now subpages of xyzzy/home/googlets.