id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
60	add extension room in furls	Brian Warner	Brian Warner	"Zooko pointed out that we would benefit in the long run by adding some
extension-tolerance into the current release of foolscap. Specifically, there
are certain places in the FURL that could be extended in the future if we
were to make the next release ignore the extensions:

 * tubid: allow use of other hash algorithms, by extending the definition of
   the tubid field.
   * for 0.2.6, we declare that we'll read the first 32 characters of the
     tubid, assert that they are valid base32 characters, treat them as a
     tubid, '''and ignore the rest of the string'''
   * in the future, we can allow the tubid to be a comma-separated list of
     tubid hashes, and we can declare a format like 'sha256d.abcdef' to
     indicate the use of a different hash. When we actually start
     implementing this, we need to be careful to not open up
     protocol-rollback attacks or other vulneratibilities that result from
     two different versions of the code interpreting the string differently.
     In particular, the client should probably assert that '''all''' given
     hashes match, rather than just a single one.
   * during a transition period, host which wish their FURLs to be useable by
     0.2.6 clients (and also want to provide better security for newer clients)
     must make sure to put the undecorated sha1 hash first.

 * connection hints: allow the use of other protocols, by adding elements to
   the connection hints
   * split the connection hints field on commas, then look for anything that
     matches host:port, i.e. {{{^([^:]+):(\d+)$}}} . Ignore anything that
     doesn't match this.
   * I'd like to accept IPv6 addresses too, which means if the leading
     character is {{{[}}}, then expect to see {{{]:(\d+)$}}} .
   * In the future, we can add host:port:protocol, and trigger on the
     presence of three colons. Or, we could do protocol:host:port, but that
     is slightly harder to distinguish.
     * Zooko is interested in alternative protocols with fewer roundtrips,
       and possibly UDP based instead of TCP. For example, if the tub had an
       ECDSA public key (perhaps instead of the tubid), then we could use a
       "":udp"" protocol that encrypts the method name and arguments and
       performs the entire request in a single roundtrip (with suitable
       replay protection, which might require the maintenance of some local
       persistent state).

In general, I'm not completely convinced that useful changes can be made
within the limits that we establish on the format now, but from what I can
tell we don't lose or risk anything by making these changes now.
"	enhancement	closed	major	0.2.6	unknown	0.2.5	fixed	furl