[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 2640

FTPEXT Working Group                              B. Curtin
INTERNET DRAFT           Defense Information Systems Agency
Expires 26 May 1997                        26 November 1996


       Internationalization of the File Transfer Protocol
                  <draft-ietf-ftpext-intl-ftp-00.txt>

Status of this Memo

   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. Internet-Drafts may be updated, replaced, or
   obsoleted by other documents at any time.  It is not
   appropriate to use Internet-Drafts as reference material or
   to cite them other than as a "working draft" or "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 ds.internic.net (US
   East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West
   Coast), or munnari.oz.au (Pacific Rim).

   Distribution of this document is unlimited.  Please send
   comments to the FTP Extension working group (FTPEXT-WG) of
   the Internet Engineering Task Force (IETF) at
   <ftp-wg@hops.ag.utk.edu>. Subscription address is
   <ftp-wg-request@hops.ag.utk.edu>. Discussions of the group
   are archived at <URL:ftp://hops.ag.utk.edu/ftp-wg/archives/>.


Abstract

   The File Transfer Protocol, as defined in RFC 959 [RFC959]
   and RFC 1123 Section 4 [RFC1123], is one of the oldest and
   widely used protocols on the Internet. The protocol's primary
   character set, 7 bit ASCII, has served the protocol well
   through the early growth years of the Internet. However, as
   the Internet becomes more global, there is a need to support
   character sets beyond 7 bit ASCII.

   This document addresses the internationalization (I18n) of
   FTP, which includes supporting the multiple character sets
   found throughout the Internet community.  This is achieved
   by extending the FTP specification and giving recommendations
   for proper internationalization support.



                              Expires 26 May 1997            [Page 1]

INTERNET DRAFT    FTP Internationalization 26 November, 1996




Table of Contents


1. INTRODUCTION.................................................3

1.1 SCOPE.......................................................3

2.0 INTERNATIONALIZATION........................................3

2.1 INTERNATIONAL CHARACTER SET.................................3

2.2 TRANSFER ENCODING...........................................4

2.3 TRANSLATIONS................................................6

2.3.1 ISO/IEC 8859-8 EXAMPLE....................................9

2.3.2 VENDOR CODEPAGE EXAMPLE..................................10

3. CONFORMANCE.................................................11

3.1 INTERNATIONAL SERVERS......................................11

3.1.1 SERVER STRATEGIES EXAMPLES...............................12

3.2 INTERNATIONAL CLIENTS......................................12

4.0 SECURITY...................................................13

5.0 ACKNOWLEDGEMENTS...........................................13

BIBLIOGRAPHY...................................................14

AUTHOR'S ADDRESS...............................................15













                              Expires 26 May 1997            [Page 2]

INTERNET DRAFT    FTP Internationalization 26 November, 1996

1.   Introduction

   As the Internet grows throughout the world the requirement to
   support character sets outside of the ASCII / Latin-1
   character set becomes ever more urgent.  For FTP, because of
   the large installed base, it is paramount that this be done
   without breaking existing clients and servers.  This document
   addresses this need. In doing so it defines a solution which
   will still allow the installed base to interoperate with new
   international clients and servers.

1.1  Scope

   This document enhances the capabilities of the File Transfer
   Protocol by defining a Universal Character Set (UCS), a UCS
   transformation format (UTF), and removing the 7-bit
   restrictions on pathnames used in client commands and server
   responses.

2.0  Internationalization

   The File Transfer Protocol was developed in a period when the
   predominate character sets were 7 bit ASCII and 8 bit EBCDIC.
   Today these character sets can not support the wide range of
   characters needed by multinational systems. Given that there
   are a number of character sets in current use that provide
   more characters than 7-bit ASCII, it makes sense to decide on
   a convenient way to represent the union of those
   possibilities. To work globally either requires support of a
   number of character sets and to be able to translate between
   them, or the use of a single preferred character set . To
   assure interoperability this document recommends the latter
   approach and defines a single character set, in addition to
   NVT ASCII and EBCDIC, which is understandable by all systems.
   For FTP this character set will be ISO/IEC 10646:1993 and the
   UTF-8 encoding.  For support of global compatibility it is
   strongly recommended that clients and servers use UTF-8
   encoding when performing operations on filenames. Clients and
   servers are, however, under no obligation to perform any
   translation on the contents of a file for operations such as
   STOR or RETR.

   A more thorough description, beyond what is given in the
   document,  on UTF-8, ISO/IEC 10646, and UNICODE can be found
   in RFC 2044 [RFC2044].

2.1  International Character Set

   The character set defined for international support of FTP
   shall be the Universal Character Set as defined in ISO

                              Expires 26 May 1997            [Page 3]

INTERNET DRAFT    FTP Internationalization 26 November, 1996

   10646:1993 [ISO-10646] as amended. This standard incorporates
   the script and symbol character sets of many existing
   international, national, and corporate standards. ISO/IEC
   10646 defines two alternate forms of encoding, UCS-4 and
   UCS-2. UCS-4 is a four byte (31 bit) encoding containing
   2**31 code positions divided into 128 groups of 256 planes.
   Each plane consists of 256 rows of 256 cells. UCS-2 is a 2
   byte (16 bit) character set consisting of plane zero or the
   Basic Multilingual Plane (BMP).  Currently, no codesets have
   been defined outside of the 2 byte BMP.

   The Unicode standard version 2.0 [UNICODE] is consistent with
   the UCS-2 subset of ISO/IEC 10646. The Unicode standard
   version 2.0 includes the repertoire of IS 10646 characters,
   amendments 1-7 of IS 10646, and editorial and technical
   corrigenda.

     NOTE -- implementers should be aware that ISO 10646 amended
     from time to time; 4 amendments have been adopted since the
     initial 1993 publication, none of which significantly
     affects this specification.  A fifth amendment, now under
     consideration, will introduce incompatible changes to the
     standard: 6556 Korean Hangul syllables allocated between
     code positions 3400 and 4DFF (hexadecimal) will be moved to
     new positions (and 4516 new syllables added), thus making
     references to the old positions invalid.  Since the Unicode
     consortium has already adopted the corresponding amendment
     in Unicode 2.0, adoption of DAM 5 is considered likely and
     implementers should probably consider the old code positions
     as already invalid.  Despite this one-time change, the
     relevant standard bodies have committed themselves not to
     change any allocated code position in the future.  To encode
     Korean Hangul irrespective of these changes, the conjoining
     Hangul Jamo in the range 1110-11F9 can be used.

2.2  Transfer Encoding

   UCS Transformation Format 8 (UTF-8) [UTF-8], also known as
   UTF-2, will be used as a transfer encoding to transmit the
   international character set. UTF-8 is a file safe encoding
   which avoids the use of byte values which have special
   significance during the parsing of file name character
   strings. UTF-8 is an 8 bit encoding of the characters in the
   UCS. Some of UTF-8's benefits are that it is compatible with
   7 bit ASCII, so it doesn't affect programs that give special
   meanings to various ASCII characters; it is immune to
   synchronization errors; and it has enough space to support
   large character sets.

   UTF-8 encoding represents each UCS character as a sequence of

                              Expires 26 May 1997            [Page 4]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

   1 to 6 bytes in length. For all sequences of one byte the
   most significant bit is ZERO. For all sequences of more than
   one byte the number of ONE bits in the first byte, starting
   from the most significant bit position, indicates the number
   of bytes in the UTF-8 sequence followed by a ZERO bit. For
   example, the first byte of a 3 byte UTF-8 sequence would have
   1110 as its most significant bits. Each additional bytes
   (continuing bytes) in the UTF-8 sequence, contain a ONE bit
   followed by a ZERO bit as their most significant bits. The
   remaining free bit positions in the continuing bytes are used
   to identify characters in the UCS. The relationship between
   UCS and UTF-8 is demonstrated in the following table:

   UCS-4 range              UTF-8 byte sequence
   0000 0000-0000 007F      0xxxxxxx
   0000 0080-0000 07FF      110xxxxx 10xxxxxx
   0000 0800-0000 FFFF      1110xxxx 10xxxxxx 10xxxxxx
   0001 0000-001F FFFF      11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   0020 0000-03FF FFFF      111110xx 10xxxxxx 10xxxxxx 10xxxxxx
                            10xxxxxx

   0400 0000-7FFF FFFF      1111110x 10xxxxxx 10xxxxxx 10xxxxxx
                            10xxxxxx 10xxxxxx

   A beneficial property of UTF-8 is that its single byte
   sequence is consistent with the ASCII character set. This
   feature will allow a transition where old ASCII-only clients
   can still interoperate with new servers which support the
   UTF-8 encoding.

   Another feature is that the encoding rules make it very
   unlikely that a character sequence from a different character
   set will be mistaken for a UTF-8 encoded character sequence.
   Clients and servers can use a simple routine to determine if
   the character set being exchanged is a valid UTF-8:

   int utf8_valid(const unsigned char *buf, unsigned int len)
   {
     const unsigned char *endbuf = buf + len;
     int trailing = 0;    /* trailing (continuation) bytes to
   follow */

     while (buf != endbuf)
     {
          unsigned char c = *buf++;
          if (trailing)
               if      ((c&0xC0) == 0x80)  trailing--;
               else                        return 0;
          else


                              Expires 26 May 1997            [Page 5]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

               if      ((c&0x80) == 0x00)  continue;
               else if ((c&0xE0) == 0xC0)  trailing = 1;
               else if ((c&0xF0) == 0xE0)  trailing = 2;
               else if ((c&0xF8) == 0xF0)  trailing = 3;
               else if ((c&0xFC) == 0xF8)  trailing = 4;
               else if ((c&0xFE) == 0xFC)  trailing = 5;
               else                        return 0;
     }
     return trailing == 0;
   }

2.3  Translations

   Translation from the local filesystem character set to UTF-8
   will normally involve a two step process. First translate the
   local character set to the UCS; then translate the UCS to
   UTF-8.

   The first step in the process can be performed by maintaining
   a translation table which includes the local character set
   code and the corresponding UCS code. For instance the ISO/IEC
   8859-8 [ISO-8859] code for the Hebrew letter "VAV" is 0xE4.
   The corresponding 4 byte ISO/IEC 10646 code is 0x000005D5.

   The next step is to translate the UCS character code to the
   UTF-8 encoding. The following routine can be used to
   determine and encode the correct number of bytes based on the
   UCS-4 character code:

   int ucs4_to_utf8 (unsigned long *ucs4_buf, unsigned int ucs4_len,
                  unsigned char *utf8_buf)
   {
     const unsigned long *ucs4_endbuf = ucs4_buf + ucs4_len;
     unsigned long ucs4_ch;

     while (ucs4_buf != ucs4_endbuf)
       {
         ucs4_ch = *ucs4_buf;
         if ( ucs4_ch <= 0x7FUL)  /* ASCII chars no conversion needed */
           *utf8_buf++ = (unsigned char) ucs4_ch;
         else
           if ( ucs4_ch <= 0x07FFUL ) /* In the 2 byte utf-8 range */
             {
               *utf8_buf++= (unsigned char) (0xC0UL + (ucs4_buf/0x40UL));
               *utf8_buf++= (unsigned char) (0x80UL + (ucs4_buf%0x40UL));
             }
           else
             if ( ucs4_ch <= 0xFFFFUL ) /* In the 3 byte utf-8 range.
                                           The values 0x0000FFFE,
                                           0x0000FFFF and

                              Expires 26 May 1997            [Page 6]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

                                           0x0000D800 - 0x0000DFFF do
                                           not occur in UCS-4 */
              {
                *utf8_buf++=
                  (unsigned char) (0xE0UL + (ucs4_buf/0x1000UL));
                *utf8_buf++= (unsigned char) (0x80UL
                             + ((ucs4_buf/0x40UL)%0x40UL));
                *utf8_buf++= (unsigned char) (0x80UL +
                                              (ucs4_buf%0x40UL));
              }
             else
               if ( ucs4_ch <= 0x1FFFFFUL ) /* In the 4 byte
                 {                             utf-8 range */
                   *utf8_buf++= (unsigned char) (0xF0UL +
                                (ucs4_buf/0x040000UL));
                   *utf8_buf++= (unsigned char) (0x80UL
                                 + ((ucs4_buf/0x10000)%0x40UL));
                   *utf8_buf++= (unsigned char) (0x80UL
                                 + ((ucs4_buf/0x40UL)%0x40UL));
                   *utf8_buf++= (unsigned char) (0x80UL +
                                (ucs4_buf%0x40UL));
                 }
               else
                 if ( ucs4_ch <= 0x03FFFFFFUL ) /* In the 5 byte
                   {                               utf-8 range */
                     *utf8_buf++= (unsigned char) (0xF8UL
                                   +(ucs4_buf/0x01000000UL));
                     *utf8_buf++= (unsigned char) (0x80UL
                                   + ((ucs4_buf/0x040000UL)%0x40UL));
                     *utf8_buf++= (unsigned char) (0x80UL
                                   + ((ucs4_buf/0x1000UL)%0x40UL));
                     *utf8_buf++= (unsigned char) (0x80UL
                                   + ((ucs4_buf/0x40UL)%0x40UL));
                     *utf8_buf++= (unsigned char) (0x80UL +
                                  (ucs4_buf%0x40UL));
                   }
                 else
                   if ( ucs4_ch <= 0x7FFFFFFFUL ) /* In the 6 byte
                     {                               utf-8 range */
                       *utf8_buf++= (unsigned char) (0xF8UL
                                    +(ucs4_buf/0x40000000UL));
                       *utf8_buf++= (unsigned char) (0x80UL
                                  + ((ucs4_buf/0x01000000UL)%0x40UL));
                       *utf8_buf++= (unsigned char) (0x80UL
                                    + ((ucs4_buf/0x040000UL)%0x40UL));
                       *utf8_buf++= (unsigned char) (0x80UL
                                    + ((ucs4_buf/0x1000UL)%0x40UL));
                       *utf8_buf++= (unsigned char) (0x80UL
                                    + ((ucs4_buf/0x40UL)%0x40UL));
                       *utf8_buf++= (unsigned char) (0x80UL

                              Expires 26 May 1997            [Page 7]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

                                    + (ucs4_buf%0x40UL));
                    }
       }
   }

   When moving from UTF-8 encoding to the local character set
   the reverse procedure is used. First the UTF-8 encoding is
   transformed into the UCS-4 character set. The UCS-4 is then
   converted to the local character set from a translation table
   (i.e. the opposite of the table used to form the UCS-4
   character code).

   To convert from UTF-8 to UCS-4 the free bits (those that do
   not define UTF-8 sequence size or signify continuation bytes)
   in a UTF-8 sequence are concatenated as a bit string. The
   bits are then distributed into a four byte sequence starting
   from the least significant bits. Those bits not assigned a
   bit in the four byte sequence are padded with ZERO bits. The
   following routine converts the UTF-8 encoding to UCS-4
   character codes:

   int utf8_to_ucs4 (unsigned long *ucs4_buf, unsigned int utf8_len,
                     unsigned char *utf8_buf)
   {
   const unsigned char *utf8_endbuf = utf8_buf + utf8_len;

   while (utf8_buf != utf8_endbuf)
     {
       if ((*utf8_buf & 0x80) == 0x00)  /* ASCII chars no conversion
         {                                 needed */
           *ucs4_buf++ = (unsigned long) *utf8_buf;
           utf8_buf++;
         }
       else
         if ((*utf8_buf & 0xE0)== 0xC0) /* In the 2 byte utf-8
           {                               range */
             *ucs4_buf++ = (unsigned long) ((*utf8_buf - 0xC0) * 0x40)
                           + ( *(utf_buf+1) - 0x80));
             utf8_buf += 2;
           }
         else
           if ( (*utf8_buf & 0xF0) == 0xE0 ) /* In the 3 byte utf-8
             {                                  range */
               *ucs4_buf++ = (unsigned long) (((*utf8_buf - 0xE0)
                             * 0x1000) + (( *(utf8_buf+1) -  0x80)
                             * 0x40) + ( *(utf_buf+2) - 0x80));
               utf8_buf += 3;
             }
          else
            if ((*utf8_buf & 0xF8) == 0xF0) /* In the 4 byte utf-8

                              Expires 26 May 1997            [Page 8]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

              {                                range */
                *ucs4_buf++ = (unsigned long) (((*utf8_buf - 0xF0)
                              * 0x040000) + (( *(utf8_buf+1) -  0x80)
                              * 0x1000) + (( *(utf8_buf+2) -  0x80)
                              * 0x40) + ( *(utf_buf+3) - 0x80));
                utf8_buf += 4;
              }
            else
              if ((*utf8_buf & 0xFC) == 0xF8) /* In the 5 byte utf-8
                {                                range */
                  *ucs4_buf++ = (unsigned long) (((*utf8_buf - 0xF8)
                                * 0x01000000) + ((*(utf8_buf+1) - 0x80)
                                * 0x040000) + (( *(utf8_buf+2) -  0x80)
                                * 0x1000)
                                + (( *(utf8_buf+3) -  0x80) * 0x40)
                                + ( *(utf_buf+4) - 0x80));
                  utf8_buf+=5;
                }
              else
                if ((*utf8_buf & 0xFE) == 0xFC) /* In the 6 byte utf-8
                  {                                range */
                    *ucs4_buf++ = (unsigned long) (((*utf8_buf - 0xFC)
                                  * 0x40000000) + ((*(utf8_buf+1)
                                  - 0x80) * 0x010000000)
                                  + ((*(utf8_buf+2) - 0x80) * 0x040000)
                                  + (( *(utf8_buf+3) -  0x80) * 0x1000)
                                  + (( *(utf8_buf+4) -  0x80) * 0x40)
                                  + ( *(utf_buf+5) - 0x80));
                    utf8_buf+=6;
                 }
     }
   }

2.3.1     ISO/IEC 8859-8 Example

   This example demonstrates mapping ISO/IEC 8859-8 character
   set to UTF-8 and back to ISO/IEC 8859-8. As noted earlier,
   the Hebrew letter "VAV" is translated from the ISO/IEC 8859-8
   character code 0xE4 to the corresponding 4 byte ISO/IEC 10646
   code of 0x000005D5 by a simple lookup of a
   translation/mapping file.

   The UCS-4 character code is transformed into UTF-8 using the
   ucs4_to_utf8 routine described earlier by:

     1. Because the UCS-4 character is between 0x80 and 0x07FF it
        will map to a 2 byte UTF-8 sequence.
     2. The first byte is defined by (0xC0 + (0x000005D5 / 0x40))
        = 0xD7.
     3. The second byte is defined by (0x80 + (0x000005D5 %

                              Expires 26 May 1997            [Page 9]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

        0x40)) = 0x95.

   The UTF-8 encoding is transferred back to UCS-4 by using the
   utf8_to_ucs4 routine described earlier by:

     1. Because the first byte of the sequence, when the '&'
        operator with a value of 0xE0 is applied, will produce
        0xC0 (0xD7 & 0xE0 = 0xC0) the UTF-8 is a 2 byte sequence.
     2.  The four byte UCS-4 character code is produced by
        (((0xD7 - 0xC0) * 0x40) + (0x95 -0x80)) = 0x000005D5.

   Finally, the UCS-4 character code is translated to ISO/IEC
   8859-8  character code (using the translation table which
   matches ISO/IEC 8859-8 to UCS-4 ) to produce the original
   0xE4 code for the Hebrew letter "VAV".

2.3.2     Vendor Codepage Example

   This example demonstrates the mapping of a codepage to UTF-8
   and back to a vendor codepage. Mapping between vendor
   codepages can be done in a very similar manner as described
   above. For instance both the PC and Mac codepages reflect the
   character set from the Thai standard TIS 620-2533. The
   character code on both platforms for the Thai letter "SO SO"
   is 0xAB. This character can then be mapped into the UCS-4 by
   way of a translation/mapping file to produce the UCS-4 code
   of 0x0E0B.

   The UCS-4 character code is transformed into UTF-8 using the
   ucs4_to_utf8 routine described earlier by:

     1. Because the UCS-4 character is between 0x0800 and 0xFFFF
        it will map to a 3 byte UTF-8 sequence.
     2. The first byte is defined by (0xE0 + (0x00000E0B /
        0x1000) =  0x00.
     3. The second byte is defined by (0x80 + ((0x00000E0B /
        0x40) % 0x40))) = 0xB8.
     4. The third byte is defined by (0x80 + (0x00000E0B % 0x40))
        = 0x8B.

   The UTF-8 encoding is transferred back to UCS-4 by using the
   utf8_to_ucs4 routine described earlier by:

     1. Because the first byte of the sequence, when the '&'
        operator with a value of 0xF0 is applied, will produce
        0xE0 (0xE0 & 0xF0 = 0xE0) the UTF-8 is a 3 byte sequence.
     2.  The four byte UCS-4 character code is produced by
        (((0xE0 - 0xE0) * 0x1000) + ((0xB8 - 0x80) * 0x40) +
        (0x8B -0x80) = 0x0000E0B.


                              Expires 26 May 1997           [Page 10]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

   Finally, the UCS-4 character code is translated to either the
   PC or MAC codepage character code (using the translation
   table which matches codepage to UCS-4 ) to produce the
   original 0xAB code for the Thai letter "SO SO".

3.   Conformance

   File names are sequences of bytes.  The character set of
   names that are valid UTF-8 sequences is UTF-8.  The character
   set of other names is undefined.

   Conforming internationalized client and servers must either
   support UTF-8 or support a local character set which is
   supported by both the client and server. Clients and servers,
   unless otherwise configured to support a specific native
   character set, should check for a valid UTF-8 byte sequence
   to determine if the pathname being presented is UTF-8.

3.1  International Servers

   The 7-bit restriction on pathnames used in server responses
   is dropped.

   If servers and clients are not configured to share the same
   character set, servers should use UTF-8 encoding for all
   pathname transfers.

   There are several plausible UTF-8 server implementation
   strategies:

   - A server that copies filenames transparently from a local
   filesystem may continue to do so. It is then up to the local
   file creators to use UTF-8 filenames.

   -A  server may translate filenames from a local character set
   to UTF-8. Each filename will be translated to UTF-8 before it
   is sent to the client.

   - UTF-8 Filenames received from the client must be translated
   back if possible. Many existing servers interpret 8-bit
   filenames as being in the local character set. They may
   continue to do so for filenames that are not valid UTF-8.

   A high-quality translating server will use the following
   procedure:

      If fn is valid UTF-8 and can be translated to the local
      character set:
        Translate fn to the local character set, obtaining
        localfn.

                              Expires 26 May 1997           [Page 11]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996
        Attempt to operate on localfn.
          Upon success: Stop.
          Upon temporary error: Return an error message to the
        client.
            Stop.
        Attempt to operate on fn.
          Upon temporary error: Return an error message to the
          client.
          Stop.
      Otherwise:
        Attempt to operate on fn.
        Upon temporary error: Return an error message to the
        client.
        Stop.

3.1.1 Server Strategies Examples

   There are a number of server strategies which might be
   employed:

   - Server's OS uses one fixed character set.  In this case,
   the server should easily be able to support built-in
   translation to UTF-8. This is trivial where that fixed
   character set is ASCII, ISO 8859/1, or UTF-8.

    - Server supports charset labeling of files and/or
   directories, such that different file names may have
   different charsets. The server should attempt to translate
   all file names to UTF-8, but if it can't then it should leave
   that name in its raw form.

    - Server's OS does not mandate the character set, but the
   administrator configures it in the FTP server. The server
   should be configured to use a particular translation table.
   (Maybe external, but the server might have some common
   choices built-in.)  This also allows the flexibility of
   defining different charsets for different directories.

   - Server's OS does not mandate the character set and it is
   not configured. The server should simply use the raw bytes in
   the file name.  They might be ASCII or UTF-8.

   - Server is a mirror, and wants to look just like the site it
   is mirroring. It should save the exact file name bytes that
   it received from the main server.

3.2  International Clients

   The 7-bit restriction on pathnames used by client commands is
   dropped.


                              Expires 26 May 1997           [Page 12]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

   While clients are not obligated to support all of the
   characters or the associated glyphs defined in the UCS,
   clients which are presented UTF-8 filenames by the server
   should parse UTF-8 correctly, and attempt to display the
   filename within the limitation of the resources available.
   Unknown UTF-8 glyphs might be displayed as question marks, or
   hex, or something else. This is a quality-of-implementation
   issue.

   Client developers should be aware that it will be possible
   for pathnames to contain mixed characters (e.g.
   /Latin1DirectoryName/HebrewFileName). They should be prepared
   to handle the Bi-directional (BIDI) display of these
   character sets (i.e. right to left display for the directory
   and left to right display for the filename).

   Character semantics of other names shall remain undefined. If
   a client detects that a server is non-UTF-8, it should change
   its display appropriately. How a client implementation
   handles non UTF-8 is a quality of implementation issue. It
   may try to assume some other encoding, give the user a chance
   to try to assume something, or save encoding assumptions for
   a server from one FTP session to another.

   Client implementation notes: Many existing clients interpret
   8-bit filenames as being in the local character set. They may
   continue to do so for filenames that are not valid UTF-8.

4.0  Security

   This document addresses the support of character sets beyond
   1 byte. Conformance to this document should not induce a
   security threat.

5.0 Acknowledgements

   The following people have contributed to this document:

   Alex Belits
   D. J. Berstein
   Martin J. Duerst
   Mark Harris
   Paul Hethmon
   Alun Jones
   James Matthews
   Keith Moore
   Benjamin Riefenstahl

   (and others from the FTPEXT working group)


                              Expires 26 May 1997           [Page 13]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

Bibliography

[ISO-8859]

        ISO 8859.  International standard -- Information
        processing -- 8-bit single-byte coded graphic character
        sets -- Part 1: Latin alphabet No. 1 (1987) -- Part 2:
        Latin alphabet No. 2 (1987) -- Part 3: Latin alphabet
        No. 3 (1988) -- Part 4: Latin alphabet No. 4 (1988) --
        Part 5: Latin/Cyrillic alphabet (1988) -- Part 6:
        Latin/Arabic alphabet (1987) -- Part : Latin/Greek
        alphabet (1987) -- Part 8: Latin/Hebrew alphabet (1988)
        -- Part 9: Latin alphabet No. 5 (1989) -- Part10: Latin
        alphabet No. 6 (1992)

[ISO-10646]

        ISO/IEC 10646-1:1993. International standard --
        Information technology -- Universal multiple-octet coded
        character set (UCS) -- Part 1: Architecture and basic
        multilingual plane.

[RFC959]

        J. Postel, J Reynolds, "File Transfer Protocol (FTP)",
        RFC 959, October 1985.

[RFC1123]

        R. Braden, "Requirements for Internet Hosts --
        Application and Support", RFC 1123, October 1989.

[RFC2044]

        F. Yergeau, "UTF-8, a transformation format of Unicode
        and ISO 10646", RFC 2044, October 1996.

[UNICODE]

        The Unicode Consortium, "The Unicode Standard - Version
        2.0", Addison Westley Developers Press, July 1996.

[UTF-8]

        ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS
        Transformation Format 8 (UTF-8).





                              Expires 26 May 1997           [Page 14]

          INTERNET DRAFT    FTP Internationalization 26 November, 1996

Author's Address

JIEO
Attn JEBBD (Bill Curtin)
Ft. Monmouth, N.J.
          07703-5613

curtinw@ftm.disa.mil











































                              Expires 26 May 1997           [Page 15]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/