[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 02

Network Working                                  S.E. Hardcastle-Kille
Group                                                 ISODE Consortium
INTERNET-DRAFT                                           November 1992
                                                   Expires:  June 1993





        MHS use of the Directory to support distribution lists






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.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Abstract

This document specifies a procedure for managing distribution lists
using the directory.  This is an extension of the mechanism defined in
X.400 [MHS88].
This draft document will be submitted to the RFC editor as a protocol
standard.  Distribution of this memo is unlimited.  Please send
comments to the author or to the discussion group
<mhs-ds@mercury.udev.cdc.com>.




INTERNET--DRAFT       Directory Distribution Lists       November 1992


*** NOTE **** Information from EXPLODE project has not been factored
into this note


1  Model

This section describes the operation of Distribution Lists, including
use of the OSI Directory.  There are two models of distribution list
expansion:

1.  Following the standard

2.  UA level expansion


The standard mechanism needs no explanation here.  The UA leve model
is almost the same.  The differences are

 o  The MTS originator is changed to a list manager.

 o  The MTS identifier is changed (doing the first without the second
    is not really sensible).

 o  In terms of the model, the message is delivered, then the list is
    expanded outside the MTS, and then the message is resubmitted.
    Essentially, this makes list expansion a ``firewall''.

 o  DL Expansion history is submitted with the new message.


In practice, the UA level expansion is very close to the standard.
Disadvantages of the UA level approach are:


 o  It is non-standard

 o  It provides less information for elimination of duplicates

Features which can be argued as an advantage of either approach are:


 o  The only service which is lost, is the ability to return to the
    originator errors which occur after expansion.


Hardcastle-Kille                          Expires:  June 1993   Page 1




INTERNET--DRAFT       Directory Distribution Lists       November 1992


    The argument in favour of this is that this is sometimes a useful
    service.
    The argument against this is that where such a service is
    required, it is better to achieve this by a mechanism where the
    orginatinge UA expands the distribution list prior to message
    submission.

The advantages of the UA level approach are:


 o  Where a list has a member on RFC 822 or X.400(84), errors will
    always be sent to the list maintainer (they will go to the
    originator if the standard is followed).

 o  Support for lists in the context of X.400(1984) and RFC 822.

 o  After the expansion, parameters (e.g.  message priority) come
    under the control of the list manager (whose policy can take the
    initial parameters into consideration).

 o  It gives a basis for extension to more powerful variations of
    distributed lists, where some additional processing is done at the
    expansion point (e.g.  moderated lists).

In cases where lists follow the UA level model, they must correctly
deal with other MTAs which follow the standard model.


2  Identifying Lists

It is important to be able to identify that an object is a list either
from its directory name, or from its O/R Address, and to be able to
determine the other form.


 o  When the distinguished name is used, it is identified as a list
    from the object class of the entry (mhs-distribution-list) The
    mhs-or-addresses attribute in the list entry should point at the
    O/R Address form.

 o  When the O/R address form is used to identifies a list, it will
    also be of object class listUA, as defined in Figure 1, and the
    attribute distributionListName will point at the distinguished
    name.

Hardcastle-Kille                          Expires:  June 1993   Page 2




INTERNET--DRAFT       Directory Distribution Lists       November 1992

_______________________________________________________________________
listUA OBJECT-CLASS
    SUBCLASS OF routedUA
    MUST CONTAIN {distributionListName}
    ::= oc-list-ua

distributionListName ATTRIBUTE
    SUBTYPE OF userName
    SINGLE VALUE
    ::= at-distribution-list-name

_____________Figure_1:__O/R_Address_of_Distribution_List_______________


Lists may have aliases pointing to them.  It seems very desirable to
establish a part of the DIT to hold well known lists, to facilitate
the location of such lists.  For example, the list of the WG which is
discussing this might have an alias:


CN=MHS-DS, OU=Lists, O=Internet


3  Schema Definitions

The use of the OSI Directory to provide distribution lists defined in
X.400 is a suitable basis for Distribution lists.  The extensions
defined_in_this_specification_are_given_in_Figure_2.___________________


IMPORTS
        mhs-distribution-list, mhs-dl-members, mhs-or-name-syntax;
                FROM {X.402}


distributionList OBJECT-CLASS
        SUBCLASS OF mhs-distribution-list
        MAY CONTAIN {dlPolicy,
                dlAccessControl,                                    10
                dlErrorsToName
                dlDynamicMembers}
        ::= oc-distribution-list

dlErrorsTo OBJECT-CLASS


Hardcastle-Kille                          Expires:  June 1993   Page 3




INTERNET--DRAFT       Directory Distribution Lists       November 1992


        SUBCLASS OF ua

dlErrorsToName  ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX mhs-or-name-syntax
        MULTI VALUE                                                 20
        ::= at-dl-errors-to-name

dlPolicy ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX DlPolicy
        SINGLE VALUE
        MATCHES FOR EQUALITY
        ::= at-dl-policy

DlPolicy ::= SEQUENCE {
        operation-mode [0] ENUMERATED {                             30
                standard(0),
                p2-level(1)},
        strip-trace [1] ENUMERATED {
                strip-all(0),
                leave-all(1),
                leave-first-element(2)} DEFAULT leave-first-element,
        futher-expansion-permitted [2] BOOLEAN DEFAULT TRUE,
        conversion-prohibited [3] MappedBoolean DEFAULT original,
        priority [4] ENUMERATED {
                original (1),                                       40
                low (2),
                normal (3),
                high (4)} DEFAULT low
        suppress-warnings [5] BOOLEAN DEFAULT TRUE,
        submit-dn-only [6] BOOLEAN DEFAULT FALSE,
        public-expansion-ok [7] BOOLEAN DEFAULT TRUE,
        disclosure-of-recipients [8] MappedBoolean DEFAULT false
        }

MappedBoolean ::=  ENUMERATED {                                     50
                original (1),
                false (2),
                true (3) }

dlDynamicMembers ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX DLDynamicMembers
        MULTI VALUE
        ::= at-dl-dynamic-members


Hardcastle-Kille                          Expires:  June 1993   Page 4




INTERNET--DRAFT       Directory Distribution Lists       November 1992


DLDynamicMembers ::= SEQUENCE {                                     60
                base DistinguishedName,
                filter Filter
                search ENUMERATED {single-level(0), subtree(1)}
                        DEFAULT subtree}

dlAccesControl ::= ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX ENUMERATED {
                no-specific-controls (0),
                add-and-delete-self (1) }
        ::= at-dl-access-control                                    70


_____________________Figure_2:__List_Definitions_______________________

The additions to the standard are:


 o  Definition of an address to which errors are returned.

 o  Definition of an attribute to control the policy of list
    expansion.

 o  Definition of a means for dynamic list expansion.

A list need not have any members.  List management interfaces should
ensure that this is not done accidentally.
The dlErrorsToName attribute defines the O/R Name of where list errors
should be directed.  Typically, this might follow the ``list-request''
convention.  The O/R Address may be omitted from the O/R Name.  In
this case a directory entry of this name must exist to identify the
O/R address.  The object class dlErrorsTo is created solely for this
purpose.

Note that the access control for managing the membership of the list
is dealt with by the normal Directory access control mechanisms.  The
owner of the list may be identified by the ``owner'' attribute.  This
identifies the user to whom queries about the list (e.g., requests to
be added) should be addressed.
The policy of list expansion is represented by the dlPolicy attribute.
This provides the following options:


operation-mode This defines whether expansion of the list should

Hardcastle-Kille                          Expires:  June 1993   Page 5




INTERNET--DRAFT       Directory Distribution Lists       November 1992


    follow X.400, or be UA level as defined here.

strip-trace This only affects UA level expansion.  If trace is
    stripped, as full UA level expansion would require, the original
    submission date is lost.  Therefore, some or all trace may be
    resubmitted.

futher-expansion-permitted This controls whether further DL expansion
    of this list is allowed.

conversion-prohibited This allows the list to override the conversion
    prohibition of the original message.

priority This allows the priority of the original message to be
    overridden.  Typically, the priority of all messages will be set
    to low.

suppress-warnings Don't send delay warnings to the error return
    address.

submit-dn-only If the DN (Distinguished Name) is present, do not
    submit the O/R address.  This forces submit time directory name
    lookup.

public-expansion-ok This allows any directory-capable MTA to expand
    the list (not just the MTA responsible).

disclose-recipients Allows disclosure of recipients to be controlled
    by the list manager.  This will generally be set to false.

The dlDynamicMembers attribute defines a means for expressing members
of a list based on the directory search operation.  This might, for
example, be used to define a list based on userclass of student.  It
may be more useful to define a list in this way, than to explicitly
list members.  This is expanded by a subtree or single level search
using the filter.  If there is a sizelimit error, the message should
be rejected, with an appropriate error message.  If there are no
matches, an error report should be sent to the orginatore and a local
administrator should be warned.

The dlAccessControl attribute allows distribution list specific access
control to be enabled.  In particular, it allows a distribution list
to be operated with add/delete self capability.  To achieve this, the
supporting DSA will need to recognise the syntax of the mhs-dl-members

Hardcastle-Kille                          Expires:  June 1993   Page 6




INTERNET--DRAFT       Directory Distribution Lists       November 1992


attribute and be able to recognise that the distinguished name in this
matches that of the bound UA.
There is a user requirement to annotate the membership of a list.
This (standard) approach does not provide a sensible means to achieve
this, as there is no means to add per-user information.
**** Make members of DL optional (need to repeat X.402 stuff), as this
is overridden by dynamic stuff


4  Operation of Distribution Lists


**** Reference X.402 as basic list model
Each distribution lists is represented as an Entry in the Directory.
They will be given names relative to an Organisation or Organisational
Unit.  A set of sibling lists will usually be supported by a set of
MTAs.
The members of a list (mhs-dl-members) will be of three types:


 o  Directory Name only.  This will force submission-time expansion.

 o  OR Address only.  This will be for users not in the directory.

 o  Both, which should become increasingly common.  The Directory Name
    is the ``managed'' portion, with the O/R Address derived as an
    optimisation.  The list management tool should be able to update
    O/R Addresses.  User interfaces should facilitate input of RFC 822
    addresses.

The permission to submit (attribute mhs-dl-submit-premissions) is
handled in the following manner:


individual In the obvious way.

member-of-dl The members of the identified distribution list are
    allowed to submit messages to the list.  Where the identified list
    contains lists as members, this right is not conferred to members
    of those sublists.

pattern-match As described in X.400.  This might be extended slightly
    after initial experience.


Hardcastle-Kille                          Expires:  June 1993   Page 7




INTERNET--DRAFT       Directory Distribution Lists       November 1992


member-of-group Here, the property ``members'' of the name given
    identifies users allowed to submit messages.  This might be an
    expensive calculation, as in many cases, the Directory Name of the
    submitter will not be present.  It might be sensible to avoid this
    one for now.

If the attribute is omitted, this is interpreted as public rights:
that is any user may submit messages to the list


Note: It may be useful to extend submit permissions in a manner
    analogous to DynamicMembers, in order to have dynamic control of
    submission rights.

******* Note P3 expansion problem


References

[HK92]  S.E. Hardcastle-Kille. MHS use of the directory to support
        MHS routing, April 1992. Internet Draft.

[MHS88] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
        SG 5/VII / ISO/IEC JTC1, Message Handling:  System and
        Service Overview.


5  Security Considerations

Security considerations are not discussed in this INTERNET--DRAFT .


6  Author's Address


    Steve Hardcastle-Kille
    ISODE Consortium
    PO Box 505
    London
    SW11 1DX
    England

    Phone:  +44-71-223-4062


Hardcastle-Kille                          Expires:  June 1993   Page 8




INTERNET--DRAFT       Directory Distribution Lists       November 1992


    EMail:  S.Kille@ISODE.COM

    DN: CN=Steve Hardcastle-Kille,
    O=ISODE Consortium, C=GB


    UFN: S. Hardcastle-Kille, ISODE Consortium, GB






































Hardcastle-Kille                          Expires:  June 1993   Page 9




INTERNET--DRAFT       Directory Distribution Lists       November 1992


A  Object Identifier Assignment


_______________________________________________________________________
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
          enterprises(1) isode-consortium (453) mhs-ds (3)}

list OBJECT IDENTIFIER ::= {mhs-ds 5}

oc OBJECT IDENTIFIER ::= {list 1}
at OBJECT IDENTIFIER ::= {list 2}


                                                                    10
oc-list-ua OBJECT IDENTIFIER ::= {oc 1}
oc-distribution-list OBJECT IDENTIFIER ::= {oc 2}


at-distribution-list-name OBJECT IDENTIFIER ::= {at 1}
at-dl-errors-to-name OBJECT IDENTIFIER ::= {at 2}
at-dl-policy OBJECT IDENTIFIER ::= {at 3}
at-dl-dynamic-members OBJECT IDENTIFIER ::= {at 4}
at-dl-access-control OBJECT IDENTIFIER ::= {at 5}


_______________Figure_3:__Object_Identifier_Assignment_________________



















Hardcastle-Kille                         Expires:  June 1993   Page 10


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/