Re: Rep (2) : QUIPU vs X.500 (was: A tool for...)

[Christian Huitema <[e-mail]>]

Steve,

Could you be more specific? I have the impression that the main difference
results from a requirement stated in RFC-1276 (page 5) that a DSA should
absolutely hold:

1.  Entries for which this DSA is the master.

2.  Slave copies of entries which are mastered in another DSA,
    indicated by a subordinate reference.  This copy must be
    maintained automatically by the DSA holding the master EDB.

This requirement is not met currently by the French master DSAs. Note that
this is not a software problem, but an administrative decision -- building a
software tool that would automatically do (2) is indeed trivial. There are
several "good" reasons behind the said administrative decision:

 1) That we want absolutely minimal operation of the national server,
    thus don't want to do anything more than simple referal handling there. We
    consider search resolution a value added service that should be served
    by competitive providers, not by a "public service" tool.

 2) That we don't want to store a full copy of the organization's entries
    in the national server for privacy/security reasons. We simply don't
    believe that central servers will perform the appropriate service controls.

Indeed, not doing this poses problems to the quipu UAs which rely heavily on
"one level searches" for "user friendly naming". One could well argue that all
pilots should support "user friendly naming" -- this is, I believe, the gist
of Steve's comments when he insists on "following RFC-1276".

There is however one problem there, which is that RFC-1276 is somewhat of an
overkill, and overspecifies the data base. To take an example, RFC-1276
specifies a knowledge representation that is a direct rendition of the Quipu
design, with concepts such as EDB or "leaf/non-leaf" separations, and with one
particular syntax for representing the knowledge in the entries themselves
which happen to be what was implemented in Quipu. It happens that other
implementations (e.g. Pizarro/UCOM-DIR) have radically different
representations of knowledge, and that changing this internal code for meeting
RFC-1276 would be a major development. The state of resources, markets, etc, is
such that this level of work can be justified for upgrading to a new version
of X.500, but cannot be committed for meeting an Internet proposed standard.

Note that RFC-1276 was published in November 1991, and has not progressed in
the standard track since. It is thus more than time to review it, as specified
in RFC-1310:

      When a standards-track specification has not reached the Internet
      Standard level but has remained at the same status level for
      twenty-four (24) months, and every twelve (12) months thereafter
      until the status is changed, the IESG shall review the viability
      of the standardization effort responsible for that specification.
      Following each such review, the IESG shall approve termination or
      continuation of the development...

Progress in the standard track is subject to some degree of "industry
consensus". Promotion to the next step, draft standard, requires two
independant interoperable implementations. I see only one, and believe that
this is due to the "overspecifying" nature of RFC-1276. Maybe we should
produce a more focused document, specifying only the need to provide support
for the "user friendly matches" and the minimal requirements, without
reproducing in extenso the internal design of Quipu...

Christian Huitema