Re: Mozilla (et al.) v. TCPIP FTP server - VMS

This is a discussion on Re: Mozilla (et al.) v. TCPIP FTP server - VMS ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > In article , sms@antinode.org (Steven M. Schweda) writes: > > Oh, really? So, the RFC expects the FTP client to do caret removal > > on the names supplied by the FTP server? This seems ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: Mozilla (et al.) v. TCPIP FTP server

  1. Re: Mozilla (et al.) v. TCPIP FTP server

    From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)

    > In article <08041807563198_2020CE0A@antinode.org>, sms@antinode.org (Steven M. Schweda) writes:
    > > Oh, really? So, the RFC expects the FTP client to do caret removal
    > > on the names supplied by the FTP server? This seems to me unlikely.
    > > Have you ever used a TCPIP FTP server with extended file names on an
    > > ODS5 disk? (Apparently not. It's lamer than you might think possible.)

    >
    > Why should the carets be removed? They are part of the file name.


    Not really. They're part of the internal representation of a
    file name with exotic characters (exotic by ODS2 standards, that is).

    alp $ pipe write sys$output "abcd" > d5:a.b.c.d
    alp $ dir d5:a.b.c.d

    Directory ALP$DKA100:[sms]

    a^.b^.c.d;1

    Total of 1 file.

    (Actually, I believe that the internal-internal representation is
    optimized a bit to maximize confusion for QIO users.)

    > Oh, you want a^.b.c on VMS to become a.b.c on some other platform?
    > That's your problem, just like when we wanted A.FTN from RSX to
    > become A.FOR on VMS.


    Not really. I'd like "a.b.c.d" on VMS to appear as "a.b.c.d" in the
    FTP server listing. Failing that, as a fall-back, I'd like to be able
    to fetch "a^.b^.c.d", when _that_ appears in the FTP server listing.
    Did you try getting a TCPIP FTP server to _accept_ that caret-filled
    mess which you claim is the true VMS file name? You should. Then tell
    me how wonderfully consistent this mess is. Remember this question +
    comment?

    > Have you ever used a TCPIP FTP server with extended file names on an
    > ODS5 disk? (Apparently not. It's lamer than you might think possible.)


    That was an actual question, not a rhetorical question, but it did
    include a hint (too subtle, apparently) to _try_ some simple tasks
    involving ODS5 extended names v. a TCPIP FTP server. Actual experience
    can be more enlightening than prejudice-laden conjecture.

    From: "Richard B. Gilbert"

    > Is there some benefit to putting carets in a file name? Other than
    > creating compatibility problems?????


    It does let you specify a space without using a real space ("^_"),
    thus not splitting a command-line token. Otherwise, no, not really.
    I think that the ODS5 encoding scheme was a pretty good solution to the
    problem of expanding the character set without breaking everything. It
    did break some things, however, like the (lame) FTP server. (The latest
    version of MMS seems to be doing better, however.)

    From: JF Mezei

    > The issue here is that VMS doesn't *really* support funky names in ODS5.
    > It has a kludge to support non standard characters by preceding them
    > with a caret.


    Not in my opinion. As demonstrated above, you can use caret-free
    extended names in DCL, and many other places. (And you _must_ use them
    with the TCPIP FTP server.) There is a risk of seeing carets in some
    places, and proper programming can hide them where appropriate. The
    TCPIP FTP server fails to hide then when it should.

    > I think NFS (if I can get it to work again without rebooting) translates
    > it back to my.chocolate.bar when feeding the mac, but not FTP.


    Perhaps the NFS server is less defective than the FTP server.

    From: Marty Kuhrt

    > [...] If you want a real
    > laff on the Mac, try using Safari to do ftp:// stuff. Firefox may be a
    > bit odd, but Safari won't do it at all (at least in my case).


    Yes, Safari is worse. I think that it tries to do a "CWD
    /dev:[dir]", or some such nonsense, and then, when it gets a complaint
    back, it gives up. One might argue either way as to which is worse:
    Safari's thoroughly defective presentation of the data, or Mozilla's
    data-dependent variably defective presentation of the data.

    ------------------------------------------------------------------------

    Steven M. Schweda sms@antinode-org
    382 South Warwick Street (+1) 651-699-9818
    Saint Paul MN 55105-2547

  2. Re: Mozilla (et al.) v. TCPIP FTP server

    Steven M. Schweda wrote:
    > From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
    >
    >> In article <08041807563198_2020CE0A@antinode.org>, sms@antinode.org (Steven M. Schweda) writes:
    >>> Oh, really? So, the RFC expects the FTP client to do caret removal
    >>> on the names supplied by the FTP server? This seems to me unlikely.
    >>> Have you ever used a TCPIP FTP server with extended file names on an
    >>> ODS5 disk? (Apparently not. It's lamer than you might think possible.)

    >> Why should the carets be removed? They are part of the file name.

    >
    > Not really. They're part of the internal representation of a
    > file name with exotic characters (exotic by ODS2 standards, that is).
    >
    > alp $ pipe write sys$output "abcd" > d5:a.b.c.d
    > alp $ dir d5:a.b.c.d
    >
    > Directory ALP$DKA100:[sms]
    >
    > a^.b^.c.d;1
    >
    > Total of 1 file.
    >
    > (Actually, I believe that the internal-internal representation is
    > optimized a bit to maximize confusion for QIO users.)
    >
    >> Oh, you want a^.b.c on VMS to become a.b.c on some other platform?
    >> That's your problem, just like when we wanted A.FTN from RSX to
    >> become A.FOR on VMS.

    >
    > Not really. I'd like "a.b.c.d" on VMS to appear as "a.b.c.d" in the
    > FTP server listing. Failing that, as a fall-back, I'd like to be able
    > to fetch "a^.b^.c.d", when _that_ appears in the FTP server listing.
    > Did you try getting a TCPIP FTP server to _accept_ that caret-filled
    > mess which you claim is the true VMS file name? You should. Then tell
    > me how wonderfully consistent this mess is. Remember this question +
    > comment?
    >
    >> Have you ever used a TCPIP FTP server with extended file names on an
    >> ODS5 disk? (Apparently not. It's lamer than you might think possible.)

    >
    > That was an actual question, not a rhetorical question, but it did
    > include a hint (too subtle, apparently) to _try_ some simple tasks
    > involving ODS5 extended names v. a TCPIP FTP server. Actual experience
    > can be more enlightening than prejudice-laden conjecture.
    >
    > From: "Richard B. Gilbert"
    >
    >> Is there some benefit to putting carets in a file name? Other than
    >> creating compatibility problems?????

    >
    > It does let you specify a space without using a real space ("^_"),
    > thus not splitting a command-line token. Otherwise, no, not really.
    > I think that the ODS5 encoding scheme was a pretty good solution to the
    > problem of expanding the character set without breaking everything. It
    > did break some things, however, like the (lame) FTP server. (The latest
    > version of MMS seems to be doing better, however.)
    >
    > From: JF Mezei
    >
    >> The issue here is that VMS doesn't *really* support funky names in ODS5.
    >> It has a kludge to support non standard characters by preceding them
    >> with a caret.

    >
    > Not in my opinion. As demonstrated above, you can use caret-free
    > extended names in DCL, and many other places. (And you _must_ use them
    > with the TCPIP FTP server.) There is a risk of seeing carets in some
    > places, and proper programming can hide them where appropriate. The
    > TCPIP FTP server fails to hide then when it should.
    >
    >> I think NFS (if I can get it to work again without rebooting) translates
    >> it back to my.chocolate.bar when feeding the mac, but not FTP.

    >
    > Perhaps the NFS server is less defective than the FTP server.
    >
    > From: Marty Kuhrt
    >
    >> [...] If you want a real
    >> laff on the Mac, try using Safari to do ftp:// stuff. Firefox may be a
    >> bit odd, but Safari won't do it at all (at least in my case).

    >
    > Yes, Safari is worse. I think that it tries to do a "CWD
    > /dev:[dir]", or some such nonsense, and then, when it gets a complaint
    > back, it gives up. One might argue either way as to which is worse:
    > Safari's thoroughly defective presentation of the data, or Mozilla's
    > data-dependent variably defective presentation of the data.
    >
    > ------------------------------------------------------------------------
    >
    > Steven M. Schweda sms@antinode-org
    > 382 South Warwick Street (+1) 651-699-9818
    > Saint Paul MN 55105-2547


    XP's command line FTP client seems to work:

    ==================================================
    Microsoft Windows XP [Version 5.1.2600]
    (C) Copyright 1985-2001 Microsoft Corp.

    C:\ ftp n8wxs.com

    Connected to n8wxs.com.
    220 pws600.n8wxs.com FTP Server (Version 5.6) Ready.

    User (n8wxs.comnone)): xxxx
    331 Username xxxx requires a Password

    Password:
    230 User logged in.

    ftp> dir

    200 PORT command successful.
    150 Opening data connection for SYS$SYSDEVICE:[USERS.xxxx]*.*;* (209.193.74.95, 076)

    Directory SYS$SYSDEVICE:[USERS.xxxx]

    A^.B^.C.D;2 1/16 19-APR-2008 06:12:44 [xxxx] (RWED,RWED,RE,)
    A^.B^.C.D;1 1/16 19-APR-2008 06:12:20 [xxxx] (RWED,RWED,RE,)
    LOGIN.COM;2 5/16 13-APR-2008 14:05:13 [xxxx] (RWED,RWED,RE,)
    SD.COM;1 1/16 13-APR-2008 14:05:40 [xxxx] (RWED,RWED,RE,)
    TCPIP$FTP_SERVER.LOG;1 0/16 19-APR-2008 06:13:31 [xxxx] (RWED,RWED,RE,)

    Total of 5 files, 8/80 blocks
    226 LIST Directory transfer complete.

    ftp: 599 bytes received in 0.05Seconds 11.98Kbytes/sec.

    ftp> get "a.b.c.d"
    200 PORT command successful.
    150 Opening data connection for -
    SYS$SYSDEVICE:[USERS.xxxx]A^.B^.C.D;2 (209.193.4.95,1077) (72 bytes)

    226 Transfer complete.

    ftp: 69 bytes received in 0.00Seconds 69000.00Kbytes/sec.

    ftp> bye
    221 Goodbye.

    C:\dir a.b.c.d
    Volume in drive C is Local Disk
    Volume Serial Number is xxxxxxxx

    Directory of C:\

    04/19/2008 06:13 AM 69 a.b.c.d
    1 File(s) 69 bytes
    0 Dir(s) 3,841,728,512 bytes free

    C:\
    ==========================================

    The problem is that the HP FTP server is interpreting the incoming file names.
    So of course it isn't going to find a requested "a^.b^.c^.d" because it will map
    the name to "a^^.b^^.c^^.d" .

    Quoting the file name on the requester's side works, though.

    Jeff


    ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= - Total Privacy via Encryption =---

  3. Re: Mozilla (et al.) v. TCPIP FTP server

    Jeff Campbell wrote:

    > ftp> dir
    > A^.B^.C.D;2 1/16 19-APR-2008 06:12:44 [xxxx] (RWED,RWED,RE,)


    > ftp> get "a.b.c.d"



    If you are to do an NLIST (the official command to get the filenames),
    you will also see "A^.B^.C.D;2"

    The problem is that NLIST is meant to provide a list of files in the
    exact representation that can be used to request that file. No FTP
    client will know to translate the NLIST output of A^.B^.C.D;2 into
    "a.b.c.d" in the request.

    If HP is no longer going to release TCPIP Services for VAX, then it
    should come out and officially say so, then then allocate mega
    development budget to get TCPIP Services to adopt the stuff to support
    not only ODS5, but also those ACME services for user authentication and
    logging/intrusion detection.

    As long as Tcpip Services was still developped for VAX, one could argue
    that they couldn't start using Alpha only system services since they
    weren't available VAX. That excuse is now wearing quite thin.

    But of course, we all know that HP isn't going to magically allocate the
    development budgets and rehire the poeple it laid off.

  4. Re: Mozilla (et al.) v. TCPIP FTP server

    In article <480a1a19$0$31244$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >But of course, we all know that HP isn't going to magically allocate the
    >development budgets and rehire the poeple it laid off.


    And iff they fix FTP, then it won't help sFTP (which we're all using now
    instead of FTP) either. Sigh

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  5. Re: Mozilla (et al.) v. TCPIP FTP server

    JF Mezei wrote:
    > Jeff Campbell wrote:
    >
    >> ftp> dir
    >> A^.B^.C.D;2 1/16 19-APR-2008 06:12:44 [xxxx] (RWED,RWED,RE,)

    >
    >> ftp> get "a.b.c.d"

    >
    >
    > If you are to do an NLIST (the official command to get the filenames),
    > you will also see "A^.B^.C.D;2"
    >


    NLIST does not work from the command prompt:

    C:\>ftp n8wxs.com
    Connected to n8wxs.com.
    220 pws600.n8wxs.com FTP Server (Version 5.6) Ready.
    User (n8wxs.comnone)): xxxx
    331 Username xxxx requires a Password
    Password:
    230 User logged in.
    ftp> list
    Invalid command.
    ftp> nlist
    Invalid command.
    ftp> ?
    Commands may be abbreviated. Commands are:

    ! delete literal prompt send
    ? debug ls put status
    append dir mdelete pwd trace
    ascii disconnect mdir quit type
    bell get mget quote user
    binary glob mkdir recv verbose
    bye hash mls remotehelp
    cd help mput rename
    close lcd open rmdir
    ftp>
    ftp> bye
    221 Goodbye.

    C:\>

    > The problem is that NLIST is meant to provide a list of files in the
    > exact representation that can be used to request that file. No FTP
    > client will know to translate the NLIST output of A^.B^.C.D;2 into
    > "a.b.c.d" in the request.


    Agreed.

    The TCPIP FTP server should deal with 'illegal' characters both directions

    - inbound using the extended file name specification escape sequences, and
    - outbound replacing the escape sequences with the original characters.

    Seems like a no brainer to me.

    >
    > If HP is no longer going to release TCPIP Services for VAX, then it
    > should come out and officially say so, then then allocate mega
    > development budget to get TCPIP Services to adopt the stuff to support
    > not only ODS5, but also those ACME services for user authentication and
    > logging/intrusion detection.
    >
    > As long as Tcpip Services was still developped for VAX, one could argue
    > that they couldn't start using Alpha only system services since they
    > weren't available VAX. That excuse is now wearing quite thin.
    >
    > But of course, we all know that HP isn't going to magically allocate the
    > development budgets and rehire the poeple it laid off.


    Jeff


    ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= - Total Privacy via Encryption =---

  6. Re: Mozilla (et al.) v. TCPIP FTP server

    Jeff Campbell wrote:
    > NLIST does not work from the command prompt:
    >
    > C:\>ftp n8wxs.com
    > Connected to n8wxs.com.
    > 220 pws600.n8wxs.com FTP Server (Version 5.6) Ready.
    > User (n8wxs.comnone)): xxxx
    > 331 Username xxxx requires a Password
    > Password:
    > 230 User logged in.
    > ftp> list
    > Invalid command.
    > ftp> nlist
    > Invalid command.


    LIST and NLST are not commands to the FTP utility but
    commands in the FTP protocol.

    In the windows FTP utility you use dir and ls.

    dir -> LIST
    ls -> NLST

    Arne

  7. Re: Mozilla (et al.) v. TCPIP FTP server

    In article <1208629068_265@isp.n>, Jeff Campbell writes:
    >
    > NLIST does not work from the command prompt:
    >


    NLIST is not a user interface command, its the RFC command that the
    user interface sends. Generally on UNIX this is caused by the ftp
    client's user interface command "dir".

    However, some clients have techniques that will allow the user to
    enter the RFC level command, try "quote".


+ Reply to Thread