[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: e-name normalization (and client interpretation)
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...)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]