purl.net/xyzzy

Reviving this dead blog was possibly maybe a bad idea, but I'm still terrified to get a Twitter account to replace G+ in April, maybe Blogger is goodbad enough. At least it still works, and apart from Gmail I'm not aware of any other still working Google product. #GirlsGotGroove could be an argument for Twitter, "registering" hashtags is about as much fun as playing with WikiData.

The old websites are now all gone, R.I.P.: 2004, 2010, 2012. For the required legalese I trusted that "click on banner + click on imprint" covered your privacy also for this blog, i.e., there is no such thing as privacy on Google products, and if you allow third party cookies SoundCloud.com (example) will track you on any page with an SC iframe (=technical term for an embedded object, ignoring images + applets.)

SC politely asked to put that info into any affected privacy policy, so consider it done here for this blog until I get a static blogger page for some remotely legal legalese. I still don't do analytics or monetisation or cookies, not here, not on YouTube, nowhere, period. BTW, get an AdBlock, and disallow JavaScript on all sites complaining about it, c.f. chrome://settings/content/javascript.

DynDNS killed xyzzy.webhop.info some years ago, IIRC it was a redirect to my Google Apps account. Meanwhile Google also killed the target, good riddance.

DynDNS also killed xn--80akhbyknj4f.boldlygoingnowhere.org and xn--xyzzy.boldlygoingnowhere.org belonging to my i18n-fun pages here. That's sad, but the fun factor was possibly maybe limited to some folks I (virtually) met in IETF WGs. All is well if it ends well, SPF is a proper RFC now, the technically dubious (or ethically too ambitious) Sender-ID is dead, and I even produced a silly RFC to balance the IAB appeal.

YAM (Yet Another Mail)

The ways of the IETF are completely bizarre, and the Tao of IETF does not really explain why.  In a recent episode the YAM WG will be closed after moving two of four e-mail related RFCs to STDs:

• STD 72 is RFC 6409 and covers "mail submission".  That's what ordinary users like you and me do when they send e-mail using their ISP or another ESP such as Gmail, GMX, or Hotmail.
• STD 71 is RFC 6152 and covers "8BITMIME".  That's what everybody uses since about 1993 outside of pure US-ASCII 7bit e-mail.

Oddly YAM didn't finish the work on a 5321bis and a 5322bis.  That leaves us with STD 10 (SMTP) and STD 11 (message format) in limbo, unless you still consider RFCs 821 and 822 (vintage 1982) as the ultimate truth in IETF e-mail standards.

For SPF it's quite interesting to look at the "reverse path" fine print of RFC 821, e.g.:

• The first host in the <reverse-path> should be the host sending this command. (RFC 821 about MAIL FROM).
• In any case, the SMTP adds its own identifier to the reverse-path. (RFC 821 about Relaying).

Sadly RFC 4408 specifying SPF also claims that this RFC 821 feature is archaic.  Of course today nobody uses reverse and forward paths as designed about thirty years ago for e-mail routing, but for SPF the MAIL FROM address is still supposed to indicate the responsible party for technical problems with an e-mail, also known as bounce address.  And e-mails forwarded to a third party need a new envelope sender address, otherwise SPF checks at this third party will fail, because IP-addresses authorized to send e-mail from the first party won't match IPs used by the forwarding second party.  That's as simple as it can be, ignoring the minor detail that RFC 1123 broke it about twenty years ago.

By the way, the work on 4408bis is supposed to start really soon now, but my confidence in the IETF is somewhat limited.

Customised Search Engines

More than four years ago I explained the secrets of LP and AH in a Google CSE query parameter cof=FORID:0%3BAH:center%3BLP:0. The percent-encoded hex. %3B is a semicolon separating FORID:0, AH:center, and LP:0 in this example going back to Google's ancient free site search.

This undocumented cruft is now seriously dead, or rather, AH:center and LP:0 now have no visible effect. Maybe the cof= parameter was removed while some new CSE features were introduced since June, see an entry on the Custom Search Blog — I've no idea what the Element might be, and the officially deprecated features didn't mention any undocumented cruft, but there, it's dead, and the new layout for CSE search results hosted by Google works fine for the xyzzy CSE. Fortunately I modified it to work on the CSE layout test page some months ago, and as it happens that is now apparently good enough for new search result pages without AH:center and LP:0.

I'll remove any remaining obsolete cof= parameters where I find them, it might be hidden in obscure places such as the template for this blog, persistent URL (PURL) redirections, rel="search" link relations in the header of my web pages, and a tiny CSE googlet (PURL of XML source).

BTW, if you were always looking for an IETF-related search engine test the xyzzy CSE as shown near the bottom of all web pages for this blog. I still update this CSE when I find new promising sites, one of the last additions was a site tracking link relation registration requests. I added it after the registration of link relation rel="canonical" on the corresponding IETF expert review mailing list.

And if you were always looking for a REXX-related search engine check out my second (and last) REXX CSE — I rarely use it, but fix it when I stumble over broken links on my KEXX page. For a recipe to convert CSEs given by their cx= ID to OpenSearch Description Documents see another four years old entry on this blog, or just adopt one of the OSDDs on my googlet page.

about: ftp:

There are I-Ds for two URI schemes:

1. about: URIs tackle about:blank and similar beasts.
2. ftp: URIs are another missing piece in the quest to finally get rid of RFC 1738.

Please review these drafts and send any feedback to the relevant IETF mailing lists — subscriptions are cheap, they cost you a working e-mail address. ;-)

So far nobody volunteered to finish the existing file: URI I-D (2005).  There are some dragons with respect to different browsers and operating systems, notably IE vs. Firefox and Windows vs. Linux, but really, almost any file: URI scheme RFC based on the work for other schemes would be better than RFC 1738 vintage 1994 today.  And you are not forced to emulate some negative records created by me for RFC 5538.  I think file: and ftp: URIs are the last missing pieces in this puzzle.  Check out the mailserver: (RFC 6196) and tn3270: (RFC 6270) URI schemes for pieces added in 2011.

Completely unrelated, and not deserving a separate article:  I've recently added a CC-BY-SA license for this blog.  That is mostly an experiment to show my support for Creative Commons and Wikimedia Commons as explained on my commons page with a fascinating (but long) video of a CCC lecture by Lawrence Lessig in 2006.  Clearly I can't revert this license to some more restrictive form for existing pages, but maybe I'll change it to public domain in the future if I feel like it, or if somebody asks for it with a sound reason (from my POV).

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.

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.

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.

videotex

Instead of a thank you to the news.t-online.de team in RFC 5538 I added the historic videotex: URI scheme to the IANA registry.

When the WWW with http: and https: started to replace gopher: and various videotex: systems (BTX, minitel, Prestel) this URI scheme allowed links to videotex: resources for browsers supporting it. It was a nice system for limited clients including DOS boxes, but the software to create videotex: pages was very expensive.

Is it only me, or do we really invent the wheel again and again ? Now we have WAP and a .mobi TLD, but what was wrong with telnet: and gopher: ? At least ftp: is still alive and kicking. And maybe news: survives.

If you know a public specification for an unregistered URI scheme, please submit it to IANA following the rules in RFC 4395 — in a nutshell this is a public review on an expert mailing list.

RFC 1849

The famous son-of-1036 Internet Draft about the Netnews article format was published as historic

• RFC 1849: "Son of 1036": News Article Format and Transmission

Son-of-1036 (also known as 1036bis) was the first Internet Draft I've ever seen 15 years ago. Admittedly I didn't know the exact difference between draft and RFC at this time, let alone the various RFC series and status flags.

RFC 1849 was immediately obsoleted by the work of the IETF USEFOR WG:

• RFC 5536: Netnews Article Format
• RFC 5537: Netnews Architecture and Protocols

Folks interested in Usenet & Netnews can be rather stubborn, one of the reasons why this WG needed more than a decade to finish its work (presumably a new IETF record). Thanks to Charles Lindsey, Russ Allberry, Ken Murchinson, Henry Spencer, Alexey Melnikov, Harald Alvestrand, Lisa Dusseault, and many other contributors on the USEFOR mailing list.

Thanks also to anybody helping to publish…

• RFC 5538: The 'news' and 'nntp' URI Schemes

… while I was offline for more than two years. That this RFC took so long was clearly my fault. Anonymous credits I coludn't add in this RFC: The news.t-online.de team triggered my interest in an Internet Draft by A. Gilman about news:, nntp:, and snews: URLs. Later Paul Hoffman started the work to obsolete all old URL schemes in RFC 1738 by new RFCs based on the Internet Standard for URLs (STD 66, RFC 3986).

There are still some schemes in RFC 1738 not yet obsoleted by fresh RFCs, notably file:. Maybe Martin Dürst could finish his work on the awfully complex mailto: scheme, I have not yet checked this. If you find no old URL scheme to work on try dict:.

Leader of the pack

Keeping Internet Drafts "active" with two updates per year is a subversive tactics, but apparently already in use: Version 02 and 04 of the pack URI drafts are identical. This draft cannot be published as RFC, because its proposed URI scheme syntax is in conflict with the generic syntax in STD 66 [RFC 3986]. This is not permitted in BCP 115 [RFC 4395] about the registration of URI schemes, as noted by the URI review expert.

The pack scheme has to be fixed before it can get a permanent registry entry. The current entry is provisional, and the unmodified draft could be an attempt to prevent the reclassification of this wannabe-scheme as historical. The greater picture is that the Open Packaging Convention is a part of ECMA 376, the fast track input for ISO 29500 also known as ooXML.

SPF EAI and IDN TLDs

SPF, EAI, and IDN TLDs are not directly related, but I ended up as author of two related Internet-Drafts: SPF EAI is now at version 03, and the IDN test TLDs are already at version 11.

The new 2606bis draft with the eleven IDN test TLDs now also covers the corresponding nine IDN example labels. Reserving the nine IDN example TLDs is one of those procedural stunts. The contributor tricking me into this adventure does this all the time, it's scaring.

For what's it worth, there is also a relatively new OpenSearch draft, most of it still TBD. It depends on a cleanup of the IANA Atom link-relation registry adding the mostly identical HTTP link-relations and other missing pieces.

No plans to transition management of the root zone file to ICANN

In a letter to the ICANN Chair published 2008-07-30 the U.S. DoC notes:

First, it is important to note that the IANA functions contract was not part of the JPA mid-term review and the Department views these as two distinct instruments. As the community is aware, the IANA functions contract covers the performance of a series of currently interdependent technical functions that enable the continued efficient operation of the Internet, including processing requests to change the authoritative root zone file. Implementations of changes to the authoritative root zone file are performed by VeriSign under the terms of a separate agreement with the Department.

The Department believes that it is important to clarify that we are not in discussions with either party to change the respective roles of the Department, ICANN or VeriSign regarding the management of the authoritative root zone file, nor do we have any plans to undertake such discussions. Consistent with public statements made by the United States governement starting in 2000 and reinforced by the 2005 U.S. Principles on the Internet's Domain Name and Addressing System, the Department, while open to operational efficiency measures that address governments' legitimate public policy and sovereignty concerns with respect to the management of their ccTLD, has no plans to transition management of the authoritative root zone file to ICANN as suggested in the PSC documents.

In an article about the All important IANA the author wrote: An ICANN that is completely privatised and does not behave well afterward also might easily be stripped from the IANA contract and therefore its grip on the root zone.

Frisian frs vs. stq

Before 2006 there was only one language tag for the Frisian languages, fy. 2005-11-16 ISO 639.2 identified fy as Western Frisian, adding frr for Northern Frisian, and frs for Eastern Frisian. So far it is clear, ignoring the detail that Northern Frisian consists of several rather different dialects.
 
After the publication of RFC 4646 the IANA language subtag registry now contains fy, frr, and frs. But not fry, this is an alpha-3 alias of fy, and the RFC 4646 rules are roughly that shorter alpha-2 ISO 639 codes win.
 
It is not obvious what the Y, R, and S in these subtags stand for, one plausible theory is that S stands for Seeltersk, the Frisian language spoken in Saterland; see the S marker on the map.
 
Interestingly ISO 639-3 uses stq instead of frs for this language, this is also the code used for the stq.wikipedia. Two alpha-3 ISO 639 codes for one language are rather strange, and there is another theory to explain this situation: frs is the code of the Lower Saxon nds dialect spoken in Eastern Frisia, the territory including Aurich at the A marker on the map. In that case the S might stand for Saxon.

The ISO 639-2 rules make it fairly difficult to get codes for nonsense, there must be some evidence what they had in mind when frs was registered. OTOH with codes such as eur and tlh Occam's razor might miss the point.

rxwhois 2.1.1

The modifications in version 2.1.1 of rxwhois.cmd include the addition of whois.nic.asia, whois.nic.bi, whois.adsib.gob.bo, whois.registry.gy, whois.nic.ht, whois.nic.im, whois.kcce.kp, whois.nic.mq, whois.nic.org.mt, whois.nic.pr, whois.co.ug, and vunic.vu from the usual sources: IANA, whois-servers.net, guesswork.

Lost in space: whois.nic.ki, whois.nic.tel, and whois.cctld.uz. Some domain grabbers in the TLDs CM, FM, GD, KN, and PN were ignored. Eleven other whois.whatever.tld hosts were added, but these are (yet) no whois servers. The rxwhois manual page contains the version history up to 2.1 over the last six years.

HTML5: asinine + selfish

HTML5 "reuses the well-known URL moniker in the most asinine way, and blames the other standards (which he thankfully has no control over) for not supporting all of the possible crappy raw data that could be input in an HTML attribute."

"That's why this whole discussion about creating new identifiers and new protocols in HTML is a total waste of time — the rest of the world does not want it and will not allow it to be published as HTML5. Pound the sand all you like; the network standards will not change because they are designed to support everyone's needs, not just the selfish desires of a very small set of browser developers."

So far from a co-author of RFC 3986 (the Internet Standard STD 66 for URLs) and of RFC 2616 (the currently revised HTTP specification) in one of the various HTML5 flame wars.¹

Fast track IDN ccTLDs

There will be hundreds, thousands, or even millions of new top-level domains, from the variety known as gTLDs. "ICANN is working towards accepting the first applications in the second quarter of 2009", as noted in their process FAQ.

This also affects the "fast track" introduction of internationalized top-level domain names for territories with a country code, also known as IDN ccTLDs. "The Board intends that the timing of the process for the introduction of IDN ccTLDs should be aligned with the process for the introduction of new gTLDs", stated in an ICANN Board resolution.

Enough time to fix the toplabel bug in RFC 1123, document the IDN test TLDs as reported here ten months ago, and get ready with IDNAbis.

Lost + found: 268,435,455 free IPs

Three Internet Standards, one of them historic, RFC 3330, an RFC 3330 erratum, and three Internet Drafts entered the battle over 6.25% of all IPv4 addresses:

RFC 3330 lists special IPv4 addresses, among others 240.0.0.0/4 also known as class E. Allegedly "reserved for future use" on page 4 of the historic RFC 1700, formerly known as STD 2. The notation 240.0.0.0/4 stands for all IPv4 addresses starting with the four bits 1111, hex. F0 is decimal 240.

Page 4 of RFC 1700 actually belongs to an introduction with basic terms copied from RFC 1122, a part of STD 3. In fact RFC 1122 specifies 0.0.0.0/8 and 127.0.0.0/8 as listed in RFC 3330, but not 240.0.0.0/4.

RFC 1122 and the RFC 1700 intro only mention class E, but it is specified in RFC 1112, a part of STD 5. Apparently RFC 3330 got this wrong, RFC 1700 by itself did not register anything at all, it was a snapshot of various IANA registries with references to registrations of all "assigned numbers".

As the future of IPv4 is now before IPv4 is replaced by IPv6 the question is what to do with these 6.25% of all IPv4 addresses "reserved for future use" minus one 255.255.255.255 specified in RFC 1122. Three Internet-Drafts fight over it:

• IANA proposes to keep class E as is, because RFC 1700 said so.
• CISCO proposes to unreserve these 268,435,455 IPs reserved in RFC 3330.
• A third draft suggested to reserve these IPs for private use updating RFC 3330.

Ignoring the expired third draft as bad idea it will be interesting how the IETF manages to free this huge pool of IPv4 addresses while the rest of the world is busy to upgrade their hard- and software to IPv6. Apparently RFC 1112 does not do anything with class E apart from reserving it, it is about class D 224.0.0.0/4 multicast addresses. Or as RFC 1812 puts it:

The Class D (IP Multicast) and Class E (Experimental) address spaces are preserved, although this is primarily an assignment policy.

Update 1, it's a bit more complex: RFC 988, a predecessor of RFC 1112, created the 224.0.0.0/4 multicast addresses as class D out of the in RFC 960 reserved 224.0.0.0/3 block, the remaining 240.0.0.0/4 block got the name class E in RFC 990 obsoleting RFC 960. After that RFC 997 updated RFC 990 and listed the "Internet numbers" including class E, while RFC 1010 obsoleted RFC 990 and listed the "assigned numbers". RFC 1010 was a predecessor of RFC 1700 over many steps, RFC 997 was the predecessor of RFC 1166. In other words, RFC 1112 specifies class D, and RFC 1166 explains the remaining class E. RFC 1166 is only "informational", that's good news from the procedural side.

Update 2, a fourth draft was published: T. Savolainen proposes to use class E for hosts indicating that they can handle this , e.g., for dial-up connections.

I ✅ Unicode

Some days ago Mark noted on the Official Google Blog that UTF-8 finally managed to be more popular than US-ASCII, I found it on the Q&A Weblog.

Actually it is not that impressive, it merely shows the Unicode conspiracy at work, UTF-8 is designed to replace US-ASCII in the next decades, one encoding to rule them all.

But it is fascinating to see the usual suspects working together on IDNAbis, another important step in the master plan, among others Vint as author of RFC 20, Mark as co-author of UTF-7 when UTF-8 was not yet ready for prime time, Harald as author of RFC 2277, and John who recently added two critical missing pieces to the puzzle:

• RFC 5137 - ASCII Escaping of Unicode Characters (BCP 137)
• RFC 5198 - Unicode Format for Network Interchange

Custom search googlet

Transforming Google CSEs into OpenSearch descriptions is simple, even when Firefox needs some proprietary <moz:SearchForm> magic to get it right.

For older browsers not supporting OpenSearch each CSE has its own default gadget for uses on iGoogle, blogger, and elsewhere. I created a smaller configurable tiny CSE variant, to use it edit the cx-number, e.g., 001904119753490578822%25:zvsejdqm-pw for the xyzzy-CSE.

CSEs hosted by Google have one issue, creators cannot easily publish the source for users wanting to know what the CSE really does. Here's a snapshot of the sites currently covered by the xyzzy-CSE:

alvestrand.no, arkko.com, ecma-international.org, gmane.org/gmane.ietf.* (ditto org.w3c.*), iab.org, iana.org, icann.org, icir.org, iesg.org, ietf.org (excl. lists), imc.org, irtf.org, isc.org, isi.edu, isoc.org, itscj.ipsj.or.jp/ISO-IR, jabber.org, langtag.net, omniplex.blogspot.com (this blog), openspf.org, postel.org, rfc-editor.org, rfc-ignorant.org, rsa.com/rsalabs, standardstrack.com, unicode.org, w3.org, xml.resource.org, xmpp.org, and my own xyzzy mirrors (plus googlets).