One document matched: draft-li-core-coap-payload-length-option-01.xml
<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.bormann-coap-misc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-coap-misc.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-li-core-coap-payload-length-option-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="CoAP Payload Length">CoAP Payload-Length Option Extension</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="K." surname="Li" fullname="Kepeng Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<phone>+86-755-289718087</phone>
<email>likepeng@huawei.com</email>
</address>
</author>
<author initials="X." surname="Sun" fullname="Xianghui Sun">
<organization abbrev="China Telecom">China Telecom</organization>
<address>
<postal>
<street>Xizhimen,Xicheng District</street>
<city>Beijing</city>
<code>100035</code>
<country>P. R. China</country>
</postal>
<phone>+86-010-58552839</phone>
<email>sunxh@ctbri.com.cn</email>
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Application</area>
<workgroup>CoRE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>CoAP, M2M, Payload-Length</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document defines an extension to the Constrained Application
Protocol (CoAP) to add one new option: Payload-Length,
which is used to indicate the length of the payload of the message.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This specification adds one new option to the Constrained
Application Protocol (CoAP): Payload-Length.
</t>
<section title="Motivation">
<t>
If a CoAP message is transported through UDP, the message length can
be obtained from the UDP header. But not all transport mechanisms
provide an unambiguous length of the CoAP message.
For example, in industry field, there are some data tranport protocols,
like RS232, RS422, RS485,
which don't provide message length indication.
For these cases,
an indication of the payload length of the message is needed in CoAP
message level.
</t>
<t>TBD: how about CAN bus protocol, USB 2.0? </t>
<t>
With this option, it will be easier for the receiver to extract the
payload part from the whole message.
</t>
<t>
Another benefit to have this option is to check the integrity of
the message length.
</t>
</section>
<section title="Justification">
<t>
To indicate the payload length, another alternative is to use encoding method
as specified in section 3.2 of <xref target="I-D.ietf-core-coap" />,
but it is better to use an Option for this.
</t>
<t>
Reason is that, payload length is an optional feature, and in most of
the cases, it is not necessary to be indicated. If we use encoding method,
every implementation needs to support this encoding for the payload, not
only for the options. If we use an Option for this, it is optional, and
it can be optionally implemented where necessary.
</t>
</section>
<section title="Terminology">
<t>
The terms CoAP Server and CoAP Client are used synonymously
to Server and Client as specified in the terminology section
of <xref target="I-D.ietf-core-coap" />.
</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.
</t>
</section>
</section>
<section title="Option Definition">
<figure>
<artwork>
+------+---+---+---+---+----------------+--------+--------+---------+
| Type | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+----------------+--------+--------+---------+
| TBD | - | - | - | - | Payload-Length | uint | 0-2 B | (none) |
+------+---+---+---+---+----------------+--------+--------+---------+
</artwork>
</figure>
<t>
If this option is present, the value of this option is an unsigned
integer giving the length of the payload of the message. Note that
this integer can be zero for a zero-length payload, which can in turn
be represented by a zero-length option value.
</t>
<t>
The Payload-Length option does not have a default value, so in case
of its absence the receiver MUST determine the payload length
through other means. This is to keep backward compatibility. If the
option is absent, the payload can have any size, and the payload length
needs to be determined as it is currently done for UDP.
</t>
<t>
The minimum payload length is 0, and the maximum payload length is
2^16-1= 65535.
</t>
<t>
In case that the transport layer does not provide message length
indication, the Payload-Length option SHOULD be included in the
CoAP message. Otherwise, it MAY be included.
</t>
<t> This options can be used both in the request and response. </t>
<t> This option MUST NOT occur more than once. </t>
</section>
<section title="Example">
<t>
In the example below, in the GET request, the payload is empty,
so the Payload-Length option has a zero-length option payload.
In the response, the payload is "22.3 C", and the Payload-Length
is 6.
</t>
<figure>
<artwork>
<![CDATA[
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | Token: 0x53
| | Uri-Path: "temperature"
| | Payload-Length: 0
| |
|<- - -+ Header: (T=ACK, Code=0, MID=0x7d38)
| |
| |
|<-----+ Header: 2.05 Content (T=CON, Code=69, MID=0xad7b)
| 2.05 | Token: 0x53
| | Payload: "22.3 C"
| | Payload-Length: 6
| |
| |
+- - ->| Header: (T=ACK, Code=0, MID=0xad7b)
| |
]]>
</artwork>
</figure>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The IANA is requested to add the following option number entries:
</t>
<figure>
<artwork>
+--------+----------------+----------------------------+
| Number | Name | Reference |
+--------+----------------+----------------------------+
| TBD | Payload-Length | Section 2 of this document |
+--------+----------------+----------------------------+
</artwork>
</figure>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The Payload-Length option defined in this document presents
no security
considerations beyond those in Section 10 of the base CoAP
specification <xref target="I-D.ietf-core-coap" />.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors of this draft would like to thank Carsten Bormann
and Klaus Hartke, for the initial texts in draft
<xref target="I-D.bormann-coap-misc" />.
</t>
<t>
The authors of this draft would like to thank Bert Greevenbosch
for the discussion and review.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&I-D.ietf-core-coap;
&I-D.bormann-coap-misc;
</references>
<!-- <section anchor="app-additional" title="Additional Stuff"> -->
<!-- <t>This becomes an Appendix.</t> -->
<!-- </section> -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:42:24 |