Re: Comments on [MANDATORY cert discovery capabiity]

[Peter Williams <peter@xxxxxxxxxxxx>]

Carlisle Adams wrote:

>  >and
> >
> >
> >     SinglePubInfo ::= SEQUENCE {      pubMethod    INTEGER {
> >               dontCare    (0),          x500        (1),          web
> >     (2)
> >
> >shoud include ldap
>
> I'm not sure what you mean here.  LDAP is not a publication method; it's
> a protocol.  All we really had in mind with this was "publish in an
> X.500 directory", or "publish on a web page", etc., with the "location"
> field giving more specific information, if desired.  Maybe the name
> "pubMethod" is not clear enough  --  suggestions?


Its nice to think of ldap as one of the protocols which implement
the X.500 Directory Abstract Service. Instead of OSI's DAP, ones
uses IPS's ldap. But this isn't real, perhaps. Effectively, ldap
is an access method for a distinct, non-X500 telematic service
which just happens to leverage off of much of
the X.500 models and objects.

The entire directory model of X.500 (as a publication method)
can be seen as distinct in its location, knowlege and distribution model.  ldap

has more interesting modes, perhaps more suited
to repository-oriented certificate publication than was simple
X.500 DAS.

Perhaps name the method "asid". Note Im not
trying to be difficult here; just positive about the asid/ldap
viewed as a distinct  "publication method". (Note, I assume "web"
implies any URL protocol, other than ldap.)

Peter.




M. Wahl
 A CIP-based Centroid Exchange for LDAP
         draft-ietf-find-ldapc-00.txt

"2. Introduction

   This document defines a centroid-based index for a subtree of the
   directory. It is carried by an update MIME object.

   The supplier server is an LDAP server which masters or shadows a naming
   context.  In this protocol it acts as a "simple CIP leaf server".

   The supplier server will at intervals mail the update to the consumer
   server.  The consumer server is a different LDAP server with a subordinate
   or cross reference to the supplier server, which makes use of this update
   to determine how to route queries.

   The centroid-based index consists of processed attribute values from
   entries. The supplier may send the complete attribute values, or if this
   would violate data protection laws, only approximate match codes of values,
   which are nonreversible.  As more processing is performed on values, the
   size of the index is reduced, as is its usefulness to the consumer.

   The specification allows for both total and incremental updates to be sent.

   This specification is intended for "push" environments, where there are many

   (tens of thousands) of naming contexts, and a small number (dozens) of
   index consumers.  The naming contexts are as a whole static, however it is
   desirable or changes to take effect rapidly."

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Williams
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 19 (TEXT/R*ch) (0001C183)