e-name normalization (and client interpretation)

[Fen Labalme <fen@idcommons.org>]

An important general question that we have to answer soon (as several of
us begin to implement e-name Registrars) is: what makes an e-name?

I've begun a wiki page on this subject to help us reach a solution as
quickly as possible (I'm also posting this to the public xrixdi email
list).  Wiki:  http://xrixdi.idcommons.net/moin.cgi/EnameNormalization

Here's the gist:

We need to specify the normalization requirements, i.e., what punctuation
chars allowed in the XRI 1.0 spec will be normalized out of GCS e-names.

Further, how will Registrars (and Registries and ID brokers, etc.)
interpret `sub-segment`s that follow a `gsc-char`?

 1. does `xri:=first.last` resolve `last` WRT the `=first` XRI-authority
  * or
 2. is `xri:=first.last` equivalent to `xri:=(first.last)` ?

While (1) is the strict conformance to the XRI spec, (2) has been
proposed as a way to help deal with the millions of e-names that we
expect to see registered.  Note that with (1), `=John` is the authority
for:

 * `=John/+email`
 * `=John.Smith/+email`
 * `=John.Adams/+email`
 * `=John/Smith/+email`

While I fear introducing exceptions from the outset, it seems like this
may be one place that we want them.

----

Another issue: do we allow `=` as the first character of a
`sub-segment`?  Note that in `xri:=foo/=bar` only `=foo` is an e-name,
while `=bar` is simple a `sub-segment` resolved WRT the '=foo` global
authority.

Again, `=foo` is a '''''legal''''' `sub-segment`, but should our
resolvers allow it, as it introduces potential confusion?

----

I hope that I am presenting these questions in a reasonable format.

Best,
=Fen (who will have to also register =Fen.Labalme if we allow the first
      exception described above...)