On Tue, 2004-09-28 at 22:00, Barry Leiba wrote: > > Why is this a better question? I consider one of the goals of > > specification to be reduced ambiguity. I would think that if there was > > expected behavior then it would be better to be written down? > > Hm. So, let's see: > You'd expect to be able to open two FTP sessions to the same server, > set the mode to "binary" in one session, transfer a file in the other > session, and expect the mode to be binary, yes? I don't think the FTP > spec says otherwise, so....
No. This is a classic "apples to oranges" comparison. A transfer mode is clearly a session characteristic. The session uses this information to operate on the data in transit. A better comparison would be state stored central to FTPs objects of operation, i.e. files. In the case of FTP the server is mirroring state about files on the server's file system. File state, while it can not be relied on to be correct the minute the server responds to an ls for example, it can be relied on to be consistent between sessions. I could envision multiple FTP clients working in concert where one did an ls and concurrent sessions then did gets. Note, I'm not arguing SNs should be session state. I'm convinced they are not. > > > My consideration at the moment is only coordinated sessions. Sessions > > that are aware of each others logic and are behaving in concert. > > And do you know ANY Internet protocols where that happens? I'm not sure exactly what you are looking for, but I would point out RFC1990 goes in this direction. It is more important to note I'm not looking for, nor expecting, protocol help to share sessions. Mike
