Network Working Group                                         J. Klensin
Internet-Draft                                             July 28, 2008
Updates: 959 (if approved)
Intended status: Standards Track
Expires: January 29, 2009


                FTP Extension for Internationalized Text
                    draft-klensin-ftp-typeu-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 29, 2009.

Abstract

   The original FTP protocol supported TYPE values for ASCII and EBCDIC
   text, plus binary ("IMAGE") transmission.  As the Internet becomes
   more international, there is a growing requirement to be able to
   transmit textual data, encoded in Unicode, in a way that is
   independent of the coding and line representation forms of particular
   operating systems.  This memo specifies a new FTP TYPE value for
   Unicode data.







Klensin                 Expires January 29, 2009                [Page 1]


Internet-Draft              FTP Unicode TYPE                   July 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Context and Overview  . . . . . . . . . . . . . . . . . . . 3
     1.2.  History of Internationalization of FTP  . . . . . . . . . . 3
     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.4.  Discussion List . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.1.  Existing TYPEs  . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Unicode TYPE  . . . . . . . . . . . . . . . . . . . . . . . 4
     2.3.  Data Structure  . . . . . . . . . . . . . . . . . . . . . . 5
     2.4.  Feature Negotiation . . . . . . . . . . . . . . . . . . . . 5
   3.  Net-Unicode Format for FTP  . . . . . . . . . . . . . . . . . . 5
   4.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8






























Klensin                 Expires January 29, 2009                [Page 2]


Internet-Draft              FTP Unicode TYPE                   July 2008


1.  Introduction

1.1.  Context and Overview

   The original FTP protocol [RFC0959] supported TYPE values for ASCII
   and EBCDIC text, plus binary ("IMAGE") transmission.  The Host
   Requirements specification [RFC1123] made other changes to FTP, but
   did not alter the TYPE environment.

   As the Internet becomes more international, there is a growing
   requirement to be able to transmit textual data, encoded in Unicode
   [Unicode51], in a way that is independent of the coding and line
   representation forms of particular operating systems.  This memo
   specifies a new FTP TYPE value for Unicode data.

1.2.  History of Internationalization of FTP

   RFC 2640 [RFC2640] is described as providing internationalization of
   FTP, but only addresses the use of FTP in internationalized (non-
   ASCII or extended ASCII [ASCII]) file systems.  Its facilities were
   slightly enhanced in a more general extensions specification
   [RFC3659], which builds on a more general FTP extension mechanism
   [RFC2389].  This document addresses the transfer of non-ASCII text
   files only, building on the TYPE command of the original FTP
   specification [RFC0959].

1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document assumes that the reader is familiar with the
   terminology of RFC 959.  Those terms, especially reply, server-FTP
   process, user-FTP process, server-PI, user-PI, logical byte size, and
   user, if used here, are used in the same way.  It also uses the ABNF
   of [RFC2389] and [RFC5234] in preference to the BNF of RFC 959.  For
   the convenience of contemporary readers, the terms "client" and
   "server" are used interchangeably with the historic terms "user-FTP
   process" and "server-FTP process".  The document also assumes the
   termology and changes in the updates to FTP specified in RFC 1123 and
   RFC 2389.

1.4.  Discussion List

   [[anchor6: RFC Editor: please remove this section before
   publication.]]




Klensin                 Expires January 29, 2009                [Page 3]


Internet-Draft              FTP Unicode TYPE                   July 2008


   Until and unless a WG is created, this proposal will be discussed on
   the list apps-discuss@ietf.org


2.  Specification

2.1.  Existing TYPEs

   The FTP TYPE command, described in [RFC0959] accepts four possible
   first argument values, as described below.  Note that these
   descriptions are provided for the reader's convenience; the
   definitions in RFC 959 remain normative.

   TYPE A  The data are expected to be in, and are transformed by the
      server if needed to, an ASCII [ASCII] data stream conforming to
      the "NVT" specification (See RFC 959 [RFC0959] and Appendix B of
      RFC 5198 [RFC5198] for more information).

   E  The data are expected to be in, and are transformed by the server
      if needed to, an EBCDIC data stream as specified in RFC 959.

   I  The data are transferred in "image" form, i.e., exactly as they
      appear in the server.  Because it is the only TYPE form in which
      true binary data can be transferred, TYPE I is often referred to
      as "binary" or "binary transfer".

   L  The data are transmitted in logical bytes of a size specified in
      an additional argument.  See RFC 959.

   Any of these four argument variations to TYPE except "TYPE A" (with
   non-print format) MAY be rejected by the server-FTP process with a
   504 response code if it does not support that type and the necessary
   conversions.

2.2.  Unicode TYPE

   The client-PI MAY transmit TYPE U to the server-PI as an alternative
   to other TYPE commands and arguments.  If it does, the server MAY
   return reply-code 504, indicating that the TYPE U feature is not
   supported (unchanged from RFC 959) or MUST respond to any data
   retrieval request (e.g., GET) by sending the data in a stream
   conformant to the Net-Unicode format specified in Section 3.
   Similarly, if the client-PI sends TYPE U and the server accepts it,
   the client MUST send any data streams in that format while the option
   is in effect.  No second parameter is used or permitted for TYPE U.






Klensin                 Expires January 29, 2009                [Page 4]


Internet-Draft              FTP Unicode TYPE                   July 2008


2.3.  Data Structure

   The default and only permitted data structure for TYPE U is "file
   structure".  Use of the STRU command SHOULD be avoided.  If is used,
   its argument MUST be "F".

2.4.  Feature Negotiation

   RFC 2389 [RFC2389] specifies a feature negotiation mechanism for new
   extensions to FTP.  Since the TYPE command is a required part of the
   base FTP specification, the client-PI is not required to issue the
   FEAT command prior to issuing TYPE U. However, it MAY do so and
   Server-FTP implementations that include TYPE U SHOULD support FEAT as
   described below.  If the FEAT command is transmitted from the
   client-PI to the server-PI, and this extension and FEAT are
   supported, the response MUST include a TYPE line that lists all TYPE
   values supported by the server (including the required ones).  For
   example, if an FTP-server supports all of TYPEs A, E, I, and U, the
   FEAT response line would contain each of the possible arguments
   separated by semicolons, e.g.,

   TYPE A;E;I;U

   This specification does not change either RFC 959 or RFC 2389.  In
   particular, no FEAT response line is required for TYPE unless this,
   or some other, extension to TYPE is supported by the FTP-server.


3.  Net-Unicode Format for FTP

   This section specifies a profile of Net-Unicode [RFC5198] for use
   with FTP TYPE U.

   Unicode characters must be transmitted in UTF-8 as specified in
   [RFC5198].  Because FTP is used in data transmission, the characters
   and sequences that are discouraged in Section 2 of RFC 5198 are
   permitted to be transported by FTP.  However, line-ending sequences
   MUST conform to the CRLF convention specified there.  Consistent with
   Paragraph 4 of that Section, strings SHOULD be normalized before
   transmission if at all possible.

   The implicit logical byte size for this transmission type is eight
   bits.


4.  Acknowledgments

   This document draws heavily on RFC 959; appreciation is expressed to



Klensin                 Expires January 29, 2009                [Page 5]


Internet-Draft              FTP Unicode TYPE                   July 2008


   its authors and to the authors of RFC 2398.  The work of Mark P.
   Peterson and Douglas J. Papenthien on other FTP extensions finally
   motivated production of this document after a long delay; that
   contribution is appreciated as well.


5.  IANA Considerations

   If the FTP extension registry established by a companion document
   [FTPExtReg] is defined, an entry for "TYPE U" that refers to this
   specification should be incorporated in that registry.


6.  Security Considerations

   ...??? ...


7.  References

7.1.  Normative References

   [ASCII]    American National Standards Institute (formerly United
              States of America Standards Institute), "USA Code for
              Information Interchange", ANSI X3.4-1968, 1968.

              ANSI X3.4-1968 has been replaced by newer versions with
              slight modifications, but the 1968 version remains
              definitive for the Internet.

   [FTPExtReg]
              Klensin, J., "FTP Extension Registry", July 2008, <http://
              tools.ietf.org/internet-drafts/
              draft-klensin-ftp-registry>.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 959, October 1985.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2389]  Hethmon, P. and R. Elz, "Feature negotiation mechanism for
              the File Transfer Protocol", RFC 2389, August 1998.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax



Klensin                 Expires January 29, 2009                [Page 6]


Internet-Draft              FTP Unicode TYPE                   July 2008


              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [Unicode51]
              The Unicode Consortium, "The Unicode Standard, Version
              5.1.0", 2008.

              defined by: The Unicode Standard, Version 5.0, Boston, MA,
              Addison-Wesley, 2007, ISBN 0-321-48091-0, as amended by
              Unicode 5.1.0
              (http://www.unicode.org/versions/Unicode5.1.0/).

7.2.  Informative References

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC2640]  Curtin, B., "Internationalization of the File Transfer
              Protocol", RFC 2640, July 1999.

   [RFC3659]  Hethmon, P., "Extensions to FTP", RFC 3659, March 2007.


Author's Address

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA  02140
   USA

   Phone: +1 617 245 1457
   Email: john+ietf@jck.com




















Klensin                 Expires January 29, 2009                [Page 7]


Internet-Draft              FTP Unicode TYPE                   July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Klensin                 Expires January 29, 2009                [Page 8]