<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.12 --><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc strict="no"?> <?rfc compact="no"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-core-senml-data-ct-07"category="std" consensus="true"number="9193" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.9.1 --> <front> <title abbrev="SenML Data Content-FormatIndication">SenMLIndication">Sensor Measurement Lists (SenML) Fields for Indicating Data ValueContent-Format Indication</title>Content-Format</title> <seriesInfoname="Internet-Draft" value="draft-ietf-core-senml-data-ct-07"/>name="RFC" value="9193"/> <author initials="A." surname="Keränen" fullname="Ari Keränen"> <organization>Ericsson</organization> <address> <postal><street/><city>Jorvas</city> <code>02420</code> <country>Finland</country> </postal> <email>ari.keranen@ericsson.com</email> </address> </author> <author initials="C." surname="Bormann" fullname="Carsten Bormann"> <organization>Universität Bremen TZI</organization> <address> <postal> <street>Postfach 330440</street> <city>Bremen</city> <code>D-28359</code> <country>Germany</country> </postal> <phone>+49-421-218-63921</phone> <email>cabo@tzi.org</email> </address> </author> <dateyear="2021"/> <keyword>Internet-Draft</keyword>year="2022" month="June"/> <keyword>Internet of Things (IoT)</keyword> <keyword>Internet of Things</keyword> <keyword>IOT</keyword> <keyword>data model</keyword> <keyword>media type</keyword> <abstract> <t>The Sensor Measurement Lists (SenML) mediatype supportstypes support multiple types of values, from numbers to text strings and arbitrary binarydata values.Data Values. In order to facilitate processing of binarydata values,Data Values, this document specifies a pair of new SenML fields for indicating the content format of those binarydata values,Data Values, i.e., their Internet mediatypetype, including parameters as well as any content codings applied.</t> </abstract> </front> <middle> <section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t>The Sensor Measurement Lists (SenML) media types <xref target="RFC8428" format="default"/> can be used to send various kinds of data. In the example given in <xref target="ex-1" format="default"/>, a temperature value, an indication whether a lock is open, and adata valueData Value (with SenML field "vd") read froman NFCa Near Field Communication (NFC) reader is sent in a single SenMLpack.Pack. The example is given in SenML JSON representation, so the "vd"(data value)(Data Value) field is encoded as a base64url string (without padding), as per <xref section="5" sectionFormat="of" target="RFC8428" format="default"/>.</t> <figure anchor="ex-1"> <name>SenMLpackPack withunidentified binary data</name>Unidentified Binary Data</name> <sourcecode type="senml-json"><![CDATA[ [ {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1}, {"n":"open","vb":false}, {"n":"nfc-reader","vd":"aGkgCg"} ] ]]></sourcecode> </figure> <t>The receiver is expected to know how to interpret the data in the "vd" field based on the context, e.g., the name of the data source and out-of-band knowledge of the application. However, this context may not always be easily available to entities processing the SenMLpack,Pack, especially if thepackPack is propagated over time and via multiple entities. To facilitate automaticinterpretationinterpretation, it is useful to be able to indicate an Internet media type and, optionally, content codings right in the SenML Record.</t> <t>TheCoAPConstrained Application Protocol (CoAP) Content-Format (<xref section="12.3" sectionFormat="of" target="RFC7252" format="default"/>) provides this information in the form of a single unsignedinteger; enclosing ainteger. For instance, <xref target="RFC8949" format="default"/> defines the Content-Format number(in this case number60as definedforcontent-type application/cbor in <xref target="RFC8949" format="default"/>)Content-Type application/cbor. Enclosing this Content-Format number in the Record is illustrated in <xref target="ex-2" format="default"/>. All registered CoAP Content-Format numbers are listed in the<xref section="COAP Content-Formats registry" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters" format="default"/>"CoAP Content-Formats" registry <xref target="IANA.core-parameters"format="default"/>format="default"/>, as specified by <xref section="12.3" sectionFormat="of" target="RFC7252" format="default"/>. Note that, at the time of writing, the structure of this registry only provides for zero or one contentcodings;coding; nothing in the present document needs to change if the registry is extended to allow sequences of content codings.</t> <figure anchor="ex-2"> <name>SenML Record withbinary data identifiedBinary Data Identified as CBOR</name> <sourcecode type="json"><![CDATA[ {"n":"nfc-reader", "vd":"gmNmb28YKg", "ct":"60"} ]]></sourcecode> </figure> <t>In this example SenML Record, thedata valueData Value contains a string "foo" and a number 42 encoded in aCBORConcise Binary Object Representation (CBOR) <xref target="RFC8949" format="default"/> array. Since the example above uses the JSON format of SenML, thedata valueData Value containing the binary CBOR value isbase64-encodedbase64 encoded (<xref section="5" sectionFormat="of" target="RFC4648" format="default"/>). Thedata valueData Value after base64 decoding is shown with CBOR diagnostic notation in <xref target="ex-2-cbor" format="default"/>.</t> <figure anchor="ex-2-cbor"> <name>Example Data Value in CBORdiagnostic notation</name>Diagnostic Notation</name> <sourcecode type="cbor-pretty"><![CDATA[ 82 # array(2) 63 # text(3) 666F6F # "foo" 18 2A # unsigned(42) ]]></sourcecode> </figure> <section anchor="evolution" numbered="true" toc="default"> <name>Evolution</name> <t>As with SenML in general, there is no expectation that the creator of a SenMLpackPack knows (or has negotiated with) each consumer of thatpack,Pack, which may be very remote in space and particularly in time. This means that the SenML creator in general has no way to know whether the consumer knows:</t> <ul spacing="normal"> <li>each specificmedia-type-name used</li>Media-Type-Name used,</li> <li>each parameter and each parameter valueused</li>used,</li> <li>each content coding inuse</li>use, and</li> <li>each Content-Format number in use for a combination ofthese</li>these.</li> </ul> <t>What SenML, as well as the new fields defined here, guarantees is that a recipient implementation <em>knows</em> when it needs to be updated to understand these field values and the values controlled by them; registries are used to evolve these name spaces in a controlled way. SenMLpacksPacks can be processed by a consumer while not understanding all the information in them, and information can generally be preserved in this processing such that it is useful for further consumers.</t> </section> </section> <section anchor="terminology" numbered="true" toc="default"> <name>Terminology</name> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL</bcp14> NOT", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t><dl> <dt> Media Type:<dl newline="false" spacing="normal"> <dt>Media type: </dt><dd> <t>A<dd>A registered label for representations (byte strings) prepared forinterchange, identified by a Media-Type-Nameinterchange <xref target="RFC1590"format="default"/>,format="default"/> <xref target="RFC6838"format="default"/>.</t> </dd> <dt> Media-Type-Name:format="default"/>, identified by a Media-Type-Name.</dd> <dt>Media-Type-Name: </dt><dd> <t>A<dd>A combination of a type-name and a subtype-name registered in <xref target="IANA.media-types"format="default"/>format="default"/>, as per <xref target="RFC6838" format="default"/>, conventionally identified by the two names separated by aslash.</t> </dd> <dt> Content-Type:slash.</dd> <dt>Content-Type: </dt><dd> <t>A<dd>A Media-Type-Name, optionally associated with parameters (<xref section="5" sectionFormat="of" target="RFC2045" format="default"/>, separated from the Media-Type-Name and from each other by a semicolon). In HTTP and many other protocols, it is used in a <tt>Content-Type</tt> headerfield.</t> </dd> <dt> contentfield.</dd> <dt>Content coding: </dt><dd> <t>A<dd>A name registered in the<xref section="HTTP"HTTP Content Codingregistry" relative="#content-coding" sectionFormat="bare" target="IANA.http-parameters" format="default"/>Registry" <xref target="IANA.http-parameters"format="default"/>format="default"/>, as specified by Sections <xreftarget="I-D.ietf-httpbis-semantics"target="RFC9110" section="16.6.1" sectionFormat="bare" format="default"/> and <xreftarget="I-D.ietf-httpbis-semantics"target="RFC9110" section="18.6" sectionFormat="bare" format="default"/> of <xreftarget="I-D.ietf-httpbis-semantics"target="RFC9110" format="default"/>, indicating an encoding transformation with semantics further specified in <xref section="8.4.1" sectionFormat="of"target="I-D.ietf-httpbis-semantics"target="RFC9110" format="default"/>. Confusingly, in HTTP, content coding values are found in a header field called"Content-Encoding", however"Content-Encoding"; however, "content coding" is the correct term for the process and the registeredvalues.</t> </dd> <dt> contentvalues.</dd> <dt>Content format: </dt><dd> <t>the<dd>The combination of a Content-Type and zero or more content codings, identified by (1) a numeric identifier defined in the<xref section="COAP Content-Formats registry" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters" format="default"/>"CoAP Content-Formats" registry <xref target="IANA.core-parameters"format="default"/>format="default"/>, as per <xref section="12.3" sectionFormat="of" target="RFC7252" format="default"/> (referred to as Content-Format number), or (2) aContent-Format-String.</t> </dd> <dt> Content-Format-String: </dt> <dd> <t>theContent-Format-String.</dd> <dt>Content-Format-String:</dt> <dd>The string representation of the combination of a Content-Type and zero or more contentcodings.</t> </dd> <dt> Content-Format-Spec: </dt> <dd> <t>thecodings.</dd> <dt>Content-Format-Spec:</dt> <dd>The string representation of a content format; either a Content-Format-String or the (decimal) string representation of a Content-Formatnumber.</t> </dd>number.</dd> </dl> <t>Readers should also be familiar with the terms and concepts discussed in <xref target="RFC8428" format="default"/>.</t> </section> <section anchor="senml-content-format-ct-field" numbered="true" toc="default"> <name>SenML Content-Format ("ct") Field</name> <t>When a SenML Record contains a Data Value field ("vd"), the Record <bcp14>MAY</bcp14> also include a Content-Format indication field, using label "ct". The value of this field is a Content-Format-Spec, i.e., oneof:</t>of the following:</t> <ul spacing="normal"> <li>a CoAP Content-Format number in decimal form with no leading zeros (except for the value "0" itself). This value represents an unsigned integer in the range of 0-65535, similar to the "ct" attribute defined in <xref section="7.2.1" sectionFormat="of" target="RFC7252" format="default"/> for CoRE Link Format <xref target="RFC6690"format="default"/>).</li> <li>or aformat="default"/>.</li> <li>a Content-Format-String containing a Content-Type and zero or more content codings (see below).</li> </ul> <t>The syntax of this field is formally defined in <xref target="abnf" format="default"/>.</t> <t>The CoAP Content-Format number provides a simple and efficient way to indicate the type of the data. Since some Internet media types and their content coding and parameter alternatives do not have assigned CoAP Content-Format numbers, using Content-Type and zero or more content codings is also allowed. Both methods use a string value in the "ct" field to keep its data type consistent across uses. When the "ct" field contains only digits, it is interpreted as a CoAP Content-Format number.</t> <t>To indicate that one or more content codings are used with a Content-Type, each of the content coding values is appended to the Content-Type value (media type and parameters, if any), separated byaan "@" sign, in the order of when the content codings were applied (the same order as in <xref section="8.4" sectionFormat="of"target="I-D.ietf-httpbis-semantics"target="RFC9110" format="default"/>). For example (using a content coding value of"deflate""deflate", as defined in <xref section="8.4.1.2" sectionFormat="of"target="I-D.ietf-httpbis-semantics"target="RFC9110" format="default"/>):</t> <artwork name="" type="" align="left" alt=""><![CDATA[ text/plain; charset=utf-8@deflate ]]></artwork> <t>If no "@" sign is present after the media type and parameters, then no content coding has been specified, and the "identity" content coding is used -- no encoding transformation is employed.</t> </section> <section anchor="senml-base-content-format-bct-field" numbered="true" toc="default"> <name>SenML Base Content-Format ("bct") Field</name> <t>The Base Content-FormatField,field, label "bct", provides a default value for the Content-FormatFieldfield (label "ct") within its range. The range of the base field includes the Record containing it, up to (but not including) the next Record containing a "bct" field, if any, or up to the end of thepackPack otherwise. The process of resolving (<xref section="4.6" sectionFormat="of" target="RFC8428" format="default"/>) this base field is performed by adding its value with the label "ct" to all Records in this range that carry a "vd" field but do not already contain a Content-Format ("ct") field.</t> <t><xref target="ex-bct" format="default"/> shows a variation of <xref target="ex-2" format="default"/> with multiple records, with the "nfc-reader" records resolving to the base field value "60" and the "iris-photo" record overriding this with the "image/png" media type (actual data left out for brevity).</t> <figure anchor="ex-bct"> <name>SenMLpackPack with the bctfield</name>Field</name> <sourcecode type="senml-json"><![CDATA[ [ {"n":"nfc-reader", "vd":"gmNmb28YKg", "bct":"60", "bt":1627430700}, {"n":"nfc-reader", "vd":"gmNiYXIYKw", "t":10}, {"n":"iris-photo", "vd":".....", "ct":"image/png", "t":10}, {"n":"nfc-reader", "vd":"gmNiYXoYLA", "t":20} ] ]]></sourcecode> </figure> </section> <section anchor="examples" numbered="true" toc="default"> <name>Examples</name> <t>The following examples are valid values for the "ct" and "bct" fields (explanation/comments in parentheses):</t> <ul spacing="normal"> <li>"60" (CoAP Content-Format number for "application/cbor")</li> <li>"0" (CoAP Content-Format number for "text/plain" with parameter "charset=utf-8")</li> <li>"application/json" (JSON Content-Type -- equivalent to "50" CoAP Content-Format number)</li> <li>"application/json@deflate" (JSON Content-Type with "deflate" as content coding -- equivalent to "11050" CoAP Content-Format number)</li> <li>"application/json@deflate@aes128gcm" (JSON Content-Type with "deflate" followed by "aes128gcm" as content codings)</li> <li>"text/csv" (Comma-Separated Values (CSV) <xref target="RFC4180" format="default"/> Content-Type)</li> <li>"text/csv;header=present@gzip" (CSV with header row, using "gzip" as content coding)</li> </ul> </section> <section anchor="abnf" numbered="true" toc="default"> <name>ABNF</name> <t>This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation <xref target="RFC5234" format="default"/>, which contains three new rules and a number of rules collected and adapted from various RFCs <xreftarget="I-D.ietf-httpbis-semantics"target="RFC9110" format="default"/> <xref target="RFC6838" format="default"/> <xref target="RFC5234" format="default"/> <xref target="RFC8866" format="default"/>.</t> <figure anchor="content-format-spec"> <name>ABNFsyntaxSyntax of Content-Format-Spec</name> <sourcecode type="abnf"><![CDATA[ ; New in this document Content-Format-Spec = Content-Format-Number / Content-Format-String Content-Format-Number = "0" / (POS-DIGIT *DIGIT) Content-Format-String = Content-Type *("@" Content-Coding) ; Cleaned up from[RFC-httpbis-semantics],RFC 9110, ; leaving only SP as blank space, ; removing legacy 8-bit characters, and ; leaving the parameter as mandatory with each semicolon: Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) parameter = token "=" ( token / quoted-string ) token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA quoted-string = %x22 *( qdtext / quoted-pair ) %x22 qdtext = SP / %x21 / %x23-5B / %x5D-7E quoted-pair = "\" ( SP / VCHAR ) ; Adapted fromsectionSection 8.4.1 of[RFC-httpbis-semantics]RFC 9110 Content-Coding = token ; Adapted from various specs Media-Type-Name = type-name "/" subtype-name ; From RFC 6838 type-name = restricted-name subtype-name = restricted-name restricted-name = restricted-name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_" restricted-name-chars =/ "." ; Characters before first dot always ; specify a facet name restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix ; Boilerplate from RFC 5234 and RFC 8866 DIGIT = %x30-39 ; 0–- 9 POS-DIGIT = %x31-39 ; 1–- 9 ALPHA = %x41-5A / %x61-7A ; A–- Z / a–- z SP = %x20 VCHAR = %x21-7E ; printable ASCII (no SP) ]]></sourcecode> </figure><t><cref anchor="replace">RFC editor: Please replace [RFC-httpbis-semantics] by what gets published from <xref target="I-D.ietf-httpbis-semantics" format="default"/>.</cref></t></section> <section anchor="seccons" numbered="true" toc="default"> <name>Security Considerations</name> <t>The indication of a media type in the data does not exempt a consuming application from properly checking its inputs. Also, the ability for an attacker to supply crafted SenML data thatspecifyspecifies media types chosen by the attacker may expose vulnerabilities of handlers for these media types to the attacker. This includes "decompression bombs", compressed data that is crafted to decompress to extremely large data items.</t> </section> <section anchor="iana" numbered="true" toc="default"> <name>IANA Considerations</name><t>(Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification and remove this note.)</t><t>IANAis requested to assignhas assigned the following new labels in the "SenML Labels"<xref section="subregistry" sectionFormat="bare" target="IANA.senml" relative="#senml-labels" format="default"/>subregistry of theSenML"Sensor Measurement Lists (SenML)" registry <xref target="IANA.senml" format="default"/> (as defined in <xref section="12.2" sectionFormat="of" target="RFC8428" format="default"/>) for the Content-Formatindicationindication, as per <xref target="tbl-senml-reg" format="default"/>:</t> <table anchor="tbl-senml-reg" align="center"> <name>IANA Registration fornewNew SenML Labels</name> <thead> <tr> <th align="right">Name</th> <th align="left">Label</th> <th align="left">JSON Type</th> <th align="left">XML Type</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="right">Base Content-Format</td> <td align="left">bct</td> <td align="left">String</td> <td align="left">string</td> <tdalign="left">RFC-AAAA</td>align="left">RFC 9193</td> </tr> <tr> <td align="right">Content-Format</td> <td align="left">ct</td> <td align="left">String</td> <td align="left">string</td> <tdalign="left">RFC-AAAA</td>align="left">RFC 9193</td> </tr> </tbody> </table> <t>Notethat asthat, per <xref section="12.2" sectionFormat="of" target="RFC8428" format="default"/>, no CBOR labelsor EXInor Efficient XML Interchange (EXI) schemaId values (EXI ID column) are supplied.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC2045" target="https://www.rfc-editor.org/info/rfc2045"> <front> <title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> <author fullname="N. Freed" initials="N." surname="Freed"> <organization/> </author> <author fullname="N. Borenstein" initials="N." surname="Borenstein"> <organization/> </author> <date month="November" year="1996"/> <abstract> <t>This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2045"/> <seriesInfo name="DOI" value="10.17487/RFC2045"/> </reference> <reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8428"> <front> <title>Sensor Measurement Lists (SenML)</title> <author fullname="C. Jennings" initials="C." surname="Jennings"> <organization/> </author> <author fullname="Z. Shelby" initials="Z." surname="Shelby"> <organization/> </author> <author fullname="J. Arkko" initials="J." surname="Arkko"> <organization/> </author> <author fullname="A. Keranen" initials="A." surname="Keranen"> <organization/> </author> <author fullname="C. Bormann" initials="C." surname="Bormann"> <organization/> </author> <date month="August" year="2018"/> <abstract> <t>This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</t> </abstract> </front> <seriesInfo name="RFC" value="8428"/> <seriesInfo name="DOI" value="10.17487/RFC8428"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.xml"/> <reference anchor="IANA.senml" target="https://www.iana.org/assignments/senml"> <front> <title>Sensor Measurement Lists (SenML)</title> <author> <organization>IANA</organization> </author><date/></front> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <referenceanchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252">anchor='RFC9110'> <front><title>The Constrained Application Protocol (CoAP)</title> <author fullname="Z. Shelby" initials="Z." surname="Shelby"> <organization/> </author><title>HTTP Semantics</title> <authorfullname="K. Hartke" initials="K." surname="Hartke"> <organization/> </author> <author fullname="C. Bormann" initials="C." surname="Bormann"> <organization/>initials='R' surname='Fielding' fullname='Roy Fielding' role="editor"> <organization /> </author> <author initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor"> <organization /> </author> <author initials='J' surname='Reschke' fullname='Julian Reschke' role="editor"> <organization /> </author> <datemonth="June" year="2014"/> <abstract> <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t> <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t> </abstract>year='2022' month='June' /> </front> <seriesInfo name="RFC"value="7252"/> <seriesInfo name="DOI" value="10.17487/RFC7252"/> </reference> <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234"> <front> <title>Augmented BNF for Syntax Specifications: ABNF</title> <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"> <organization/> </author> <author fullname="P. Overell" initials="P." surname="Overell"> <organization/> </author> <date month="January" year="2008"/> <abstract> <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t> </abstract> </front>value="9110"/> <seriesInfo name="STD"value="68"/> <seriesInfo name="RFC" value="5234"/>value="97"/> <seriesInfo name="DOI"value="10.17487/RFC5234"/> </reference> <reference anchor="I-D.ietf-httpbis-semantics" target="https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.txt"> <front> <title>HTTP Semantics</title> <author fullname="Roy T. Fielding"> <organization>Adobe</organization> </author> <author fullname="Mark Nottingham"> <organization>Fastly</organization> </author> <author fullname="Julian Reschke"> <organization>greenbytes GmbH</organization> </author> <date day="12" month="September" year="2021"/> <abstract> <t> The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-19"/>value="10.17487/RFC9110"/> </reference> <reference anchor="IANA.media-types" target="https://www.iana.org/assignments/media-types"> <front> <title>Media Types</title> <author> <organization>IANA</organization> </author><date/></front> </reference> <reference anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters"> <front> <title>Constrained RESTful Environments (CoRE) Parameters</title> <author> <organization>IANA</organization> </author><date/></front> </reference> <reference anchor="IANA.http-parameters" target="https://www.iana.org/assignments/http-parameters"> <front> <title>Hypertext Transfer Protocol (HTTP) Parameters</title> <author> <organization>IANA</organization> </author><date/></front> </reference><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"> <organization/> </author> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"> <organization/> </author> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name><reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648"> <front> <title>The Base16, Base32, and Base64 Data Encodings</title> <author fullname="S. Josefsson" initials="S." surname="Josefsson"> <organization/> </author> <date month="October" year="2006"/> <abstract> <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/> </reference> <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949"> <front> <title>Concise Binary Object Representation (CBOR)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"> <organization/> </author> <author fullname="P. Hoffman" initials="P." surname="Hoffman"> <organization/> </author> <date month="December" year="2020"/> <abstract> <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t> </abstract> </front> <seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/> </reference> <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838"> <front> <title>Media Type Specifications and Registration Procedures</title> <author fullname="N. Freed" initials="N." surname="Freed"> <organization/> </author> <author fullname="J. Klensin" initials="J." surname="Klensin"> <organization/> </author> <author fullname="T. Hansen" initials="T." surname="Hansen"> <organization/> </author> <date month="January" year="2013"/> <abstract> <t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="13"/> <seriesInfo name="RFC" value="6838"/> <seriesInfo name="DOI" value="10.17487/RFC6838"/> </reference> <reference anchor="RFC1590" target="https://www.rfc-editor.org/info/rfc1590"> <front> <title>Media Type Registration Procedure</title> <author fullname="J. Postel" initials="J." surname="Postel"> <organization/> </author> <date month="March" year="1994"/> <abstract> <t>Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t> </abstract> </front> <seriesInfo name="RFC" value="1590"/> <seriesInfo name="DOI" value="10.17487/RFC1590"/> </reference> <reference anchor="RFC6690" target="https://www.rfc-editor.org/info/rfc6690"> <front> <title>Constrained RESTful Environments (CoRE) Link Format</title> <author fullname="Z. Shelby" initials="Z." surname="Shelby"> <organization/> </author> <date month="August" year="2012"/> <abstract> <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6690"/> <seriesInfo name="DOI" value="10.17487/RFC6690"/> </reference> <reference anchor="RFC4180" target="https://www.rfc-editor.org/info/rfc4180"> <front> <title>Common Format and MIME Type for Comma-Separated Values (CSV) Files</title> <author fullname="Y. Shafranovich" initials="Y." surname="Shafranovich"> <organization/> </author> <date month="October" year="2005"/> <abstract> <t>This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4180"/> <seriesInfo name="DOI" value="10.17487/RFC4180"/> </reference> <reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8866"> <front> <title>SDP: Session Description Protocol</title> <author fullname="A. Begen" initials="A." surname="Begen"> <organization/> </author> <author fullname="P. Kyzivat" initials="P." surname="Kyzivat"> <organization/> </author> <author fullname="C. Perkins" initials="C." surname="Perkins"> <organization/> </author> <author fullname="M. Handley" initials="M." surname="Handley"> <organization/> </author> <date month="January" year="2021"/> <abstract> <t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.</t> </abstract> </front> <seriesInfo name="RFC" value="8866"/> <seriesInfo name="DOI" value="10.17487/RFC8866"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1590.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6690.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4180.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml"/> </references> </references> <section numbered="false" anchor="acks" toc="default"><name>Acknowledgements</name><name>Acknowledgments</name> <t>The authors would like to thank <contact fullname="Sérgio Abreu"/> for the discussions leading to the design of this extension and <contact fullname="Isaac Rivera"/> for reviews and feedback. <contact fullname="Klaus Hartke"/> suggested not burdening thisdraftdocument with a separate mandatory-to-implement version of the fields. <contact fullname="Alexey Melnikov"/>, <contact fullname="Jim Schaad"/>, and <contact fullname="Thomas Fossati"/> provided helpful comments atWorking-Group last call.Working Group Last Call. <contact fullname="Marco Tiloca"/> asked for clarifying and using the term Content-Format-Spec.</t> </section> </back><!-- ##markdown-source: H4sIAJ+acWEAA51b63rbRnr+P1cxC3c3pEPQJHWwTEetaVmOlfhUS8nGm81u QGJIogIBBgNIZmTl6T20F9Af+6e30dxJr6Tv980MTqS82ep5TJODmW++82kG vu8LnQdJ+NcgThM1lnlWKBGtM/6m89Fg8GgwEmE6S4IVHodZMM/9SOVzf5Zm ytcqWcV+GOSBP8v9OMiVzsWl2lynWTiWZ0muskTl/jNaJmZBPpY6D8UsTbBQ F9rut47GQso8nY3lZxulPzM/0tU6mOWNoVCt8yVG9uzvKAlVUpuiN6tMzXVt IM3y5gjArrCmNhIlcUSkl2vyLOJ9k9QusHiY37qYNofyKI+x/Fwlr17KZ2CF /DaICyVPUpCf5P7zNFsFOZgRRuBAlCYimE4zddVYcvdkMBfQR4PRUARFvkyz sfCBMwiY9OXXKvv1b4lKgJcR0CSL6oNpthjLU9CjdZoY2pQixJmyKN+M5Vdp dhVoJjQkLgxG+6OBIbxI8gwznoNDUBEMqVUQxWMZZFH/UmUB9niiLPA+mCJ8 ZidQO+nLp0RJUmF2EmQaJNbGGblvkuhKZTrKf/1bLp9mCsKRF386q+H6NtX5 PJgt5d7eYH9/UCJuJpeIP/NHR3sHj+qIf6loqw2G1kvW7s/3H/n7o6E/Gh75 h3uPwNKSplkwTZ/kP0d9YCVEwmIAZqSY756fjAb7B2O5ilZqaAaO9kdHUGZS fwycTV5P+vzDzn84OhgBZhqsze+D0d4++DZN5uKenbA3GMtlnq8H1cjQjBBA /1mfrYx+TyMNQwMlOVhtpviJunb7rlQYBX6+WSs8rP1wz9lQ10EGKcAcNaHV GHDzGG59XmtARMm8xZb9w31wYRpoZbnyaP8R4E/TzPw+PNo7sjgRSn6mwFvf 98EJSBcmJMTFUpEdwFDlKxXogoWay5eRzrXssIV0DQRJIGB+6zWMWstVEefR OlbSEJvO5RWZne7JeZauZFKspkAaXkLm6kPOVp0stIQiQ3+nEbbPNnIaJfQf OTC7vC/OEmhmqDJaCr2L4iiHCcp1ls6U1gAisdf2wp7Ml5GWcJUFUSD0Ws2i eaSwpVwHUUarIDVr9HgQh1qCoTAYY+sAnC8VOUfyBNLwmlbB6LXauWPUV33a VwG8c7aGWYKZFSWzuAgJciVGGWh5reKY/odxSLcfrMgwaL2OIxX2jaBWURjG SggoKTbI0rCYkVeSN/ci+nn7DwtQy5sbEzZub2F0iZwqWWgVCnAbwyFoy6K0 0PISfNFEPlHch44mRKhUH4IVSX0BLUxAoLi5UR/84e1tD3zO1WoNv5QDCcMj DCYlg4H29VIBSIapcTq7lJBXulYJzQpFUOOt7FxH+bIuK+ldhV5XZioIjYIB 8OvnJzwAgICkiewokYEgJYmVXY1IcdlnLjnUMddhb+d8df7mNSCtM0VAGNUe YhcTTPvKDqEmGLWuxQdQVEKuL2RJshUe7hdZbFXdkJAWuVgHIYm226OJ4A8k cK6MGA+IwU4cEPkvv/xinJr/bxQwvocZ33jTxBt7RZaMQwSt9Ho8HKjR4OFe MBgOjgaDw72x1/NoCnEfXwt8PVExvl1544f94W2PodAMYjaNT73xPIi1qj1K 5jPf8JImhBgJvrxcnCy8W/EDoSVuxvIeSVpyvD32Ku5KllWRRJQMkMmFdWPx rI5maqYo1DDjPsA4c8yD0l0m6bVc4h++R2RDkELOnGd1iJJSCsIwnhgdytSM s/V8yHtS9RcwRQp1xmTtcp0W2Uyx14Eo/HTuT0nXaNNYhYtyMludUdK+fJFe K2BqPYrdQq6CjUzSXAbxdbDRsBsBc4vijQyuEMGCKbnCVBILcvI6NX+VL+vK CFzZNwUx1kZzQU+ZjREvWgeLgFiTEq9yRDxG/grmW3pct0dfXtRdJOUnKcWH WcVIY3ZRTsBh5vMiJiRh8w5fa5y0S+nCRM3fY/MejJTAEMK9LX+VRYtl7sRk qHynEOLIg5HcT9LJW9FKrzqVBQxH/T02AgrWt7ddYsEVNEkz86uYlyZuDxqg FRCusfMi0dEiAcuI6oXKHpNhximzfiuzM3FJdhgYSRfa5AYPB7BQEap5RNAo NlhifcOKSkceUIwlhOBM6SshbtEzxEvCPY4LCrM5oybZUY5g5nIC749QDA+t MjwjDu1GE34FnjSmiaGw8G9uHFKGM3DyJ2+2AGhhNsg23S92ZSFw/oT61iA8 lAucsLSNuFNQffE6hdbkywDGFxiDZW3FlOssonDKkZG8IWIWRQQ2NbDcYQYb jjeilDfx+2eVpYj+eKLaivaYjG9JMrWMsN5auIiP6K5CTjhmyyCBaUfGtMvt 2PEAZGgcD9Q5vRZa/VRAXRSHutaW1iGzK972ktK4ycXq9Wo6Onr/9YKGZjmG DgdwejWfOWr6TKsh7DXrWUXNf0IMJ0/fvCPfeWYV1UWvOoxe5ehM2CQCAlQA ZBwmCnnzNPVM1iWsmu+PyshF4ZJ3qhQZKpcFm748R/KiGiEfGfqVEvAimoc5 aFZZEuN1F0LOC1pyaUcTTUkoJnL6DqdOOzzScxiYCeI12KhpQY1ZLUNlhMaZ AMJJIpi/TBuc2SJBFQPHCB0qnYkxSEu2lTX98Mlx5htxNJLV3z3Dl86oi5Ap D/eqcQoOnT0epieHh88Pn2OYGU+DwyM5mti5zlV19gGnriGMhVOTU8vwWjEL dO8ihZTk3j15epXGBVesYqJlLX3C0oVKkJbFLJ2MeZ6kNggbbpAZm3gK7c7J AOfIx2ohngImPA2eLKGbiVqkecSOjTbqSkX1IbUVYImZMXQA5GgnrpcRHlL0 RNhBUNvAIlfkO4CYxhQT4OCFQFQRBxlFxYR9CUkcuK5UkOgKRYOVQ7SizmCW SkRnl1cIl2/aVMGgx7SMkV8btK2/m9VqN5/zCE6L7aTSSTKyrSGjjvXpTUdC SOKpe7g7Ipk57AUDanqQqbBsTIaC5eKPxAJrZ7UqgoijysbWNC5+kah7clEA TewHo40MEyFY5GLROuJ8mRRt5ZJeeZ95c5/ydM4aSpdKVcI6DEzOJgr40Iz7 VgY1mxKbskjaYfeTeJGlccwBhR6sHrvgxNVZZljHyRN0+EpZmCwDVhBt/FQN EGTcF5V6alfJ2KTLbBVUIocOwp4oe6tQ5/Qgjjn/2k4zVlyUNB7QHlbX4o3Z DXhmV+xHBTvpWtKnC4ialbaRfZF850XGWunQo0BzT16obBUlaZwuNiZzulQb SY08Lb1X35xfUHih/+XrN/z93em/fnP27vQZfT9/MXn5svwi7IzzF2++efms +latPHnz6tXp62dmMUZlY0h4rybvPcMA783bi7M3rycvPelSpjLgkuiMbpT5 JscupFB6lkVTE2Cenrz9n/8a7sPd/o46OcPhI04+6MfR8OE+fpC2md0oI7A/ waGNQMqlArYN8BwCWCPRjTVrPzt5VnJw7/73xJkfxvKL6Ww93P9nO0AENwYd zxqDzLPtka3Fhok7hnZsU3KzMd7idBPfyfvGb8f32qAQrzgxv4CLGouxnNSz SFQgyqhXs5CF155ucuUaMJRgK7guk+ByvxDrTcbUq6cgbEC8n0/7+a/JHG9u /gViGx48Gtya2vHGb3SXOI62FhlMWx7NVBfGz3JyQn3daqhGV5TU9jGdNZOn mkq6vT8XKFdEhSlYiMIGUZyoXqfsXqhpQG48d/TqONBLkOBcdMXpFlH1mgjI 6HRWhUPZ6O1tpTPcxSREq72poUEddaDW5jgxh/sdHDpS9hsGVbWKZvAWCRIj 7s68uLh4y9Op52pnwh9RJ59Mhn0s+9Ef69T9CBPiDgq7cJDeDF2G+G2ZtEoR G+c6jIMFj/9pEMi1SpFWX9OUItuD7VJEVn0TLYeH/cP+kMkdHvUPmbGuMUu8 rTX14LU5tTS4oB5LdOXTWV5lc7f0zNXGnCc6AR7197EpciNZ3434D5rnBdej G9qchdGulcv4mFGYLxIrjjr/qXsecITznJBOLe7wx0vTl0CV0YDrmchOGU6G yJ4TlYgl7AtMocRBqYzLNUG6nmur60lSNwBbRlvXHIbnCrYVKsl2+VR3J8AJ WtsZdgEkoZhHTQr3NCtzlk/XuIbP9Sq3rVq/rcoFnK1OXKu8lZ1MzVWW2VJR tzamUxVO27o9oh5VwVanwT9nh1tzJo1xx2JbpjV9tutK/V3+A49PSWDH5lDs v7t1IJvq8FiqyLRttyRgqZFW1Toow6JVEHc/AXwLhmUlkH3HpsCxvUA+iVDP 2cU8WEVxhDyArZUdOPTbKDQwnak1NCGM9KzQxsmJqsfd5965SRXbXSiq1rvy ORsekmtF1tgo0WvldK0WM8luhxvSvXrPByFcMM6m76+2u0+1VjhDIbdMbDLB m/DpS4nczxbHrmNSdpy3lQzydOcQ1DRJ5yhs7vO8u5pKZGRWTKaXxlxF4RSD +8ZJkk7B5tQHYm3pRwxO3gD+JtcqnncZV2BlHpSiJsEASLst54w74+YMSBv4 hwcHewcIhBHkG/CBD01gPpCN5tChaYHcpeYeKot92B+xMy5NlvA8Sd+dypdR con1lmqTsxweUs7SpVxRcom1W49r/Yp/2NpkRysFfY3T665tfuoNwH3YliPb FaUODcrofJI11vVN7xBg2TKjFqhpzVBROkcRy0UdqiNRb+2yxRANtc44ZGc6 PDpFbG8eXtmDIqLYnG214pit111BHNNaPpak2oCrrGWAMg5pESuA+ESD0xnA JwNLKyfRgiyB7IxbeCqkw26oMNBZpiFXWlX/68q1T/gUAYplhYAq9lKpNamy 6Skxg6gio9hIxc0MNsDANHjF3qEJQpTegauWMFoAVs9We82CaLc9itLvXTSE Rf00MuU7tKwsmNlum1raEyZNdOFjV/oR8Rlj2QbNl6rJfXsAVzvGbMibSJzT yWW3186evSeeJJH3HL/NOW5qzjjadFxTK8qedsoOByQ+veE1gd7KvEQzx4OJ gY1lc7JT2H7/LqKJIR5MjS7IeAS7MjvRyu76o1Yu2YVDpeYdtfkerGMI/DE1 mDOt8uMin/tHTyxgIc7m5EYdF8x5DntE26okGptHK3W2EpMSAtCigNpaU6WS KintlamcZ3KofOO1bMR2HEL5v//+n9zss1lkO/+lxjL4l274xNkFyqd0KLIV Laf1cEkuate05yas2YBGS3p1fwVeBUWcW7FQBVrXvzoM2amCYpd1PUrYWjl+ mDBZxRI6uadOsHOxJgDrenSuufYoh99Zk/Z3EF/YY5VH9V1h+mkf8h0LA0OS C97GEDgFNOC4XU59DIMRt065EruOtMPZpeOYA+1I4yuunCo13LfljE1guiZ0 8CWPMn4gdyUZWsMLjcRzF4nLNKnioD3wsCRp4Xo5hoHsc2ZBlrEV04G3PWoF c6xHD2I699g4ZiCN251NuTKSm+vgFeIydWpI9nSzoEwD3WmYQbY82swMfr2S BlE/c3GPa4yzTK/J3qYphwPPmYnwoizS/nqJYtjB4PPVLDI2QZwomeYhM1qo B2sqrCprFZ1glhdImThYxGqe04Ey5xx0mQwm2L3r/P43HByRh2HN4sMjzJji 6/Bw9HB/b/BwMLjjnL4CFL3/7uz919c0RAvrC2qkuwV9+itPqypyd6y+c7v0 /cuJXTAatO4IgJC7bgnQIxYTnVpwam4PO7RxKfOUQjoJxTp2E+8g06jsL7t8 lPWae5SVTWqBrBVeOrHHtPa2IQUTanol3FrWXU6SWUU6n8izaCOvferrdWnp b1lZRQyv1RcSlOPWY4gBWt+K9Ad78CFbIzz7vlQ/FRF4Qd4e6u8dABk+Zb+j sNoJ+0kZDnfswdjWAybf6mvEl200hsOBw+T/gceTQOnh6GgxW92JEXGtxMko inGAXm1toNuJBm/LspjpKxbbahX452Xq8q3Rqs7J+bddWyzsD49QLDQwaEB5 bHo2xza8P1n8HK09hmBYZ1s6WXrt8lvPTNnByS5bweTp6+fCHHe58yjjKmux 0xQNJneJ6m2CssrYVe2XN+8MIrRRdQqKOtkUHT3Jx3RVTpsvM2WOlbIitoc6 gVNvCl08OqPjGL7Jw8/DYE03Fbhf6e6RgZ26bPBxRrWja1shYiVwdHR46A5l fzEXNx/L18CmfQixs8Mhj9vl3WuD+IPdZd8WEDv9mA39gey8fXPuPzv78uxC 3uf/urubOvDix029vd+hdNANnTiJP5YnqLYpA0XewOz6HkRv3zb9oYepmMmh jsuM87ek4lN4uEtzOEYz6ECVp8RqEcw28sifogwhD4OgxSk71XIVJHPlqCzg NLWMQzpO3Rj9NeeirsE8bvbDmch2m/p+R94Hat5jj/+vgHdF9Z3/juEsLpHN esewGPv9gfypSKE5vi3awCHzoPw7lsP7OREk+LP+wPsdici7x5//xJ+/588/ 8Odn/HnfE7L5h8HP+ZHPn33+/At//pU/f+TPj/z5y47lRh8eyMnLty8mokkA 0Pr9h9GI2PJTyLfHShL5LmqXHwv7rKIFrHtAj4bmvz3/4Cl/O3jmPzwVdQiG 9D8TD3nRtycvJu8kq9bEmKHRK91qXd+laJWMjZJWktoC6SybHJXeOu6hZeU5 jvfAaxzsECzsL+lishDVvGPK6PjeP+jjiY3joO3HojWwPcWfR5nO5f3h6LD9 hENvG4KdD0AsUCfgrWm8eGsaKUmlh21lqf6sgv6hpnlO5+7Y6dgoJzxGac4o B+fUGTAYh+WdxLu3pb/HNrJQjj+H48j5WOcTu37e2tUUsXGAPddxof/hTcub YKGLWLqYz6MPgrTiaRrFKltTcDdaRmpC1/Y5stAPCglCGG4b9Ydh7A38vUeN /QYoef9DPhKVyzYTh+2JQzvRyLGEuD/0DyZsdIdD/+EEEyc88U8YC/jbzwIW V5os2elAGPOrRrD0tLHbGn4h50uXk/OTszPZQVF+/rZrAhwnzs0jD5/45rJo DtpVL3FHxKN0+vu/ZAoMnKkf6t/HzDzYKNz7WL5FCNDcq6WH8s93eAPKqq6p KFyovCnhdTGNI710vqAR2G0HYVZkKIcIS43MJbOn0Df34Iqov2bvA9da4Xzk UGuM2O4RV1phqjQXoOqDWq3z8lIHRe1aLmmwoeuzii4QzZZqdumK4ihZF7nu i0msU9OvD6Z0ZXZjLtsk1GhGgWLeOKD3GwgAvTEFIk39YhqEdHfGaXO9Tzqj 9wMSd7ZcAqMbT6hF6N2BqyKmayO8a2RellhCrWOyKlvNaNWAactaB8zehCrb Gh5dd1tR+qmJ+Gm6mmqvJ90YEC9RpnaBpYaawtVCvnDzIaf3BUBwHGQLd+U6 VytzJYXO1LblGKG6ghA75gJoyvp1ulu/qOWQzqAQWXnH0iONm+DPFEXcbSEI VWqZb2fB5AM4yVHmKRRC9WE8jCBfKf0JOXzuTuu4/Ua5KzdAdNn+NdJ8yYOe uLlBkHEHiF9U7xDd3sIcMxVzS/vYu2cKegMKdmaTbgOrvFx6c1MHIDuNJmPz nHHUbO9YBWj3U2r2UR5W5tPYvvLHWTMSs4+SY27r76OhEf9zJcVZ20f5HfC1 X9/R4SaJRH4EiF19vI9cqhOoMrXFd5feEAgrRskgWqstFgzht4EgD9ggj2oL ffwZAo6MP3OOkOX9zvDc2j24V73W89IJqbqdvPOotyGCHjVI+XalVReAPP3u TGh4kVVwVvYdOhiUZ88IsWKVdLkxwe6iel1nCmvlcm5WvmFg+g839+ia2i2R aRRdhcdekrqXI8ybhVpe87lnHF0q4wEoy78B5r/+d7aIUjmBuha39qiLXaQ5 9GTDdMd31nXATZAVOHvim8/a2RJgnukgmMl39EpG4EBSI0tdm5OfuVLhlN+d weSv4wAB/0WQ5ZeKJutisTD2Rq55WmShSspOGr+k6k4n3BGBKEsMP0/98tqh 5JcPq1LWNHF4z0kMl79BpREn0WV6dUuCwvBX0UqeI0kJQh6x1Fws0xUE/TzV GnpBKNrCme5Bxut5EYuyFwSd+GOaUXjwv8xSFGCc0tC9C973VZDNUnkRxemM GRPoS/c2AJwknL87AivKlzv4usWOqNwX/wcH7dvh4TsAAA== --></rfc>