IPv6 bug du jour: SubEthaEdit

Severity: Minor

SubEthaEdit is a great text editor for OS X. I use it regularly. One of its most useful features is collaborative editing of a document. It can do this using Bonjour (née ZeroConf) networking to discover collaborators on the subnet. It can also work over a WAN. SubEthaEdit has supported IPv6 since 2004.

SubEthaEdit has its own URL syntax for identifying a document using the see URI scheme (which doesn't seem to be registered with IANA). Here is an example of a SubEthaEdit URL: see://bakunin.et-test.psu.edu/Untitled.txt?documentID=77E29585-B15C-40CF-83D5-6BD3479F5548

A user can generate one of these URLs by selecting the File -> Copy Document URL menu item and sending the link to a colleague. Herein lies today's IPv6 bug: On a dual-stacked host, SubEthaEdit embeds the host's IPv6 address in the URL. For example, here's a link from my desktop:

see://[2610:8:6800:1::408]/Untitled.txt?documentID=BE3C9836-C886-4DCD-8EB1-2AD1DC901E35

(notice the embedded IPv6 address, using RFC 2732 syntax).

My desktop, bakunin.et-test.psu.edu, is dual-stacked, and SubEthaEdit is listening on both IPv4 and IPv6. So it's a bug to only include the IPv6 address in the URL. Ideally, SubEthaEdit could check if all of the IPs on which it is listening resolve to the same hostname, and if so, use the hostname in the URL. But this likely would not be the case for addresses obtained via DHCP, and it most certainly is not the case for auto-configured IPv6 addresses. So, it's not an easy fix for the SubEthaEdit developers. Short of emitting multiple URLs (one for each address on the host), I'm not sure of how to fix it.