Skip to main content

Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
draft-ietf-core-stateless-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Carsten Bormann <cabo@tzi.org>, rfc-editor@rfc-editor.org, core@ietf.org, core-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-core-stateless@ietf.org, barryleiba@gmail.com, cabo@tzi.org
Subject: Protocol Action: 'Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)' to Proposed Standard (draft-ietf-core-stateless-08.txt)

The IESG has approved the following document:
- 'Extended Tokens and Stateless Clients in the Constrained Application
   Protocol (CoAP)'
  (draft-ietf-core-stateless-08.txt) as Proposed Standard

This document is the product of the Constrained RESTful Environments Working
Group.

The IESG contact persons are Murray Kucherawy and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-stateless/


Ballot Text

Technical Summary
This is a standards-track update to RFC 7252 (CoAP) and RFC 8323
(CoAP-TCP/TLS), updating the semantics of the TKL (token length) field
to support extended-length tokens, and defining how to use these for
placing requests with reduced state-keeping requirements.

Working Group Summary
There was considerable trepidation about touching the basic format of
CoAP messages, but there is now consensus that the present approach is
minimally invasive and a good way to solve the requirement for
reducing per-request state in certain cases, as required by 6TiSCH and
other technologies.

Document Quality
The document has received reviews both from core CoRE members and
members of the communities that intend to make use of it.
Implementation efforts likely will be focused initially on the environments
using the dependent documents; we have not surveyed that yet.

Personnel
Carsten Bormann is the document shepherd, and Barry Leiba is the responsible AD.

RFC Editor Note