internet capable / internet ready OS - Unix

This is a discussion on internet capable / internet ready OS - Unix ; RP> [...] RP> ARP - high - used by ethernet protocols RP> NNTP - moderate - newsgroups RP> ICMP - moderate - ping, traceroute RP> UDP - low, was high - gaming, peer-to-peer RP> TELNET - almost zero, was high ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: internet capable / internet ready OS

  1. internet capable / internet ready OS

    RP> [...]
    RP> ARP - high - used by ethernet protocols
    RP> NNTP - moderate - newsgroups
    RP> ICMP - moderate - ping, traceroute
    RP> UDP - low, was high - gaming, peer-to-peer
    RP> TELNET - almost zero, was high years ago - remote user
    RP> accounts, file transfer (rzsz,Kermit), "raw" email or nntp

    JdeBP> You are conflating TELNET the protocol with "telnet" the
    JdeBP> applications program.

    RP> No, I'm not.

    Yes you are -- repeatedly. You've conflated them again in this very
    post.

    RP> Did you not see all the other TELNET protocol app's that I
    RP> listed other than "'telnet' the applications program?" i.e.,
    rzsz,
    RP> Kermit, "raw" email or nntp. Aren't you amazed that you even
    RP> quoted them back to me while disclaiming them?

    No, because quoting them was part of pointing out your error. As I've
    told you once already, "raw e-mail" and "raw nntp" are _not_ "TELNET
    protocol apps". As I wrote:

    JdeBP> "raw e-mail" and "raw nntp" don't use the TELNET protocol.

    RP> Yes they do. By "raw," I was indicating that instead of using
    the
    RP> primary protocol, you could use TELNET instead.

    Utter rubbish. They do not use the TELNET protocol, as either a
    secondary protocol or otherwise. They do not use that protocol _at
    all_. As I said:

    JdeBP> They (most commonly) use NNTP, POP3, and SMTP,
    JdeBP> layered on top of TCP, in turn layered on top of IP.
    JdeBP> (Although they could also use QMTP, MSOAP, IMAP,
    JdeBP> and so forth.)

    RP> This is true. But, some of those protocols are built on TELNET.

    Utter rubbish. They are layered on top of TCP, which is in turn
    layered on top of IP. The TELNET protocol is nowhere involved. As I
    already explained:

    JdeBP> One can use the "telnet" applications program to speak (some
    of)
    JdeBP> those protocol combinations (such as SMTP/TCP/IP or
    JdeBP> NNTP/TCP/IP), because they involve passing data across the
    JdeBP> connection in human-readable and human-writable form and
    "telnet"
    JdeBP> provides an easy mechanism for sending and receiving
    JdeBP> human-readable/writable data across TCP/IP (such that it is
    JdeBP> the human, not the software, speaking the higher-level
    protocol),
    JdeBP> but that doesn't mean that one is using the TELNET protocol.

    RP> Are you implying "'telnet' the applications program" "knows"
    RP> (i.e., was programmed for) protocols other than TELNET? Are
    RP> you implying that "'telnet' the applications program" can
    RP> communicate via the full SMTP or NNTP protocols?
    RP> That's very unlikely...

    What part of "it is the human, not the software, speaking the higher-
    level protocol" is so hard to understand?

    RP> "'telnet' the applications program" can only communicate
    RP> with servers compliant with the TELNET protocol.
    RP> These include TELNET, FTP, NNTP, SMTP, etc.

    Yet more utter rubbish. An FTP server (for example) knows nothing of
    the TELNET protocol. FTP is layered on top of TCP/IP. The TELNET
    protocol is nowhere involved. Most (but not all of) the File Transfer
    Protocol involves passing data in human-readable/writable form. And
    "telnet" the application, as I said before, provides an easy mechanism
    for sending and receiving human-readable/writable data across TCP/IP
    (such that it is the human, not the software, speaking the higher-
    level protocol), but that doesn't mean that one is using the TELNET
    protocol. In fact, most "telnet" applications will only attempt to
    use the TELNET protocol when they are connecting to that protocol's
    well-known port. (This is not universally true. There are some
    "telnet" applications that use the TELNET protocol irrespective of
    port, which confuses servers for protocols such as SMTP, NNTP, HTTP,
    and so forth, which _don't speak the TELNET protocol_.) The BSD
    "telnet" records whether it intends to speak the TELNET protocol in a
    variable named "telnetport", for example.

    RP> "As in SMTP, all NNTP commands are ASCII text that are sent
    RP> over the NNTP TCP connection to an NNTP server, from the
    RP> device acting as the client (which may be a newsreader client or
    RP> an NNTP server itself). These are standard text strings adhering
    RP> to the Telnet Network Virtual Terminal (NVT) format, terminated
    RP> by the two-character 'CRLF' sequence. As is the case with SMTP
    RP> and FTP, you can conduct an interactive session with an NNTP
    RP> server by using Telnet to connect to it on port 119."
    RP> (3 seconds to locate, fourth link on first page of Yahoo search
    for
    RP> +telnet +nntp +smtp.)
    RP>
    RP> I'm sure that there is a more complete, perhaps more accurate,
    RP> and most certainly more cryptic explanation buried in the RFC's
    RP> somewhere, but since I've found well over three dozen sites which
    RP> explain exactly the same thing in a fairly short time period [...]

    That's a sad testament to the proliferation of rubbish via the World
    Wide Web if true. SMTP and NNTP do not employ the NVT concept. (For
    starters, an SMTP or an NNTP server doesn't have "a printer and a
    keyboard". Indeed, furthermore, an SMTP or NNTP server will complain
    if one uses TELNET functions.) However, it isn't true. The text that
    you've quoted states that one can use "telnet" _the application_ to
    connect to an SMTP or an NNTP server, not TELNET the protocol.


  2. FTP / telnet (was: internet capable / internet ready OS)

    [Subject updated and followup to comp.protocols.tcp-ip]

    J de Boyne Pollard a écrit :
    >
    > An FTP server (for example) knows nothing of the TELNET protocol.


    RFC 959 defining FTP seems to state otherwise. Sample quote :

    2.2. TERMINOLOGY
    [...]
    control connection

    The communication path between the USER-PI and SERVER-PI for
    the exchange of commands and replies. This connection follows
    the Telnet Protocol.
    ^^^^^^

  3. Re: FTP / telnet (was: internet capable / internet ready OS)

    In article ,
    Pascal Hambourg wrote:
    >[Subject updated and followup to comp.protocols.tcp-ip]
    >
    >J de Boyne Pollard a écrit :
    >>
    >> An FTP server (for example) knows nothing of the TELNET protocol.

    >
    >RFC 959 defining FTP seems to state otherwise. Sample quote :
    >
    > 2.2. TERMINOLOGY
    > [...]
    > control connection
    >
    > The communication path between the USER-PI and SERVER-PI for
    > the exchange of commands and replies. This connection follows
    > the Telnet Protocol.
    > ^^^^^^


    And further down in that RFC you will see this:


    ... In practice, FTP relies on very
    little of the Telnet Protocol, so the first approach does not
    necessarily involve a large amount of code.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  4. internet capable / internet ready OS

    JdeBP> You are conflating TELNET the protocol with "telnet" the
    JdeBP> applications program.

    RP> No, I'm not.

    JdeBP> [...] "raw e-mail" and "raw nntp" don't use the TELNET
    JdeBP> protocol. They (most commonly) use NNTP, POP3,
    JdeBP> and SMTP, layered on top of TCP, in turn layered on
    JdeBP> top of IP. (Although they could also use QMTP,
    JdeBP> MSOAP, IMAP, and so forth.) [...]

    RP> This is true. But, some of those protocols are built on TELNET.
    [...]

    CK> And speaking for myself, also because I agree with
    CK> Jonathon ('s facts).
    CK> [...]
    CK> TELNET makes no contribution to an SMTP session. The
    CK> telnet application is kinda handy for setting up a TCP
    CK> connection, and maybe even buffering keyboard input
    CK> so we can correct mistakes before we send them. But
    CK> the TELNET protocol is nowhere to be seen.

    RP> [...]
    RP> Again, that depends on the implementation. And, it
    RP> doesn't change the facts that one can use a TELNET
    RP> connection (probably due to MTP) and the fact that
    RP> mail was built on FTP which uses the TELNET
    RP> protocol. This is true even if SMTCP can be used
    RP> on other protocols.
    RP> [...]

    CK> [...]
    CK> And note that a TELNET connection intersperses control
    CK> information with the data. My interpretation is that without
    CK> this control information you don't have a TELNET
    CK> connection, you have just a raw TCP connection. That
    CK> interpretation underpins my entire thesis: TELNET has
    CK> no contribution to make to SMTP.
    CK>
    CK> (I confess that I've digressed a bit and argued also that
    CK> full TELNET is incompatible with SMTP, but that was to
    CK> demonstrate that in order to use a TELNET connection
    CK> with SMTP you have to reduce TELNET's contribution
    CK> to zero. And in fact, on this point I'm speculating based
    CK> on RFCs, not on experience.)

    I, conversely, _am_ writing based upon experience, of writing clients
    and servers for many of these protocols and of many other things.
    Remember the "telnet" applications that I mentioned in an earlier
    message, that only attempt to use the TELNET protocol when they are
    connecting to that protocol's well-known port? I once had to use one
    that _didn't_. (Step forward, IBM's "telnet" for OS/2!) It would, by
    default, _always_ speak the TELNET protocol, irrespective of port
    specified. Using it to perform SMTP conversations was tricky, because
    of course the client would be speaking the TELNET protocol and the
    server would be speaking the SMTP. The server wouldn't understand the
    client, because they weren't speaking the same protocol, leading to
    conversations such as this:

    [C:\]telnet a.mx.yp.to smtp
    220 a.mx.cr.yp.to NO UCE ESMTP
    quit
    502 unimplemented (#5.5.1)
    quit
    221 a.mx.cr.yp.to NO UCE
    Session closed...

    The SMTP server doesn't understand the first QUIT verb because the
    "telnet" application is speaking the TELNET protocol, and has sent a
    whole load of option negotiation characters over the connection before
    sending the first 'q'.

    By being the rare "telnet" application that always speaks the TELNET
    protocol, unlike most other "telnet" applications, this application
    serves as a reminder of the fact that applications don't map to
    protocols. One may be using a "telnet" application to talk to a
    server, but that doesn't mean that one is using the TELNET protocol in
    order to do so.

    CK> About the history... it doesn't matter whether once upon a time
    CK> SMTP ran over FTP over TELNET, [...]

    .... although it never actually did. FTP was a precursor mail
    transport to SMTP, not a protocol that ever underlay it. SMTP isn't
    and never has been layered over TELNET, either. SMTP is layered over
    TCP for Internet purposes. Moreover, in practice the only other
    things that it is commonly layered over are things such as an
    operating system's internal stream IPC mechanisms (e.g. sending a file
    to an SMTP server program, as Batch SMTP). As Mark Crispin once
    explained, although SMTP was designed to work over protocols such as
    NCP, it only ever reached the experimental stage in doing so. In the
    main, SMTP was used over TCP over IP right from the get-go.


  5. Re: internet capable / internet ready OS

    On Thu, 25 Oct 2007, J de Boyne Pollard wrote:
    > RP> This is true. But, some of those protocols are built on TELNET.


    I do not know who "RP" is, but JdBP is correct and RP is wrong.

    SMTP is most emphatically NOT built upon TELNET protocol. SMTP does NOT
    have the distinguishing feature of TELNET protocol: the IAC negotiation
    mechanism. You can NOT issue IACs to an SMTP session, and allowing TELNET
    protocol over SMTP would break 8-bit SMTP.

    However, an obscure bit of Internet trivia is that there IS a protocol,
    other than TELNET, that is built on TELNET protocol. That protocol is
    FTP! That capability has not been used for many many years, and very few
    people still remember it. I've been around since the early 1970s and I
    can never recall that capability actually being used.

    What's more, there are numerous FTP server implementations that do not
    recognize TELNET protocol. I'm probably the only person ever to have
    noticed (since I just finished surveying some in the course of posting
    this message). That doesn't mean that I care... ;-)

    -- Mark --

    http://panda.com/mrc
    Democracy is two wolves and a sheep deciding what to eat for lunch.
    Liberty is a well-armed sheep contesting the vote.

  6. Re: internet capable / internet ready OS

    On Thu, 25 Oct 2007, J de Boyne Pollard wrote:
    > JdeBP> You are conflating TELNET the protocol with "telnet" the
    > JdeBP> applications program.


    JdeBP is correct on this detail as well. Most TELNET programs have
    explicit code to disable TELNET protocol unless the connection is on port
    23 or the server starts babbling TELNET protocol first. With the advent
    of 8-bit character sets, the latter test ("the server starts babbling
    TELNET protocol first") is often omitted since 8-bit characters can be
    confused with TELNET protocol (especially so-called "old TELNET protocol"
    which hopefully went extinct along with NCP in 1983).

    Now, if RP (whomever he is) wishes to discuss these matters with me, he is
    welcome to do so; but I would like to know his qualifications first.

    I was around in the early 1970s. I wrote multiple implementations of the
    early protocols in that time, including TELNET client and server
    implementations for three different operating systems and one of the very
    first SMTP implementations (said SMTP implementation was, for a while in
    the 1980s, the leading SMTP implementation until UNIX and sendmail
    displaced the systems in question).

    -- Mark --

    http://panda.com/mrc
    Democracy is two wolves and a sheep deciding what to eat for lunch.
    Liberty is a well-armed sheep contesting the vote.

  7. Re: internet capable / internet ready OS

    In , Mark Crispin writes:
    >On Thu, 25 Oct 2007, J de Boyne Pollard wrote:


    Sir Mark, you forgot to mention that you are also an
    accomplished author. Your personal entry on Wikipedia
    is a VERY fine example of self promotion.

    later,
    lin Baden


    >Now, if RP (whomever he is) wishes to discuss these matters with me, he is
    >welcome to do so; but I would like to know his qualifications first.
    >
    >I was around in the early 1970s. I wrote multiple implementations of the
    >early protocols in that time, including TELNET client and server
    >implementations for three different operating systems and one of the very
    >first SMTP implementations (said SMTP implementation was, for a while in
    >the 1980s, the leading SMTP implementation until UNIX and sendmail
    >displaced the systems in question).
    >
    >-- Mark --
    >
    >http://panda.com/mrc
    >Democracy is two wolves and a sheep deciding what to eat for lunch.
    >Liberty is a well-armed sheep contesting the vote.




    -----------------------------------------------------------
    Let Ignorance and Intolerance Rule!

    Baden Kudrenecky
    baden@baden.nu
    http://baden.nu/
    -----------------------------------------------------------



  8. Re: internet capable / internet ready OS

    "Mark Crispin" wrote in message
    news:alpine.OSX.0.9999.0710251014250.24162@pangtzu .panda.com...

    Follow-ups set to alt.os.development,comp.protocols.tcp-ip,comp.mail.misc.
    Newserver restriction. The wide cross-post by JdBP was obviously to draw
    you into the conversation... I believe I've picked the two groups to which
    you post more frequently, yes?

    > On Thu, 25 Oct 2007, J de Boyne Pollard wrote:
    > > RP> This is true. But, some of those protocols are built on TELNET.

    >
    > I do not know who "RP" is, but JdBP is correct and RP is wrong.
    >


    I pity you for knowing Jonathan. He's proven himself wrong, illogical,
    confused, and/or sidetracked on numerous topics, on dozens of NG's. If he's
    correct, as you claim, this would be a miraculous first...

    > SMTP is most emphatically NOT built upon TELNET protocol. SMTP does NOT
    > have the distinguishing feature of TELNET protocol: the IAC negotiation
    > mechanism. You can NOT issue IACs to an SMTP session, and allowing TELNET
    > protocol over SMTP would break 8-bit SMTP.
    >


    As an individual who should be respected due to his contributions to various
    protocols, I'm interested in hearing your explanation to the following. I
    find it really odd you completely fail to make any distinction between the
    control and data stream channels of the TELNET protocol. I.e., the
    "distinguishing feature" of control channel negotiation doesn't encompass
    the entire TELNET protocol, or even large portions of it. Jonathan de Boyne
    Pollard and Ciarian Keating whose prior comments are on alt.os.development
    (where an almost unrelated thread was usurped by JdBP), both seem to ignore
    _all_ aspects of the data channel as well. Why are you of all people,
    trivializing the importance and requirements of the data channel portion of
    the TELNET protocol which was incorporated into other protcols? Your
    trivialization seems to contradict the known historical facts. FTP (RFC959)
    requires TELNET. MTP (RFC722) requires TELNET. SMTP(RFC821) requires
    RFC822 (standardization of TELNET NVT-ASCII) from MTP.

    > However, an obscure bit of Internet trivia is that there IS a protocol,
    > other than TELNET, that is built on TELNET protocol. That protocol is
    > FTP! That capability has not been used for many many years, and very few
    > people still remember it. I've been around since the early 1970s and I
    > can never recall that capability actually being used.
    >


    Yes, we already covered that and much more in the original thread...

    In your other post:

    > Now, if RP (whomever he is) wishes to discuss these matters with me, he is

    welcome to do so; but I would like to know his qualifications first.

    If you really weren't interested in discussing matters (implied by your
    statement: "... but I would like to know his qualifications first."), it's
    best not to post. Yet, you did so twice. Why incite, provoke, or slight
    someone you don't know when you don't have to? That seems unwise...

    If you're actually interested in discussing the matters with anyone, feel
    free to posts your thoughts to the entire a.o.d. thread, after you've read
    it in it's entirety, and not just the excerpts of context cross-posted by
    JdBP.


    Rod Pemberton


+ Reply to Thread