RFC6455-The WebSocket protocol 之十一(終結版):11. IANA Considerations

11. IANA Considerations

11.IANA的考慮

11.1. Registration of New URI Schemes
11.1 新URI結構(Schemes)註冊

11.1.1. Registration of "ws" Scheme
A |ws| URI identifies a WebSocket server and resource name.
URI scheme name
ws
Status
Permanent
URI scheme syntax
Using the ABNF [RFC5234] syntax and ABNF terminals from the URI
specification [RFC3986]:
"ws:" "//" authority path-abempty [ "?" query ]
The <path-abempty> and <query> [RFC3986] components form the resource
name sent to the server to identify the kind of service desired.
Other components have the meanings described in [RFC3986].
URI scheme semantics
The only operation for this scheme is to open a connection using
the WebSocket Protocol.
Encoding considerations
Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII as specified
in [RFC3987] or its replacement. For the purposes of scheme-based
normalization, Internationalized Domain Name (IDN) forms of the
host component and their conversions to punycode are considered

equivalent (see Section 5.3.3 of [RFC3987]).

Characters in other components that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by first
encoding the characters as UTF-8 and then replacing the
corresponding bytes using their percent-encoded form as defined in
the URI [RFC3986] and Internationalized Resource Identifier (IRI)
[RFC3987] specifications.
Applications/protocols that use this URI scheme name
WebSocket Protocol
Interoperability considerations
Use of WebSocket requires use of HTTP version 1.1 or higher.
Security considerations
See "Security Considerations" section.
Contact
HYBI WG <[email protected]>
Author/Change controller
IETF <[email protected]>
References
RFC 6455
11.1.1 "ws"結構的註冊

一個ws URI定義了一個WebSocket服務器和資源名稱。
URI結構名稱
ws
狀態
永久的

URI結構語法
使用ABNF的語法和URI說明書中定義的字符:
"ws:" "//" authority path-abempty [ "?" query ]
<path-abempty> 和 <query>標誌着發往服務器的期待的資源名稱。其它部分與[RFC3986]中描述的一致。

URI結構語義
這個結構的唯一操作就是使用WebSocket協議打開服務端的連接。

編碼注意事項
主機組件中被上面語法排除的字符必須從unicode轉成ASCII,就像[RFC3987]或其替代品中定義的那樣。爲了保證基於結構的規範化,IDN行成了主機組件和域名轉換被認爲是同等的。
其它組件中被上面語法排除的字符也必須從unicode轉成ASCII,但是首先要把字符轉成UTF-8,然後使用URI和IRI中定義的部分編碼的形式替換掉對應的字節。

應用/協議 使用的URI結構名稱
WebSocket協議

通用性要求
使用WebSocket需要HTTP v1.1以上。

安全性要求
參照“安全性要求”節。

聯繫
HYBI WG <[email protected]>

作者/改變 總管
IETF <[email protected]>

引用
RFC 6455

11.1.2. Registration of "wss" Scheme
A |wss| URI identifies a WebSocket server and resource name and
indicates that traffic over that connection is to be protected via
TLS (including standard benefits of TLS such as data confidentiality
and integrity and endpoint authentication).
URI scheme name
wss
Status
Permanent
URI scheme syntax
Using the ABNF [RFC5234] syntax and ABNF terminals from the URI
specification [RFC3986]:
"wss:" "//" authority path-abempty [ "?" query ]
The <path-abempty> and <query> components form the resource name sent
to the server to identify the kind of service desired. Other
components have the meanings described in [RFC3986].

URI scheme semantics
The only operation for this scheme is to open a connection using
the WebSocket Protocol, encrypted using TLS.
Encoding considerations
Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII as specified
in [RFC3987] or its replacement. For the purposes of scheme-based
normalization IDN forms of the host component and their
conversions to punycode are considered equivalent (see Section
5.3.3 of [RFC3987]).
Characters in other components that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by first
encoding the characters as UTF-8 and then replacing the
corresponding bytes using their percent-encoded form as defined in
the URI [RFC3986] and IRI [RFC3987] specifications.
Applications/protocols that use this URI scheme name
WebSocket Protocol over TLS
Interoperability considerations
Use of WebSocket requires use of HTTP version 1.1 or higher.
Security considerations
See "Security Considerations" section.
Contact
HYBI WG <[email protected]>
Author/Change controller
IETF <[email protected]>
References
RFC 6455
11.1.2 “wss”結構的註冊
一個wss URI定義了一個Websocket服務器和資源名稱,而且暗示着在這個連接上的傳輸受到TLS的保護(包含TLS的標準優勢,例如數據保密、數據完整、終端驗證等)。
URI 結構名稱
wss

狀態
永久的

URI 結構語法
使用ABNF語法和URI說明書中的定義的字符:
"wss:" "//" authority path-abempty [ "?" query ]

<path-abempty> 和 <query>標誌着發往服務器的期待的資源名稱。其它部分與[RFC3986]中描述的一致。

URI結構語義
這個結構的唯一操作就是使用WebSocket協議打開服務端的連接,使用TLS加密。

編碼注意事項
主機組件中被上面語法排除的字符必須從unicode轉成ASCII,就像[RFC3987]或其替代品中定義的那樣。爲了保證基於結構的規範化,IDN行成了主機組件和域名轉換被認爲是同等的。
其它組件中被上面語法排除的字符也必須從unicode轉成ASCII,但是首先要把字符轉成UTF-8,然後使用URI和IRI中定義的部分編碼的形式替換掉對應的字節。

應用/協議 使用的URI結構名稱
基於TLS的WebSocket協議

通用性要求
使用WebSocket需要HTTP v1.1以上。

安全性要求
參照“安全性要求”節。

聯繫
HYBI WG <[email protected]>

作者/改變 總管
IETF <[email protected]>

引用
RFC 6455


11.2. Registration of the "WebSocket" HTTP Upgrade Keyword
This section defines a keyword registered in the HTTP Upgrade Tokens
Registry as per RFC 2817 [RFC2817].
Name of token
WebSocket
Author/Change controller
IETF <[email protected]>

Contact
HYBI <[email protected]>
References
RFC 6455
11.2 WebSocket HTTP Upgrade關鍵字註冊
這節定義了一個在HTTP Upgrade Tokens中註冊的關鍵字。
標誌名稱
WebSocket

聯繫
HYBI WG <[email protected]>

作者/改變 總管
IETF <[email protected]>

引用
RFC 6455

11.3. Registration of New HTTP Header Fields
11.3 新HTTP 頭字段的註冊

11.3.1. Sec-WebSocket-Key
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Key
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Key| header field is used in the WebSocket opening
handshake. It is sent from the client to the server to provide part
of the information used by the server to prove that it received a
valid WebSocket opening handshake. This helps ensure that the server
does not accept connections from non-WebSocket clients (e.g., HTTP
clients) that are being abused to send data to unsuspecting WebSocket
servers.
The |Sec-WebSocket-Key| header field MUST NOT appear more than once
in an HTTP request.
11.3.1 Sec-WebSocket-Key
本節描述一個在永久消息頭字段名稱庫中定義的頭字段。
頭字段名稱
Sec-WebSocket-Key

可適用的協議
http

狀態
標準

作者/改變 總管

IETF

說明書文檔
RFC 6455

相關信息
這個頭字段僅僅用在WebSocket握手。

Sec-WebSocket-Key頭字段被用在打開WebSocket握手。它從客戶端發往服務端,提供給服務端用以證明是合法WebSocket握手的部分信息。這幫助確認服務端沒有從非WebSocket客戶端接收請求,這正在被濫用發送數據到受信任的WebSocket服務端。
Sec-WebSocket-Key在HTTP 請求中只能出現一次。

11.3.2. Sec-WebSocket-Extensions

This section describes a header field for registration in the
Permanent Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Extensions
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Extensions| header field is used in the WebSocket
opening handshake. It is initially sent from the client to the
server, and then subsequently sent from the server to the client, to
agree on a set of protocol-level extensions to use for the duration
of the connection.
The |Sec-WebSocket-Extensions| header field MAY appear multiple times
in an HTTP request (which is logically the same as a single
|Sec-WebSocket-Extensions| header field that contains all values.
However, the |Sec-WebSocket-Extensions| header field MUST NOT appear
more than once in an HTTP response.
11.3.2. Sec-WebSocket-Extensions

本節描述一個在永久消息頭字段名稱庫中定義的頭字段。
頭字段名稱
Sec-WebSocket-Extensions

可適用的協議
http

狀態
標準

作者/改變 總管

IETF

說明書文檔
RFC 6455

相關信息
這個頭字段僅僅用在WebSocket握手。

Sec-WebSocket-Extensions頭字段被用在打開WebSocket握手。它首先從客戶端發往服務端,然後服務端把一部分返回給客戶端,提供一套在連接過程中使用的協議級別的擴展。Sec-WebSocket-Extensions在HTTP 請求中可能出現多次(在邏輯上來說它與一個包含所有內容的Sec-WebSocket-Extensions是一樣的)。但是Sec-WebSocket-Extensions在HTTP響應中只能出現一次。

11.3.3. Sec-WebSocket-Accept
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Accept
Applicable protocol
http
Status
standard

Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for the WebSocket opening
handshake.
The |Sec-WebSocket-Accept| header field is used in the WebSocket
opening handshake. It is sent from the server to the client to
confirm that the server is willing to initiate the WebSocket
connection.
The |Sec-WebSocket-Accept| header MUST NOT appear more than once in
an HTTP response.

本節描述一個在永久消息頭字段名稱庫中定義的頭字段。
頭字段名稱
Sec-WebSocket-Accept

可適用的協議
http

狀態
標準

作者/改變 總管

IETF

說明書文檔
RFC 6455

相關信息
這個頭字段僅僅用在WebSocket握手。

Sec-WebSocket-Extensions頭字段被用在打開WebSocket握手。它從服務端發往客戶端以證明服務端正打算初始化這個連接Sec-WebSocket-Extensions在HTTP響應中只能出現一次。


11.3.4. Sec-WebSocket-Protocol
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Protocol
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for the WebSocket opening
handshake.
The |Sec-WebSocket-Protocol| header field is used in the WebSocket
opening handshake. It is sent from the client to the server and back
from the server to the client to confirm the subprotocol of the
connection. This enables scripts to both select a subprotocol and be
sure that the server agreed to serve that subprotocol.

The |Sec-WebSocket-Protocol| header field MAY appear multiple times
in an HTTP request (which is logically the same as a single
|Sec-WebSocket-Protocol| header field that contains all values).
However, the |Sec-WebSocket-Protocol| header field MUST NOT appear
more than once in an HTTP response.

本節描述一個在永久消息頭字段名稱庫中定義的頭字段。
頭字段名稱
Sec-WebSocket-Protocol

可適用的協議
http

狀態
標準

作者/改變 總管

IETF

說明書文檔
RFC 6455

相關信息
這個頭字段僅僅用在WebSocket握手。

Sec-WebSocket-Protocol頭字段被用在打開WebSocket握手。它從客戶端發往服務端然後從服務端返回到客戶端以確定連接的子協議。這即允許腳本去選擇一個子協議又確定服務端同意支持這個子協議。Sec-WebSocket-Protocol在HTTP 請求中可能出現多次(在邏輯上來說它與一個包含所有內容的Sec-WebSocket-Protocol是一樣的)。但是Sec-WebSocket-Protocol在HTTP響應中只能出現一次。


11.3.5. Sec-WebSocket-Version
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Version
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for the WebSocket opening
handshake.
The |Sec-WebSocket-Version| header field is used in the WebSocket
opening handshake. It is sent from the client to the server to
indicate the protocol version of the connection. This enables
servers to correctly interpret the opening handshake and subsequent
data being sent from the data, and close the connection if the server
cannot interpret that data in a safe manner. The |Sec-WebSocket-
Version| header field is also sent from the server to the client on
WebSocket handshake error, when the version received from the client
does not match a version understood by the server. In such a case,
the header field includes the protocol version(s) supported by the
server.
Note that there is no expectation that higher version numbers are
necessarily backward compatible with lower version numbers.

The |Sec-WebSocket-Version| header field MAY appear multiple times in
an HTTP response (which is logically the same as a single
|Sec-WebSocket-Version| header field that contains all values).
However, the |Sec-WebSocket-Version| header field MUST NOT appear
more than once in an HTTP request.

本節描述一個在永久消息頭字段名稱庫中定義的頭字段。
頭字段名稱
Sec-WebSocket-Version

可適用的協議
http

狀態
標準

作者/改變 總管

IETF

說明書文檔
RFC 6455

相關信息
這個頭字段僅僅用在WebSocket握手。

Sec-WebSocket-Version頭字段被用在打開WebSocket握手。它從客戶端發往服務端以確定連接的協議版本。這確保服務端可以正確的解析打開的握手和隨後的數據,一旦服務端不能以安全的方式解析數據它就會關閉連接。當從客戶端接收到的版本與服務端能理解的版本不一致時,Sec-WebSocket-Version在WebSocket握手失敗的時候也會從服務端發往客戶端。這時候該字段代表的是服務端支持的版本。注意這裏並沒有要求高版本向下兼容低版本。

Sec-WebSocket-Version在HTTP 請求中可能出現多次(在邏輯上來說它與一個包含所有內容的Sec-WebSocket-Version是一樣的)。但是Sec-WebSocket-Protocol在HTTP請求中只能出現一次。

11.4. WebSocket Extension Name Registry
This specification creates a new IANA registry for WebSocket
Extension names to be used with the WebSocket Protocol in accordance
with the principles set out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Extension Identifier
The identifier of the extension, as will be used in the
|Sec-WebSocket-Extensions| header field registered in
Section 11.3.2 of this specification. The value must conform to
the requirements for an extension-token as defined in Section 9.1
of this specification.
Extension Common Name
The name of the extension, as the extension is generally referred
to.
Extension Definition
A reference to the document in which the extension being used with
the WebSocket Protocol is defined.
Known Incompatible Extensions
A list of extension identifiers with which this extension is known
to be incompatible.
WebSocket Extension names are to be subject to the "First Come First
Served" IANA registration policy [RFC5226].
There are no initial values in this registry.

11.4 WebSocket Extension Name Resitry
本說明書爲WebSocket 擴展名稱提供了一個新的IANA註冊,這個擴展與WebSocket協議一塊使用,與RFC 5226中定義的原則保持一致。作爲註冊的一部分,IANA包含以下的信息:

    擴展標記

        是擴展的標記,會在本書的11.3.2節中註冊的|Sec-WebSocket-Extensions|頭字段中使用到。它的值必須滿足擴展符號(extension-token)的要求,就像說明書中9.1節定義的那樣。

    擴展通用名稱
        擴展的名稱,就像擴展通常所引用的。
    擴展定義
        WebSocket 協議使用的擴展的定義文檔。
    已知的不可用的擴展
        已知的不可用的擴展標識列表
    WebSocket擴展名稱遵循IANA註冊協議:第一個來的第一個提供服務

   
11.5. WebSocket Subprotocol Name Registry
This specification creates a new IANA registry for WebSocket
Subprotocol names to be used with the WebSocket Protocol in
accordance with the principles set out in RFC 5226 [RFC5226].

As part of this registry, IANA maintains the following information:
Subprotocol Identifier
The identifier of the subprotocol, as will be used in the
|Sec-WebSocket-Protocol| header field registered in Section 11.3.4
of this specification. The value must conform to the requirements
given in item 10 of Section 4.1 of this specification -- namely,
the value must be a token as defined by RFC 2616 [RFC2616].
Subprotocol Common Name
The name of the subprotocol, as the subprotocol is generally
referred to.
Subprotocol Definition
A reference to the document in which the subprotocol being used
with the WebSocket Protocol is defined.
WebSocket Subprotocol names are to be subject to the "First Come
First Served" IANA registration policy [RFC5226].
11.5 WebSocket Subprotocol Name 註冊
本節爲WebSocket 協議創造一個新的IANA註冊,WebSocket Subprotocol與WebSocket協議一塊使用,與RFC 5226中定義的原則保持一致。作爲註冊的一部分,IANA包含以下的信息:

Subprotocol標記

是子協議的標記,會在本書的11.3.4節中註冊的|Sec-WebSocket-Protocol|頭字段中使用到。它的值必須與本說明書中4.1節第10部分描述的一致,它的值必須是RFC 2616中定義的。

    Subprotocol通用名稱
        Subprotocol的名稱,就像Subprotocol通常所引用的。
    Subprotocol定義
        WebSocket 協議使用的Subprotocol的定義文檔。
    WebSocket擴展名稱遵循IANA註冊協議:第一個來的第一個提供服務


11.6. WebSocket Version Number Registry

11.6 WebSocket 版本數字註冊
This specification creates a new IANA registry for WebSocket Version
Numbers to be used with the WebSocket Protocol in accordance with the
principles set out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Version Number
The version number to be used in the |Sec-WebSocket-Version| is
specified in Section 4.1 of this specification. The value must be
a non-negative integer in the range between 0 and 255 (inclusive).

Reference
The RFC requesting a new version number or a draft name with
version number (see below).
Status
Either "Interim" or "Standard". See below for description.
A version number is designated as either "Interim" or "Standard".
A "Standard" version number is documented in an RFC and used to
identify a major, stable version of the WebSocket protocol, such as
the version defined by this RFC. "Standard" version numbers are
subject to the "IETF Review" IANA registration policy [RFC5226].

An "Interim" version number is documented in an Internet-Draft and
used to help implementors identify and interoperate with deployed
versions of the WebSocket protocol, such as versions developed before
the publication of this RFC. "Interim" version numbers are subject
to the "Expert Review" IANA registration policy [RFC5226], with the
chairs of the HYBI Working Group (or, if the working group closes,
the Area Directors for the IETF Applications Area) being the initial
Designated Experts.
IANA has added initial values to the registry as follows.


本節爲WebSocket 協議創造一個新的IANA註冊,WebSocket Version Numbers與WebSocket協議一塊使用,與RFC 5226中定義的原則保持一致。作爲註冊的一部分,IANA包含以下的信息:

    版本號
        版本號用在4.1節中介紹的|Sec-WebSocket-Version|中。值必須是介於0和255之間的整數。
    引用
        RFC要求一個新的版本號或帶有版本號的草稿名。
    狀態
        “過渡期”或“正式版”,看下面的描述。
        “正式版”的版本號在RFC中定義,用來標識WebSocket協議的一個重要的、穩定的版本,就像本RFC中定義的版本。“正式版”的版本號遵從IANA中定義的"IETF Review"。
        “過渡期”版本在“網絡-草案”中定義,用來幫助開發人員標識和區分已經部署的WebSocket 協議,例如在RFC發佈之前開發的版本。“過渡期”的版本號遵從IANA中定義的"Expert Review",HYBI Working Group是其初始設計團隊。
        IANA已經增加的過渡期的值如下所示:

11.7. WebSocket Close Code Number Registry
This specification creates a new IANA registry for WebSocket
Connection Close Code Numbers in accordance with the principles set
out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Status Code
The Status Code denotes a reason for a WebSocket connection
closure as per Section 7.4 of this document. The status code is
an integer number between 1000 and 4999 (inclusive).
Meaning
The meaning of the status code. Each status code has to have a
unique meaning.
Contact
A contact for the entity reserving the status code.
Reference
The stable document requesting the status codes and defining their
meaning. This is required for status codes in the range 1000-2999
and recommended for status codes in the range 3000-3999.
WebSocket Close Code Numbers are subject to different registration
requirements depending on their range. Requests for status codes for
use by this protocol and its subsequent versions or extensions are
subject to any one of the "Standards Action", "Specification
Required" (which implies "Designated Expert"), or "IESG Review" IANA
registration policies and should be granted in the range 1000-2999.
Requests for status codes for use by libraries, frameworks, and
applications are subject to the "First Come First Served" IANA
registration policy and should be granted in the range 3000-3999.
The range of status codes from 4000-4999 is designated for Private
Use. Requests should indicate whether they are requesting status
codes for use by the WebSocket Protocol (or a future version of the
protocol), by extensions, or by libraries/frameworks/applications.
IANA has added initial values to the registry as follows.
11.7 WebSocket 關閉碼註冊
本節創造了一個新的IANA註冊,用來作爲WebSocket連接關閉碼,這與RFC5226中定義的一致。作爲註冊的一部分,IANa包含以下信息:
狀態碼:
一個狀態碼暗示了一種WebSocket連接關閉的原因,就像7.4節中描述的。這個狀態碼是介於1000到4999之間的整數。
含義:
狀態碼的含義。每一個狀態碼必須只有一個意義。
聯繫人
保留狀態碼的聯繫人。
引用
正式的文檔要求狀態碼並定義了它的含義。對於1000-2999之間的狀態碼是必須的,對於3000-3999之間的狀態碼是推薦的。
WebSocket關閉碼在不同的範圍內對他們的限制是不同的。本協議、後面的版本或擴展版本使用的狀態碼要求遵從"Standards Action", "Specification Required"或IANA中的"IESG Review",允許在1000-2999之間。庫、框架、應用使用的狀態碼要求遵循IANa的“先來先服務”原則,允許在3000-3999之間。4000-4999之間的狀態碼是用來做私有使用的。請求需要表明狀態碼是否使用在WebSocket協議上,或者擴展上,或者庫/框架/應用上。IANA已經定義了一些初始的值:


11.8. WebSocket Opcode Registry
This specification creates a new IANA registry for WebSocket Opcodes
in accordance with the principles set out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Opcode
The opcode denotes the frame type of the WebSocket frame, as
defined in Section 5.2. The opcode is an integer number between 0
and 15, inclusive.
Meaning
The meaning of the opcode value.

Reference
The specification requesting the opcode.
WebSocket Opcode numbers are subject to the "Standards Action" IANA
registration policy [RFC5226].
IANA has added initial values to the registry as follows.
11.8 WebSocket 操作碼註冊
本節創建了一個新的IANA註冊項,用在WebSocket操作碼,與RFC5225保持一致。作爲註冊項的一部分,IANA包含以下的信息:
操作碼
    操作碼定義了WebSocket幀的幀類型,就像5.2節中定義的。操作碼是介於0-15之間的整數。
含義
    操作碼的含義
引用
    規範要求操作碼。
    WebSocket操作碼與RFC5225中的IANA註冊協議的"Standards Action"保持一致。
    IANa已經定義了一些初始值:
|Opcode | Meaning | Reference |
-+--------+-------------------------------------+-----------|
| 0 | Continuation Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 1 | Text Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 2 | Binary Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 8 | Connection Close Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 9 | Ping Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 10 | Pong Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
11.9. WebSocket Framing Header Bits Registry
This specification creates a new IANA registry for WebSocket Framing
Header Bits in accordance with the principles set out in RFC 5226
[RFC5226]. This registry controls assignment of the bits marked
RSV1, RSV2, and RSV3 in Section 5.2.
These bits are reserved for future versions or extensions of this
specification.
WebSocket Framing Header Bits assignments are subject to the
"Standards Action" IANA registration policy [RFC5226].
11.9WebSocket Framing Header Bits Registry
本節創建了一個新的IANA註冊項,用在WebSocket 幀頭比特,與RFC5225保持一致。這個註冊項決定了在5.2中定義的RSV1、RSV2、RSV3的作用。
這些“位”給將來的版本或擴展而保留。
WebSocket Framing Header Bits與IANA中的"Standards Action"保持一致。

本節之後的內容,與WebSocket本身就沒多大關係了,歷時將近一個月的WebSocket翻譯工作就告一段落了。雖然翻譯的過程比較痛苦,雖然翻譯的質量有待提高,但是培養這種從頭到尾堅持到底的精神,正是本次翻譯的目標。很高興,我堅持下來了,我爲自己加油。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章