ISO/IEC 10021-7:1997/Cor 2:2000

INTERNATIONAL STANDARD ISO/IEC 10021-7:1997
TECHNICAL CORRIGENDUM 2
TECHNICAL CORRIGENDUM 3
Published 2000-05-01
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION � МЕЖДУНАРОДНАЯОРГАНИЗАЦИЯПОСТАНДАРТИЗАЦИИ � ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION � МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОМИССИЯ � COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
Information technology — Message Handling Systems (MHS):
Interpersonal messaging system
TECHNICAL CORRIGENDUM 2
TECHNICAL CORRIGENDUM 3
Technologies de l'information — Systèmes de messagerie (MHS): Système de messagerie entre personnes
RECTIFICATIF TECHNIQUE 2
RECTIFICATIF TECHNIQUE 3
Technical Corrigenda 2 and 3 to International Standard ISO/IEC 10021-7:1997 were prepared byJoint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 6, Telecommunications and information
exchange between systems.
ICS 35.240.20 Ref. No. ISO/IEC 10021-7:1997/Cor.2:2000(E)
ISO/IEC 10021-7:1997/Cor.3:2000(E)
© ISO/IEC 2000 – All rights reserved
Printed in Switzerland

---------------------- Page: 1 ----------------------
ISO/IEC 10021-7:1997/Cor.2:2000 (E) & Cor.3:2000 (E)
INTERNATIONAL STANDARD
ISO/IEC 10021-7 : 1997/Cor.2 (1997) E & Cor.3 (1998) E
ITU-T Rec. X.420 (1997)/Cor.2 (1997E) & Cor.3 (1998E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – MESSAGE HANDLING SYSTEMS (MHS):
INTERPERSONAL MESSAGING SYSTEM
TECHNICAL CORRIGENDUM 2 AND CORRIGENDUM 3
1 Subclause 7.2.6
In 7.2.6 delete "heading" in the first sentence, and append to the first paragraph: "It may be present as a
Heading field, or alternatively as an equivalent MTS extension that may be present in the per-recipient-
message-submission-extensions field of a message-submission envelope and in the message-delivery-
extensions field of a message-delivery envelope.". Insert after the existing ASN.1 productions:
blind-copy-recipients EXTENSION ::= {
BlindCopyRecipientsField,
IDENTIFIED BY standard-extension:41 }
Insert at the end of 7.2.6:
NOTE – When submitting through an MS which provides Storage on Submission, the use of the alternative envelope
encoding will result in a single submitted-message entry instead of an additional submitted-message entry for each blind
copy recipient, which gives greater efficiency of submission, better correspondence between the user’s perception of
submitting one IPM and the resultant stored entry, and improved correlation of reports and notifications for blind copy
recipients with the submitted-message entry. However, if the blind copy recipient’s MS or UA conforms to an earlier
version of this specification, then use of the alternative envelope encoding will result in the absence of requested
notifications and the recipient being aware only implicitly rather than explicitly that he was a blind copy recipient.
2 Subclause 7.2.13
Replace the ASN.1 production for ReplyRecipientsSubfield in 7.2.13 by:
ReplyRecipientsSubfield ::= ORDescriptor (WITH COMPONENTS{.,
formal-name PRESENT})
3 Subclause 7.4.7
In 7.4.7 bullet b) second sentence "The presence . is discouraged", replace "The presence" by "For a delivered
message, the presence".
Add a new final paragraph to 7.4.7 (before the Notes):
If the forwarded IPM represents a previously submitted IPM (rather than a delivered IPM) then a simulated
delivery-envelope may be constructed to contain message-submission-time; the originator-name and this-
recipient-name components of this envelope each contain the OR-address of the IPM's originator.
 ITU-T Rec. X.420 (1997)/Cor.2 (1997E) & Cor.3 (1998E) 1

---------------------- Page: 2 ----------------------
ISO/IEC 10021-7:1997/Cor.2:2000 (E) & Cor.3:2000 (E)
4 Subclause 7.4.11
In 7.4.11 number the existing Example as Example 1 and insert after it:
EXAMPLE 2 – The extended EITs for the Basic Multilingual Plane of ISO/IEC 10646-1 (16-bit encoding
without restrictions on combining characters) are {id-cs-eit-authority 176} for the G0 set,
{id-cs-eit-authority 1} for the basic C0 set, and (if required) {id-cs-eit-authority 77} for the C1 set of ISO 6429.
5 Subclause 7.4.12
Delete the last 4 lines of the ASN.1 comment against FileTransferData in 7.4.12.
6 Subclause 7.4.12.7
In 7.4.12.7 second paragraph, second sentence: delete the words "a sequence of Externals to convey".
Delete the 3rd sentence of the 2nd paragraph of clause 7.4.12.7 ("The encoding of each data value in the
external is described in 7.4.12"), and replace by: "Where the file content comprises more than one data value,
each value is placed in a separate External in the FileTransferData".
Delete the last paragraph of clause 7.4.12.7 ("The encoding shall be based.") and replace by:
For the purposes of FileTransferData, this Specification places additional restrictions on the encoding of the
External ASN.1 type, excluding some of the implementation options permitted by the ASN.1 Basic Encoding
Rules in 8.18 of ITU-T Rec. X.690 | ISO/IEC 8825-1:
a) If the data value is a single ASN.1 type, the single-ASN1-type choice shall be used; the
options to place a BER-encoding of the data value in the octet-aligned or arbitrary choices
are excluded.
b) If the data value comprises an integral number of octets, but is not a single ASN.1 type, the
octet-aligned choice shall be used; the option to place octet-aligned data in the arbitrary
choice is excluded.
A data value comprising a single ASN.1 Octet String and a data value comprising octets which are not
specified as any ASN.1 type are considered equivalent, and either of the applicable encodings may be used (i.e.
the single-ASN1-type choice containing an explicitly tagged Octet String, or the octet-aligned choice
containing just the data octets without additional Octet String encoding).
7 Subclause 7.4.16
In 7.4.16 replace the last line of the ASN.1 production for ForwardedContentParameters by:
mts-identifier [2] MessageDeliveryIdentifier OPTIONAL,
submission-proof [3] SubmissionProof OPTIONAL}
In 7.4.16 insert new bullet d):
d) Submission-proof (C): The proof-of-submission of the original message together with the associated
certificate of the public key of the MTA which generated that proof and the message-submission-
envelope, if the content represents a message previously submitted to the MTS.
SubmissionProof ::= SET {
proof-of-submission [0] ProofOfSubmission,
originating-MTA-certificate [1] OriginatingMTACertificate,
message-submission-envelope MessageSubmissionEnvelope}
2 ITU-T Rec. X.420 (1997)/Cor.2 (1997E) & Cor.3 (1998E)

---------------------- Page: 3 ----------------------
ISO/IEC 10021-7:1997/Cor.2:2000 (E) & Cor.3:2000 (E)
In 7.4.16, insert a new penultimate paragraph (after the Notes):
If the original message’s delivery envelope contains a message-token which contains encrypted-data then it
may be necessary to create a Forwarded Content Token (see B.6.2) for each recipient of the forwarding IPM.
This is required, for example, when an asymmetric algorithm is used for encrypted-data that contains a content-
confidentiality-key.
8 Clause 8
In clause 8, fifth paragraph (starting "The subject recipient specifier"), append to the first sentence ", and
Blind Copy Recipients envelope field".
9 Subclause 18.2.2
In 18.2.2 first bullet a) insert new bullet iv):
iv) Blind-copy-recipients and Disclosure-of-other-recipients: If blind copy recipients are
specified in the envelope then Disclosure-of-other-recipients shall have the value disclosure-
of-other-recipients-prohibited (either explicitly or by default), and the Blind Copy Recipients
heading field shall be absent within the Content.
In 18.2.2, add a new sentence to the end of the second paragraph of first bullet b):
The This IPM heading field of the IPM shall contain the same value for each instance of such a multiple
submission.
In 18.2.2 first bullet b) insert a Note after the second paragraph):
NOTE – An alternative to the multiple submissions required by the Blind Copy Recipients heading field is a
single submission with the blind copy recipients encoded in the Blind-copy-recipients per-recipient field in the
envelope.
10 Subclause 19.2.1
In 19.2.1, insert the following paragraph before the last paragraph (“Figure 5 illustrates…”):
If the Message-log entry-class is supported, a Message-log entry is created for each Stored-message main-
entry. Message-log child-entries are not created.
11 Subclause 19.2.3
In 19.2.3 third set of bullets insert new bullet e):
e) if Submission-proof is present in Parameters then the proof-of-submission, originating-MTA-
certificate, and message-submission-envelope general-attribute-types shall be present.
12 Subclause 19.5.2.2
In 19.5.2.2 replace the last paragraph (before Notes) by:
In a Message body part constructed from a stored IPM that represents a delivered-message entry, the
Parameters component shall contain delivery-time and delivery-envelope.
 ITU-T Rec. X.420 (1997)/Cor.2 (1997E) & Cor.3 (1998E) 3

---------------------- Page: 4 ----------------------
ISO/IEC 10021-7:1997/Cor.2:2000 (E) & Cor.3:2000 (E)
In a Message body part constructed from a stored IPM that represents a submitted-message entry, the
Parameters component shall not contain delivery-time and shall contain delivery-envelope. This simulated
delivery-envelope shall not contain originally-intended-recipient-name, converted-encoded-information-types,
nor any extension whose presence is not defined in both a Message Submission envelope and a Message
Delivery envelope. The originator-name and this-recipient-name components of this delivery-envelope each
contain the OR-address of the IPM's originator.
In a Message body part constructed from a stored IPM that represents a draft-message entry, the Parameters
component shall not contain delivery-time or delivery-envelope.
In a Forwarded Content body part constructed from a stored IPM, the Parameters component shall contain
delivery-time and delivery-envelope as prescribed above for a Message body part, and shall also contain MTS-
identifier except where the stored IPM represents a draft-message entry. In a Forwarded Content body part
constructed from a stored IPM that represents a submitted-message entry which has a proof-of-submission and
the associated originating-MTA-certificate, the Parameters component shall contain submission-proof.
When the IPMS-MS has assembled the new Body, it shall update the original-encoded-information-types in the
message-submission-envelope as necessary, such that the complete message still satisfies the requirements of
20.4.
In 19.5.2.2 insert a new Note:
4. If any of the assembled body parts contain data that has been encrypted with a symmetric encryption algorithm where the
session-key for that algorithm is itself encrypted in an associated token, it is the responsibility of the IPMS-MS-user to
generate appropriate tokens for each recipient of the forwarding IPM. This does not require the IPMS-MS-user to retrieve
or decrypt the encrypted data in these body parts, but just to retrieve, decrypt and re-encrypt the associated tokens.
13 Subclause 19.5.2.4
Insert new clause 19.5.2.5:
19.5.2.5 Originator-forwarded-content-token
This MS-submission-extension is used where the submitted message contains a Forwarded Content Token (see
B.6.2) that has been encrypted such that it cannot subsequently be decrypted by the originator. This extension
enables the originator to supply a Forwarded Content Token constructed as if the originator were a recipient of
the message, to be stored in the submitted-message entry but not submitted to the MTS. Subsequently, the
originator may retrieve this information and use it to recover the Forwarded Content body part.
originator-forwarded-content-token MS-EXTENSION ::= {
ForwardedContentToken IDENTIFIED BY
id-mst-originator-forwarded-content-token}
14 Table 3
Add the following to MS attributes definitions to Table 3:
 Support P
Attribute V Sm Dl Sl IPMNRNRN ON L S
F
Forwarded Content Token S O O O C — — — Y N
Forwarding Token S O — — C — — — Y N

4 ITU-T Rec. X.420 (1997)/Cor.2 (1997E) & Cor.3 (1998E)

---------------------- Page: 5 ----------------------
ISO/IEC 10021-7:1997/Cor.2:2000 (E) & Cor.3:2000 (E)
15 Subclause 19.6.2.4
In 19.6.2.4, insert after the production for blind-copy-recipients:
NOTE – If the blind-copy-recipients envelope field is present then the heading field of the same name is absent, and this
attribute has instead subfields of the envelope field as its values.
16 Subclause 19.6.2.5
Insert new subclause19.6.2.6:
19.6.2.6 Envelope Extensions
Some attributes bear the names of extensions that are logically part of the IPM, but to facilitate efficient
processing are envelope extensions, and have as their values the values of those extensions or a part thereof.
forwarded-content-token ATTRIBUTE ::= {
WITH ATTRIBUTE-SYNTAX ForwardedContentToken,
NUMERATION single-valued,
ID id-hat-forwarded-content-token }
forwarding-token ATTRIBUTE ::= {
WITH ATTRIBUTE-SYNTAX MessageToken,
NUMERATION single-valued,
ID id-hat-forwarding-token }
An IPMS-MS that supports the Forwarded Content Token attribute shall maintain it for an information object
that it holds (and the Message-log entry for such an object) if that object is a message whose content is an IPM
whose Body contains a Forwarded Content. An IPMS-MS that supports the Forwarding Token attribute shall
maintain it for an information object that it holds if, and only if, that object is a child-entry which represents a
Forwarded Content body part, where that content originally had an associated message-token containing
encrypted-data.
17 Subclause 19.6.5
In 19.6.5, append to the second paragraph:
With the exception of AC Forwarded IPMs, all other Correlation attributes defined in this clause are applicable
only to main entries.
18 Subclause 19.6.5.1.7
In 19.6.5.1.7 first sentence replace "attribute contains the sequence-number" by "attribute, which is multi-
valued, contains the sequence-numbers of each instance", and in the final sentence replace "the entry" by "each
entry". In the NUMERATION line of the ASN.1 production replace "single" by "multi".
19 Subclause 19.6.5.1.9
In 19.6.5.1.9 first sentence replace "attribute contains the sequence-number" by "attribute, which is multi-
valued, contains the sequence-numbers of each instance", and in the final sentence replace "the entry" by "each
entry". In the NUMERATION line of the ASN.1 production replace "single" by "multi".
20 Subclause 19.6.6
In 19.6.6, insert into "IPMSAttributeTable" after "-- 1994 extension additions --" in the correct alphabetic
sequence:
forwarded-content-token | forwarding-token |
 ITU-T Rec. X.420 (1997)/Cor.2 (1997E) & Cor.3 (1998E) 5

---------------------- Page: 6 ----------------------
ISO/IEC 10021-7:1997/Cor.2:2000 (E) & Cor.3:2000 (E)
21 Table 5
In Table 5, in the Generation rules column in the row for Blind Copy Recipients, insert "Envelope field, if
present, otherwise of the" before "Heading field".
Add the following rows to Table 5 in the correct alphabetic sequence:
Attribute-type name Single/ Source Generation rules
multi
valued
Forwarded Content Token S IPM For a delivered-message main-entry the attribute-
value is the value of the Delivery Envelope
parameter of the same name. For a submitted-
message main-entry the attribute-value is the value
of the Originator-forwarded-content-token MS-
submission-extension. For a child-entry the
attribute-value is the appropriate message-or-
content-body-part component from this
attribute-value in its parent-entry.
Forwarding Token S IPM This attribute may only be present in a child-entry
which represents a Forwarded Content body part,
where that content originally had an associated
message-token containing encrypted-data. The
attribute-value is the value of the Forwarding-token
component of the Forwarded Content Token which
is associated with this Forwarded Content body
part.

22 Subclause 19.9.1.1
In 19.9.1.1, item a), append the following paragraph after the Note:
If the delivered message contains an IPM whose This IPM heading field matches a subfield of the
Replied-to IPM heading field of a stored IPM, then the sequence-number of each such stored IPM is
recorded in the A
...