Re: UFN take 2

Paul-Andre Pays <Paul-Andre.Pays@inria.fr> Fri, 24 January 1992 03:08 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa24277; 23 Jan 92 22:08 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa24273; 23 Jan 92 22:08 EST
Via: bells.cs.ucl.ac.uk; Fri, 24 Jan 1992 02:11:53 +0000
Received: from nsfnet-relay.ac.uk by sun.nsfnet-relay.ac.uk with Internet SMTP id <sg.23411-0@sun.nsfnet-relay.ac.uk>; Fri, 24 Jan 1992 00:40:43 +0000
Received: from [192.93.2.39] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa14966; 23 Jan 92 23:30 GMT
Original-Received: from nuri.inria.fr by concorde.inria.fr, Thu, 23 Jan 92 22:45:00 +0100
PP-warning: Illegal Received field on preceding line
Original-Received: by nuri.inria.fr, Thu, 23 Jan 92 22:41:07 +0100
PP-warning: Illegal Received field on preceding line
Date: Thu, 23 Jan 92 22:41:07 +0100
From: Paul-Andre Pays <Paul-Andre.Pays@inria.fr>
Message-Id: <9201232141.AA05128@nuri.inria.fr>
To: S.Kille@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk
Subject: Re: UFN take 2
Sender: pays@nuri.inria.fr

a few comments on OSI-DS 23

Steve,

   Could you give the reasons for the choice to have many keywords
   for the same attribute? Why not limit to a single very short
   value?

     I understand the different national variants (eg Organization
     and organisation), but I am wandering whether there could not be
     a single token value. I have the impression that with some
     experience it would be much more easy to read DN representation
     if they were ALLWAYS using the same single keyword for the same
     attribute. I personaly hate from one DN to another to have to
     switch from say "O" to "Organization".

     I even personaly pretend that keywords made of 1 or a very few
     capital letters will make DN much more readable than long
     keywords (not speaking of their many variants).

     eg.

     CN=Steve Hardcastle-Kille, OU=computer science, 
     O=University College London, C=GB

     is much more easy to read than

     Common Name=Steve Hardcastle-Kille, Organizational Unit=computer science,
     Organisation=University College London, Country=GB

     Yes, you may pretend that the longer keywords are more intuitive,
     more similar to every day usage, BUT
       this is a very english centric view
     In all different speaking countries the argument does not hold,
     anyhow user will have to associate a given set of letters with
     some semantic (thought in their native language).
     For all of us (non english speakers) it is much easier to
     remember that C is the [pays|estado|pais|country|...]
     that O is the [organisme|organization|...] than to have to read
     the full english or american word.

     You will tell me that the native language representation is an
     interface matter, and you will be right. I will just add that the
     same applies also to english and american people and that I don't
     mind using english based abbreviates such as O C CN or OU, as
     long as 
	they are simple (a few capital letters, non blank, etc...)
	there is a single value for each keyword
     Any appropriate end-user interface will be able to translate
     these unique keywords in the long appropriate native language
     word or sentence.


Even if I am not able to convince you (and all the WG people), I would
at least suggest that among the variants there allways be a
"recommended one"  which of course would be the short one.
I bet that after a very short time this will results in everyone
using only this, thus removing most of the interest for the extra
complication induced by the long variants.



Issues:
========

  for the sake of uniformity I would really suggest that "," be
  defined as the very single delimiter. Think of automatic wraping
  (window resizing, text editors etc...), which will lead to many
  problems is the last "," of a line (in a multilined DN) is
  optional.


  For the very same reason, plus readability when a DN will appear
  in the middle of a text, I really advocate strongly the definition
  in the document of "brackets" to delimit an address.
  I do not say that this specification should be made mandatory, but
  that if some delimiters is used/needed then it is highly recommended
  to allways use  the defined delimiters.
    In the pizarro community, we are used to "<" and ">"
	<CN=Paul-Andre Pays, O=INRIA, C=FR>
  but I have no strong opinion about which pair or "chars" should be
  used for that purpose (this could be changed easily), but we would
  really appreciate to have one defined and recommended specification.

Regards,

-- PAP