At 11:55 AM 12/22/1999 , Jim Schaad (Exchange) wrote:
I am in complete agreement with Al. I looked at this issue back when the
drafts were first getting started and I was just scared by the concept of
allowing more that I could reasonably verify into the RFC822 address
field. I had a chance as a mail program of looking at the RFC822 name,
but not all of the "comments" that go along with it. While I agree that
there may be some issues for display of RFC822 names vs the comment fields
that are in messages, I think this is true no matter what is done and is
more of a presentation/application issue
Folks,
If one insists on specific semantics to the string(s) being used, then the
task is probably difficult and all the stated fears are likely valid.
To the extent that the only real issue is ensuring uniqueness, then there
are emerging enhancements to the RFC822 address string that might prove
useful.
In effect the enhancement is retrofitting a schema template onto the
mailbox (local-part) to the address. The rough style is <key=str1/str2/...
@domain>. (Apologies for the shudders this no doubt engendered among those
with an X.400 background.) Also, there is still some flux in the work and
so I could imagine that it will also permit <str1/str2/(_dot_)(_dot_)(_dot_)(_at_)domain> without
the keyword preface.
The real point behind mentioning this is to suggest that you probably can
choose to defer dealing with the issue, since it really involves matters
that are larger than certs: Things like shared mailboxes, roles vs.
people, etc., need to be dealt with much more generally. And they will be.
And it is looking likely that they will be dealt with in ways that will be
compatible with (and transparent to) the current RFC822 address format.
d/
=-=-=-=-=
Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg Consulting <www.brandenburg.com>
Tel: +1.408.246.8253, Fax: +1.408.273.6464
675 Spruce Drive, Sunnyvale, CA 94086 USA