idnits 2.17.1 draft-laroche-ted-net-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 441 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 25 has weird spacing: '...listing conta...' == Line 150 has weird spacing: '...sion of at on...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 388, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 391, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 397, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 409, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 412, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 416, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 419, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1894 (ref. '2') (Obsoleted by RFC 3464) == Outdated reference: A later version (-09) exists of draft-ietf-ediint-req-04 ** Downref: Normative reference to an Informational draft: draft-ietf-ediint-req (ref. '6') == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-05 ** Obsolete normative reference: RFC 822 (ref. '8') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 12 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 JP Laroche 2 INTERNET-DRAFT GIE TEDECO 3 CAP GEMINI 4 Expires : 08/1998 1998/01/24 6 The Ted.Net protocol for messaging based business interchanges 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use 21 Internet-Drafts as reference material or to cite them other 22 than as work in progress. 24 To learn the current status of any Internet-Draft, please check 25 the 1id-abstracts.txt listing contained in the Internet- 26 Drafts Shadow Directories on ds.internic.net (US East Coast), 27 ftp.nordu.net (Europe), ftp.isi.edu (US West Coast), or 28 munnari.oz.au (Pacific Rim), ftp.is.co.za (Africa). 30 Abstract 32 The Ted.Net protocol improves messaging systems while 33 being fully compatible with all of them. 34 Ted.Net improvements bring to messaging systems' end users : 35 - large file transfers capabilities, 36 - pretty good level of privacy, 37 - integrity control of the transfered data, 38 - time stamped proofs of the acceptance of data by the recipient. 39 With the secure and stable services of Ted.Net, users can rely on 40 private or public messaging systems, SMTP, X400, or editors' 41 ones, to put on Electronic Data Interchanges (EDI). 43 Table of contents 45 1. Introduction 46 1.1 The Ted.Net protocol 47 1.2 Discussion 48 1.3 Interest 49 2. The Ted.Net services 50 3. Messaging background 51 4. Coding 52 5. The use of the "subject" field 53 6. The Ted.Net header 54 7. The report message 55 8. References 56 9. Author's address 58 1. Introduction 59 1.1 The Ted.Net protocol 60 The Ted.Net protocol offers : 61 - sub addressing capability, 62 - compression and segmentation to allow large files transfer, 63 efficiency, and confidentiality, 64 - end to end control, 65 - recovery mechanism, 66 - content definition and process recommandation. 67 These services are described in section 2. 68 >From an architecture point of view, the software that handles 69 the Ted.Net protocol is interfaced with a standard mail client 70 software and with the end users (applications or/and persons). 71 For mail protocols, Ted.Net parameters are not visible ; 72 they look to belong to user's data. 73 To allow the largest inter operability, for a long while, 74 between messaging systems, Internet, X400 or editors' ones, 75 Ted.net relies on the minimum of common services of these 76 messaging systems to carry data. 78 1.2 Discussion 79 The Ted.Net protocol has been defined by a large group of EDI 80 actors who are exchanging today lots of mega bytes each month 81 through X400 systems, and who plan to do far more through SMTP. 82 We are quite confident in the improvements of Internet protocols 83 in the messaging domain. Works about Delivery Status Notification 84 (DSN), Message Disposition Notification (MDN) or "MIME based 85 Secure EDI" will offer new possibilities to mail users. But 86 DSN is chiefly useful when there is a doubt about the destination 87 address, which is rarely the case for business exchanges, and 88 MIME based Secure EDI solves control, non repudation or 89 confidentiality with PKCS which is very efficient, but difficult 90 to organize on a large scale, and in fact too sophisticated 91 for most current data transfers. The MDN is very near to fill 92 users' needs for transfers'control. But : 93 - the MDN draft is now in its seventh version, 94 - each message has to ask for MDN, which can bring some drawback in 95 case of contest, 96 - the MDN has a powerful option : it can be sent by the mail 97 provider or by the mail client; this point will 98 necessitate discussions between partners before they agree 99 on the conditions of an interchange ; furthermore, this option 100 will not facilitate audit in case of misfunctions, 101 - some important functionality, as integrity control, are still 102 lacking, either for the whole message or for each body part, 103 - the "processed" disposition type of MDN exceeds the transportation 104 notification's domain. It is an application information. 105 A "get" MDN will be the ultimate notification at the transport 106 level to tell to the sender that the responsability of the general 107 process is now at the recipient's side. 108 - the MDN is difficult to handle when "messages partial" are used, 109 - the MDN have to be translated by gateways. This is the main point 110 because translation is impossible if the corresponding notification 111 does not exist in the non Internet mail system or does not offer the 112 equivalent capabilities. The X400 Receipt notification for example 113 is used by providers only, to tell that a mesage was picked out 114 from a mail box. 115 Then, as MDN 116 - need still some amendments, 117 - are not available today by every mail providers, or by every 118 gateway providers, or in mail client softwares, 119 and because it is difficult for users to 120 - impose changes to mail system providers, 121 - extend industrial client softwares, 122 users can only add a piece of software between their applications 123 and their mail client software, to get immediately the appropriate 124 level of services. 125 The Ted.Net protocol defines this "add-on" to mail client software 126 that permits to wait comfortably for the future standards. 128 1.3 Interest 129 This draft is being distributed to members of the Internet 130 community in order to solicit their reactions to the 131 proposals contained in it. Two positive results may occur : 132 - some people in a hurry to use Internet for business exchanges 133 will adopt the Ted.net protocol, with or without amendments, 134 while waiting for the appropriate standards, 135 - the Ted.Net protocol contributes to the continuous improvement 136 of Internet standards, as the MDN or the message partial of SMTP. 138 2. The Ted.Net services 139 For end users, Ted.Net improves mail systems with the following 140 services : 141 - Sub-addressing 142 Several users or applications can share the same mailbox : One 143 site can have a single mailbox for lots of applications without 144 any confusion between the corresponding flows of data. 145 The sub-addresses are under the responsability of agencies who 146 can handle their own private groups of partners. 148 - Compression and segmentation of large files 149 We call a "batch" the whole data that an originator asks the 150 transmission of at one time. 151 At the sender's side, the batch is compressed. If the result is 152 still too large to cross some mail system, it is cut in 153 segments so that each segment can be forwarded in a single message, 154 even by the weakest mail system. The receiver does the reverse 155 processing : he reassembles the segments and decompresses the 156 data. 157 It can be noticed that end to end compression and segmentation 158 does not only improve efficiency at the transport level, but 159 that it minimizes also storage needs in the intermediate hosts 160 and in mailboxes. 161 Last but not least, end to end compression and 162 segmentation bring a significant level of confidentiality : 163 data are never transferred nor stored in a clear 164 format, and, with an appropriate compression algorithm that 165 needs reassembling data before decompressing them, decompression 166 is not an easy task, chiefly when all messages don't use 167 the same way across mail systems. 169 - End to end control 170 At the receiving side, Ted.Net controls that the recipient 171 designated by its sub address exists, that it is able to process 172 the announced data, and that the integrality of the data can 173 be put to its disposal at a time compatible with the delay 174 fixed by the sender. 175 The result of these controls is sent back to the originator in a 176 report message which has a coded format to facilitate automatic 177 processing by an application. The report message can be an 178 "opening acknowledgement", if all the controls are positives, 179 or a "partial acknowledgement", if some messages are missing, 180 or a "negative acknowledgement", if recovery actions are no 181 more possible. 182 This end to end control is chiefly the mean to point a 183 transfer of responsibility between originator and recipient, 184 which is of the utmost importance in the EDI business. 185 It is also a master piece in the process of 186 auditing exchanges and of tracking dysfunctions. 188 The Ted.Net acknowledgement is more significant than the 189 receipt notification of X400 or than the MDN foreseen 190 in Internet as we explained it in the introduction to 191 justify actions at a user's level. 192 The Ted.Net end to end control is mandatory. This particularity 193 helps the detection of masquerade : It is difficult for a false 194 sender to prevent the report message to be sent back to the 195 legal declared sender, as he would have to intercept the report 196 message or to change the DNS of providers. So, a Ted.Net user who 197 receives an acknowledgement for a batch that he did not send, 198 can suspect a masquerade and give the alert. 200 - Recovery mechanism : 201 The Ted.Net protocol offers an optional recovery mechanism that 202 allows a recipient to get automatically lost messages, which 203 is useful if non reliable systems are used. 204 The receiver's Ted.Net software can ask for missing segments. 205 That operation can occur twice at most. After that, if the 206 received data are always incomplete, the receiver announces 207 the sender that the transfer has failed. 209 - Content definition 210 Ted.Net carries informations to tell to the receiver how it has to 211 process the data carried by the Ted.Net container. 212 This service permits transportation of all kinds of files, 213 fixed length files, variable length files, or unformatted files ; 214 the parameters associated with fixed or variable types of 215 files allow receivers to use the file system of every operating 216 systems. 217 When necessary, Ted.Net tells which presentation of data is 218 used, EDIFACT, MIME, ... and which mechanism improves security, 219 SMIME ... 221 3. Messaging background 222 Ted.Net containers are sent and received by traditional mail 223 user agents connected to mail transport systems. To be abble to 224 use all of them and to cross the gateways that interconnect 225 these mail systems, Ted.Net relies on the minimum of mail 226 services : 227 - Internet messaging 228 Ted.Net satisfies itself with the initial SMTP defined in 229 rfc821 and 822. From SMTP, Ted.Net uses only the sender's and the 230 receivers' addresses, and the subject field. Of course, Ted.net 231 containers can also be carried by SMTP versions that integrate 232 functionalities defined in more recent rfc (1425, 1426, 1870, 233 1891, 1893, 1894, 2034). 234 Ted.Net satisfies itself with the initial MIME version 1.0 235 defined in rfc1521 and 1522. In MIME, Ted.Net uses only a 236 body-part of type/sub-type "application/octet-stream", with the 237 content-transfer-encoding "base 64". Ted.Net containers can 238 transport user's data assembled with improved version of MIME 239 according to rfc1767, 1847, 1848, 1892, 2045 to 2049, 2077, 240 2110, 2112, ... or Internet drafts (ietf-receipt-mdn-05, ietf- 241 mime-sgml-related, dusse-smime-msg-spec, ...). 243 - X400 messaging 244 >From X411 (P1), Ted.Net uses only the following parameters : 245 Sender's and receivers' addresses, Content-type "IPM" (P2), no 246 transcoding. 247 >From X420 (P2), Ted.Net uses the subject field and the body-part 248 of type 14, "bilaterally defined". 249 These services are provided by all x400 systems, from the first 250 X400-84 to the newest x400-96. 252 - Industrial messaging 253 In the same way, when Ted.Net relies on an industrial messaging 254 system, it needs only the sender's and receivers' addresses, 255 the subject, and a transparent body-part (not processed by 256 the mail agent software). 258 - Gateways 259 To allow inter-operability between subscribers of different 260 mail systems, gateways have to : 261 . Convert sender's and receiver's addresses on a symmetrical 262 way, so that the sender's address can be used by the receiver 263 to send back a response. 264 . Convert X400 body-part 14 into MIME body application/octet- 265 stream and reciprocally without processing the content ; do an 266 analogue conversion between the industrial messaging body and 267 the previous ones. 268 These conversions are done by most gateways. They are included 269 in the recommendations defined in rfc1664 and in the Internet 270 draft "ietf-mixer-bodymap". 272 4. Coding 273 Ted.Net parameters are assembled in a header situated between 274 the standard message body part header and the user's data. 275 For the message body-part used, the Ted.Net header is a part 276 of the user's data. 277 For simplicity reasons, and not to choose between the ASCII 278 lines of Internet and the basic encoding rules (BER) of X400, 279 Ted.Net parameters are fixed length coded. Thus the Ted.Net 280 header is 120 bytes long. 281 The Ted.Net report message is a Ted.Net message, with a Ted.Net 282 header and the content of which consists also of fixed length 283 parameters. 284 All Ted.Net parameters use only seven bits characters (numbers 285 are represented by text). 287 5. The use of the "subject" field 288 Ted.Net put a special sequence of characters, "TEDECOV301", at 289 the beginning of the subject field of messages, to help Ted.Net 290 messages recognition. 291 A receiver have to look for Ted.Net bodies only in messages 292 which have that sequence at the beginning of the subject field. 293 The remainder of the subject field is free for users. 295 6. The Ted.Net header 296 For each parameter we give the name, the position, the length, 297 the possible values and comments. The position 1 is the 298 position of the first byte that follows the standard header of 299 the body part. 300 Protocol name (1, 6) : "TEDECO" 301 Protocol version (7, 2) : "V3" 302 Protocol profile (9, 2) : "03" 303 Software identification (11, 2) : 306 Codification agency (13, 3) : ; this code is given by a 308 mother agency 309 Application code (16 ,3) : ; this code is attributed by a 311 codification agency. 312 Application code complement (19, 13) : . 314 Batch number (32, 6) : ; 316 if a batch is sent in several messages all the Ted.Net headers 317 will carry the same batch number. 318 Comment (38, 16) : . 319 Type of batch (54, 1) : "F", file, for user data, "A", 320 acknowledgement, for report message (cf. 7) 321 Subtype of batch (55, 1) : For the "F" type : "B", binary 322 file, "F", fixed length file, "V", variable length file ; for 323 the "A" type : "O", opening acknowledgement (transfer 324 successful), "P", partial acknowledgement, "N", negative 325 acknowledgement (transfer failed). 326 Batch format (56, 1) : "E", EDIFACT, other values under the 327 responsibility of coding agencies. 328 Length of record (57, 6) : . 331 Compression (63, 3) : "Z01" for V42 bis ; other codes are under 332 the responsibility of coding agencies. 333 Segment number (66, 2) : ; numbering starts from 01. 335 Largest segment number (68, 2) : 337 Batch length (70, 10) : 338 Opening delay (80, 3) : . 341 Sending date and time (83, 14) : ; this parameter has the 343 form CCYYMMDDThhmmZ (GMT time). 344 Recovery count (97, 1) : ; the first value is "1" and the maximum one, "3". 346 Added security (98, 4) : . 348 Content presentation (102, 2) : "M1" for MIME content 349 compatible with rfc1521, other codes are under the 350 responsibility of coding agencies. 352 7. The report message 353 The report message uses the Ted.Net header with the batch type 354 "A" and the appropriate subtype, "O", "P" or "N". 355 The report itself is a structured list of parameters that we 356 describe as the Ted.Net header, the position 1 being the first 357 byte that follows the Ted.Net header. 358 Date and time (1, 14) : , on the form CCYYMMDDThhmmZ (GMT time). 360 Diagnostic family (15, 2) : "01", invalid data type for a 361 parameter in the header ; "02" invalid value for a parameter ; 362 "03", impossibility to reconstitute the batch ; "04", local 363 problem at the receiver's side ; "05", incomplete batch ; "06", 364 batch rejected by the receiver. 365 Detail code (17,2) : that precises the 366 diagnostic. 368 Reports of "P" type, partial acknowledgement, have the 369 following additional parameters : 370 First missing segment (19, 2) : , 372 Second missing segment (21, 2) : idem 373 ... 374 End of the list of missing segments : CR-LF. 375 The list of missing segments can be optimised this way : 376 --xx : all segments until the xx segment (included) 377 xx-- : all segments from the xx segment (included) 378 xx--yy : all segments between xx and yy segments (included) 379 ---- : all the segments of a batch 381 An annex with the list of error codes will be provided later. 383 8. References 384 References dealing with messaging appear first, 385 then come references dealing with the content of messages 386 or of general interest. 388 [1] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 389 August 1, 1982. 391 [2] K. Moore, G. Vaudreuil, "An Extensible Message Format for 392 Delivery Status Notification", RFC 1894, January, 1996. 394 [3] R. Fajman, "An Extensible Message Format for Message Disposition 395 Notifications", draft-ietf-receipt-mdn-07.txt, July, 1997. 397 [4] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 398 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 399 December 02, 1996. 401 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 402 (MIME) Part Two: Media Types", RFC 2046, December 02, 403 1996. 405 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 406 (MIME) Part Five: Conformance Criteria and Examples", RFC 407 2049, December 02, 1996. 409 [5] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 410 March 2, 1995. 412 [6] M. Jansson, C. Shih, R. Drummond, "Requirements for 413 Inter-operable Internet EDI", Internet draft : 414 draft-ietf-ediint-req-04.txt, July 8, 1997. 416 [7] M. Jansson, C. Shih, R. Drummond, "MIME-based Secure EDI", 417 Internet draft: draft-ietf-ediint-as1-05.txt, July 8, 418 1997. 419 [8] Alvestrand, Mapping between X400 and RFC-822/MIME Message bodies 420 July 1997 422 [9] ITU V42 bis, january 1990 424 9. Author's address 425 Jean Paul LAROCHE 426 GIE TEDECO 427 207, rue de Bercy 428 75012 PARIS 429 e-mail : gie.tedeco2@wanadoo.fr 430 Phone : 33 1 44 87 22 26 431 Fax : 33 1 44 87 22 22