Re: UFN take 2

Alan Young <awy@concurrent.co.uk> Fri, 24 January 1992 09:23 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa01674; 24 Jan 92 4:23 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa01670; 24 Jan 92 4:23 EST
Received: from slough.concurrent.co.uk by bells.cs.ucl.ac.uk with Internet SMTP id <g.20909-0@bells.cs.ucl.ac.uk>; Fri, 24 Jan 1992 09:01:11 +0000
Received: from tubby.concurrent.co.uk by slough.concurrent.co.uk via TCP/IP with SMTP id aa04306; 24 Jan 92 9:00 GMT
X-To: Paul-Andre Pays <Paul-Andre.Pays@fr.inria>
cc: S.Kille@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk
Organization: Concurrent Computer Corp (ESDG), Slough, U.K.
Phone: +44 753 513316
Subject: Re: UFN take 2
In-reply-to: Your message of Thu, 23 Jan 92 22:41:07 +0100. <9201232141.AA05128@nuri.inria.fr>
Date: Fri, 24 Jan 92 08:59:54 +0000
Message-ID: <862.696243594@concurrent.co.uk>
From: Alan Young <awy@concurrent.co.uk>

I am glad to see UFN up for discussion again.  I have voiced a number of
concerns in the past and I think that this input (from PAP) is most
welcome.

I agree with the "single attribute name abbreviation" comment, although
I would settle for "strongly recommend".

>   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.

This is an excellent selection.  Perhaps "<" and ">" are a poor choice
because of the possible confusion with an (RFC822) address.  Whatever
bracketing syntax is choosen could also be used to indicate that input
in this format is to be taken as a DN when there is possible confusion
with a purported name - looking at it the other way around, an input
system that accepts both DNs and purported names would assume purported
name when presented with input without the brackets.

Alan.