Re: LDAP Certificate transfer syntax

[Mark Wahl <Mark.Wahl@sun.com>]

David Chadwick wrote:
> 
> Steven
> 
> thanks for your messages that have clearly stated the case that ;binary
> is needed as a general transfer encoding, and that many attributes exist
> without a native LDAP encoding being defined for them.
> 
> But this does raise the more general issue of how does a user who asks
> for "all" attributes, deal with those which are returned, whose native
> encoding he is unfamiliar with. 

An application which asks for all attributes will need to expect to see
returned in the search result entry some attributes whose syntax OID is not 
one known to it.

RFC 2256 section 4.3.1 states that clients which request that all 
attributes be returned from entries MUST be prepared to receive values
in binary (e.g. userCertificate;binary) and SHOULD NOT simply display
binary or unrecognized values to users.

What the application does with this is analogous to an email or web client 
that receives a Content-Type: application/x-foo-bar.  It might
 - ignore it, 
 - report an error,
 - save the bytes to the file,
 - attempt to 'guess' (e.g. if all the bytes are in a pattern that matches
   the UTF-8 rules, then maybe it is UTF-8).

> Does the server assume the client knows (in which case ;binary will only
> be used on those attributes with no native encoding defined) or does not 
> know (in which case ;binary will need to be used on all attributes that 
> are not defined in Internet  standard RFCs).

A server knows nothing about client's schema capabilities.  There is no 
operation for a client to 'upload' a syntax table to the server.  The
;binary is used when the client requests it, either on the Add or Modify
which introduces the attribute and value to the entry, or when the client
requests it in the search's attribute description list.

Mark Wahl
Sun Microsystems Inc.