Subscription/Notification for Lightweight Directory Access Protocol (LDAP)
draft-dawkins-ldapext-subnot-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 17, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document extends Lightweight Directory Access Protocol (LDAP) to support subscription and notification mechanism. An LDAP client can subscribe to data of interest available from an LDAP server and receive notifications from the LDAP server when this data is updated. By this means, an LDAP client can become aware of changes to data of interest in a timely manner.

Table of Contents

1.  Introduction
2.  Terminology in this Specification
3.  Applicability of this Specification
4.  The Subscribe Operation
    4.1.  The Subscribe Request
        4.1.1.  SubscribeReq.requestValue.subscribeRequestType
        4.1.2.  SubscribeReq.requestValue.notificationRefData
        4.1.3.  SubscribeReq.requestValue.sendDataIndication
        4.1.4.  SubscribeReq.requestValue.expiryTime
        4.1.5.  SubscribeReq.subscribeContent
        4.1.6.  SubscribeReq.requestValue.notifyRestriction
    4.2.  Subscribe Result
5.  Notice of Data Changed
6.  Security Considerations
7.  IANA Considerations
8.  Normative References
§  Authors' Addresses

1.  Introduction

This document extends the Lightweight Directory Access Protocol (LDAP) ([RFC4510] (Zeilenga, K., “Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map,” June 2006.), [RFC4511] (Sermersheim, J., “Lightweight Directory Access Protocol (LDAP): The Protocol,” June 2006.), [RFC4512] (Zeilenga, K., “Lightweight Directory Access Protocol (LDAP): Directory Information Models,” June 2006.)) to allow LDAP clients to subscribe to data of interest available from LDAP servers and be notified of changes to subscribed data.

This extension consists of one extended operation and one unsolicited notification message. The Subscribe operation is used by the LDAP client to subscribe for interested data in LDAP server. When the subscribed data are updated, the LDAP server sends the notification message to the related LDAP client with required data.

2.  Terminology in this Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)

Augmented BNF ([RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.)) is used in this specification.

3.  Applicability of this Specification

This specification describes an LDAP extension for use in a controlled network environment, which does not have firewalls or Network Address Translators (NATs). For this reason, no considerations for NAT traversal, translator binding lifetimes, etc. are included in this specification.

4.  The Subscribe Operation

The Subscribe operation allows an LDAP client to create a subscription to specific data in an LDAP server.

4.1.  The Subscribe Request

NOTE TO RFC EDITOR: Please replace all instances of "IANA-ASSIGNED-OID" with the actual value assigned by IANA, when this value is available.

The Subscribe Request is an LDAPMessage of CHOICE extendedReq where the requestName is IANA-ASSIGNED-OID.1. The message is defined as follows:

SubscribeReq ::= [APPLICATION 23] SEQUENCE {
	requestName		LDAPOID,
	requestValue		SubscribeRequestValue }

SubscribeRequestValue ::= SEQUENCE {
	subscribeRequestType	ENUMERATED {
		subscribe	(0),
		unsubscribe	(1) }
	subscribeContent	SubscribeContent,
	notifyRestriction	NotifyRestriction OPTIONAL,
	notificationRefData	LDAPString OPTIONAL,
	sendDataIndication 	BOOLEAN,
	expiryTime		GeneralizedTime OPTIONAL }

SubscribeContent ::= SEQUENCE {
	baseObject		LDAPDN,
	subscribeAttributeList	SEQUENCE OF SubscribeAttributes }

SubscribeAttributes ::= SEQUENCE {
	attributes		AttributeSelection,
	operation		SET SIZE(1..3) OF ENUMERATED {
			add	(0),
			modify	(1),
			delete	(2) } }

NotifyRestriction ::= SEQUENCE {
	notifyTo		NotifyReceiver,
	notifyStart		GeneralizedTime OPTIONAL }

NotifyReceiver ::= SEQUENCE {
	entryDN		LDAPDN,
	attributeName	AttributeDescription }

4.1.1.  SubscribeReq.requestValue.subscribeRequestType

This field indicates this request is a request to subscribe or unsubscribe. The values of this field are:

• subscribe: indicates this request is to subscribe to specific data in LDAP server
• unsubscribe: indicates this request is to cancel the associated subscription

4.1.2.  SubscribeReq.requestValue.notificationRefData

If present, this is an opague block of data that a client sends to the server in the Subscribe request and gets back unmodified in the Notification response when the notification is triggered.

4.1.3.  SubscribeReq.requestValue.sendDataIndication

This indication tells the server whether to return the current values of the subscribed attributes listed in subscribeContent in the Subscribe response.

4.1.4.  SubscribeReq.requestValue.expiryTime

If present, this is the designated time at which the subscription expires, specified as GeneralizedTime. If this field is absent, the Subscribe request is always valid until the LDAP server receives a Subscribe request with the subscribeRequestType set to unsubscribe.

4.1.5.  SubscribeReq.subscribeContent

The subscriberContent defines the content of a subscription request.

4.1.5.1.  baseObject

This field specifies the name of object entry that LDAP clients wish to receive notifications for, when the object entry attributes change.

4.1.5.2.  SubscribeReq.subscribeContent.subscribeAttributeList

A subscribeAttributeList lists the selected attributes that the LDAP client is interested in.

• attributes: In this field, the selected attributes in the entry are listed. If the value of any attribute listed in this field is updated, a Notification response is sent to the client.
• operation: The value of this field denotes that the client is interested in the specific cause that results in the change of attribute. In this field, one or more (of the following three) operations MUST be listed.
  • add: if the attribute is added, the server sends the notification response.
  • modify: if the attribute is modified, the server sends the notification response.
  • delete: if the attribute is deleted, the server sends the notification response.

4.1.6.  SubscribeReq.requestValue.notifyRestriction

The notifyRestriction describes how the Notice of Data Changed Notification is sent.

4.1.6.1.  SubscribeReq.requestValue.notifyRestriction.notifyTo

This denotes the receiver of a Notice of Data Changed Notification of a related Subscribe request. In the Subscribe request, an attribute name MAY be designated and the value(s) of this attribute contains the specific client(s) name(s) which will receive the related Notification.

4.1.6.1.1.  SubscribeReq.requestValue.notifyRestriction.notifyTo.entryDN

This field describes the entry in which the designated attribute locates.

4.1.6.1.2.  SubscribeReq.requestValue.notifyRestriction.notifyTo.attributeName

This field denotes the attribute name which contains the specific client(s) name(s).

4.1.6.2.  SubscribeReq.requestValue.notifyRestriction.notifyStart

The designated time that the Subscribe request comes into effect, specified as GeneralizedTime. If this field is absent, the Subscribe request is valid when the server receives it.

4.2.  Subscribe Result

The results of the Subscribe Request consist of zero or more SubscribeResultEntry messages followed by a single SubscribeResultDone message.

The SubscribeResultEntry is present if the sendDataIndication is set to TRUE in the Subscribe Request. Every SubscribeResultEntry represents an entry listed in subscribeContent of the Subscribe Request. The SubscribeResultEntry is an IntermediateResponse message where the requestName is IANA-ASSIGNED-OID.2 and the requestValue is present and contains a SubscribeResultData type defined as follows:

SubscribeResultData ::= SEQUENCE {
	objectName		LDAPDN,
	attributes		PartialAttributeList}

PartialAttributeList ::= SEQUENCE OF
	partialAttribute PartialAttribute

The SubscribeResultDone is an LDAPMessage of CHOICE extendedResp where the requestName is IANA-ASSIGNED-OID.3. The message is defined as follows:

SubscribeResultDone ::= [APPLICATION 24] SEQUENCE {
	COMPONENTS OF LDAPResult,
	responseName	LDAPOID }

5.  Notice of Data Changed

After a client successfully subscribes to notification of the data change in the server, if the subscribed data is updated (i.e. added, deleted, modified), the server SHALL send the Notification of Data Change message to the required client(s) with the data before and after the changes. To perform this operation, first, the server SHALL check if the actual notification receiver - which is designated in the value of parameter SubscribeReq.requestValue.notifyRestriction.notifyTo - is valid.

Second, the server SHALL check if the notification receiver is permitted to receive the data according to the access control mechanism of LDAP. Then the server SHALL send the notification message after all the checks are done.

The Notice of Data Change is an Unsolicited Notification as defined in [RFC4511] (Sermersheim, J., “Lightweight Directory Access Protocol (LDAP): The Protocol,” June 2006.). The responseName field of the Notice of Data Changed message is IANA-ASSIGNED-OID.4 and the responseValue is present and contains a BER-encoded NotifyResponseValue.

NotifyResponseValue ::= SEQUENCE {
	notificationRefData	LDAPString OPTIONAL,
	notifyContent		SEQUENCE OF NotifyEntry }

NotifyEntry ::= SEQUENCE {
	baseObject		LDAPDN,
	notifyAttributeList	SEQUENCE OF NotifyAttribute }

NotifyAttribute ::= SEQUENCE {
	state			ENUMERATED {
			add	(0),
			modify	(1),
			delete	(2) }
	attributeType		AttributeDesciption,
	newValue [0] SET OF value AttributeValue OPTIONAL,
	oldValue [1] SET OF value AttributeValue OPTIONAL
}

Fields of the Notice of Data Changed message are:

1. notificationRefData: server returns the same notificationRefData as received in the related Subscribe Request to the Notification of Data Change message.
2. notificationContent: the detailed data which has been updated.
3. state: denotes the operation that changed the attribute, i.e. the attribute has been added, deleted, or modified.
4. attributeType: denotes which attribute is changed.
5. newValue: the new value of the attribute after change.
6. oldValue: the original value of the attribute before change.

The server sends the Notification of Data Change message and will not expect any response from the clients.

6.  Security Considerations

General security considerations in [RFC4510] (Zeilenga, K., “Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map,” June 2006.), especially those associated with update operations in [RFC4511] (Sermersheim, J., “Lightweight Directory Access Protocol (LDAP): The Protocol,” June 2006.), apply to this extension.

7.  IANA Considerations

It is requested that Internet Assigned Numbers Authority (IANA) make the following assignment:

Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: see table
Description: see table
Person and email address to contact for further information:
	Peng Xun xunpeng@huawei.com

NOTE TO RFC EDITOR: Please replace all instances of
			XXXX with the RFC number
			for this specification when it is
			assigned.
Specification: RFC XXXX

Author/Change Controller: IESG

Comments:

Object Identifier   Type Description
------------------- ---- -------------------------
IANA-ASSIGNED-OID.1  E	Subscribe Extended Request
IANA-ASSIGNED-OID.2  E	SubscribeResultEntry Extended
                                 IntermediateResponse
IANA-ASSIGNED-OID.3  E	SubscribeResultDone Extended
                                 Response
IANA-ASSIGNED-OID.4  N	Notice of Data Changed

Legend
---------------------------------------------------
E => supportedExtension
N => Unsolicited Notice

8. Normative References

Authors' Addresses