Easily Parsed LIST Format (EPLF) INTERNET-DRAFT draft-bernstein-eplf-00.txt (expires 1 October 1996) This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Status of this memo This memo defines an experimental protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Abstract The File Transfer Protocol (FTP) supports two commands that list files: NLST and LIST. The NLST response is easy to parse but provides very little information. The LIST response provides more information but is not in a standard format. This document defines Easily Parsed LIST Format (EPLF), a format for the LIST response that is usable by humans yet easy for programs to handle. With EPLF it is straightforward for an indexing program to automatically traverse an FTP area, for a mirroring program to avoid downloading the same file twice, or for a browser to display dates in the user's native language. Network Working Group D. Bernstein XXXXXXXXXXXXXXXXXXXX: NNNN IR Category: Experimental 3 April 1996 Easily Parsed LIST Format (EPLF) Status of this memo This memo defines an experimental protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. 1. Introduction The File Transfer Protocol (FTP) supports two commands that list files: NLST and LIST. The NLST response is easy to parse but provides very little information. The LIST response provides more information but is not in a standard format. This document defines Easily Parsed LIST Format (EPLF), a format for the LIST response that is usable by humans yet easy for programs to handle. With EPLF it is straightforward for an indexing program to automatically traverse an FTP area, for a mirroring program to avoid downloading the same file twice, or for a browser to display dates in the user's native language. EPLF also corrects a design flaw in FTP's handling of LIST arguments. An EPLF server must respond to ``LIST filename'' with information about that file and no others, even if that file is a directory. A client that wants an EPLF list of the contents of a directory must first CWD to that directory. A client that merely wants a list of file names in a different directory may use NLST. In this document, a string of 8-bit bytes may be written in two different forms: as a series of hexadecimal numbers between angle brackets, or as a sequence of ASCII characters between double quotes. For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of length 12; it is the same as the string "hello world!". 2. Format An EPLF response to LIST is a series of lines, each line specifying a different file. Each line begins with "+", continues with a series of facts about the file, and ends with <09> followed by the file name. Each fact is zero or more bytes of information, terminated by "," and not containing <09>. Bernstein [Page 1] XXX NNNN Easily Parsed LIST Format April 1996 There are several possible facts, each of which appears at most once, in any order: "r" If this file name is supplied in a RETR command, the RETR should succeed. The server must supply this fact unless it is aware of file type problems, permission problems, or other reasons that RETR will fail. The presence of "r" does not guarantee success: the file may be removed or renamed, or the RETR may suffer a temporary failure. "/" If this file name is supplied in a CWD command, the CWD should succeed. As with "r", the server must supply this fact unless it is aware of reasons that CWD will fail. The presence of "/" does not guarantee success. "i" This file has identifier . is a sequence of bytes not including "," or <09>. If two files on the same FTP server (not necessarily in the same LIST response) have the same , those files have the same contents; a successful RETR of each file should produce the same results, and a successful CWD to each file should lead to the same working directory. (Under UNIX, for example, . could be used as , where and are the device number and inode number of the file.) "s" The size of this file is . is a sequence of ASCII digits specifying a number. If the file is retrieved in TYPE I and is not modified, it will contain exactly bytes. This fact should not be supplied if "r" is not supplied. "m"