RFC: [RFC Number or Draft Name] Category: [Standards Track | Informational | Experimental | Best Current Practice] Date: [Month Year] Author: [Author Name]

[Document Title]¶

This is an RFC template for drafting new specifications; it has no Chinese edition.

Status of This Memo¶

[Insert appropriate status boilerplate here. For example:] This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.

Abstract¶

[A concise summary of the document's purpose and content. Usually 1-2 paragraphs explaining what the protocol does and what problem it solves.]

1. Introduction¶

[Provide the context, motivation, and a high-level overview of the protocol or system being defined. Explain why this document is necessary and what it aims to achieve.]

2. Conventions and Terminology¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

[Define other protocol-specific terms here to ensure readers have a clear understanding of the vocabulary used in the rest of the document.]

[Term 1]: [Definition]
[Term 2]: [Definition]

3. Protocol Overview¶

[Describe the general operation of the protocol. Use sub-sections as needed to break down complex workflows, state machines, or lifecycle events.]

3.1. Sub-section¶

[Detailed explanation of a specific part of the protocol operation.]

4. Message Format¶

[Define the structure of messages, packets, or frames. ASCII art diagrams are highly recommended for binary protocols to clearly show byte/bit boundaries.]

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Field 1   |    Field 2    |             Field 3           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Field 4                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field 1 (X bits/bytes): [Description, data type, and constraints. E.g., Version number.]
Field 2 (X bits/bytes): [Description, data type, and constraints.]
Field 3 (X bits/bytes): [Description, data type, and constraints.]
Field 4 (Variable): [Description, such as Payload.]

5. Security Considerations¶

[Discuss the security implications of the protocol. Identify potential threats (e.g., eavesdropping, replay attacks, denial of service) and explain how the protocol mitigates them. If there are unresolved security issues or assumptions about the environment (like relying on TLS), state them clearly here.]

6. IANA Considerations¶

[Specify any required actions by the Internet Assigned Numbers Authority (IANA). For example, registering new port numbers, MIME types, or creating new registries. If none, state: "This document has no IANA actions."]

7. References¶

7.1. Normative References¶

[List documents that must be understood or implemented to use this specification.]

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

7.2. Informative References¶

[List documents that provide background information or additional context but are not strictly required to implement the protocol.]

[Reference Name] [Author, Title, Date/Link]

Appendix A. [Optional Appendix Title]¶

[Include supplementary material such as complex examples, proof of concepts, test vectors, or detailed state machine charts.]

Author's Address

[Your Name / Organization]
[Email Address]
[Website or Link]