techblog 

I just got a Areneus Alea I true random number generator going with OS X. The device will work with any Unix like OS that support libusb.
First get libusb from http://libusb.sourceforge.net/ and install it like this

./configure --prefix=/opt/libusb
make
make install

Then copy the contents of the driver CD that came with the Alea I somewhere you can write to.

cd linux
#edit the Makefile and make it look like this
randomfile: randomfile.c
cc randomfile.c -L/opt/libusb/lib -lusb -Wl,-framework
-Wl,IOKit -Wl,-framework -Wl,CoreFoundation -Wl,-prebind
-I/opt/libusb/include  -o randomfile

make

Then run the resulting randomfile program to see it work. Tests with this device will follow.

Thanks to Mark Baker who showed me this little trick.

Whenever you display and email address in a web page there is a good chance a spambot will harvest that address and add it to a database. This technique allows you to publish email addresses in a way that browsers and email programs correctly understand but very few spambots do.

The way it works is to write out the email address using HTML character data - i.e. each letter is written like &#number; . So the email address jay@nominet.org.uk gets written in HTML as follows (line breaks added for clarity)

<a href=”mailto:&#106;&#097;&#121;&#064;&#110;
&#111;&#109;&#105;&#110;&#101;&#116;
&#046;&#111;&#114;&#103;&#046;&#117;
&#107;”>&#106;&#097;&#121;&#064;&#110;
&#111;&#109;&#105;&#110;&#101;&#116;
&#046;&#111;&#114;&#103;&#046;&#117;
&#107;</a>

which ends up looking like this:

jay@nominet.org.uk

Can you tell the difference?

Some of you may be thinking that this trick will be quickly discovered by spambot authors. However I think that spambots are generally only after the quick pickings and unless this trick becomes very popular it is not going to appear on their radar.

To start off, if you don’t know much about ENUM then read our brief introduction on our website.

ENUM as a technology is all about telephone numbers, but just how long will telephone numbers actually last and so how long will ENUM be with us?

Surprisingly it turns out that for VoIP we could do away with telephone number immediately. By using SRV records it is possible to have fully alphanumeric VoIP addresses that look just like email addresses. However there are some very big problems with this:

Dialling names not numbers

Most devices capable of dialling do not support dialling a name instead of a number. Obviously for VoIP phones and clients this is an omission that could be corrected just by greater awareness amongst developers. The really interesting bit though is mobile phones. The technical platform that mobile phones work on could support name dialling with limited changes, so they might do it one day.

Social exclusion

One of the big themes in the ongoing IGF is access to the Internet. Switching to alphanumeric addresses for VoIP could make the problems of exclusion much wider. Technologies will probably be developed to bridge the gap, but the problem will still be there.

In conclusion I think that telephone numbers, and ENUM by implication, will phase out over perhaps ten or twenty years, whilst we are weaned from our addiction to telephone numbers. But then given that Nominet is only ten years old and so much has happened in that time, I don’t think that makes ENUM any less worthwhile.

There are a number of technologies, such as Jabber or SIP that use what look like email addresses but actually aren’t. These addresses look just like email address of the form name@domain and they rely on SRV records to make them work.

In other words, how do I use jay@nominet.org.uk as my email address, my jabber address and my SIP address? How does the client know how to find the appropriate server if all it knows is the domain name part of nominet.org.uk?

Mail servers as we know have the special DNS record, the MX record. To specify the mail servers for a domain you just add appropriate MX records under that domain. However there aren’t special DNS records for SIP or Jabber. WE might assume that all we need do is find the address for the domain but then that would mean that all services have to run on the same server. What we need is some way to specify the address of the SIP server that is different from any other server address for that domain. So as well as SRV records we have a special way of showing protocol they refer to.

An MX record for say nominet.org.uk is specified like this in DNS:

nominet.org.uk.                      86400  IN   MX  10  mx3.nominet.org.uk

Whereas an SRV record for say SIP has a specially constructed left hand side, which looks like this:

_sip._tcp.nominet.org.uk.            86400  IN    SRV  1  0  5060  sip.nominet.org.uk

As you can see this DNS name is unique to SIP over TCP, which is how we can identify that this particular SRV record is that of the SIP server.

Similarly the SRV record for Jabber looks like either of these (xmpp is the standard name for jabber):

_jabber._tcp.nominet.org.uk.         86400  IN    SRV  1  0  5269  im.nominet.org.uk
_xmpp-server._tcp.nominet.org.uk.    86400  IN    SRV  1  0  5269  im.nominet.org.uk

All of these SRV records can happily co-exist and applications will only find those they need.

The final thing is to explain the numbers in the record. To the right of the SRV part we have Priority, Weight, Port, Server name.

• Priority. Clients should connect to the server with the lowest priority but should not try any servers with a a higher priority unless the first ones are not responding. This allow you to specify backup servers that you know will only be used if the primary servers are down.
• Weight. Clients should distribute their hits across all servers with the same priority in proportion to the weights. In other words if two servers have a weight of 50 then they both 50% of the hits.
• Port and Server. Obvious really, what server to connect to and what port to do it on.

SRV records could really make MX records redundant though nobody uses them that way. But they probably make it unlikely that any DNS record similar to MX will ever be developed in the future.

I’ve just invented a new protocol called docdav. Except it only exists as a vision of a future I’d like to see today and I haven’t actually got as far as the technology. Despite this obvious flaw I think it still has much to offer, so here goes:

The internet hasn’t really affected documents in the way it has many other things. We still think of documents as things we author locally, store on file systems in islands of information and share by email or, shudder, ftp. To be clear, what I mean by a document in this context is:

• A file in an domain-specific/application-specific format, such as a spreadsheet or a mindmap; or
• A file in a format that gives us full control over the layout of the information as well as the content, such as a word processing document.

But I don’t mean anything to do with the web as we currently use it. HTML/CSS is truly awful for layout and is not going to reach even word processor levels of sophistication for years. The one difference HTML/CSS does have is interactivity, but that’s nothing to with documents, that’s GUI functionality.

So here’s what I want docdav to do:

• I want browsers, embedded browsers and anything that currently understands http:// to be able to understand doc:// in the same way. For browsers that means retrieving and then rendering the document at that location.
• I want a docdav server that holds a set of documents and provides the following functionality:
  • Cataloguing, so that I can see an index of all the documents on the server and details of them
  • Categorisation for all documents, with multiple levels and mutliple categories
  • Indexing, so that I can search through all the documents on the server
  • Versioning so that I can retrieve old copies and see changes
  • Access control, so that I can specify exactly who can do what on this server
  • And one I’m not sure about - embedding. Some document formats do this, some don’t but this may not be the best place to try and fix that.
• For all this functionality I want a simple set of conventions that determine how to use it. For example:
  • doc://domain.tld/ brings up the catalogue
  • doc://domain.tld/mycategory/ brings up a catalogue for that category
  • doc://domain.tld/?term=myterm for searching
  • doc://domain.tld/mydocument.doc retrieves a named MS Word document
  • doc://domain.tld/mydocument.doc?version=1.1 for a specific version of the document
  • and so on, with appropriate i18n considerations of course
• Finally, I want the server to have a simple verb based protocol like HTTP, which deals with the basic CRUD operations and access control so that I can easily interact with the server

When I’ve got it then I’m going to abolish file systems for end users. We will finally be able to move from network document storage to Internet document storage.

Hopefully docdav will also make Lotus Notes and Sharepoint redundant (or they become docdav compliant). If I think about it, with a combination of email, iCal (caldav), docdav and something like XForms there is nothing I can’t do that I can do with proprietary solutions. Instead of sending someone an email with a document attached, I send a link to a doc:// URI. Okay, so I haven’t worked the XForms bit through properly.

In case you haven’t picked up on it, I’ve called it docdav because webdab/dav is almost there. It could probably be the foundation for docdav in the same way that it is for caldav. So maybe this vision isn’t that far away.

We use the excellent Subversion for our source control here at Nominet. The latest version (1.4) apparently has huge performance improvements for certain client-side operations. I believe this is because the metadata that it stores in your working copy has changed. This also means that previous versions of Subversion would not understand working copies created by version 1.4. This included the integration with my favoured Java IDE, IntelliJ IDEA until the version just released.

So it seemed like now would be the perfect opportunity to upgrade Subversion to take advantage of these improvements. I run Mac OS X which means there are two ways to install Subversion. Either as a prebuilt binary or via the package management system Fink. Unfortunately there is no prebuilt binary available beyond version 1.3.1, so that means I’m forced to use Fink.

The page for the subversion client shows that I should be able to get 1.4.2-10 via CVS or rsync source but not via binary distribution. But quite how you do this is a bit of a mystery. Something in the fink man pages suggests that in order to get such source distributions I have to self-update Fink itself via rsync. When I do this it tells me that I need to completely reinstall Fink itself because I am apparently running the “10.4-transitional” Tree. Aaaaaagh!

I thought the point of a package management system was that it insulated you from all of this kind of tinkering. I’m only trying to install the latest, stable version of a well known software tool. I’m not trying to hack the kernel of my machine….

Update: I now have managed to install it.  But only once I’d installed the latest version of XCode, reinstalled fink from scratch, self-updated it and installed the subversion client (which seemed to build every imaginable library from source).  Not bad for a morning’s work!

Following up on Jay’s posting on the unexplained symbols on Mac keyboards, I was also initially rather confused when I first started using a Mac 18 months ago. What was even stranger was that books such as David Pogue’s Mac OS X - The Missing Manual didn’t explain either. Surely one of the first things you need to tell a newcomer to Mac OS X is that when someone talks about the ‘Command’ button they mean that one with the cloverleaf pattern on it?

Anyway, after that someone else (I think it was jad) emailed round a link to the Mac OS X keyboard by Matias. This has text on almost every button, but even they think that the cloverleaf button is self-explanatory…. Sigh.

As you may have seen there have been no new posts for a week whilst we made the move to WordPress, away from Blojsom. Blojsom initially suited us very well, but as time has moved on it doesn’t have the functionality that WordPress has. In fact WordPress is a very impressive product.

Migration was pretty straightforward using the RSS import utility. There was one post that did not import and had to be re-entered by hand (the one about tail -f). More concerning was that there was no way to import comments without writing code, which we half did and half just cut and pasted.

With the move to WordPress we have made some improvements, namely:

• The categories have been tidied up
• One post can now be in multiple categories
• We’ve added links to our personal blogs (for those that have them).

The design is only partly complete, we will be revising it over time.

Unfortunately we did not keep the same permalink structure so old links will need to be changed. But the posts are all still there.