[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                            M. Wahl
INTERNET-DRAFT                                          ISODE Consortium
Expires in six months from                              23 February 1996
Intended Category: Experimental

                Lightweight Directory Access Protocol:
                     MIME-based Transport Mapping
                 <draft-ietf-asid-ldapv3-mime-00.txt>



1.  Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

2.  Abstract

   The Lightweight Directory Access Protocol (LDAP) [1] is a mechanism for
   clients to access a Directory service.  Protocol mappings have been
   defined for TCP, UDP and OSI Connection-Oriented Transport.  This
   document defines how LDAP may be represented using MIME Content Types,
   so that it can be carried in SMTP or other protocols such as HTTP.

3.  Specification

   The application/ber-stream defined in [2] is used to encode LDAP for
   transport in MIME.

   The protocol is identified by an OBJECT IDENTIFIER based on TCP port
   389 (assigned in RFC 1777).  The content of the application/ber-stream
   is the base64 representation of a BER encoding of a series of one or
   more ASN.1 data values, each of type
   Lightweight-Directory-Access-Protocol.LDAPMessage.
   The subset of BER described in section 5 of [1] must be used when
   encoding, and the values must be concatenated according to the LDAP
   specification.

   Quoted printable content transfer encoding must not be generated.


INTERNET-DRAFT     LDAP MIME-based Transport Mapping    19 February 1996

4.  Request/Response Mechanisms

   The client will produce a single content containing a series of
   LDAPMessages.

   The acceptable choices in the request content for LDAPMessage are
   bindRequest, searchRequest, modifyRequest, addRequest, delRequest,
   modDNRequest, compareRequest, newDelRequest, extendedReq and
   unbindRequest.  Message Ids must be unique across all requests in a
   content, and no requests must follow an unbindRequest.  A Content-ID
   must be generated and associated with this content.

   The server will parse this content and process each request
   individually and in order.  If a bindRequest fails the server should
   process no following requests.  In addition, the server should stop
   processing following an unbindRequest.  For all other operations the
   server should continue to process even if a request fails.

   The server will respond to this content with another
   application/ber-stream content, containing a series of LDAPMessages.
   The references field of the Content-Type contains the Content-Id of
   the request.

   The acceptable choices in the response content for LDAPMessage are
   bindRespBasic, bindRespExtd, searchResEntry, searchResDone,
   searchResRef, modifyResponse, addResponse, delResponse, modDNResponse,
   compareResponse and extendedResp.  There will typically be one response
   per request, except that there may be more than one response to the
   searchRequest, and there is no response to an unbindRequest.

4.1. Mapping to SMTP

   The client will produce an electronic mail message containing a single
   content, the application/ber-stream of the request, and mail it to an
   automated responder of the server.

   The server will reply to the requestor with an electronic mail message
   containing a single content, the application/ber-stream of the
   response, and mail it to the requesting address.

4.2. Mapping to HTTP

   The client will post a request to the server in the HTTP [3] protocol.
   The POST includes an Entity-Body of the application/ber-stream content
   of the request.  As the response will be returned over the same TCP
   connection a Content-ID need not be generated.

   The server will reply to this request with status 200 and include
   another content, the application/ber-stream of the response. The
   references field should be absent if Content-ID was not in the request.

5.  Security Considerations

   Security considerations are not currently discussed in this memo.


INTERNET-DRAFT     LDAP MIME-based Transport Mapping    19 February 1996

6.  Bibliography

   [1] M. Wahl, W. Yeong, T. Howes, S. Kille, "Lightweight Directory
       Access Protocol (Version 3)", INTERNET-DRAFT,
       <draft-ietf-asid-ldapv3-protocol-00.txt>.

   [2] M.Wahl, "A MIME Content-Type for ASN.1 PDUs", INTERNET-DRAFT,
       <draft-ietf-asid-mime-ber-00.txt>.

   [3] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transport
       Protocol -- HTTP/1.0", INTERNET-DRAFT,
       <draft-ietf-http-v10-spec-03.txt>.

7.  Author's Address

   Mark Wahl
   ISODE Consortium Inc.
   3925 West Braker Lane #333
   Austin TX 78759
   USA

   M.Wahl@isode.com
   +1 (512) 305-0280