Path: utzoo!attcan!uunet!wuarchive!usc!orion.oac.uci.edu!ucivax!gateway
From: pays@mars.emse.fr (Paul-Andre Pays)
Newsgroups: comp.protocols.iso.x400
Subject: re: printable format
Message-ID: <9008151346.AA05289@mars.emse.fr>
Date: 15 Aug 90 13:49:42 GMT
Lines: 66
Approved: usenet@ICS.UCI.EDU
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 15 Aug 90 15:47:30+0100
X400-Received: by /PRMD=emse/ADMD=atlas/C=fr/;
	Relayed; 15 Aug 90 15:46:59+0200

Thanks to Jacob for the results of this human factors study...

This is inline with my own experience managing a somehow
representative set of users.

1. An X.400 ('84) ORname is not a user friendly and easy "name" for
    a remote user (or mailbox)
   as a snail mail address it is an address and as such made of a set of
   attributes and not a "one string" name

2. We have to distinguish different purposes
   . to be able to exchange ORnames via printed media
   . to be able to enter an ORname into some computer based
       application (better a local -personal or shared- alias system
       than directly when composing mail -- though both should be
       availble)
   . to be able to compose mail quite easily and quickly
   . to be able to remember easily some form of a name for our most
        common recipients

3. the ";=" (keyworded form) seems perfectly suited for ORname
exchange and I am pleased with its "business card" purpose..
   for the user interface there could and probably should be several
different input "forms". One of them is certainly the fill-in form
already mentioned by Huitema and available with many products; another
one useful is for the software to accept as an input a blind
"retyping" of the ";=" business card form (assuming that a common
strict syntax is accepted and used); there could perfectly be one or
more other forms which are more inline with the overall user interface
either of the mail-system or the specific Operating sytem or shell
   the user "task" to translate the business form into a fill in form
   using the same labels (keywords) is easy for any user even novice,
   and besides presents the advantage to make these users painlessly
   aware of what they are doing

   As stated above, it appears that the right approach is to limit
   the use of whatever form of these addresses to the strict minimum.
   i.e. the software should allow to normaly use names instead of
   these addresses. Thus, in my opinion, any acceptable mail system
   and user interface should present the ability (and encourage the
   use) of aliases... either strictly personal or shared or any
   combination. These aliases should be short enough though remaining
   significant enough and easy to remember.

4. X.500 directory services
  X.500 is not as such a solution to the previous problem: a Directory
  name -- though a name is still a set of attributes and not a string.
   a DName is structured and long even if the attributes are expected
   to be more "natural" than those in the ORaddress. The DS will
   allow queries and search using partial information, it will not
   provide a universal one-string short and easy name.
  Of course a specific X.500 implementation may be combined with an
   alias mechanism of the type presented before, but this will be an
   implementation and management matter


Well, while still waiting for the common acceptance of a printable
form of ORnames (mainly for business card and additionaly for an
optional input form for user interfaces) I maintain that
printable "ORnames" and user interfaces are really completely
different though related issues. probably RFC-822 which used only one
form was easier but is too limited and misleading.

regards,

-- PAP