RFC 2484

PPP LCP Internationalization Configuration Option

📅 published January 1999, from ietf

RFC 2484 🎀 PPP LCP Internationalization Configuration Option

okay bestie, this one is Standards Track 💅 and it was written by Glen Zorn of Microsoft Corporation in January 1999 🌸. It's giving "PPP upgrade for speaking more languages." It updates RFCs 2284, 1994, and 1570 ✨, and it doesn't obsolete anything. Let's get into it 🦋

Status of This Memo ⭐

this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

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

1. Abstract ✨

okay so PPP [1] is the standard way to carry multi-protocol datagrams over point-to-point links 💖. It also has an extensible Link Control Protocol (LCP), which lets the two ends negotiate an Authentication Protocol to check who's on the other side before any Network Layer protocols are allowed to send stuff over the link 🔥.

Both LCP and Authentication Protocol packets can hold text meant for humans to read [2,3,4]. This document adds an LCP configuration option for negotiating the character set and language, as required by RFC 2277 [5] 🎀.

2. Specification of Requirements 🫶

in this doc, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are read the way [6] describes 💅.

3. Additional LCP Configuration Option 🧚

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

the LCP Option Type field values are kept up to date in STD 2 [7] 📋. this document is about this value:

28  Internationalization

the Internationalization option is giving independence 🦋. it MAY be negotiated independently in each direction.

only one instance of this option SHOULD be sent by an implementation, and it should represent its preferred language and charset 💜.

if the peer rejects the Internationalization option, the default language and charset MUST be used to build all human-readable messages sent to that peer 🙈.

4.1. Internationalization 🌸

Description

this Configuration Option lets an implementation tell its peer two things: the language its human-readable messages should be written in, and the charset that language should be shown in 🍓.

here's the format summary. the fields go 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

the Type is 28 🎀.

Length

the Length is >= 7 📏.

MIBenum

the MIBenum field is four octets long, and it holds a unique integer that identifies a charset [5,11] 💖.

this value MUST represent one of the charsets listed in the IANA charset registry [7]. no other charsets allowed, bestie 🙅‍♀️.

the charset registration procedure is in RFC 2278 [9] 📚.

the default charset is UTF-8 [10], and its MIBenum value is 106 👑.

Language-Tag

the Language-Tag field is an ASCII string holding a language tag, as defined in RFC 1766 [8] 🌈.

language tags are case-insensitive in principle 🙃. capitalization doesn't mean anything, so implementations SHOULD send only lower-case Tag fields ✨.

the default Tag value is "i-default" [8] 💅.

4. References 📚

  • [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
  • [3] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
  • [4] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
  • [5] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
  • [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [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.
  • [9] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998.
  • [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
  • [11] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.

5. Security Considerations 🙈

it's possible that an attacker could mess with this option so the messages a reader sees become totally unintelligible 💀. that's a real risk, so keep your guard up 🔥.

6. Acknowledgements 🫶

big thanks to these legends for their helpful suggestions and feedback 💖: 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) 👑.

7. Chair's Address 🧚

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

Phone: +1 614 326 6841
EMail: karl@ascend.com

8. Author's Address 🎀

Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052

Phone: +1 425 703 1559
Fax:   +1 425 936 7329
EMail: glennz@microsoft.com

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

okay so this doc and its translations can be copied and handed out to anyone 🌈, and you can make derivative works that comment on or explain it, or that help people implement it. those can be prepared, copied, published, and distributed, in whole or in part, with no restrictions 💅. the one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work ✨.

the document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️. the exceptions are when you need it to develop Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when you translate it into a language other than English 🌸.

the permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns 💖.

this document and the info in it are provided "AS IS", 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 😭.

📦 where this page comes from