Russ, Great question. Simply - it gives the "client" the opportunity to establish whether or not it can or cannot support retrieval of the information from that data source (directory sub-tree). Client and server implementations choose which protocols and data models they're going to "support" all the time. As long as both support the same model(s), then they interoperate. My proposal is that we define one way to identify which data model(s) is(are) employed, so that servers and clients can determine whether they are capable of supporting the formats. If they are not capable, they can gracefully fail. The client can be made as "fat" or as "lean" as the implementer wants, because the implementer can decide which formats to support. If the implementer decides to support one while another part of the industry tends to support another - well, then that particular implementation will get "fatter" because it will wind up supporting both. My premise is that there is not a single data model that "fits" for ALL applications/deployments. And because of that, multiple data models can and will (in real-world scenarios) exist. So why not accept this, define a (singular) way of identifying which model is used, and move on. At least in this way, if a particular implementation/application has a need to store things in a different way, it can, and we can still hope for interoperability through IETF documents. Regards, Tim Hahn Internet: hahnt@xxxxxxxxxx Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 |+-----------------------+------------------------------------------------| || Russ Housley | | || <housley@xxxxxxxxxxx| To: Timothy | || m> | Hahn/Durham/IBM@IBMUS | || | cc: ietf-pkix@xxxxxxx | || 01/06/2003 04:28 PM | Subject: Re: LDAP PKI Schema | || | (was Re: No-op LDAP ;binary option) | || | | || | | |+-----------------------+------------------------------------------------| Tim: I do not understand how a client is better off with multiple ways to put the same information in the Directory. Doesn't this approach just make the client fat? It seem to me that the client would have to support all of the possible ways that the information could be stored. It cannot know which method it will encounter until it starts looking at data in the Directory. Russ At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote: >Hello all, > >After listening to the different view-points on this topic, it seems to me >that there are multiple valid approaches. These approaches include, but >are not limited to: > - leveraging the general solution of component-matching > - new schema to support application-managed componentization of >information to make things searchable >as well as others (additional matching rules, for example). > >It occurs to me that perhaps we have a situation where "one size does not >fit all". Why not accept this and define a way for applications to >determine which (of possibly multiple) format(s) has been used to place the >information into the directory? We could define some small bit of schema >which indicates the way in which the certificate information is placed into >the directory, then different applications could query this and determine: > - whether they can use the data at all > - if they can use the data, how they can best use it (if there are, for >example, multiple mechanisms employed). > >Just a thought to get us through this discussion. > >Regards, >Tim Hahn
Attachment:
smime.p7s
Description: Binary data