[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
                                                        JP Laroche
INTERNET-DRAFT                                          GIE TEDECO
<draft-laroche-ted-net-protocol-00.txt>                 CAP GEMINI
Expires : 08/1998                                       1998/01/24

  The Ted.Net protocol for messaging based business interchanges

       <draft-laroche-ted-net-protocol-00.txt>

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

To learn the current status of any Internet-Draft, please check
the 1id-abstracts.txt listing  contained in the Internet-
Drafts Shadow Directories on ds.internic.net (US East Coast),
ftp.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim), ftp.is.co.za (Africa).


Abstract

The Ted.Net protocol improves messaging systems while
being fully compatible with all of them.
Ted.Net improvements bring to messaging systems' end users :
- large file transfers capabilities,
- pretty good level of privacy,
- integrity control of the transfered data,
- time stamped proofs of the acceptance of data by the recipient.
With the secure and stable services of Ted.Net, users can rely on
private or public messaging systems, SMTP, X400, or editors'
ones, to put on Electronic Data Interchanges (EDI).

Table of contents

 1. Introduction
 1.1 The Ted.Net protocol
 1.2 Discussion
 1.3 Interest
 2. The Ted.Net services
 3. Messaging background
 4. Coding
 5. The use of the "subject" field
 6. The Ted.Net header
 7. The report message
 8. References
 9. Author's address

1. Introduction
1.1 The Ted.Net protocol
The Ted.Net protocol offers :
- sub addressing capability,
- compression and segmentation to allow large files transfer,
efficiency, and confidentiality,
- end to end control,
- recovery mechanism,
- content definition and process recommandation.
These services are described in section 2.
>From an architecture point of view, the software that handles
the Ted.Net protocol is interfaced with a standard mail client
software and with the end users (applications or/and persons).
For mail protocols, Ted.Net parameters are not visible ;
they look to belong to user's data.
To allow the largest inter operability, for a long while,
between messaging systems, Internet, X400 or editors' ones,
Ted.net relies on the minimum of common services of these
messaging systems to carry data.

1.2 Discussion
The Ted.Net protocol has been defined by a large group of EDI
actors who are exchanging today lots of mega bytes each month
through X400 systems, and who plan to do far more through SMTP.
We are quite confident in the improvements of Internet protocols
in the messaging domain. Works about Delivery Status Notification
(DSN), Message Disposition Notification (MDN) or "MIME based
Secure EDI" will offer new possibilities to mail users. But
DSN is chiefly useful when there is a doubt about the destination
address, which is rarely the case for business exchanges, and
MIME based Secure EDI solves control, non repudation or
confidentiality with PKCS which is very efficient, but difficult
to organize on a large scale, and in fact too sophisticated
for most current data transfers. The MDN is very near to fill
users' needs for transfers'control. But :
- the MDN draft is now in its seventh version,
- each message has to ask for MDN, which can bring some drawback in
case of contest,
- the MDN has a powerful option : it can be sent by the mail
provider or by the mail client; this point will
necessitate discussions between partners before they agree
on the conditions of an interchange ; furthermore, this option
will not facilitate audit in case of misfunctions,
- some important functionality, as integrity control, are still
lacking, either for the whole message or for each body part,
- the "processed" disposition type of MDN exceeds the transportation
notification's domain. It is an application information.
A "get" MDN will be the ultimate notification at the transport
level to tell to the sender that the responsability of the general
process is now at the recipient's side.
- the MDN is difficult to handle when "messages partial" are used,
- the MDN have to be translated by gateways. This is the main point
because translation is impossible if the corresponding notification
does not exist in the non Internet mail system or does not offer the
equivalent capabilities. The X400 Receipt notification for example
is used by providers only, to tell that a mesage was picked out
from a mail box.
Then, as MDN
- need still some amendments,
- are not available today by every mail providers, or by every
gateway providers, or in mail client softwares,
and because it is difficult for users to
- impose changes to mail system providers,
- extend industrial client softwares,
users can only add a piece of software between their applications
and their mail client software, to get immediately the appropriate
level of services.
The Ted.Net protocol defines this "add-on" to mail client software
that permits to wait comfortably for the future standards.

1.3 Interest
This draft is being distributed to members of the Internet
community in order to solicit their reactions to the
proposals contained in it. Two positive results may occur :
- some people in a hurry to use Internet for business exchanges
will adopt the Ted.net protocol, with or without amendments,
while waiting for the appropriate standards,
- the Ted.Net protocol contributes to the continuous improvement
of Internet standards, as the MDN or the message partial of SMTP.

2. The Ted.Net services
For end users, Ted.Net improves mail systems with the following
services :
- Sub-addressing
Several users or applications can share the same mailbox : One
site can have a single mailbox for lots of applications without
any confusion between the corresponding flows of data.
The sub-addresses are under the responsability of agencies who
can handle their own private groups of partners.

- Compression and segmentation of large files
We call a "batch" the whole data that an originator asks the
transmission of  at one time.
At the sender's side, the batch is compressed. If the result is
still too large to cross some mail system, it is cut in
segments so that each segment can be forwarded in a single message,
even by the weakest mail system. The receiver does the reverse
processing : he reassembles the segments and decompresses the
data.
It can be noticed that end to end compression and segmentation
does not only improve efficiency at the transport level, but
that it minimizes also storage needs in the intermediate hosts
and in mailboxes.
Last but not least, end to end compression and
segmentation bring a significant level of confidentiality :
data are never transferred nor stored in a clear
format, and, with an appropriate compression algorithm that
needs reassembling data before decompressing them, decompression
is not an easy task, chiefly when all messages don't use
the same way across mail systems.

- End to end control
At the receiving side, Ted.Net controls that the recipient
designated by its sub address exists, that it is able to process
the announced data, and that the integrality of the data can
be put to its disposal at a time compatible with the delay
fixed by the sender.
The result of these controls is sent back to the originator in a
report message which has a coded format to facilitate automatic
processing by an application. The report message can be an
"opening acknowledgement", if all the controls are positives,
or a "partial acknowledgement", if some messages are missing,
or a "negative acknowledgement", if recovery actions are no
more possible.
This end to end control is chiefly the mean to point a
transfer of responsibility between originator and recipient,
which is of the utmost importance in the EDI business.
It is also a master piece in the process of
auditing exchanges and of tracking dysfunctions.

The Ted.Net acknowledgement is more significant than the
receipt notification of X400 or than the MDN foreseen
in Internet as we explained it in the introduction to
justify actions at a user's level.
The Ted.Net end to end control is mandatory. This particularity
helps the detection of masquerade : It is difficult for a false
sender to prevent the report message to be sent back to the
legal declared sender, as he would have to intercept the report
message or to change the DNS of providers. So, a Ted.Net user who
receives an acknowledgement for a batch that he did not send,
can suspect a masquerade and give the alert.

- Recovery mechanism :
The Ted.Net protocol offers an optional recovery mechanism that
allows a recipient to get automatically lost messages, which
is useful if non reliable systems are used.
The receiver's Ted.Net software can ask for missing segments.
That operation can occur twice at most. After that, if the
received data are always incomplete, the receiver announces
the sender that the transfer has failed.

- Content definition
Ted.Net carries informations to tell to the receiver how it has to
process the data carried by the Ted.Net container.
This service permits transportation of all kinds of files,
fixed length files, variable length files, or unformatted files ;
the parameters associated with fixed or variable types of
files allow receivers to use the file system of every operating
systems.
When necessary, Ted.Net tells which presentation of data is
used, EDIFACT, MIME, ... and which mechanism improves security,
SMIME ...

3. Messaging background
Ted.Net containers are sent and received by traditional mail
user agents connected to mail transport systems. To be abble to
use all of them and to cross the gateways that interconnect
these mail systems, Ted.Net relies on the minimum of mail
services :
- Internet messaging
Ted.Net satisfies itself with the initial SMTP defined in
rfc821 and 822. From SMTP, Ted.Net uses only the sender's and the
receivers' addresses, and the subject field. Of course, Ted.net
containers can also be carried by SMTP versions that integrate
functionalities defined in more recent rfc (1425, 1426, 1870,
1891, 1893, 1894, 2034).
Ted.Net satisfies itself with the initial MIME version 1.0
defined in rfc1521 and 1522. In MIME, Ted.Net uses only a
body-part of type/sub-type "application/octet-stream", with the
content-transfer-encoding "base 64". Ted.Net containers can
transport user's data assembled with improved version of MIME
according to rfc1767, 1847, 1848, 1892, 2045 to 2049, 2077,
2110, 2112, ... or Internet drafts (ietf-receipt-mdn-05, ietf-
mime-sgml-related, dusse-smime-msg-spec, ...).

- X400 messaging
>From X411 (P1), Ted.Net uses only the following parameters :
Sender's and receivers' addresses, Content-type "IPM" (P2), no
transcoding.
>From X420 (P2), Ted.Net uses the subject field and the body-part
of type 14, "bilaterally defined".
These services are provided by all x400 systems, from the first
X400-84 to the newest x400-96.

- Industrial messaging
In the same way, when Ted.Net relies on an industrial messaging
system, it needs only the sender's and receivers' addresses,
the subject, and a transparent body-part (not processed by
the mail agent software).

- Gateways
To allow inter-operability between subscribers of different
mail systems, gateways have to :
. Convert sender's and receiver's addresses on a symmetrical
way, so that the sender's address can be used by the receiver
to send back a response.
. Convert X400 body-part 14 into MIME body application/octet-
stream and reciprocally without processing the content ; do an
analogue conversion between the industrial messaging body and
the previous ones.
These conversions are done by most gateways. They are included
in the recommendations defined in rfc1664 and in the Internet
draft "ietf-mixer-bodymap".

4. Coding
Ted.Net parameters are assembled in a header situated between
the standard message body part header and the user's data.
For the message body-part used, the Ted.Net header is a part
of the user's data.
For simplicity reasons, and not to choose between the ASCII
lines of Internet and the basic encoding rules (BER) of X400,
Ted.Net parameters are fixed length coded. Thus the Ted.Net
header is 120 bytes long.
The Ted.Net report message is a Ted.Net message, with a Ted.Net
header and the content of which consists also of fixed length
parameters.
All Ted.Net parameters use only seven bits characters (numbers
are represented by text).

5. The use of the "subject" field
Ted.Net put a special sequence of characters, "TEDECOV301", at
the beginning of the subject field of messages, to help Ted.Net
messages recognition.
A receiver have to look for Ted.Net bodies only in messages
which have that sequence at the beginning of the subject field.
The remainder of the subject field is free for users.

6. The Ted.Net header
For each parameter we give the name, the position, the length,
the possible values and comments. The position 1 is the
position of the first byte that follows the standard header of
the body part.
Protocol name (1, 6) : "TEDECO"
Protocol version (7, 2) : "V3"
Protocol profile (9, 2) : "03"
Software identification (11, 2) : <the label number given to
the Ted.Net software by the mother agency or by a codification
agency (see next parameter)>
Codification agency (13, 3) : <the code given to the agency
responsible for attributing code> ; this code is given by a
mother agency
Application code (16 ,3) : <this sub-addressing code designates
an end user that share a mailbox> ; this code is attributed by a
codification agency.
Application code complement (19, 13) : <a complement of the
application code>.
Batch number (32, 6) : <a serial number determined by the
sender to designate unambiguously the batch he wants to send> ;
if a batch is sent in several messages all the Ted.Net headers
will carry the same batch number.
Comment (38, 16) : <free for user>.
Type of batch (54, 1) : "F", file, for user data, "A",
acknowledgement, for report message (cf. 7)
Subtype of batch (55, 1) :  For the "F" type : "B", binary
file, "F", fixed length file, "V", variable length file ; for
the "A" type : "O", opening acknowledgement (transfer
successful), "P", partial acknowledgement, "N", negative
acknowledgement (transfer failed).
Batch format (56, 1) : "E", EDIFACT, other values under the
responsibility of coding agencies.
Length of record (57, 6) : <the number of bytes of the records
for "FF" data, or the number of bytes of the longest record for
"FV" data>.
Compression (63, 3) : "Z01" for V42 bis ; other codes are under
the responsibility of coding agencies.
Segment number (66, 2) : <the number of the segments in this
message, for a given batch> ; numbering starts from 01.
Largest segment number (68, 2) : <the largest number of a
segment for a given batch>
Batch length (70, 10) : <the bytes count of the batch>
Opening delay (80, 3) : <the number of hours for which the
sender will wait acknowledgement before considering that the
transfer failed>.
Sending date and time (83, 14) : <the date and time at which
the sender starts the opening delay> ; this parameter has the
form CCYYMMDDThhmmZ (GMT time).
Recovery count (97, 1) : <the number of time this segment has
been sent> ; the first value is "1" and the maximum one, "3".
Added security (98, 4) : <a code under the responsibility of
coding agencies>.
Content presentation (102, 2) : "M1" for MIME content
compatible with rfc1521, other codes are under the
responsibility of coding agencies.

7. The report message
The report message uses the Ted.Net header with the batch type
"A" and the appropriate subtype, "O", "P" or "N".
The report itself is a structured list of parameters that we
describe as the Ted.Net header, the position 1 being the first
byte that follows the Ted.Net header.
Date and time (1, 14) : <the date and time at which the report
is sent>, on the form CCYYMMDDThhmmZ (GMT time).
Diagnostic family (15, 2) : "01", invalid data type for a
parameter in the header ; "02" invalid value for a parameter ;
"03", impossibility to reconstitute the batch ; "04", local
problem at the receiver's side ; "05", incomplete batch ; "06",
batch rejected by the receiver.
Detail code (17,2) : <one of 30 values> that precises the
diagnostic.

Reports of "P" type, partial acknowledgement, have the
following additional parameters :
First missing segment (19, 2) : <the number of the segment that
the sender have to resend>,
Second missing segment (21, 2) : idem
...
End of the list of missing segments : CR-LF.
The list of missing segments can be optimised this way :
--xx : all segments until the xx segment (included)
xx-- : all segments from the xx segment (included)
xx--yy : all segments between xx and yy segments (included)
---- : all the segments of a batch

An annex with the list of error codes will be provided later.

8. References
References dealing with messaging appear first,
then come references dealing with the content of messages
or of general interest.

[1]  J. Postel, "Simple Mail Transfer Protocol",  STD 10, RFC 821,
     August 1, 1982.

[2]  K. Moore, G. Vaudreuil, "An Extensible Message Format for
     Delivery Status Notification", RFC 1894, January, 1996.

[3]  R. Fajman, "An Extensible Message Format for Message Disposition
     Notifications", draft-ietf-receipt-mdn-07.txt, July, 1997.

[4]  N. Borenstein,  N.Freed, "Multipurpose Internet Mail Extensions
     (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
     December 02, 1996.

     N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
     (MIME) Part Two: Media Types", RFC 2046, December 02,
     1996.

     N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
     (MIME) Part Five: Conformance Criteria and Examples", RFC
     2049, December 02, 1996.

[5]  D. Crocker, "MIME Encapsulation of EDI Objects",  RFC 1767,
     March 2, 1995.

[6]  M. Jansson, C. Shih, R. Drummond, "Requirements for
     Inter-operable Internet EDI", Internet draft :
     draft-ietf-ediint-req-04.txt, July 8, 1997.

[7]  M. Jansson, C. Shih, R. Drummond, "MIME-based Secure EDI",
     Internet draft: draft-ietf-ediint-as1-05.txt, July 8,
     1997.
[8]  Alvestrand, Mapping between X400 and RFC-822/MIME Message bodies
     July 1997

[9]  ITU V42 bis, january 1990

9. Author's address
Jean Paul LAROCHE
GIE TEDECO
207, rue de Bercy
75012 PARIS
e-mail : gie.tedeco2@wanadoo.fr
Phone : 33 1 44 87 22 26
Fax :   33 1 44 87 22 22