Network Working Group                                            G. Zorn
Request for Comments: 2484                         Microsoft Corporation
Category: Standards Track                                   January 1999
Updates: 2284, 1994, 1570
        
Network Working Group                                            G. Zorn
Request for Comments: 2484                         Microsoft Corporation
Category: Standards Track                                   January 1999
Updates: 2284, 1994, 1570
        

PPP LCP Internationalization Configuration Option

PPP LCP国际化配置选项

Status of this Memo

本备忘录的状况

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (1999). All Rights Reserved.

版权所有(C)互联网协会(1999年)。版权所有。

1. Abstract
1. 摘要

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.

点到点协议(PPP)[1]提供了通过点到点链路传输多协议数据报的标准方法。PPP还定义了一个可扩展链路控制协议(LCP),该协议允许在允许网络层协议通过链路传输之前协商身份验证协议以对其对等方进行身份验证。

Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable [2,3,4]. This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277 [5].

LCP和认证协议数据包都可能包含人类可读的文本[2,3,4]。根据RFC 2277[5]的要求,本文件定义了一个LCP配置选项,用于协商字符集和语言使用。

2. Specification of Requirements
2. 需求说明

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [6].

在本文件中,关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[6]所述。

3. Additional LCP Configuration Option
3. 附加LCP配置选项

The Configuration Option format and basic options are already defined for LCP [1].

已为LCP[1]定义了配置选项格式和基本选项。

Up-to-date values of the LCP Option Type field are specified in STD 2 [7]. This document concerns the following value:

STD 2[7]中规定了LCP选项类型字段的最新值。本文件涉及以下价值:

28 Internationalization

28国际化

The Internationalization option described here MAY be negotiated independently in each direction.

这里描述的国际化选项可以在每个方向上单独协商。

Only one instance of this option SHOULD be sent by an implementation, representing its preferred language and charset.

实现只应发送此选项的一个实例,表示其首选语言和字符集。

If Internationalization option is rejected by the peer, the default language and charset MUST be used to construct all human-readable messages sent to the peer.

如果对等方拒绝国际化选项,则必须使用默认语言和字符集来构造发送给对等方的所有人类可读消息。

4.1. Internationalization
4.1. 国际化

Description

描述

This Configuration Option provides a method for an implementation to indicate to the peer both the language in which human-readable messages it sends should be composed and the charset in which that language should be represented.

此配置选项为实现提供了一种方法,用于向对等方指示其发送的人类可读消息应使用的语言以及该语言应使用的字符集。

A summary of the Internationalization option format is shown below. The fields are transmitted from left to right.

国际化选项格式的摘要如下所示。字段从左向右传输。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          MIBenum
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             MIBenum (cont)        |        Language-Tag...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          MIBenum
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             MIBenum (cont)        |        Language-Tag...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type

类型

28

28

Length

>= 7

>= 7

MIBenum

MIBenum

The MIBenum field is four octets in length. It contains a unique integer value identifying a charset [5,11].

MIBenum字段的长度为四个八位字节。它包含标识字符集的唯一整数值[5,11]。

This value MUST represent one of the set of charsets listed in the IANA charset registry [7].

此值必须表示IANA字符集注册表中列出的字符集之一[7]。

The charset registration procedure is described in RFC 2278 [9].

RFC 2278[9]中描述了字符集注册过程。

The default charset value is UTF-8 [10]. The MIBenum value for the UTF-8 charset is 106.

默认字符集值为UTF-8[10]。UTF-8字符集的MIBenum值为106。

Language-Tag

语言标签

The Language-Tag field is an ASCII string which contains a language tag, as defined in RFC 1766 [8].

语言标记字段是一个ASCII字符串,包含RFC 1766[8]中定义的语言标记。

Language tags are in principle case-insensitive; however, since the capitalization of a tag does not carry any meaning, implementations SHOULD send only lower-case Tag fields.

语言标记原则上不区分大小写;然而,由于标记的大小写没有任何意义,实现应该只发送小写的标记字段。

The default Tag value is "i-default" [8].

默认标记值为“i-default”[8]。

4. References
4. 工具书类

[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[1] 辛普森,W.,“点对点协议(PPP)”,STD 51,RFC 1661994年7月。

[2] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[2] 辛普森,W.,“PPP挑战握手认证协议(CHAP)”,RFC 1994,1996年8月。

[3] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.

[3] 辛普森W.,“PPP LCP扩展”,RFC 15701994年1月。

[4] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.

[4] Blunk,L.和J.Vollbrecht,“PPP可扩展认证协议(EAP)”,RFC 2284,1998年3月。

[5] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

[5] Alvestrand,H.,“IETF字符集和语言政策”,BCP 18,RFC 2277,1998年1月。

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

[6] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

   [7]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.  See also: http://www.iana.org/numbers.html
        
   [7]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.  See also: http://www.iana.org/numbers.html
        

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

[8] Alvestrand,H.,“语言识别标签”,RFC1766,1995年3月。

[9] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998.

[9] Freed,N.和J.Postel,“IANA字符集注册程序”,BCP 19,RFC 2278,1998年1月。

[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.

[10] “UTF-8,ISO 10646的转换格式”,RFC 2279,1998年1月。

[11] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.

[11] 史密斯,R.,赖特,F.,黑斯廷斯,T.,齐尔斯,S.和J.吉伦斯科,“打印机MIB”,RFC 1759,1995年3月。

5. Security Considerations
5. 安全考虑

It is possible that an attacker might manipulate the option in such a way that displayable messages would be unintelligible to the reader.

攻击者可能会以读者无法理解可显示消息的方式操纵该选项。

6. Acknowledgements
6. 致谢

Thanks to Craig Fox (fox@cisco.com), James Carlson (carlson@ironbridgenetworks.com), Harald Alvestrand (Harald.Alvestrand@maxware.no), Kevin Smith (kevin@ascend.com), Karl Fox (karl@ascend.com), Thomas Narten (narten@raleigh.ibm.com) and Narendra Gidwani (nareng@microsoft.com) for helpful suggestions and feedback.

多亏了克雷格·福克斯(fox@cisco.com),詹姆斯·卡尔森(carlson@ironbridgenetworks.com),Harald Alvestrand(Harald。Alvestrand@maxware.no),凯文·史密斯(kevin@ascend.com),卡尔·福克斯(karl@ascend.com),托马斯·纳顿(narten@raleigh.ibm.com)还有纳伦德拉·吉德瓦尼(nareng@microsoft.com)获取有用的建议和反馈。

7. Chair's Address
7. 主席致辞

Karl Fox Ascend Communications 3518 Riverside Drive Suite 101 Columbus, OH 43221

卡尔·福克斯艾森德通讯公司3518河畔大道101号套房,俄亥俄州哥伦布市,邮编43221

   Phone: +1 614 326 6841
   EMail: karl@ascend.com
        
   Phone: +1 614 326 6841
   EMail: karl@ascend.com
        
8. Author's Address
8. 作者地址

Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052

格伦·佐恩微软公司华盛顿州雷德蒙微软大道一号,邮编:98052

   Phone: +1 425 703 1559
   Fax:   +1 425 936 7329
   EMail: glennz@microsoft.com
        
   Phone: +1 425 703 1559
   Fax:   +1 425 936 7329
   EMail: glennz@microsoft.com
        
9. Full Copyright Statement
9. 完整版权声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

版权所有(C)互联网协会(1999年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。