W3C home > Mailing lists > Public > uri@w3.org > April 2002

Re: URI schemes used in vim: rcp://, scp://

From: Jimmy Cerra <jimbofc@yahoo.com>
Date: Wed, 24 Apr 2002 20:00:48 -0400
To: <uri@w3.org>
Message-ID: <000101c1ebec$44f57230$0100a8c0@locutus>
I'm no expert, but the document RFC 2718 (http://www.ietf.org/rfc/rfc2718.txt)
recommends that:

2.1.2 Improper use of "//" following "<scheme>:"
   Contrary to some examples set in past years, the use of double
   slashes as the first component of the <scheme-specific-part> of a URL
   is not simply an artistic indicator that what follows is a URL:
   Double slashes are used ONLY when the syntax of the URL's <scheme-
   specific-part> contains a hierarchical structure as described in RFC
   2396.  In URLs from such schemes, the use of double slashes indicates
   that what follows is the top hierarchical element for a naming
   authority.  (See section 3 of RFC 2396 for more details.)  URL
   schemes which do not contain a conformant hierarchical structure in
   their <scheme-specific-part> should not use double slashes following
   the "<scheme>:" string.

I think that the use of double slashes in "scp://machine//path" is improper,
according to the above suggestion.
Jimmy Cerra

Original Message:
Date: Tue, 23 Apr 2002 00:28:34 -0400
From: Gerald Oskoboiny <gerald@w3.org>
To: uri@w3.org
Message-ID: <20020423042834.GA2043@w3.org>
Subject: URI schemes used in vim: rcp://, scp://

I found some new-to-me URI schemes today (rcp: and scp:),
used in the vim text editor:


which is quoted in part below.

This strikes me as strange:

    For an absolute path use scp://machine//path.

(double-slash is required after hostname to specify an absolute path)
but I'm not sure if that violates any existing URI specs.

>                           Vim documentation: pi_netrw
>    main help file
>      _________________________________________________________________
> *pi_netrw.txt*  For Vim version 6.0.  Last change: 2001 Sep 17
>                   VIM REFERENCE MANUAL    by Charles E. Campbell, Jr.
> 1. Network-Oriented File Transfer                       *netrw-xfer*
> Network-oriented file transfer under Vim is implemented by a VimL-based script
> (<netrw.vim>) using plugin techniques.  It currently supports both reading
> and writing across networks using rcp, scp, ftp, or ftp+<.netrc> as
> appropriate.  http is currently supported read-only.
> For rcp, scp, and http, one can use network-oriented file transfer
> transparently:
>         vim rcp://machine/path
>         vim scp://machine/path
>       Reading                      Writing                        Uses
>       ------------------------     ---------------------------    ----------
>     * rcp://machine/path         * rcp://machine/path             rcp
>       :Nread rcp://machine/path    :Nwrite rcp://machine/path     rcp
>     * scp://machine/path         * scp://machine/path             scp
>       :Nread scp://machine/path    :Nwrite scp://machine/path     scp (**)
>     * ftp://machine/path         * ftp://machine/path             ftp
>  :Nread ftp://machine/path :Nwrite  ftp://machine/path ftp+***
>       :Nread machine path          :Nwrite machine path           ftp+.netrc
>       :Nread machine uid pass path :Nwrite machine uid pass path  ftp
>       (for ftp, "machine" may be machine#port if a different port is needed
>       than the standard ftp port)
>     * http://machine/path                                         wget
>  :Nread http://machine/path wget
>         (*) transparent file transfer: i.e. vim rcp://machine/path
>  :r     ftp://machine/path
>  :w     ftp://machine/path
>         (**) For an absolute path use scp://machine//path.
>         (***) if <.netrc> is present, it is assumed that it will
>              work with your ftp client.  Otherwise the script will
>              prompt for user-id and pasword.

Gerald Oskoboiny     http://www.w3.org/People/Gerald/
World Wide Web Consortium (W3C)    http://www.w3.org/
tel:+1-613-261-6630             mailto:gerald@w3.org
Received on Wednesday, 24 April 2002 20:01:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:04 UTC