RFC1801 - MHS use of the X.500 Directory to support MHS Rout(3)

时间:2005-02-15 来源: 作者: 点击:
Figure 16. If a nonDeliveryInfo attribute is present, any supportingMTA attribute shall be ignored and the message non- delivered. 22.4 Bad Addresses If there is a bad address, it is desirable to do
  
Figure 16. If a nonDeliveryInfo attribute is present, any
supportingMTA attribute shall be ignored and the message non-
delivered.

22.4 Bad Addresses

If there is a bad address, it is desirable to do a directory search
to find alternatives. This is a helpful user service and may be
supported. This function is invoked after address checking has
failed, and where this is no user supplied alternate recipient. This
function would be an MTA-chosen alternative to administratively
assigned alternate recipient.

Attributes to support handling of bad addresses are defined in Figure
17. The attributes are:

badAddressSearchPoint This gives the point (or list of points) from
which to search.

badAddressSearchAttributes This gives the set of attribute types to
search on. The default is common name.

---------------------------------------------------------------------

badAddressSearchPoint ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-bad-address-search-point}

badAddressSearchAttributes ATTRIBUTE ::= {
WITH SYNTAX AttributeType
ID at-bad-address-search-attributes}

alternativeAddressInformation EXTENSION 10
AlternativeAddressInformation
::= id-alternative-address-information
-- X.400(92) continues to use MACRO notation

AlternativeAddressInformation ::= SET OF SEQUENCE {
distinguished-name DistinguishedName OPTIONAL,
or-address ORAddress OPTIONAL,
other-useful-info SET OF Attribute }

Figure 17: Bad Address Pointers

---------------------------------------------------------------------

Searches are always single level, and always use approximate match.
If a small number of matches are made, this is returned to the
originator by use of the per recipient AlternativeAddressInformation
in the delivery report (DR). This shall be marked non-critical, so
that it will not cause the DR to be discarded (e.g., in downgrading
to X.400(1984)). This attribute allows the Distinguished Name and
O/R Address of possible alternate recipients to be returned with the
delivery report. There is also the possibility to attach extra
information in the form of directory attributes. Typically this
might be used to return attributes of the entry which were matched in
the search. A summary of the information shall also be returned
using the delivery report supplementary information filed (e.g.,
"your message could not be delivered to smith, try J. Smith or P.
Smith"), so that the information is available to user agents not
supporting this extension. Note the length restriction of this field
is 256 (ub-supplementary-info-length) in X.400(1988).

If the directory search fails, or there are no matches returned, a
delivery report shall be returned as if this extra check had not been
made.

Note: It might be useful to allow control of search type, and also
single level vs subtree. This issue is for further study.

---------------------------------------------------------------------

localAccessUnit ATTRIBUTE ::= {
WITH SYNTAX AccessUnitType
ID at-local-access-unit}

AccessUnitType ::= ENUMERATED {
fax (1),
physical-delivery (2),
teletex (3),
telex (4) } 10

accessUnitsUsed ATTRIBUTE ::= {
WITH SYNTAX SelectedAccessUnit
ID at-access-units-used}

SelectedAccessUnit ::= SEQUENCE {
type AccessUnitType,
providing-MTA DistinguishedName,
filter SET OF ORAddress OPTIONAL }

Figure 18: Access UnitAttributes

---------------------------------------------------------------------

23. Submission

A message may be submitted with Distinguished Name only. If the MTA
to which the message is submitted supports this service, this section
describes how the mapping is done.

23.1 Normal Derivation

The Distinguished Name is looked up to find the attribute mhs-or-
addresses. If the attribute is single value, it is straightforward.
If there are multiple values, one O/R address shall be selected at
random.

23.2 Roles and Groups

Some support for roles is given. If there is no O/R address, and the
entry is of object class role, then the roleOccupant attribute shall
be dereferenced, and the message submitted to each of the role
occupants. Similarly, if the entry is of object class group, where
the groupMember attribute is used.

24. Access Units

Attributes needed for support of Access Units, as defined in
X.400(88), are defined in Figure 18. The attributes defined are:

localAccessUnit This defines the list of access units supported by
the MTA.

accessUnitsUsed This defines which access units are used by the MTA,
giving the type and MTA. An O/R Address filter is provided to
control which access unit is used for a given recipient. For a
filter to match an address, all attributes specificed in the
filter shall match the given address. This is specified as an O/R
Address, so that routing to access units can be filtered on the
basis of attributes not mapped onto the directory (e.g., postal
attributes). Where a remote MTA is used, it may be necessary to
use source routing.

Note 1: This mechanism might be used to replace the routefilter
mechanism of the MTS routing. Comments are solicited.

Note 2: It has been proposed to add a more powerful filter mechanism.
Comments are solicited.

Note 3: The utility of this specification as a mechanism to route
faxes and other non MHS messages has been noted, but not explored.
Comments as to how and if this should be developed are solicited.

These three issues are for further study.

25. The Overall Routing Algorithm

Having provided all the pieces, a summary of how routing works can be
given.

The core of the X.400 routing is described in Section 10. A sequence
of routing trees are followed. As nodes of the routing tree are
matched, a set of MTAs will be identified for evaluation as possible
next hops. If all of these are rejected, the trees are followed
further. (It might be argued that the trees should be followed to
find alternate routes in the case that only one MTA is acceptable.
This is not proposed.) A set of MTAs is evaluated on the following
criteria:

o If an MTA is the local MTA, deliver locally.

o Supported protocols. The MTA shall support a protocol that the
current MTA supports, as described in Section 18.2.

(Note that this could be an RFC822 protocol, as well as an
X.400 protocol.)

o The protocols shall share a common transport community, as
described in Section 18.1.

o There shall be no capability restrictions in the MTA which
prevents transfer of the current message, as described in
Section 18.3.

o There shall be no policy restrictions in the MTA which prevents
transfer of the current message, as described in Section 21.

o The authentication requirements of the MTA shall be met by the
local MTA, as described in Section 20.2.

o If the authentication (Section 20.2) indicates that a bilateral
agreement is present, the MTA shall be listed in the local set of
bilateral agreements, as described in Section 17.

o In cases where the recipient UA's capabilities can be determined,
there should either be no mismatch, or there shall be an ability
to use local or remote reformatting capabilities, as described
in [12].

26. Performance

The routing algorithm has been designed with performance in mind. In
particular, care has been taken to use only the read function, which
will in general be optimised. Routing trees may be configured so
that routing decisions can be made with only two directory reads.
More complex configurations will not require a substantially larger
number of operations.

27. Acknowledgements

This memo is the central document of a series of specifications [14,
15, 16], and to other work in progress. The acknowledgements for all
of this work is given here. Previous work, which significantly
influenced these specifications is described in Section 3. This lead
to an initial proposal by the editor, which was subsequently split
into eight documents. Work on this specifications has been done by
the IETF MHS-DS working group. Special credit is given to the joint
chairs of this group: Harald Alvestrand (Uninett) and Kevin Jordan
(CDC). Credit is given to all members of the WG. Those who have made
active contribution include: Piete Brooks (Cambridge University);
Allan Cargille (University of Wisconsin); Jim Craigie (JNT); Dennis
Doyle (SSS); Urs Eppenberger (SWITCH); Peter Furniss; Christian

Huitema (Inria); Marko Kaittola (Dante); Sylvain Langlois (EDF); Lucy
Loftin (AT&T GIS); Julian Onions (NEXOR); Paul-Andre Pays (Inria);
Colin Robbins (NEXOR); Michael Roe (Cambridge University); Jim
Romaguera (Netconsult); Michael Storz (Leibniz Rechenzentrum); Mark
Wahl (ISODE Consortium); Alan Young (ISODE Consortium).

This work was partly funded by the COSINE Paradise project.

28. References

[1] The Directory --- overview of concepts, models and services,
1993. CCITT X.500 Series Recommendations.

[2] J.N. Chiappa. A new IP routing and addressing architecture,
1991.

[3] A. Consael, M. Tschicholz, O. Wenzel, K. Bonacker, and M. Busch.
DFN-Directory nutzung durch MHS, April 1990. GMD Report.

[4] P. Dick-Lauder, R.J. Kummerfeld, and K.R. Elz. ACSNet - the
Australian alternative to UUCP. In EUUG Conference, Paris, pages
60--69, April 1985.

[5] Eppenberger, U., "Routing Coordination for X.400 MHS Services
Within a Multi Protocol / Multi Network Environment Table Format
V3 for Static Routing", RFC1465, SWITCH, May 1993.

[6] K.E. Jordan. Using X.500 directory services in support of X.400
routing and address mapping, November 1991. Private Note.

[7] S.E. Kille. MHS use of directory service for routing. In IFIP
6.5 Conference on Message Handling, Munich, pages 157--164.
North Holland Publishing, April 1987.

[8] S.E. Kille. Topology and routing for MHS. COSINE Specification
Phase 7.7, RARE, 1988.

[9] Kille, S., "Encoding Network Addresses to support operation over
non-OSI lower layers", RFC1277, Department of Computer Science,
University College London, November 1991.

[10] S.E. Kille. Implementing X.400 and X.500: The PP and QUIPU
Systems. Artech House, 1991. ISBN 0-89006-564-0.

[11] Kille, S., "A Representation of Distinguished Names
(OSI-DS 23 (v5))", RFC1485, Department of Computer Science,
University College London, January 1992.

[12] Kille, S., Mhs use of X.500 directory to support mhs content
conversion, Work in Progress, July 1993.

[13] Kille, S., "Use of the X.500 directory to support routing for
RFC822 and related protocols", Work in Progress, July 1993.

[14] Kille, S., "Representing tables and subtrees in the X.500
directory", Work in Progress, September 1994.

[15] Kille, S., "Representing the O/R Address hierarchy in the X.500
directory information tree", Work in Progress, September 1994.

[16] Kille, S., "Use of the X.500 directory to support mapping
between X.400 and RFC822 addresses", Work in Progress,
September 1994.

[17] Lauder, P., Kummerfeld, R., and A. Fekete. Hierarchical network
routing. In Tricomm 91, 1991.

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

[19] Zen and the ART of navigating through the dark and murky regions
of the message transfer system: Working document on MTS
routing, September 1991. ISO SC 18 SWG Messaging.

29. Security Considerations

Security issues are not discussed in this memo.

30. Author's Address

Steve Kille
ISODE Consortium
The Dome
The Square
Richmond
TW9 1DT
England

Phone: +44-81-332-9091
EMail: S.Kille@ISODE.COM
X.400: I=S; S=Kille; O=ISODE Consortium; P=ISODE;
A=Mailnet; C=FI;

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

UFN: S. Kille, ISODE Consortium, GB

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 (7)}

routing OBJECT IDENTIFIER ::= {mhs-ds 3}

oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}

10
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8}
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}

at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2} 20
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}

at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7}

at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}30
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40}
at-mta-name OBJECT IDENTIFIER ::= {at 19}

at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}40
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 25}

at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28}
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33} 50
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45}
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}

id-alternative-address-information OBJECT IDENTIFIER ::= {id 1} 60

Figure 19: Object Identifier Assignment

-----------------------------------------------------------------------

B Community Identifier Assignments

-----------------------------------------------------------------------

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

tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006
tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
-- Without CONS10
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK)

Figure 20: Transport Community Object Identifier Assignments

-----------------------------------------------------------------------

C Protocol Identifier Assignments

-----------------------------------------------------------------------

mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4)n enterprises(1) isode-consortium (453) mail-protocol (5)}

ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984)
ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail
(UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5} -- p1(1988) in
X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984) 10

Figure 21: Protocol Object Identifier Assignments

-----------------------------------------------------------------------

D ASN.1 Summary

-----------------------------------------------------------------------

MHS-DS-Definitions
DEFINITIONS ::=
BEGIN

-- assign OID to module
-- define imports and exports

routingTreeRoot OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation|subtree}
ID oc-routing-tree-root} 10

routingTreeList ATTRIBUTE ::= {
WITH SYNTAX RoutingTreeList
SINGLE VALUE
ID at-routing-tree-list}

RoutingTreeList ::= SEQUENCE OF RoutingTreeName

RoutingTreeName ::= DistinguishedName
20
routingInformation OBJECT-CLASS ::= {
SUBCLASS OF top
KIND auxiliary
MAY CONTAIN {

subtreeInformation|
routingFilter|
routingFailureAction|
mTAInfo|
accessMD|
nonDeliveryInfo| 30
badAddressSearchPoint|
badAddressSearchAttributes}
ID oc-routing-information}
-- No naming attributes as this is not a
-- structural object class

subtreeInformation ATTRIBUTE ::= {
WITH SYNTAX SubtreeInfo 40
SINGLE VALUE
ID at-subtree-information}

SubtreeInfo ::= ENUMERATED {
all-children-present(0),
not-all-children-present(1) }

routingFilter ATTRIBUTE ::= {
WITH SYNTAX RoutingFilter 50
ID at-routing-filter}

RoutingFilter ::= SEQUENCE{
attribute-type OBJECT-IDENTIFIER,
weight RouteWeight,
dda-key String OPTIONAL,
regex-match IA5String OPTIONAL,
node DistinguishedName }
60
String ::= CHOICE {PrintableString, TeletexString}

routingFailureAction ATTRIBUTE ::= {
WITH SYNTAX RoutingFailureAction
SINGLE VALUE
ID at-routing-failure-action}

RoutingFailureAction ::= ENUMERATED {
next-level(0),
next-tree-only(1), 70
next-tree-first(2),
stop(3) }

mTAInfo ATTRIBUTE ::= {
WITH SYNTAX MTAInfo
ID at-mta-info}

MTAInfo ::= SEQUENCE {
name DistinguishedName, 80
weight [1] RouteWeight DEFAULT preferred-access,
mta-attributes [2] SET OF Attribute OPTIONAL,
ae-info SEQUENCE OF SEQUENCE {
aEQualifier PrintableString,
ae-weight RouteWeight DEFAULT preferred-access,
ae-attributes SET OF Attribute OPTIONAL} OPTIONAL
}

RouteWeight ::= INTEGER {endpoint(0),
preferred-access(5), 90
backup(10)} (0..20)

accessMD ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-access-md}

routedUA OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation}
KIND auxiliary
MAY CONTAIN { 100
-- from X.402
mhs-deliverable-content-length|
mhs-deliverable-content-types|
mhs-deliverable-eits|
mhs-message-store|
mhs-preferred-delivery-methods|
-- defined here
supportedExtensions|
redirect|
supportingMTA| 110
userName|
nonDeliveryInfo}
ID oc-routed-ua}

supportedExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-extensions}

supportingMTA ATTRIBUTE ::= {
SUBTYPE OF mTAInfo 120
ID at-supporting-mta}

userName ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-user-name}

mTAName ATTRIBUTE ::= {
SUBTYPE OF name
WITH SYNTAX DirectoryString{ub-mta-name-length}
SINGLE VALUE 130
ID at-mta-name}
-- used for naming when
-- MTA is named in O=R Address Hierarchy

globalDomainID ATTRIBUTE ::= {
WITH SYNTAX GlobalDomainIdentifier
SINGLE VALUE
ID at-global-domain-id}
-- both attributes present when MTA
-- is named outside O=R Address Hierarchy 140
-- to enable trace to be written

mTAApplicationProcess OBJECT-CLASS ::= {
SUBCLASS OF {application-process}
KIND auxiliary
MAY CONTAIN {
mTAWillRoute|
globalDomainID|
routingTreeList|
localAccessUnit| 150
accessUnitsUsed
}
ID oc-mta-application-process}

mTA OBJECT CLASS ::= { -- Application Entity
SUBCLASS OF {mhs-message-transfer-agent}
KIND structural
MAY CONTAIN {
mTAName|
globalDomainID| -- per AE variant 160
responderAuthenticationRequirements|
initiatorAuthenticationRequirements|
responderPullingAuthenticationRequirements|
initiatorPullingAuthenticationRequirements|
initiatorP1Mode|
responderP1Mode|
polledMTAs|
protocolInformation|
respondingRTSCredentials|
initiatingRTSCredentials| 170

callingPresentationAddress|
callingSelectorValidity|
bilateralTable|
mTAWillRoute|
mhs-deliverable-content-length|
routingTreeList|
supportedMTSExtensions|
mTAsAllowedToPoll
}
ID oc-mta} 180

mTABilateralTableEntry OBJECT-CLASS ::=
SUBCLASS OF {mTA| distinguishedNameTableEntry}
ID oc-mta-bilateral-table-entry}

bilateralTable ATTRIBUTE ::= {
WITH SYNTAX SEQUENCE OF DistinguishedName
SINGLE VALUE
ID at-bilateral-table}
190
supportedMTSExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-mts-extensions}

restrictedSubtree OBJECT-CLASS ::= {
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {
subtreeDeliverableContentLength|
subtreeDeliverableContentTypes| 200
subtreeDeliverableEITs}
ID oc-restricted-subtree}

subtreeDeliverableContentLength ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-length
ID at-subtree-deliverable-content-length}

subtreeDeliverableContentTypes ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-types
ID at-subtree-deliverable-content-types} 210

subtreeDeliverableEITs ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-eits
ID at-subtree-deliverable-eits}

initiatorP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode

SINGLE VALUE
ID at-initiator-p1-mode} 220

responderP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-responder-p1-mode}

P1Mode ::= ENUMERATED {
push-only(0),
pull-only(1),
twa(2) } 230

polledMTAs ATTRIBUTE ::= {
WITH SYNTAX PolledMTAs
ID at-polled-mtas}

PolledMTAs ::= SEQUENCE {
mta DistinguishedName,
poll-frequency INTEGER OPTIONAL --frequency in minutes
}
240
mTAsAllowedToPoll ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-mtas-allowed-to-poll}

responderAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-authentication-requirements}
250
initiatorAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-authentication-requirements}

responderPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-pulling-authentication-requirements}
260
initiatorPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-pulling-authentication-requirements}

AuthenticationRequirements ::= BITSTRING {

mta-name-present(0),
aet-present(1),
aet-valid(2),
network-address(3), 270
simple-authentication(4),
strong-authentication(5),
bilateral-agreement-needed(6)}

respondingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-responding-rts-credentials}

280
initiatingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-initiating-rts-credentials}

RTSCredentials ::= SEQUENCE {
request [0] MTAandPassword OPTIONAL,
response [1] MTAandPassword OPTIONAL }
290

MTAandPassword ::= SEQUENCE {
MTAName,
Password } -- MTAName and Password
-- from X.411

callingPresentationAddress ATTRIBUTE ::= {
SUBTYPE OF presentationAddress
MULTI VALUE 300
ID at-calling-presentation-address}

callingSelectorValidity ATTRIBUTE ::= {
WITH SYNTAX CallingSelectorValidity
SINGLE VALUE
ID at-calling-selector-validity}

CallingSelectorValidity ::= ENUMERATED {
all-selectors-fixed(0),
tsel-may-vary(1), 310
all-selectors-may-vary(2) }

mTAWillRoute ATTRIBUTE ::= {
WITH SYNTAX MTAWillRoute

ID at-mta-will-route}

MTAWillRoute ::= SEQUENCE {
from [0] SET OF ORAddressPrefix OPTIONAL,
to [1] SET OF ORAddressPrefix OPTIONAL,
from-excludes [2] SET OF ORAddressPrefix OPTIONAL, 320
to-excludes [3] SET OF ORAddressPrefix OPTIONAL }

ORAddressPrefix ::= DistinguishedName

redirect ATTRIBUTE ::= {
WITH SYNTAX Redirect
SINGLE VALUE
ID at-redirect}

Redirect ::= SEQUENCE OF SEQUENCE { 330
or-name ORName,
reason RedirectionReason, -- from X.411
filter CHOICE {
min-size [1] INTEGER,
max-size [2] INTEGER,
content [3] ContentType,
eit [4] ExternalEncodedInformationType } OPTIONAL
}

nonDeliveryInfo ATTRIBUTE ::= { 340
WITH SYNTAX NonDeliveryReason
SINGLE VALUE
ID at-non-delivery-info}

NonDeliveryReason ::= SEQUENCE {
reason INTEGER (0..ub-reason-codes),
diagnostic INTEGER (0..ub-diagnostic-codes) OPTIONAL,
supplementaryInfo PrintableString OPTIONAL }

badAddressSearchPoint ATTRIBUTE ::= { 350
SUBTYPE OF distinguishedName
ID at-bad-address-search-point}

badAddressSearchAttributes ATTRIBUTE ::= {
WITH SYNTAX AttributeType
ID at-bad-address-search-attributes}

alternativeAddressInformation EXTENSION
AlternativeAddressInformation
::= id-alternative-address-information 360
-- X.400(92) continues to use MACRO notation

AlternativeAddressInformation ::= SET OF SEQUENCE {
distinguished-name DistinguishedName OPTIONAL,
or-address ORAddress OPTIONAL,
other-useful-info SET OF Attribute }

localAccessUnit ATTRIBUTE ::= {
WITH SYNTAX AccessUnitType
ID at-local-access-unit} 370

AccessUnitType ::= ENUMERATED {
fax (1),
physical-delivery (2),
teletex (3),
telex (4) }

accessUnitsUsed ATTRIBUTE ::= {
WITH SYNTAX SelectedAccessUnit
ID at-access-units-used} 380

SelectedAccessUnit ::= SEQUENCE {
type AccessUnitType,
providing-MTA DistinguishedName,
filter SET OF ORAddress OPTIONAL }
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) isode-consortium (453) mhs-ds (7)}

routing OBJECT IDENTIFIER ::= {mhs-ds 3}
390
oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8} 400
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}

at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2}
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}

at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7} 410

at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40} 420
at-mta-name OBJECT IDENTIFIER ::= {at 19}

at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 25}
at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28} 430
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33}
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45} 440
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}

id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}

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

450
tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006
tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
-- Without CONS
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK)

mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mail-protocol (5)} 460

ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984)
ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail (UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5}
-- p1(1988) in X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984)
END

Figure 22: ASN.1 Summary

-----------------------------------------------------------------------

E Regular Expression Syntax

This appendix defines a form of regular expression for pattern
matching. This pattern matching is derived from commonly available
regular expression software including UNIX egrep(1) The matching is
modified to be case insensitive.

A regular expression (RE) specifies a set of character strings to
match against - such as "any string containing digits 5 through
9". A member of this set of strings is said to be matched by the
regular expression.

Where multiple matches are present in a line, a regular expression
matches the longest of the leftmost matching strings.

Regular expressions can be built up from the following
"single-character" RE's:

c Any ordinary character not listed below. An ordinary
character matches itself.

\ Backslash. When followed by a special character, the RE
matches the "quoted" character, cancelling the special nature
of the character.

. Dot. Matches any single character.

^ As the leftmost character, a caret (or circumflex) con-
strains the RE to match the leftmost portion of a string. A
match of this type is called an "anchored match" because it is
"anchored" to a specific place in the string. The ^ character
loses its special meaning if it appears in any position other

than the start of the RE.

$ As the rightmost character, a dollar sign constrains the RE to
match the rightmost portion of a string. The $ character
loses its special meaning if it appears in any position other
than at the end of the RE.

^RE$ The construction ^RE$ constrains the RE to match the entire
string.

[c...]
A nonempty string of characters, enclosed in square brackets
matches any single character in the string. For example,
[abcxyz] matches any single character from the set `abcxyz'.
When the first character of the string is a caret (^), then
the RE matches any charac- ter except those in the remainder
of the string. For example, `[^45678]' matches any character
except `45678'. A caret in any other position is interpreted
as an ordinary character.

[]c...]
The right square bracket does not terminate the enclosed
string if it is the first character (after an initial `^', if
any), in the bracketed string. In this position it is treated
as an ordinary character.

[l-r]
The minus sign (hyphen), between two characters, indicates a
range of consecutive ASCII characters to match. For example,
the range `[0-9]' is equivalent to the string `[0123456789]'.
Such a bracketed string of characters is known as a character
class. The `-' is treated as an ordinary character if it
occurs first (or first after an initial ^) or last in the
string.

The following rules and special characters allow for
con-structing RE's from single-character RE's:

A concatenation of RE's matches a concatenation of text
strings, each of which is a match for a successive RE in the
search pattern.

* A regular expression, followed by an asterisk (*) matches zero
or more occurrences of the regular expression. For example,
[a-z][a-z]* matches any string of one or more lower case
letters.

+ A regular expression, followed by a plus character (+) matches
one or more occurrences of the regular expression. For
example, [a-z]+ matches any string of one or more lower case
letters.

? A regular expression, followed by a question mark (?) matches
zero or one occurrences of the regular expression. For
example, ^[a-z]?[0-9]* matches a string starting with an
optional lower case letter, followed by zero or more digits.

{m}
{m,}
{m,n}
A regular expression, followed by {m}, {m,}, or {m,n} matches
a range of occurrences of the regular expression. The values
of m and n must be non-negative integers less than 256; {m}
matches exactly m occurrences; {m,} matches at least m
occurrences; {m,n} matches any number of occurrences between m
and n inclusive. Whenever a choice exists, the regular
expression matches as many occurrences as possible.

| Alternation: two regular expressions separated by `|' or
NEWLINE match either a match for the first or a match for the
second.

(...)
A regular expression enclosed between the character sequences
( and ) matches whatever the unadorned RE matches.

The order of precedence of operators at the same parenthesis level
is `[ ]' (character classes), then `*' `+' `?' '{m,n}' (closures),
then concatenation, then `|' (alternation) and NEWLINE.

------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容