As per the development schedule (only a little late!), this is the direction I am planning to take for category reform. This consists of a revision and replacement of the earlier reform proposal.
This document is unfortunately terse. I apologize. Comments are welcome; I am fairly well decided on the outline of the system, but I am still willing to make small changes that have a good reason.
Locations are composed of an address (the part before the "@") and a domain (the part after the "@"). Both the address and the domain consist of a series of at least one component (period-delimited word). Components may use any character valid in a DNS domain name.
| address address.sub.addr | @ | domain subdomain.dom.ain |
The components of the address and domain form a hierarchy. The last component of the domain is the most significant (least specific); the last component of the address is the least significant (most specific). If location X differs only from location Y by the addition of more specific components, then X is a "sublocation" of Y and Y is a "superlocation" of X. For example, "pub.foo@ofb.net" is a sublocation of "pub@ofb.net", and "pub@foo.ofb.net" is a sublocation of "ofb.net". "Direct" superlocations and sublocations are those which are created by removing or adding only a single component.
Locations are used for routing messages (much like "categories"). The domain component is used via DNS lookup to locate a set of servers, and the address component is used to select specific messages. Clients subscribe to a set of locations, and receive messages posted to any sublocation of their subscription. (Negative subscriptions work as before, and every location in the subscription must include a complete domain.)
Associated with each location is a key. A location's key must have the same name as the location, or it must be a wildcard key which matches the location. A wildcard key has "*" as its most specific component, e.g. "pub.*@ofb.net". ("*" is not valid in any other context, and except for the "root" key described below, key names must otherwise follow the same restrictions as location names.) A wildcard key matches a location if the location is a sublocation of the location formed by removing the "*" component from the wildcard key. For example, "pub.food.beer@ofb.net" matches the "pub.*@ofb.net" wildcard key. However, "pub@ofb.net" does not. At most one key may match a particular location, so if "pub.*@ofb.net" exists, "pub.food@ofb.net" must not also exist.
Every key must be signed by its direct superlocation. Keys without a direct superlocation (top-level domains) must be signed by the special root key named "!". Keys contain metadata used by Gale clients to control how messages are sent. The primary use of keys is to control the encryption used when messages are sent. A key may specify no encryption (in which case it is a "null key" and can have no subkeys), may include cryptographic public key data used to encrypt messages sent to matching locations, or may reference another key (in which case it is a "symlink key" and its children are treated as children of the referenced key).
Gale clients are not required to "obey" key information, but should do so by default.
Gale servers will treat locations much as they treated directed categories in the past; only the syntax is different. The category separator in subscription and transmission strings will be " " instead of ":". Gale servers will remain unaware of encryption or "key" issues. Existing servers will be supported via translation filters activated by protocol version detection.
Keys will be retrieved by an AKD mechanism very similar to the one currently in use, with improvements TBD to improve efficiency and bandwidth utilization, and to support key revocation/reassignment. Keys will be signed by each other much as they are today. Existing keys will remain valid, subject to transformation rules.
Clients will determine the key to associate with a location by transmitting an AKD key request for the location in question. Any key-server agent (including gdomain, gsub, and other clients) which has a key which matches the requested location will send it. The client will use the first properly formatted and signed key which matches the request, following "symlink" references as necessary. These "symlink" references should also change the location in use by the client (not just the key). Key-server agents can usually implement the relevant matching with a simple subscription to the relevant AKD category.
Clients should implement "aliasing" mechanisms allowing users to define local, shorter synonyms for commonly used location. Clients should expand sublocations of these aliases to sublocations of the expanded location. For example, if "pub" is defined locally to be an alias for "pub@ofb.net", then "pub.food.beer" should refer to "pub.food.beer@ofb.net". Clients should also allow advanced users to override the key-specified behavior for a location, allowing the use of a different key.