LDAPFetch is NOT unidirectional nor will it ever be.
Why?
 - LDAP supports multi-value attribute, the Palm addressbook does not.
  When operating in one direction it is as simple as things might not
  function properly on the Palm, when operating in both directions we are
  dealing with the well being of data!
 - Schemas for new entries would have to be defined.
  LDAPFetch strives to be a very generic and easily configured tool.  If
  it were going to be possible to create a new entry on the Palm and for
  that entry to get carried across to LDAP, a custom schema for every
  installation would have to be written with default values and
  objectclasses.
 - "ColdSync has no guarantee that the Palm device it is talking to is
  really the one it claims to be."
  Unauthorized retrieval of data, which is usually already public
  information, from a LDAP server is not near the security risk as
  an unauthorized party updating data.
 - The "Oops" factor.
  Joe downloads ldapfetch and setups unidirectional syncing thinking that
  it might one day come in handy.  A month later Joe 1. realizes he has
  two entries in his Palm for his boss so he deletes one, 2. allows his
  kids to play games on it and they decide to play "AddressBook", 3. leaves
  his Palm laying on his desk while he goes to lunch, 4. has someone gain
  access to his machine, normally Joe wouldn't need to store his LDAP 
  password in plaintext for LDAPFetch since he is only accessing public
  information but since he decided he wanted unidirectional support his
  password is now accessed.
 - It's plain crazy.
  The idea of my Palm Pilot having enough access to possibly lock every
  user out of their network, email, web, windows, (ldap blurb here) account
  should be more than enough reason not to.