[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP terminology proposal



RL 'Bob' Morgan wrote:


OK, I believe we have consensus on this new terminology, and so direct the document editors to revise the drafts accordingly. This affects the protocol and authmeth drafts, and maybe the url draft, but not any of the others as far as I can tell.

I modified the second and third paragraphs of [LDAPURL]'s Security Considerations section to avoid the term "connection" (which was used quite a bit). In every instance except the last sentence of the third paragraph, I replaced "connection" with "LDAP session." Here is the revised text:


  The use of security mechanisms when processing LDAP URLs requires
  particular care, since clients may encounter many different servers
  via URLs, and since URLs are likely to be processed automatically,
  without user intervention. A client SHOULD have a user-configurable
  policy that controls which servers the client will establish LDAP
  sessions with using which security mechanisms, and SHOULD NOT
  establish LDAP sessions that are inconsistent with this policy.  If a
  client chooses to reuse an existing LDAP session when resolving one
  or more LDAP URLs, it MUST ensure that the session is compatible with
  the URL and that no security policies are violated.

  Sending authentication information, no matter the mechanism, may
  violate a user's privacy requirements.  In the absence of specific
  policy permitting authentication information to be sent to a server,
  a client should use an anonymous LDAP session.  (Note that clients
  conforming to previous LDAP URL specifications, where all LDAP
  sessions are anonymous and unprotected, are consistent with this
  specification; they simply have the default security policy.)  Simply
  opening a transport connection to another server may violate some
  users' privacy requirements, so clients should provide the user with
  a way to control URL processing.

Comments?

-Mark