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