[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



   Use of the Directory to support routing for RFC 822 and related

                              protocols




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 defines a mechanism to route RFC 822 using the OSI
Directory.  The basic mechanisms are being developed for routing X.400
[HK92].  These offer a number of benefits relative to the current
mechanisms available for RFC 822 routing.  The prime goal of this
specification is to provide integrated routing management for sites
using both RFC 822 and X.400 [Cro82, 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        RFC 822 routing using X.500       November 1992


The domain hierarchy of an RFC 822 mailbox information are represented
in the directory according to RFC 1279 [HK91].  This will allow
domains and mailboxes to be verified.  This information is used
primarily for address checking and for mapping onto specific RFC 822
protocols.  Protocol modules should utilise native RFC 822 directory
and routing services (e.g., SMTP should use DNS)
[Pos82, Moc87a, Moc87b].
The structure of the MHS Use of Directory to Support Routing [HK92] is
designed so that RFF 822 mailboxes and X.400 mailboxes can be the same
entries with the same relative distinguished names.  This will enable
the level above the mailboxes to be linked with an alias.  This will
significantly reduce the complexity for a dual X.400/RFC 822 site.
Authoritative answers can be given for parts of the DNS tree where
registration is complete (i.e., all of the children are present, and
so any other purported child will be illegal).  This is achieved by
the subtreeInformation attribute as defined in [HK92] and referenced
in Figure 1.

Once validity of a domain is determined, routing must be done.  This
information is not relevant to a site without RFC 822 support, as it
will not be doing domain based routing.  The basic node contains
information specific for SMTP based routing is given in RFC 1279 (MX
and A record information).
The attribute x400Domain indicates that some or all of the subtree
under the domain specified uses X.400.  If the value is ``x400-only'',
the domain exists purely to represent X.400 addresses in the RFC 822
world, and X.400 routing should be used if possible.  If the value is
``x400-and-822'', then protocol choice should reflect local policy
(e.g., to prefer X.400 or to avoid protocol conversion).  Protocol
conversion should be avoided.
For sites with SMTP on the Internet, any valid domain may be routed
through SMTP. DNS Information is also available in the tree, to
facilitate route calculation (RFC 1279 and RFC 974 [Par86]).

For sites with JNT Mail support, the jNTMailSupport attribute
indicates that the domain supports JNT Mail, and gives sufficient
information to make a routing decision.  This mechanism is included to
show how the directory can handle RFC 822 mail routing beyond SMTP.
Local addresses are handled in the same way as for X.400, as described
in [HK92].  The approach is designed to be convenient for either
environment.  Where a site supports both, the appropriate parts of the
O/R Address and Domain namespaces should be linked by aliases.  The
object pointed to should be of object class domain-component and


Hardcastle-Kille                          Expires:  June 1993   Page 1




INTERNET--DRAFT        RFC 822 routing using X.500       November 1992




_______________________________________________________________________
822Node OBJECT-CLASS
    SUBCLASS OF domain
    MAY CONTAIN {
        authoritativeAddress,
        x400Domain,
        badAddressSearchPoint,
        badAddressSearchAttributes}
   ::= oc-822-node

x400Domain ATTRIBUTE                                                10
    WITH ATTRIBUTE-SYNTAX X400DomainType
    ::= at-x400-domain

X400DomainType ::= ENUMERATED {
        x400-only(1),
        x400-and-822(2) }


jNTMailNode OBJECT-CLASS
    SUBCLASS OF 822Node                                             20
    MAY CONTAIN {
        jntMailSupport }
    ::= oc-jnt-mail-node

jNTMailSupport ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX JNTMailSupport
    ::= at-jnt-mail-support

JNTMailSupport ::= SEQUENCE {
        supported-nets BITSTRING {                                  30
            janet(1),
            pss(2),
            ipss(3),
            ixi(4) }
        application-relay DistinguishedName }

_________________Figure_1:__RFC_822_Node_Information___________________





Hardcastle-Kille                          Expires:  June 1993   Page 2




INTERNET--DRAFT        RFC 822 routing using X.500       November 1992


or-address component.
An MTA identifies a local address by finding its own name (Application
Process) as one of the MTAs that supports the UA in question.  This is
the same as for O/R Address checking.
One problem with bootstrapping this approach is that there is a need
to load the DNS namespace information into the DIT. This can only be
done gradually.  Fortunately, there is no requirement for all of the
domain name information to be in the DIT. The minimum needed is:


 o  Users local to the MTA, and the tree leading down to that

 o  All of the top level domains

 o  Information needed to verify or deny partially qualified domains.

The DNS could be used as an alternative checking mechanism at this
point.  The disadvantages of doing this are:


 o  No mailbox (UA) checking

 o  No support for multiple RFC 822 protocols

Multiple Domain Routing Trees can be established analogously to O/R
Address routing trees.  This is important for:


 o  Sites with RFC 822 support, but not JNT Mail or SMTP.

 o  Sites which gateway RFC 822 to other protocols (e.g., UUCP).


1  Example

*** tbs


References

[Cro82]  D.H. Crocker. Standard of the format of ARPA internet text
         messages. Request for Comments 822, University of Delaware,
         August 1982.


Hardcastle-Kille                          Expires:  June 1993   Page 3




INTERNET--DRAFT        RFC 822 routing using X.500       November 1992


[HK91]   S.E. Hardcastle-Kille. X.500 and domains.  Request for
         Comments RFC 1279, Department of Computer Science,
         University College London, November 1991.

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

[Moc87a] P. Mockapetris. Domain names - concepts and facilities.
         Request for Comments RFC 1034, USC/Information Sciences
         Institute, November 1987.

[Moc87b] P. Mockapetris. Domain names - implementation and
         specification. Request for Comments RFC 1035,
         USC/Information Sciences Institute, November 1987.

[Par86]  C. Partridge. Mail routing and the domain system.  Request
         for Comments 974, DDN Network Information Center, SRI
         International, February 1986.

[Pos82]  J.B. Postel. Simple Mail Transfer Protocol.  Request for
         Comments 821, DDN Network Information Center, SRI
         International, August 1982.


2  Security Considerations

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


3  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 4




INTERNET--DRAFT        RFC 822 routing using X.500       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 5




INTERNET--DRAFT        RFC 822 routing using X.500       November 1992


A  Object Identifier Assignment


_______________________________________________________________________

rfc-822 OBJECT IDENTIFIER ::= {mhs-ds 6}

oc OBJECT IDENTIFIER ::= {rfc-822 1}
at OBJECT IDENTIFIER ::= {rfc-822 2}



oc-822-node OBJECT IDENTIFIER ::= {oc 1}
oc-jnt-mail-node OBJECT IDENTIFIER ::= {oc 2}                       10

at-x400-domain OBJECT IDENTIFIER ::= {at 1}
at-jnt-mail-support OBJECT IDENTIFIER ::= {at 2}


_______________Figure_2:__Object_Identifier_Assignment_________________

























Hardcastle-Kille                          Expires:  June 1993   Page 6


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