idnits 2.17.1 draft-friend-oftp2-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 6006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5989. 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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 6034 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2204, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1077 has weird spacing: '...ecision o----...' == Line 1106 has weird spacing: '...to send o---...' == Line 5948 has weird spacing: '... EMail info@...' == Line 5949 has weird spacing: '... Web www....' -- 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.) -- The document date (April 2007) is 6193 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TCP' is mentioned on line 450, but not defined == Missing Reference: 'Ba' is mentioned on line 1403, but not defined == Missing Reference: 'Ca' is mentioned on line 1422, but not defined == Missing Reference: 'Cb' is mentioned on line 1428, but not defined == Unused Reference: 'RFC-739' is defined on line 5896, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'RFC-739') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3850 (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ieuan Friend 2 Internet-Draft ODETTE 3 Obsoletes: RFC 2204 April 2007 4 Category: Informational 6 ODETTE File Transfer Protocol 2.0 7 draft-friend-oftp2-04 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may 17 not be created, except to publish it as an RFC and to translate it 18 into languages other than English. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The IEFT Trust (2007). 40 Abstract 42 This memo updates the ODETTE File Transfer Protocol, an established 43 file transfer protocol facilitating electronic data interchange 44 of business data between trading partners, to version 2.0. 46 The protocol now supports secure and authenticated communication 47 over the Internet using Transport Layer Security, provides file 48 encryption, signing and compression using Cryptographic Message 49 Syntax and provides signed receipts for the acknowledgement of 50 received files. 52 The protocol supports both direct peer to peer communication and 53 indirect communication via a Value Added Network and may be used 54 with TCP/IP, X.25 and ISDN based networks. 56 Table of Contents 58 1. Introduction 59 1.1 - Background 60 1.2 - Summary Of Features 61 1.3 - General Principles 62 1.4 - Structure 63 1.5 - Virtual Files 64 1.6 - Service Description 65 1.7 - Security 67 2. Network Service 68 2.1 - Introduction 69 2.2 - Service Primitives 70 2.3 - Secure ODETTE-FTP Session 71 2.4 - Port Assignment 73 3. File Transfer Service 74 3.1 - Model 75 3.2 - Session Setup 76 3.3 - File Transfer 77 3.4 - Session Take Down 78 3.5 - Service State Automata 80 4. Protocol Specification 81 4.1 - Overview 82 4.2 - Start Session Phase 83 4.3 - Start File Phase 84 4.4 - Data Transfer Phase 85 4.5 - End File Phase 86 4.6 - End Session Phase 87 4.7 - Problem Handling 89 5. Commands and Formats 90 5.1 - Conventions 91 5.2 - Commands 92 5.3 - Command Formats 93 5.4 - Identification Code 95 6. File Services 96 6.1 - Overview 97 6.2 - File Signing 98 6.3 - File Encryption 99 6.4 - File Compression 100 6.5 - V Format Files - Record Lengths 102 7. ODETTE-FTP Data Exchange Buffer 103 7.1 - Overview 104 7.2 - Data Exchange Buffer Format 105 7.3 - Buffer Filling Rules 107 8. Stream Transmission Buffer 108 8.1 - Introduction 109 8.2 - Stream Transmission Header Format 111 9. Protocol State Machine 112 9.1 - ODETTE-FTP State Machine 113 9.2 - Error Handling 114 9.3 - States 115 9.4 - Input Events 116 9.5 - Output Events 117 9.7 - Local Variables 118 9.8 - Local Constants 119 9.9 - Session Connection State Table 120 9.10 - Error and Abort State Table 121 9.11 - Speaker State Table 1 122 9.12 - Speaker State Table 2 123 9.13 - Listener State Table 124 9.14 - Example 126 10. Miscellaneous 127 10.1 - Algorithm Choice 128 10.2 - Cryptographic Algorithms 129 10.3 - Protocol Extensions 130 10.4 - Security Considerations 132 Appendix A Virtual File Mapping Example 133 Appendix B ISO 646 Character Subset 134 Appendix C X.25 Specific Information 135 Appendix D OFTP X.25 Over ISDN Recommendation 137 IANA Considerations 138 Acknowledgements 139 Informative References 140 Normative References 141 ODETTE Address 142 Author's Address 143 Copyright 145 1. Introduction 147 1.1 Background 149 The ODETTE File Transfer Protocol (ODETTE-FTP) was defined in 1986 by 150 working group four of the Organisation for Data Exchange by Tele 151 Transmission in Europe (ODETTE) to address the electronic data 152 interchange (EDI) requirements of the European automotive industry. 154 The ODETTE-FTP allows business applications to exchange files on a 155 peer to peer basis in a standardised, purely automatic manner and 156 provides a defined acknowledgment process on successful receipt of 157 a file. 159 ODETTE-FTP is not to be confused as a variant of, or similar to, the 160 Internet FTP [FTP] which provides an interactive means for individuals 161 to share files and which does not have any sort of acknowledgement 162 process. By virtue of its interactive nature, lack of file 163 acknowledgements and client/server design, FTP does not easily lend 164 itself to mission critical environments for the exchange of business 165 data. 167 Over the last ten years ODETTE-FTP has been widely deployed on 168 systems of all sizes from personal computers to large mainframes 169 while the Internet has emerged as the dominant international network, 170 providing high speed communication at low cost. To match the demand 171 for EDI over the Internet, ODETTE has decided to extend the scope of 172 its file transfer protocol to incorporate security functions and 173 advanced compression techniques to ensure that it remains at the 174 forefront of information exchange technology. 176 The protocol now supports secure and authenticated communication 177 over the Internet using Transport Layer Security, provides file 178 encryption, signing and compression using Cryptographic Message 179 Syntax and provides signed receipts for the acknowledgement of 180 received files. 182 The protocol supports both direct peer to peer communication and 183 indirect communication via a Value Added Network and may be used 184 with TCP/IP, X.25 and ISDN based networks. 186 ODETTE-FTP has been defined by the ODETTE Security Working Group 187 which consists of a number of ODETTE member organisations. 188 All members have significant operational experience working with 189 and developing OFTP and EDI solutions. 191 1.2 Summary Of Features 193 This memo is a development of version 1.4 of the ODETTE-FTP [OFTP] 194 with these changes/additions - 196 Session level encryption 197 File level encryption 198 Secure authentication 199 File compression 200 Signed EERP 201 Signed NERP 202 Maximum permitted file size increased to 9PB (petabytes) 203 Virtual file description added 204 Extended error codes 206 Version 1.4 of ODETTE-FTP included these changes and additions to 207 version 1.3 - 209 Negative End Response (NERP) 210 Extended Date and Timestamp 211 New reason code 14 (File direction refused) 213 1.3 General Principles 215 The aim of the ODETTE-FTP is to facilitate the transmission of a file 216 between one or more locations in a way that is independent of the 217 data communication network, system hardware and software environment. 219 In designing and specifying the protocol, the following factors were 220 considered. 222 1. The possible differences of size and sophistication of file storage 223 and small and large systems. 225 2. The necessity to work with existing systems (reduce changes to 226 existing products and allow easy implementation). 228 3. Systems of different ages. 230 4. Systems of different manufactures. 232 5. The potential for growth in sophistication (limit impact and avoid 233 changes at other locations). 235 1.4 Structure 237 ODETTE-FTP is modelled on the OSI reference model. It is designed to 238 use the Network Service provided by level 3 of the model and provide 239 a File Service to the users. Thus the protocol spans levels 4 to 7 240 of the model. 242 The description of the ODETTE-FTP contained in this memo is closely 243 related to the original 'X.25' specification of the protocol and in 244 the spirit of the OSI model describes: 246 1. A File Service provided to a user monitor. 248 2. A protocol for the exchange of information between peer 249 ODETTE-FTP entities. 251 1.5 Virtual Files 253 Information is always exchanged between ODETTE-FTP entities in a 254 standard representation called a Virtual File. This allows data 255 transfer without regard for the nature of the communicating systems. 257 The mapping of a file between a local and virtual representation will 258 vary from system to system and is not defined here. 260 o---------o 261 Site | Local | 262 A | File A | 263 o---------o 264 | 265 o----------------------- Mapping A ------------------------o 266 | | | 267 | o---------o | 268 | | Virtual | | 269 | | File | | 270 | o---------o | 271 | o------------------------------------------------o | 272 | | | | 273 | | ODETTE-FTP | | 274 | | | | 275 | o------------------------------------------------o | 276 | o---------o o---------o | 277 | | Virtual | | Virtual | | 278 | | File | | File | | 279 | o---------o o----+----o | 280 | | | | 281 o------ Mapping B ------------------------ Mapping C ------o 282 | | 283 o---------o o----+----o 284 | Local | Site Site | Local | 285 | File B | B C | File C | 286 o---------o o---------o 288 A Virtual File is described by a set of attributes identifying and 289 defining the data to be transferred. The main attributes are: 291 1.5.1 Organisation: 293 Sequential 295 Logical records are presented one after another. The ODETTE-FTP 296 must be aware of the record boundaries. 298 1.5.2 Identification 300 Dataset Name 302 Dataset name of the Virtual File being transferred, assigned by 303 bilateral agreement. 305 Time stamp (HHMMSScccc) 307 A file qualifier indicating the time the Virtual File was made 308 available for transmission. The counter (cccc=0001-9999) gives 309 higher resolution. 311 Date stamp (CCYYMMDD) 313 A file qualifier indicating the date the Virtual File was made 314 available for transmission. 316 The Dataset Name, Date and Time attributes are assigned by the Virtual 317 File's originator and are used to uniquely identify a file. They 318 are all mandatory and must not be changed by intermediate locations. 320 The User Monitor may use the Virtual File Date and Time attributes 321 in local processes involving date comparisons and calculations. Any 322 such use falls outside the scope of this protocol. 324 1.5.3 Record Format 326 Four record formats are defined - 328 Fixed (F) 330 Each record in the file has the same length. 332 Variable (V) 334 The records in the file can have different lengths. 336 Unstructured (U) 338 The file contains a stream of data. No structure is defined. 340 Text File (T) 342 A Text File is defined as a sequence of ASCII characters, 343 containing no control characters except CR-LF which delimit 344 lines. A line will not have more than 2048 characters. 346 1.5.4 Restart 348 ODETTE-FTP can negotiate the restart of an interrupted Virtual File 349 transmission. Fixed and Variable format files are restarted on 350 record boundaries. For Unstructured and Text files the restart 351 position is expressed as a file offset in 1K (1024 octet) blocks. 352 The restart position is always calculated relative to the start of 353 the Virtual File. 355 1.6 Service Description 357 ODETTE-FTP provides a file transfer service to a user monitor and in 358 turn uses the Internet transport layer stream service to communicate 359 between peers. 361 These services are specified in this memo using service primitives 362 grouped into four classes as follows: 364 Request (RQ) An entity asks the service to do some work. 365 Indication (IND) A service informs an entity of an event. 366 Response (RS) An entity responds to an event. 367 Confirm (CF) A service informs an entity of the response. 369 Services may be confirmed, using the request, indication, response 370 and confirm primitives, or unconfirmed using just the request and 371 indication primitives. 373 1.7 Security 375 ODETTE-FTP provides a number of security services to protect a 376 Virtual File transmission across a hostile network. 378 These security services are as follows: 380 Confidentiality 381 Integrity 382 Non-repudiation of receipt 383 Non-repudiation of origin 384 Secure authentication 386 Security services in this specification are implemented as follows: 388 Session level encryption 389 File level encryption 390 Signed files 391 Signed receipts 392 Session level authentication 393 ODETTE-FTP Authentication 395 Session level encryption provides data confidentiality by encryption 396 of all the protocol commands and data exchanged between two parties, 397 preventing a third party from extracting any useful information from 398 the transmission. 400 This session level encryption is achieved by layering ODETTE-FTP 401 over [TLS], Transport Layer Security, distinguishing between secure 402 and unsecure TCP/IP traffic using different port numbers. 404 File encryption provides complementary data confidentiality by 405 encryption of the files in their entirety. Generally this 406 encryption occurs prior to transmission, but it is also possible to 407 encrypt and send files while in session. File encryption has the 408 additional benefit of allowing a file to remain encrypted outside of 409 the communications session in which it was sent. The file can be 410 received and forwarded by multiple intermediaries, yet only the 411 final destination will be able to decrypt the file. File encryption 412 does not encrypt the actual protocol commands, so trading partner 413 EDI codes and Virtual File Names are still viewable. 415 Secure authentication is implemented through the session level 416 authentication features available in [TLS] and proves the identity of 417 the parties wishing to communicate. 419 ODETTE-FTP Authentication also provides an authentication mechanism, 420 but one that is integral to ODETTE-FTP and is available on all 421 network infrastructures over which ODETTE-FTP is operated (this is in 422 contrast to [TLS] which is generally only available over TCP/IP based 423 networks). Both parties are required to possess certificates when 424 ODETTE-FTP Authentication is used. 426 The security features in ODETTE-FTP 2.0 are centred around the use of 427 [X.509] certificates. To take advantage of the complete range of 428 security services offered in both directions, each party is required 429 to possess an [X.509] certificate. If the confidentiality of data 430 between two parties is the only concern, then [TLS] alone can be used 431 which allows the party accepting an incoming connection 432 (the Responder) to be the only partner required to possess a 433 certificate. 435 For businesses this means that session level encryption between a hub 436 and its trading partners can be achieved without requiring all the 437 trading partners to obtain a certificate, assuming that trading 438 partners always connect to the hub. 440 With the exception of [TLS], all the security services work with X.25 441 and ISDN as transport media. Although nothing technically precludes 442 [TLS] from working with X.25 or ISDN, implementations are rare. 444 2. Network Service 446 2.1 Introduction 448 ODETTE-FTP peer entities communicate with each other via the OSI 449 Network Service or the Transmission Control Protocol Transport 450 Service [TCP]. This is described by service primitives representing 451 request, indication, response and confirmation actions. 453 For the Internet environment, the service primitives mentioned below 454 for the Network Service have to be mapped to the respective Transport 455 Service primitives. This section describes the network service 456 primitives used by ODETTE-FTP and their relationship to the TCP 457 interface. In practice the local transport service application 458 programming interface will be used to access the TCP service. 460 2.2 Service Primitives 462 All Network primitives can be directly mapped to the respective 463 Transport primitives when using TCP. 465 2.2.1 Network Connection 467 N_CON_RQ ------> N_CON_IND 468 N_CON_CF <------ N_CON_RS 470 This describes the setup of a connection. The requesting ODETTE-FTP 471 peer uses the N_CON_RQ primitive to request an active OPEN of a 472 connection to a peer ODETTE-FTP, the Responder, which has previously 473 requested a passive OPEN. The Responder is notified of the incoming 474 connection via N_CON_IND and accepts it with N_CON_RS. The requester 475 is notified of the completion of its OPEN request upon receipt of 476 N_CON_CF. 478 Parameters 480 Request Indication Response Confirmation 481 --------------------------------------------------------------------- 482 Dest addr ------> same same same 484 2.2.2 Network Data 486 N_DATA_RQ ------> N_DATA_IND 488 Data exchange is an unconfirmed service. The Requester passes data 489 for transmission to the network service via the N_DATA_RQ primitive. 490 The Responder is notified of the availability of data via N_DATA_IND. 491 In practice the notification and receipt of data may be combined, 492 such as by the return from a blocking read from the network socket. 494 Parameters 496 Request Indication 497 --------------------------------------------------------------------- 498 Data ------------------> same 500 2.2.3 Network Disconnection 502 N_DISC_RQ ------> N_DISC_IND 504 An ODETTE-FTP requests the termination of a connection with the 505 N_DISC_RQ service primitive. Its peer is notified of the CLOSE by a 506 N_DISC_IND event. It is recognised that each peer must issue a 507 N_DISC_RQ primitive to complete the TCP symmetric close procedure. 509 2.2.4 Network Reset 511 ------> N_RST_IND 513 An ODETTE-FTP entity is notified of a network error by a N_RST_IND 514 event. It should be noted that N_RST_IND would also be generated by 515 a peer RESETTING the connection, but this is ignored here as N_RST_RQ 516 is never sent to the Network Service by ODETTE-FTP. 518 2.3 Secure ODETTE-FTP Session 520 [TLS] provides a mechanism for securing an ODETTE-FTP session over 521 the Internet or a TCP network. ODETTE-FTP is layered over [TLS], 522 distinguishing between secure and unsecure traffic by using different 523 server ports. 525 The implementation is very simple. Layer the ODETTE-FTP over [TLS] in 526 the same way as layering ODETTE-FTP over TCP/IP. [TLS] provides both 527 session encryption and authentication, both of which may be used by 528 the connecting parties. A party acts as a [TLS] server when receiving 529 calls and acts as a [TLS] client when making calls. When the [TLS] 530 handshake has completed, the responding ODETTE-FTP may start the 531 ODETTE-FTP session by sending the Ready Message. 533 2.4 Port Assignment 535 An ODETTE-FTP requester will select a suitable local port. 537 The responding ODETTE-FTP will listen for connections on Registered 538 Port 3305, the service name is 'odette-ftp'. 540 The responding ODETTE-FTP will listen for secure TLS connections 541 on Registered Port 6619, the service name is 'odette-ftps'. 543 3. File Transfer Service 545 The File Transfer Service describes the services offered by an 546 ODETTE-FTP Entity to its User Monitor (generally an application). 548 NOTE: The implementation of the service primitives is an application 549 issue. 551 3.1 Model 553 o-------------------o o-------------------o 554 | | | | 555 | USER MONITOR | | USER MONITOR | 556 | | | | 557 o-------------------o o-------------------o 558 | A | A 559 ...............|...|... FILE TRANSFER SERVICE ...|...|............... 560 | | | | 561 F_XXX_RQ/RS | | F_XXX_IND/CF F_XXX_RQ/RS | | F_XXX_IND/CF 562 V | V | 563 o-------------------o o-------------------o 564 | |- - - - - - >| | 565 | ODETTE-FTP Entity | E-Buffer | ODETTE-FTP Entity | 566 | |< - - - - - -| | 567 o-------------------o o-------------------o 568 | A | A 569 N_XXX_RQ/RS | | N_XXX_IND/CF N_XXX_RQ/RS | | N_XXX_IND/CF 570 | | | | 571 ...............|...|...... NETWORK SERVICE ......|...|............... 572 V | V | 573 o---------------------------------------------------------o 574 | | 575 | N E T W O R K | 576 | | 577 o---------------------------------------------------------o 579 Key: E-Buffer - Exchange Buffer 580 F_ - File Transfer Service Primitive 581 N_ - Network Service Primitive 583 3.2 Session Setup 585 3.2.1 Session Connection Service 587 These diagrams represent the interactions between two communicating 588 ODETTE-FTP entities and their respective User Agents. 590 The vertical lines represent the ODETTE-FTP entities. 591 The User Agents are not shown. 593 | | 594 F_CONNECT_RQ ---->|------------|----> F_CONNECT_IND 595 | | 596 F_CONNECT_CF <----|------------|<---- F_CONNECT_RS 597 | | 599 Parameters 601 Request Indication Response Confirm 602 --------------------------------------------------------------------- 603 called-address -> same --- ---- 604 calling-address-> same --- ---- 605 ID1 ------------> same ID2 ------------> same 606 PSW1------------> same PSW2 -----------> same 607 mode1 ----------> mode2 ----------> mode3 ----------> same 608 restart1 -------> same -----------> restart2 -------> same 609 authentication1-> same -----------> authentication2-> same 610 --------------------------------------------------------------------- 612 Mode 614 Specifies the file transfer capabilities of the entity sending or 615 receiving a F_CONNECT primitive for the duration of the session. 617 Value: 618 Sender-Only The entity can only send files. 619 Receiver-Only The entity can only receive files. 620 Both The entity can both send and receive files. 622 Negotiation: 623 Sender-Only Not negotiable. 624 Receiver-Only Not negotiable. 625 Both Can be negotiated down to Sender-Only or 626 Receiver-Only by the User Monitor or the 627 ODETTE-FTP entity. 629 Request Indication Response Confirm 630 --------------------------------------------------------------------- 631 Sender-only ----> Receiver-only --> Receiver-only --> Sender-only 633 Receiver-only --> Sender-only ----> Sender-only ----> Receiver-only 635 Both -----+-----> Both ----+------> Both -----------> Both 636 | or +------> Receiver-only --> Sender-only 637 | or +------> Sender-only ----> Receiver-only 638 | 639 or +-----> Receiver-only --> Receiver-only --> Sender-only 640 or +-----> Sender-only ----> Sender-only ----> Receiver-only 641 --------------------------------------------------------------------- 643 Restart 645 Specifies the file transfer restart capabilities of the User 646 Monitor. 648 Value: 650 Negotiation: 652 Request Indication Response Confirm 653 --------------------------------------------------------------------- 654 restart = Y ----> restart = Y --+-> restart = Y ----> restart = Y 655 or +-> restart = N ----> restart = N 657 restart = N ----> restart = N ----> restart = N ----> restart = N 658 --------------------------------------------------------------------- 660 Authentication 662 Specifies the authentication requirement of the User Monitor. 664 Value: 665 Y Authentication required. 666 N Authentication not required. 668 Negotiation: Not negotiable. 670 Request Indication Response Confirm 671 --------------------------------------------------------------------- 672 auth = Y ----> auth = Y ----> auth = Y ----> auth = Y 674 auth = N ----> auth = N ----> auth = N ----> auth = N 675 --------------------------------------------------------------------- 677 3.3 File Transfer 679 3.3.1 File Opening 681 | | 682 F_START_FILE_RQ ---->|------------|----> F_START_FILE_IND 683 | | 684 F_START_FILE_CF(+|-) <----|------------|<---- F_START_FILE_RS(+|-) 685 | | 687 Parameters: 689 Request Ind. RS(+) CF(+) RS(-) CF(-) 690 ------------------------------------------------------------------ 691 filename-------> same ---- ---- ---- ---- 692 date-time------> same ---- ---- ---- ---- 693 destination----> same ---- ---- ---- ---- 694 originator-----> same ---- ---- ---- ---- 695 rec-format-----> same ---- ---- ---- ---- 696 rec-size ------> same ---- ---- ---- ---- 697 file-size------> same ---- ---- ---- ---- 698 org-file-size--> same ---- ---- ---- ---- 699 signed-eerp----> same ---- ---- ---- ---- 700 cipher---------> same ---- ---- ---- ---- 701 sec-services---> same ---- ---- ---- ---- 702 compression----> same ---- ---- ---- ---- 703 envelope-format> same ---- ---- ---- ---- 704 description----> same ---- ---- ---- ---- 705 restart-pos1---> same-> restart-pos2-> same ---- ---- 706 ---- ---- ---- ---- cause ------> same 707 ---- ---- ---- ---- retry-later-> same 708 ------------------------------------------------------------------ 710 Notes: 712 1. Retry-later has values "Y" or "N". 713 2. Cause is the reason for refusing the transfer (1,..,13,99). 714 3. Restart-pos1 not equal 0 is only valid if restart has been 715 agreed during initial negotiation. 716 4. Restart-pos2 is less than or equal to restart-pos1. 718 3.3.2 Data Regime 720 | | 721 F_DATA_RQ ---->|------------|----> F_DATA_IND 722 | | 723 F_DATA_CF <----|(---CDT----)| 724 | | 726 Note: 728 Unlike other commands, where the F_XXX_CF signal is a result of 729 a corresponding F_XXX_RS command, in this case, the local entity 730 layer issues this signal when it is ready for the next data 731 request. This decision is based on the current credit count and 732 the reception of CDT from the receiver. 734 3.3.3 File Closing 736 | | 737 F_CLOSE_FILE_RQ --->|------------|----> F_CLOSE_FILE_IND 738 | | 739 F_CLOSE_FILE_CF(+|-) <---|------------|<---- F_CLOSE_FILE_RS(+|-) 740 | | 741 Parameters 743 Request Ind RS(+) CF(+) RS(-) CF(-) 744 --------------------------------------------------------------------- 745 rec-count ---> same ---- ---- ---- ---- 746 unit-count --> same ---- ---- ---- ---- 747 ---- ---- Speaker=Y ---> Speaker=N ---- ---- 748 ---- ---- Speaker=N ---> Speaker=Y ---- ---- 749 ---- ---- ---- ---- cause ---> same 750 --------------------------------------------------------------------- 752 In a positive Close File response (F_CLOSE_FILE_RS(+)) the current 753 Listener may either: 755 1. Set Speaker to "Yes" and become the Speaker. 2. Set Speaker 756 to "No" and remain the Listener. 758 The File Transfer service will ensure that the setting of the speaker 759 parameter is consistent with the capabilities of the peer user. 761 The turn is never exchanged in the case of a negative response or 762 confirmation. 764 Only the Speaker is allowed to issue F_XXX_FILE_RQ primitives. 766 3.3.4 Exchanging the Turn 768 3.3.4.1 Initial Turn (First Speaker) 770 The Initiator becomes the first Speaker at the end of the Session 771 Setup (F_CONNECT_CF received by Initiator and F_CONNECT_RS sent by 772 Responder). 774 3.3.4.2 Following Turns 776 Rules: 778 1. At each unsuccessful End of File the turn is not exchanged. 780 2. At each successful End of File the turn is exchanged if requested 781 by the Listener: 783 - The current Listener receives F_CLOSE_FILE_IND 784 (Speaker = choice). 786 - If the Listener answers F_CLOSE_FILE_RS(Speaker = YES), it 787 becomes Speaker, the Speaker receives F_CLOSE_FILE_CF (Speaker = 788 NO) and becomes Listener. 790 - If the Listener answers F_CLOSE_FILE_RS(Speaker = NO), it 791 remains Listener, and the Speaker receives F_CLOSE_FILE_CF 792 (Speaker = YES) and remains Speaker. 794 3. The Speaker can issue a Change Direction request (F_CD_RQ) to 795 become the Listener. The Listener receives a Change Direction 796 indication (F_CD_IND) and becomes the Speaker. 798 4. In order to prevent loops of F_CD_RQ/IND, the Speaker may not send 799 an F_CD_RQ after receiving an unsolicited F_CD_IND. If the 800 Listener receives a solicited F_CD_IND as a result of sending 801 EFPA(Speaker=Yes), it is acceptable to immediately relinquish the 802 right to speak by sending an F_CD_RQ. 804 3.3.5 End to End Response 806 This service is initiated by the current Speaker (if there is no file 807 transfer in progress) to send an End-to-End response from the final 808 destination to the originator of a file. 810 | | 811 F_EERP_RQ ---->|------------|----> F_EERP_IND 812 | | 813 F_RTR_CF <----|------------|<---- F_RTR_RS 814 | | 815 Parameters 817 Request Indication 818 ------------------------------------ 819 filename -----------> same 820 date ---------------> same 821 time ---------------> same 822 destination --------> same 823 originator ---------> same 824 hash ---------------> same 825 signature ----------> same 826 ------------------------------------ 828 Relationship with Turn: 830 - Only the Speaker may send an End to End Response request. 832 - Invoking the EERP service does not change the turn. 834 - If a F_CD_IND has been received just before F_EERP_RQ is issued, 835 this results in leaving the special condition created by the 836 reception of F_CD_IND; i.e. while it was possible to issue 837 F_RELEASE_RQ and not possible to issue F_CD_RQ just after the 838 reception of F_CD_IND, after having issued F_EERP_RQ the normal 839 Speaker status is entered again (F_CD_RQ valid, but F_RELEASE_RQ 840 not valid). 842 Notes: 844 1. The F_EERP_RQ (and also F_NERP_RQ) is confirmed with an F_RTR_CF 845 signal. The F_RTR_CF signal is common to both F_EERP_RQ and 846 F_NERP_RQ. There should be no ambiguity, since there can only be 847 one such request pending at any one time. 849 2. The signature is optional and is requested when sending the 850 F_START_FILE_RQ. 852 3. If it is not possible to sign the EERP, then an unsigned 853 EERP should still be sent. 855 4. It is an application implementation issue to validate the contents 856 of the EERP and its signature and to decide what action to take 857 on receipt of an EERP that fails validation or is not signed when 858 a signed EERP was requested. 860 3.3.6 Negative End Response 862 This service is initiated by the current speaker (if there is no file 863 transfer in progress) to send a negative end response when a file 864 could not be transmitted to the next destination. It is sent only if 865 the problem is of a non-temporary kind. 867 This service may also be initiated by the final destination instead 868 of sending an End-to-End Response when a file could not be processed, 869 after having successfully received the file. 871 | | 872 F_NERP_RQ ---->|------------|----> F_NERP_IND 873 | | 874 F_RTR_CF <----|------------|----- F_RTR_RS 875 | | 876 Parameters 878 Request Indication 879 --------------------------------------------------- 880 filename ----------------------> same 881 date --------------------------> same 882 time --------------------------> same 883 destination -------------------> same 884 originator --------------------> same 885 creator of negative response --> same 886 reason ------------------------> same 887 reason text -------------------> same 888 hash --------------------------> same 889 signature ---------------------> same 890 --------------------------------------------------- 892 Relationship with Turn: 894 The same as for the End-To-End response (see 3.3.5). 896 3.4 Session Take Down 898 3.4.1 Normal Close 900 | | 901 F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND 902 | | 904 Parameters 906 Request Indication 907 --------------------------------------------------------------------- 908 reason = normal -------> ---- 909 --------------------------------------------------------------------- 911 The Release service can only be initiated by the Speaker. 913 The Speaker can only issue a Release request (F_RELEASE_RQ) just 914 after receiving an unsolicited Change Direction indication 915 (F_CD_IND). This ensures that the other partner doesn't want to send 916 any more files in this session. 918 Peer ODETTE-FTP entities action a normal session release by 919 specifying Reason = Normal in an End Session (ESID) command. 921 3.4.2 Abnormal close 923 | | 924 F_RELEASE_RQ ---->|------------|----> F_ABORT_IND 925 | | 927 Parameters 929 Request Indication 930 --------------------------------------------------------------------- 931 reason = error value --> same (or equivalent) 932 AO (Abort Origin) = (L)ocal or (D)istant 933 --------------------------------------------------------------------- 935 Abnormal session release can be initiated by either the Speaker or 936 the Listener and also by the user or provider. 938 Abnormal session release can occur at any time within the session. 940 Peer ODETTE-FTP entities action an abnormal session release by 941 specifying Reason = Error-value in an End Session (ESID) command. 943 The abnormal session release deals with the following types of error: 945 1. The service provider will initiate an abnormal release in the 946 following cases: 948 1. Protocol error. 949 2. Failure of the Start Session (SSID) negotiation. 950 3. Command not recognised. 951 4. Data Exchange buffer size error. 952 5. Resources not available. 953 6. Other unspecified abort code (with "REASON" = unspecified). 955 2. The User Monitor will initiate an abnormal release in the 956 following cases: 958 1. Local site emergency close down. 959 2. Resources not available. 960 3. Other unspecified abort code (with "REASON" = unspecified). 962 Other error types may be handled by an abort of the connection. 964 3.4.3 Abort 966 | | 967 F_ABORT_RQ ---->|------------|----> F_ABORT_IND 968 | | 969 User Initiated Abort 971 | | 972 F_ABORT_IND <----|------------|----> F_ABORT_IND 973 | | 974 Provider Initiated Abort 976 Parameters 978 Request Indication 979 --------------------------------------------------------------------- 980 -- R (Reason): specified or unspecified 981 -- AO (Abort Origin): (L)ocal or (D)istant 982 --------------------------------------------------------------------- 984 The Abort service may be invoked by either entity at any time. 986 The service provider may initiate an abort in case of error 987 detection. 989 3.4.4 Explanation of Session Take Down Services 991 User | OFTP | Network | OFTP | User 992 ---------------|------|----------------------|------|--------------- 993 | | | | 995 1. Normal Release 997 F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND 998 *--------------|-> ==|======================|=> --|--------------> 999 (R=normal) | | | | 1001 2. User Initiated Abnormal Release 1003 F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND 1004 *--------------|-> ==|======================|=> -|--------------> 1005 (R=error value)| | | | (R=error,AO=D) 1007 User | OFTP | Network | OFTP | User 1008 ---------------|------|----------------------|------|--------------- 1009 | | | | 1011 3. Provider Initiated Abnormal Release 1013 F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND 1014 <--------------|-* *=|======================|=> --|--------------> 1015 | | | | 1017 4. User Initiated Connection Abort 1019 F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND 1020 *--------------|-> --|--------->..----------|-> --|--------------> 1021 | | N_DISC_IND | | (R=unsp.,AO=D) 1023 5. Provider Initiated Connection Abort 1025 F_ABORT_IND | | N_DISC_RQ | | F_ABORT_IND 1026 <--------------|-* *-|--------->..----------|-> --|--------------> 1027 (R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D) 1029 Key: * Origin of command flow 1030 F_ ---> File Transfer Service primitive 1031 N_ ---> Network Service primitive 1032 ===> ODETTE-FTP (OFTP) protocol message 1034 3.5 Service State Automata 1036 These state automata define the service as viewed by the User 1037 Monitor. Events causing a state transition are shown in lower case 1038 and the resulting action in upper case where appropriate. 1040 3.5.1 Idle State Diagram 1042 o------------o 1043 decision | | f_connect_ind 1044 +-----------------| IDLE |-----------------+ 1045 | F_CONNECT_RQ | (0) | F_CONNECT_RS | 1046 | o------------o | 1047 V | 1048 o-----------------o | 1049 | | | 1050 | I_WF_FCONNECTCF | | 1051 | | | 1052 o--------+--------o | 1053 | | 1054 | F_CONNECT_CF | 1055 V V 1056 o-----------------o o-----------------o 1057 | | | | 1058 | IDLE SPEAKER | | IDLE LISTENER | 1059 | (1) | | (2) | 1060 | See Speaker | | See Listener | 1061 | State Diagram | | State Diagram | 1062 | | | | 1063 o-----------------o o-----------------o 1065 3.5.2 Speaker State Diagram 1066 o-----------------o o-----------------o 1067 | IDLE LISTENER | | IDLE | 1068 | CD_RQ just sent | | see (0) | 1069 | see (3), Listen | | Idle | 1070 | State Diagram | | State Diagram | 1071 o-----------------o o-----------------o 1072 A A 1073 | | 1074 decision decision 1075 F_CD_RQ F_RELEASE_RQ 1076 | | 1077 o================o decision o----------o decision o---------------o 1078 | |---------->| WAIT FOR |<----------| | 1079 | | F_EERP_RQ | | F_EERP_RQ | | 1080 | IDLE | | EERP/ | | IDLE | 1081 | SPEAKER | decision | NERP | decision | SPEAKER | 1082 | (1) |---------->| CONFIRM. |<----------| (4) | 1083 | | F_NERP_RQ | | F_NERP_RQ | | 1084 | | | | | | 1085 | | | | | CD_IND | 1086 | | f_rtr_cf | | | just received | 1087 | |<----------| | | | 1088 | | o----------o | | 1089 | | | | 1090 | | | | 1091 o================o o---------------o 1092 A A | | 1093 | | | decision and P2 decision and P2 | 1094 | | +-----------------+ +---------------------+ 1095 | | F_START_FILE_RQ | | F_START_FILE_RQ 1096 | | V V 1097 | | o---------------o 1098 | | f_file_start_cf(-) | | 1099 | +----------------------| OPENING | 1100 | | | 1101 | o---------------o 1102 | | 1103 f_file_close_cf(-) or f_start_file_cf(+) 1104 f_file_close_cf(+) and not P1 | 1105 | V 1106 o---------------o o---------------o record to send o---------o 1107 | | | |------------------>| | 1108 | CLOSING | | DATA TRANSFER | F_DATA_RQ | NEXT | 1109 | | | | | RECORD | 1110 | | | | f_data_cf | | 1111 | | | |<------------------| | 1112 o---------------o o---------------o o---------o 1113 | A | 1114 | | end of file | 1115 | +-------------------+ 1116 | F_CLOSE_FILE_RQ 1117 | o-----------------o 1118 | f_file_close_cf(+) and P1 | IDLE LISTENER | 1119 +--------------------------------------------->| see (2), Listen | 1120 | State Diagram | 1121 Predicates: o-----------------o 1122 P1: Positive confirmation and Speaker = YES 1123 P2: Mode = Both or (Mode = Sender-Only) 1125 3.5.3 Listener State Diagram 1126 o-----------------o o-----------------o 1127 | IDLE SPEAKER | | IDLE | 1128 | CD_IND just | | | 1129 | received see(4) | | see (0) | 1130 | Speaker State | | Idle | 1131 | Diagram | | State Diagram | 1132 o-----------------o o-----------------o 1133 A A 1134 | | 1135 decision f_eerp_ind decision 1136 F_CD_IND +--------------+ F_RELEASE_IND 1137 | | F_RTR_RS | | 1138 o=================o | o-----------------o 1139 | |<-----------+ | | 1140 | | | | 1141 | | f_nerp_ind | | 1142 | |------------+ | | 1143 | | F_RTR_RS | | | 1144 | | | | | 1145 | |<-----------+ | | 1146 | IDLE LISTENER | f_eerp_ind | IDLE LISTENER | 1147 | (2) |<-----------------------------| (3) | 1148 | | F_RTR_RS | CD_RQ | 1149 | | | just sent | 1150 | | f_nerp_ind | | 1151 | |<-----------------------------| | 1152 | | F_RTR_RS | | 1153 | | | | 1154 | | f_start_file_ind | | 1155 | | and not P1 | | 1156 | |---------------------+ | | 1157 o=================o F_START_FILE_RS(-) | o-----------------o 1158 A A | A A | | | 1159 | | | | +-----------------------+ | | 1160 | | | | | | 1161 | | | | f_start_file_ind and not P1 | | 1162 | | | +--------------------------------------+ | 1163 | | | F_START_FILE_RS(-) | 1164 | | | | 1165 | | | f_start_file_ind f_start_file_ind | 1166 | | | and P1 and P1 | 1167 | | +----------------------------+ +------------------+ 1168 | | F_START_FILE_RS(+) | | F_START_FILE_RS(+) 1169 | | V V 1170 | | o---------------o 1171 | |f_close_file_ind and not P3 | | 1172 | +----------------------------| | 1173 | F_CLOSE_FILE_RS(+,N) | | 1174 | | DATA | 1175 | | TRANSFER | 1176 | f_close_file_ind and not P2 | |-------------+ 1177 +------------------------------| | | 1178 F_CLOSE_FILE_RS(-) | |<------------+ 1179 o---------------o F_DATA_IND 1180 o---------------o | 1181 | IDLE SPEAKER | f_close_file_ind and P3 | 1182 | see (1), Spkr |<--------------------------+ 1183 | State Diagram | F_CLOSE_FILE_RS(+,Y) 1184 o---------------o 1186 Predicates: 1187 P1: Decision to send F_START_FILE_RS(+) 1188 P2: Decision to send F_CLOSE_FILE_RS(+) 1189 P3: Decision to become Speaker 1191 4. Protocol Specification 1193 4.1 Overview 1195 The ODETTE-FTP protocol is divided into five operating phases. 1197 Start Session 1198 Start File 1199 Data Transfer 1200 End File 1201 End Session 1203 After the End File phase an ODETTE-FTP entity may enter a new Start 1204 File phase or terminate the session via the End Session phase. 1206 ODETTE-FTP peers communicate by sending and receiving messages in 1207 Exchange Buffers via the Network Service. Each Exchange Buffer 1208 contains one of the following commands. 1210 SSRM Start Session Ready Message 1211 SSID Start Session 1212 SECD Security Change Direction 1213 AUCH Authentication Challenge 1214 AURP Authentication Response 1215 SFID Start File 1216 SFPA Start File Positive Answer 1217 SFNA Start File Negative Answer 1218 DATA Data 1219 CDT Set Credit 1220 EFID End File 1221 EFPA End File Positive Answer 1222 EFNA End File Negative Answer 1223 ESID End Session 1224 CD Change Direction 1225 EERP End to End Response 1226 NERP Negative End Response 1227 RTR Ready To Receive 1229 The remainder of this section describes the protocol flows. Section 1230 five details the command formats. 1232 4.2 Start Session Phase 1234 The Start Session phase is entered immediately after the network 1235 connection has been established. 1237 4.2.1 Entity Definition 1239 The ODETTE-FTP entity that took the initiative to establish the 1240 network connection becomes the Initiator. Its peer becomes the 1241 Responder. 1243 4.2.2 Protocol Sequence 1245 The first message must be sent by the Responder. 1247 1. Initiator <-------------SSRM -- Responder Ready Message 1248 -- SSID ------------> Identification 1249 <------------ SSID -- Identification 1251 4.2.3 Secure Authentication 1253 Having exchanged SSIDs, the Initiator may optionally begin an 1254 authentication phase, in which each party proves its identity 1255 to the other. 1257 4.2.4 Protocol Sequence 1259 The first authentication message must be sent by the Initiator. 1261 1. Initiator -- SECD ------------> Responder Change Direction 1262 <------------ AUCH -- Challenge 1263 -- AURP ------------> Response 1264 <------------ SECD -- Change Direction 1265 -- AUCH ------------> Challenge 1266 <------------ AURP -- Response 1268 The Initiator sends a Security Change Direction (SECD) to which 1269 the Responder replies with an Authentication Challenge (AUCH). 1271 The Responder looks up the public certificate that is linked to 1272 the purported identity of the Initiator (located in the SSID). If 1273 the Responder is unable to locate a suitable certificate then 1274 authentication fails. The Responder uses the public key contained 1275 in the certificate to encrypt a random challenge, unique for each 1276 session, for the Initiator. This encrypted challenge is sent as 1277 a [CMS] envelope to the Initiator as part of the AUCH. 1279 The Initiator decrypts the challenge using their private key 1280 and sends the decrypted challenge back to the Responder in the 1281 Authentication Response (AURP). 1283 The Responder checks that the data received in the AURP matches 1284 the random challenge that was sent to the Initiator. 1286 If the data matches, then the Initiator has authenticated 1287 successfully and the Responder replies with a Security Change 1288 Direction (SECD) beginning the complementary process of verifying 1289 the Responder to the Initiator. If the data does not match then 1290 the Initiator fails authentication. 1292 4.3 Start File Phase 1294 4.3.1 Entity Definition 1296 The Initiator from the Start Session phase is designated the Speaker 1297 while the Responder becomes the Listener. The roles are reversed by 1298 the Speaker sending a Change Direction command to the Listener. 1300 4.3.2 Protocol Sequence 1302 1. Speaker -- SFID ------------> Listener Start File 1303 <------------ SFPA -- Answer YES 1305 2. Speaker -- SFID ------------> Listener Start File 1306 <------------ SFNA -- Answer NO 1307 Go To 1 1309 Note: The User Monitor should take steps to prevent a loop 1310 situation occurring. 1312 2. Speaker -- CD --------------> Listener Change Direction 1313 Listener <------------ EERP -- Speaker End to End Response 1314 -- RTR -------------> Ready to Receive 1315 <------------ NERP -- Negative End Response 1316 -- RTR -------------> Ready to Receive 1317 <------------ SFID -- Start File 1319 4.3.3 Restart Facilities 1321 The Start File command includes a count allowing the restart of an 1322 interrupted transmission to be negotiated. If restart facilities are 1323 not available the restart count must be set to zero. The sender will 1324 start with the lowest record count + 1. 1326 4.3.4 Broadcast Facilities 1328 The destination in a Start File command can be specified as follows. 1330 1. An explicitly defined destination. 1332 2. A group destination that allows an intermediate location to 1333 broadcast the Virtual File to multiple destinations. 1335 The Listener will send a negative answer to the Speaker when the 1336 destination is not known. 1338 4.3.5 Priority 1340 The prioritisation of files for transmission is left to the local 1341 implementation. To allow some flexibility, a change direction 1342 mechanism is available in the End File phase. 1344 4.3.6 End To End Response (EERP) 1346 The End to End Response (EERP) command notifies the originator of a 1347 Virtual File that the Virtual File has been successfully delivered 1348 to its final destination. This allows the originator to perform 1349 house keeping tasks such as deleting copies of the delivered data. 1351 If the originator of the Virtual File requested a signed EERP in 1352 the SFID, the EERP must be signed. Signing allows the originator 1353 of the file to prove that the EERP was generated by the final 1354 destination. If the final destination is unable to sign the EERP 1355 they may send back an unsigned EERP. It is an implementation issue 1356 to allow the acceptance of an unsigned EERP if a signed EERP 1357 is requested. 1359 A Response Command must be sent from the location performing the 1360 final processing or distribution of the data to the originator. The 1361 Response is mandatory and may be sent in the same or in any 1362 subsequent session. 1364 When an intermediate location broadcasts or distributes a Virtual 1365 File it must receive a Response command from all the locations to 1366 which it forwarded the data before sending its own Response. This 1367 ensures that the Response received by the Virtual File's originator 1368 accounts for all the destination locations. An intermediate location 1369 therefore needs to track the status of files it processes over time. 1371 The requesting of a signed EERP is incompatible with the use of 1372 broadcast facilities because an EERP can be signed by only one 1373 destination. If this scenario occurs, the intermediate 1374 broadcast location may continue and ignore the request for a 1375 signed EERP or send back a NERP. 1377 Example: Point to Point 1379 Location A sends file Ba to Location B which will send an EERP to 1380 location A after it successfully receives the file. 1382 o----------o o-----------o 1383 | Loc. A |----------- S1 ---------->| Loc. B | 1384 | | | | 1385 | [Ba] |<---------- R2 -----------| [Ba] | 1386 +----------o o-----------o 1388 Key: 1389 S - File Transfer R - Response EERP [Ba] - File for B from A 1391 Example: Data distribution 1393 Location A sends a Virtual File containing data for distribution to 1394 locations B and C via clearing centres E1 and E2. Clearing centre E1 1395 must wait for a response from E2 (for file Ba) and location C before 1396 it sends its response, R8, to location A. Clearing centre E2 can 1397 only send response R7 to E1 when location B acknowledges file Ba with 1398 response R6. 1400 o---------o o---------o o---------o o---------o 1401 | Loc. A |-- S1 ->| Loc. E1 |-- S2 ->| Loc. E2 |-- S5 ->| Loc. B | 1402 | | | | | | | | 1403 | [Ba,Ca] |<- R8 --| [Ba,Ca] |<- R7 --| [Ba] |<- R6 --| [Ba] | 1404 o---------o o---------o o---------o o---------o 1405 A | 1406 | | o---------o 1407 | +----- S3 ->| Loc. C | 1408 | | | 1409 +--------- R4 --| [Ca] | 1410 o---------o 1412 Example: Data collection 1414 Locations A and B send files Ca and Cb to clearing centre E1 which 1415 forwards both files to location C in a single Virtual File. When it 1416 receives response R4 from C, clearing centre E1 sends response R5 to 1417 location A and R6 to location B. 1419 o---------o o---------o o---------o 1420 | Loc. A |-- S1 ->| Loc. E1 |-- S3 ->| Loc. C | 1421 | | | | | | 1422 | [Ca] |<- R5 --| [Ca,Cb] |<- R4 --| [Ca,Cb] | 1423 o---------o o---------o o---------o 1424 A | 1425 o---------o | | 1426 | Loc. B |-- S2 -----+ | 1427 | | | 1428 | [Cb] |<- R6 ---------+ 1429 o---------o 1431 4.3.7 Negative End Response (NERP) 1433 In addition to the EERP, which allows control over successful 1434 transmission of a file, a Negative End Response signals that a file 1435 could not be delivered to the final destination or that the final 1436 destination could not process the received file. 1438 It may be created by an intermediate node that could not transmit the 1439 file any further because the next node refuses to accept the file. 1440 The cause of the refusal has to be non-temporary, otherwise the 1441 intermediate node has to try the transmission again. 1443 It may also be created by the final node that is unable to process 1444 the file because of non-recoverable syntax or semantic errors in the 1445 file, or because of the failure of any other processing performed on 1446 the file. 1448 The NERP will be sent back to the originator of the file. 1450 The parameters are equal to the ones of the EERP, but with additional 1451 information about the creator of the NERP and the abort reason. Where 1452 the NERP is created due to a failure to transmit, the abort reason is 1453 taken from the refusal reason that was sent by the node refusing the 1454 file. Because of the NERP it is possible for the intermediate node to 1455 stop trying to send the non-deliverable file and to delete the file. 1457 The NERP allows the originator of the file to react to the 1458 unsuccessful transmission or processing, depending on the reason code 1459 and the creator of the NERP. 1461 If the originator of the Virtual File requested a signed EERP in 1462 the SFID, the NERP must be signed. Signing allows the originator 1463 of the file to prove by whom the NERP was generated. If the 1464 location generating the NERP is unable to sign the NERP they may send 1465 back an unsigned NERP. It is an implementation issue to allow the 1466 acceptance of an unsigned EERP if a signed NERP is requested. 1468 4.3.8 Ready To Receive Command (RTR) 1470 In order to avoid congestion between two adjacent nodes caused by a 1471 continuous flow of EERPs and NERPs, a Ready To Receive (RTR) 1472 command is provided. The RTR acts as an EERP/NERP acknowledgement 1473 for flow control but has no end-to-end significance. 1475 Speaker -- EERP ------------> Listener End to End Response 1476 <------------- RTR -- Ready to Receive 1477 -- EERP ------------> End to End Response 1478 <------------- RTR -- Ready to Receive 1479 -- NERP ------------> Negative End Response 1480 <------------- RTR -- Ready to Receive 1481 -- SFID ------------> Start File 1482 or 1483 -- CD --------------> Exchange the turn 1485 After sending an EERP or NERP, the Speaker must wait for an RTR 1486 before sending any other commands. The only acceptable commands 1487 to follow are : 1489 EERP 1490 NERP 1491 SFID or CD (if there are no more EERPs or NERPs to be sent) 1493 4.4 Data Transfer Phase 1495 Virtual File data flows from the Speaker to the Listener during the 1496 Data Transfer phase which is entered after the Start File phase. 1498 4.4.1 Protocol Sequence 1500 To avoid congestion at the protocol level a flow control mechanism is 1501 provided via the Credit (CDT) command. 1503 A Credit limit is negotiated in the Start Session phase, this 1504 represents the number of Data Exchange Buffers that the Speaker may 1505 send before it is obliged to wait for a Credit command from the 1506 Listener. 1508 The available credit is initially set to the negotiated value by the 1509 Start File positive answer, which acts as an implicit Credit command. 1510 The Speaker decreases the available credit count by one for each data 1511 buffer sent to the Listener. 1513 When the available credit is exhausted, the Speaker must wait for a 1514 Credit command from the Listener otherwise a protocol error will 1515 occur and the session will be aborted. 1517 The Listener should endeavour to send the Credit command without 1518 delay to prevent the Speaker blocking. 1520 1. Speaker -- SFID ------------> Listener Start File 1521 <------------ SFPA -- Answer YES 1523 2. If the Credit Value is set to 2 1525 Speaker -- Data ------------> Listener Start File 1526 -- Data ------------> 1527 <------------- CDT -- Set Credit 1528 -- Data ------------> 1529 -- EFID ------------> End File 1531 4.5 End File Phase 1533 4.5.1 Protocol Sequence 1535 The Speaker notifies the Listener that it has finished sending a 1536 Virtual File by sending an End File (EFID) command. The Listener 1537 replies with a positive or negative End File command and has the 1538 option to request a Change Direction command from the Speaker. 1540 1. Speaker -- EFID ------------> Listener End File 1541 <------------ EFPA -- Answer YES 1543 2. Speaker -- EFID ------------> Listener End File 1544 <------------ EFPA -- Answer YES + CD 1545 -- CD --------------> Change Direction 1546 Listener <------------ EERP -- Speaker End to End Response 1547 -------------- RTR -> Ready to Receive 1548 Listener <------------ NERP -- Speaker Negative End Response 1549 -------------- RTR -> Ready to Receive 1550 Go to Start File Phase 1552 3. Speaker -- EFID ------------> Listener End File 1553 <------------ EFNA -- Answer NO 1555 4.6 End Session Phase 1557 4.6.1 Protocol Sequence 1559 The Speaker terminates the session by sending an End Session (ESID) 1560 command. The Speaker may only do this if the Listener has just 1561 relinquished its role as speaker. 1563 1. Speaker -- EFID ------------> Listener End File 1564 <------------ EFPA -- Answer YES 1565 -- CD --------------> Change Direction 1566 Listener <------------ ESID -- Speaker End Session 1568 4.7 Problem Handling 1570 Error detection and handling should be done as close as possible to 1571 the problem. This aids problem determination and correction. Each 1572 layer of the reference model is responsible for its own error 1573 handling. 1575 ODETTE-FTP can detect protocol errors by virtue of its state 1576 machine and uses activity timers to detect session hang 1577 conditions. These mechanisms are separate from the End to End 1578 controls. 1580 4.7.1 Protocol Errors 1582 If a protocol error occurs the session will be terminated and 1583 application activity aborted. Both locations enter the IDLE state. 1585 4.7.2 Timers 1587 To protect against application and network hang conditions ODETTE-FTP 1588 uses activity timers for all situations where a response is required. 1589 The timers and actions to be taken if they expire are described in 1590 section 8, the Protocol State Machine. 1592 4.7.3 Clearing Centres 1594 The use of clearing centres introduces the possibility of errors 1595 occurring as a result of data processing activities within the 1596 centre. Such errors are not directly related to ODETTE-FTP or the 1597 communication network and are therefore outside the scope of this 1598 specification. 1600 5. Commands and Formats 1602 ODETTE-FTP entities communicate via Exchange Buffers. The Command 1603 Exchange Buffers are described below. Virtual File data is carried 1604 in Data Exchange Buffers which are described in Section 6. 1606 5.1 Conventions 1608 5.1.1 Representation unit: 1610 The basic unit of information is an octet, containing eight bits. 1612 5.1.2 Values and Characters: 1614 The ISO 646 IRV 7-bit coded character set [ISO-646], according to 1615 Appendix B, is used to encode constants and strings within command 1616 exchange buffers except where [UTF-8] is explicitly indicated against 1617 a field. 1619 5.2 Commands 1621 A Command Exchange Buffer contains a single command starting at the 1622 beginning of the buffer. Commands and data are never mixed within an 1623 Exchange Buffer. Commands can not be compressed. Variable length 1624 parameters may be omitted entirely if not required and the associated 1625 length indicator field set to zero. 1627 Components: 1629 1. Command identifier: 1631 The first octet of an Exchange Buffer is the Command Identifier 1632 and defines the format of the buffer. 1634 2. Parameter(s): 1636 Command parameters are stored in fields within a Command Exchange 1637 Buffer. Where variable length fields are used, they are preceded 1638 with a header field indicating the length. All values are 1639 required except where explicitly indicated. 1641 5.3 Command Formats 1643 The ODETTE-FTP commands are described below using the following 1644 definitions. 1646 Position (Pos.) 1648 Field offset within the Command Exchange Buffer, relative to a 1649 zero origin. 1651 Field 1653 The name of the field. 1655 Description 1657 A description of the field. 1659 Format 1661 F - A field containing fixed values. All allowable values for 1662 the field are enumerated in the command definition. 1664 V - A field with variable values within a defined range. For 1665 example the SFIDLRECL field may contain any integer value 1666 between 00000 and 99999. 1668 X(n) - An alphanumeric field of length n octets. 1670 A String contains alphanumeric characters from the following 1671 set: 1673 The numerals: 0 to 9 1674 The upper case letters: A to Z 1675 The following special set: / - . & ( ) space. 1677 Space is not allowed as an embedded character. 1679 9(n) - A numeric field of length n octets. 1681 U(n) - A binary field of length n octets. 1683 Numbers encoded as binary are always unsigned and in 1684 network byte order. 1686 T(n) - An field of length n octets, encoded using [UTF-8]. 1688 String and alphanumeric fields are always left justified and right 1689 padded with spaces where needed. 1691 Numeric fields are always right justified and left padded with 1692 zeros where needed. 1694 Reserved fields should be padded with spaces. 1696 5.3.1 SSRM - Start Session Ready Message 1698 o-------------------------------------------------------------------o 1699 | SSRM Start Session Ready Message | 1700 | | 1701 | Start Session Phase Initiator <---- Responder | 1702 |-------------------------------------------------------------------| 1703 | Pos | Field | Description | Format | 1704 |-----+-----------+---------------------------------------+---------| 1705 | 0 | SSRMCMD | SSRM Command, 'I' | F X(1) | 1706 | 1 | SSRMMSG | Ready Message, 'ODETTE FTP READY ' | F X(17) | 1707 | 18 | SSRMCR | Carriage Return | F X(1) | 1708 o-------------------------------------------------------------------o 1710 SSRMCMD Command Code Character 1712 Value: 'I' SSRM Command identifier. 1714 SSRMMSG Ready Message String(17) 1716 Value: 'ODETTE FTP READY ' 1718 SSRMCR Carriage Return Character 1720 Value: Character with hex value '0D' or '8D'. 1722 5.3.2 SSID - Start Session 1724 o-------------------------------------------------------------------o 1725 | SSID Start Session | 1726 | | 1727 | Start Session Phase Initiator <---> Responder | 1728 |-------------------------------------------------------------------| 1729 | Pos | Field | Description | Format | 1730 |-----+-----------+---------------------------------------+---------| 1731 | 0 | SSIDCMD | SSID Command 'X' | F X(1) | 1732 | 1 | SSIDLEV | Protocol Release Level | F 9(1) | 1733 | 2 | SSIDCODE | Initiator's Identification Code | V X(25) | 1734 | 27 | SSIDPSWD | Initiator's Password | V X(8) | 1735 | 35 | SSIDSDEB | Data Exchange Buffer Size | V 9(5) | 1736 | 40 | SSIDSR | Send / Receive Capabilities (S/R/B) | F X(1) | 1737 | 41 | SSIDCMPR | Buffer Compression Indicator (Y/N) | F X(1) | 1738 | 42 | SSIDREST | Restart Indicator (Y/N) | F X(1) | 1739 | 43 | SSIDSPEC | Special Logic Indicator (Y/N) | F X(1) | 1740 | 44 | SSIDCRED | Credit | V 9(3) | 1741 | 47 | SSIDAUTH | Secure Authentication (Y/N) | F X(1) | 1742 | 48 | SSIDRSV1 | Reserved | F X(4) | 1743 | 52 | SSIDUSER | User Data | V X(8) | 1744 | 60 | SSIDCR | Carriage Return | F X(1) | 1745 o-------------------------------------------------------------------o 1747 SSIDCMD Command Code Character 1749 Value: 'X' SSID Command identifier. 1751 SSIDLEV Protocol Release Level Numeric(1) 1753 Used to specify the level of the ODETTE-FTP protocol 1755 Value: '1' for Revision 1.2 1756 '2' for Revision 1.3 1757 '4' for Revision 1.4 1758 '5' for Revision 2.0 1760 Future release levels will have higher numbers. The 1761 protocol release level is negotiable, with the lowest level 1762 being selected. 1764 Note: ODETTE File Transfer Protocol 1.3 (RFC2204) specifies 1765 '1' for the release level, despite adhering to 1766 revision 1.3. 1768 SSIDCODE Initiator's Identification Code String(25) 1770 Format: See Identification Code (Section 5.4) 1772 Uniquely identifies the Initiator (sender) participating 1773 in the ODETTE-FTP session. 1775 It is an application implementation issue to link the 1776 expected [X.509] certificate to the SSIDCODE provided. 1778 SSIDPSWD Password String(8) 1780 Key to authenticate the sender. Assigned by bilateral 1781 agreement. 1783 SSIDSDEB Data Exchange Buffer Size Numeric(5) 1785 Minimum: 128 1786 Maximum: 99999 1788 The length, in octets, of the largest Data Exchange Buffer 1789 that can be accepted by the location. The length includes 1790 the command octet but does not include the Stream 1791 Transmission Header. 1793 After negotiation the smallest size will be selected. 1795 SSIDSR Send / Receive Capabilities Character 1797 Value: 'S' Location can only send files. 1798 'R' Location can only receive files. 1799 'B' Location can both send and receive files. 1801 Sending and receiving will be serialised during the 1802 session, so parallel transmissions will not take place in 1803 the same session. 1805 An error occurs if adjacent locations both specify the send 1806 or receive capability. 1808 SSIDCMPR Buffer Compression Indication Character 1810 Value: 'Y' The location can handle OFTP data buffer compression 1811 'N' The location can not handle OFTP buffer compression 1813 Compression is only used if supported by both locations. 1815 The compression mechanism referred to here applies to each 1816 individual OFTP data buffer. This is different from 1817 the file compression mechanism in OFTP which involves the 1818 compression of whole files. 1820 SSIDREST Restart Indication Character 1822 Value: 'Y' The location can handle the restart of a partially 1823 transmitted file. 1824 'N' The location can not restart a file. 1826 SSIDSPEC Special Logic Indication Character 1828 Value: 'Y' Location can handle Special Logic 1829 'N' Location can not handle Special Logic 1831 Special Logic is only used if supported by both locations. 1833 The Special Logic extensions are only useful to access an 1834 X.25 network via an asynchronous entry and are not 1835 supported for TCP/IP connections. 1837 SSIDCRED Credit Numeric(3) 1839 Maximum: 999 1841 The number of consecutive Data Exchange Buffers sent by the 1842 Speaker before it must wait for a Credit (CDT) command from 1843 the Listener. 1845 The credit value is only applied to Data flow in the Data 1846 Transfer phase. 1848 The Speaker's available credit is initialised to SSIDCRED 1849 when it receives a Start File Positive Answer (SFPA) 1850 command from the Listener. It is zeroed by the End File 1851 (EFID) command. 1853 After negotiation, the smallest size must be selected in 1854 the answer of the Responder, otherwise a protocol error 1855 will abort the session. 1857 Negotiation of the "credit-window-size" parameter. 1859 Window Size m -- SSID ------------> 1860 <------------ SSID -- Window Size n 1861 (n less or equal m) 1862 Note: negotiated value will be "n". 1864 SSIDAUTH Secure Authentication Character 1866 Value: 'Y' The location requires secure authentication. 1867 'N' The location does not require secure authentication. 1869 Secure authentication is only used if agreed by both 1870 locations. 1872 If the answer of the Responder does not match with the 1873 authentication requirements of the Initiator, then the 1874 Initiator must abort the session. 1876 No negotiation of authentication is allowed. 1878 authentication p -- SSID ------------> 1879 <------------ SSID -- authentication q 1881 p == q -> continue. 1882 p != q -> abort. 1884 SSIDRSV1 Reserved String(4) 1886 This field is reserved for future use. 1888 SSIDUSER User Data String(8) 1890 May be used by the ODETTE-FTP in any way. If unused it 1891 should be initialised to spaces. It is expected that a 1892 bilateral agreement exists as to the meaning of the data. 1894 SSIDCR Carriage Return Character 1896 Value: Character with hex value '0D' or '8D'. 1898 5.3.3 SFID - Start File 1900 o-------------------------------------------------------------------o 1901 | SFID Start File | 1902 | | 1903 | Start File Phase Speaker ----> Listener | 1904 |-------------------------------------------------------------------| 1905 | Pos | Field | Description | Format | 1906 |-----+-----------+---------------------------------------+---------| 1907 | 0 | SFIDCMD | SFID Command, 'H' | F X(1) | 1908 | 1 | SFIDDSN | Virtual File Dataset Name | V X(26) | 1909 | 27 | SFIDRSV1 | Reserved | F X(3) | 1910 | 30 | SFIDDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) | 1911 | 38 | SFIDTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) | 1912 | 48 | SFIDUSER | User Data | V X(8) | 1913 | 56 | SFIDDEST | Destination | V X(25) | 1914 | 81 | SFIDORIG | Originator | V X(25) | 1915 | 106 | SFIDFMT | File Format (F/V/U/T) | F X(1) | 1916 | 107 | SFIDLRECL | Maximum Record Size | V 9(5) | 1917 | 112 | SFIDFSIZ | File Size, 1K blocks | V 9(13) | 1918 | 125 | SFIDOSIZ | Original File Size, 1K blocks | V 9(13) | 1919 | 138 | SFIDREST | Restart Position | V 9(17) | 1920 | 155 | SFIDSEC | Security Level | F 9(2) | 1921 | 157 | SFIDCIPH | Cipher suite selection | F 9(2) | 1922 | 159 | SFIDCOMP | File compression algorithm | F 9(1) | 1923 | 160 | SFIDENV | File enveloping format | F 9(1) | 1924 | 161 | SFIDSIGN | Signed EERP request | F X(1) | 1925 | 162 | SFIDDESCL | Virtual File Description length | V 9(3) | 1926 | 165 | SFIDDESC | Virtual File Description | V T(n) | 1927 o-------------------------------------------------------------------o 1929 SFIDCMD Command Code Character 1931 Value: 'H' SFID Command identifier. 1933 SFIDDSN Virtual File Dataset Name String(26) 1935 Dataset name of the Virtual File being transferred, 1936 assigned by bilateral agreement. 1938 No general structure is defined for this attribute. 1940 See Virtual Files - Identification (Section 1.5.2) 1942 SFIDRSV1 Reserved String(3) 1944 This field is reserved for future use. 1946 SFIDDATE Virtual File Date stamp Numeric(8) 1948 Format: 'CCYYMMDD' 8 decimal digits representing the century, 1949 year, month and day. 1951 Date stamp assigned by the Virtual File's Originator 1952 indicating when the file was made available for 1953 transmission. 1955 See Virtual Files - Identification (Section 1.5.2) 1957 SFIDTIME Virtual File Time stamp Numeric(10) 1959 Format: 'HHMMSScccc' 10 decimal digits representing hours, 1960 minutes, seconds and a counter (0001-9999), which gives 1961 higher resolution 1963 Time stamp assigned by the Virtual File's Originator 1964 indicating when the file was made available for 1965 transmission. 1967 See Virtual Files - Identification (Section 1.5.2) 1969 SFIDUSER User Data String(8) 1971 May be used by the ODETTE-FTP in any way. If unused it 1972 should be initialised to spaces. It is expected that a 1973 bilateral agreement exists as to the meaning of the data. 1975 SFIDDEST Destination String(25) 1977 Format: See Identification Code (Section 5.4) 1979 The Final Recipient of the Virtual File. 1981 This is the location that will look into the Virtual File 1982 content and perform mapping functions. It is also the 1983 location that creates the End to End Response (EERP) 1984 command for the received file. 1986 SFIDORIG Originator String(25) 1988 Format: See Identification Code (Section 5.4) 1990 Originator of the Virtual File. 1991 It is the location that created (mapped) the data for 1992 transmission. 1994 SFIDFMT File Format Character 1996 Value: 'F' Fixed format binary file 1997 'V' Variable format binary file 1998 'U' Unstructured binary file 1999 'T' Text 2001 Virtual File format. Used to calculate the restart 2002 position. (Section 1.5.3) 2004 Once a file has been signed, compressed and/or encrypted, 2005 in file format terms it becomes unstructured, format U. 2006 The record boundaries are no longer discernable until the 2007 file is decrypted, decompressed and/or verified. SFID File 2008 Format Field in this scenario indicates the format of the 2009 original file and the transmitted file must be treated as 2010 U format. 2012 SFIDLRECL Maximum Record Size Numeric(5) 2014 Maximum: 99999 2016 Length in octets of the longest logical record which may be 2017 transferred to a location. Only user data is included. 2019 If SFIDFMT is 'T' or 'U' then this attribute must be set to 2020 '00000'. 2022 If SFIDFMT is 'V' and the file is compressed, encrypted or 2023 signed then the maximum value of SFIDRECL is '65536'. 2025 SFIDFSIZ Transmitted File Size Numeric(13) 2027 Maximum: 9999999999999 2029 Space in 1K (1024 octet) blocks required at the Originator 2030 location to store the actual Virtual File that is to be 2031 transmitted. 2033 e.g. if a file is compressed before sending, then this is 2034 the space required to store the compressed file. 2036 This parameter is intended to provide only a good estimate 2037 of the Virtual File size. 2039 13 digits allows for a maximum file size of approximately 2040 9.3PB (petabytes) to be transmitted. 2042 SFIDOSIZ Original File Size Numeric(13) 2044 Maximum: 9999999999999 2046 Space in 1K (1024 octet) blocks required at the Originator 2047 location to store the original before it was signed, 2048 compressed and/or encrypted. 2050 If no security or compression services have been used, 2051 SFIDOSIZ should contain the same value as SFIDFSIZ. 2053 If the original file size is not known, the value zero 2054 should be used. 2056 This parameter is intended to provide only a good estimate 2057 of the original file size. 2059 The sequence of events in file exchange are: 2061 (a) raw data file ready to be sent 2062 SFIDOSIZ = Original File Size 2064 (b) signing/compression/encryption 2066 (c) transmission 2067 SFIDFSIZ = Transmitted File Size 2069 (d) decryption/decompression/verification 2071 (e) received raw data file for in-house applications 2072 SFIDOSIZ = Original File Size 2074 The Transmitted File Size at (c) indicates to the receiver 2075 how much storage space is needed to receive the file. 2077 The Original File Size at (e) indicates to the in-house 2078 application how much storage space is needed to process the 2079 file. 2081 SFIDREST Restart Position Numeric(17) 2083 Maximum: 99999999999999999 2085 Virtual File restart position. 2087 The count represents the: 2088 - Record Number if SSIDFMT is 'F' or 'V'. 2089 - File offset in 1K (1024 octet) blocks if SFIDFMT is 2090 'U' or 'T'. 2092 The count will express the transmitted user data (i.e. 2093 before ODETTE-FTP buffer compression, header not included). 2095 After negotiation between adjacent locations, 2096 retransmission will start at the lowest value. 2098 Once a file has been signed, compressed and/or encrypted, 2099 in file format terms, it has become unstructured, like 2100 format U. The file should be treated as format U for the 2101 purposes of restart, regardless of the actual value in 2102 SFIDFMT. 2104 SFIDSEC Security Level Numeric(2) 2106 Value: '00' No security services 2107 '01' Encrypted 2108 '02' Signed 2109 '03' Encrypted and signed 2111 Indicates whether the file has been signed and/or encrypted 2112 before transmission. (See Section 6.2) 2114 SFIDCIPH Cipher suite selection Numeric(2) 2116 Value: '00' No security services 2117 '01' See Section 10.2 2119 Indicates the cipher suite used to sign and/or encrypt 2120 the file and also to indicate the cipher suite that should 2121 be used when a signed EERP or NERP is requested. 2123 SFIDCOMP File compression algorithm Numeric(1) 2125 Value: '0' No compression 2126 '1' Compressed with [ZLIB] algorithm 2128 Indicates the algorithm used to compress the file. 2129 (See Section 6.4) 2131 SFIDENV File enveloping format Numeric(1) 2133 Value: '0' No envelope 2134 '1' File is enveloped using [CMS] 2136 Indicates the enveloping format used in the file. 2138 If the file is encrypted/signed/compressed or is an 2139 enveloped file for the exchange and revocation of 2140 certificates, this field must be set accordingly. 2142 SFIDSIGN Signed EERP request Character 2144 Value: 'Y' The EERP returned in acknowledgement of the file 2145 must be signed 2146 'N' The EERP must not be signed 2148 Requests whether the EERP returned for the file must 2149 be signed. 2151 SFIDDESCL Virtual File Description length Numeric(3) 2153 Length in octets of the field SFIDDESC. 2155 A value of 0 indicates that no description is present. 2157 SFIDDESC Virtual File Description [UTF-8](n) 2159 May be used by the ODETTE-FTP in any way. If not used, 2160 SFIDDESCL should be set to zero. 2162 No general structure is defined for this attribute but it 2163 is expected that a bilateral agreement exists as to the 2164 meaning of the data. 2166 It is encoded using [UTF-8] to support a range of national 2167 languages. 2169 Maximum length of the encoded value is 999 octets. 2171 5.3.4 SFPA - Start File Positive Answer 2173 o-------------------------------------------------------------------o 2174 | SFPA Start File Positive Answer | 2175 | | 2176 | Start File Phase Speaker <---- Listener | 2177 |-------------------------------------------------------------------| 2178 | Pos | Field | Description | Format | 2179 |-----+-----------+---------------------------------------+---------| 2180 | 0 | SFPACMD | SFPA Command, '2' | F X(1) | 2181 | 1 | SFPAACNT | Answer Count | V 9(17) | 2182 o-------------------------------------------------------------------o 2184 SFPACMD Command Code Character 2186 Value: '2' SFPA Command identifier. 2188 SFPAACNT Answer Count Numeric(17) 2190 The Listener must enter a count lower or equal to the 2191 restart count specified by the Speaker in the Start File 2192 (SFID) command. The count expresses the received user 2193 data. If restart facilities are not available, a count of 2194 zero must be specified. 2196 5.3.5 SFNA - Start File Negative Answer 2198 o-------------------------------------------------------------------o 2199 | SFNA Start File Negative Answer | 2200 | | 2201 | Start File Phase Speaker <---- Listener | 2202 |-------------------------------------------------------------------| 2203 | Pos | Field | Description | Format | 2204 |-----+-----------+---------------------------------------+---------| 2205 | 0 | SFNACMD | SFNA Command, '3' | F X(1) | 2206 | 1 | SFNAREAS | Answer Reason | F 9(2) | 2207 | 3 | SFNARRTR | Retry Indicator, (Y/N) | F X(1) | 2208 | 4 | SFNAREASL | Answer Reason Text Length | V 9(3) | 2209 | 7 | SFNAREAST | Answer Reason Text | V T(n) | 2210 o-------------------------------------------------------------------o 2212 SFNACMD Command Code Character 2214 Value: '3' SFNA Command identifier. 2216 SFNAREAS Answer Reason Numeric(2) 2218 Value: '01' Invalid filename. 2219 '02' Invalid destination. 2220 '03' Invalid origin. 2221 '04' Storage record format not supported. 2222 '05' Maximum record length not supported. 2223 '06' File size is too big. 2224 '10' Invalid record count. 2225 '11' Invalid byte count. 2226 '12' Access method failure. 2227 '13' Duplicate file. 2228 '14' File direction refused. 2229 '15' Cipher suite not supported. 2230 '16' Encrypted file not allowed. 2231 '17' Unencrypted file not allowed. 2232 '18' Compression not allowed. 2233 '19' Signed file not allowed. 2234 '20' Unsigned file not allowed. 2235 '99' Unspecified reason. 2237 Reason why transmission can not proceed. 2239 SFNARRTR Retry Indicator Character 2241 Value: 'N' Transmission should not be retried. 2242 'Y' The transmission may be retried later. 2244 This parameter is used to advise the Speaker if it should 2245 retry at a later time due to a temporary condition at the 2246 Listener site, such as a lack of storage space. It 2247 should be used in conjunction with the Answer Reason code 2248 (SFNAREAS). 2250 An invalid file name error code may be the consequence of a 2251 problem in the mapping of the Virtual File on to a real 2252 file. Such problems cannot always be resolved immediately. 2253 It is therefore recommended that when a SFNA with Retry = Y 2254 is received the User Monitor attempts to retransmit the 2255 relevant file in a subsequent session. 2257 SFNAREASL Answer Reason Text Length Numeric(3) 2259 Length in octets of the field SFNAREAST. 2261 0 indicates that no SFNAREAST field follows. 2263 SFNAREAST Answer Reason Text [UTF-8](n) 2265 Reason why transmission can not proceed in plain text. 2267 It is encoded using [UTF-8]. 2269 Maximum length of the encoded reason is 999 octets. 2271 No general structure is defined for this attribute. 2273 5.3.6 DATA - Data Exchange Buffer 2275 o-------------------------------------------------------------------o 2276 | DATA Data Exchange Buffer | 2277 | | 2278 | Data Transfer Phase Speaker ----> Listener | 2279 |-------------------------------------------------------------------| 2280 | Pos | Field | Description | Format | 2281 |-----+-----------+---------------------------------------+---------| 2282 | 0 | DATACMD | DATA Command, 'D' | F X(1) | 2283 | 1 | DATABUF | Data Exchange Buffer payload | V U(n) | 2284 o-------------------------------------------------------------------o 2286 DATACMD Command Code Character 2288 Value: 'D' DATA Command identifier. 2290 DATABUF Data Exchange Buffer payload Binary(n) 2292 Variable length buffer containing the data payload. The 2293 Data Exchange Buffer is described in Section 6. 2295 5.3.7 CDT - Set Credit 2297 o-------------------------------------------------------------------o 2298 | CDT Set Credit | 2299 | | 2300 | Data Transfer Phase Speaker <---- Listener | 2301 |-------------------------------------------------------------------| 2302 | Pos | Field | Description | Format | 2303 |-----+-----------+---------------------------------------+---------| 2304 | 0 | CDTCMD | CDT Command, 'C' | F X(1) | 2305 | 1 | CDTRSV1 | Reserved | F X(2) | 2306 o-------------------------------------------------------------------o 2308 CDTCMD Command Code Character 2310 Value: 'C' CDT Command identifier. 2312 CDTRSV1 Reserved String(2) 2314 This field is reserved for future use. 2316 5.3.8 EFID - End File 2318 o-------------------------------------------------------------------o 2319 | EFID End File | 2320 | | 2321 | End File Phase Speaker ----> Listener | 2322 |-------------------------------------------------------------------| 2323 | Pos | Field | Description | Format | 2324 |-----+-----------+---------------------------------------+---------| 2325 | 0 | EFIDCMD | EFID Command, 'T' | F X(1) | 2326 | 1 | EFIDRCNT | Record Count | V 9(17) | 2327 | 18 | EFIDUCNT | Unit Count | V 9(17) | 2328 o-------------------------------------------------------------------o 2330 EFIDCMD Command Code Character 2332 Value: 'T' EFID Command identifier. 2334 EFIDRCNT Record Count Numeric(17) 2336 Maximum: 99999999999999999 2338 For SSIDFMT 'F' or 'V' the exact record count. 2339 For SSIDFMT 'U' or 'T' zeros. 2341 The count will express the real size of the file (before 2342 buffer compression, header not included). The total count 2343 is always used, even during restart processing. 2345 EFIDUCNT Unit Count Numeric(17) 2347 Maximum: 99999999999999999 2349 Exact number of units (octets) transmitted. 2351 The count will express the real size of the file. The 2352 total count is always used, even during restart processing. 2354 5.3.9 EFPA - End File Positive Answer 2356 o-------------------------------------------------------------------o 2357 | EFPA End File Positive Answer | 2358 | | 2359 | End File Phase Speaker <---- Listener | 2360 |-------------------------------------------------------------------| 2361 | Pos | Field | Description | Format | 2362 |-----+-----------+---------------------------------------+---------| 2363 | 0 | EFPACMD | EFPA Command, '4' | F X(1) | 2364 | 1 | EFPACD | Change Direction Indicator, (Y/N) | F X(1) | 2365 o-------------------------------------------------------------------o 2367 EFPACMD Command Code Character 2369 Value: '4' EFPA Command identifier. 2371 EFPACD Change Direction Indicator Character 2373 Value: 'N' Change direction not requested. 2374 'Y' Change direction requested. 2376 This parameter allows the Listener to request a Change 2377 Direction (CD) command from the Speaker. 2379 5.3.10 EFNA - End File Negative Answer 2381 o-------------------------------------------------------------------o 2382 | EFNA End File Negative Answer | 2383 | | 2384 | End File Phase Speaker <---- Listener | 2385 |-------------------------------------------------------------------| 2386 | Pos | Field | Description | Format | 2387 |-----+-----------+---------------------------------------+---------| 2388 | 0 | EFNACMD | EFNA Command, '5' | F X(1) | 2389 | 1 | EFNAREAS | Answer Reason | F 9(2) | 2390 | 3 | EFNAREASL | Answer Reason Text Length | V 9(3) | 2391 | 6 | EFNAREAST | Answer Reason Text | V T(n) | 2392 o-------------------------------------------------------------------o 2394 EFNACMD Command Code Character 2396 Value: '5' EFNA Command identifier. 2398 EFNAREAS Answer Reason Numeric(2) 2400 Value: '01' Invalid filename. 2401 '02' Invalid destination. 2402 '03' Invalid origin. 2403 '04' Storage record format not supported. 2404 '05' Maximum record length not supported. 2405 '06' File size is too big. 2406 '10' Invalid record count. 2407 '11' Invalid byte count. 2408 '12' Access method failure. 2409 '13' Duplicate file. 2410 '14' File direction refused. 2411 '15' Cipher suite not supported. 2412 '16' Encrypted file not allowed. 2413 '17' Unencrypted file not allowed. 2414 '18' Compression not allowed. 2415 '19' Signed file not allowed. 2416 '20' Unsigned file not allowed. 2417 '21' Invalid file signature. 2418 '22' File decryption failure. 2419 '23' File decompression failure. 2420 '99' Unspecified reason. 2422 Reason why transmission failed. 2424 EFNAREASL Answer Reason Text Length Numeric(3) 2426 Length in octets of the field EFNAREAST. 2428 0 indicates that no EFNAREAST field follows. 2430 EFNAREAST Answer Reason Text [UTF-8](n) 2432 Reason why transmission failed in plain text. 2434 It is encoded using [UTF-8]. 2436 Maximum length of the encoded reason is 999 octets. 2438 No general structure is defined for this attribute. 2440 5.3.11 ESID - End Session 2442 o-------------------------------------------------------------------o 2443 | ESID End Session | 2444 | | 2445 | End Session Phase Speaker ----> Listener | 2446 |-------------------------------------------------------------------| 2447 | Pos | Field | Description | Format | 2448 |-----+-----------+---------------------------------------+---------| 2449 | 0 | ESIDCMD | ESID Command, 'F' | F X(1) | 2450 | 1 | ESIDREAS | Reason Code | F 9(2) | 2451 | 3 | ESIDREASL | Reason Text Length | V 9(3) | 2452 | 6 | ESIDREAST | Reason Text | V T(n) | 2453 | | ESIDCR | Carriage Return | F X(1) | 2454 o-------------------------------------------------------------------o 2456 ESIDCMD Command Code Character 2458 Value: 'F' ESID Command identifier. 2460 ESIDREAS Reason Code Numeric(2) 2462 Value '00' Normal session termination 2464 '01' Command not recognised 2466 An Exchange Buffer contains an invalid command code 2467 (1st octet of the buffer). 2469 '02' Protocol violation 2471 An Exchange Buffer contains an invalid command for 2472 the current state of the receiver. 2474 '03' User code not known 2476 A Start Session (SSID) command contains an unknown or 2477 invalid Identification Code. 2479 '04' Invalid password 2481 A Start Session (SSID) command contained an invalid 2482 password. 2484 '05' Local site emergency close down 2486 The local site has entered an emergency close down 2487 mode. Communications are being forcibly terminated. 2489 '06' Command contained invalid data 2491 A field within a Command Exchange buffer contains 2492 invalid data. 2494 '07' Exchange Buffer size error 2496 The length of the Exchange Buffer as determined by 2497 the Stream Transmission Header differs from the 2498 length implied by the Command Code. 2500 '08' Resources not available 2502 The request for connection has been denied due to a 2503 resource shortage. The connection attempt should be 2504 retried later. 2506 '09' Time out 2508 '10' Mode or capabilities incompatible 2510 '11' Invalid challenge response 2512 '12' Secure authentication requirements incompatible 2514 '99' Unspecified Abort code 2516 An error was detected for which no specific code is 2517 defined. 2519 ESIDREASL Reason Text Length Numeric(3) 2521 Length in octets of the field ESIDREAST. 2523 0 indicates that no ESIDREAST field is present. 2525 ESIDREAST Reason Text [UTF-8](n) 2527 Reason why session ended in plain text. 2529 It is encoded using [UTF-8]. 2531 Maximum length of the encoded reason is 999 octets. 2533 No general structure is defined for this attribute. 2535 ESIDCR Carriage Return Character 2537 Value: Character with hex value '0D' or '8D'. 2539 5.3.12 CD - Change Direction 2541 o-------------------------------------------------------------------o 2542 | CD Change Direction | 2543 | | 2544 | Start File Phase Speaker ----> Listener | 2545 | End File Phase Speaker ----> Listener | 2546 | End Session Phase Initiator <---> Responder | 2547 |-------------------------------------------------------------------| 2548 | Pos | Field | Description | Format | 2549 |-----+-----------+---------------------------------------+---------| 2550 | 0 | CDCMD | CD Command, 'R' | F X(1) | 2551 o-------------------------------------------------------------------o 2553 CDCMD Command Code Character 2555 Value: 'R' CD Command identifier. 2557 5.3.13 EERP - End to End Response 2559 o-------------------------------------------------------------------o 2560 | EERP End to End Response | 2561 | | 2562 | Start File Phase Speaker ----> Listener | 2563 | End File Phase Speaker ----> Listener | 2564 |-------------------------------------------------------------------| 2565 | Pos | Field | Description | Format | 2566 |-----+-----------+---------------------------------------+---------| 2567 | 0 | EERPCMD | EERP Command, 'E' | F X(1) | 2568 | 1 | EERPDSN | Virtual File Dataset Name | V X(26) | 2569 | 27 | EERPRSV1 | Reserved | F X(3) | 2570 | 30 | EERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) | 2571 | 38 | EERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) | 2572 | 48 | EERPUSER | User Data | V X(8) | 2573 | 56 | EERPDEST | Destination | V X(25) | 2574 | 81 | EERPORIG | Originator | V X(25) | 2575 | 106 | EERPHSHL | Virtual File Hash length | V U(2) | 2576 | 108 | EERPHSH | Virtual File Hash | V U(n) | 2577 | | EERPSIGL | EERP signature length | V U(2) | 2578 | | EERPSIG | EERP signature | V U(n) | 2579 o-------------------------------------------------------------------o 2581 EERPCMD Command Code Character 2583 Value: 'E' EERP Command identifier. 2585 EERPDSN Virtual File Dataset Name String(26) 2587 Dataset name of the Virtual File being transferred, 2588 assigned by bilateral agreement. 2590 No general structure is defined for this attribute. 2592 See Virtual Files - Identification (Section 1.5.2) 2594 EERPRSV1 Reserved String(3) 2596 This field is reserved for future use. 2598 EERPDATE Virtual File Date stamp Numeric(8) 2600 Format: 'CCYYMMDD' 8 decimal digits representing the century, 2601 year, month and day respectively. 2603 Date stamp assigned by the Virtual File's Originator 2604 indicating when the file was made available for 2605 transmission. 2607 See Virtual Files - Identification (Section 1.5.2) 2609 EERPTIME Virtual File Time stamp Numeric(10) 2611 Format: 'HHMMSScccc' 10 decimal digits representing hours, 2612 minutes, seconds and a counter (0001-9999), which gives 2613 higher resolution 2615 Time stamp assigned by the Virtual File's Originator 2616 indicating when the file was made available for 2617 transmission. 2619 See Virtual Files - Identification (Section 1.5.2) 2621 EERPUSER User Data String(8) 2623 May be used by the ODETTE-FTP in any way. If unused it 2624 should be initialised to spaces. It is expected that a 2625 bilateral agreement exists as to the meaning of the data. 2627 EERPDEST Destination String(25) 2629 Format: See Identification Code (Section 5.4) 2631 Originator of the Virtual File. 2633 This is the location that created the data for 2634 transmission. 2636 EERPORIG Originator String(25) 2638 Format: See Identification Code (Section 5.4) 2640 Final Recipient of the Virtual File. 2642 This is the location that will look into the Virtual File 2643 content and process it accordingly. It is also the 2644 location that creates the EERP for the received file. 2646 EERPHSHL Virtual File hash length Binary(2) 2648 Length in octets of the field EERPHSH. 2650 A binary value of 0 indicates that no hash is present. 2651 This is always the case if the EERP is not signed. 2653 EERPHSH Virtual File hash Binary(n) 2655 Hash of the transmitted Virtual File. 2656 i.e. not the hash of the original file. 2658 The algorithm used is determined by the bilaterally agreed 2659 cipher suite specified in the SFIDCIPH. 2661 It is an application implementation issue to validate the 2662 EERPHSH to ensure that the EERP is acknowledging the exact 2663 same file as was originally transmitted. 2665 EERPSIGL EERP Signature length Binary(2) 2667 0 indicates that this EERP has not been signed. 2669 Any other value indicates the length of EERPSIG in octets 2670 and indicates that this EERP has been signed. 2672 EERPSIG EERP Signature Binary(n) 2674 Contains the [CMS] enveloped signature of the EERP. 2676 Signature = Sign{EERPDSN 2677 EERPDATE 2678 EERPTIME 2679 EERPDEST 2680 EERPORIG 2681 EERPHSH} 2683 Each field is taken in its entirety, including any 2684 padding. The envelope must contain the original data, 2685 not just the signature. 2687 The [CMS] content type used is SignedData. 2689 The encapsulated content type used is id-data. 2691 It is an application issue to validate the signature with 2692 the contents of the EERP. 2694 5.3.14 NERP - Negative End Response 2696 o-------------------------------------------------------------------o 2697 | NERP Negative End Response | 2698 | | 2699 | Start File Phase Speaker ----> Listener | 2700 | End File Phase Speaker ----> Listener | 2701 |-------------------------------------------------------------------| 2702 | Pos | Field | Description | Format | 2703 |-----+-----------+---------------------------------------+---------| 2704 | 0 | NERPCMD | NERP Command, 'N' | F X(1) | 2705 | 1 | NERPDSN | Virtual File Dataset Name | V X(26) | 2706 | 27 | NERPRSV1 | Reserved | F X(6) | 2707 | 33 | NERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) | 2708 | 41 | NERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) | 2709 | 51 | NERPDEST | Destination | V X(25) | 2710 | 76 | NERPORIG | Originator | V X(25) | 2711 | 101 | NERPCREA | Creator of NERP | V X(25) | 2712 | 126 | NERPREAS | Reason code | F 9(2) | 2713 | 128 | NERPREASL | Reason text length | V 9(3) | 2714 | 131 | NERPREAST | Reason text | V T(n) | 2715 | | NERPHSHL | Virtual File hash length | V U(2) | 2716 | | NERPHSH | Virtual File hash | V U(n) | 2717 | | NERPSIGL | NERP signature length | V U(2) | 2718 | | NERPSIG | NERP signature | V U(n) | 2719 o-------------------------------------------------------------------o 2721 NERPCMD Command Code Character 2723 Value: 'N' NERP Command identifier. 2725 NERPDSN Virtual File Dataset Name String(26) 2727 Dataset name of the Virtual File being transferred, 2728 assigned by bilateral agreement. 2730 No general structure is defined for this attribute. 2732 See Virtual Files - Identification (Section 1.5.2) 2734 NERPRSV1 Reserved String(6) 2736 This field is reserved for future use. 2738 NERPDATE Virtual File Date stamp Numeric(8) 2740 Format: 'CCYYMMDD' 8 decimal digits representing the century, 2741 year, month and day respectively. 2743 Date stamp assigned by the Virtual File's Originator 2744 indicating when the file was made available for 2745 transmission. 2747 See Virtual Files - Identification (Section 1.5.2) 2749 NERPTIME Virtual File Time stamp Numeric(10) 2751 Format: 'HHMMSScccc' 10 decimal digits representing hours, 2752 minutes, seconds and a counter (0001-9999), which gives 2753 higher resolution 2755 Time stamp assigned by the Virtual File's Originator 2756 indicating when the file was made available for 2757 transmission. 2759 See Virtual Files - Identification (Section 1.5.2) 2761 NERPDEST Destination String(25) 2763 Format: See Identification Code (Section 5.4) 2765 Originator of the Virtual File. 2767 This is the location that created the data for 2768 transmission. 2770 NERPORIG Originator String(25) 2772 Format: See Identification Code (Section 5.4) 2774 The Final Recipient of the Virtual File. 2776 This is the location that will look into the Virtual File 2777 content and perform mapping functions. 2779 NERPCREA Creator of the NERP String(25) 2781 Format: See Identification Code (Section 5.4) 2783 It is the location that created the NERP. 2785 NERPREAS Reason code Numeric(2) 2787 This attribute will specify why transmission cannot 2788 proceed or why processing of the file failed. 2790 "SFNA(RETRY=N)" below should be interpreted as "EFNA or 2791 SFNA(RETRY=N)" where appropriate. 2793 Value '03' ESID received with reason code '03' 2794 ( user code not known ) 2795 '04' ESID received with reason code '04' 2796 ( invalid password ) 2797 '09' ESID received with reason code '99' 2798 ( unspecified reason ) 2799 '11' SFNA(RETRY=N) received with reason code '01' 2800 ( invalid file name ) 2801 '12' SFNA(RETRY=N) received with reason code '02' 2802 ( invalid destination ) 2803 '13' SFNA(RETRY=N) received with reason code '03' 2804 ( invalid origin ) 2805 '14' SFNA(RETRY=N) received with reason code '04' 2806 ( invalid storage record format ) 2807 '15' SFNA(RETRY=N) received with reason code '05' 2808 ( maximum record length not supported ) 2809 '16' SFNA(RETRY=N) received with reason code '06' 2810 ( file size too big ) 2811 '20' SFNA(RETRY=N) received with reason code '10' 2812 ( invalid record count ) 2813 '21' SFNA(RETRY=N) received with reason code '11' 2814 ( invalid byte count ) 2815 '22' SFNA(RETRY=N) received with reason code '12' 2816 ( access method failure ) 2817 '23' SFNA(RETRY=N) received with reason code '13' 2818 ( duplicate file ) 2819 '24' SFNA(RETRY=N) received with reason code '14' 2820 ( file direction refused ) 2821 '25' SFNA(RETRY=N) received with reason code '15' 2822 ( cipher suite not supported ) 2823 '26' SFNA(RETRY=N) received with reason code '16' 2824 ( encrypted file not allowed ) 2825 '27' SFNA(RETRY=N) received with reason code '17' 2826 ( unencrypted file not allowed ) 2827 '28' SFNA(RETRY=N) received with reason code '18' 2828 ( compression not allowed) 2829 '29' SFNA(RETRY=N) received with reason code '19' 2830 ( signed file not allowed) 2831 '30' SFNA(RETRY=N) received with reason code '20' 2832 (unsigned file not allowed) 2833 '31' File signature not valid. 2834 '32' File decompression failed. 2835 '33' File decryption failed. 2836 '34' File processing failed. 2837 '35' Not delivered to recipient. 2838 '36' Not acknowledged by recipient. 2839 '50' Transmission stopped by the operator. 2840 '90' File size incompatible with recipient's 2841 protocol version 2842 '99' Unspecified reason. 2844 NERPREASL Reason Text Length Numeric(3) 2846 Length in octets of the field NERPREAST. 2848 0 indicates that no NERPREAST field follows. 2850 NERPREAST Reason Text [UTF-8](n) 2852 Reason why transmission cannot proceed in plain text. 2854 It is encoded using [UTF-8]. 2856 Maximum length of the encoded reason is 999 octets. 2858 No general structure is defined for this attribute. 2860 NERPHSHL Virtual File hash length Binary(2) 2862 Length in octets of the field NERPHSH. 2864 A binary value of 0 indicates that no hash is present. 2865 This is always the case if the NERP is not signed. 2867 NERPHSH Virtual File hash Binary(n) 2869 Hash of the Virtual File being transmitted. 2871 The algorithm used is determined by the bilaterally agreed 2872 cipher suite specified in the SFIDCIPH. 2874 NERPSIGL NERP Signature length Binary(2) 2876 0 indicates that this NERP has not been signed. 2878 Any other value indicates the length of NERPSIG in octets 2879 and indicates that this NERP has been signed. 2881 NERPSIG NERP Signature Binary(n) 2883 Contains the [CMS] enveloped signature of the NERP. 2885 Signature = Sign{NERPDSN 2886 NERPDATE 2887 NERPTIME 2888 NERPDEST 2889 NERPORIG 2890 NERPCREA 2891 NERPHSH} 2893 Each field is taken in its entirety, including any 2894 padding. The envelope must contain the original data, 2895 not just the signature. 2897 The [CMS] content type used is SignedData. 2899 The encaulated content type used is id-data. 2901 It is an application issue to validate the signature with 2902 the contents of the NERP. 2904 5.3.15 RTR - Ready To Receive 2906 o-------------------------------------------------------------------o 2907 | RTR Ready To Receive | 2908 | | 2909 | Start File Phase Initiator <---- Responder | 2910 | End File Phase Initiator <---- Responder | 2911 |-------------------------------------------------------------------| 2912 | Pos | Field | Description | Format | 2913 |-----+-----------+---------------------------------------+---------| 2914 | 0 | RTRCMD | RTR Command, 'P' | F X(1) | 2915 o-------------------------------------------------------------------o 2917 RTRCMD Command Code Character 2919 Value: 'P' RTR Command identifier. 2921 5.3.16 SECD - Security Change Direction 2923 o-------------------------------------------------------------------o 2924 | SECD Security Change Direction | 2925 | | 2926 | Start Session Phase Initiator <---> Responder | 2927 |-------------------------------------------------------------------| 2928 | Pos | Field | Description | Format | 2929 |-----+-----------+---------------------------------------+---------| 2930 | 0 | SECDCMD | SECD Command, 'J' | F X(1) | 2931 o-------------------------------------------------------------------o 2933 SECDCMD Command Code Character 2935 Value: 'J' SECD Command identifier. 2937 5.3.17 AUCH - Authentication Challenge 2939 o-------------------------------------------------------------------o 2940 | AUCH Authentication Challenge | 2941 | | 2942 | Start Session Phase Initiator <---> Responder | 2943 |-------------------------------------------------------------------| 2944 | Pos | Field | Description | Format | 2945 |-----+-----------+---------------------------------------+---------| 2946 | 0 | AUCHCMD | AUCH Command, 'A' | F X(1) | 2947 | 1 | AUCHCHLL | Challenge Length | V U(2) | 2948 | 3 | AUCHCHAL | Challenge | V U(n) | 2949 o-------------------------------------------------------------------o 2951 AUCHCMD Command Code Character 2953 Value: 'A' AUCH Command identifier. 2955 AUCHCHLL Challenge length Binary(2) 2957 Indicates the length of AUCHCHAL in octets. 2959 The length is expressed as an unsigned binary number using 2960 network byte order. 2962 AUCHCHAL Challenge Binary(n) 2964 A [CMS] encrypted 20 byte random number uniquely generated 2965 each time an AUCH is sent. 2967 5.3.18 AURP - Authentication Response 2969 o-------------------------------------------------------------------o 2970 | AURP Authentication Response | 2971 | | 2972 | Start Session Phase Initiator <---> Responder | 2973 |-------------------------------------------------------------------| 2974 | Pos | Field | Description | Format | 2975 |-----+-----------+---------------------------------------+---------| 2976 | 0 | AURPCMD | AURP Command, 'S' | F X(1) | 2977 | 1 | AURPRSP | Response | V U(20) | 2978 o-------------------------------------------------------------------o 2980 AURPCMD Command Code Character 2982 Value: 'S' AURP Command identifier. 2984 AURPRSP Response Binary(20) 2986 Contains the decrypted challenge (AUCHCHAL). 2988 IMPORTANT: 2990 It is an application implementation issue to validate a 2991 received AURP to ensure that the response matches the 2992 challenge. This validation is extremely important to ensure 2993 that a party is correctly authenticated. 2995 5.4 Identification Code 2997 The Initiator (sender) and Responder (receiver) participating in an 2998 ODETTE-FTP session are uniquely identified by an Identification Code 2999 based on [ISO-6523], Structure for the Identification of 3000 Organisations (SIO). The locations are considered to be adjacent for 3001 the duration of the transmission. 3003 The SIO has the following format. 3005 o-------------------------------------------------------------------o 3006 | Pos | Field | Description | Format | 3007 |-----+-----------+---------------------------------------+---------| 3008 | 0 | SIOOID | ODETTE Identifier | F X(1) | 3009 | 1 | SIOICD | International Code Designator | V 9(4) | 3010 | 5 | SIOORG | Organisation Code | V X(14) | 3011 | 19 | SIOCSA | Computer Sub-Address | V X(6) | 3012 o-------------------------------------------------------------------o 3014 SIOOID ODETTE Identifier Character 3016 Value: 'O' Indicates ODETTE assigned Organisation Identifier. 3017 Other values may be used for non-ODETTE codes. 3019 SIOICD International Code Designator String(4) 3021 A code forming part of the Organisation Identifier. 3023 SIOORG Organisation Code String(14) 3025 A code forming part of the Organisation Identifier. This 3026 field may contain the letters A to Z, the digits 0 to 9, 3027 space and hyphen characters. 3029 SIOCSA Computer Sub-Address String(6) 3031 A locally assigned address which uniquely identifies a 3032 system within an organisation (defined by an Organisation 3033 Identifier). 3035 6. File Services 3037 6.1 Overview 3039 The ODETTE-FTP provides services for compressing, encrypting and 3040 signing files. These services should generally be performed 3041 off line, outside of the ODETTE-FTP communications session for 3042 performance reasons although this is not a strict requirement. 3044 The ODETTE-FTP requires that the following steps must be performed in 3045 this exact sequence, although any of steps 2, 3 or 4 may be omitted. 3046 Step 1 is required only if any of steps 2, 3, or 4 are performed: 3048 1. Insert record length indicators (V Format files only)(Section 6.5) 3049 2. Sign 3050 3. Compress 3051 4. Encrypt 3053 The cipher suite for the encryption and signing algorithms is 3054 assigned by bilateral agreement. 3056 Secured and/or compressed files must be enveloped. The envelope 3057 contains additional information about the service used that is 3058 necessary for a receiving party to fully process the file. 3060 The [CMS] content types used are: 3062 EnvelopedData - Indicates encrypted data 3063 CompressedData - Indicates compressed data 3064 SignedData - Indicates signed content 3065 Data - Indicates unstructured data 3067 For signed or encrypted data, the encapsulated content type 3068 (eContentType field) is id-data. 3070 6.2 File Signing 3072 Files that are to be signed are enveloped according to the file 3073 enveloping format (SFIDENV). Generally this will be as a 3074 [CMS] package. 3076 A file may be signed more than once to ease the changeover between 3077 old and new certificates. 3079 It is recommended that the envelope does not contain the public 3080 certificate of the signer. Where files are sent to the 3081 same recipient continuously, it would serve no benefit to repeatedly 3082 send the same certificate. Both the orginal file data and 3083 signature are stored within the [CMS] package. 3085 6.3 File Encryption 3087 Files that are to be encrypted are enveloped according to the file 3088 enveloping format (SFIDENV). Generally this will be as a 3089 [CMS] package. 3091 It is recommended that encryption should be performed before the 3092 ODETTE-FTP session starts because a large file takes a long time to 3093 encrypt and could cause session time outs, even on high performance 3094 machines. 3096 Likewise, decryption of the file should occur outside of 3097 the session. Though it may be that an application chooses to allow 3098 in-session encryption and decryption for very small files. 3100 6.4 File Compression 3102 Files that are to be compressed are enveloped according to the 3103 file enveloping format (SFIDENV). Generally this will be as a 3104 [CMS] package using the [CMS Compression] data type, which uses the 3105 [ZLIB] compression algorithm by default. 3107 Unlike the buffer compression method, this method operates on a 3108 whole file. Because of the increased levels of compression, file 3109 level compression essentially deprecates the older buffer 3110 compression inside ODETTE-FTP. The buffer compression is kept 3111 for backwards compatibility. 3113 6.5 V Format Files - Record Lengths 3115 A file that has been signed, compressed and/or encrypted will have 3116 lost its record structure, so ODETTE-FTP will not be able to insert 3117 the End of Record Flag in sub record headers in Data Exchange 3118 Buffers. To preserve the record structure, V format files must have 3119 record headers inserted into them prior to signing, compression or 3120 encryption. These 2 byte binary numbers, in network byte order, 3121 indicate the length of each record, allowing the receiving system, 3122 where appropriate, to recreate the files complete with the original 3123 variable length records. Note that the header bytes hold the number 3124 of data bytes in the record and don't include themselves. 3126 This is only applicable to V Format files, which themselves are 3127 typically only of concern for mainframes. 3129 7. ODETTE-FTP Data Exchange Buffer 3131 7.1 Overview 3133 Virtual Files are transmitted by mapping the Virtual File records 3134 into Data Exchange Buffers, the maximum length of which was 3135 negotiated between the ODETTE-FTP entities via the Start Session 3136 (SSID) commands exchanged during the Start Session Phase of the 3137 protocol. 3139 Virtual File records may be of arbitrary length. A simple 3140 compression scheme is defined for strings of repeated characters. 3142 An example of the use of the Data Exchange Buffer can be found in 3143 Appendix A. 3145 7.2 Data Exchange Buffer Format 3147 For transmission of Virtual File records, data is divided into 3148 Subrecords, each of which is preceded by a one octet Subrecord 3149 Header. 3151 The Data Exchange Buffer is made up of the initial Command character, 3153 o-------------------------------------------------------- 3154 | C | H | | H | | H | | / 3155 | M | D | SUBRECORD | D | SUBRECORD | D | SUBRECORD | /_ 3156 | D | R | | R | | R | | / 3157 o------------------------------------------------------- 3159 CMD 3161 The Data Exchange Buffer Command Character, 'D'. 3163 HDR 3165 A one octet Subrecord Header defined as follows: 3167 0 1 2 3 4 5 6 7 3168 o-------------------------------o 3169 | E | C | | 3170 | o | F | C O U N T | 3171 | R | | | 3172 o-------------------------------o 3174 Bits 3176 0 End of Record Flag 3178 Set to indicate that the next subrecord is the last 3179 subrecord of the current record. 3181 Unstructured files are transmitted as a single record, in 3182 this case the flag acts as an end of file marker. 3184 1 Compression Flag 3186 Set to indicate that the next subrecord is compressed. 3188 2-7 Subrecord Count 3190 The number of octets in the Virtual File represented by the 3191 next subrecord expressed as a binary value. 3193 For uncompressed data this is simply the length of the 3194 subrecord. 3196 For compressed data this is the number of times that the 3197 single octet in the following subrecord must be inserted in 3198 the Virtual File. 3200 As six bits are available, the next subrecord may 3201 represent between 0 and 63 octets of the Virtual File. 3203 7.3 Buffer Filling Rules 3205 A Data Exchange Buffer may be any length up to the value negotiated 3206 in the Start Session exchange. 3208 Virtual File records may be concatenated within one Data Exchange 3209 Buffer or split across a number of buffers. 3211 A subrecord is never split between two Exchange Buffers. If the 3212 remaining space in the current Exchange Buffer is insufficient to 3213 contain the next 'complete' subrecord one of the following strategies 3214 should be used: 3216 1. Truncate the Exchange Buffer, and put the complete 3217 subrecord (preceded by its header octet) in a new Exchange Buffer. 3219 2. Split the subrecord into two, filling the remainder of the 3220 Exchange Buffer with the first new subrecord and starting a new 3221 Exchange Buffer with the second. 3223 A record of length zero may appear anywhere in the Exchange Buffer. 3225 A subrecord of length zero may appear anywhere in the record and/or 3226 the Exchange Buffer. 3228 8. Stream Transmission Buffer 3230 8.1 Introduction 3232 To utilise the TCP stream a Stream Transmission Buffer (STB) is 3233 created by adding a Stream Transmission Header (STH) to the start 3234 of all Command and Data Exchange Buffers before they are passed to 3235 the TCP transport service. This allows the receiving ODETTE-FTP to 3236 recover the original Exchange Buffers. 3238 Note: The Stream Transmission Buffer is not used when using 3239 ODETTE-FTP over an X.25 network. 3241 This is because ODETTE-FTP can rely on the fact that the network 3242 service will preserve the sequence and boundaries of data units 3243 transmitted through the network and that the network service will 3244 pass the length of the data unit to the receiving ODETTE-FTP. 3245 TCP offers a stream based connection which does not provide 3246 these functions. 3248 The Stream Transmission Buffer comprises of a STH and OEB. 3250 o-----+-----------------+-----+--------------------+-----+------ 3251 | STH | OEB | STH | OEB | STH | OEB/ 3252 o-----+-----------------+-----+--------------------+-----+---- 3254 STH - Stream Transmission Header 3255 OEB - ODETTE-FTP Exchange Buffer 3257 8.2 Stream Transmission Header Format 3259 The Stream Transmission Header is shown below. The fields are 3260 transmitted from left to right. 3262 0 1 2 3 3263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 |Version| Flags | Length | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 Version 3270 Value: 0001 (binary) 3272 Stream Transmission Header version number. 3274 Flags 3276 Value: 0000 (binary) 3278 Reserved for future use. 3280 Length 3282 Range: 5 - 100003 (decimal) 3284 The length of the Stream Transmission Buffer (STH+OEB). 3286 The smallest STB is 5 octets consisting of a 4 octet header 3287 followed by a 1 octet Exchange Buffer such as a Change Direction 3288 (CD) command. 3290 The maximum Exchange Buffer length that can be negotiated is 99999 3291 octets (Section 5.3.2) giving a STB length of 100003. 3293 The length is expressed as a binary number in network byte order. 3295 It is expected that implementations of this protocol will follow the 3296 Internet robustness principle of being conservative in what is sent 3297 and liberal in what is accepted. 3299 9. Protocol State Machine 3301 9.1 ODETTE-FTP State Machine 3303 The operation of an ODETTE-FTP entity is formally defined by the 3304 State Machine presented below. There are five State and Transition 3305 tables and for each table additional information is given in the 3306 associated Predicate and Action lists. 3308 The response of an ODETTE-FTP entity to the receipt of an event is 3309 defined by a Transition table entry indexed by the Event/State 3310 intersection within the appropriate State table. 3312 Each Transition table entry defines the actions taken, events 3313 generated and new state entered. Predicates may be used within a 3314 table entry to select the correct response on the basis of local 3315 information held by the entity. 3317 A transition table contains the following fields: 3319 Index(I) State transition index. 3321 Predicate A list of predicates used to select between different 3322 possible transitions. The predicates are defined in 3323 the Predicate and Action list. 3325 Actions A list of actions taken by the entity. The actions 3326 are defined in the Predicate and Action list. 3328 Events Output events generated by the entity 3330 Next State The new state of the entity. 3332 9.2 Error Handling 3334 The receipt of an event in a given state may be invalid for three 3335 reasons. 3337 1. The case is impossible by design of the state automata, 3338 denoted 'X' in the State tables. For example a timer which has 3339 not been set cannot run out. 3341 2. The event is the result of an error in the Network Service 3342 implementation, also denoted 'X' in the state tables. The 3343 Network Service implementation is considered to be correct. 3345 3. For all other cases the event is considered to be a User Error, 3346 denoted "U" in the state tables. 3348 The State tables define the conditions under which a User event is 3349 valid, thus preventing the generation of a protocol error by the 3350 ODETTE-FTP entity as a result of a User Monitor error. The reaction 3351 of the entity to such errors is undefined and regarded as a local 3352 implementation issue. 3354 The State tables also allow protocol errors due to the receipt of 3355 invalid Exchange Buffers, to be detected. In such cases the reaction 3356 of the entity to the error is defined. 3358 9.3 States 3360 The Command Mode is strictly a Half Duplex Flip-Flop Mode. 3362 A_NC_ONLY Responder, Network Connection opened 3364 The Responder has sent its Ready Message (SSRM) and is 3365 waiting for Start Session (SSID) from the Initiator. 3367 A_WF_CONRS Responder Waiting for F_CONNECT_RS 3369 The Responder has received the Initiator's Start Session 3370 (SSID) and is waiting for a response (F_CONNECT_RS) from 3371 its User Monitor. 3373 CDSTWFCD CD_RQ stored in WF_CD state 3375 Since the User Monitor doesn't see the WF_CD state it may 3376 send a Change Direction request (F_CD_RQ) before the 3377 ODETTE-FTP receives a Change Direction (CD) command. 3379 CLIP Close Input Pending 3381 The Listener has received an End File (EFID) command and 3382 is waiting for the Close File response (F_CLOSE_FILE_RS) 3383 from its User Monitor. 3385 CLOP Close Out Pending 3387 The Speaker has sent an End File (EFID) command and is 3388 waiting for an End File Answer (EFPA or EFNA). 3390 ERSTWFCD End to End Response stored in WF_CD state 3392 Since the User Monitor doesn't see the WF_CD state it may 3393 send F_EERP_RQ, before the ODETTE-FTP receives a Change 3394 Direction (CD) command. 3396 IDLE Connection IDLE 3398 IDLELI Idle Listener 3400 IDLELICD Idle Listener, F_CD_RQ Received 3402 The ODETTE-FTP entity has become the Listener after 3403 receiving a Change Direction request (F_CD_RQ) from the 3404 User Monitor. The receipt of an End Session (ESID) is 3405 valid in this state. 3407 IDLESP Idle Speaker 3409 IDLESPCD Idle Speaker, F_CD_IND Sent 3411 The ODETTE-FTP entity has sent a Change Direction 3412 indication (F_CD_IND) to the User Monitor. A Change 3413 Direction request (F_CD_RQ) is invalid in this state. 3415 I_WF_NC Initiator Waiting for Network Connection 3417 The Initiator has requested a new network connection and 3418 is waiting for a Connection confirmation (N_CON_CF) from 3419 the Network Service. 3421 I_WF_RM Initiator Waiting for Ready Message 3423 Before sending Start Session (SSID), the Initiator must 3424 wait for a Ready Message (SSRM) from the Responder. 3426 I_WF_SSID Initiator Waiting for SSID 3428 The Initiator has sent a Start Session (SSID) command and 3429 is waiting for Start Session from the Responder. 3431 NRSTWFCD Negative End Response stored in WF_CD state 3433 Since the User Monitor doesn't see the WF_CD state it may 3434 send F_NERP_RQ, before the ODETTE-FTP receives a Change 3435 Direction (CD) command. 3437 OPI Open Input (Data Transfer Phase) 3439 The Listener is waiting for the Speaker to send a Data 3440 Exchange buffer. 3442 OPIP Open Input Pending 3444 The Listener has received a Start File (SFID) command and 3445 is waiting for the Start File response (F_START_FILE_RS) 3446 from its User Monitor. 3448 OPO Open Out (Data Transfer Phase) 3450 The Speaker has received a Start File Positive Answer 3451 (SFPA) and is waiting for a Data (F_DATA_RQ) or Close 3452 File (F_CLOSE_FILE) request from its User Monitor. 3454 OPOP Open Out Pending 3456 The Speaker has sent a Start File (SFID) command and is 3457 waiting for a Start File Answer (SFPA or SFNA). 3459 OPOWFC Open Out Wait for Credit 3461 The Speaker is waiting for a Set Credit (CDT) command 3462 before sending further Data Exchange buffers. 3464 RTRP Ready to Receive (RTR) Pending 3466 The Listener has received an EERP or a NERP and is 3467 waiting for the Ready to Receive response (F_RTR_RS) 3468 from its User Monitor. 3470 SFSTWFCD Start File Request stored in WF_CD state. 3472 Since the User Monitor doesn't see the WF_CD state it may 3473 send a Start File request (F_START_FILE_RQ) before the 3474 ODETTE-FTP receives a Change Direction (CD) command. 3476 WF_CD Wait for Change Direction 3478 The Listener wishes to become the Speaker and is waiting 3479 for a Change Direction (CD) command after sending an End 3480 File Positive Answer (EFPA) requesting change direction. 3482 WF_RTR Wait for Ready To Receive 3484 The Speaker has sent an End to End Response (EERP) 3485 or a Negative End Response (NERP) command and must wait 3486 for Ready To Receive (RTR) from the Listener. 3488 WF_NDISC Wait for N_DISC_IND 3490 ODETTE-FTP has sent an End Session (ESID) command and is 3491 waiting for a Disconnection indication (N_DISC_IND) from 3492 the Network Service. 3494 WF_SECD Wait for Security Change Direction 3496 The Speaker is expecting a Security Change 3497 Direction (SECD) from the Listener. 3499 WF_AUCH Wait for Authentication Challenge 3501 The Speaker has sent a Security Change Direction 3502 (SECD) command and must wait for Authentication Challenge 3503 (AUCH) from the Listener. 3505 WF_AURP Wait for Authentication Response 3507 The Speaker has sent an Authentication Challenge (AUCH) 3508 command and must wait for Authentication Response (AURP) 3509 from the Listener. 3511 9.4 Input Events 3513 User Monitor Input Events (Section 3) 3515 F_DATA_RQ F_CONNECT_RQ F_START_FILE_RQ F_CLOSE_FILE_RQ 3516 F_EERP_RQ F_CONNECT_RS F_START_FILE_RS(+) F_CLOSE_FILE_RS(+) 3517 F_NERP_RQ F_ABORT_RQ F_START_FILE_RS(-) F_CLOSE_FILE_RS(-) 3518 F_CD_RQ F_RELEASE_RQ F_RTR_RS 3520 Network Input Events (Section 2.2) 3522 N_CON_IND N_CON_CF N_DATA_IND N_DISC_IND N_RST_IND 3524 Peer ODETTE-FTP Input Events (Section 4) 3526 SSID SFID SFPA SFNA EFID EFPA EFNA 3527 DATA ESID EERP RTR CD CDT SSRM 3528 NERP SECD AUCH AURP 3530 Internal Input Events 3532 TIME-OUT - Internal ODETTE-FTP timer expires. 3534 Input event parameters are denoted I.Event-name.Parameter-name within 3535 the state table action and predicate lists. Their value can be 3536 examined but not changed by the ODETTE-FTP entity. 3538 9.5 Output Events 3540 User Monitor Output Events (Section 3) 3542 F_DATA_IND F_CONNECT_IND F_START_FILE_IND F_CLOSE_FILE_IND 3543 F_EERP_IND F_CONNECT_CF F_START_FILE_CF(+) F_CLOSE_FILE_CF(+) 3544 F_CD_IND F_ABORT_IND F_START_FILE_CF(-) F_CLOSE_FILE_CF(-) 3545 F_NERP_IND F_RELEASE_IND F_DATA_CF F_RTR_CF 3547 Network Output Events (Section 2.2) 3549 N_CON_RQ N_CON_RS N_DATA_RQ N_DISC_RQ 3551 Peer ODETTE-FTP Output Events (Section 4) 3553 SSID SFID SFPA SFNA EFID EFPA EFNA 3554 DATA ESID EERP RTR CD CDT SSRM 3555 NERP SECD AUCH AURP 3557 Output event parameters are denoted O.Event-name.Parameter-name 3558 within the state table action and predicate lists. Their values can 3559 be examined and changed by the ODETTE-FTP entity. 3561 9.7 Local Variables 3563 The following variables are maintained by the ODETTE-FTP entity to 3564 assist the operation of the protocol. They are denoted V.Variable- 3565 name within the state table action and predicate lists. Their value 3566 can be examined and changed by the ODETTE-FTP entity. The initial 3567 value of each variable is undefined. 3569 Variable Type Comments 3570 --------------------------------------------------------------------- 3571 Buf-size Integer Negotiated Data Exchange Buffer size. 3572 Called-addr Address Used to build O.F_CONNECT_IND.Called-addr 3573 Calling-addr Address To build O.F_CONNECT_IND.Calling-addr 3574 Compression Yes/No Compression in use as agreed. 3575 Credit_L Integer Listeners credit counter. 3576 Credit_S Integer Speaker's credit counter. 3577 Id String Used to build O.SSID.Id 3578 Mode Sender-only, Receiver-only, Both. 3579 Pswd String Password, used to build O.SSID.Pswd 3580 Req-buf Primitive Input event (F_XXX_RQ) stored in WF_CD 3581 state. 3582 Restart Yes/No Restart in used as agreed. 3583 Restart-pos Integer Used only during file opening. 3584 Window Integer The Credit value negotiated for the 3585 session. 3586 Caller Yes/No This entity initiated the ODETTE-FTP 3587 session. 3588 Authentication Yes/No Secure authentication in use as agreed 3589 Challenge Binary Random challenge 3590 --------------------------------------------------------------------- 3592 9.8 Local Constants 3594 The following constants define the capabilities of a given ODETTE-FTP 3595 entity. They are denoted C.Constant-name within the state table 3596 action and predicate lists. Their value can be examined but not 3597 changed by the ODETTE-FTP entity. 3599 Constant Value Comments 3600 --------------------------------------------------------------------- 3601 Cap-compression Yes/No Compression supported ? 3602 Cap-init Initiator Must be Initiator. 3603 Responder Must be Responder. 3604 Both Can be Initiator or Responder. 3605 Cap-mode Sender-only Must be sender. 3606 Receiver-only Must be receiver. 3607 Both Can be sender or receiver. 3608 Max-buf-size 127 < Int < 100000 Maximum Data Exchange Buffer 3609 size supported. 3610 Max-window 0 < Int < 1000 Local maximum credit value. 3611 Cap-restart Yes/No Restart supported ? 3612 Cap-logic 0, 1, 2 0 = does not support special 3613 logic 3614 1 = supports special logic 3615 2 = needs special logic 3616 --------------------------------------------------------------------- 3618 9.9 Session Connection State Table 3620 9.9.1 State Table 3622 o----------------------------------------------------------o 3623 | | Other States | 3624 | |--------------------------------------------------o | 3625 | | WF_SECD | | 3626 | |----------------------------------------------o | | 3627 | | WF_AURP | | | 3628 | |------------------------------------------o | | | 3629 | | WF_AUCH | | | | 3630 | |--------------------------------------o | | | | 3631 | S | A_WF_CONRS | | | | | 3632 | |----------------------------------o | | | | | 3633 | T | A_NC_ONLY | | | | | | 3634 | |------------------------------o | | | | | | 3635 | A | I_WF_SSID | | | | | | | 3636 | |--------------------------o | | | | | | | 3637 | T | I_WF_RM | | | | | | | | 3638 | |----------------------o | | | | | | | | 3639 | E | I_WF_NC | | | | | | | | | 3640 | |------------------o | | | | | | | | | 3641 | | IDLE | | | | | | | | | | 3642 |==================o---+---+---+---+---+---+---+---+---+---| 3643 | | F_CONNECT_RQ | A | X | X | X | X | X | X | X | X | X | 3644 | |--------------+---+---+---+---+---+---+---+---+---+---| 3645 | E | N_CON_CF | X | C | X | X | X | X | X | X | X | X | 3646 | |--------------+---+---+---+---+---+---+---+---+---+---| 3647 | V | SSRM | X | X | H | X | X | X | L | L | L | X | 3648 | |--------------+---+---+---+---+---+---+---+---+---+---| 3649 | E | SSID | X | X | X | D | E | F | L | L | L | F | 3650 | |--------------+---+---+---+---+---+---+---+---+---+---| 3651 | N | N_CON_IND | B | X | X | X | X | X | X | X | X | X | 3652 | |--------------+---+---+---+---+---+---+---+---+---+---| 3653 | T | F_CONNECT_RS | X | U | U | U | U | G | X | X | X | U | 3654 | |--------------+---+---+---+---+---+---+---+---+---+---| 3655 | | ESID | X | X | X | F | X | X | F | F | F | X | 3656 | |--------------+---+---+---+---+---+---+---+---+---+---| 3657 | | AUCH | X | X | U | U | X | X | I | L | L | U | 3658 | |--------------+---+---+---+---+---+---+---+---+---+---| 3659 | | AURP | X | X | U | U | X | X | L | K | L | U | 3660 | |--------------+---+---+---+---+---+---+---+---+---+---| 3661 | | SECD | X | X | U | U | X | X | L | L | J | U | 3662 o----------------------------------------------------------o 3664 9.9.2 Transition Table 3666 I | Predicate Actions Output Events Next State 3667 ===o============================================================= 3668 A | P1: F_ABORT_IND IDLE 3669 | !P1: 1,2 N_CON_RQ I_WF_NC 3670 ---+------------------------------------------------------------- 3671 B | P3: N_DISC_RQ IDLE 3672 | !P3: 2 N_CON_RS 3673 | SSRM A_NC_ONLY 3674 ---+------------------------------------------------------------- 3675 C | 4,2 I_WF_RM 3676 ---+------------------------------------------------------------- 3677 D | P2 & P8 & P11: 4,2,5 SECD WF_AUCH 3678 | P2 & P8 & !P11: 4,2,5 F_CONNECT_CF IDLESP 3679 | P2 & !P8: 4,2 ESID(R=12) 3680 | F_ABORT_IND(R,AO=L) WF_NDISC 3681 | else: 4,2 ESID(R=10) 3682 | F_ABORT_IND(R,AO=L) WF_NDISC 3683 ---+------------------------------------------------------------- 3684 E | P4: 4 N_DISC_RQ IDLE 3685 | !P4: 4,2 F_CONNECT_IND A_WF_CONRS 3686 ---+------------------------------------------------------------- 3687 F | 4 F_ABORT_IND 3688 | N_DISC_RQ IDLE 3689 ---+------------------------------------------------------------- 3690 G | P2 & P9 & P10: 4,2,5 SSID WF_SECD 3691 | P2 & !P9 & P10: 4,2,5 SSID IDLELI 3692 | !P10: 4,2 ESID(R=12) 3693 | F_ABORT_IND(R,AO=L) WF_NDISC 3694 | else: 4,2 ESID(R=10) 3695 | F_ABORT_IND(R,AO=L) WF_NDISC 3696 ---+------------------------------------------------------------- 3697 H | 4,2,3 SSID I_WF_SSID 3698 ---+------------------------------------------------------------- 3699 I | P5: 4,2 AURP WF_SECD 3700 | !P5: 4,2 AURP IDLELI 3701 ---+------------------------------------------------------------- 3702 J | 4,2 AUCH WF_AURP 3703 ---+------------------------------------------------------------- 3704 K | P6: 4,2 F_CONNECT_CF IDLESP 3705 | P7: 4,2 SECD WF_AUCH 3706 | else: 4,2 ESID(R=11) 3707 | F_ABORT_IND(R,AO=L) WF_NDISC 3708 ---+------------------------------------------------------------- 3709 L | 4,2 ESID(R=02) 3710 | F_ABORT_IND(R,AO=L) WF_NDISC 3711 ---+------------------------------------------------------------- 3713 9.9.3 Predicates and Actions. 3715 Predicate P1: (No resources available) OR 3716 (C.Cap-init = Responder) OR 3717 (C.Cap-mode = Sender-only AND 3718 I.F_CONNECT_RQ.Mode = Receiver-only) OR 3719 (C.Cap-mode = Receiver-only AND 3720 I.F_CONNECT_RQ.Mode = Sender-only) 3722 Predicate P2: SSID negotiation is successful 3723 ( for these, Buf-size, Restart, Compression, Mode, 3724 Special logic and Window, compare the inbound SSID 3725 with the local constants to set the local variables. 3726 Any incompatibilities result in failure of the 3727 negotiation. ) 3729 Predicate P3: C.Cap-init = Initiator 3731 Predicate P4: Mode in SSID incompatible with C.Cap-mode 3733 Predicate P5: V.Caller = Yes 3735 Predicate P6: (V.Caller = Yes) AND 3736 (AURP.Signature verifies with V.Challenge) 3738 Predicate P7: (V.Caller = No) AND 3739 (AURP.Signature verifies with V.Challenge) 3741 Predicate P8: V.Authentication = I.SSID.Authentication 3743 Predicate P9: I.F_CONNECT_RS.Authentication = Yes 3745 Predicate P10: O.F_CONNECT_IND.Authentication = 3746 I.F_CONNECT_RS.Authentication 3748 Predicate P11: V.Authentication = Yes 3750 Action 1: Set V.Mode from (C.Cap-mode, I.F_CONNECT_RQ.Mode) 3751 Set V.Pswd, V.Id, V.Restart and 3752 V.Authentication from I.F_CONNECT_RQ 3753 Set V.Buf-size = C.Max-buf-size 3754 Set V.Compression = C.Cap-compression 3755 Set V.Caller = Yes 3756 Build O.N_CON_RQ 3758 Action 2: Start inactivity timer 3760 Action 3: Set parameters in O.SSID = from local variables 3762 Action 4: Stop timer 3764 Action 5: Set V.Mode, V.Restart, V.Compression, V.Buf-size, 3765 V.Window, V.Authentication = from SSID 3767 Action 6: Set V.Challenge = A random number unique to 3768 the session 3770 9.10 Error and Abort State Table 3772 9.10.1 State Table 3774 o--------------------------------------o 3775 | | Other States | 3776 | S |------------------------------o | 3777 | T | WF_NDISC | | 3778 | A |--------------------------o | | 3779 | T | I_WF_NC | | | 3780 | E |----------------------o | | | 3781 | | IDLE | | | | 3782 |======================o---+---+---+---| 3783 | | TIME-OUT | X | X | A | B | 3784 | |------------------+---+---+---+---| 3785 | E | F_ABORT_RQ | X | A | X | C | 3786 | V |------------------+---+---+---+---| 3787 | E | N_RST_IND | X | X | A | D | 3788 | N |------------------+---+---+---+---| 3789 | T | N_DISC_IND | X | E | F | G | 3790 | |------------------+---+---+---+---| 3791 | | Invalid Buffer | X | X | H | I | 3792 o--------------------------------------o 3794 9.10.2 Transition Table 3796 I | Predicate Actions Output Events Next State 3797 ===o================================================================= 3798 A | N_DISC_RQ IDLE 3799 ---+----------------------------------------------------------------- 3800 B | F_ABORT_IND 3801 | N_DISC_RQ IDLE 3802 ---+----------------------------------------------------------------- 3803 C | 1 N_DISC_RQ IDLE 3804 ---+----------------------------------------------------------------- 3805 D | 1 N_DISC_RQ 3806 | F_ABORT_IND IDLE 3807 ---+----------------------------------------------------------------- 3808 E | F_ABORT_IND IDLE 3809 ---+----------------------------------------------------------------- 3810 F | 1 IDLE 3811 ---+----------------------------------------------------------------- 3812 G | 1 F_ABORT_IND IDLE 3813 ---+----------------------------------------------------------------- 3814 H | WF_NDISC 3815 ---+----------------------------------------------------------------- 3816 I | 1,2 ESID(R=01) 3817 | F_ABORT_IND(R,AO=L) WF_NDISC 3818 --------------------------------------------------------------------- 3820 9.10.3 Predicates and Actions. 3822 Action 1: Stop inactivity timer 3824 Action 2: Start inactivity timer 3826 9.11 Speaker State Table 1 3828 9.11.1 State Table 3830 The following abbreviations are used in the Speaker State table. 3832 F_REL_RQ(Ok) - F_RELEASE_RQ Reason = Normal 3833 F_REL_RQ(Err) - F_RELEASE_RQ Reason = Error 3835 o--------------------------------------------------------------------o 3836 | | Other States | 3837 | |--------------------------------------------------------------o | 3838 | | WF_NDISC | | 3839 | |----------------------------------------------------------o | | 3840 | | OPOWFC | | | 3841 | |------------------------------------------------------o | | | 3842 | | OPO | | | | 3843 |S|--------------------------------------------------o | | | | 3844 | | OPOP | | | | | 3845 |T|----------------------------------------------o | | | | | 3846 | | CDSTWFCD | | | | | | 3847 |A|------------------------------------------o | | | | | | 3848 | | SFSTWFCD | | | | | | | 3849 |T|--------------------------------------o | | | | | | | 3850 | | NRSTWFCD | | | | | | | | 3851 |E|----------------------------------o | | | | | | | | 3852 | | ERSTWFCD | | | | | | | | | 3853 | |------------------------------o | | | | | | | | | 3854 | | WF_CD | | | | | | | | | | 3855 | |--------------------------o | | | | | | | | | | 3856 | | WF_RTR | | | | | | | | | | | 3857 | |----------------------o | | | | | | | | | | | 3858 | | IDLESPCD | | | | | | | | | | | | 3859 | |------------------o | | | | | | | | | | | | 3860 | | IDLESP | | | | | | | | | | | | | 3861 |=+==============o---+---+---+---+---+---+---+---+---+---+---+---+---| 3862 | | F_EERP_RQ | A | A | W | F | W | W | U | U | U | U | U | U | U | 3863 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3864 | | F_NERP_RQ | Y | Y | W | Z | W | W | U | U | U | U | U | U | U | 3865 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3866 | | F_START_ | B | B | W | G | W | W | U | U | U | U | U | X | U | 3867 | | FILE_RQ | | | | | | | | | | | | | | 3868 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3869 | | SFPA | C | C | C | C | C | C | C | C | K | C | C | S | C | 3870 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3871 |E| SFNA | C | C | C | C | C | C | C | C | L | C | C | S | C | 3872 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3873 |V| CD | C | C | C | H | R | Z1| I | J | C | C | C | S | C | 3874 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3875 |E| F_DATA_RQ | U | U | U | U | U | U | U | U | U | M | U | S | U | 3876 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3877 |N| CDT | C | C | C | C | C | C | C | C | C | P | O | S | C | 3878 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3879 |T| F_CD_RQ | D | U | W | T | W | W | U | U | U | U | U | X | U | 3880 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3881 | | F_REL_RQ(Ok) | U | E | U | U | U | U | U | U | U | U | U | X | U | 3882 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3883 | | F_REL_RQ(Err)| Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | S | Q | 3884 | |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---| 3885 | | RTR | C | C | N | C | C | C | C | C | C | C | C | S | C | 3886 o--------------------------------------------------------------------o 3888 9.11.2 Transition Table 3890 I | Predicate Actions Output Events Next State 3891 ===o================================================================= 3892 A | P5: 1,2,3,18 EERP WF_RTR 3893 | !P5: 1,2,3 EERP WF_RTR 3894 ---+----------------------------------------------------------------- 3895 B | P1: UE 3896 | !P1: 1,2,5 SFID OPOP 3897 ---+----------------------------------------------------------------- 3898 C | 1,2 ESID(R=02) 3899 | F_ABORT_IND(R,AO=L) WF_NDISC 3900 ---+----------------------------------------------------------------- 3901 D | 1,2 CD IDLELICD 3902 ---+----------------------------------------------------------------- 3903 E | 1,2 ESID(R=00) WF_NDISC 3904 ---+----------------------------------------------------------------- 3905 F | 4 ERSTWFCD 3906 ---+----------------------------------------------------------------- 3907 G | P1: UE 3908 | !P1: 6 SFSTWFCD 3909 ---+----------------------------------------------------------------- 3910 H | 1,2 IDLESP 3911 ---+----------------------------------------------------------------- 3912 I | 1,2,10 SFID OPOP 3913 ---+----------------------------------------------------------------- 3914 J | 1,2 CD IDLELICD 3915 ---+----------------------------------------------------------------- 3916 K | P2: 1,2 ESID(R=02) 3917 | F_ABORT_IND(R,AO=L) WF_NDISC 3918 | !P2: 1,2,7,12 F_START_FILE_CF(+) OPO 3919 ---+----------------------------------------------------------------- 3920 L | 1,2,8 F_START_FILE_CF(-) IDLESP 3921 ---+----------------------------------------------------------------- 3922 M | P3: 1,2,11,13 DATA OPOWFC 3923 | !P3: 1,2,11,13 DATA 3924 | F_DATA_CF OPO 3925 ---+----------------------------------------------------------------- 3926 N | F_RTR_CF IDLESP 3927 ---+----------------------------------------------------------------- 3928 O | 12 F_DATA_CF OPO 3929 ---+----------------------------------------------------------------- 3930 P | Protocol 1,2 ESID(R=02) 3931 | Error F_ABORT_IND(R,AO=L) WF_NDISC 3932 ---+----------------------------------------------------------------- 3933 Q | 1,2 ESID(R) WF_NDISC 3934 ---+----------------------------------------------------------------- 3935 Continued --> 3937 I | Predicate Actions Output Events Next State 3938 ===o================================================================= 3939 R | 1,2,9 EERP WF_RTR 3940 ---+----------------------------------------------------------------- 3941 S | WF_NDISC 3942 ---+----------------------------------------------------------------- 3943 T | CDSTWFCD 3944 ---+----------------------------------------------------------------- 3945 U | User Error UE 3946 ---+----------------------------------------------------------------- 3947 W | User Error - Note 1 UE 3948 ---+----------------------------------------------------------------- 3949 X | Error 3950 ---+----------------------------------------------------------------- 3951 Y | P4 & P5: 1,2,15,18 NERP WF_RTR 3952 | !P4 & !P5: 1,2,15,14 NERP WF_RTR 3953 | P4 & !P5: 1,2,15 NERP WF_RTR 3954 | !P4 & P5: 1,2,15,14,18 NERP WF_RTR 3955 ---+----------------------------------------------------------------- 3956 Z | 16 NRSTWFCD 3957 --------------------------------------------------------------------- 3958 Z1| P4: 1,2,17 NERP WF_RTR 3959 | !P4: 1,2,17,14 NERP WF_RTR 3960 --------------------------------------------------------------------- 3962 9.11.3 Predicates and Actions. 3964 Predicate P1: (I.F_START_FILE_RQ.Restart-pos > 0 AND 3965 V.Restart = No) OR (V.Mode = Receiver-only) 3967 Note: Restart requested and not supported for this session. 3969 Predicate P2: I.SFPA.Restart-pos > V.Restart-pos 3971 Note: Protocol error due to the restart position in the 3972 SFPA acknowledgement being greater than the position 3973 requested in the SFID request. 3975 Predicate P3: V.Credit_S - 1 = 0 3977 Note: Speaker's Credit is exhausted. 3979 Predicate P4: No special logic is in use 3981 Predicate P5: Signed EERP/NERP requested 3983 Action 1: Stop inactivity timer 3985 Action 2: Start inactivity timer 3987 Action 3: Build an EERP from F_EERP_RQ 3989 Action 4: Store F_EERP_RQ in V.Req-buf 3991 Action 5: Build SFID from F_START_FILE_RQ 3992 V.Restart-pos = I.F_START_FILE_RQ.Restart-pos 3994 Action 6: Store F_START_FILE_RQ in V.Req-buf 3996 Action 7: Build F_START_FILE_CF(+) from I.SFPA 3998 Action 8: Build F_START_FILE_CF(-) from I.SFNA 4000 Action 9: Build EERP from F_EERP_RQ stored in V.Req-buf 4002 Action 10: Build SFID from F_START_FILE_RQ stored in V.Req-buf 4003 Set V.Restart-pos 4005 Action 11: Build Exchange Buffer 4007 Action 12: V.Credit_S = V.Window 4009 Action 13: V.Credit_S = V.Credit_S - 1 4011 Action 14: Activate CRC-calculus function. Wrap Exchange buffer 4012 in special logic 4014 Action 15: Build a NERP from F_NERP_RQ 4016 Action 16: Store F_NERP_RQ in V.Req-buf 4018 Action 17: Build NERP from F_NERP_RQ stored in V.Req-buf 4020 Action 18: Sign the contents of NERP/EERP 4022 Note 1: Whether to accept this "Request/Event" while in 4023 this state is a matter of local implementation. The 4024 ODETTE state tables are based on the assumption that 4025 this event cannot occur in this state and is 4026 considered to be a user error (UE). 4028 9.12 Speaker State Table 2 4030 9.12.1 State Table 4032 o---------------------------------o 4033 | S | CLOP | 4034 | T |-------------------------o | 4035 | A | OPOWFC | | 4036 | T |---------------------o | | 4037 | E | OPO | | | 4038 |=====================o---+---+---| 4039 | E | F_CLOSE_FILE_RQ | A | E | U | 4040 | V |-----------------+---+---+---| 4041 | E | EFPA | B | B | C | 4042 | N |-----------------+---+---+---| 4043 | T | EFNA | B | B | D | 4044 o---------------------------------o 4046 9.12.2 Transition Table 4048 I | Predicate Actions Output Events Next State 4049 ===o================================================================= 4050 A | 1,2,5,7 EFID CLOP 4051 ---+----------------------------------------------------------------- 4052 B | 1,2 ESID(R=02) 4053 | F_ABORT_IND(R,AO=L) WF_NDISC 4054 ---+----------------------------------------------------------------- 4055 C | P1: 1,2,3 F_CLOSE_FILE_CF(+,SP=No) 4056 | CD IDLELI 4057 | !P1: 1,2,4 F_CLOSE_FILE_CF(+,SP=Yes) IDLESP 4058 ---+----------------------------------------------------------------- 4059 D | 1,2,6 F_CLOSE_FILE_CF(-) IDLESP 4060 ---+----------------------------------------------------------------- 4061 E | See Note 1 4062 ---+----------------------------------------------------------------- 4063 U | User Error UE 4064 --------------------------------------------------------------------- 4066 9.12.3 Predicates and Actions. 4068 Predicate P1: (I.EFPA.CD-Request = Yes) 4070 Predicate P2: No special logic is in use 4072 Action 1: Stop inactivity timer 4074 Action 2: Start inactivity timer 4076 Action 3: O.F_CLOSE_FILE_CF(+).Speaker = No 4078 Action 4: O.F_CLOSE_FILE_CF(+).Speaker = Yes 4080 Action 5: Build EFID from F_CLOSE_FILE_RQ 4082 Action 6: Build F_CLOSE_FILE_CF(-) from EFNA 4084 Action 7: Set V.Credit_S = 0 4086 Action 8: Wrap Exchange buffer in special logic 4088 Note 1: In order to respect the "half duplex" property of 4089 ODETTE-FTP it is forbidden to send EFID while in the 4090 OPOWFC state. EFID can be sent only in the OPO state. 4092 The ODETTE-FTP implementation must avoid sending EFID 4093 (or receiving F_CLOSE_FILE_RQ) while in the OPOWFC 4094 state. 4096 9.13 Listener State Table 4098 9.13.1 State Table 4100 o---------------------------------------------o 4101 | | RTRP | 4102 | |-------------------------------------o | 4103 | | CLIP | | 4104 | |---------------------------------o | | 4105 | | OPI | | | 4106 | S |-----------------------------o | | | 4107 | T | OPIP | | | | 4108 | A |-------------------------o | | | | 4109 | T | IDLELICD | | | | | 4110 | E |---------------------o | | | | | 4111 | | IDLELI | | | | | | 4112 |=====================o---+---+---+---+---+---+ 4113 | | SFID | A | A | B | B | B | B | 4114 | |-----------------+---+---+---+---+---+---+ 4115 | E | DATA | B | B | B | I | B | B | 4116 | V |-----------------+---+---+---+---+---+---+ 4117 | E | EFID | B | B | B | J | B | B | 4118 | N |-----------------+---+---+---+---+---+---+ 4119 | T | F_START_FILE_RS | U | U | H | U | U | U | 4120 | |-----------------+---+---+---+---+---+---+ 4121 | | F_CLOSE_FILE_RS | U | U | U | U | K | U | 4122 | |-----------------+---+---+---+---+---+---+ 4123 | | CD | C | B | B | B | B | B | 4124 | |-----------------+---+---+---+---+---+---+ 4125 | | ESID R=Normal | D | F | D | D | D | D | 4126 | |-----------------+---+---+---+---+---+---+ 4127 | | ESID R=Error | D | D | D | D | D | D | 4128 | |-----------------+---+---+---+---+---+---+ 4129 | | EERP | E | E | B | B | B | B | 4130 | |-----------------+---+---+---+---+---+---+ 4131 | | NERP | L | L | B | B | B | B | 4132 | |-----------------+---+---+---+---+---+---+ 4133 | | F_RTR_RS | U | U | U | U | U | M | 4134 o---------------------------------------------o 4136 9.13.2 Transition Table 4138 I | Predicate Actions Output Events Next State 4139 ===o================================================================= 4140 A | P1: 1,2 ESID(R=02) 4141 | F_ABORT_IND(R,AO=L) WF_NDISC 4142 | !P1: 1,2,3 F_START_FILE_IND OPIP 4143 ---+----------------------------------------------------------------- 4144 B | 1,2 ESID(R=02) 4145 | F_ABORT_IND(R,AO=L) WF_NDISC 4146 ---+----------------------------------------------------------------- 4147 C | 1,2 F_CD_IND IDLESPCD 4148 ---+----------------------------------------------------------------- 4149 D | 1 F_ABORT_IND(Received 4150 | ESID Reason,AO=D) 4151 | N_DISC_RQ IDLE 4152 ---+----------------------------------------------------------------- 4153 E | 1,2,4 F_EERP_IND RTRP 4154 ---+----------------------------------------------------------------- 4155 F | 1 F_RELEASE_IND 4156 | N_DISC_RQ IDLE 4157 ---+----------------------------------------------------------------- 4158 H | P4: User Error UE 4159 | P2 & !P4 & !P5: 1,2,8 SFPA OPI 4160 | !P2 & !P4 & !P5: 1,2 SFNA IDLELI 4161 | P2 & !P4 & P5: 1,2,5,8 SFPA OPI 4162 | !P2 & !P4 & P5: 1,2,5 SFNA IDLELI 4163 ---+----------------------------------------------------------------- 4164 I | P6: 1,2 ESID(R=02) 4165 | F_ABORT_IND(R,A0=L) WF_NDISC 4166 | !P5 & !P6 & !P7: 1,2,7 F_DATA_IND (See Note 1) OPI 4167 | !P5 & !P6 & P7: 1,2,8 F_DATA_IND 4168 | CDT (See Note 1) OPI 4169 | P5 & !P6 & P8: 1,2 ESID(R=07) 4170 | F_ABORT_IND(R,A0=L) WF_NDISC 4171 | P5 & !P6 & !P7 : 1,2,6,7 F_DATA_IND (See Note 1) OPI 4172 | & !P8 4173 | P5 & !P6 & P7 : 1,2,5,6,8 F_DATA_IND OPI 4174 | & !P8 CDT (See Note 1) 4175 ---+----------------------------------------------------------------- 4176 J | 1,2 F_CLOSE_FILE_IND CLIP 4177 ---+----------------------------------------------------------------- 4178 K | P2 & P3 & !P5: 1,2 EFPA(CD-Req) WF_CD 4179 | P2 & !P3 & !P5: 1,2 EFPA(no CD) IDLELI 4180 | !P2 & !P5: 1,2 EFNA IDLELI 4181 | P2 & !P3 & P5: 1,2,5 EFPA(no CD) IDLELI 4182 | !P2 & P5: 1,2,5 EFNA IDLELI 4183 | P2 & P3 & P5: 1,2,5 EFPA(CD-Req) WF_CD 4184 ---+----------------------------------------------------------------- 4185 L | 1,2,10 F_NERP_IND RTRP 4186 ---+----------------------------------------------------------------- 4187 M | 1,2 RTR IDLELI 4188 ---+----------------------------------------------------------------- 4189 U | User Error UE 4190 --------------------------------------------------------------------- 4192 9.13.3 Predicates and Actions. 4194 Predicate P1: (I.SFID.Restart-pos > 0 AND V.Restart = No) OR 4195 (V.Mode = Sender-only) 4197 Note: Invalid Start File command 4199 Predicate P2: Positive Response 4201 Predicate P3: I.F_CLOSE_FILE_RS(+).Speaker = Yes 4203 Predicate P4: I.F_START_FILE_RS(+).Restart-pos > V.Restart 4205 Predicate P5: Special logic is used 4207 Predicate P6: V.Credit_L - 1 < 0 4209 Note: Protocol Error because the Speaker has exceeded its 4210 available transmission credit. 4212 Predicate P7: V.Credit_L - 1 = 0 4214 Note: The Speaker's credit must be reset before it can send 4215 further Data Exchange buffers. 4217 Predicate P8: The calculus of the received CRC indicates an error 4219 Action 1: Stop inactivity timer. 4221 Action 2: Start inactivity timer 4223 Action 3: Build F_START_FILE_IND from I.SFID 4224 V.Restart-pos = I.SFID.Restart-pos 4226 Action 4: Build F_EERP_IND from I.EERP 4228 Action 5: Add special logic header to the command to be sent to 4229 the speaker 4231 Action 6: Suppress the special logic header from the data buffer 4232 before giving it to the user. 4234 Action 7: V.Credit_L = V.Credit_L - 1 4236 Action 8: V.Credit_L = V.Window 4238 Action 10: Build F_NERP_IND from I.NERP 4240 Note 1: Flow control in case of reception. 4242 The ODETTE-FTP Listener must periodically send new 4243 credit to the Speaker. The timing of this operation 4244 will depend on: 4246 1. The User Monitor's capacity to receive data. 4247 2. The number of buffers available to ODETTE-FTP. 4248 3. The Speaker's available credit, which must be 4249 equal to zero. 4251 9.14 Example 4253 Consider an ODETTE-FTP entity that has sent a Start File (SFID) 4254 command and entered the Open Out Pending (OPOP) state. Its response 4255 on receiving a Positive Answer (SFPA) is documented in Speaker State 4256 Table 1 which shows that transition 'K' should be applied and is 4257 interpreted as follows: 4259 if (I.SFPA.Restart-pos > V.Restart-pos) then 4260 begin // invalid restart 4261 Actions: Stop inactivity timer, // reset timer 4262 Start inactivity timer; 4263 Output: ESID(R=02), // to peer ODETTE-FTP 4264 F_ABORT_IND(R,AO=L); // to user monitor 4265 New State: WF_NDISC; 4266 end 4267 else begin 4268 Actions: Stop inactivity timer, // reset timer 4269 Start inactivity timer; 4270 Build F_START_FILE_CF(+) from I.SFPA 4271 V.Credit_S = V.Window // initialise credit 4272 Output: F_START_FILE_CF(+); // to user monitor 4273 New State: OPO; 4274 end 4276 The ODETTE-FTP checks the restart position in the received Start File 4277 Positive Answer (SFPA) command. If it is invalid it aborts the 4278 session by sending an End Session (ESID) command to its peer and an 4279 Abort indication (F_ABORT_IND) to its User Monitor. If the restart 4280 position is valid a Start File confirmation (F_START_FILE_CF) is 4281 built and sent to the User Monitor, the credit window is initialised 4282 and the Open Out (OPO) state is entered. 4284 10. Miscellaneous 4286 10.1 Algorithm Choice 4288 The choice of algorithms to use for security or compression between 4289 partners is for bilateral agreement outside of the ODETTE-FTP. 4291 10.2 Cryptographic Algorithms 4293 The algorithms for symmetric and asymmetric cryptography and hashing 4294 are represented by a coded value, the cipher suite: 4296 Cipher Suite Symmetric Asymmetric Hashing 4298 01 3DES_EDE_CBC_3KEY RSA_PKCS1_15 SHA-1 4299 02 AES_256_CBC RSA_PKCS1_15 SHA-1 4301 Support of all cipher suites listed here is mandatory. 4303 The certificates used must be [X.509] certificates. 4305 TripleDES is using Cipher Block Chaining mode (CBC) for added 4306 security and uses the EDE (Encryption Decryption Encryption) process 4307 with 3 different 64 bit keys. 4309 RSA padding is as defined in [PKCS #1]. 4311 AES is using a 256 bit key in Cipher Block Chaining mode (CBC). 4313 An extended list of optional cipher suites may be used (Section 10.2) 4314 but there is no guarantee that two communicating ODETTE-FTP entities 4315 would both support these optional cipher suites. 4317 10.2 Protocol Extensions 4319 The algorithms and file enveloping formats available in ODETTE-FTP 4320 may be extended outside of this document. 4322 A free list of optional extensions authorised for use as part of 4323 ODETTE-FTP is available from ODETTE International Ltd and on their 4324 website at http://www.odette.org 4326 10.3 Certificate Services 4328 Certificates and certificate revocation lists may be exchanged as 4329 [CMS] enveloped files. It is therefore valid to exchange a [CMS] 4330 file that is neither encrypted, compressed or signed. It is an 4331 application implementation issue to determine the correct 4332 course of action on receipt of such a file. 4334 10.4 Security Considerations 4336 ODETTE-FTP security requires the use of [X.509] certificates. If 4337 no security options are agreed for use, the send and 4338 receive passwords are sent in plain text. Whilst this is acceptable 4339 over X.25 and ISDN networks, this is a risky practice over 4340 insecure public networks such as the Internet. 4342 All, some or none of the security options available in ODETTE-FTP 4343 may be used. No recommendations for the use of these options are 4344 provided in this specification. Whilst use of the highest strength 4345 encryption algorithms may seem admirable there is often a 4346 performance tradeoff to be made, and signing all files and 4347 acknowledgements has potential legal implications that should be 4348 considered. 4350 It should be noted that whilst the security measures ensure that 4351 an ODETTE-FTP partner is authenticated, it does not necessarily 4352 mean that the partner is authorised. Having proven the identity of 4353 a partner, it is an application issue to decide whether that 4354 partner is allowed to connect or exchange files. 4356 Extracted from [RFC 3850]: 4358 "When processing certificates, there are many situations where the 4359 processing might fail. Because the processing may be done by a user 4360 agent, a security gateway, or other program, there is no single way 4361 to handle such failures. Just because the methods to handle the 4362 failures have not been listed, however, the reader should not assume 4363 that they are not important. The opposite is true: if a certificate 4364 is not provably valid and associated with the message, the processing 4365 software should take immediate and noticeable steps to inform the end 4366 user about it. 4368 Some of the many situations in which signature and certificate 4369 checking might fail include the following: 4371 No certificate chain leads to a trusted CA 4372 No ability to check the Certificate Revocation List (CRL) for a 4373 certificate 4374 An invalid CRL was received 4375 The CRL being checked is expired 4376 The certificate is expired 4377 The certificate has been revoked 4379 There are certainly other instances where a certificate may be 4380 invalid, and it is the responsibility of the processing software to 4381 check them all thoroughly, and to decide what to do if the check 4382 fails. See RFC 3280 for additional information on certificate path 4383 validation." 4385 The push / pull nature of ODETTE-FTP means that a party can 4386 make an outbound connection from behind a firewall to another 4387 party and exchange files in both directions. There is no need for 4388 both partners to open ports on their firewalls to allow incoming 4389 connections - only one party needs to allow incoming connections. 4391 See Section 1.7 for a discussion of the benefits of session security 4392 [TLS] versus file security. 4394 Appendix A. Virtual File Mapping Example 4396 This example demonstrates the mapping of a Virtual File into a 4397 sequence of ODETTE-FTP Data Exchange Buffers. 4399 Each line in this extract from 'The Rime of the Ancient Mariner' by 4400 Coleridge [RIME] is considered to be a separate record in a file 4401 containing variable length records, that is being transmitted as a 4402 V Format file. 4404 It is an ancient Mariner, 4405 And he stoppeth one of three. 4406 "By thy long grey beard and glittering eye, 4407 "Now wherefore stopp'st thou me ? 4409 "The bridegroom's doors are opended wide, 4410 "And I am next of kin; 4411 "The guests are met, the feast is set : 4412 "May'st hear the merry din." 4414 He holds him with his skinny hand, 4415 "There was a ship," quoth he. 4416 "Hold off | unhand me, grey-beard loon |" 4417 Eftsoons his hand dropt he. 4419 He holds them with his glittering eye - 4420 The Wedding-Guest stood still, 4421 And listens like a three years' child : 4422 The Mariner hath his will. 4424 The Wedding-Guest sat on a stone : 4425 He cannot chuse but hear ; 4426 And thus spake on that ancient man, 4427 The bright-eyes Mariner. 4429 The ship was cheered, the harbour cleared, 4430 Merrily did we drop 4431 Below the kirk, below the hill, 4432 Below the light-house top. 4434 The Exchange buffers below were built from the above. The top line of 4435 each represents the ASCII code, while the two lines below give the 4436 hexadecimal value. 4438 Note that : 4440 . The "D" at the beginning of each Exchange buffer is the command 4441 code. 4443 . The "." preceding each subrecord is the header octet (see the 4444 hexadecimal value). 4446 Exchange buffer 1 4448 D.It is an ancient Mariner,.And he stoppeth one of three.."By th 4449 494726726626666667246766672946626627767767626662662767662A247276 4450 499409301E01E395E40D129E52CD1E4085034F005480FE50F6048255EB229048 4452 y long grey beard and glittering eye,."Now wherefore stopp'st th 4453 7266662676726667626662666776766626762A24672766766676277677277276 4454 90CFE70725902512401E407C944529E70595C12EF70785256F25034F00734048 4456 ou me ?."The bridegroom's doors are opended wide,."And I am next 4457 6726623A25662676666766627266677267626766666276662924662426626677 4458 F50D50F9248502294572FFD7304FF2301250F05E45407945C621E40901D0E584 4460 of kin;."The guests are met, the feast is set :."May'st hear th 4461 26626663A2566267677726762667227662666772672767230246727726667276 4462 0F60B9EB72485075534301250D54C048506513409303540AF2D1973408512048 4464 Exchange buffer 2 4466 D.e merry din.".He holds him with his skinny hand,."There was a 4467 486266777266622A462666672666276762667276666726666292566762767262 4468 4D50D5229049EE228508FC43089D07948089303B9EE9081E4CD2485250713010 4470 ship," quoth he.."Hold off | unhand me, grey-beard loon |".Eftso 4471 7667222776762662A24666266622276666626622676726667626666222946776 4472 3890C2015F48085E928FC40F660105E81E40D5C07259D251240CFFE012B5643F 4474 ons his hand dropt he..He holds them with his glittering eye -.T 4475 6672667266662676772662A46266667276662767626672666776766626762295 4476 FE30893081E4042F04085E78508FC430485D07948089307C944529E705950DE4 4478 he Wedding-Guest stood still,.And listens like a three years' ch 4479 6625666666247677277666277666224662667766726666262767662766772266 4480 85075449E7D75534034FF40349CCC21E40C9345E30C9B5010482550951237038 4482 Exchange buffer 3 4484 D.ild :.The Mariner hath his will..The Wedding-Guest sat on a st 4485 4866623956624676667266762667276662A56625666666247677276726626277 4486 459C40AA4850D129E52081480893079CCE2485075449E7D7553403140FE01034 4488 one :.He cannot chuse but hear ;.And thus spake on that ancient 4489 66623946266666726677626772666723A4662767727766626627667266666672 4490 FE50AA85031EEF40385350254085120B31E4048530301B50FE0481401E395E40 4492 man,.The bright-eyes Mariner..The ship was cheered, the harbour 4493 66629566267666726767246766672A5662766727672666676622766266766772 4494 D1EC84850229784D59530D129E52EA48503890071303855254C048508122F520 4496 cleared,.Merrily did we drop.Below the kirk, below the hill,.Bel 4497 6666766294677667266627626767946667276626676226666727662666620466 4498 3C51254C3D5229C90494075042F0F25CF704850B92BC025CF70485089CCC325C 4500 Exchange buffer 4 4502 D.ow the light-house top. 4503 4967276626666726677627672 4504 47F704850C9784D8F53504F0E 4506 Appendix B. ISO 646 Character Subset 4508 o-----------------------------------------------------------------o 4509 | | 7| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 4510 | | B -+-----+-----+-----+-----+-----+-----+-----+-----| 4511 | | I 6| 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 4512 | | T -+-----+-----+-----+-----+-----+-----+-----+-----| 4513 | | 5| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 4514 | |----+-----+-----+-----+-----+-----+-----+-----+-----| 4515 | | | | | | | | | | | 4516 | | | | | | | | | | | 4517 |------------| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 4518 | BIT | | | | | | | | | | 4519 | 4 3 2 1 | | | | | | | | | | 4520 |============o====o=====+=====+=====+=====+=====+=====+=====+=====| 4521 | 0 0 0 0 | 0 | | | SP | 0 | | P | | | 4522 |------------|----|-----+-----+-----+-----+-----+-----+-----+-----| 4523 | 0 0 0 1 | 1 | | | | 1 | A | Q | | | 4524 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4525 | 0 0 1 0 | 2 | | | | 2 | B | R | | | 4526 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4527 | 0 0 1 1 | 3 | | | | 3 | C | S | | | 4528 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4529 | 0 1 0 0 | 4 | | | | 4 | D | T | | | 4530 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4531 | 0 1 0 1 | 5 | | | | 5 | E | U | | | 4532 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4533 | 0 1 1 0 | 6 | | | & | 6 | F | V | | | 4534 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4535 | 0 1 1 1 | 7 | | | | 7 | G | W | | | 4536 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4537 | 1 0 0 0 | 8 | | | ( | 8 | H | X | | | 4538 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4539 | 1 0 0 1 | 9 | | | ) | 9 | I | Y | | | 4540 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4541 | 1 0 1 0 | 10 | | | | | J | Z | | | 4542 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4543 | 1 0 1 1 | 11 | | | | | K | | | | 4544 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4545 | 1 1 0 0 | 12 | | | | | L | | | | 4546 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4547 | 1 1 0 1 | 13 | | | - | | M | | | | 4548 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4549 | 1 1 1 0 | 14 | | | . | | N | | | | 4550 |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| 4551 | 1 1 1 1 | 15 | | | / | | O | | | | 4552 o-----------------------------------------------------------------o 4554 Appendix C. X.25 Specific Information 4556 The International Standards Organisation (ISO) Open System 4557 Interconnection (OSI) model is the basis for the ODETTE-FTP. 4559 The ODETTE-FTP covers levels 4 to 7 and originally CCITT X.25 was the 4560 only recommended telecommunication protocol for OSI's layers 1, 2, 3. 4562 ISO Reference Model : 4564 +------------------------------+ <==== File Service 4565 | Level-7 FTP application | 4566 |------------------------------| 4567 | Level-6 FTP presentation | 4568 |------------------------------| 4569 | Level-5 FTP session | 4570 |------------------------------| 4571 | Level-4 FTP transport | 4572 |------------------------------| <==== Network Service 4573 | Level-3 X.25 | 4574 |------------------------------| 4575 | Level-2 X.25 | 4576 |------------------------------| 4577 | Level-1 X.25 | 4578 +------------------------------+ 4580 C.1 X.25 Addressing Restrictions 4582 When an X.25 call is made over a PSDN, the NUA of the destination 4583 must be specified in order that the PTT may route the call. The call 4584 placed is directed to the termination equipment upon the user's 4585 premises. 4587 It is possible to provide extra information in the Call 4588 Request Packet in addition to the mandatory NUA required by the PTT. 4590 This extra information may be of 2 kinds : 4592 (a) A sub-address : 4594 It is simply an extension to the address and it is put into the 4595 called address field of the Call Request Packet. This 4596 information (Address + Sub-address) is taken from the destination 4597 address field of the F_CONNECT_RQ, therefore from the user's 4598 point of view there is no distinction between the part which is 4599 the main address and the part which is the sub-address. 4601 (b) User data : 4603 There is no standard for user data. Moreover there is no 4604 information in the F_CONNECT_RQ from which the ODETTE-entity may 4605 derive user data to be put in the N_CONNECT_RQ; therefore User 4606 data shall not be used. 4608 C.2 Special Logic 4610 The SSID field SSIDSPEC specifies whether special logic must be 4611 applied ( Y (yes) or N (no) ) to the data exchange buffer before the 4612 ODETTE-FTP moves the data into the NSDU ( Network Service Data Unit ) 4613 and passes control to the network service. 4615 C.2.1 When special logic is not to be used 4617 This logic is not applied to SSRM and SSID commands. 4619 C.2.2 The need for "enveloping" exchange buffers 4621 The "special-logic" was created in order to allow the use of 4622 ODETTE-FTP over asynchronous links. The "special-logic" could be 4623 needed to enable terminals to access an X.25 network via an 4624 asynchronous entry (through a PAD: Packet Assembly / Disassembly). 4625 The "special-logic" is not needed in case of a whole X.25 connection. 4626 This "special-logic" realises a CRC function in order to detect 4627 errors due to the asynchronous medium. 4629 Negotiation of the "special-logic" parameter in the SSID command: 4631 SSID SSID 4632 ----------------------------------------------- 4634 special-logic=yes ---------------------> 4636 <------------------------------------ special-logic=yes 4637 or 4638 <------------------------------------ special-logic=no 4640 special-logic=no ----------------------> 4642 <------------------------------------ special-logic=no 4644 This logic is activated when the SPECIAL LOGIC parameter in the SSID 4645 specifies Y (yes). 4647 Special logic processing, when activated, will function within level 4648 4 of the OSI model. 4650 +------------------------------+ <==== File Service 4651 | Level-7 FTP application | 4652 |------------------------------| 4653 | Level-6 FTP presentation | 4654 |------------------------------| 4655 | Level-5 FTP session | 4656 |------------------------------| 4657 | Level-4 FTP transport | 4658 | SPECIAL LOGIC PROCESSING | 4659 |------------------------------| <==== Network Service 4660 | Level-3 X.25 | 4661 |------------------------------| 4662 | Level-2 X.25 | 4663 |------------------------------| 4664 | Level-1 X.25 | 4665 +------------------------------+ 4667 C.2.3 Responsibilities of special logic 4669 When transmitting an exchange buffer and special logic is active, 4670 layer 4 will wrap the exchange buffer in synchronization and 4671 delineation characters, then protect the data integrity by means of a 4672 block checksum (BCS). When receiving an exchange buffer and special 4673 logic is active, layer 4 will remove such things as synchronization 4674 and delineation characters etc ... before passing the exchange 4675 buffer to the higher layers. 4677 C.2.4 Extended exchange buffer format 4679 Each envelope has one byte header prefixed to it, and a 2 bytes 4680 checksum appended to the end. The checksum is derived in a manner 4681 specified in the ISO DIS 8073 TRANSPORT LAYER documentation. 4683 The layout of the data buffer will be structured as follows: 4685 +------------------------------------------------------------------+ 4686 | S | B | | B | C | 4687 | T | S | COMPLETE EXCHANGE BUFFER (CEB) | C | / | 4688 | X | N | | S | R | 4689 +------------------------------------------------------------------+ 4690 A A A A 4691 | | | | 4692 | +------------- Block sequence number | | 4693 | | | 4694 +----------------- Synchronization character | | 4695 | | 4696 Block checksum -----------------------+ | 4697 | 4698 Delineation character --------------------+ 4700 The envelope is initialised with an STX and the checksum variables 4701 are set to 0. The leading STX is not protected by the checksum 4702 calculation but is explicitly protected by a character compare at the 4703 receiver's end. The exchange buffer is processed character by 4704 character. As each character is removed from the exchange buffer it 4705 is put through the checksum calculation and then, prior to it's 4706 insertion in the envelope it is put through the Shift-out 4707 transparency logic, which will result in either one or two characters 4708 being inserted. When the contents of the exchange buffer have been 4709 entirely processed then the checksum variables are brought up to date 4710 by inserting two X'00's through the checksum calculator and the two 4711 resultant checksum characters forwarded to the shift-out transparency 4712 logic for insertion into the envelope. Finally a carriage return (CR) 4713 is appended to the envelope. The segment is now ready for 4714 transmission to line. 4716 Upon receipt of a valid envelope that has the correct sequence 4717 number, the host should increment his sequence number register ready 4718 for the next transmission. 4720 The receiver will initialise his receiving buffer area upon receipt 4721 of a STX character, place the STX at the beginning of the buffer and 4722 reset checksum variables. All subsequent characters are processed 4723 using Shift-out logic before they are inserted into the buffer, at 4724 which point they will be NOT processed by the checksum calculator, 4725 although the character following the Shift-out (after subtracting 4726 X'20') will be. The checksum characters themselves will be processed 4727 by the checksum calculator by virtue of the design of the checksum 4728 algorithm. 4730 C.2.5 Error recovery 4732 C.2.5.1 Mechanism 4734 The error correction scheme is implemented by the definition of three 4735 Timers and the use of an ASCII NAK (Negative Acknowledgement) 4736 character followed by a C/R. The will flow between the 4737 two session partners, but only as a consequence of previous bad data. 4739 A user of the error recovery correcting extension must always work 4740 with a Credit Value of 1. This can be forced upon any session partner 4741 at SSID negotiation. The effect will be to force a simple half-duplex 4742 flip-flop protocol. 4744 Upon receipt of a bad block, send to the session partner. 4746 Upon receipt of a , a session partner should retransmit the 4747 last block in its entirety. 4749 C.2.5.2 Timers 4751 The majority of error conditions will be detected by a bad BCS 4752 sequence. However, certain conditions cannot be so detected. For 4753 example, a corrupt C/R will mean that the receiver will not know that 4754 the end of a block has been reached. No matter how long he waits, no 4755 more data will come from the sender. Thus a Timer is the only way to 4756 detect this type of corruption. There are three Timers needed to 4757 detect all possible malignant conditions of this type. 4759 T1 - Exchange Buffer Time Out (Inactivity or Response) 4760 T2 - Inter Character Time Out 4761 T3 - Data Carrier Detect Loss Time Out 4763 The three Timers are in addition to the timer defined in the original 4764 protocol. 4766 TIMER T1 - RESPONSE TIME OUT (DEFAULT = 45 SECONDS) : 4768 Used to detect a high level block Time Out. E.g. the Time Out 4769 between an SFID and its associated SFPA or SFNA response. 4771 Started - It is started after the last character of an exchange 4772 buffer has been sent to the line. 4774 Stopped - It is stopped when a STX has been received. 4776 Expiry - Retransmit the whole block again, until such time as the 4777 retry limit has been reached. 4779 TIMER T2 - INTER CHARACTER TIME OUT (DEFAULT = 7 SECONDS) : 4781 Used to detect errors in the reception of individual characters. 4783 Started - For an asynchronous entity it is started upon receipt of 4784 each character while in synchronisation mode. For an 4785 X.25 entity it is started after a received block that 4786 did not terminate an exchange buffer. 4788 Stopped - Upon receipt of the next character. 4790 Expiry - Send a , drop out of synchronised mode and go 4791 back and listen to line. 4793 TIMER T3 - DATA CARRIER TEMPORARY LOSS (DEFAULT = 1 SECOND) : 4795 Used by an asynchronous entity only and is used to detect a 4796 temporary carrier failure. 4798 Started - When DCD (Data Carrier Detect) is lost. 4800 Stopped - When DCD is regained. 4802 Expiry - Disconnect the session. 4804 C.2.5.3 Types of error 4806 Data corruption when it occurs can be categorised in one of five 4807 ways: 4809 (1) CORRUPT STX (START OF TEXT) 4811 In this situation the STX is not seen and synchronisation is not 4812 achieved. The terminating C/R is received out of synchronisation and 4813 hence the block is not seen by the receiver. A is 4814 transmitted to the sender to indicate this. The sender should then 4815 retransmit the last block (each implementation will need to set a 4816 retry limit to be used for the number of consecutive times it 4817 attempts to retransmit a block - a default limit of 5 is 4818 recommended). All data received outside synchronisation (except 4819 ) are ignored. 4821 (A) (B) 4823 Dropped Start of Text (STX) 4825 +-------------------------+ 4826 | | B | | B | C | 4827 -----| | S | CEB | C | / |-----> Not sync 4828 | | N | | S | R | 4829 +-------------------------+ 4831 +-------+ 4832 | N | C | 4833 <-----| A | / |----- Not sync 4834 | K | R | 4835 +-------+ 4837 Exchange Buffer Resent 4839 +-------------------------+ 4840 | S | B | | B | C | 4841 -----| T | S | CEB | C | / |-----> Sync 4842 | X | N | | S | R | 4843 +-------------------------+ 4845 (2) CORRUPT TERMINATION (C/R) 4847 This situation manifests itself as an extended period of 4848 synchronisation with no activity. The T2 Timer will detect this 4849 condition. 4851 (A) (B) 4853 Corrupt Carriage Return 4855 +-------------------------+ 4856 | S | B | | B | | 4857 -----| T | S | CEB | C | |-----> No activity 4858 | X | N | | S | | 4859 +-------------------------+ 4861 +-------+ 4862 | N | C | T2 4863 <-----| A | / |----- Timed out 4864 | K | R | 4865 +-------+ 4867 Exchange Buffer Resent 4869 +-------------------------+ 4870 | S | B | | B | C | 4871 -----| T | S | CEB | C | / |-----> Sync 4872 | X | N | | S | R | 4873 +-------------------------+ 4875 (3) BAD DATA 4876 (4) BAD BCS (BLOCK CHECK SUM) 4878 In this situation, the receiver is unable to tell whether the error 4879 is bad data, or bad BCS. In either case the response is to discard 4880 the exchange buffer and send a . 4882 (A) (B) 4884 Bad Data/BCS 4886 +-------------------------+ 4887 | S | B | | B | C | Bad data 4888 -----| T | S | "%! | C | / |-----> detected 4889 | X | N | | S | R | 4890 +-------------------------+ 4892 +-------+ 4893 | N | C | 4894 <-----| A | / |----- Discard Block 4895 | K | R | 4896 +-------+ 4898 Exchange Buffer Resent 4900 +-------------------------+ 4901 | S | B | | B | C | 4902 -----| T | S | CEB | C | / |-----> Data OK 4903 | X | N | | S | R | 4904 +-------------------------+ 4906 (5) BAD BLOCK SEQUENCE NUMBER (BSN) 4908 A circular sequential number (0 up to and including 9) is assigned 4909 to transmitted exchange buffers. This is to aid detection of 4910 duplicate or out of sequence exchange buffers. Once a duplicate 4911 block is detected, the exchange buffer in question is discarded. 4912 Once an out of sequence block is detected this should result in a 4913 protocol violation. 4915 Example protocol sequence: 4917 (A) (B) 4919 Exchange Buffer Being Sent 4921 +-------------------------+ 4922 | S | | | B | C | Expecting 4923 -----| T | 0 | EERP | C | / |-----> BSN=0 4924 | X | | | S | R | Transmission 4925 +-------------------------+ 4927 Exchange Buffer Being Sent 4929 +-------------------------+ 4930 | S | | | B | C | Response to 4931 <----| T | 0 | RTR | C | / |----- Previous 4932 | X | | | S | R | Block 4933 +-------------------------+ 4935 Exchange Buffer Being Sent 4937 +-------------------------+ Expecting 4938 | S | | | B | C | BSN=1 (Block 4939 -----| T | 1 | SFID | C | / |- // -> lost in 4940 | X | | | S | R | Transmission) 4941 +-------------------------+ T1 Timed Out 4943 Exchange Buffer Being Sent 4945 +-------------------------+ 4946 | S | | | B | C | Send last 4947 <----| T | 0 | RTR | C | / |----- Block 4948 | X | | | S | R | again 4949 +-------------------------+ 4951 Discard Block 4952 and start 4953 Timer T1 4955 T1 Timed Out 4957 Exchange Buffer Resent 4959 +-------------------------+ 4960 | S | | | B | C | Expecting 4961 -----| T | 1 | SFID | C | / |-----> BSN=1 4962 | X | | | S | R | Block OK 4963 +-------------------------+ 4965 Exchange Buffer Being Sent 4967 +-------------------------+ 4968 | S | | | B | C | Response 4969 <----| T | 1 | SFPA | C | / |----- BSN=1 4970 | X | | | S | R | Block OK 4971 +-------------------------+ 4973 Exchange Buffer Being Sent 4975 +-------------------------+ 4976 | S | | | B | C | 4977 -----| T | 2 | DATA | C | / |-----> Data OK 4978 | X | | | S | R | 4979 +-------------------------+ 4981 Note: A credit value of 1 must be used to guarantee half-duplex 4982 flip-flop. 4984 C.2.6 Sequence of events for special logic processing 4986 Following functions will be executed in sequence: 4988 1. Calculation of the Block Sequence Number (BSN): 4990 BSN is set to zero by SSID. First block will be sent with value 4991 zero. Value of BSN is increased by one for each data buffer to be 4992 transmitted. When BSN value exceeds 9, counter will be reset to 4993 zero. 4995 Format: numeric/1 pos. 4997 2. Calculation of the Block Checksum (BCS): 4999 Calculation is done as specified in the ISO DIS 8073 TRANSPORT 5000 LAYER document. 5002 Format: binary/2 pos. 5004 3. Shift-out transparency (See TRANSMIT/RECEIVE logic) 5006 To avoid appearance of any control characters in the data stream, 5007 all the characters of the extended exchange buffer (with exception 5008 of the STX and carriage return characters enveloping the buffer) 5009 are put through a Shift-out logic, which result in a character 5010 being inserted (SO) and adding hex value '20' to the control 5011 character. 5013 4. The carriage return is inserted at the end of the data buffer. 5015 NOTE: After adding STX, BSN, BCS, CR and SO-logic, the data buffer 5016 may exceed the data exchange buffer size. 5018 C.2.7 Checksum creation algorithm 5020 These follow the ISO DIS 8073 TRANSPORT LAYER standard. 5022 SYMBOLS : 5024 The following symbols are used : 5026 C0,C1 Variables used in the algorithm 5027 L Length of the complete NSDU 5028 X Value of the first octet of the checksum parameter 5029 Y Value of the second octet of the checksum parameter 5031 ARITHMETIC CONVENTIONS : 5033 Addition is performed in one of the two following modes : 5035 a) modulo 255 arithmetic, 5036 b) one's complement arithmetic in which if any of the variables 5037 has the value minus zero (i.e. 255) it shall be regarded as 5038 though if was plus zero (i.e. 0). 5040 ALGORITHM FOR GENERATING CHECKSUM PARAMETERS : 5042 . Set up the complete NSDU with the value of the checksum parameter 5043 field set to zero. 5045 . Initialise C0 and C1 to zero. 5047 . Process each octet sequentially from i=1 to L by 5049 a) adding the value of the octet to C0; then 5050 b) adding the value of C0 to C1. 5052 . Calculate X and Y such that 5054 X = C0 - C1 5055 Y = C1 - 2*C0 5057 . Place the values X and Y in the checksum bytes 1 and 2 5058 respectively. 5060 C.2.8 Algorithm for checking checksum parameters 5062 . Initialise parameters C0 and C1 to zero. 5064 . Process each octet of NSDU sequentially from i=1 to L by 5066 a) adding the value of the octet to C0; then 5067 b) adding the value of C0 to C1. 5069 . If, when all the octets have been processed, either or both C0 5070 and C1 does not have the value zero, then the checksum formulas 5071 have not been satisfied. 5073 Note that the nature of the algorithm is such that it is not 5074 necessary to compare explicitly the stored checksum bytes. 5076 C.2.9 Shift-out processing 5078 (Transparency for all control characters) 5080 TRANSMIT LOGIC (values SO: X'0E' or X'8E') 5082 Buffer(1), ... , (n) is a character in the buffer to be sent. 5084 FOR i=1 to n /* for all octets of the buffer */ 5086 IF ((buffer(i) & X'7F') < X'20') 5088 THEN output (SO) 5089 output (buffer(i) + X'20') 5091 ELSE output (buffer(i)) 5093 NEXT: 5095 RECEIVE LOGIC (values SO: X'0E' or X'8E') 5097 Buffer(1), ... , (n) is a character in the received buffer. 5099 drop = false 5100 FOR i=1 to n /* for all octets of the buffer */ 5102 IF drop = true 5104 THEN output (buffer(i) - X'20') 5105 drop = false 5107 ELSE IF buffer(i) = (X'0D' or X'8D') 5108 THEN Stop 5109 ELSE IF buffer(i) = SO 5110 THEN drop = true 5111 ELSE output (buffer(i)) 5113 NEXT: 5115 C.3 PAD Parameter profile 5117 Before an (ODETTE-FTP) asynchronous entity --> Modem--> PAD--> 5118 (ODETTE-FTP) native X.25 link can be established, the target PAD 5119 parameters must be set such that correct communication is 5120 established. It is strongly recommended that the PAD-parameters are 5121 set by the X.25 entity. CCITT recommendations X.3, X.28 and X.29 5122 define the PAD parameters and procedures for exchange of control 5123 information and user data between a PAD and a packet mode DTE. 5125 Following is the Parameter list and values used to set the PAD for 5126 ODETTE-FTP communication. For further detailed information see the 5127 specification for CCITT X.25, X.28, X.29 and X.3. 5129 No Description Value Meaning 5130 1 Escape from Data Transfer 0 Controlled by host 5131 2 Echo 0 No Echo 5132 3 Data Forwarding Signal 2 Carriage Return 5133 4 Selection of Idle Timer Delay 20 1 second 5134 5 Ancillary Device Control 0 X-ON, X-OFF not used 5135 6 PAD Service Signals 1 All except prompt 5136 7 Procedure on Break 2 Reset 5137 8 Discard Output 0 Do not discard 5138 9 Padding after Carriage Return 0 No padding 5139 10 Line Folding 0 No line folding 5140 11 Terminal Data Rate - Read only 5141 12 Flow Control of the PAD 0 No flow control used 5142 13 Linefeed Insertion after C/R 0 No line feed 5143 14 Linefeed Padding 0 No line feed padding 5144 15 Editing 0 No editing 5145 16 Character Delete 127 Delete 5146 17 Line Delete 24 X 5147 18 Line Display 18 R 5148 19 Editing PAD Service Signals 0 No service signal 5149 20 Echo Mask 0 No echo mask 5150 21 Parity Treatment 0 No parity check 5151 22 Page Wait 0 No page wait 5153 Note 1: 5155 Refer to CCITT (1984) 5156 - Parameters 1 - 12 are mandatory and available internationally. 5157 - Parameters 13 - 22 may be available on certain networks and may 5158 also be available internationally. 5159 - A parameter value may be mandatory or optional. 5161 The ODETTE profile refers only to parameter values which must be 5162 internationally implemented if the parameter is made available 5163 internationally. 5165 The ODETTE-FTP special logic option may be impossible on some PADs 5166 because of none support of some of the parameters (13 - 22). (If the 5167 PAD is supporting parity check (21) by default, ODETTE-FTP special 5168 logic would be impossible.) 5170 It is a user responsibility to ensure special logic consistency when 5171 making the PAD subscription. 5173 Note 2: 5175 Some parameters may have to be set differently depending on: 5176 - Make and function of the start-stop mode DTE entity. 5177 - Start-stop mode DTE entity ODETTE-FTP monitor function. 5178 - PAD services implemented. 5179 - Packet mode DTE entity ODETTE-FTP monitor function. 5181 Appendix D. OFTP X.25 Over ISDN Recommendation 5183 This appendix describes the recommendation of ODETTE Group 4 (1) for 5184 the use of OFTP (2) over X.25 over ISDN. 5186 This document offers an introductory overview of a technical subject. 5187 It is structured to contain the ODETTE recommendation, together with 5188 introductory information for the person not familiar with ISDN and 5189 also notes on the issues associated with the implementation of the 5190 recommendation. 5192 The first section provides the detailed ODETTE recommendation which 5193 is followed by a general discussion. If you are not familiar with the 5194 terminology, please read the subsequent sections first. 5196 How far an existing X.25 Line adapter may be replaced by an ISDN line 5197 adapter in an installation depends on the opportunities in view of 5198 connections (X.25 or ISDN) of the involved partners for file 5199 transfer. 5201 Companies, which keep many connections to external partners (for 5202 example car manufacturing companies), may use the OFTP file transfer 5203 in view of compatibility, which must always be considered, anyway 5204 only in parallel to the X.25 network. 5206 It is not the aim of this recommendation, to remove the OFTP file 5207 transfer generally from the X.25 network to the ISDN network. This 5208 will not always be possible for international connections because of 5209 technical reasons, and this does not always make sense for 5210 connections with a low size of data to be transmitted. 5212 Certainly the use of ISDN, when exchanging a high volume of data (for 5213 example CAD/CAM files), is very much cheaper than the use of an X.25 5214 network. For such cases this recommendation shall provide a cost 5215 effective possibility for file transfer. 5217 (1) ODETTE Group 4 is responsible for the specification of 5218 Telecommunications standards and recommendations for use within the 5219 Automotive Industry. 5221 (2) OFTP (ODETTE File Transfer Protocol) is the communications 5222 standard specified by ODETTE Group 4 designed for the transfer of 5223 both EDI and non-EDI data. 5225 Contents 5227 D.1 - ODETTE ISDN 5228 Recommendation: Defines the ODETTE recommendation in these 5229 terms. 5231 D.2 - Introduction 5232 to ISDN: Introduces the ISDN environment to the 5233 unfamiliar reader. 5235 D.3 - Equipment 5236 Types: Describes the various methods of connecting 5237 to ISDN. 5239 D.4 - Implementation: Implementation issues 5241 D.1 ODETTE ISDN Recommendation 5243 X.25: Level 2 ISO 7776 5244 Protocol 5246 Level 3 ISO 8208 5247 Protocol 5249 Packet Size 128 5251 Level 2 7 5252 Window Size 5254 Level 3 7 5255 Window Size 5257 First LCN 1 5259 Number of LCNs 1 5261 Facilities Window Size and Packet Size 5262 negotiation shall be supported 5263 by everybody. Call User Data 5264 should not be required. 5266 Calling NUA Optionally provided by the call 5267 initiator. 5269 Called NUA Should be set to a value where 5270 the last 'n' digits can be 5271 specified by the called party. 5273 ISDN: Apart from requesting a 64K unrestricted digital 5274 call, no ISDN features shall be required. 5276 Timeout control: To avoid connections (B-Channels) within the 5277 circuit switched ISDN network remaining active 5278 but unused for a long time, the adapter should 5279 include a timeout control. 5281 An ISDN connection (B-channel) should be released 5282 if no X.25 packets have been transmitted on this 5283 connection for a longer time. For flexibility a 5284 variable user definable timer should be 5285 incorporated into the adapter. 5287 In the event of a timeout situation the adapter 5288 has to release the ISDN connection and notify the 5289 local OFTP by the transmission of a clear packet. 5291 The pages that follow are informational and do 5292 not form part of this recommendation 5294 D.2 Introduction to ISDN 5296 The use of digital encoding techniques over such high 5297 quality, error free, backbone networks has allowed the 5298 PTTs to offer high bandwidths to the end user. The service 5299 is named ISDN (Integrated Services Digital Network). 5301 The increasing need to transfer larger volumes of EDI 5302 data, in particular CAD/CAM drawings, has focused 5303 attention upon high speed, low cost, communication. The 5304 traditional X.25 over a Packet Switched Data Network 5305 (PSDN) has been a good general purpose communications subsystem. 5306 Unfortunately its cost and transfer speed make 5307 PSDN expensive for the new requirement. 5309 X.25 over the new ISDN provides both, the transfer speed and cost 5310 benefits to satisfy the new requirements. 5312 Terminology: For us to make sense of ISDN and X.25 it is important 5313 that we use definitions precisely and avoid the abuses 5314 of the past. 5316 ISDN: Integrated Services Digital Network 5318 X.25: X.25 is a communications protocol. It defines the 5319 structure of data packets that comprise the protocol 5320 and the manner in which they are used. 5322 PSDN: A PSDN (Packet Switching Data Network) is a network 5323 over which the X.25 protocol is operated. 5325 PSPDN: A PSPDN (Packet Switching Public Data Network) are 5326 PSDNs operated by the PTTs. PSPDNs are given Trade 5327 Names, such as PSS in the UK, Datex-P in Germany and 5328 Transpac in France. 5330 BRI: Basic Rate Interface, also known as Basic Rate 5331 Access, defines an ISDN facility with 2 x 64K 5332 B-Channels. 5334 PRI: Primary Rate Interface, also known as Primary Rate 5335 Access, defines an ISDN facility with 30 x 64K 5336 B-Channels. 5338 Channels: ISDN is typically brought into a consumer's premises 5339 using a twisted pair of wire. Over this wire data can 5340 be transmitted in frequency bands. These frequency 5341 bands are allocated as channels. 5343 B Channels: The B Channels are the data channels and operate at 5344 64Kb. The two end users of a connection will 5345 communicate over a B Channel. 5347 D Channel: Signalling on ISDN is performed over the D Channel. 5348 Signalling is used to setup and release connections on 5349 the B channels. In some countries the D channel can 5350 also be used for limited X.25 access to the PTTs PSDN. 5352 The D channel operates at the lower speed of 16Kb as it 5353 is normally used only at the beginning and end of a 5354 connection. 5356 Bandwidth Allocation: 5357 2 Wire B2 - 64 Kbit 5358 Twisted Pair B1 - 64 Kbit 5359 D Channel - 16 Kbit 5361 The standard for the operation of the D channel is 5362 called ETSI and is used in most European countries. 5363 However some countries that started the introduction 5364 very early used proprietary standards e.g. 5366 1TR6 Used in Germany 5367 BTNR Used in UK 5369 Although there are D channel variations, this will not 5370 affect communications over the B channels as the 5371 communication over the D channel is between the 5372 subscriber and the ISDN service provider. 5374 However, the consumer's equipment must be able to 5375 handle the channel D signalling operated by the ISDN 5376 service provider and so there may be a problem of 5377 equipment availability and certification. 5379 All the PTTs have committed to migrate to ETSI (3) and 5380 many are currently supporting both, their national 5381 variant and ETSI. It is advisable that in this 5382 situation the subscriber select the ETSI variant to 5383 avoid unnecessary equipment obsolescence. 5385 (3) Also known as EURO-ISDN and as Q.931 5387 Services: The high speed service is provided in two forms, Basic 5388 and Primary. 5390 Basic: 2+D, the D 2B channel operates at 16 Kb. The 5391 Basic Rate access is normally provided to the 5392 subscriber over simple twisted pair cable. 5394 Primary: 30B+D, the D channel operates at 64 Kb. 5395 Primary Rate access is normally provided to the 5396 subscriber over shielded coaxial cable. Note, that the 5397 bandwidth for Primary is 2.048 Mbit/s. 5399 Protocols: The B channel is a binary channel and is transparent to 5400 the flow of data. Therefore all of the currently 5401 available protocols can operate over a B channel. The 5402 most common protocols are: 5404 X.25: The X.25 protocol is a primary protocol for open 5405 computer to computer communication. 5407 Passive Bus: It is possible to have an ISDN service enter a building 5408 and then have an 8 core cable laid within the building 5409 with multiple ISDN junction points, in the same way as 5410 one would have multiple telephone points (extensions) 5411 for a particular external telephone line. 5413 Connection Setup 5415 The adapter is responsible for analysing the outgoing X.25 call 5416 request and making an ISDN call to a derived ISDN address, 5417 establishing a new X.25 level-2 and level-3; then propagating the 5418 X.25 Call Request Packet. 5420 Connection Termination 5422 The termination phase of the X.25 call is made with a Clear 5423 Request and finalised with a Clear Confirmation. The recipient of 5424 the Clear Confirm should then closedown the ISDN connection. 5426 The clear down of the ISDN connection should only be made if there 5427 are no other SVCs active on the ISDN connection; note that the 5428 usage of multiple simultaneous SVCs is only by virtue of 5429 bi-lateral agreement. 5431 D.3 Equipment Types 5433 There are a number of ways in which ISDN/X.25 access can be made. 5435 Integrated Adapter 5437 This is normally a PC based ISDN adapter inside a PC. It is 5438 normal in such an environment that the OFTP application has the 5439 ability to manipulate the ISDN and X.25 aspects of the session 5440 independently and therefore have complete control. 5442 Equally important, is that the speed of communication between the 5443 adapter and the application are at PC BUS speeds. It is therefore 5444 more likely that the effective transmission speed will be nearer 5445 the 64K limit. 5447 The other benefit of such a direct linkage, is that both 64K B 5448 channels may be used in parallel and both able to operate at 5449 64Kb. 5451 Elementary Terminal Adapter 5453 In this scenario, the computer has an integral X.25 adapter 5454 communicating X.21 with a Terminal Adapter that fronts the ISDN 5455 network. This allows a host with a X.25 capability to interface 5456 to ISDN, normally on a one to one 5458 The interface between the Terminal Adapter and the PC will 5459 typically only support one 64K B channel. This is obviously an 5460 inefficient usage of the ISDN service. 5462 Because the linkage between the computer and the Terminal Adapter 5463 is only X.25, then some modification/configuration may be needed 5464 inside the Terminal Adapter when new users are added. 5466 X.25 Switch 5468 This solution is normally found inside the larger corporates 5469 where an internal X.25 network is operated or where dual X.25 and 5470 ISDN is required. 5472 The main benefit of a switch is to support both PSDN and ISDN 5473 simultaneously. Also multiple X.21 lines may be implemented 5474 between the X.25 Switch and the computer. 5476 This solution normally requires more effort to configure and may 5477 require obligations to be placed upon how incoming callers 5478 specify routing. 5480 D.4 Implementation 5482 Introduction 5484 The adoption of ISDN as an additional sub-system to support OFTP 5485 communications has associated implementation problems which can be 5486 categorised as below: 5488 X.25/ISDN Addressing 5489 Making a call 5490 Receiving a call 5491 Logical Channel assignment 5492 Facilities Negotiation 5493 ISDN call attributes 5494 Homologation Issues 5495 Performance 5496 Growth 5498 X.25/ISDN Addressing 5500 The original OFTP was designed to work over the X.25 networks 5501 provided by the PTTs (PSPDNs). The national X.25 networks were 5502 interconnected to provide a global X.25 network and a common 5503 addressing scheme was adopted by all. Although there were a few 5504 differences in addressing within a national network, the interface 5505 to other countries was quite rigid and normalised. 5507 PSPDN Numbering 5509 The addressing scheme adopted in X.25 is a 15 digit number (Network 5510 User Address, NUA) where the first three identify the country, the 5511 fourth digit identifies the network within the country and the 5512 remainder specify the individual subscriber plus an optional 5513 subaddress. In the UK where a full X.25 numbering scheme is adopted, 5514 a NUA is e.g. 234221200170; where 2342 is the DNIC (Data Network 5515 Identification Code) and 21200170 is the subscriber number. 5517 ISDN Numbering 5519 ISDN is an extension of the normal telephone system, consequently it 5520 adopts (or rather is) the same numbering scheme as the telephone 5521 system (PSTN). 5523 The Numbering Conflict 5525 The PSDN and PSTN numbering schemes are two totally different 5526 numbering schemes. There is no relationship between them. It is this 5527 conflict that is at the heart of the matter. 5529 Making a Call 5531 It is a consequence of PSDN and PSTN being based upon different and 5532 unconnected numbering schemes that the key problem arises. 5534 For X.25 to work over ISDN, three main methods of addressing are 5535 available: 5537 Un-mapped: The X.25 called NUA is used as the PSTN number. Thus 5538 an X.25 call to 0733394023 will result in a PSTN call 5539 to 0733394023 and the call request that consequently 5540 flows will also be to 0733394023. 5542 Manipulated: The X.25 called NUA is manipulated by the subtraction 5543 and/or addition of digits to derive a resultant PSTN 5544 number. Thus 2394023 could be manipulated to derive a 5545 PSTN number of 00944733394023; where the prefix 2 is 5546 deleted and replaced by 00944733. 5548 Mapped: The X.25 called NUA is used as a look-up into a table 5549 of PSTN numbers. Thus an X.25 call to 234221200170 5550 could be mapped to and result in a PSTN call to 5551 0733394023 and the call request that consequently 5552 flows will remain as 234221200170. 5554 Un-mapped Calls 5556 Un-mapped calls are where the host specified X.25 NUA is converted 5557 directly to the corresponding ISDN number. 5559 Thus an X.25 call issued by the host to X.25 NUA 0733394023 will 5560 result in an ISDN call to the PSTN number 0733394023. After the 5561 call has been established, then HDLC/X.25 protocol setup will be 5562 established after which an X.25 call request will be transferred 5563 with the NUA 0733394023. 5565 When a PSTN call is made, the number of digits in the called number 5566 vary depending upon the location of the called party. 5568 When a number is called, it may be local, national or international. 5570 local: 394023 5571 national: 0733 394023 5572 international: 009 44 733 394023 5574 Depending upon where a call originates, the corresponding X.25 NUA 5575 in the call request packet will vary dramatically. 5577 Such variation of X.25 NUA, in particular the changing prefix, can 5578 be difficult to be accommodated by X.25 routing logic in many 5579 products. 5581 When an international PSTN call is being made, then it is likely 5582 that the PSTN number exceeds 15 digits, which is the maximum length 5583 of an X.25 NUA. Therefore, using un-mapped addressing may make some 5584 international calls impossible to make. 5586 Manipulated Calls 5588 The X.25 called NUA is manipulated by the subtraction and/or 5589 addition of digits to derive a resultant PSTN number. 5591 Let us assume that by internal convention we have identified the 5592 prefix '2' to indicate an international ISDN call. Thus an X.25 call 5593 request of 244733394023 could be manipulated to derive a PSTN number 5594 of 00944733394023; where the prefix '2' is deleted and replaced by 5595 '009' (the international prefix). 5597 The X.25 call NUA would typically be left in its un-manipulated 5598 state. As individual internal conventions vary, the X.25 call NUA 5599 will vary, in the case above it would be 244733394023, but another 5600 installation might have the convention where a prefix of '56' 5601 specifies the UK and so the NUA will be 56733394023 where the '56' 5602 is deleted and replaced with '00944' to derive the PSTN number. 5604 Mapped Calls 5606 The mapped method offers maximum flexibility in that: 5608 The PSTN number can exceed 15 digits. 5610 The X.25 NUA and PSTN number can be totally different. 5612 The problem with mapped calls is administrative. IBM mainframes 5613 can't handle X.25 over ISDN at all, let alone support mapping. For 5614 the mainframe solution to work an external X.25/ISDN router box is 5615 required and it is the responsibility of the external box to provide 5616 any mapping necessary. 5618 This means that any changes or addition of OFTP partners over ISDN 5619 will require access to the Computer room or special configuration 5620 equipment to change the tables inside the external X.25/ISDN router 5621 box. 5623 Receiving Calls 5625 We have seen from the previous section that the called X.25 NUA from 5626 an ISDN incoming call may vary considerably. If ISDN/X.25 is 5627 confined to a national boundary, then such variation will not be so 5628 great as most calls will have matching called X.25 NUA and PSTN 5629 numbers. 5631 X.25 switches and X.25 adapters normally route/accept/reject calls 5632 based upon their X.25 called NUA. In particular, routing is made 5633 upon the X.25 called NUA sub-address. 5635 To derive this subaddress there are 2 methods: 5637 1) the last 'n' digits are analysed. 5639 2) the base X.25 NUA of the line is removed from the called NUA. 5640 e.g. if the called X.25 NUA is 23422120017010 and the PSDN 5641 subscriber NUA is 234221200170 then the subaddress derived from 5642 subtraction is 10. 5644 Obviously, the second method will not work if the incoming NUA 5645 varies. 5647 ISDN Features 5649 ISDN, like X.25, has a core set of features which are then enriched 5650 with options. In the original OFTP X.25 specification it was decided 5651 that the Q-bit and D-bit options were not common to all networks or 5652 applications, they were therefore positively excluded from the 5653 specification. 5655 It is proposed that apart from the core ISDN features necessary to 5656 establish a call, no other features be used. 5658 Subaddressing 5660 There are two forms of ISDN subaddressing, overdialled and specific. 5662 The overdial method allows an ISDN number to be artificially 5663 extended. A typical case would be where a private exchange has been 5664 installed in a larger company. Assume that the base number is 394023 5665 and the computer is on internal extension 1234, then by specifying 5666 an ISDN number of 3940231234, direct access may be made to the 5667 internal extension. 5669 The problem with this method is that it extends to called number and 5670 may, especially for international access, exceed the ISDN numbering 5671 limits between countries. 5673 The other method of sub-addressing is where a discrete sub address 5674 is placed in a specific field in the ISDN call setup. 5676 The problem with this method, is that it requires the caller to 5677 place the sub-address in the ISDN call setup. Not all ISDN 5678 implementations will allow this insertion. 5680 In conclusion, subaddressing of any kind should be avoided. 5682 Logical Channel Assignment 5684 An X.25 dataline will have associated with it a number of logical 5685 channels. 5687 The number of channels is a part of the agreement between the PTT 5688 and the subscriber. The number of channels subscribed to is 5689 important; call failure and similar problems will result if the 5690 number of logical channels defined at the two remote ends are 5691 different. 5693 If a DTE makes a call out, then the highest defined logical channel 5694 number will be selected, if the remote DCE does not have the same 5695 number of logical channels defined, then an invalid logical channel 5696 is being used from the perspective of the recipient DCE and the call 5697 will be rejected. 5699 Facilities Negotiation 5701 In the PSPDN environment, it is possible to subscribe to negotiation 5702 of window size and packet size. Although this negotiation requested 5703 by the originator's DTE may be propagated to the remote DTE at the 5704 discretion of the originator's DCE, it is a local responsibility 5705 between the DTE and DCE pair. 5707 In the ISDN scenario where it is a DTE-DTE type connection, the 5708 window size and packet size may be left at the default value and 5709 consequently the values may be omitted from the call request. If no 5710 values are specified then it is vital that both DTEs have 5711 configured themselves to the recommended defaults. 5713 The symptom of a window size mismatch is a hang situation without 5714 any informational error codes. 5716 The symptoms of a packet size mismatch could work in some scenarios 5717 but would otherwise issue error codes indicating invalid packet 5718 sizes. 5720 Window Size 5722 The CCITT X.25 window size has a default value of '2', although 5723 subscribers may have other default window sizes, e.g. '7', by virtue 5724 of agreement with the PTT. 5726 Window size negotiation can be explicitly requested by specifying 5727 the requested window size in the Facilities fields in the Call 5728 Request packet. 5730 Packet Size: 5732 The CCITT X.25 packet size has a default value of '128' octets, 5733 although subscribers may have other default values, e.g. '1024', 5734 agreed with the PTT. 5736 ISDN Call Setup 5738 The initial setup of an ISDN call is initiated with the transmission 5739 of a Q.931 SETUP command. Apart from requesting that a call be 5740 established, the SETUP command can optionally carry information 5741 about the calling party, the called party, routing information, the 5742 type of circuit required (e.g. voice or data) and information about 5743 the protocols than are requested to be established. 5745 Setup Parameters: 5747 Bearer capability Information transfer and 5748 access attributes 5750 Called Party number Destination's network address 5752 Called Party subaddress Destination's complete 5753 address 5755 Calling Party number Source's network address 5757 Low-layer compatibility Layer 1-3 indication 5759 High-layer compatibility Layer 4-7 indication 5761 Homologation 5763 Homologation procedures were adopted and vigorously enforced by the 5764 PTTs with respect to the quality and conformance of communications 5765 equipment connected to the services provided by the PTT s. 5767 In particular, commercial X.25 products had to be tested and 5768 approved before they could be connected to the PTTs PSPDN. The 5769 advantage of this to the subscriber was that there was very little 5770 chance of the approved equipment not working. 5772 With ISDN, similar approval standards are still enforced. So the 5773 subscriber has the same confidence in their ISDN equipment. Wrong, 5774 the ISDN equipment itself is approved but the X.15 protocol that 5775 operates on top of ISDN is now outside of the scope of approval 5776 services. 5778 This means that quality of conformance to standards of X.25 over 5779 ISDN is subject to the variable quality procedures within the 5780 various ISDN equipment manufacturers. 5782 Although it is likely that commercial reputation will place pressure 5783 upon the manufacturers with a programming bug to correct such 5784 errors, it still requires the subscribers that do not communicate 5785 well to put time and effort into finding the party with the error. 5787 So far tests have shown a number of subtle errors, such as timing 5788 problems, that have taken many days to find, prove and fix. 5790 Growth 5792 Primary Rate Access: 5794 If a user decides to plan for growth from the beginning, then the 5795 Primary Rate Access (PRI) has apparent financial benefits. Such 5796 apparent savings are usually lost due to the increased cost of user 5797 hardware to support such an interface. The BRI for data usage is 5798 very common and cards/adapters are low in cost whereas the PRI 5799 cards/adapters are few and far between and consequently highly 5800 priced. 5802 Basic Rate Access: 5804 One way to grow with ISDN is to buy multiple BRI lines, increasing 5805 slowly in units of 2 x B channels. The PTTs will be able to 5806 provide the same subscriber number for all the lines provided in a 5807 similar way to the traditional hunting group associated with PSTN 5808 type working. 5810 Performance 5812 The obvious benefit of ISDN is speed; unfortunately the majority of 5813 computer systems in use today have a finite amount of computing 5814 power available. The attachment of multiple active high speed 5815 communication lines used in file transfer mode could take a 5816 significant amount of CPU resource to the detriment of other users 5817 on the system. 5819 Connecting an ISDN line with the default 2 B channels to your 5820 computer using an X.21 interface is going to give a consistent 64Kb 5821 throughput only if one of the B channels is active at any one time. 5823 If there are two 64Kb channels active and contending for a single 5824 64Kb X.21 interface then effective throughput will be reduced 5825 significantly to just over 50 %. 5827 Mainframe issues: 5829 Users with a mainframe front-end are also going to find cost an 5830 issue. The scanners that scan the communications interfaces are 5831 based upon aggregate throughput. A 64Kb interface takes up a lot of 5832 cycles. 5834 Determining 'DTE' or 'DCE' characteristics 5836 The following section is an extract from the ISO/IEC 8208 5837 (International Standards Organization, International 5838 Electrotechnical Commission) (1990-03-15) standard which is an ISO 5839 extension of the CCITT X.25 standard. 5841 The restart procedure can be used to determine whether the DTE acts 5842 as a DCE or maintains its role as a DTE with respect to the logical 5843 channel selection during Virtual Call establishment and resolution 5844 of Virtual Call collision. 5846 When prepared to initialise the Packet Layer, the DTE shall initiate 5847 the restart procedure (i.e. transmit a RESTART REQUEST packet). The 5848 determination is based on the response received from the DXE as 5849 outlined below. 5851 a) If the DTE receives a RESTART INDICATION packet with a 5852 restarting cause code that is not 'DTE Originated' (i.e., it 5853 came from a DCE), then the DTE shall maintain its role as a DTE. 5855 b) If the DTE receives a RESTART INDICATION packet with a 5856 restarting cause code of 'DTE Originated' (i.e., it came from 5857 another DTE) then the DTE shall confirm the restart an act as a 5858 DCE. 5860 c) If the DTE receives a RESTART INDICATION packet with a 5861 restarting cause code of 'DTE Originated' (i.e., it came from 5862 another DTE) and it does not have an unconfirmed RESTART REQUEST 5863 packet outstanding (i.e., a restart collision), then the DTE 5864 shall consider this restart procedure completed but shall take 5865 no further action except to transmit another RESTART REQUEST 5866 packet after some randomly chosen time delay. 5868 d) If the DTE issues a RESTART REQUEST packet that is subsequently 5869 confirmed with a RESTART CONFIRMATION packet, then the DTE shall 5870 maintain its role as a DTE. 5872 IANA Considerations 5874 This document has no actions for IANA. 5876 Acknowledgements 5878 This document draws extensively on revision 1.4 of the ODETTE File 5879 Transfer Specification [OFTP]. 5881 Many people have contributed to the development of this protocol and 5882 their work is hereby acknowledged. 5884 Informative References 5886 [ISO-6523] International Organisation for Standardisation, ISO 5887 Standard 6523:1984, "Data interchange -- Structures for the 5888 identification of organisations", 1984 5890 [OFTP] Organisation for Data Exchange by Tele Transmission in 5891 Europe, Odette File Transfer Protocol, Revision 1.4, April 2000 5893 [FTP] Postel, J., Reynolds, J., "File Transfer Protocol", RFC 959, 5894 October 1985, 5896 [RFC-739] Postel, J., "Transmission Control Protocol", STD 7, 5897 RFC 793, September 1981 5899 [RIME] Coleridge, Samuel Taylor "The Rime of the Ancient Mariner", 5900 1798 5902 [X.509] Internet Society, "Internet X.509 Public Key Infrastructure, 5903 Certificate and CRL Profile", RFC 2459, January 1999 5905 [RFC 3850] Internet Society, "Secure/Multipurpose Internet Mail 5906 Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, 5907 July 2004 5909 Normative References 5911 [CMS Compression] Gutmann, P., "Compressed Data Content Type for 5912 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002 5914 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 5915 July 2004 5917 [ISO-646] International Organisation for Standardisation, ISO 5918 Standard 646:1991, "Information technology -- ISO 7-bit coded 5919 character set for information interchange", 1991 5921 [PKCS #1] RSA Laboratories East, "PKCS #1: RSA Encryption 5922 Version 1.5", RFC 2313, March 1998 5924 [TLS] Internet Society, "The TLS Protocol, Version 1.0", RFC 2246, 5925 January 1999 5927 [UTF-8] Yergeau, F., "UTF-8, A Transformation Format of ISO 10646", 5928 RFC 3629, November 2003 5930 [ZLIB] Deutsch, P., "ZLIB Compressed Data Format Specification 5931 version 3.3", RFC 1950, May 1996 5933 ODETTE Address 5935 The ODETTE File Transfer Protocol is a product of the Technology 5936 Committee of Odette International. The Technology Committee can 5937 be contacted via the ODETTE Central Office: 5939 ODETTE INTERNATIONAL Limited 5940 Forbes House 5941 Halkin Street 5942 London 5943 SW1X 7DS 5944 United Kingdom 5946 Phone: +44 (0)171 344 9227 5947 Fax: +44 (0)171 235 7112 5948 EMail info@odette.org 5949 Web www.odette.org 5951 Author's Address 5953 The author can be contacted at: 5955 Ieuan Friend 5956 Data Interchange Plc 5957 Rhys House 5958 The Minerva Business Park 5959 Lynchwood 5960 Peterborough 5961 PE2 6FT 5962 United Kingdom 5964 Phone: +44 (0)1733 371 311 5965 EMail: ieuan.friend@dip.co.uk 5967 IPR Disclosure 5969 The IETF takes no position regarding the validity or scope of any 5970 Intellectual Property Rights or other rights that might be claimed to 5971 pertain to the implementation or use of the technology described in 5972 this document or the extent to which any license under such rights 5973 might or might not be available; nor does it represent that it has 5974 made any independent effort to identify any such rights. Information 5975 on the procedures with respect to rights in RFC documents can be 5976 found in BCP 78 and BCP 79. 5978 Copies of IPR disclosures made to the IETF Secretariat and any 5979 assurances of licenses to be made available, or the result of an 5980 attempt made to obtain a general license or permission for the use of 5981 such proprietary rights by implementers or users of this 5982 specification can be obtained from the IETF on-line IPR repository at 5983 http://www.ietf.org/ipr. 5985 The IETF invites any interested party to bring to its attention any 5986 copyrights, patents or patent applications, or other proprietary 5987 rights that may cover technology that may be required to implement 5988 this standard. Please address the information to the IETF at 5989 ietf-ipr@ietf.org. 5991 Copyright 5993 Copyright (C) The IETF Trust (2007). 5995 This document is subject to the rights, licenses and restrictions 5996 contained in BCP 78, and except as set forth therein, the authors 5997 retain all their rights. 5999 This document and the information contained herein are provided on 6000 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 6001 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 6002 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 6003 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 6004 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 6005 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 6006 FOR A PARTICULAR PURPOSE.