idnits 2.17.1 draft-ietf-pppext-lcp-charset-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([5], [2,3,4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 60: '...ption described here MAY be negotiated...' RFC 2119 keyword, line 63: '...e of this option SHOULD be sent by an ...' RFC 2119 keyword, line 67: '...uage and charset MUST be used to const...' RFC 2119 keyword, line 102: '... This value MUST represent one of...' RFC 2119 keyword, line 117: '... implementations SHOULD send only lowe...' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1994, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1570, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC1570, updated by this document, for RFC5378 checks: 1994-01-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Novenber 1998) is 9626 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 123 looks like a reference -- Missing reference section? '2' on line 126 looks like a reference -- Missing reference section? '3' on line 129 looks like a reference -- Missing reference section? '4' on line 131 looks like a reference -- Missing reference section? '5' on line 134 looks like a reference -- Missing reference section? '6' on line 137 looks like a reference -- Missing reference section? '7' on line 140 looks like a reference -- Missing reference section? '11' on line 152 looks like a reference -- Missing reference section? '9' on line 146 looks like a reference -- Missing reference section? '10' on line 149 looks like a reference -- Missing reference section? '8' on line 143 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Zorn 2 Internet-Draft Microsoft Corporation 3 Category: Standards Track Novenber 1998 4 Updates: RFC 1570, RFC 1994, RFC 2284 5 7 PPP LCP Internationalization Configuration Option 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as and expires May 20, 1999. Please send 28 comments to the PPP Extensions Working Group mailing list (ietf- 29 ppp@merit.edu) or to the author (glennz@microsoft.com). 31 2. Abstract 33 The Point-to-Point Protocol (PPP) [1] provides a standard method for 34 transporting multi-protocol datagrams over point-to-point links. PPP 35 also defines an extensible Link Control Protocol (LCP), which allows 36 negotiation of an Authentication Protocol for authenticating its peer 37 before allowing Network Layer protocols to transmit over the link. 39 Both LCP and Authentication Protocol packets may contain text which is 40 intended to be human-readable [2,3,4]. This document defines an LCP 41 configuration option for the negotiation of character set and language 42 usage, as required by RFC 2277 [5]. 44 3. Specification of Requirements 46 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 47 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 48 described in [6]. 50 4. Additional LCP Configuration Option 52 The Configuration Option format and basic options are already defined 53 for LCP [1]. 55 Up-to-date values of the LCP Option Type field are specified in STD 2 56 [7]. This document concerns the following value: 58 28 Internationalization 60 The Internationalization option described here MAY be negotiated 61 independently in each direction. 63 Only one instance of this option SHOULD be sent by an implementation, 64 representing its preferred language and charset. 66 If Internationalization option is rejected by the peer, the default 67 language and charset MUST be used to construct all human-readable 68 messages sent to the peer. 70 4.1. Internationalization 72 Description 74 This Configuration Option provides a method for an implementation 75 to indicate to the peer both the language in which human-readable 76 messages it sends should be composed and the charset in which that 77 language should be represented. 79 A summary of the Internationalization option format is shown below. 80 The fields are transmitted from left to right. 82 0 1 2 3 83 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 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | Type | Length | MIBenum 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 MIBenum (cont) | Language-Tag... 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 Type 91 28 93 Length 95 >= 7 97 MIBenum 99 The MIBenum field is four octets in length. It contains a unique 100 integer value identifying a charset [5,11]. 102 This value MUST represent one of the set of charsets listed in the 103 IANA charset registry [7]. 105 The charset registration procedure is described in RFC 2278 [9]. 107 The default charset value is UTF-8 [10]. The MIBenum value for 108 the UTF-8 charset is 106. 110 Language-Tag 112 The Language-Tag field is an ASCII string which contains a 113 language tag, as defined in RFC 1766 [8]. 115 Language tags are in principle case-insensitive; however, since 116 the capitalization of a tag does not carry any meaning, 117 implementations SHOULD send only lower-case Tag fields. 119 The default Tag value is "i-default" [8]. 121 5. References 123 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 124 July 1994 126 [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol 127 (CHAP)", RFC 1994, August 1996 129 [3] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994 131 [4] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Proto- 132 col (EAP)", RFC 2284, March 1998 134 [5] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 135 18, RFC 2277, January 1998 137 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 138 Levels", BCP 14, RFC 2119, March 1997 140 [7] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC 1700, 141 October 1994 143 [8] Alvestrand, H., "Tags for the Identification of Languages", RFC 144 1766, March 1995 146 [9] Freed, N. and Postel, J., "IANA Charset Registration Procedures", 147 BCP 19, RFC 2278, January 1998 149 [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 150 2279, January 1998 152 [11] Smith, R., et al., "Printer MIB", RFC 1759, March 1995 154 6. Security Considerations 156 It is possible that an attacker might manipulate the option in such a 157 way that displayable messages would be unintelligible to the reader. 159 7. Acknowledgements 161 Thanks to Craig Fox (fox@cisco.com), James Carlson 162 (carlson@ironbridgenetworks.com), Harald Alvestrand 163 (Harald.Alvestrand@maxware.no), Kevin Smith (kevin@ascend.com), Karl Fox 164 (karl@ascend.com), Thomas Narten (narten@raleigh.ibm.com) and Narendra 165 Gidwani (nareng@microsoft.com) for helpful suggestions and feedback. 167 8. Chair's Address 169 The PPP Extensions Working Group can be contacted via the current chair: 171 Karl Fox 172 Ascend Communications 173 3518 Riverside Drive 174 Suite 101 175 Columbus, OH 43221 177 Phone: +1 614 326 6841 178 Email: karl@ascend.com 180 9. Author's Address 182 Questions about this memo can also be directed to: 184 Glen Zorn 185 Microsoft Corporation 186 One Microsoft Way 187 Redmond, Washington 98052 189 Phone: +1 425 703 1559 190 FAX: +1 425 936 7329 191 EMail: glennz@microsoft.com 193 10. Expiration Date 195 This memo is filed as and expires 196 on May 20, 1999.