[core] [Errata Verified] RFC7252 (4954)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 18 January 2023 09:11 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D294DC14CF1F; Wed, 18 Jan 2023 01:11:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UOm9C97QQfS; Wed, 18 Jan 2023 01:11:48 -0800 (PST)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4CEC14CEFC; Wed, 18 Jan 2023 01:11:48 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id E5FA5961FB; Wed, 18 Jan 2023 01:11:47 -0800 (PST)
To: hartke@tzi.org, zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: francesca.palombini@ericsson.com, iesg@ietf.org, core@ietf.org, iana@iana.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20230118091147.E5FA5961FB@rfcpa.amsl.com>
Date: Wed, 18 Jan 2023 01:11:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/3wGAijKsQk73uRlXdJPRLkHudX8>
Subject: [core] [Errata Verified] RFC7252 (4954)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2023 09:11:51 -0000

The following errata report has been verified for RFC7252,
"The Constrained Application Protocol (CoAP)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid4954

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Klaus Hartke <hartke@tzi.org>
Date Reported: 2017-02-28
Verified by: Francesca Palombini (IESG)

Section: 12.3

Original Text
-------------
CoAP does not include a separate way to convey content-encoding
information with a request or response, and for that reason the
content-encoding is also specified for each identifier (if any).  If
multiple content-encodings will be used with a media type, then a
separate Content-Format identifier for each is to be registered.
Similarly, other parameters related to an Internet media type, such
as level, can be defined for a CoAP Content-Format entry.

+--------------------------+----------+----+------------------------+
| Media type               | Encoding | ID | Reference              |
+--------------------------+----------+----+------------------------+


Corrected Text
--------------
CoAP does not include a separate way to convey content-coding
information with a request or response, and for that reason the
content-coding is also specified for each identifier (if any).  If
multiple content-codings will be used with a media type, then a
separate Content-Format identifier for each is to be registered.
Similarly, other parameters related to an Internet media type, such
as level, can be defined for a CoAP Content-Format entry.

+--------------------------+----------------+----+------------------+
| Content type             | Content coding | ID | Reference        |
+--------------------------+----------------+----+------------------+


Notes
-----
A CoAP Content-Format is the combination of an Internet Media Type with an HTTP Content Coding, as correctly explained in the first paragraphs of Section 12.3. However, the next paragraph (the original text above) incorrectly uses the term "content-encoding". The correct term is "content-coding", as shown in the corrected text.

Examples for _valid_ CoAP Content-Format registrations:

- media type "text/plain; charset=iso-8859-1" with content-coding "deflate"

- media type "image/png" with content-coding "" (no content-coding)

- media type "image/png" with content-coding "identity" (same as previous, no content-coding)

- media type "application/example+xml" with content-coding "exi"

Examples for _invalid_ CoAP Content-Format registrations:

- media type "application/coap-group+json" with content-coding "UTF-8" (UTF-8 is a character encoding, not a content-coding; should be media type "application/coap-group+json; charset=utf-8" with content-coding "identity")

- media type "audio/opus" with content-coding "identity" ("audio/opus" has a required parameter "rate"; should be media type "audio/opus; rate=48000" with content-coding "identity")

- media type "application/example+xml" with content-coding "identity, exi" (too many content-codings; should be media type "application/example+xml" with content-coding "identity" and, separately, media type "application/example+xml" with content-coding "exi")

- media type "application/example+exi" with content-coding "identity" ("+exi" is not a registered structured syntax suffix at the time of writing of this erratum)

- media type "video/ogg" with content-coding "exi" (EXI is a content-coding for XML information)

--------------------------------------
RFC7252 (draft-ietf-core-coap-18)
--------------------------------------
Title               : The Constrained Application Protocol (CoAP)
Publication Date    : June 2014
Author(s)           : Z. Shelby, K. Hartke, C. Bormann
Category            : PROPOSED STANDARD
Source              : Constrained RESTful Environments APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG