Re: UFN take 2
Paul-Andre Pays <Paul-Andre.Pays@inria.fr> Fri, 24 January 1992 03:09 UTC
Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa24293;
23 Jan 92 22:09 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa24289;
23 Jan 92 22:09 EST
Via: bells.cs.ucl.ac.uk; Fri, 24 Jan 1992 02:09:51 +0000
Received: from nsfnet-relay.ac.uk by sun.nsfnet-relay.ac.uk with Internet SMTP
id <sg.18970-9@sun.nsfnet-relay.ac.uk>;
Fri, 24 Jan 1992 00:19:46 +0000
Received: from [192.93.2.39] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP
id aa13872; 23 Jan 92 22:05 GMT
Original-Received: from nuri.inria.fr by concorde.inria.fr, Thu, 23 Jan 92
23:07:21 +0100
PP-warning: Illegal Received field on preceding line
Original-Received: by nuri.inria.fr, Thu, 23 Jan 92 23:03:28 +0100
PP-warning: Illegal Received field on preceding line
Date: Thu, 23 Jan 92 23:03:28 +0100
From: Paul-Andre Pays <Paul-Andre.Pays@inria.fr>
Message-Id: <9201232203.AA05504@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
One additional comment to UFN OSI-DS 23
One more justification to all my previous comments
. single keyword value for each attribute
. mandatory "," delimiter (even at line break)
. recommended "bracket" delimiters
Within our OPAX X.500 pilot project we have some (limited but
the hard way) experience of "multi-vendor" X.500 implementations,
and we really badly need a unique common way of representing
attributes and attribute values AT EVERY LEVEL
. for human exchange of DN
. for documentation (technical or not)
. even for text based exchange of Directory objects
In our last meeting, we even decided to try to work out
a proposal for such a representation.
From the current state of OSI-DS 23, I really think it would be a pity
not to able to merge this with it. That is to be able to use
the UFN proposal base (limited to the keyworded option) for
this.
. this would onluy be possible, if this keyworded option has a
strong enough syntax to suit our needs
. I have the feeling there is no reason not to accept
. Moreover, if accepted, I bet all major X.500 implementations
will within a matter of say at most a few month, offer
this representation (subset of OSI-DS 23) as direct input
valid format (this will be done for Pizarro).
(of course this would lead to complete OSI-DS 23 with some
additional keywords, but on the basis of what exist today
with QUIPU or PIZARRO or others, it would be a very easy task to
define this table of valid keywors, and to update it each time
new applications will standardize or spread enough to justify
naming the extra attributes. identicaly, the issue of representing
other attrribute syntax will have to be solved, but as it is already
done separetly for QUIPU and PIZARRO at least, it would not be
difficult to come to an aggreement.)
I understand that this proposal goes farther that the initial scope
of OSI-DS 23, I don't say that OSI-DS 23 should cover all this.
I merely advocate that with some goodwill (and common sense)
OSI-DS 23 could be made suitable to be a strong basis
for this additional purpose and specification.
This would certainly enligthen both users and implementers
to reach soon such a simple and universal agreement and
specification.
Regards,
-- PAP
- UFN take 2 Steve Hardcastle-Kille
- Re: UFN take 2 Paul-Andre Pays
- Re: UFN take 2 Paul-Andre Pays
- Re: UFN take 2 Alan Young
- Re: UFN take 2 Steve Hardcastle-Kille
- Re: UFN take 2 Sylvain Langlois
- Re: UFN take 2 Steve Hardcastle-Kille
- Re: UFN take 2 Alan Young
- Re: UFN take 2 Keld J|rn Simonsen
- Re: UFN take 2 Paul-Andre Pays
- Re: UFN take 2 Steve Hardcastle-Kille
- Re: UFN take 2 Keld J|rn Simonsen
- Re: UFN take 2 Einar Stefferud
- Re: UFN take 2 Sylvain Langlois