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