rfc2640.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

4. Language Support

   The Character Set Workshop Report [RFC2130] suggests that clients and
   servers SHOULD negotiate a language for "greetings" and "error
   messages". This specification interprets the use of the term  "error
   message", by RFC 2130, to mean any explanatory text string returned
   by server-PI in response to a user-PI command.






Curtin                     Proposed Standard                    [Page 7]

RFC 2640                  FTP Internalization                  July 1999


   Implementers SHOULD note that FTP commands and numeric responses are
   protocol elements. As such, their use is not affected by any guidance
   expressed by this specification.

   Language support of greetings and command responses shall be the
   default language supported by the server or the language supported by
   the server and selected by the client.

   It may be possible to achieve language support through a virtual host
   as described in [MLST]. However, an FTP server might not support
   virtual servers, or virtual servers might be configured to support an
   environment without regard for language. To allow language
   negotiation this specification defines a new LANG command. Clients
   and servers that comply with this specification MUST support the LANG
   command.

4.1 The LANG command

   A new command "LANG" is added to the FTP command set to allow
   server-FTP process to determine in which language to present server
   greetings and the textual part of command responses. The parameter
   associated with the LANG command SHALL be one of the language tags
   defined in RFC 1766 [RFC1766]. If a LANG command without a parameter
   is issued the server's default language will be used.

   Greetings and responses issued prior to language negotiation SHALL be
   in the server's default language. Paragraph 4.5 of [RFC2277] state
   that this "default language MUST be understandable by an English-
   speaking person". This specification RECOMMENDS that the server
   default language be English encoded using ASCII. This text may be
   augmented by text from other languages. Once negotiated, server-PI
   MUST return server messages and textual part of command responses in
   the negotiated language and encoded in UTF-8. Server-PI MAY wish to
   re-send previously issued server messages in the newly negotiated
   language.

   The LANG command only affects presentation of greeting messages and
   explanatory text associated with command responses. No attempt should
   be made by the server to translate protocol elements (FTP commands
   and numeric responses) or data transmitted over the data connection.

   User-PI MAY issue the LANG command at any time during an FTP session.
   In order to gain the full benefit of this command, it SHOULD be
   presented prior to authentication. In general, it will be issued
   after the HOST command [MLST]. Note that the issuance of a HOST or






Curtin                     Proposed Standard                    [Page 8]

RFC 2640                  FTP Internalization                  July 1999


   REIN command [RFC959] will negate the affect of the LANG command.
   User-PI SHOULD be capable of supporting UTF-8 encoding for the
   language negotiated. Guidance on interpretation and rendering of
   UTF-8, defined in section 3, SHALL apply.

   Although NOT REQUIRED by this specification, a user-PI SHOULD issue a
   FEAT command [RFC2389] prior to a LANG command. This will allow the
   user-PI to determine if the server supports the LANG command and
   which language options.

   In order to aid the server in identifying whether a connection has
   been established with a client which conforms to this specification
   or an older client, user-PI MUST send a HOST [MLST] and/or LANG
   command prior to issuing any other command (other than FEAT
   [RFC2389]). If user-PI issues a HOST command, and the server's
   default language is acceptable, it need not issue a LANG command.
   However, if the implementation does not support the HOST command, a
   LANG command MUST be issued. Until server-PI is presented with either
   a HOST or LANG command it SHOULD assume that the user-PI does not
   comply with this specification.

4.2 Syntax of the LANG command

   The LANG command is defined as follows:

   lang-command       = "Lang" [(SP lang-tag)] CRLF
   lang-tag           = Primary-tag *( "-" Sub-tag)
   Primary-tag        = 1*8ALPHA
   Sub-tag            = 1*8ALPHA

   lang-response      = lang-ok / error-response
   lang-ok            = "200" [SP *(%x00..%xFF) ] CRLF
   error-response     = command-unrecognized / bad-argument /
                     not-implemented / unsupported-parameter
   command-unrecognized  = "500" [SP *(%x01..%xFF) ] CRLF
   bad-argument       = "501" [SP *(%x01..%xFF) ] CRLF
   not-implemented    = "502" [SP *(%x01..%xFF) ] CRLF
   unsupported-parameter = "504" [SP *(%x01..%xFF) ] CRLF

   The "lang" command word is case independent and may be specified in
   any character case desired. Therefore "LANG", "lang", "Lang", and
   "lAnG" are equivalent commands.

   The OPTIONAL "Lang-tag" given as a parameter specifies the primary
   language tags and zero or more sub-tags as defined in [RFC1766]. As
   described in [RFC1766] language tags are treated as case insensitive.
   If omitted server-PI MUST use the server's default language.




Curtin                     Proposed Standard                    [Page 9]

RFC 2640                  FTP Internalization                  July 1999


   Server-FTP responds to the "Lang" command with either "lang-ok" or
   "error-response". "lang-ok" MUST be sent if Server-FTP supports the
   "Lang" command and can support some form of the "lang-tag". Support
   SHOULD be as follows:

   - If server-FTP receives "Lang" with no parameters it SHOULD return
     messages and command responses in the server default language.

   - If server-FTP receives "Lang" with only a primary tag argument
     (e.g. en, fr, de, ja, zh, etc.), which it can support, it SHOULD
     return messages and command responses in the language associated
     with that primary tag. It is possible that server-FTP will only
     support the primary tag when combined with a sub-tag (e.g. en-US,
     en-UK, etc.). In such cases, server-FTP MAY determine the
     appropriate variant to use during the session. How server-FTP makes
     that determination is outside the scope of this specification. If
     server-FTP cannot determine if a sub-tag variant is appropriate it
     SHOULD return an "unsupported-parameter" (504) response.

   - If server-FTP receives "Lang" with a primary tag and sub-tag(s)
     argument, which is implemented, it SHOULD return messages and
     command responses in support of the language argument. It is
     possible that server-FTP can support the primary tag of the "Lang"
     argument but not the sub-tag(s). In such cases server-FTP MAY
     return messages and command responses in the most appropriate
     variant of the primary tag that has been implemented. How server-
     FTP makes that determination is outside the scope of this
     specification. If server-FTP cannot determine if a sub-tag variant
     is appropriate it SHOULD return an "unsupported-parameter" (504)
     response.

   For example if client-FTP sends a "LANG en-AU" command and server-FTP
   has implemented language tags en-US and en-UK it may decide that the
   most appropriate language tag is en-UK and return "200 en-AU not
   supported. Language set to en-UK". The numeric response is a protocol
   element and can not be changed. The associated string is for
   illustrative purposes only.

   Clients and servers that conform to this specification MUST support
   the LANG command. Clients SHOULD, however, anticipate receiving a 500
   or 502 command response, in cases where older or non-compliant
   servers do not recognize or have not implemented the "Lang". A 501
   response SHOULD be sent if the argument to the "Lang" command is not
   syntactically correct. A 504 response SHOULD be sent if the "Lang"
   argument, while syntactically correct, is not implemented. As noted
   above, an argument may be considered a lexicon match even though it
   is not an exact syntax match.




Curtin                     Proposed Standard                   [Page 10]

RFC 2640                  FTP Internalization                  July 1999


4.3 Feat response for LANG command

   A server-FTP process that supports the LANG command, and language
   support for messages and command responses, MUST include in the
   response to the FEAT command [RFC2389], a feature line indicating
   that the LANG command is supported and a fact list of the supported
   language tags. A response to a FEAT command SHALL be in the following
   format:

        Lang-feat  = SP "LANG" SP lang-fact CRLF
        lang-fact  = lang-tag ["*"] *(";" lang-tag ["*"])

        lang-tag   = Primary-tag *( "-" Sub-tag)
        Primary-tag= 1*8ALPHA
        Sub-tag    = 1*8ALPHA

   The lang-feat response contains the string "LANG" followed by a
   language fact. This string is not case sensitive, but SHOULD be
   transmitted in upper case, as recommended in [RFC2389]. The initial
   space shown in the Lang-feat response is REQUIRED by the FEAT
   command. It MUST be a single space character. More or less space
   characters are not permitted. The lang-fact SHALL include the lang-
   tags which server-FTP can support. At least one lang-tag MUST be
   included with the FEAT response. The lang-tag SHALL be in the form
   described earlier in this document. The OPTIONAL asterisk, when
   present, SHALL indicate the current lang-tag being used by server-FTP
   for messages and responses.

4.3.1 Feat examples

        C> feat
        S> 211- <any descriptive text>
        S>  ...
        S>  LANG EN*
        S>  ...
        S> 211 end

   In this example server-FTP can only support English, which is the
   current language (as shown by the asterisk) being used by the server
   for messages and command responses.

        C> feat
        S> 211- <any descriptive text>
        S>  ...
        S>  LANG EN*;FR
        S>  ...
        S> 211 end




Curtin                     Proposed Standard                   [Page 11]

RFC 2640                  FTP Internalization                  July 1999


        C> LANG fr
        S> 200 Le response sera changez au francais

        C> feat
        S> 211- <quelconque descriptif texte>
        S>  ...
        S>  LANG EN;FR*
        S>  ...
        S> 211 end

   In this example server-FTP supports both English and French as shown
   by the initial response to the FEAT command. The asterisk indicates
   that English is the current language in use by server-FTP. After a
   LANG command is issued to change the language to French, the FEAT
   response shows French as the current language in use.

   In the above examples ellipses indicate placeholders where other
   features may be included, but are NOT REQUIRED.

5 Security Considerations

   This document addresses the support of character sets beyond 1 byte
   and a new language negotiation command. Conformance to this document
   should not induce a security risk.

6 Acknowledgments

   The following people have contributed to this document:

   D. J. Bernstein
   Martin J. Duerst
   Mark Harris
   Paul Hethmon
   Alun Jones
   Gregory Lundberg
   James Matthews
   Keith Moore
   Sandra O'Donnell
   Benjamin Riefenstahl
   Stephen Tihor

   (and others from the FTPEXT working group)









Curtin                     Proposed Standard                   [Page 12]

RFC 2640                  FTP Internalization                  July 1999


7 Glossary

   BIDI - abbreviation for Bi-directional, a reference to mixed right-
   to-left and left-to-right text.

   Character Set - a collection of characters used to represent textual
   information in which each character has a numeric value

   Code Set -  (see character set).

   Glyph - a character image represented on a display device.

   I18N - "I eighteen N", the first and last letters of the word
   "internationalization" and the eighteen letters in between.

   UCS-2 - the ISO/IEC 10646 two octet Universal Character Set form.

   UCS-4 - the ISO/IEC 10646 four octet Universal Character Set form.

   UTF-8 - the UCS Transformation Format represented in 8 bits.

   TF-16 - A 16-bit format including the BMP (directly encoded) and
   surrogate pairs to represent characters in planes 01-16; equivalent
   to Unicode.

8 Bibliography

   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 2234, November 1997.

   [ASCII]      ANSI X3.4:1986 Coded Character Sets - 7 Bit American
                National Standard Code for Information Interchange (7-
                bit ASCII)

   [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)

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




Curtin                     Proposed Standard                   [Page 13]

RFC 2640                  FTP Internalization                  July 1999


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

   [MLST]       Elz, R. and P. Hethmon, "Extensions to FTP", Work in
                Progress.

   [RFC854]     Postel, J. and J. Reynolds, "Telnet Protocol
                Specification", STD 8, RFC 854, May 1983.

   [RFC959]     Postel, J. and J. Reynolds, "File Transfer Protocol
                (FTP)", STD 9, RFC 959, October 1985.

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

   [RFC1738]    Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
                Resource Locators (URL)", RFC 1738, December 1994.

   [RFC1766]    Alvestrand, H., "Tags for the Identification of
                Languages", RFC 1766, March 1995.

   [RFC2130]    Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,