Before Bob shoots me down in flames ( :-) ), I will point out that I made a
slight technical blunder in the handling of %-hack addresses.
On Wed, 23 Feb 1994, Mr Rhys Weatherley wrote:
Of course, there are nasties like jueneman%wotan(_at_)gte(_dot_)com, but they
aren't
impossible to handle:
C=US, O=Internet, OU=com, OU=gte, OU=wotan, CN=jueneman
It is impossible to get a reversible mapping using this. It should have
been the following:
C=US, O=Internet, OU=com, OU=gte, CN=jueneman(p)wotan
where "(p)" is the encoding of "%" in the RFC <-> X.400 stuff (RFC 1327
is the latest version I have on me).
The Internet -> DN mapping algorithm is therefore:
1. Everything to the right of the last '@' is converted into a DN
according to the mechanism in my previous message.
2. Everything to the left of the last '@' is encoded using RFC 1327's
conventions and becomes the common name.
3. If there is no '@' in the Internet address or the characters '%' or
'!' appear to the right of the last '@', then complain to the user,
because the address either isn't a real Internet address or it has been
mangled. If it really needs to be converted, then make the whole
DN a single CN field encoded according to RFC 1327.
The reverse mapping algorithm is:
1. If the DN does not begin with "C=??, O=Internet" then leave it as is,
as it probably is a conventional DN rather than an encoded Internet
address.
2. Convert the C and OU fields into an Internet domain name for the
right-hand side of the '@'.
3. Decode the CN field using RFC 1327 conventions for the left-hand side
of the '@'.
Aside: can the CN field be encoded using a T.61 string rather than a
printable string? If so, we probably don't need RFC 1327 at all.
Cheers,
Rhys.