Issue 4177: Transfer operation protocol negotiation unspecified (ftamftp-ftf) Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: In Section 3.2 File Transfer Session, the transfer operation is described requires the source FileTransferSession and Target FileTransferSession to negotiate the transfer protocol by inspecting each other's protocols_supported attribute. This is problematic if either FileTransferSession supports more than one protocol as the protocol negotiation is not specified. For example take two FileTransferSessions that list their supported protocols in their preferred order: FileTransferSession (A) FileTransferSession (B) ---------------------- ----------------------- supported_protocols: supported_protocols: 1. "TCP/IP:xxx.xxx.xx.xx:yyy" 1. "Other:adafadfasdfd" 2. "Other:adfadfasdfadfdf" 2. "TCP/IP:xxx.xxx.xx.xx:yyy" Even though they both support the same protocols, if these two FileTransferSessions attempt a transfer using the Code sample in Section 4.5.2, A will select TCP/IP, B will select "Other" and the transfer will never happen. Action Requested: specify transfer protocol selection method. Resolution: see above Revised Text: Sections 2.1.4 FileTransfer and Section 2.2 File Transfer Protocol strictly define protocol negotiation. Actions taken: January 30, 2001: received issue Discussion: Resolution Define protocol negotiation in the specification, such that one transfer endpoint defines the protocol to be used. End of Annotations:===== Date: Tue, 30 Jan 2001 16:32:33 +1000 From: Ted McFadden To: issues@omg.org, ftamftp-ftf@omg.org Cc: tmcf@ooc.com.au Subject: ftam/ftp issue: Transfer operation protocol negotation unspecified Message-ID: <20010130163233.B15721@ooc.com.au> Reply-To: Ted McFadden Mail-Followup-To: issues@omg.org, ftamftp-ftf@omg.org Mime-Version: 1.0 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id AAA08415 for ; Wed, 31 Jan 2001 00:49:44 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id AAA16789 for tmcf@ooc.com.au; Wed, 31 Jan 2001 00:49:44 +1000 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id QAA07301 for ; Tue, 30 Jan 2001 16:32:33 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id QAA16303 for tmcf@ooc.com.au; Tue, 30 Jan 2001 16:32:33 +1000 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: X/9!!]e-e9dJIe9lK:e9 Hi, This issue could be a major problem for interoperability of different vendor's FileTransferSessions. ftam/fp issue: Transfer operation protocol negotiation unspecified ---------------------------------------------------------- In Section 3.2 File Transfer Session, the transfer operation is described requires the source FileTransferSession and Target FileTransferSession to negotiate the transfer protocol by inspecting each other's protocols_supported attribute. This is problematic if either FileTransferSession supports more than one protocol as the protocol negotiation is not specified. For example take two FileTransferSessions that list their supported protocols in their preferred order: FileTransferSession (A) FileTransferSession (B) ---------------------- ----------------------- supported_protocols: supported_protocols: 1. "TCP/IP:xxx.xxx.xx.xx:yyy" 1. "Other:adafadfasdfd" 2. "Other:adfadfasdfadfdf" 2. "TCP/IP:xxx.xxx.xx.xx:yyy" Even though they both support the same protocols, if these two FileTransferSessions attempt a transfer using the Code sample in Section 4.5.2, A will select TCP/IP, B will select "Other" and the transfer will never happen. Action Requested: specify transfer protocol selection method. -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill 4169, QLD. Australia > #4177: This point is inaccurate. Only the source > FileTransferSession will determine which protocol to > use. It will inspect the supported protocols of the > destination FileTransferSession, and select the first > compatible one. Therefore, in the example given > (assuming FTS A is the source), the "other" protocol > will be used. > I can't see where in the spec it says the source will examine the destination's protocol list and use the first compatible one (implying that the destination looks at its own first.) This certainly works, but given the draft spec, you could implement it other ways without violating the specification. The text only says things like the source "FileTransferSession will use the values of its own, and the destination FileTransferSession's protocols_supported attribute to establish a connection." This text is in Chapter 4. The source FileTransferSession never communicates its selected protocol to the target FileTransferSession, it just calls "transfer" on the target FTS. So both FileTransferSessions are in fact choosing a protocol and they must process each others protocol lists differently to end up choosing the same protocol. The source FileTransferSession could directly communicate its chosen protocol if the receive_transfer operation mentioned in the prior issue had a protocol parameter. (Again no IDL proposed, just for discussion.) When I raised this issue, I wasn't implying its not possible for the FileTransferSessions to work out a protocol. Its just that the spec has to be precise about things like this. (I do have other serious concerns about the use of protocols and `transfer' in general which I will write up separately.)