1.

Giới thiệu
Việc sử dụng các dịch vụ Web (Web APIs) trên Internet đang trở nên phổ cập (ubiquitous) trong
hầu hết các ứng dụng và phụ thuộc vào kiến trúc REST(Representational State Transfer) cơ bản
của Web.
Làm việc trên môi trường Constrained RESTful Environments (CoRE) nhằm mục đích thực hiện
kiến trúc REST ở dạng phù hợp với các nodes bị giới hạn (constrained) (VD : VXL 8 bit với RAM và
ROM giới hạn) và mạng (VD :LoWPAN). Mạng bị giới hạn (Constrained networks) như 6LoWPAN
hỗ trợ phân giải (fragmentation) các gói tin IPv6 thành các frame link-layer nhỏ, tuy nhiên điều
này giảm đáng kể xác suất phân phối gói tin (packet delivery probability). Một trong những mục
tiêu thiết kế của COAP là làm giữ cho message overhaead nhỏ, do đó (thus) giới hạn nhu cầu cho
phân giải.
Một trong các mục tiêu chính của CoAP là thiết kế một giao thức web chung cho các yêu cầu đặc
biệt trong môi trường giới hạn này, đặc biệt khi xem xét đến năng lượng, tự động hóa toàn nhà,
và các ứng dụng (M2M) machine-to-machine khác. Mục tiêu của CoAP không chỉ là việc nén lại
của giao thức HTTP, mà còn nhận ra một tập con của REST với HTTP mà tối ưu cho ứng dujgn
M2M. Mặ c dù CoAP có thể sử dụng để đổi mới các giao diện HTTP đơn giản (refashioning
simple HTTP interfaces) thành một giao thức gọn hơn nhưng quan trọng hơn là nó cũng đề xuất
các tính năng cho M2M như built-in discovery, multicast support, and asynchronous message
exchanges.
1.1 Các tính năng
CoAP có các chức năng chính sau :
- Giao thức đáp ứng (fulfilling) các yêu cầu M2M trong môi trường ràng buộc.
- Truyền qua UDP đáng tin cậy và yêu cầu multicast.
- Truyền bản tin có đồng bộ
- Giảm chi phi header và độ phức tạp phân tích cú pháp (parsing)
- Hỗ trợ URI và các loại nội dung (Content-Type)
- Proxy đơn giản và có khả năng cache (caching capablilities)
- Ánh xạ HTTP không trạng thái, cho phép proxies để truy cập vào các tài nguyên CoAP
thông qua HTTP một cách thống nhất hoặc thay thế các HTTP interface đơn giản qua
CoAP.
- Bảo mật qua DTLS (Datagram Transport Layer Security)
1.2 Các thuật ngữ (Terminology)
Interpreted (Giải thích)
Endpoint: Một thực thể tham gia trong giao thứcc CoAP. Thông thường (Colloquially), một
endpoint sống trên một “Node”, mặc dù “Host” có thể phù hợp (consistent) hơn với việc sử
dụng các tiêu chuẩn Internet và được định danh bằng các thông tin ghép kênh ở lớp
Transport layer có thể bao gồm một cổng UDP và một thông tin bảo mật. (Phần 4.1_
Sender: Là endpoint gửi bản tin. Khi các khía cạn(aspect) của một định danh cho một sender
được đề cập đến thì cũng được gọi là “source endpoint”.
Recipient: Là endpoint nhận bản tin. Tương tự có thể gọi là "destination endpoint"
Client: Là endpoint nguồn của một yêu cầu và là endpoint đích của một phản hồi.
Server: Là endpoint đích của một yêu cầu và là endpoint nguồn của một phản hồi.
Origin Server : Nơi mà tại đó tài nguyên được lưu trữ hoặc được tạo ra.
 Intermediary : Là một CoAP endpoint mà hoạt động cả như một server cũng như client
hướng tới origin server ( Có thể thông qua các Intermediary khác). Một dạng phổ biến cảu
một intermediary là một proxy.
Proxy: Là một intermediary chủ yếu quan tâm đến các yêu cầu chuyển tiếp và gửi lại các
phản hồi, có thể caching, dịch namespace, hoặc dịch giao thức. Trái ngược (As opposed) với
intermediaries theo nghĩa chung, proxied nhìn chung không thực thi các application
semantic cụ thể. Dựa trên vị trí trong cấu trúc chung của request forwarding, có 2 dạng
proxy là : forward-proxy và reverse-proxy. Trong một vài trường hợp, một endpoint đơn có
thể hoạt động như một origin server, forward-proxy, or reverse-proxy, switching behavior
dựa trên bản chất của mỗi request.
Forward-Proxy: Là một endpoint được lựa chọn bởi 1 client, thường thông qua các quy tắc
cấu hình nội bộ, để thực hiện các request thay mặt cho client, là một vài dịch cần thiết. Một
số bản dịch được tối thiểu, như proxy request cho “coap” URI, trong khi (whereas) các
request khác có thể yêu cầu dịch tới và từ Các giao thức lớp ứng dụng hoàn toàn khác nhau.
Reverse-Proxy : Một endpoint mà viết tắt của một hoặc nhiều máy chủ khác và đáp ứng các
yêu cầu thay mặt cho những thứ này, thực hiện bất kỳ bản dịch cần thiết nào. Không giống
như một proxy tiền đạo, khách hàng có thể không nhận thức được rằng nó đang giao tiếp
với một proxy ngược; Một proxy ngược nhận các yêu cầu như thể đó là máy chủ gốc cho tài
nguyên đích
CoAP-to-CoAP Proxy: Một proxy ánh xạ từ yêu cầu COAP đến yêu cầu COAP, tức là sử dụng
giao thức COAP cả ở phía máy chủ và phía máy khách. Tương phản với cross-proxy.
Cross-Proxy: Một cross-protocol proxy , hay viết tắt là "cross-proxy" , là một proxy dịch giữa
các giao thức khác nhau, chẳng hạn như proxy coap-to-http hoặc proxy HTTP-to COAP.
Confirmable Message: Một vài message yêu cầu một yêu cầu xác nhận (acknowledgement).
Các message này được được gọi là "Confirmable". Khi không có packet bị mất, mỗi
Confirmable message sẽ cần chính xác một message trả về loại Acknowledgement hoặc
Reset.
Non-confirmable Message: Một số message khác không yêu cầu acknowledgement. Điều
này đặc biệt đúng đối với các thông báo được lặp lại thường xuyên cho các yêu cầu của ứng
dụng, chẳng hạn như đọc lặp lại từ một cảm biến
Acknowledgement Message: thừa nhận rằng một message có thể xác nhận cụ thể đã đến.
Chính nó, một thông báo xác nhận không chỉ ra thành công hay thất bại của bất kỳ yêu cầu
nào được gói gọn trong message có thể xác nhận, nhưng thông báo xác nhận cũng có thể
mang theo phản hồi cõng.
Reset Message: A Reset message chỉ ra rằng một thông điệp cụ thể (có thể xác nhận hoặc
không thể xác nhận) đã được nhận, nhưng một số ngữ cảnh bị thiếu để xử lý đúng cách.
Điều kiện này thường được gây ra khi node nhận đã khởi động lại và đã quên một số trạng
thái sẽ được yêu cầu để giải thích thông điệp. Kích thích một thông báo đặt lại (ví dụ: bằng
cách gửi một message có thể xác nhận trống) cũng hữu ích như một kiểm tra rẻ tiền về khả
năng sống của một điểm cuối ("COAP ping").
Piggybacked Response:
2. CoAP

Mô hình tương tác của COAP tương tự như mô hình server/client của HTTP. Tuy nhiên, các tương
tác machine-to-machine (M2M) thường dẫn đến việc triển khai COAP hoạt động trong cả vai trò của
server và client. Request COAP tương đương với HTTP và được client gửi để yêu cầu một action (sử
dụng Method Code) trên resource (được xác định bởi URI) trên server. Server sau đó gửi Response
với Response Code; Response này có thể bao gồm một đại diện tài nguyên.

Không giống như HTTP, COAP liên quan đến các nút giao này không đồng bộ trên một vận chuyển
định hướng dữ liệu như UDP. Điều này được thực hiện một cách logic bằng cách sử dụng một lớp
message hỗ trợ độ tin cậy tùy chọn (với sự trở lại theo cấp số nhân). COAP xác định bốn loại
message: xác nhận, không thể xác nhận, xác nhận, đặt lại. Mã phương thức và mã phản hồi có trong
một số message này khiến chúng thực hiện các yêu cầu hoặc phản hồi. Các trao đổi cơ bản của bốn
loại message có phần trực giao với các tương tác yêu cầu/phản hồi; Các yêu cầu có thể được thực
hiện trong các message có thể xác nhận và không thể xác nhận và các phản hồi có thể được thực
hiện trong những thông điệp này cũng như cõng trong các message xác nhận.

Người ta có thể nghĩ về CoAP một cách logic như sử dụng phương pháp hai layer, message layer của
CoAP được sử dụng để xử lý với UDP và tính không đồng bộ của các tương tác. Request/Response
layer xử lý các tương tác yêu cầu/phản hồi bằng cách sử dụng mã phản hồi và mã phản ứng (xem
Hình 1). Tuy nhiên, COAP là một giao thức đơn, với messaging và Request/Response chỉ là các tính
năng của tiêu đề COAP.

2.1 Messaging Model

Messaging Model của COAP dựa trên việc trao đổi message qua UDP giữa các endpoint.

COAP sử dụng header nhị phân có độ dài cố định ngắn (4 byte) có thể được theo sau bởi các tùy
chọn nhị phân nhỏ gọn và một payload. Message format này được chia sẻ bởi các yêu cầu và phản
hồi. Định dạng message COAP được mô tả trong Phần 3. Mỗi message chứa một ID message được
sử dụng để phát hiện các bản lặp và tùy chọn độ tin .

Độ tin cậy được cung cấp bằng cách đánh dấu một thông báo là có thể xác nhận (Con). Một
confirmable message được truyền lại bằng cách sử dụng thời gian chờ mặc định và ngược theo cấp
số nhân giữa các truyền lại, cho đến khi người nhận gửi message xác nhận (ACK) với cùng một ID
message (trong ví dụ này, 0x7D34) từ điểm cuối tương ứng; Xem Hình 2. Khi người nhận hoàn toàn
không thể xử lý một confirmable message (nghĩa là, thậm chí không thể cung cấp phản hồi lỗi phù
hợp), nó trả lời bằng message đặt lại (RST) thay vì xác nhận (ACK).

Một thông báo không yêu cầu truyền đáng tin cậy (ví dụ: mỗi phép đo từ một luồng dữ liệu cảm
biến) có thể được gửi dưới dạng Non-confirmable message(Non). Chúng không được xác nhận,
nhưng vẫn có ID message để phát hiện trùng lặp (trong ví dụ này, 0x01A0); Xem Hình 3. Khi người
nhận không thể xử lý một Non-confirmable message, nó có thể trả lời bằng message đặt lại (RST).

Khi COAP chạy qua UDP, nó cũng hỗ trợ việc sử dụng multicast đến các địa chỉ đích IP , cho phép các
COAP request phát multicast. Phần 8 thảo luận về việc sử dụng đúng các thông điệp COAP với các
địa chỉ và biện pháp phòng ngừa multicast để tránh tắc nghẽn phản ứng.

Một số chế độ bảo mật được xác định cho COAP trong Phần 9 từ không bảo mật đến bảo mật dựa
trên certificate . Tài liệu này chỉ định một liên kết với DTLS để đảm bảo giao thức; Việc sử dụng IPSEC
với COAP được thảo luận trong [IPSEC-CoAP].

2.2 Request/Response Model

Yêu cầu COAP và ngữ nghĩa phản hồi được thực hiện trong các thông báo COAP, bao gồm mã
phương thức hoặc mã phản hồi tương ứng. Yêu cầu tùy chọn (hoặc mặc định) thông tin phản hồi và
thông tin phản hồi, chẳng hạn như loại phương tiện URI và payload được thực hiện dưới dạng tùy
chọn COAP. Một mã thông báo được sử dụng để khớp các phản hồi với các yêu cầu một cách độc
lập với các thông báo cơ bản (Phần 5.3). (Lưu ý rằng mã thông báo là một khái niệm tách biệt với ID
message.)

Một yêu cầu được thực hiện trong một message có thể xác nhận (Con) hoặc không xác nhận (không)
và nếu có sẵn ngay lập tức, phản hồi cho một yêu cầu được thực hiện trong một confirmable
message được thực hiện trong thông báo xác nhận kết quả (ACK). Đây được gọi là một phản ứng
cõng, chi tiết trong Phần 5.2.1. . Một kết quả là phản hồi 4.04 (không tìm thấy).

Nếu máy chủ không thể trả lời ngay lập tức với một yêu cầu được thực hiện trong một message có
thể xác nhận, nó chỉ cần trả lời bằng một thông báo xác nhận trống để khách hàng có thể ngừng
truyền lại yêu cầu. Khi phản hồi đã sẵn sàng, máy chủ sẽ gửi nó trong một confirmable message mới
(lần lượt cần phải được khách hàng thừa nhận). Đây được gọi là "phản ứng riêng biệt", như được
minh họa trong Hình 5 và được mô tả chi tiết hơn trong Phần 5.2.2.
Nếu một yêu cầu được gửi trong một message không thể xác nhận, thì phản hồi được gửi bằng
message mới không thể xác nhận, mặc dù máy chủ có thể gửi một message có thể xác nhận. Loại
trao đổi này được minh họa trong Hình 6.

COAP sử dụng các phương thức GET, PUT, POST và XÓA theo cách tương tự như HTTP, với ngữ
nghĩa được chỉ định trong Phần 5.8. . sự chỉ rõ.)
Các phương pháp vượt quá bốn cơ bản có thể được thêm vào COAP trong các thông số kỹ thuật
riêng biệt. Các phương pháp mới không nhất thiết phải sử dụng các yêu cầu và phản hồi theo cặp.
Ngay cả đối với các phương thức hiện có, một yêu cầu duy nhất có thể mang lại nhiều phản hồi, ví
dụ: cho một yêu cầu phát đa hướng (Phần 8) hoặc với tùy chọn Quan sát [Quan sát]

Hỗ trợ URI trong một máy chủ được đơn giản hóa khi máy khách đã phân tích URI và chia nó thành
các thành phần máy chủ, cổng, đường dẫn và truy vấn, sử dụng các giá trị mặc định cho hiệu quả.
Mã phản hồi liên quan đến một tập hợp con nhỏ của mã trạng thái HTTP với một vài mã cụ thể
COAP được thêm vào, như được định nghĩa trong Phần 5.9.

2.3 Intermediaries and Caching

Giao thức hỗ trợ bộ đệm phản hồi để thực hiện hiệu quả các yêu cầu. Bộ nhớ đệm đơn giản được
kích hoạt bằng cách sử dụng thông tin độ tươi và tính hợp lệ được thực hiện với các phản hồi của
COAP. Một bộ đệm có thể được đặt trong một điểm cuối hoặc một trung gian. Chức năng bộ nhớ
đệm được chỉ định trong Phần 5.6.

Proxy rất hữu ích trong các mạng bị ràng buộc vì nhiều lý do, bao gồm hạn chế lưu lượng mạng, để
cải thiện hiệu suất, truy cập tài nguyên của thiết bị ngủ và vì lý do bảo mật. Việc ủy thác các yêu cầu
thay mặt cho điểm cuối CoAP khác được hỗ trợ trong giao thức. Khi sử dụng proxy, URI của tài
nguyên để yêu cầu được bao gồm trong yêu cầu, trong khi địa chỉ IP đích được đặt thành địa chỉ của
proxy. Xem Phần 5.7 để biết thêm thông tin về chức năng proxy.

Vì COAP được thiết kế theo kiến trúc REST [REST], và do đó thể hiện chức năng tương tự như giao
thức HTTP, nên việc ánh xạ từ COAP đến HTTP và từ HTTP đến COAP khá đơn giản. Một ánh xạ như
vậy có thể được sử dụng để nhận ra giao diện REST HTTP bằng COAP hoặc để chuyển đổi giữa HTTP
và COAP. Chuyển đổi này có thể được thực hiện bởi một proxy giao thức chéo ("proxy chéo"),
chuyển đổi phương thức hoặc mã phản hồi, loại phương tiện và các tùy chọn thành tính năng HTTP
tương ứng. Phần 10 cung cấp thêm chi tiết về ánh xạ HTTP.

2.4 Resource Discovery

Khám phá tài nguyên rất quan trọng đối với các tương tác với máy và máy và được hỗ trợ bằng định
dạng liên kết cốt lõi [RFC6690] như được thảo luận trong Phần 7.

3 Message Format

COAP dựa trên việc trao đổi các message nhỏ gọn, theo mặc định, được vận chuyển qua UDP (nghĩa
là, mỗi thông báo COAP chiếm phần dữ liệu của một datagram UDP). COAP cũng có thể được sử
dụng trên bảo mật lớp vận chuyển Datagram (DTLS) (xem Phần 9.1). Nó cũng có thể được sử dụng
trên các phương tiện vận chuyển khác như SMS, TCP hoặc SCTP, đặc điểm kỹ thuật nằm ngoài phạm
vi tài liệu này. .

Message COAP được mã hóa ở định dạng nhị phân đơn giản. Định dạng message bắt đầu bằng tiêu
đề 4 byte có kích thước cố định. Tiếp theo là một giá trị mã thông báo có độ dài thay đổi, có thể dài
từ 0 đến 8 byte.

Theo giá trị mã thông báo có một chuỗi các tùy chọn COAP bằng 0 hoặc nhiều hơn ở định dạng giá
trị độ dài loại (TLV), tùy chọn theo sau là một payload chiếm phần còn lại của datagram.
Các trường trong tiêu đề được xác định như sau:

Phiên bản (Ver): Số nguyên không dấu 2 bit. Cho biết số phiên bản COAP. Việc triển khai thông số kỹ
thuật này phải đặt trường này thành 1 (01 nhị phân). Các giá trị khác được dành riêng cho các phiên
bản trong tương lai. Message có số phiên bản không xác định phải được bỏ qua âm thầm.

Loại (t): Số nguyên không dấu 2 bit. Cho biết nếu thông báo này là loại có thể xác nhận (0), không thể
xác nhận (1), xác nhận (2) hoặc đặt lại (3). Các ngữ nghĩa của các loại message này được xác định
trong Phần 4.

Độ dài mã thông báo (TKL): Số nguyên không dấu 4 bit. Cho biết độ dài của trường mã thông báo có
độ dài biến (0-8 byte). Độ dài 9-15 được bảo lưu, không được gửi và phải được xử lý như một lỗi
định dạng message.

Mã: Số nguyên không dấu 8 bit, chia thành lớp 3 bit (các bit quan trọng nhất) và chi tiết 5 bit (bit ít
quan trọng nhất), được ghi nhận là "c.dd" trong đó "C" là một chữ số từ 0 đến 7 Đối với trường con
3 bit và "DD" là hai chữ số từ 00 đến 31 cho trường con 5 bit. Lớp có thể chỉ ra một yêu cầu (0), phản
hồi thành công (2), phản hồi lỗi của máy khách (4) hoặc phản hồi lỗi của máy chủ (5). (Tất cả các giá
trị lớp khác được bảo lưu.) Như một trường hợp đặc biệt, mã 0,00 cho biết một thông báo trống.
Trong trường hợp yêu cầu, trường mã chỉ ra phương thức yêu cầu; Trong trường hợp phản hồi, mã
phản hồi. Các giá trị có thể được duy trì trong các cơ quan đăng ký mã COAP (Mục 12.1). Các ngữ
nghĩa của các yêu cầu và phản hồi được xác định trong Phần 5.

ID message: Số nguyên không dấu 16 bit trong thứ tự byte mạng. Được sử dụng để phát hiện sao
chép message và để phù hợp với các message của loại xác nhận/đặt lại với các confirmable
message/không xác nhận được. Các quy tắc để tạo ID message và message phù hợp được xác định
trong Phần 4.

Tiêu đề được theo sau bởi giá trị mã thông báo, có thể là 0 đến 8 byte, như được đưa ra bởi trường
Độ dài mã thông báo. Giá trị mã thông báo được sử dụng để tương quan các yêu cầu và phản hồi.
Các quy tắc để tạo mã thông báo và các yêu cầu và phản hồi tương quan được xác định trong Phần
5.3.1.
Tiêu đề và mã thông báo được theo sau bởi các tùy chọn bằng không hoặc nhiều hơn (Phần 3.1).
Một tùy chọn có thể được theo sau bởi kết thúc của message, bởi một tùy chọn khác hoặc bằng
điểm đánh dấu payload và payload.

Theo tiêu đề, mã thông báo và các tùy chọn, nếu có, payload tùy chọn. Nếu có và có độ dài khác
không, nó được tiền tố bởi điểm đánh dấu payload một byte cố định (0xFF), cho biết kết thúc của
các tùy chọn và bắt đầu payload. Dữ liệu payload kéo dài từ sau khi điểm đánh dấu đến cuối
datagram UDP, tức là độ dài payload được tính từ kích thước datagram. Sự vắng mặt của điểm đánh
dấu payload biểu thị payload độ dài bằng không. Sự hiện diện của một điểm đánh dấu theo sau là
payload có độ dài bằng không phải được xử lý dưới dạng lỗi định dạng message.

Triển khai Lưu ý: Giá trị byte 0xff cũng có thể xảy ra trong một độ dài hoặc giá trị tùy chọn, vì vậy
việc quét byte đơn giản cho 0xFF không phải là một kỹ thuật khả thi để tìm điểm đánh dấu payload.
Byte 0xff có ý nghĩa của điểm đánh dấu payload chỉ khi bắt đầu tùy chọn khác có thể xảy ra.

3.1. Tùy chọn định dạng CoAP xác định một số tùy chọn có thể được bao gồm trong một thông báo.
Mỗi phiên bản tùy chọn trong một thông báo chỉ định số tùy chọn của tùy chọn COAP đã xác định,
độ dài của giá trị tùy chọn và chính giá trị tùy chọn.

Thay vì chỉ định số tùy chọn trực tiếp, các phiên bản phải xuất hiện theo thứ tự số tùy chọn của
chúng và mã hóa delta được sử dụng giữa chúng: số tùy chọn cho mỗi trường hợp được tính là tổng
của delta và số tùy chọn của phiên bản trước trong thông điệp. Đối với trường hợp đầu tiên trong
một message, một thể hiện tùy chọn trước với số tùy chọn Zero được giả định. Nhiều phiên bản của
cùng một tùy chọn có thể được bao gồm bằng cách sử dụng đồng bằng số 0.

Số tùy chọn được duy trì trong sổ đăng ký "Số tùy chọn COAP" (Phần 12.2). Xem Phần 5.4 để biết
ngữ nghĩa của các tùy chọn được xác định trong tài liệu này.
Các trường trong một tùy chọn được xác định như sau: Tùy chọn Delta: Số nguyên không dấu 4 bit.
Giá trị từ 0 đến 12 cho biết tùy chọn Delta. Ba giá trị được dành riêng cho các cấu trúc đặc biệt:

13: Số nguyên không dấu 8 bit tuân theo byte ban đầu và cho biết tùy chọn Delta trừ 13.

14: Số nguyên không dấu 16 bit trong thứ tự byte mạng theo byte ban đầu và chỉ ra tùy chọn Delta
trừ 269.

15: Dành riêng cho điểm đánh dấu payload. Nếu trường được đặt thành giá trị này nhưng toàn bộ
byte không phải là điểm đánh dấu payload, thì điều này phải được xử lý dưới dạng lỗi định dạng
message.

Tùy chọn kết quả Delta được sử dụng làm sự khác biệt giữa số tùy chọn của tùy chọn này và tùy
chọn trước đó (hoặc không cho tùy chọn đầu tiên). Nói cách khác, số tùy chọn được tính bằng cách
tổng hợp các giá trị delta tùy chọn của tất cả các tùy chọn này trước đó.

Độ dài tùy chọn: Số nguyên không dấu 4 bit. Giá trị từ 0 đến 12 cho biết độ dài của giá trị tùy chọn,
tính bằng byte. Ba giá trị được dành cho các cấu trúc đặc biệt:

13: Số nguyên không dấu 8 bit trước giá trị tùy chọn và cho biết độ dài tùy chọn trừ 13.
14: Số nguyên không dấu 16 bit trong thứ tự byte mạng trước giá trị tùy chọn và cho biết độ dài tùy
chọn trừ 269.

15: Dành riêng cho việc sử dụng trong tương lai. Nếu trường được đặt thành giá trị này, nó phải
được xử lý như một lỗi định dạng message.

Giá trị: Một chuỗi có độ dài tùy chọn chính xác. Độ dài và định dạng của giá trị tùy chọn phụ thuộc
vào tùy chọn tương ứng, có thể xác định các giá trị độ dài biến. Xem Phần 3.2 để biết các định dạng
được sử dụng trong tài liệu này; Các tùy chọn được xác định trong các tài liệu khác có thể sử dụng
các định dạng giá trị tùy chọn khác.

3.2. Các định dạng giá trị tùy chọn

Các tùy chọn được xác định trong tài liệu này Sử dụng các định dạng giá trị tùy chọn sau.

trống: một chuỗi không có độ dài của byte.

mờ đục: một chuỗi mờ của byte.

UINT: Một số nguyên không âm được biểu diễn trong thứ tự byte mạng bằng cách sử dụng số byte
được đưa ra bởi trường Độ dài tùy chọn.

Một định nghĩa tùy chọn có thể chỉ định một loạt các số byte cho phép; Nếu nó có một lựa chọn,
người gửi nên đại diện cho số nguyên với càng ít byte càng tốt, tức là, mà không cần dẫn số byte. Ví
dụ: số 0 được biểu thị bằng giá trị tùy chọn trống (trình tự có độ dài không có byte) và số 1 bằng một
byte duy nhất với giá trị số là 1 (kết hợp bit 00000001 trong hầu hết các ký hiệu đầu tiên bit quan
trọng). Một người nhận phải được chuẩn bị để xử lý các giá trị với số byte bằng 0.

Thực hiện Lưu ý: Hành vi đặc biệt được phép cho người gửi được dành cho các triển khai được giới
hạn, được đặt ra (ví dụ: triển khai phần cứng) sử dụng các tùy chọn kích thước cố định trong các
mẫu.

Chuỗi: Một chuỗi unicode được mã hóa bằng UTF-8 [RFC3629] ở dạng net-Unicode [RFC5198].

Lưu ý rằng ở đây, và ở tất cả các nơi khác mà mã hóa UTF-8 được sử dụng trong giao thức COAP, ý
định là các chuỗi được mã hóa có thể được sử dụng trực tiếp và so sánh dưới dạng chuỗi byte mờ
bằng cách triển khai giao thức COAP. Không có kỳ vọng và không cần phải thực hiện bình thường
hóa trong quá trình triển khai COAP (ngoại trừ khi các chuỗi unicode không được biết là được chuẩn
hóa được nhập từ các nguồn bên ngoài giao thức COAP). Cũng lưu ý rằng các chuỗi ASCII (không sử
dụng các ký tự điều khiển đặc biệt) luôn luôn là các chuỗi UTF-8 Net-Unicode hợp lệ.

4. Message Transmission

Thông điệp CoAP được trao đổi không đồng bộ giữa các điểm cuối COAP. Chúng được sử dụng để
vận chuyển các yêu cầu và phản hồi của COAP, ngữ nghĩa được xác định trong Phần 5. Vì CoAP bị
ràng buộc với các phương tiện vận chuyển không đáng tin cậy như UDP, message COAP có thể xuất
hiện theo thứ tự, xuất hiện trùng lặp hoặc bị thiếu mà không cần thông báo trước. Vì lý do này,
COAP thực hiện một cơ chế độ tin cậy nhẹ, mà không cố gắng tạo lại bộ tính năng đầy đủ của bộ vận
chuyển như TCP. Nó có các tính năng sau:
o Độ tin cậy truyền lại dừng và chờ đơn giản với việc quay lại theo cấp số nhân cho các message có
thể xác nhận.

o Phát hiện trùng lặp cho cả message có thể xác nhận và không xác nhận.

4.1. Message và điểm cuối Một điểm cuối COAP là nguồn hoặc đích của thông báo COAP. Định nghĩa
cụ thể của điểm cuối phụ thuộc vào việc vận chuyển được sử dụng cho COAP. Đối với các phương
tiện vận chuyển được xác định trong thông số kỹ thuật này, điểm cuối được xác định tùy thuộc vào
chế độ bảo mật được sử dụng (xem Phần 9): Không có bảo mật, điểm cuối chỉ được xác định bởi địa
chỉ IP và số cổng UDP. Với các chế độ bảo mật khác, điểm cuối được xác định là được xác định bởi
chế độ bảo mật

Có nhiều loại message khác nhau. Loại message được chỉ định bởi trường loại của tiêu đề COAP.

Tách biệt với loại message, message có thể mang theo yêu cầu, phản hồi hoặc trống. Điều này được
báo hiệu bởi trường mã yêu cầu/phản hồi trong tiêu đề COAP và có liên quan đến mô hình yêu
cầu/phản hồi. Các giá trị có thể cho trường được duy trì trong các cơ quan đăng ký mã COAP (phần
12.1).

Một thông báo trống có trường mã được đặt thành 0,00. Trường độ dài mã thông báo phải được
đặt thành 0 và không phải là byte dữ liệu sau trường ID message. Nếu có bất kỳ byte nào, chúng
phải được xử lý như một lỗi định dạng message.

4.2. Các message được truyền một cách đáng tin cậy,

việc truyền message đáng tin cậy được bắt đầu bằng cách đánh dấu message là có thể xác nhận
trong tiêu đề COAP. Một confirmable message luôn mang theo yêu cầu hoặc phản hồi, trừ khi nó chỉ
được sử dụng để gợi ra một thông báo đặt lại, trong trường hợp đó trống. Người nhận phải (a) thừa
nhận một message có thể xác nhận với message xác nhận hoặc (b) từ chối message nếu người nhận
thiếu ngữ cảnh để xử lý message đúng, bao gồm các tình huống trong đó thông báo trống, sử dụng
mã với lớp dành riêng (1 , 6, hoặc 7) hoặc có lỗi định dạng message. Từ chối một message có thể xác
nhận được thực hiện bằng cách gửi message đặt lại phù hợp và nếu không thì bỏ qua nó. Thông báo
xác nhận phải lặp lại ID message của message có thể xác nhận và phải mang theo phản hồi hoặc
trống (xem Phần 5.2.1 và 5.2.2). Thông báo đặt lại phải lặp lại ID message của message có thể xác
nhận và phải trống. Từ chối một xác nhận hoặc message đặt lại (bao gồm cả trường hợp xác nhận
thực hiện yêu cầu hoặc mã với lớp dành riêng hoặc thông báo đặt lại không trống) được thực hiện
bằng cách âm thầm bỏ qua nó. Tổng quát hơn, những người nhận message xác nhận và đặt lại
không được trả lời bằng cách xác nhận hoặc đặt lại message.

Người gửi truyền lại confirmable message trong các khoảng thời gian tăng theo cấp số nhân, cho
đến khi nhận được xác nhận (hoặc đặt lại message) hoặc hết nỗ lực. Truyền lại được kiểm soát bởi
hai điều mà điểm cuối COAP phải theo dõi cho mỗi message có thể xác nhận mà nó gửi trong khi chờ
xác nhận (hoặc đặt lại): thời gian chờ và bộ đếm truyền lại. Đối với một confirmable message mới,
thời gian chờ ban đầu được đặt thành một thời lượng ngẫu nhiên (thường không phải là số giây tích
hợp) giữa ACK_Timeout và (ACK_Timeout * ACK_RANDOM_FACTOR) (xem Phần 4.8) và Bộ đếm
truyền lại được đặt thành 0. Khi thời gian chờ được kích hoạt và bộ đếm truyền lại nhỏ hơn
MAX_RETRANSMIT, thông báo được truyền lại, bộ đếm truyền lại được tăng lên và thời gian chờ
được nhân đôi. Nếu bộ đếm truyền lại đạt đến MAX_RETRANDMIT khi hết thời gian chờ hoặc nếu
điểm cuối nhận được message đặt lại, thì nỗ lực truyền message bị hủy và quy trình ứng dụng được
thông báo về lỗi. Mặt khác, nếu điểm cuối nhận được xác nhận kịp thời, việc truyền tải được coi là
thành công.

Thông số kỹ thuật này không có yêu cầu mạnh mẽ về độ chính xác của đồng hồ được sử dụng để
thực hiện thuật toán ngược theo cấp số nhân nhị phân ở trên. Cụ thể, một điểm cuối có thể bị trễ
đối với việc truyền lại cụ thể do lịch trình ngủ của nó và có thể bắt kịp ở điểm tiếp theo. Tuy nhiên,
khoảng cách tối thiểu trước khi truyền lại là ACK_Timeout và toàn bộ chuỗi truyền (Re-) phải ở trong
phong bì của MAX_Transmit_Span (xem Phần 4.8.2), ngay cả khi điều đó có nghĩa là người gửi có thể
bỏ lỡ cơ hội truyền.

Một điểm cuối COAP đã gửi một message có thể xác nhận có thể từ bỏ khi cố gắng để có được một
ACK ngay cả trước khi đạt được giá trị bộ đếm MAX_RETRANDMIT. Ví dụ, ứng dụng đã hủy yêu cầu
vì nó không còn cần phản hồi, hoặc có một số dấu hiệu khác cho thấy message CON đã đến. Cụ thể,
một thông báo yêu cầu COAP có thể đã gợi ra một phản hồi riêng biệt, trong trường hợp đó rõ ràng
cho người yêu cầu rằng chỉ có ACK bị mất và việc truyền lại yêu cầu sẽ không phục vụ mục đích. Tuy
nhiên, một người trả lời không được dựa vào hành vi chéo này từ một người yêu cầu, tức là, nó phải
giữ lại trạng thái để tạo ACK cho yêu cầu, nếu cần, ngay cả khi một phản hồi có thể xác nhận đã
được người yêu cầu thừa nhận.

Một lý do khác để từ bỏ truyền lại có thể là nhận lỗi ICMP. Nếu mong muốn tính đến các lỗi ICMP,
để giảm thiểu các cuộc tấn công giả mạo tiềm năng, việc triển khai nên cẩn thận để kiểm tra thông
tin về datagram ban đầu trong thông báo ICMP, bao gồm các số cổng và thông tin tiêu đề COAP như
loại message và mã thông báo, ID message ID message và mã thông báo; Nếu điều này là không thể
do các hạn chế của API dịch vụ UDP, các lỗi ICMP nên bị bỏ qua. Gói lỗi quá lớn [RFC4443] ("Cần
phân mảnh và đặt DF" cho IPv4 [RFC0792]) không thể xảy ra đúng và nên bỏ qua nếu lưu ý thực hiện
trong Phần 4.6 được tuân thủ; Mặt khác, chúng nên đưa vào một thuật toán khám phá MTU đường
dẫn [RFC4821]. Nguồn Qench và thời gian vượt quá message ICMP nên được bỏ qua. Máy chủ,
mạng, cổng hoặc giao thức không thể truy cập lỗi hoặc lỗi sự cố tham số có thể, sau khi kiểm tra
thích hợp, được sử dụng để thông báo cho việc áp dụng lỗi trong việc gửi.

4.3. Messages Transmitted without Reliability

Một số message không yêu cầu xác nhận. Điều này đặc biệt đúng đối với các thông điệp được lặp đi
lặp lại thường xuyên cho các yêu cầu ứng dụng, chẳng hạn như các bài đọc lặp đi lặp lại từ một cảm
biến trong đó thành công cuối cùng là đủ. Là một sự thay thế nhẹ hơn, một thông điệp có thể được
truyền đi ít đáng tin cậy hơn bằng cách đánh dấu thông điệp là không thể xác nhận. Một message
không xác nhận luôn mang theo yêu cầu hoặc phản hồi và không được trống. Một thông điệp không
thể xác nhận không được thừa nhận bởi người nhận. Người nhận phải từ chối message nếu thiếu
ngữ cảnh để xử lý thông báo đúng, bao gồm trường hợp thông báo trống, sử dụng mã có lớp dành
riêng (1, 6 hoặc 7) hoặc có lỗi định dạng message. Từ chối một message không xác nhận có thể liên
quan đến việc gửi message đặt lại phù hợp và ngoài message đặt lại, message bị từ chối phải được
bỏ qua âm thầm. Ở cấp độ COAP, không có cách nào để người gửi phát hiện nếu một message
không xác nhận có được nhận được hay không. Người gửi có thể chọn truyền nhiều bản sao của
thông báo không thể xác nhận trong MAX_TransMIT_SPAN (giới hạn bởi các quy định của Mục 4.7,
đặc biệt, bằng cách thăm dò_rate nếu không nhận được phản hồi) hoặc mạng có thể sao chép thông
báo trong quá trình vận chuyển. Để cho phép người nhận chỉ hành động một lần trên message, các
message không thể xác nhận cũng chỉ định ID message. . Hoạt động nhưng chỉ để gợi ra một thông
báo đặt lại ("COAP ping").

4.4. Message Correlation

Một message xác nhận hoặc đặt lại có liên quan đến một message có thể xác nhận hoặc message
không thể xác nhận bằng phương tiện của ID message cùng với thông tin địa chỉ bổ sung của điểm
cuối tương ứng. ID message là một số nguyên không dấu 16 bit được tạo bởi người gửi một
confirmable message hoặc không xác nhận và được đưa vào tiêu đề COAP. ID message phải được
lặp lại trong message xác nhận hoặc đặt lại message của người nhận.

ID message tương tự không được sử dụng lại (trong giao tiếp với cùng một điểm cuối) trong
Exchange_lifetime (Mục 4.8.2).

THỰC HIỆN Lưu ý: Một số chiến lược thực hiện có thể được sử dụng để tạo ID message. Trong
trường hợp đơn giản nhất, điểm cuối COAP tạo ID message bằng cách giữ một biến ID message duy
nhất, được thay đổi mỗi khi một confirmable message hoặc không xác nhận mới được gửi, bất kể
địa chỉ hoặc cổng đích mới. Các điểm cuối liên quan đến số lượng lớn các giao dịch có thể giữ nhiều
biến ID message, ví dụ: trên mỗi tiền tố hoặc địa chỉ đích. . Khởi động) được chọn ngẫu nhiên, để
thực hiện các cuộc tấn công ngoài đường thành công trên giao thức ít có khả năng.

Đối với message xác nhận hoặc đặt lại để khớp với message có thể xác nhận hoặc không xác nhận,
ID message và điểm cuối nguồn của message xác nhận hoặc đặt lại phải khớp với ID message và
điểm cuối đích của message có thể xác nhận hoặc không xác nhận.

4.5. Message Deduplication

Người nhận có thể nhận được cùng một message có thể xác nhận (như được chỉ định bởi ID
message và điểm cuối nguồn) nhiều lần trong Exchange_Lifetime (phần 4.8.2), ví dụ, khi sự thừa
nhận của nó bị mất hết giờ. Người nhận nên xác nhận từng bản sao trùng lặp của một message có
thể xác nhận bằng cách sử dụng cùng một xác nhận hoặc đặt lại message nhưng chỉ nên xử lý bất kỳ
yêu cầu hoặc phản hồi nào trong message chỉ một lần. Quy tắc này có thể được nới lỏng trong
trường hợp message có thể xác nhận vận chuyển một yêu cầu là idempotent (xem Phần 5.1) hoặc có
thể được xử lý theo kiểu idempotent. Ví dụ cho sự sao chép message thư giãn:

o Một máy chủ có thể thư giãn yêu cầu trả lời tất cả các truyền lại của một yêu cầu idempotent với
cùng một phản hồi (Phần 4.2), để nó không phải duy trì trạng thái cho ID message. Ví dụ, việc triển
khai có thể muốn xử lý các lần truyền trùng lặp, đặt hoặc xóa yêu cầu dưới dạng các yêu cầu riêng
biệt nếu nỗ lực phát sinh do xử lý trùng lặp ít tốn kém hơn so với việc theo dõi các phản hồi trước
đó.

o Một máy chủ bị ràng buộc thậm chí có thể muốn thư giãn yêu cầu này đối với các yêu cầu không
có ý kiến nhất định nếu ngữ nghĩa ứng dụng làm cho sự đánh đổi này thuận lợi. Ví dụ: nếu kết quả
của một yêu cầu bài đăng chỉ là việc tạo ra một trạng thái tồn tại ngắn tại máy chủ, thì có thể ít tốn
kém hơn để đưa ra nỗ lực này nhiều lần cho một yêu cầu hơn là theo dõi liệu việc truyền trước cùng
một yêu cầu đã được xử lý.

Người nhận có thể nhận được cùng Non-confirmable message(như được chỉ định bởi ID message và
điểm cuối nguồn) nhiều lần trong Non_lifetime (Mục 4.8.2). Theo nguyên tắc chung có thể được nới
lỏng dựa trên ngữ nghĩa cụ thể của message, người nhận nên âm thầm bỏ qua bất kỳ message
không xác nhận được sao chép nào và nên xử lý bất kỳ yêu cầu hoặc phản hồi nào trong message chỉ
một lần.

4.6. Message Size

Mặc dù các lớp liên kết cụ thể làm cho nó có lợi để giữ cho các message COAP đủ nhỏ để phù hợp
với các gói lớp liên kết của chúng (xem Phần 1), đây là vấn đề về chất lượng thực hiện. Đặc điểm kỹ
thuật COAP chỉ cung cấp một ràng buộc trên với kích thước message. Message lớn hơn một gói IP
dẫn đến phân mảnh gói không mong muốn. Một thông báo COAP, được đóng gói một cách thích
hợp, sẽ phù hợp với một gói IP duy nhất (nghĩa là tránh phân mảnh IP) và (bằng cách khớp với một
payload UDP) rõ ràng cần phải phù hợp với một Datagram IP. Nếu đường dẫn MTU không được biết
đến cho một điểm đến, nên giả sử MTU IP là 1280 byte; Nếu không có gì được biết về kích thước của
các tiêu đề, giới hạn trên tốt là 1152 byte cho kích thước message và 1024 byte cho kích thước
payload. Việc triển khai Lưu ý: Sự lựa chọn của CoAP về các tham số kích thước message hoạt động
tốt với IPv6 và với hầu hết các đường dẫn IPV4 ngày nay. . , giá trị tối thiểu tuyệt đối của IP MTU cho
IPv4 thấp tới 68 byte, điều này sẽ chỉ để lại 40 byte chi phí bảo mật cho payload UDP. Việc triển khai
tập trung vào bộ vấn đề này cũng có thể đặt bit IPv4 DF và thực hiện một số Hình thức khám phá
MTU đường dẫn [RFC4821]; Tuy nhiên, điều này thường không cần thiết trong các trường hợp sử
dụng thực tế cho COAP.) Điều này có thể thúc đẩy các triển khai để được tiết kiệm trong kích thước
gói của họ và chuyển sang chuyển nhượng theo khối [khối] khi tiếp cận kích thước message ba chữ
số. Kích thước message cũng có tầm quan trọng đáng kể đối với việc triển khai trên các nút bị ràng
buộc. Nhiều triển khai sẽ cần phân bổ một bộ đệm cho các message đến. Nếu việc triển khai quá
hạn chế để cho phép phân bổ giới hạn trên được đề cập ở trên, thì nó có thể áp dụng chiến lược
thực hiện sau đây cho các message không sử dụng bảo mật DTLS: triển khai nhận được datagram
vào bộ đệm quá nhỏ thường có thể xác định xem việc theo dõi Một phần của một datagram đã bị
loại bỏ và để lấy phần ban đầu. Vì vậy, ít nhất là tiêu đề và tùy chọn COAP, nếu không phải tất cả các
trọng tải, có khả năng phù hợp với bộ đệm. Do đó, một máy chủ có thể giải thích đầy đủ một yêu
cầu và trả về mã phản hồi 4.13 (yêu cầu quá lớn; xem Phần 5.9.2.9) Mã phản hồi nếu payload bị cắt
ngắn. Một khách hàng gửi một yêu cầu idempotent và nhận phản hồi lớn hơn so với phù hợp với bộ
đệm có thể lặp lại yêu cầu với giá trị phù hợp cho tùy chọn khối [khối].

4.7. Kiểm soát tắc nghẽn Điều khiển tắc nghẽn cơ bản cho COAP được cung cấp bởi cơ chế ngược
theo cấp số nhân trong Phần 4.2. Để không gây tắc nghẽn, máy khách (bao gồm cả proxy) phải giới
hạn nghiêm ngặt số lượng tương tác xuất sắc đồng thời mà họ duy trì cho một máy chủ nhất định
(bao gồm cả proxy) đối với NSTART. Một tương tác nổi bật là một con mà ACK chưa nhận được
nhưng vẫn được mong đợi (lớp message) hoặc yêu cầu mà không phải là một thông báo xác nhận
cũng chưa được nhận nhưng vẫn có thể xảy ra tại Đồng thời, tính là một tương tác nổi bật). Giá trị
mặc định của nstart cho đặc điểm kỹ thuật này là 1. Các tối ưu hóa và cân nhắc kiểm soát tắc nghẽn
hơn nữa trong tương lai, ví dụ có thể cung cấp tự động khởi tạo các tham số truyền COAP được xác
định trong Phần 4.8, và do đó có thể cho phép giá trị cho NSTART lớn hơn một . Sau khi
Exchange_Lifetime, một khách hàng ngừng mong đợi phản hồi cho một yêu cầu có thể xác nhận mà
không nhận được message xác nhận nào.

Thuật toán cụ thể mà khách hàng dừng lại để "mong đợi" phản hồi cho một yêu cầu có thể xác nhận
được xác nhận hoặc yêu cầu không thể xác nhận, không được xác định. Trừ khi điều này được sửa
đổi bởi các tối ưu hóa kiểm soát tắc nghẽn bổ sung, nó phải được chọn theo cách mà điểm cuối
không vượt quá tốc độ dữ liệu trung bình của Probing_rate khi gửi đến điểm cuối khác không phản
hồi. LƯU Ý: COAP đặt trách nhiệm kiểm soát tắc nghẽn chủ yếu vào khách hàng. Tuy nhiên, khách
hàng có thể bị trục trặc hoặc thực sự là kẻ tấn công, ví dụ, để thực hiện các cuộc tấn công khuếch
đại (phần 11.3). Để hạn chế thiệt hại (đối với mạng và tài nguyên năng lượng của chính nó), một máy
chủ nên thực hiện một số giới hạn tốc độ đối với việc truyền phản hồi dựa trên các giả định hợp lý
về các yêu cầu ứng dụng. Điều này là hữu ích nhất nếu chỉ giới hạn tỷ lệ có thể được thực hiện hiệu
quả đối với các điểm cuối sai. 4.8. Truyền truyền thông báo Truyền thông báo được điều khiển bởi
các tham số sau:

4.8.1. Thay đổi các tham số Các giá trị cho ACK_Timeout, ACK_Random_Factor, MAX_RETRANDMIT,
NSTART, DEFAULT_LEISURE (Phần 8.2) và Probing_rate có thể được cấu hình thành các giá trị cụ thể
cho môi trường ứng dụng (bao gồm các giá trị được điều chỉnh động); Tuy nhiên, phương thức cấu
hình nằm ngoài phạm vi của tài liệu này. Khuyến cáo rằng môi trường ứng dụng sử dụng các giá trị
nhất quán cho các tham số này; Các tác động cụ thể của hoạt động với các giá trị không nhất quán
trong môi trường ứng dụng nằm ngoài phạm vi của thông số kỹ thuật hiện tại. Các thông số truyền
tải đã được chọn để đạt được một hành vi với sự hiện diện của tắc nghẽn an toàn trên internet. Nếu
cấu hình mong muốn sử dụng các giá trị khác nhau, thì trách nhiệm Cấu hình để đảm bảo các thuộc
tính kiểm soát tắc nghẽn này không bị vi phạm. Cụ thể, việc giảm ACK_Timeout dưới 1 giây sẽ vi
phạm các hướng dẫn của [RFC5405]. . Tuy nhiên, nơi mong muốn giảm đáng kể ack_timeout hoặc
tăng nstart, điều này chỉ có thể được thực hiện một cách an toàn khi duy trì các phép đo đó. Cấu
hình không được giảm Ack_Timeout hoặc tăng NSTART mà không sử dụng các cơ chế đảm bảo an
toàn kiểm soát tắc nghẽn, được xác định trong cấu hình hoặc trong các tài liệu tiêu chuẩn trong
tương lai. ACK_RANDOM_FACTOR không được giảm dưới 1.0 và nó phải có một giá trị đủ khác với
1.0 để cung cấp một số bảo vệ khỏi các hiệu ứng đồng bộ hóa. MAX_RETRANDMIT có thể được điều
chỉnh tự do, nhưng một giá trị quá nhỏ sẽ làm giảm xác suất thực sự nhận được confirmable
message, trong khi giá trị lớn hơn được đưa ra ở đây sẽ yêu cầu điều chỉnh thêm trong các giá trị
thời gian (xem Phần 4.8.2). Nếu việc lựa chọn các tham số truyền dẫn đến tăng các giá trị thời gian
dẫn xuất (xem Phần 4.8.2), cơ chế cấu hình phải đảm bảo giá trị được điều chỉnh cũng có sẵn cho tất
cả các điểm cuối mà các giá trị được điều chỉnh này sẽ được sử dụng để giao tiếp. 4.8.2. Các giá trị
thời gian xuất phát từ các tham số truyền sự kết hợp của ack_timeout, ack_random_factor và
max_retransmit ảnh hưởng đến thời gian truyền lại, từ đó ảnh hưởng đến thời gian một số mục
thông tin nhất định cần được lưu giữ khi thực hiện. Để có thể tham chiếu rõ ràng các giá trị thời gian
xuất phát này, chúng tôi cung cấp cho chúng các tên như sau: o max_transmit_span là thời gian tối
đa từ lần truyền đầu tiên của một confirmable message đến truyền lại cuối cùng. Đối với các tham
số truyền mặc định, giá trị là (2+4+8+16) * 1.5 = 45 giây hoặc nói chung hơn: ack_timeout * ((2 **
max_retransmit) - 1) *

o max_transmit_wait là thời gian tối đa từ lần truyền đầu tiên của một confirmable message đến
thời điểm người gửi từ bỏ khi nhận được xác nhận hoặc đặt lại. Đối với các tham số truyền mặc
định, giá trị là (2+4+8+16+32) * 1.5 = 93 giây, hay nói chung hơn: ack_timeout * ((2 **
(max_retransmit+1)) - 1) , một số giả định cần được thực hiện trên các đặc điểm của mạng và các
nút. o max_latency là thời gian tối đa mà một datagram dự kiến sẽ nhận được từ khi bắt đầu truyền
đến việc hoàn thành việc tiếp nhận của nó. Hằng số này có liên quan đến MSL (tuổi thọ tối đa) của
[RFC0793], được "được xác định tùy ý là 2 phút" ([RFC0793] Thuật ngữ, trang 81). Lưu ý rằng điều
này không nhất thiết phải nhỏ hơn max_transmit_wait, vì MAX_LATENCY không nhằm mô tả tình
huống khi giao thức hoạt động tốt, nhưng tình huống tồi tệ nhất mà giao thức phải bảo vệ. Chúng
tôi, cũng tùy ý, định nghĩa Max_Latency là 100 giây. Ngoài việc thực tế một cách hợp lý đối với phần
lớn các cấu hình cũng như gần với sự lựa chọn lịch sử cho TCP, giá trị này còn cho phép các bộ hẹn
giờ trọn đời ID message được thể hiện trong 8 bit (khi được đo bằng giây). Trong các tính toán này,
không có giả định rằng hướng truyền là không liên quan (tức là, mạng là đối xứng); Chỉ có giả định
rằng cùng một giá trị có thể được sử dụng một cách hợp lý như một giá trị tối đa cho cả hai hướng.
Nếu đó không phải là trường hợp, các tính toán sau đây chỉ trở nên phức tạp hơn một chút. o
Processing_delay là thời gian một nút thực hiện để biến một confirmable message thành một xác
nhận. Chúng tôi giả sử nút sẽ cố gắng gửi một ACK trước khi hết thời gian người gửi, vì vậy như một
giả định bảo thủ, chúng tôi đặt nó bằng với ack_timeout. o max_rtt là thời gian khứ hồi tối đa, hoặc:
(2 * max_latency) + processing_delay từ các giá trị này, chúng ta có thể lấy các giá trị sau có liên
quan đến hoạt động giao thức: o exchange_lifetime là thời gian bắt đầu gửi confirmable message
cho đến thời điểm Khi một xác nhận không còn được mong đợi, tức là, thông tin lớp message về
trao đổi message có thể được thanh trừng. Exchange_lifetime bao gồm Max_Transmit_Span,
chuyển tiếp MAX_LATENCY, Processing_Delay và Max_Latency cho

đường về. Lưu ý rằng không cần phải xem xét max_transmit_wait nếu cấu hình được chọn sao cho
khoảng thời gian chờ cuối cùng (ack_timeout * (2 ** max_retransmit) hoặc sự khác biệt giữa
MAX_Transmit_Span và Max_Transmit_wait) Max_Latency là một giá trị trường hợp xấu nhất khó
có thể được đáp ứng trong thế giới thực. Trong trường hợp này, Exchange_Lifetime đơn giản hóa
thành: MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + Processing_Delay hoặc 247 giây với các tham
số truyền mặc định. o Non_lifetime là thời gian từ việc gửi một message không thể xác nhận đến
thời điểm ID message của nó có thể được sử dụng lại một cách an toàn. Nếu nhiều truyền message
không được sử dụng, giá trị của nó là MAX_LATENCY hoặc 100 giây. Tuy nhiên, người gửi COAP có
thể gửi message không nhiều lần, đặc biệt là cho các ứng dụng phát đa hướng. Mặc dù giai đoạn tái
sử dụng không bị giới hạn bởi đặc điểm kỹ thuật, nhưng kỳ vọng phát hiện sự trùng lặp đáng tin cậy
tại máy thu là trong khoảng thời gian của MAX_Transmit_Span. Do đó, với mục đích này, sẽ an toàn
hơn khi sử dụng giá trị: max_transmit_span + max_latency hoặc 145 giây với các tham số truyền
mặc định; Tuy nhiên, việc triển khai chỉ muốn sử dụng một giá trị thời gian chờ duy nhất cho ID
message đã nghỉ hưu có thể sử dụng một cách an toàn giá trị lớn hơn cho Exchange_Lifetime. Bảng
3 liệt kê các tham số dẫn xuất được giới thiệu trong tiểu mục này với các giá trị mặc định của chúng.

5. Yêu cầu/Phản hồi ngữ nghĩa COAP hoạt động theo mô hình yêu cầu/phản hồi tương tự như HTTP:
Điểm cuối COAP trong vai trò của "máy khách" gửi một hoặc nhiều yêu cầu COAP đến "máy chủ",
dịch vụ các yêu cầu bằng cách gửi phản hồi COAP. Không giống như HTTP, các yêu cầu và phản hồi
không được gửi qua kết nối được thiết lập trước đó nhưng được trao đổi không đồng bộ qua các
message COAP. 5.1. Yêu cầu yêu cầu COAP bao gồm phương thức được áp dụng cho tài nguyên,
định danh của tài nguyên, payload và loại phương tiện Internet (nếu có) và siêu dữ liệu tùy chọn về
yêu cầu. COAP hỗ trợ các phương pháp cơ bản của GET, POST, PUT và XÓA, dễ dàng được ánh xạ tới
HTTP. Chúng có cùng các thuộc tính của an toàn (chỉ truy xuất) và idempotent (bạn có thể gọi nó
nhiều lần với cùng một hiệu ứng) như HTTP (xem Phần 9.1 của [RFC2616]). Phương pháp GET là an
toàn; Do đó, nó không được thực hiện bất kỳ hành động nào khác trên một tài nguyên khác ngoài
việc truy xuất. Các phương thức GET, đặt và xóa phải được thực hiện theo cách mà chúng không ổn
định. Bài đăng không phải là idempotent, bởi vì hiệu ứng của nó được xác định bởi máy chủ gốc và
phụ thuộc vào tài nguyên đích; Nó thường dẫn đến một tài nguyên mới đang được tạo hoặc tài
nguyên mục tiêu được cập nhật. Một yêu cầu được bắt đầu bằng cách đặt trường mã trong tiêu đề
COAP của một confirmable message hoặc không xác nhận cho mã phương thức và bao gồm thông
tin yêu cầu. Các phương pháp được sử dụng trong các yêu cầu được mô tả chi tiết trong Phần 5.8.
5.2. Các phản hồi sau khi nhận và giải thích yêu cầu, máy chủ trả lời với phản hồi COAP được khớp
với yêu cầu bằng mã thông báo được tạo của máy khách (Phần 5.3); Lưu ý rằng điều này khác với ID
message phù hợp với một confirmable message với xác nhận của nó. Một phản hồi được xác định
bởi trường mã trong tiêu đề COAP được đặt thành mã phản hồi. Tương tự như mã trạng thái HTTP,
mã phản hồi COAP cho biết kết quả của nỗ lực hiểu và đáp ứng yêu cầu. Các mã này được xác định
đầy đủ trong Phần 5.9. Các số mã phản hồi được đặt trong trường mã của tiêu đề COAP được duy trì
trong Cơ quan đăng ký mã phản hồi COAP (Mục 12.1.2).

Ba bit trên của số mã phản hồi 8 bit xác định lớp phản hồi. Năm bit thấp hơn không có bất kỳ vai trò
phân loại nào; Họ cung cấp thêm chi tiết cho lớp tổng thể (Hình 9). Là một ký hiệu có thể đọc được
cho con người cho các thông số kỹ thuật và chẩn đoán giao thức, các số mã COAP bao gồm mã phản
hồi được ghi lại ở định dạng "c.dd", trong đó "C" là lớp theo số thập phân và "DD" là chi tiết như hai
-Phigit thập phân. Ví dụ: "Cấm" được viết là 4.03-chỉ ra giá trị mã 8 bit của thập lục phân 0x83
(4*0x20+3) hoặc thập phân 131 (4*32+3). Có 3 lớp mã phản hồi: 2 - Thành công: Yêu cầu đã được
nhận, hiểu và chấp nhận thành công. 4 - Lỗi máy khách: Yêu cầu chứa cú pháp xấu hoặc không thể
thực hiện được. 5 - Lỗi máy chủ: Máy chủ không thực hiện được yêu cầu rõ ràng hợp lệ. Các mã
phản hồi được thiết kế để mở rộng: mã phản hồi trong lớp lỗi máy khách hoặc lớp lỗi máy chủ
không được công nhận bởi điểm cuối được coi là tương đương với mã phản hồi chung của lớp đó
(lần lượt là 4,00 và 5,00). Tuy nhiên, không có mã phản hồi chung nào cho thấy thành công, do đó,
mã phản hồi trong lớp thành công không được công nhận bởi điểm cuối chỉ có thể được sử dụng để
xác định rằng yêu cầu đã thành công mà không có thêm thông tin chi tiết nào. Các mã phản hồi có
thể được mô tả chi tiết trong Phần 5.9. Phản hồi có thể được gửi theo nhiều cách, được xác định
trong các tiểu mục sau.

5.2.1. Bạch cõng Trong trường hợp cơ bản nhất, phản hồi được thực hiện trực tiếp trong thông báo
xác nhận thừa nhận yêu cầu (yêu cầu yêu cầu được thực hiện trong một confirmable message). Đây
được gọi là "phản ứng cõng". Phản hồi được trả về trong thông báo xác nhận, không phụ thuộc vào
việc phản hồi cho biết thành công hay thất bại. Trong thực tế, phản hồi được cõng trên thông báo
xác nhận và không cần message riêng để trả về phản hồi. THỰC HIỆN Lưu ý: Giao thức để lại quyết
định có nên cõng phản hồi hay không (nghĩa là gửi phản hồi riêng) cho máy chủ. Khách hàng phải
được chuẩn bị để nhận. Ở cấp độ chất lượng thực hiện, có một kỳ vọng mạnh mẽ là các máy chủ sẽ
triển khai mã để cõng bất cứ khi nào có thể-tiết kiệm tài nguyên trong mạng và cả tại máy khách và
tại máy chủ. 5.2.2. Tách có thể không thể trả lại một phản ứng cõng trong mọi trường hợp. Ví dụ:
một máy chủ có thể cần lâu hơn để có được biểu diễn tài nguyên được yêu cầu hơn là nó có thể chờ
để gửi lại thông báo xác nhận, mà không liên quan đến khách hàng liên tục truyền lại thông báo yêu
cầu (xem thêm thảo luận về xử lý_delay trong Phần 4.8.2). Phản hồi cho một yêu cầu được thực hiện
trong một message không thể xác nhận luôn được gửi riêng (vì không có thông báo xác nhận). Một
cách để thực hiện điều này trong một máy chủ là bắt đầu nỗ lực để có được biểu diễn tài nguyên và,
trong khi đó đang được tiến hành, thời gian ra một bộ đếm thời gian xác nhận. Một máy chủ cũng có
thể ngay lập tức gửi một xác nhận nếu nó biết trước rằng sẽ không có phản hồi cõng. Trong cả hai
trường hợp, sự thừa nhận một cách hiệu quả là một lời hứa rằng yêu cầu sẽ được thực hiện sau này.
Khi máy chủ cuối cùng đã có được biểu diễn tài nguyên, nó sẽ gửi phản hồi. Khi mong muốn rằng
message này không bị mất, nó được gửi dưới dạng message có thể xác nhận từ máy chủ đến máy
khách và được khách hàng trả lời với xác nhận, lặp lại ID message mới do máy chủ chọn. . Khi máy
chủ gửi lại một xác nhận trống, nó không được gửi lại

Phản hồi trong một xác nhận khác, ngay cả khi khách hàng truy xuất một yêu cầu giống hệt nhau.
Nếu nhận được yêu cầu truyền lại (có lẽ vì xác nhận ban đầu bị trì hoãn), một xác nhận trống khác sẽ
được gửi và bất kỳ phản hồi nào phải được gửi dưới dạng phản hồi riêng. Nếu máy chủ sau đó gửi
một phản hồi có thể xác nhận, sự xác nhận của khách hàng đối với phản hồi đó cũng phải là một
thông báo trống (một thông báo không mang theo yêu cầu cũng như phản hồi). Máy chủ phải ngừng
truyền lại phản hồi của mình trên bất kỳ xác nhận phù hợp nào (âm thầm bỏ qua bất kỳ mã phản hồi
hoặc payload nào) hoặc đặt lại message. Ghi chú triển khai: Lưu ý rằng, vì vận chuyển Datagram cơ
bản có thể không được bảo tồn trình tự, confirmable message mang phản hồi thực sự có thể đến
trước hoặc sau message xác nhận cho yêu cầu; Đối với các mục đích chấm dứt trình tự truyền lại,
điều này cũng đóng vai trò là một sự thừa nhận. Cũng lưu ý rằng, trong khi bản thân giao thức COAP
không đưa ra bất kỳ yêu cầu cụ thể nào ở đây, nhưng có một kỳ vọng rằng phản hồi sẽ đến trong
khung thời gian hợp lý từ quan điểm ứng dụng. Vì không có giao thức vận chuyển cơ bản nào có thể
được hướng dẫn để chạy một cơ chế tồn tại, nên người yêu cầu có thể muốn thiết lập thời gian chờ
không liên quan đến bộ định thời truyền lại của CoAP trong trường hợp máy chủ bị phá hủy hoặc
không thể gửi phản hồi. 5.2.3. Không thể xác nhận nếu thông báo yêu cầu không thể xác nhận, thì
phản hồi cũng sẽ được trả về trong một thông báo không thể xác nhận. Tuy nhiên, một điểm cuối
phải được chuẩn bị để nhận được phản hồi không thể xác nhận (trước hoặc theo sau là một thông
báo xác nhận trống) để trả lời yêu cầu có thể xác nhận hoặc phản hồi có thể xác nhận để trả lời yêu
cầu không thể xác nhận. 5.3. Yêu cầu/Phản hồi khớp bất kể cách gửi phản hồi, nó được khớp với yêu
cầu bằng mã thông báo được khách hàng đưa vào trong yêu cầu, cùng với thông tin địa chỉ bổ sung
của điểm cuối tương ứng. 5.3.1. Mã thông báo Mã thông báo được sử dụng để phù hợp với phản
hồi với yêu cầu. Giá trị mã thông báo là một chuỗi từ 0 đến 8 byte. .

Một mã thông báo được dự định để sử dụng làm mã định danh khách hàng để phân biệt giữa các
yêu cầu đồng thời (xem Phần 5.3); Nó có thể được gọi là "ID yêu cầu". Máy khách nên tạo mã thông
báo theo cách mà các mã thông báo hiện đang được sử dụng cho một cặp điểm cuối nguồn/đích
nhất định là duy nhất. (Lưu ý rằng việc triển khai máy khách có thể sử dụng cùng một mã thông báo
cho bất kỳ yêu cầu nào nếu nó sử dụng điểm cuối khác mỗi lần, ví dụ: số cổng nguồn khác , hoặc khi
các yêu cầu được thực hiện một cách tự do cho mỗi điểm đến và nhận được phản hồi cõng. Tuy
nhiên, có nhiều chiến lược thực hiện có thể để thực hiện điều này. Một khách hàng gửi yêu cầu mà
không sử dụng bảo mật lớp vận chuyển (Phần 9) nên sử dụng mã thông báo ngẫu nhiên, không cần
thiết để bảo vệ chống giả mạo phản hồi (Phần 11.4). Việc sử dụng mã thông báo bảo vệ này là lý do
chúng được phép có kích thước lên đến 8 byte. Kích thước thực tế của thành phần ngẫu nhiên được
sử dụng cho mã thông báo phụ thuộc vào các yêu cầu bảo mật của máy khách và mức độ đe dọa do
giả mạo phản hồi. Một khách hàng được kết nối với Internet chung nên sử dụng ít nhất 32 bit ngẫu
nhiên, hãy nhớ rằng việc không được kết nối trực tiếp với Internet không nhất thiết phải bảo vệ đầy
đủ để chống giả mạo. . (ví dụ: bằng cách kiểm đếm sự không phù hợp về mã thông báo gần đây
trong các message đến) và điều chỉnh độ dài mã thông báo trở lên một cách thích hợp. [RFC4086]
Thảo luận về các yêu cầu ngẫu nhiên về bảo mật. Điểm cuối nhận được mã thông báo mà nó không
tạo ra phải coi mã thông báo là mờ đục và không đưa ra giả định nào về nội dung hoặc cấu trúc của
nó.

5.3.2. Quy tắc phù hợp yêu cầu/phản hồi Các quy tắc chính xác để khớp một phản hồi với yêu cầu
như sau: 1. Điểm cuối nguồn của phản hồi phải giống như điểm cuối đích của yêu cầu ban đầu. 2.
Trong một phản hồi cõng, ID message của yêu cầu có thể xác nhận và xác nhận phải khớp và mã
thông báo của phản hồi và yêu cầu ban đầu phải khớp. Trong một phản hồi riêng biệt, chỉ các mã
thông báo của phản hồi và yêu cầu ban đầu phải khớp.

Trong trường hợp một thông báo mang phản hồi là bất ngờ (máy khách không chờ phản hồi từ điểm
cuối được xác định, tại điểm cuối được giải quyết và/hoặc với mã thông báo được cho), phản hồi bị
từ chối (Phần 4.2 và 4.3). Triển khai Lưu ý: Một khách hàng nhận được phản hồi trong message CON
có thể muốn dọn sạch trạng thái message ngay sau khi gửi ACK. Nếu ACK đó bị mất và máy chủ sẽ
truyền lại CON, máy khách có thể không còn bất kỳ trạng thái nào để tương quan phản hồi này, làm
cho việc truyền lại trở thành một thông báo bất ngờ; Khách hàng có thể sẽ gửi message đặt lại để nó
không nhận được bất kỳ truyền lại nào nữa. Hành vi này là bình thường và không phải là một dấu
hiệu của một lỗi. .

5.4. Tùy chọn cả yêu cầu và phản hồi có thể bao gồm danh sách một hoặc nhiều tùy chọn. Ví dụ, URI
trong một yêu cầu được vận chuyển trong một số tùy chọn và siêu dữ liệu sẽ được thực hiện trong
tiêu đề HTTP trong HTTP cũng được cung cấp dưới dạng tùy chọn. COAP xác định một bộ tùy chọn
duy nhất được sử dụng trong cả hai yêu cầu và phản hồi: o định dạng nội dung o etag o vị trí đường
dẫn địa điểm o query o Max-age o proxy-uri o proxy-scheme o uri-host o uri-path o Uri-port

o uri-query o Chấp nhận o if-match o if-none-match o size1 Các ngữ nghĩa của các tùy chọn này cùng
với các thuộc tính của chúng được xác định chi tiết trong Phần 5.10. Không phải tất cả các tùy chọn
được xác định để sử dụng với tất cả các phương thức và mã phản hồi. Các tùy chọn có thể cho các
phương thức và mã phản hồi được xác định trong phần 5.8 và 5,9, tương ứng. Trong trường hợp
một tùy chọn không được xác định cho một phương thức hoặc mã phản hồi, nó không được đưa
vào bởi người gửi và phải được đối xử như một tùy chọn không được người nhận không nhận ra.
5.4.1. Các tùy chọn quan trọng/tự chọn rơi vào một trong hai lớp: "phê bình" hoặc "tự chọn". Sự
khác biệt giữa những điều này là cách một tùy chọn không được công nhận bởi một điểm cuối được
xử lý: o khi tiếp nhận, các tùy chọn không được công nhận của lớp "tự chọn" phải được bỏ qua âm
thầm. o Các tùy chọn không được công nhận của lớp "quan trọng" xảy ra trong một yêu cầu có thể
xác nhận phải gây ra sự trở lại của phản hồi 4.02 (tùy chọn xấu). Phản hồi này nên bao gồm một
payload chẩn đoán mô tả (các) tùy chọn không được công nhận (xem Phần 5.5.2). o Các tùy chọn
không được công nhận của lớp "quan trọng" xảy ra trong một phản ứng có thể xác nhận hoặc cõng
trong xác nhận, phải khiến phản hồi bị từ chối (Mục 4.2). o Các tùy chọn không được công nhận của
lớp "quan trọng" xảy ra trong một message không thể xác nhận phải khiến thông báo bị từ chối
(Phần 4.3). Lưu ý rằng, cho dù quan trọng hay tự chọn, một tùy chọn không bao giờ là "bắt buộc"
(luôn luôn là tùy chọn): các quy tắc này được xác định để cho phép triển khai dừng các tùy chọn xử
lý mà họ không hiểu hoặc thực hiện.

Các quy tắc quan trọng/tự chọn áp dụng cho các điểm cuối không proxying. Một quy trình proxy các
tùy chọn dựa trên các lớp không an toàn/an toàn đến chuyển tiếp như được định nghĩa trong Phần
5.7. 5.4.2. Proxy không an toàn hoặc an toàn để chuyển tiếp và Nocachekey ngoài một tùy chọn
được đánh dấu là quan trọng hoặc tự chọn, các tùy chọn cũng được phân loại dựa trên cách một
proxy đối phó với tùy chọn nếu nó không nhận ra nó. Với mục đích này, một tùy chọn có thể được
coi là không an toàn để chuyển tiếp (không an toàn được đặt) hoặc an toàn để chuyển tiếp (không
an toàn là rõ ràng). Ngoài ra, đối với một tùy chọn được đánh dấu an toàn để chuyển tiếp, số tùy
chọn cho biết liệu nó có được dự định là một phần của khóa đệm (Phần 5.6) trong một yêu cầu hay
không. Nếu một số bit Nocachekey là 0, thì đó là; Nếu tất cả các bit Nocachekey là 1, thì không (xem
Phần 5.4.6). Lưu ý: Chỉ báo khóa đệm chỉ có liên quan đối với các proxy không thực hiện tùy chọn đã
cho làm tùy chọn yêu cầu và thay vào đó chỉ dựa vào chỉ báo không an toàn/an toàn để chuyển tiếp.
Ví dụ, đối với ETAG, thực sự sử dụng tùy chọn yêu cầu như một phần của khóa đệm là không hiệu
quả, nhưng đó là điều tốt nhất người ta có thể làm nếu ETAG không được thực hiện bởi proxy, vì
phản hồi sẽ khác nhau dựa trên sự hiện diện của tùy chọn yêu cầu. Một proxy hữu ích hơn thực hiện
tùy chọn yêu cầu ETAG là không sử dụng ETAG như một phần của khóa đệm. NocacheKey được chỉ
định trong ba bit để chỉ có một trong số tám CodePoint đủ điều kiện là Nocachekey, để lại bảy trong
số tám điểm codePoint cho những gì dường như là trường hợp có nhiều khả năng hơn. Hành vi
proxy liên quan đến các lớp này được xác định trong Phần 5.7. 5.4.3. Các giá trị tùy chọn độ dài
được xác định là có độ dài cụ thể, thường ở dạng giới hạn trên và dưới. Nếu độ dài của giá trị tùy
chọn trong một yêu cầu nằm ngoài phạm vi được xác định, tùy chọn đó phải được xử lý như một tùy
chọn không được công nhận (xem Phần 5.4.1). 5.4.4. Tùy chọn giá trị mặc định có thể được xác định
là có giá trị mặc định. Nếu giá trị của một tùy chọn được dự định là giá trị mặc định này, tùy chọn
không nên được đưa vào thông báo. Nếu tùy chọn không có, giá trị mặc định phải được giả định.

Trong trường hợp một tùy chọn quan trọng có giá trị mặc định, điều này được chọn theo cách mà sự
vắng mặt của tùy chọn trong thông báo có thể được xử lý đúng cách cả hai bằng cách triển khai
không biết về tùy chọn quan trọng và bằng cách triển khai giải thích sự vắng mặt này là sự hiện diện
của mặc định Giá trị cho tùy chọn. 5.4.5. Tùy chọn lặp lại Định nghĩa của một số tùy chọn chỉ định
rằng các tùy chọn đó có thể lặp lại. Một tùy chọn có thể lặp lại có thể được bao gồm một hoặc nhiều
lần trong một message. Một tùy chọn không thể lặp lại không được bao gồm nhiều hơn một lần
trong một message. Nếu một thông báo bao gồm một tùy chọn có nhiều lần xuất hiện hơn tùy chọn
được xác định, thì mỗi tùy chọn siêu nhân xuất hiện sau đó trong thông báo phải được xử lý như
một tùy chọn không được nhận ra (xem Phần 5.4.1). 5.4.6. Số tùy chọn Một tùy chọn được xác định
bởi một số tùy chọn, cũng cung cấp một số thông tin ngữ nghĩa bổ sung, ví dụ: số lẻ cho thấy một
tùy chọn quan trọng, trong khi các số thậm chí cho thấy một tùy chọn tự chọn. Lưu ý rằng đây không
chỉ là một quy ước, nó là một tính năng của giao thức: liệu một tùy chọn là tự chọn hay quan trọng
hoàn toàn được xác định bởi liệu số tùy chọn của nó là chẵn hay lẻ. Nói chung, một số tùy chọn
được xây dựng với một chút mặt nạ để cho biết liệu một tùy chọn là quan trọng hay tự chọn, không
an toàn hoặc an toàn để chuyển tiếp, và trong trường hợp an toàn để chuyển tiếp, để cung cấp một
chỉ dẫn khóa đệm như thể hiện bởi hình sau đây. Trong văn bản sau, mặt nạ bit được biểu thị dưới
dạng một byte duy nhất được áp dụng cho byte ít có ý nghĩa nhất của số tùy chọn trong biểu diễn số
nguyên không dấu. Khi bit 7 (bit ít quan trọng nhất) là 1, một tùy chọn là rất quan trọng (và tương tự
như vậy khi tự chọn khi 0). Khi bit 6 là 1, một tùy chọn không an toàn (và tương tự như vậy là an
toàn để chuyển tiếp khi 0). Khi bit 6 là 0, tức là, tùy chọn không an toàn, nó không phải là khóa đệm
(NocacheKey) khi và chỉ khi bit 3-5 được đặt thành 1; Tất cả các kết hợp bit khác có nghĩa là nó thực
sự là một khóa đệm. Các lớp tùy chọn này được giải thích trong các phần tiếp theo.

Điểm cuối có thể sử dụng tương đương của mã C trong Hình 11 để lấy các đặc điểm của một số tùy
chọn "onum". Quan trọng = (onum & 1); Không an toàn = (onum & 2); NocacheKey = ((onum & 0x1e)
== 0x1c); Hình 11: Xác định các đặc điểm từ số tùy chọn Số tùy chọn cho các tùy chọn được xác định
trong tài liệu này được liệt kê trong sổ đăng ký "Số tùy chọn COAP" (Phần 12.2). 5.5. Payload và biểu
diễn cả hai yêu cầu và phản hồi có thể bao gồm payload, tùy thuộc vào phương thức hoặc mã phản
hồi, tương ứng. Nếu một phương thức hoặc mã phản hồi không được xác định để có payload, thì
người gửi không được bao gồm một và người nhận phải bỏ qua nó. 5.5.1. Biểu diễn payload của các
yêu cầu hoặc của các phản hồi cho thấy thành công thường là đại diện của một tài nguyên ("đại diện
tài nguyên") hoặc kết quả của hành động được yêu cầu ("kết quả hành động"). Định dạng của nó
được chỉ định bởi loại phương tiện Internet và mã hóa nội dung được đưa ra bởi tùy chọn định dạng
nội dung. Trong trường hợp không có tùy chọn này, không có giá trị mặc định nào được giả định và
định dạng sẽ cần được suy ra bởi ứng dụng (ví dụ: từ bối cảnh ứng dụng). Payload "Sniffing" chỉ nên
được thử nếu không có loại nội dung nào được đưa ra. Việc thực hiện Lưu ý: Ở cấp độ chất lượng
thực hiện, có một kỳ vọng mạnh mẽ rằng một chỉ định định dạng nội dung sẽ được cung cấp các
biểu diễn tài nguyên bất cứ khi nào có thể. Đây không phải là một yêu cầu cấp độ "nên" chỉ vì nó
không phải là yêu cầu giao thức và cũng sẽ rất khó để phác thảo chính xác trong những trường hợp
kỳ vọng này có thể bị vi phạm. Đối với các phản hồi cho biết lỗi máy khách hoặc máy chủ, payload
được coi là biểu diễn kết quả của hành động được yêu cầu chỉ khi tùy chọn định dạng nội dung được
đưa ra. Trong trường hợp không có tùy chọn này, payload là payload chẩn đoán (Phần 5.5.2).
5.5.2. Payload chẩn đoán Nếu không có tùy chọn định dạng nội dung, payload của các phản hồi cho
biết lỗi máy khách hoặc máy chủ là một thông báo chẩn đoán có thể đọc được ngắn gọn, giải thích
tình huống lỗi. Thông báo chẩn đoán này phải được mã hóa bằng UTF-8 [RFC3629], cụ thể hơn bằng
cách sử dụng Mẫu Net-Unicode [RFC5198]. Thông báo tương tự như cụm từ lý do trên dòng trạng
thái HTTP. Nó không dành cho người dùng cuối nhưng đối với các kỹ sư phần mềm, trong quá trình
gỡ lỗi cần phải diễn giải nó trong bối cảnh của đặc điểm kỹ thuật tiếng Anh hiện tại; Do đó, không
cần cơ chế gắn thẻ ngôn ngữ hoặc được cung cấp. Trái ngược với những gì thông thường trong
HTTP, payload sẽ trống nếu không có thông tin bổ sung nào ngoài mã phản hồi. 5.5.3. Biểu diễn
được chọn không phải tất cả các phản hồi đều mang payload cung cấp một đại diện của tài nguyên
được giải quyết theo yêu cầu. Tuy nhiên, đôi khi, đôi khi hữu ích để có thể đề cập đến một đại diện
như vậy liên quan đến một phản ứng, không phụ thuộc vào việc nó có thực sự được kèm theo hay
không. Chúng tôi sử dụng thuật ngữ "Biểu diễn được chọn" để chỉ biểu diễn hiện tại của tài nguyên
đích sẽ được chọn trong phản hồi thành công nếu yêu cầu tương ứng đã sử dụng phương thức nhận
và loại trừ bất kỳ tùy chọn yêu cầu có điều kiện nào (Phần 5.10.8). Một số tùy chọn phản hồi cung
cấp siêu dữ liệu về biểu diễn được chọn, có thể khác với biểu diễn được bao gồm trong thông báo
để trả lời cho một số phương thức thay đổi trạng thái. Trong số các tùy chọn phản hồi được xác định
trong thông số kỹ thuật này, chỉ có tùy chọn phản hồi ETAG (Phần 5.10.6) được định nghĩa là siêu dữ
liệu về biểu diễn được chọn. 5.5.4. Đàm phán nội dung Một máy chủ có thể có thể cung cấp một đại
diện cho một tài nguyên ở một trong nhiều định dạng đại diện. Không có thêm thông tin từ khách
hàng, nó sẽ cung cấp đại diện trong định dạng mà nó thích. Bằng cách sử dụng tùy chọn Chấp nhận
(Phần 5.10.4) trong một yêu cầu, máy khách có thể cho biết công thức nội dung nào mà nó thích
nhận.

5.6. Bộ nhớ đệm COAP Các điểm cuối có thể phản hồi bộ đệm để giảm thời gian phản hồi và mức
tiêu thụ băng thông mạng trong các yêu cầu tương đương, tương đương. Mục tiêu của bộ nhớ đệm
trong COAP là sử dụng lại thông báo phản hồi trước để đáp ứng yêu cầu hiện tại. Trong một số
trường hợp, một phản hồi được lưu trữ có thể được sử dụng lại mà không cần yêu cầu mạng, giảm
độ trễ và các chuyến đi khứ hồi mạng; Một cơ chế "độ tươi" được sử dụng cho mục đích này (xem
Phần 5.6.1). Ngay cả khi yêu cầu mới, thường có thể sử dụng lại payload của phản hồi trước để đáp
ứng yêu cầu, do đó giảm sử dụng băng thông mạng; Một cơ chế "xác nhận" được sử dụng cho mục
đích này (xem Phần 5.6.2). Không giống như HTTP, khả năng lưu trữ của các phản hồi COAP không
phụ thuộc vào phương thức yêu cầu, nhưng nó phụ thuộc vào mã phản hồi. Khả năng lưu trữ của
từng mã phản hồi được xác định dọc theo các định nghĩa mã phản hồi trong Phần 5.9. Các mã phản
hồi cho thấy thành công và không được công nhận bởi một điểm cuối không được lưu trữ. Đối với
một yêu cầu được trình bày, điểm cuối COAP không được sử dụng phản hồi được lưu trữ, trừ khi: o
Phương thức yêu cầu được trình bày và được sử dụng để có được sự phù hợp phản hồi được lưu
trữ, o tất cả các tùy chọn khớp giữa các tùy chọn trong yêu cầu được trình bày và các yêu cầu được
sử dụng để có được Phản hồi được lưu trữ (bao gồm URI yêu cầu), ngoại trừ không cần phải phù
hợp với bất kỳ tùy chọn yêu cầu nào được đánh dấu là NocacheKey (Mục 5.4) hoặc được nhận biết
bởi bộ đệm và được giải thích đầy đủ về hành vi bộ đệm được chỉ định của nó (chẳng hạn như Tùy
chọn yêu cầu ETAG được mô tả trong Phần 5.10.6; xem thêm Phần 5.4.2) và o Phản hồi được lưu trữ
là mới hoặc được xác thực thành công như được định nghĩa dưới đây. Tập hợp các tùy chọn yêu cầu
được sử dụng để khớp mục nhập bộ đệm cũng được gọi chung là "khóa đệm". Đối với các sơ đồ URI
khác ngoài COAP và Coaps, việc khớp các tùy chọn tạo thành URI yêu cầu có thể được thực hiện
theo các quy tắc cụ thể cho sơ đồ URI.
5.6.1. Mô hình độ tươi Khi một phản hồi là "mới" trong bộ đệm, nó có thể được sử dụng để đáp ứng
các yêu cầu tiếp theo mà không cần liên hệ với máy chủ gốc, do đó cải thiện hiệu quả. Cơ chế xác
định độ tươi là dành cho máy chủ gốc để cung cấp thời gian hết hạn rõ ràng trong tương lai, sử dụng
tùy chọn Age Age (xem Phần 5.10.5). Tùy chọn độ tuổi tối đa chỉ ra rằng phản hồi sẽ được coi là
không mới sau khi tuổi của nó lớn hơn số giây được chỉ định. Tùy chọn độ tuổi tối đa mặc định là giá
trị là 60. Do đó, nếu nó không có trong phản hồi có thể lưu trữ được, thì phản hồi được coi là không
mới sau khi tuổi của nó lớn hơn 60 giây. Nếu một máy chủ gốc muốn ngăn chặn bộ đệm, nó phải
bao gồm một tùy chọn tuổi tối đa với giá trị bằng 0 giây. Nếu khách hàng có phản hồi được lưu trữ
mới và đưa ra yêu cầu mới phù hợp với yêu cầu phản hồi được lưu trữ đó, phản hồi mới làm mất
hiệu lực phản hồi cũ. 5.6.2. Mô hình xác thực khi điểm cuối có một hoặc nhiều phản hồi được lưu
trữ cho yêu cầu GET, nhưng không thể sử dụng bất kỳ phản hồi nào trong số chúng (ví dụ: vì chúng
không phải là mới), nó có thể sử dụng tùy chọn ETAG (Mục 5.10.6) trong yêu cầu nhận được Máy
chủ gốc là một cơ hội để chọn một phản hồi được lưu trữ sẽ được sử dụng và cập nhật độ mới của
nó. Quá trình này được gọi là "xác nhận" hoặc "tái hiện" phản ứng được lưu trữ. Khi gửi yêu cầu như
vậy, điểm cuối sẽ thêm một tùy chọn ETAG chỉ định thẻ thực thể của từng phản hồi được lưu trữ có
thể áp dụng. Phản hồi 2.03 (hợp lệ) cho biết phản hồi được lưu trữ được xác định bởi thẻ thực thể
được đưa ra trong tùy chọn phản hồi ETAG ETAG có thể được sử dụng lại sau khi cập nhật nó như
được mô tả trong Phần 5.9.1.3. Bất kỳ mã phản hồi nào khác chỉ ra rằng không có câu trả lời được
lưu trữ nào được đề cử trong yêu cầu là phù hợp. Thay vào đó, phản hồi nên được sử dụng để đáp
ứng yêu cầu và có thể thay thế phản hồi được lưu trữ.

5.7. Proxy proxy là điểm cuối COAP có thể được các máy khách COAP giao nhiệm vụ thực hiện các
yêu cầu thay mặt họ. Điều này có thể hữu ích, ví dụ, khi yêu cầu không thể được thực hiện hoặc để
phục vụ phản hồi từ bộ đệm để giảm thời gian phản hồi và băng thông mạng hoặc tiêu thụ năng
lượng. Trong một kiến trúc tổng thể cho một môi trường yên tĩnh bị ràng buộc, các proxy có thể
phục vụ các mục đích khá khác nhau. Proxy có thể được khách hàng lựa chọn rõ ràng, một vai trò mà
chúng tôi gọi là "proxy chuyển tiếp". Proxy cũng có thể được chèn vào để đứng cho các máy chủ gốc,
một vai trò mà chúng tôi gọi là "proxy ngược". Truyền hình trực giao với sự khác biệt này, proxy có
thể ánh xạ từ yêu cầu COAP sang yêu cầu COAP (proxy coap-to coap) hoặc dịch từ hoặc một giao
thức khác ("proxy chéo"). Định nghĩa đầy đủ của các Điều khoản này được cung cấp trong Phần 1.2.
Lưu ý: Thuật ngữ trong đặc điểm kỹ thuật này đã được chọn để tương thích về mặt văn hóa với
thuật ngữ được sử dụng trong môi trường ứng dụng web rộng hơn, mà không nhất thiết phải khớp
với mọi chi tiết (thậm chí có thể không liên quan đến môi trường yên tĩnh bị ràng buộc). Không quá
nhiều ngữ nghĩa nên được gán cho các thành phần của các thuật ngữ (chẳng hạn như "chuyển tiếp",
"đảo ngược" hoặc "chéo"). Các proxy HTTP, bên cạnh hoạt động như các proxy HTTP, thường cung
cấp chức năng proxy giao thông vận tải ("Kết nối") để cho phép bảo mật lớp vận chuyển từ đầu đến
cuối thông qua proxy. Không có chức năng như vậy được xác định cho các proxy COAP-to COAP
trong đặc điểm kỹ thuật này, vì việc chuyển tiếp các gói UDP không có khả năng có nhiều giá trị trong
các môi trường yên tĩnh bị ràng buộc. Xem thêm Phần 10.2.7 cho trường hợp proxy chéo. Khi khách
hàng sử dụng proxy để đưa ra yêu cầu sử dụng sơ đồ URI an toàn (ví dụ: "coaps" hoặc "https"), yêu
cầu đối với proxy nên được gửi bằng cách sử dụng Chân giữa máy khách và proxy. 5.7.1. Hoạt động
proxy Một proxy thường cần một cách để xác định các tham số yêu cầu tiềm năng cho một yêu cầu
mà nó đến một điểm đến, dựa trên yêu cầu mà nó nhận được từ máy khách của mình. Cách này
được chỉ định đầy đủ cho một sản phẩm tiến bộ nhưng có thể phụ thuộc vào cấu hình cụ thể cho
proxy ngược. Cụ thể, máy khách của một proxy ngược thường không chỉ ra một trình định vị cho
đích đến,

đòi hỏi một số hình thức dịch không gian tên trong proxy ngược. Tuy nhiên, một số khía cạnh của
hoạt động của các proxy là phổ biến cho tất cả các hình thức của nó. Nếu proxy không sử dụng bộ
đệm, thì nó chỉ cần chuyển tiếp yêu cầu được dịch đến đích xác định. Mặt khác, nếu nó sử dụng bộ
đệm nhưng không có phản hồi được lưu trữ phù hợp với yêu cầu được dịch và được coi là mới, thì
nó cần phải làm mới bộ đệm của nó theo Mục 5.6. Đối với các tùy chọn trong yêu cầu mà proxy
nhận ra, nó có biết liệu tùy chọn có được dự định hoạt động như một phần của khóa được sử dụng
để tìm kiếm giá trị được lưu trong bộ nhớ cache hay không. Ví dụ: vì các yêu cầu cho các giá trị
đường dẫn URI khác nhau giải quyết các tài nguyên khác nhau, các giá trị đường dẫn URI luôn là một
phần của khóa đệm, trong khi, ví dụ, các giá trị mã thông báo không bao giờ là một phần của khóa
đệm. Đối với các tùy chọn mà proxy không nhận ra nhưng được đánh dấu an toàn để chuyển tiếp
trong số tùy chọn, tùy chọn cũng cho biết liệu nó có được đưa vào bộ đệm (Nocachekey không phải
là tất cả) hay không (NocacheKey là tất cả đặt). . Nếu yêu cầu đến đích trả về một phản hồi không
thể được xử lý bởi proxy (ví dụ: do các tùy chọn quan trọng không được nhận ra hoặc lỗi định dạng
message), thì phải trả lời phản hồi 5.02 (Cổng xấu). Nếu không, proxy trả về phản hồi cho máy khách.
Nếu một phản hồi được tạo ra từ bộ đệm, tùy chọn được tạo (hoặc ngụ ý) không được mở rộng độ
tuổi tối đa ban đầu được đặt bởi máy chủ, xem xét thời gian biểu diễn tài nguyên được sử dụng
trong bộ đệm. Ví dụ: tùy chọn tuổi tối đa có thể được điều chỉnh bởi proxy cho mỗi phản hồi bằng
cách sử dụng công thức: proxy-max-age = bản gốc-max-age-ví dụ như bộ nhớ cache Được làm mới
cách đây 20 giây và có tuổi tối đa ban đầu là 60 giây, sau đó rằng Age Max được ủy quyền của tài
nguyên hiện là 40 giây. Xem xét độ trễ mạng tiềm năng trên đường từ máy chủ gốc, một proxy phải
bảo thủ trong các giá trị độ tuổi tối đa được cung cấp. Tất cả các tùy chọn có trong một yêu cầu
proxy phải được xử lý tại proxy. Các tùy chọn không an toàn trong một yêu cầu không được proxy
nhận ra phải dẫn đến phản hồi 4.02 (tùy chọn xấu) được proxy trả lại. Proxy coap-to tiền COAP phải
chuyển tiếp đến máy chủ gốc Tất cả các tùy chọn an toàn đến chuyển tiếp mà nó không nhận ra.
Tương tự,

Các tùy chọn không an toàn trong một phản hồi không được công nhận bởi máy chủ proxy COAP-to-
CoAP phải dẫn đến phản hồi 5.02 (Cổng xấu). Một lần nữa, các tùy chọn an toàn đến chuyển tiếp
không được công nhận phải được chuyển tiếp. Những cân nhắc bổ sung cho proxy giao thức chéo
giữa COAP và HTTP được thảo luận trong Phần 10. 5.7.2. CoAP proxies phân biệt giữa các yêu cầu
được thực hiện (như thể) với máy chủ gốc và các yêu cầu được thực hiện thông qua proxy chuyển
tiếp. Các yêu cầu COAP cho một proxy chuyển tiếp được thực hiện dưới dạng các yêu cầu có thể xác
nhận hoặc không thể xác nhận bình thường đến điểm cuối proxy chuyển tiếp, nhưng chúng chỉ định
URI yêu cầu theo một cách khác: URI yêu cầu trong yêu cầu proxy được chỉ định là một chuỗi trong
proxy Tùy chọn -URI (xem Phần 5.10.2), trong khi URI yêu cầu theo yêu cầu đến máy chủ gốc được
chia thành các tùy chọn URI-HOST, URI-PORT, URI-PATH và URI-Trình tự UR (xem Phần 5.10.1) .
Ngoài ra, URI trong một yêu cầu proxy có thể được lắp ráp từ tùy chọn Schy-Scheme và các tùy chọn
phân chia được đề cập. Khi yêu cầu proxy được thực hiện theo điểm cuối và điểm cuối không sẵn
sàng hoặc không thể đóng vai trò là ủy quyền cho URI yêu cầu, nó phải trả về phản hồi 5.05 (ủy
quyền không được hỗ trợ). Nếu cơ quan (máy chủ và cổng) được công nhận là xác định chính điểm
cuối proxy (xem Phần 5.10.2), thì yêu cầu phải được coi là yêu cầu cục bộ (không proxied). Trừ khi
một proxy được cấu hình để chuyển tiếp yêu cầu proxy sang một proxy khác, nó phải dịch yêu cầu
như sau: sơ đồ của URI yêu cầu xác định giao thức gửi đi và chi tiết của nó (ví dụ: CoAP được sử
dụng trên UDP cho sơ đồ "COAP" và Trên DTLS cho sơ đồ "Coaps".) Đối với proxy coap-to tiền, địa
chỉ IP và cổng của máy chủ gốc được xác định bởi thành phần thẩm quyền của URI yêu cầu và URI
yêu cầu được giải mã và chia thành máy chủ URI , Các tùy chọn URI-PORT, URI-PATH và URI. Điều
này tiêu thụ tùy chọn Proxy-URI hoặc Proxy-Scheme, do đó không được chuyển tiếp đến máy chủ
gốc. 5.7.3. Các proxies ngược lại không sử dụng các tùy chọn proxy-uri hoặc proxy-scheme nhưng
cần xác định đích (hop tiếp theo) của một yêu cầu từ thông tin trong yêu cầu và thông tin trong cấu
hình của chúng. Ví dụ, một proxy ngược có thể cung cấp các tài nguyên khác nhau như thể chúng là
tài nguyên của chính nó, sau khi biết được sự tồn tại của chúng thông qua khám phá tài nguyên.
Proxy ngược có thể tự do xây dựng một không gian tên cho các URI xác định các tài nguyên này. Một
proxy ngược cũng có thể xây dựng một không gian tên cung cấp cho khách hàng nhiều hơn

Kiểm soát nơi yêu cầu đi, ví dụ: bằng cách nhúng các định danh máy chủ và số cổng vào đường dẫn
URI của các tài nguyên được cung cấp. Khi xử lý phản hồi, một proxy ngược phải cẩn thận rằng các
giá trị tùy chọn ETAG từ các nguồn khác nhau không được trộn lẫn trên một tài nguyên được cung
cấp cho khách hàng của mình. Trong nhiều trường hợp, ETAG có thể được chuyển tiếp không thay
đổi. Nếu ánh xạ từ một tài nguyên được cung cấp bởi proxy ngược đến các tài nguyên được cung
cấp bởi các máy chủ xuất xứ khác nhau của nó không phải là duy nhất, thì proxy ngược có thể cần
phải tạo ETAG mới, đảm bảo ngữ nghĩa của tùy chọn này được bảo tồn đúng. 5,8. Định nghĩa
phương thức Trong phần này, mỗi phương thức được xác định cùng với hành vi của nó. Một yêu cầu
với mã phương thức không được công nhận hoặc không được hỗ trợ phải tạo phản hồi 4.05
(phương thức không được phép). 5.8.1. Nhận phương thức Get Truy xuất một đại diện cho thông tin
hiện tương ứng với tài nguyên được xác định bởi URI yêu cầu. Nếu yêu cầu bao gồm một tùy chọn
chấp nhận, điều đó cho biết định dạng nội dung ưa thích của phản hồi. Nếu yêu cầu bao gồm một
tùy chọn ETAG, phương thức GET yêu cầu ETAG được xác nhận và chỉ được chuyển giao nếu xác
thực không thành công. Sau khi thành công, mã phản hồi 2.05 (Nội dung) hoặc 2.03 (hợp lệ) phải có
trong phản hồi. Phương pháp GET là an toàn và idempotent. 5,8.2. Đăng phương thức bài yêu cầu
rằng đại diện được đặt trong yêu cầu được xử lý. Hàm thực tế được thực hiện bởi phương thức
POST được xác định bởi máy chủ gốc và phụ thuộc vào tài nguyên đích. Nó thường dẫn đến một tài
nguyên mới đang được tạo hoặc tài nguyên mục tiêu được cập nhật. Nếu một tài nguyên đã được
tạo trên máy chủ, phản hồi được máy chủ trả về sẽ có mã phản hồi 2.01 (được tạo) và nên bao gồm
URI của tài nguyên mới theo chuỗi của một hoặc nhiều đường dẫn vị trí và/hoặc trình độ vị trí Tùy
chọn (Mục 5.10.7). Nếu bài đăng thành công nhưng không dẫn đến tài nguyên mới được tạo trên
máy chủ, phản hồi sẽ có mã phản hồi 2.04 (đã thay đổi). Nếu bài đăng thành công và dẫn đến tài
nguyên mục tiêu bị xóa, phản hồi phải có mã phản hồi 2.02 (bị xóa). Bài đăng không an toàn cũng
không phải là idempotent.

5,8.3. Đặt phương thức PUT yêu cầu rằng tài nguyên được xác định bởi URI yêu cầu được cập nhật
hoặc tạo với biểu diễn kèm theo. Định dạng đại diện được chỉ định bởi loại phương tiện và mã hóa
nội dung được đưa ra trong tùy chọn định dạng nội dung, nếu được cung cấp. Nếu một tài nguyên
tồn tại theo yêu cầu URI, biểu diễn kèm theo nên được coi là phiên bản sửa đổi của tài nguyên đó và
mã phản hồi 2.04 (đã thay đổi) sẽ được trả về. Nếu không có tài nguyên nào tồn tại, thì máy chủ có
thể tạo một tài nguyên mới với URI đó, dẫn đến mã phản hồi 2.01 (được tạo). Nếu tài nguyên không
thể được tạo hoặc sửa đổi, thì phải gửi mã phản hồi lỗi thích hợp. Có thể thực hiện các hạn chế hơn
nữa đối với việc đặt bằng cách bao gồm các tùy chọn IF-F-F-F-F-F-F-C-C-C-C-C-Câu (xem Phần
5.10.8.1) hoặc IF-None (xem Phần 5.10.8.2) trong yêu cầu. Đặt không an toàn nhưng là idempotent.
5,8.4. Xóa phương thức xóa các yêu cầu mà tài nguyên được xác định bởi URI yêu cầu sẽ bị xóa. Mã
phản hồi 2.02 (bị xóa) nên được sử dụng khi thành công hoặc trong trường hợp tài nguyên không
tồn tại trước yêu cầu. Xóa không an toàn nhưng là idempotent. 5.9. Định nghĩa mã phản hồi Mỗi mã
phản hồi được mô tả dưới đây, bao gồm mọi tùy chọn cần thiết trong phản hồi. Khi thích hợp, một
số mã sẽ được chỉ định liên quan đến các mã phản hồi liên quan trong HTTP [RFC2616]; Điều này
không có nghĩa là bất kỳ mối quan hệ nào như vậy đều sửa đổi ánh xạ HTTP được chỉ định trong
Phần 10. 5.9.1. Thành công 2.xx Lớp mã phản hồi này cho thấy yêu cầu của khách hàng đã được
nhận, hiểu và chấp nhận thành công. 5.9.1.1. 2.01 được tạo như HTTP 201 "được tạo", nhưng chỉ
được sử dụng để đáp ứng với các yêu cầu POST và đặt. Payload được trả về với phản hồi, nếu có, là
một đại diện của kết quả hành động.

Nếu phản hồi bao gồm một hoặc nhiều tùy chọn đường dẫn vị trí và/hoặc vị trí, các giá trị của các
tùy chọn này xác định vị trí mà tài nguyên được tạo. Mặt khác, tài nguyên đã được tạo tại URI yêu
cầu. Một bộ đệm nhận được phản hồi này phải đánh dấu bất kỳ phản hồi được lưu trữ nào cho tài
nguyên được tạo là không mới. Phản hồi này không thể lưu trữ được. 5.9.1.2. 2.02 Đã xóa mã phản
hồi này giống như HTTP 204 "không có nội dung" nhưng chỉ được sử dụng để đáp ứng các yêu cầu
khiến tài nguyên ngừng có sẵn, chẳng hạn như xóa và trong một số trường hợp nhất định. Payload
được trả về với phản hồi, nếu có, là một đại diện của kết quả hành động. Phản hồi này không thể lưu
trữ được. Tuy nhiên, bộ đệm phải đánh dấu bất kỳ phản hồi được lưu trữ nào cho tài nguyên bị xóa
là không mới. 5.9.1.3. 2.03 Mã phản hồi hợp lệ này có liên quan đến HTTP 304 "không được sửa đổi"
nhưng chỉ được sử dụng để chỉ ra rằng phản hồi được xác định bởi TAG thực thể được xác định bởi
tùy chọn ETAG được bao gồm là hợp lệ. Theo đó, phản hồi phải bao gồm một tùy chọn ETAG và
không được bao gồm payload. Khi bộ đệm nhận dạng và xử lý tùy chọn phản hồi ETAG nhận được
phản hồi 2.03 (hợp lệ), nó phải cập nhật phản hồi được lưu trữ với giá trị của tùy chọn tuổi tối đa có
trong phản hồi (rõ ràng hoặc ngầm là giá trị mặc định; xem thêm Mục 5.6.2). Đối với mỗi loại tùy
chọn an toàn đến chuyển tiếp trong phản hồi, bộ tùy chọn (có thể trống) của loại này có trong phản
hồi được lưu trữ phải được thay thế bằng tập hợp các tùy chọn thuộc loại này trong phản hồi nhận
được. (Tùy chọn không an toàn có thể kích hoạt xử lý cụ thể tùy chọn tương tự như được xác định
bởi tùy chọn.) 5.9.1.4. 2.04 Thay đổi mã phản hồi này giống như HTTP 204 "không có nội dung"
nhưng chỉ được sử dụng để đáp ứng với các yêu cầu POST và đặt. Payload được trả về với phản hồi,
nếu có, là một đại diện của kết quả hành động. Phản hồi này không thể lưu trữ được. Tuy nhiên, bộ
đệm phải đánh dấu bất kỳ phản hồi được lưu trữ nào cho tài nguyên đã thay đổi là không mới.

5.9.1.5. 2.05 Nội dung Mã phản hồi này giống như HTTP 200 "OK" nhưng chỉ được sử dụng để đáp
ứng để nhận yêu cầu. Payload được trả về với phản hồi là một đại diện của tài nguyên đích. Phản hồi
này có thể lưu trữ được: Bộ nhớ cache có thể sử dụng tùy chọn tuổi tối đa để xác định độ tươi (xem
Phần 5.6.1) và (nếu có) tùy chọn ETAG để xác thực (xem Phần 5.6.2). 5.9.2. Lỗi máy khách 4.xx Lớp
mã phản hồi này được dành cho các trường hợp mà máy khách dường như đã sai. Các mã phản hồi
này được áp dụng cho bất kỳ phương thức yêu cầu nào. Máy chủ nên bao gồm payload chẩn đoán
trong các điều kiện chi tiết trong Phần 5.5.2. Phản hồi của lớp này có thể lưu trữ được: Bộ nhớ cache
có thể sử dụng tùy chọn tuổi tối đa để xác định độ tươi (xem Phần 5.6.1). Họ không thể được xác
nhận. 5.9.2.1. 4.00 Yêu cầu xấu Mã phản hồi này giống như HTTP 400 "Yêu cầu xấu". 5.9.2.2. 4.01
Nhập học Khách hàng không được phép thực hiện hành động được yêu cầu. Máy khách không nên
lặp lại yêu cầu mà không cải thiện trạng thái xác thực của mình cho máy chủ. Cơ chế cụ thể nào có
thể được sử dụng cho điều này nằm ngoài phạm vi tài liệu này; Xem thêm Phần 9. 5.9.2.3. 4.02 Tùy
chọn xấu Yêu cầu không thể được máy chủ hiểu được do một hoặc nhiều tùy chọn không được nhận
ra hoặc không đúng định dạng. Khách hàng không nên lặp lại yêu cầu mà không cần sửa đổi. 5.9.2.4.
4.03 Cấm mã phản hồi này giống như HTTP 403 "bị cấm".

5.9.2.5. 4.04 Không tìm thấy mã phản hồi này giống như HTTP 404 "không tìm thấy". 5.9.2.6. Phương
pháp 4.05 Không cho phép mã phản hồi này giống như phương thức HTTP 405 "không được phép"
nhưng không có song song với trường tiêu đề "cho phép". 5.9.2.7. 4.06 Không được chấp nhận Mã
phản hồi này giống như HTTP 406 "không được chấp nhận", nhưng không có thực thể phản hồi.
5.9.2.8. 4.12 Điều kiện tiên quyết không thành công Mã phản hồi này giống như HTTP 412 "Điều kiện
tiên quyết không thành công". 5.9.2.9. 4.13 Thực thể yêu cầu quá lớn Mã phản hồi này giống như
http 413 "thực thể yêu cầu quá lớn". Phản hồi phải bao gồm tùy chọn Size1 (Mục 5.10.9) để chỉ ra
kích thước tối đa của thực thể yêu cầu mà máy chủ có thể và sẵn sàng xử lý, trừ khi máy chủ không
ở vị trí để cung cấp thông tin này. 5.9.2.10. 4.15 Định dạng nội dung không được hỗ trợ Mã phản hồi
này giống như HTTP 415 "Loại phương tiện không được hỗ trợ". 5.9.3. Lỗi máy chủ 5.xx Lớp mã phản
hồi này cho biết các trường hợp trong đó máy chủ biết rằng nó đã sai hoặc không có khả năng thực
hiện yêu cầu. Các mã phản hồi này được áp dụng cho bất kỳ phương thức yêu cầu nào. Máy chủ nên
bao gồm payload chẩn đoán trong các điều kiện chi tiết trong Phần 5.5.2. Phản hồi của lớp này có
thể lưu trữ được: Bộ nhớ cache có thể sử dụng tùy chọn tuổi tối đa để xác định độ tươi (xem Phần
5.6.1). Họ không thể được xác nhận. 5.9.3.1. 5.00 Lỗi máy chủ nội bộ Mã phản hồi này giống như
HTTP 500 "Lỗi máy chủ nội bộ".

5.9.3.2. 5.01 Không được triển khai Mã phản hồi này giống như HTTP 501 "không được triển khai".
5.9.3.3. 5.02 Cổng xấu Mã phản hồi này giống như HTTP 502 "Cổng xấu". 5.9.3.4. 5.03 Dịch vụ Không
khả dụng Mã phản hồi này giống như HTTP 503 "Dịch vụ không có sẵn" nhưng sử dụng tùy chọn Age
Age thay cho trường tiêu đề "thử lại sau" để chỉ ra số giây sau đó để thử lại. 5.9.3.5. 5.04 Thời gian
chờ đợi Mã phản hồi này giống như HTTP 504 "Thời gian chờ cổng". 5.9.3.6. 5.05 proxy không được
hỗ trợ máy chủ không thể hoặc không muốn hoạt động như một proxy chuyển tiếp cho URI được chỉ
định trong tùy chọn proxy-uri hoặc sử dụng proxy-scheme (xem Phần 5.10.2). 5.10. Định nghĩa tùy
chọn Các tùy chọn COAP riêng lẻ được tóm tắt trong Bảng 4 và được giải thích trong các phần phụ
của phần này. Trong bảng này, các cột C, U và N biểu thị các thuộc tính quan trọng, không an toàn và
Nocachekey, tương ứng. Vì NocacheKey chỉ có ý nghĩa cho các tùy chọn an toàn đến chuyển tiếp
(không được đánh dấu không an toàn), nên cột được lấp đầy bằng một dấu gạch ngang cho các tùy
chọn không an toàn.
5.10.1. URI-HOST, URI-PORT, URI-PATH và URI-QUẢNG CÁO Các tùy chọn URI-HOST, URI-PORT, URI-
PATH và URI-Trận đấu được sử dụng để chỉ định tài nguyên đích của yêu cầu đến máy chủ gốc COAP.
Các tùy chọn mã hóa các thành phần khác nhau của URI yêu cầu theo cách mà không hiển thị mã
hóa phần trăm trong các giá trị tùy chọn và URI đầy đủ có thể được xây dựng lại ở bất kỳ điểm cuối
liên quan nào. Cú pháp của URI COAP được xác định trong Phần 6. Các bước để phân tích cú pháp
URI vào các tùy chọn được xác định trong Phần 6.4. Các bước này dẫn đến không hoặc nhiều tùy
chọn URI-HOST, URI-PORT, URI-PATH và URI-Trận chuyển Tài nguyên đang được yêu cầu, o Tùy chọn
cổng Uri-Chỉ định số cổng lớp vận chuyển của tài nguyên, o mỗi tùy chọn đường dẫn URI chỉ định
một đoạn của đường dẫn tuyệt đối đến tài nguyên và

o Mỗi tùy chọn URI-Quary chỉ định một đối số tham số hóa tài nguyên. Lưu ý: Các đoạn ([RFC3986],
Phần 3.5) không phải là một phần của URI yêu cầu và do đó sẽ không được truyền theo yêu cầu
COAP. Giá trị mặc định của tùy chọn lưu trữ URI là IP theo nghĩa đen đại diện cho địa chỉ IP đích của
thông báo yêu cầu. Tương tự như vậy, giá trị mặc định của tùy chọn URI-Port là cổng UDP đích. Các
giá trị mặc định cho các tùy chọn lưu trữ URI và cổng URI là đủ cho các yêu cầu cho hầu hết các máy
chủ. Các tùy chọn lưu trữ URI và URI-cổng rõ ràng thường được sử dụng khi điểm cuối lưu trữ nhiều
máy chủ ảo. Tùy chọn URI-Path và Uri-Quary có thể chứa bất kỳ trình tự ký tự nào. Không có phần
trăm mã hóa được thực hiện. Giá trị của một tùy chọn đường dẫn Uri không phải là "." hoặc ".."
(như URI yêu cầu phải được giải quyết trước khi phân tích các tùy chọn). Các bước để xây dựng URI
yêu cầu từ các tùy chọn được xác định trong Phần 6.5. Lưu ý rằng việc triển khai không nhất thiết
phải xây dựng URI; Nó chỉ đơn giản là tìm kiếm tài nguyên mục tiêu bằng cách kiểm tra các tùy chọn
riêng lẻ. Ví dụ có thể được tìm thấy trong Phụ lục B. 5.10.2. Proxy-uri và proxy-scheme Tùy chọn
proxy-uri được sử dụng để đưa ra yêu cầu proxy chuyển tiếp (xem Phần 5.7). Proxy chuyển tiếp
được yêu cầu chuyển tiếp yêu cầu hoặc dịch vụ từ bộ đệm hợp lệ và trả lại phản hồi. Giá trị tùy chọn
là một URI tuyệt đối ([RFC3986], Phần 4.3). Lưu ý rằng proxy chuyển tiếp có thể chuyển tiếp yêu cầu
sang một proxy khác hoặc trực tiếp đến máy chủ được chỉ định bởi URI tuyệt đối. Để tránh các vòng
lặp yêu cầu, proxy phải có khả năng nhận ra tất cả các tên máy chủ của nó, bao gồm mọi bí danh,
biến thể cục bộ và địa chỉ IP số. Điểm cuối nhận được yêu cầu với tùy chọn Proxy-URI không thể
hoặc không muốn đóng vai trò là một điều kiện chuyển tiếp cho yêu cầu phải gây ra sự trở lại của
phản hồi 5.05 (ủy quyền không được hỗ trợ). Tùy chọn Proxy-URI phải được ưu tiên hơn bất kỳ tùy
chọn URI-HOST, URI-PORT, URI-PATH hoặc URI-Quan sát URI (mỗi trong số đó không được đưa vào
yêu cầu chứa tùy chọn Proxy-URI).

Là một trường hợp đặc biệt để đơn giản hóa nhiều máy khách proxy, URI tuyệt đối có thể được xây
dựng từ các tùy chọn URI-*. Khi có tùy chọn Schy-Scheme, URI tuyệt đối được xây dựng như sau:
URI COAP được xây dựng từ các tùy chọn URI-* như được định nghĩa trong Phần 6.5. Trong URI kết
quả, sơ đồ ban đầu lên đến, nhưng không bao gồm, dấu hai chấm sau đó được thay thế bằng nội
dung của tùy chọn sơ đồ proxy. Lưu ý rằng trường hợp này chỉ được áp dụng nếu các thành phần
của URI mong muốn khác với thành phần sơ đồ thực sự có thể được thể hiện bằng các tùy chọn URI-
*; Ví dụ, để đại diện cho một URI với thành phần userInfo trong thẩm quyền, chỉ có thể sử dụng
proxy-uri. 5.10.3. Định dạng nội dung Tùy chọn định dạng nội dung cho biết định dạng biểu diễn của
payload message. Định dạng biểu diễn được đưa ra như một định danh định dạng nội dung số được
xác định trong Cơ quan đăng ký "Nội dung COAP" (Mục 12.3). Trong trường hợp không có tùy chọn,
không có giá trị mặc định nào được giả định, tức là, định dạng biểu diễn của bất kỳ payload message
đại diện nào là không xác định (Phần 5.5). 5.10.4. Chấp nhận tùy chọn chấp nhận COAP có thể được
sử dụng để chỉ ra định dạng nội dung nào được khách hàng chấp nhận. Định dạng biểu diễn được
đưa ra như một định danh định dạng nội dung số được xác định trong sổ đăng ký "Nội dung COAP"
(Mục 12.3). Nếu không có tùy chọn chấp nhận được đưa ra, máy khách không thể hiện ưu tiên (do
đó không có giá trị mặc định được giả định). Máy khách thích đại diện được máy chủ trả về để được
chỉ định định dạng nội dung. Máy chủ trả về định dạng nội dung ưa thích nếu có. Nếu định dạng nội
dung ưa thích không thể được trả về, thì phải "không thể chấp nhận được 4.06 như một phản hồi,
trừ khi một mã lỗi khác được ưu tiên cho phản hồi này. 5.10.5. Tối đa tùy chọn tuổi tối đa cho biết
thời gian tối đa có thể được lưu trữ trước khi nó được coi là không mới (xem Phần 5.6.1). Giá trị tùy
chọn là số nguyên của giây trong khoảng từ 0 đến 2 ** 32-1 (khoảng 136,1 năm). Giá trị mặc định là
60 giây được giả định trong trường hợp không có tùy chọn trong phản hồi. Giá trị được dự định là
hiện tại tại thời điểm truyền. Các máy chủ cung cấp tài nguyên có dung sai nghiêm ngặt về giá trị của
tuổi tối đa sẽ cập nhật giá trị trước mỗi lần truyền lại. (Xem thêm Phần 5.7.1.)

5.10.6. ETAG Một thẻ thực thể được dự định để sử dụng như một định danh tài nguyên địa phương
để phân biệt giữa các biểu diễn của cùng một tài nguyên thay đổi theo thời gian. Nó được tạo bởi
máy chủ cung cấp tài nguyên, có thể tạo nó theo bất kỳ cách nào bao gồm phiên bản, tổng kiểm tra,
băm hoặc thời gian. Một điểm cuối nhận được một thẻ thực thể phải coi nó là mờ đục và không đưa
ra giả định nào về nội dung hoặc cấu trúc của nó. . ETAG như một tùy chọn phản hồi, tùy chọn ETAG
trong một phản hồi cung cấp giá trị hiện tại (nghĩa là, sau khi yêu cầu được xử lý) của thẻ thực thể
cho "đại diện được gắn thẻ". Nếu không có tùy chọn vị trí-*, biểu diễn được gắn thẻ là biểu diễn
được chọn (phần 5.5.3) của tài nguyên đích. Nếu một hoặc nhiều tùy chọn vị trí-* có mặt và do đó,
một vị trí URI được chỉ định (Phần 5.10.7), biểu diễn được gắn thẻ là đại diện sẽ được truy xuất bằng
yêu cầu nhận đến URI vị trí. Một tùy chọn phản hồi ETAG có thể được bao gồm trong bất kỳ phản
hồi nào có biểu diễn được gắn thẻ (ví dụ: nó sẽ không có ý nghĩa trong phản hồi 4.04 hoặc 4.00). Tùy
chọn ETAG không được xảy ra nhiều hơn một lần trong một phản hồi. Không có giá trị mặc định cho
tùy chọn ETAG; Nếu nó không có trong một phản hồi, máy chủ không đưa ra tuyên bố nào về thẻ
thực thể cho biểu diễn được gắn thẻ. 5.10.6.2. ETAG như một tùy chọn yêu cầu trong một yêu cầu
GET, điểm cuối có một hoặc nhiều biểu diễn được lấy trước đây từ tài nguyên và đã có được các tùy
chọn phản hồi ETAG với các tùy chọn này, có thể chỉ định một thể hiện của tùy chọn ETAG cho một
hoặc nhiều phản hồi được lưu trữ này. Một máy chủ có thể phát hành phản hồi hợp lệ 2.03 (Mục
5.9.1.3) thay cho phản hồi nội dung 2.05 nếu một trong các ETAG được đưa ra là thẻ thực thể cho
biểu diễn hiện tại, tức là, là hợp lệ; Phản hồi hợp lệ 2.03 sau đó lặp lại ETAG cụ thể này trong một
tùy chọn phản hồi. Trên thực tế, một khách hàng có thể xác định xem bất kỳ biểu diễn được lưu trữ
nào là hiện tại (xem Phần 5.6.2) mà không cần phải chuyển chúng lại.

Tùy chọn ETAG có thể xảy ra bằng 0, một hoặc nhiều lần trong một yêu cầu. 5.10.7. Vị trí đường dẫn
và vị trí-Trìnhd Các tùy chọn đường dẫn vị trí và vị trí cùng nhau biểu thị một URI tương đối bao gồm
một đường dẫn tuyệt đối, chuỗi truy vấn hoặc cả hai. Một sự kết hợp của các tùy chọn này được bao
gồm trong phản hồi 2.01 (được tạo) để chỉ ra vị trí của tài nguyên được tạo là kết quả của yêu cầu
POST (xem Phần 5.8.2). Vị trí được giải quyết liên quan đến URI yêu cầu. Nếu một phản hồi với một
hoặc nhiều tùy chọn đường dẫn vị trí và/hoặc vị trí đi qua bộ đệm để diễn giải các tùy chọn này và
URI ngụ ý xác định một hoặc nhiều phản hồi hiện đang được lưu trữ, các mục đó phải được đánh
dấu là không mới. Mỗi tùy chọn đường dẫn vị trí chỉ định một phân đoạn của đường dẫn tuyệt đối
đến tài nguyên và mỗi tùy chọn Trọng phần vị trí chỉ định một đối số tham số hóa tài nguyên. Tùy
chọn đường dẫn vị trí và trình tự vị trí có thể chứa bất kỳ chuỗi ký tự nào. Không có phần trăm mã
hóa được thực hiện. Giá trị của tùy chọn đường dẫn vị trí không phải là "." hoặc "..". Các bước để
xây dựng URI vị trí từ các tùy chọn tương tự như phần 6.5, ngoại trừ năm bước đầu tiên được bỏ
qua và kết quả là một tham chiếu URI tương đối, sau đó được giải thích so với URI yêu cầu. Lưu ý
rằng tham chiếu URI tương đối được xây dựng theo cách này luôn bao gồm một đường dẫn tuyệt
đối (ví dụ: bỏ đi đường dẫn vị trí nhưng cung cấp trình tải vị trí có nghĩa là thành phần đường dẫn
trong URI là "/"). Các tùy chọn được sử dụng để tính toán tham chiếu URI tương đối được gọi chung
là các tùy chọn vị trí-*. Ngoài vị trí đường dẫn và truy vấn vị trí, nhiều tùy chọn vị trí hơn-* có thể
được xác định trong tương lai và đã được bảo lưu số tùy chọn 128, 132, 136 và 140. Nếu có bất kỳ
số tùy chọn được bảo lưu nào xảy ra ngoài đường dẫn vị trí và vị trí /hoặc queer vị trí và không được
hỗ trợ, sau đó phải trả về lỗi 4.02 (tùy chọn xấu). 5.10.8. Tùy chọn yêu cầu có điều kiện Tùy chọn yêu
cầu có điều kiện cho phép máy khách yêu cầu máy chủ chỉ thực hiện yêu cầu nếu các điều kiện nhất
định được chỉ định bởi tùy chọn được đáp ứng.

Đối với mỗi tùy chọn này, nếu điều kiện được đưa ra không được đáp ứng, thì máy chủ không được
thực hiện phương thức được yêu cầu. Thay vào đó, máy chủ phải phản hồi với mã phản hồi 4.12
(điều kiện tiên quyết). Nếu điều kiện được đáp ứng, máy chủ sẽ thực hiện phương thức yêu cầu như
thể các tùy chọn yêu cầu có điều kiện không có mặt. Nếu yêu cầu sẽ, nếu không có các tùy chọn yêu
cầu có điều kiện, sẽ dẫn đến bất cứ điều gì khác ngoài mã phản hồi 2.xx hoặc 4.12, thì bất kỳ tùy
chọn yêu cầu có điều kiện nào cũng có thể bị bỏ qua. 5.10.8.1. IF-Match Tùy chọn IF-match có thể
được sử dụng để thực hiện yêu cầu có điều kiện về sự tồn tại hoặc giá trị hiện tại của ETAG cho một
hoặc nhiều biểu diễn của tài nguyên đích. IF-match thường hữu ích cho các yêu cầu cập nhật tài
nguyên, chẳng hạn như các yêu cầu đặt, như một phương tiện để bảo vệ chống lại sự ghi đè vô tình
khi nhiều máy khách đang hành động song song trên cùng một tài nguyên (nghĩa là vấn đề "Cập nhật
bị mất"). Giá trị của tùy chọn IF-match là ETAG hoặc chuỗi trống. Một tùy chọn IF phù hợp với ETAG
phù hợp với một đại diện với ETAG chính xác đó. Tùy chọn IF-match với giá trị trống phù hợp với bất
kỳ biểu diễn hiện có nào (nghĩa là, nó đặt điều kiện tiên quyết về sự tồn tại của bất kỳ biểu diễn hiện
tại nào cho tài nguyên đích). Tùy chọn IF-match có thể xảy ra nhiều lần. Nếu bất kỳ tùy chọn nào
khớp, thì điều kiện được đáp ứng. Nếu có một hoặc nhiều tùy chọn nếu phù hợp, nhưng không có
tùy chọn nào khớp, thì điều kiện không được đáp ứng. 5.10.8.2. IF-NONE-MATCH Tùy chọn if-none-
match có thể được sử dụng để thực hiện yêu cầu có điều kiện về sự không tồn tại của tài nguyên
đích. Nếu-không-phù hợp rất hữu ích cho các yêu cầu tạo tài nguyên, chẳng hạn như các yêu cầu
đặt, như một phương tiện để bảo vệ chống lại sự ghi đè vô tình khi nhiều máy khách đang hành
động song song trên cùng một tài nguyên. Tùy chọn if-none-match không có giá trị. Nếu tài nguyên
đích không tồn tại, thì điều kiện không được đáp ứng. .

5.10.9. Size1 Tùy chọn Tùy chọn Size1 cung cấp thông tin kích thước về biểu diễn tài nguyên trong
một yêu cầu. Giá trị tùy chọn là một số nguyên của byte. Sử dụng chính của nó là với chuyển nhượng
theo khối [khối]. Trong thông số kỹ thuật hiện tại, nó được sử dụng trong 4.13 phản hồi (Mục
5.9.2.9) để chỉ ra kích thước tối đa của thực thể yêu cầu mà máy chủ có thể và sẵn sàng xử lý. 6.
COAP URIS COAP sử dụng các sơ đồ URI "COAP" và "Coaps" để xác định tài nguyên COAP và cung
cấp phương tiện định vị tài nguyên. Các tài nguyên được tổ chức theo thứ bậc và được điều chỉnh
bởi một máy chủ gốc COAP tiềm năng lắng nghe các yêu cầu COAP ("COAP") hoặc các yêu cầu COAP
được bảo đảm DTLS ("CoAP") trên cổng UDP đã cho. Máy chủ COAP được xác định thông qua thành
phần Cơ quan Cú pháp chung, bao gồm một thành phần máy chủ và số cổng UDP tùy chọn. Phần còn
lại của URI được coi là xác định một tài nguyên có thể được vận hành bằng các phương thức được
xác định bởi giao thức COAP. Do đó, các sơ đồ URI "coap" và "coaps" có thể được so sánh với các sơ
đồ URI "HTTP" và "HTTPS" tương ứng. Cú pháp của các sơ đồ URI "coap" và "coaps" được chỉ định
trong phần này ở dạng tăng cường maur (ABNF) [RFC5234]. Các định nghĩa của "máy chủ", "cổng",
"path-abempty", "truy vấn", "phân đoạn", "chữ" ip "," ipv4address "và" reg-name "được áp dụng từ
[RFC3986]. Lưu ý thực hiện: Thật không may, theo thời gian, định dạng URI đã có được sự phức tạp
đáng kể. Người thực hiện được khuyến khích kiểm tra [RFC3986] chặt chẽ. Ví dụ, ABNF cho các địa
chỉ IPv6 phức tạp hơn có thể mong đợi. Ngoài ra, người thực hiện nên cẩn thận thực hiện xử lý phần
trăm mã hóa hoặc mã hóa phần trăm chính xác một lần trên đường từ URI đến các thành phần được
giải mã hoặc trở lại. Mã hóa phần trăm là rất quan trọng đối với tính minh bạch của dữ liệu nhưng
có thể dẫn đến kết quả bất thường như ký tự chém trong một thành phần đường dẫn. 6.1. COAP
URI Sơ đồ coap-uri = "coap:" "//" host [":" cổng] path-abempty ["?" Truy vấn] Nếu thành phần máy
chủ được cung cấp dưới dạng IP theo nghĩa IP hoặc IPv4Address, thì có thể đạt được máy chủ COAP
tại địa chỉ IP đó. Nếu máy chủ là tên đã đăng ký, thì tên đó được coi là định danh gián tiếp và điểm
cuối có thể sử dụng dịch vụ độ phân giải tên, chẳng hạn như DNS, để tìm địa chỉ của máy chủ đó.
Máy chủ không được trống; Nếu một uri

được nhận với một cơ quan bị thiếu hoặc một máy chủ trống, sau đó nó phải được coi là không hợp
lệ. Subscent của cổng chỉ ra cổng UDP mà tại đó máy chủ COAP được đặt. Nếu nó trống hoặc không
được đưa ra, thì cổng mặc định 5683 được giả định. Đường dẫn xác định một tài nguyên trong phạm
vi của máy chủ và cổng. Nó bao gồm một chuỗi các phân đoạn đường dẫn được phân tách bằng một
ký tự chém (U+002F solidus "/"). Truy vấn phục vụ để tiếp tục tham số hóa tài nguyên. Nó bao gồm
một chuỗi các đối số được phân tách bằng một ký tự ampersand (U+0026 ampersand "&"). Một đối
số thường ở dạng cặp "key = value". Sơ đồ URI "COAP" hỗ trợ tiền tố đường dẫn "/ Điều này cho
phép khám phá chính sách hoặc thông tin khác về máy chủ ("Siêu dữ liệu toàn trang"), chẳng hạn
như tài nguyên được lưu trữ (xem Phần 7). Các nhà thiết kế ứng dụng được khuyến khích sử dụng
URI ngắn nhưng mô tả. Vì các môi trường mà COAP được sử dụng thường bị hạn chế đối với băng
thông và năng lượng, sự đánh đổi giữa hai phẩm chất này nên nghiêng về độ ngắn, mà không bỏ qua
tính mô tả. 6.2. Coaps URI Sơ đồ coaps-uri = "coaps:" "//" host [":" cổng] path-abempty ["?" Truy
vấn] Tất cả các yêu cầu được liệt kê ở trên cho sơ đồ "COAP" cũng là các yêu cầu cho sơ đồ "Coaps",
ngoại trừ cổng UDP mặc định của 5684 được giả định nếu thành phần con của cổng trống hoặc
không được đưa ra và Datagram UDP phải được được bảo đảm thông qua việc sử dụng DTL như
được mô tả trong Phần 9.1. Cân nhắc về bộ nhớ đệm các câu trả lời cho các yêu cầu được xác định
"Coaps" được thảo luận trong Phần 11.2. Các tài nguyên được cung cấp thông qua sơ đồ "Coaps"
không có danh tính chung với sơ đồ "COAP" ngay cả khi số nhận dạng tài nguyên của họ cho biết
cùng một cơ quan (cùng một máy chủ nghe cùng một cổng UDP). Chúng là những không gian tên
riêng biệt và được coi là máy chủ nguồn gốc riêng biệt.

6.3. Các quy tắc chuẩn hóa và so sánh kể từ các sơ đồ "COAP" và "Coaps" phù hợp với cú pháp
chung của URI, các URI đó được chuẩn hóa và so sánh theo thuật toán được xác định trong
[RFC3986], Phần 6, sử dụng các mặc định được mô tả ở trên cho từng sơ đồ. Nếu cổng bằng với
cổng mặc định cho một sơ đồ, biểu mẫu bình thường là để chọn thành phần con. Tương tự như vậy,
một thành phần đường dẫn trống tương đương với đường dẫn tuyệt đối của "/", do đó, dạng bình
thường là cung cấp đường dẫn "/" thay vào đó. Sơ đồ và vật chủ là trường hợp không nhạy cảm và
thường được cung cấp bằng chữ thường; Chữ viết IP ở dạng được đề xuất [RFC5952]; Tất cả các
thành phần khác được so sánh theo cách nhạy cảm trường hợp. Các ký tự khác với các ký tự trong
bộ "dành riêng" tương đương với các byte được mã hóa phần trăm của chúng (xem [RFC3986], Phần
2.1): Mẫu bình thường là không mã hóa chúng. Ví dụ: ba URI sau đây là tương đương và khiến các
tùy chọn và giá trị tùy chọn tương tự xuất hiện trong các thông báo CoAP: COAP: //example.com:
5683/˜Sensors/Temp.xml COAP: //example.com/%7esensors /temp.xml coap: //example.com:
/%7esensors/temp.xml 6.4. Phân tách URI vào các tùy chọn Các bước để phân tích các tùy chọn yêu
cầu từ một chuỗi | url | như sau. Các bước này hoặc dẫn đến số không hoặc nhiều tùy chọn URI-
COTS, URI-PORT, URI-PATH và URI-QUERY được bao gồm trong yêu cầu hoặc chúng thất bại. 1. Nếu
| url | Chuỗi không phải là một URI tuyệt đối ([RFC3986]), sau đó không thành công thuật toán này.
2. Giải quyết | url | Chuỗi sử dụng quy trình độ phân giải tham chiếu được xác định bởi [RFC3986].
Ở giai đoạn này, URL nằm trong mã hóa ASCII [RFC0020], mặc dù các thành phần được giải mã sẽ
được giải thích trong UTF-8 [RFC3629] sau các bước 5, 8 và 9. Lưu ý: Không quan trọng nó được giải
quyết tương đối Vì, vì chúng ta đã biết đó là một URL tuyệt đối vào thời điểm này. 3. Nếu | url |
Không có thành phần <Sơ đồ> có giá trị, khi được chuyển đổi thành chữ thường ASCII, là "coap"
hoặc "coaps", sau đó không thành công thuật toán này. 4. Nếu | url | Có một thành phần <mảnh>,
sau đó không thành công thuật toán này.

5. Nếu thành phần <host> của | url | không đại diện cho địa chỉ IP đích của yêu cầu dưới dạng IP-
Distral hoặc IPv4Address, bao gồm tùy chọn URI-HOST và để giá trị của tùy chọn đó là giá trị của
thành phần <sters> của | url |, được chuyển đổi thành chữ thường ASCII và sau đó chuyển đổi tất cả
Phần trăm mã hóa ("%" theo sau là hai chữ số thập lục phân) cho các ký tự tương ứng. Lưu ý: Trong
trường hợp thông thường trong đó địa chỉ IP đích yêu cầu được lấy từ phần máy chủ, điều này đảm
bảo rằng tùy chọn máy chủ URI chỉ được sử dụng cho một thành phần <host> của tên gọi. 6. Nếu |
url | Có một thành phần <port>, sau đó hãy để | Cổng | là thành phần giá trị của thành phần được
hiểu là một số nguyên thập phân; Nếu không, hãy để | Cổng | là cổng mặc định cho sơ đồ. 7. Nếu |
Cổng | Không bằng cổng UDP đích yêu cầu, bao gồm tùy chọn URI-Port và để tùy chọn đó giá trị của
bạn là | Cổng |. 8. Nếu giá trị của thành phần <path> của | url | là trống hoặc bao gồm một ký tự
dấu gạch chéo duy nhất (u+002F solidus "/"), sau đó chuyển sang bước tiếp theo. Mặt khác, đối với
mỗi phân đoạn trong thành phần <path>, bao gồm tùy chọn đường dẫn URI và để giá trị của tùy
chọn đó là phân đoạn (không bao gồm các ký tự dấu phân định) sau khi chuyển đổi từng phần trăm
mã hóa ("%" theo sau là hai chữ số thập lục phân)) đến byte tương ứng. 9. Nếu | url | Có một thành
phần <truy vấn>, sau đó, cho mỗi đối số trong thành phần <query>, bao gồm tùy chọn URI-Trận đấu
và để giá trị của tùy chọn đó là đối số (không bao gồm dấu câu hỏi và các ký tự ampers và phân định)
sau khi chuyển đổi từng phần trăm- mã hóa cho byte tương ứng. Lưu ý rằng các quy tắc này hoàn
toàn giải quyết bất kỳ phần trăm mã hóa. 6.5. Việc soạn UI từ các tùy chọn, các bước để xây dựng
URI từ các tùy chọn yêu cầu như sau. Các bước này hoặc dẫn đến một URI hoặc chúng thất bại.
Trong các bước này, mã hóa phần trăm một ký tự có nghĩa là thay thế từng byte (được mã hóa UTF-
8) của nó bằng một ký tự "%" theo sau là hai chữ số thập lục phân đại diện cho byte, trong đó các
chữ số A-F ở chữ hoa của [RFC3986]; Để giảm độ biến thiên, ký hiệu thập lục phân để mã hóa phần
trăm trong URI COAP phải sử dụng các chữ cái viết hoa). Các định nghĩa của "không được bảo tồn"
và "phụ trách phụ" được thông qua từ [RFC3986].

1. Nếu yêu cầu được bảo mật bằng DTLS, hãy để | URL | là chuỗi "Coaps: //". Nếu không, hãy để |
url | là chuỗi "COAP: //". 2. Nếu yêu cầu bao gồm tùy chọn lưu trữ URI, hãy để | Máy chủ | là giá trị
tùy chọn đó, trong đó bất kỳ ký tự không phải ASCII nào được thay thế bằng mã hóa phần trăm
tương ứng của chúng. Nếu | máy chủ | không phải là một reg-name hợp lệ hoặc nghĩa là IP hoặc
IPv4Address, không thành công thuật toán. Nếu yêu cầu không bao gồm tùy chọn URI-HOST, hãy để
| Máy chủ | là hình ảnh IP (sử dụng các quy ước của [RFC5952]) hoặc IPv4Address đại diện cho địa
chỉ IP đích yêu cầu. 3. Phụ lục | Máy chủ | đến | url |. 4. Nếu yêu cầu bao gồm tùy chọn URI-PANT,
hãy để | Cổng | là tùy chọn đó giá trị. Nếu không, hãy để | Cổng | là cổng UDP đích yêu cầu. 5. Nếu |
Cổng | không phải là cổng mặc định cho sơ đồ, sau đó nối một ký tự đại tràng U+003A (:) theo sau là
biểu diễn thập phân của | Cổng | đến | url |. 6. Đặt tên tài nguyên | là chuỗi trống. Đối với mỗi tùy
chọn đường dẫn URI trong yêu cầu, hãy nối một ký tự U+002F solidus (/) theo sau là giá trị của tùy
chọn thành | tên tài nguyên |, sau khi chuyển đổi bất kỳ ký tự nào không nằm trong bộ "không được
bảo vệ", trong "trong" Sub-delims "Đặt, đại tràng U+003A (:) ký tự hoặc thương mại U+0040 tại (@)
thành dạng được mã hóa phần trăm của nó. 7. Nếu | Tên tài nguyên | là chuỗi trống, đặt nó thành
một ký tự u+002f solidus (/). 8. Đối với mỗi tùy chọn URI-Quan sát trong yêu cầu, hãy nối một ký tự
U+003F đánh dấu câu hỏi (?) , sau khi chuyển đổi bất kỳ ký tự nào không có trong tập hợp "không
được lưu giữ", trong tập hợp "DELIMS phụ" (ngoại trừ U+0026 ampersand (&)) . 9. Phụ lục | Tên tài
nguyên | đến | url |. 10. Trả lại | url |. Lưu ý rằng các bước này đã được thiết kế để dẫn đến URI ở
dạng bình thường (xem Phần 6.3).