<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.1.2 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no"?>

<rfc ipr="trust200902" docName="draft-ietf-core-rd-dns-sd-05" category="std">

  <front>
    <title>CoRE Resource Directory: DNS-SD mapping</title>

    <author initials="P." surname="van der Stok" fullname="Peter van der Stok">
      <organization>Consultant</organization>
      <address>
        <phone>+31 492474673 (Netherlands), +33 966015248 (France)</phone>
        <email>consultancy@vanderstok.org</email>
        <uri>www.vanderstok.org</uri>
      </address>
    </author>
    <author initials="M." surname="Koster" fullname="Michael Koster">
      <organization>SmartThings</organization>
      <address>
        <postal>
          <street>665 Clyde Avenue</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>USA</country>
        </postal>
        <phone>+1 707-502-5136</phone>
        <email>Michael.Koster@smartthings.com</email>
      </address>
    </author>
    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization>Energy Harvesting Solutions</organization>
      <address>
        <postal>
          <street>Hollandstr. 12/4</street>
          <code>1020</code>
          <country>Austria</country>
        </postal>
        <phone>+43 664-9790639</phone>
        <email>c.amsuess@energyharvesting.at</email>
      </address>
    </author>

    <date year="2019" month="July" day="07"/>

    <area>Internet</area>
    <workgroup>CoRE</workgroup>
    <keyword>CoRE, Web Linking, Resource Discovery, Resource Directory</keyword>

    <abstract>


<t>Resource and service discovery are complementary.  Resource discovery
provides fine-grained detail about the content of a web server, while
service discovery can provide a scalable method to locate servers in
large networks.  This document defines a method for mapping between
CoRE Link Format attributes and DNS-Based Service Discovery records
to facilitate the use of either method to locate RESTful service
interfaces (APIs) in heterogeneous HTTP/CoAP environments.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction-and-background" title="Introduction and Background">

<t>The Constrained RESTful Environments (CoRE) working group aims at
realizing the <xref target="REST"/> architecture in a suitable form for the most
constrained devices (e.g. 8-bit microcontrollers with limited RAM and
ROM) and networks (e.g. 6LoWPAN <xref target="RFC4944"/>).  CoRE is aimed at machine-to-machine
(M2M) applications such as smart energy and building
automation.  The main deliverable of CoRE is the Constrained
Application Protocol (CoAP) specification <xref target="RFC7252"/>.</t>

<t>CoRE Link Format <xref target="RFC6690"/> is intended to support fine-grained
discovery of hosted resources, their attributes, and possibly other
related resources.  Automated dynamic discovery of resources
hosted by a constrained server is critical in M2M applications, where
human intervention is minimal and static configurations result in
brittleness.</t>

<t>DNS-Based Service Discovery (DNS-SD) <xref target="RFC6763"/> supports wide-area search for
instances of a given service type (i.e. servers that support
a particular application protocol stack).  A service instance consists of a
server’s name, IP address, and port number plus additional meta-data
about the server.  This data may
extend to support multi-function devices, where multiple
services are available at the same endpoint. The result of the discovery process may
   include a path to a resource representing the entry point to each
   function’s RESTful service interface and possibly a link to a formal
   description of that interface (e.g. a JSON Hyper-Schema document
   <xref target="I-D.handrews-json-schema-hyperschema"></xref>).</t>

<t>Resource and service discovery are complementary in the case of large
networks, where the latter can facilitate scaling.  This document
defines a mapping between CoRE Link Format attributes and DNS-Based
Service Discovery records that permits discovery of
CoAP services by either method.  It also addresses the CoRE charter
goal to interoperate with DNS-SD.</t>

<t>The primary use case for mapping between resource and service discovery is to
support heterogeneous HTTP/CoAP environments where, for example,
HTTP clients may discover and communicate with CoAP servers that are behind a “cross proxy” <xref target="RFC8075"/>.</t>

<section anchor="terminology" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL”
in this
document are to be interpreted as described in <xref target="RFC2119"/>. The
term “byte” is used in its now conventional sense as a synonym for “octet”.</t>

<t>This specification requires readers to be familiar with all the terms and
concepts that are discussed in <xref target="RFC6690"/> and <xref target="RFC8288"/>. Readers should
also be familiar with the terms and concepts discussed in <xref target="RFC7252"/>.</t>

<t>This specification also incorporates the terminology of <xref target=" I-D.ietf-core-resource-directory"/>.</t>

<t>In particular, the following terms are used frequently:</t>

<t>Endpoint: a web server associated with a specific IP address and
port; thus a physical device may host one or more endpoints.  Endpoints may also act as clients.</t>

<t>Link: Web Linking <xref target="RFC8288"/> defines a Web Link (link) as a typed connection between
two resources, comprised of:</t>

<t><list style="symbols">
  <t>a link context,</t>
  <t>a link relation type (see Section 2.1 of <xref target="RFC8288"/>,</t>
  <t>a link target, and</t>
  <t>optionally, target attributes (see Section 2.2 of <xref target="RFC8288"/>).</t>
</list></t>

<t>A link can be viewed as a statement of the form “link context has a
link relation type resource at link target, which (optionally) has
target attributes”, where link target and context are typically
Universal Resource Identifiers (URIs) <xref target="RFC3986"/>.  For example,
“https://www.example.com/” has a “canonical” resource at
“https://example.com”, which has a “type” of “text/html”.</t>

</section>
<section anchor="core-resource-discovery" title="CoRE Resource Discovery">

<t>The main function of Resource Discovery is to return links to the
resources hosted by a server, complemented by attributes about those
resources and additional link relations.  In CoRE this collection of
links and attributes is itself a resource (in contrast to HTTP, where
headers delivered with a specific resource describe its attributes).</t>

<t>Resource Discovery can be performed either unicast or multicast.
   When a server’s IP address is already known, either a priori or
   resolved via the Domain Name System (DNS) <xref target="RFC1034"/><xref target="RFC1035"/>, unicast
   discovery is performed in order to locate the entry point to the
   resource of interest.  This is performed using a GET to “/.well-
   known/core” on the server, which returns a payload in the CoRE Link
   Format <xref target="RFC6690"/>.  A client would then match the appropriate Resource
   Type, Interface Description, and possible media type <xref target="RFC2045"/> for
   its application.  These attributes may also be included in the query
   string in order to filter the number of links returned in a response.</t>

<t>Multicast Resource Discovery is useful when a client needs to locate
   a resource within a limited scope, and that scope supports IP
   multicast.  A GET request to the appropriate multicast address is
   made for “/.well-known/core”.  In order to limit the number and size
   of responses, a query string is recommended with the known
   attributes.  Typically, a resource would be discovered based on its
   Resource Type and/or Interface Description, along with possible
   application-specific attributes.</t>

</section>
<section anchor="core-resource-directories" title="CoRE Resource Directories">

<t>In many M2M scenarios, direct discovery of resources is not practical
due to sleeping nodes, limited bandwidth, or networks where multicast
traffic is inefficient.  These problems can be solved by deploying a
network element called a Resource Directory (RD), which hosts
descriptions of resources that originate on other endpoints and allows
indirect lookups to be performed for those resources.</t>

<t>The Resource Directory implements a set of REST interfaces for endpoints
to register and maintain collections of links, called Resource
Directory registrations.  <xref target=" I-D.ietf-core-resource-directory"/> specifies the
web interfaces that an RD supports for endpoints to
discover the RD and to register, maintain, lookup and remove resource
descriptions; for the RD to validate entries; and for clients to
lookup resources from the RD.</t>

</section>
<section anchor="dns-based-service-discovery" title="DNS-Based Service Discovery">

<t>DNS-Based Service Discovery (DNS-SD) defines a conventional method of
naming and configuring DNS PTR, SRV, and TXT resource records to
facilitate discovery of services (such as CoAP servers in a subdomain)
using the existing DNS infrastructure.  This section gives a brief
overview of DNS-SD; for a detailed specification see <xref target="RFC6763"/>.</t>

<t>DNS-SD Service Names are limited to 255 bytes and are of the form:</t>

<figure><artwork><![CDATA[
      Service Name = <Instance>.<ServiceType>.<Domain>
]]></artwork></figure>

<t>The Service Name identifies a SRV/TXT Resource Record (RR) pair.
The SRV RR specifies the hostname and port of an endpoint.  The TXT
RR provides additional information in the form of key/value pairs.
DNS-Based Service Discovery is accomplished by sending a DNS request
for PTR records with the name &lt;ServiceType&gt;.&lt;Domain&gt;, which will
return a list of zero or more Service Names.</t>

<t>The &lt;Domain&gt; part of the Service Name is identical to the global (DNS
subdomain) part of the authority in URIs <xref target="RFC3986"/> that identify the resources
on an individual server or group of servers.</t>

<t>The &lt;ServiceType&gt; part is generally composed of two labels.  The
   first label of the pair is the application protocol name <xref target="RFC6335"/>
   preceded by an underscore character.  For example, an organization
   such as the Open Connectivity Foundation <xref target="OCF"/> that specifies
   Resource Types <xref target="RFC6335"/> might register application protocol names
   beginning with “oic”, which all servers that advertise OCF resources
   would use as part of their ServiceType.  The second label indicates the transport protocol binding and is typically “_udp” for CoAP
   services.</t>

<t>The default &lt;Instance&gt; part of the Service Name SHOULD be set to a
default value at the factory and MAY be modified during the commissioning
process.  It MUST uniquely identify an instance of &lt;ServiceType&gt;
within a &lt;Domain&gt;.  Taken together, these three elements comprise a
unique name for an SRV/TXT record pair within the DNS subdomain.</t>

<t>The granularity of a Service Name MAY be that of a host or group, or
it might represent a particular resource within a CoAP server.  The
SRV record contains the host name (AAAA record name) and port of
the endpoint, while protocol is part of the Service Name.  In the case
where a Service Name identifies a particular resource, the path part
of the URI must be carried in a corresponding TXT record.</t>

<t>A DNS TXT record is in practice limited to a few hundred bytes in
length, which is indicated in the resource record header in the DNS
response message (See section 6 of <xref target="RFC6763"/>).  The data consist of one or more strings
comprising a key/value pair.  By convention, the first pair is
txtver=&lt;number&gt; (to support different versions of a service
description).  Each string is formatted as a single length byte
followed by 0-255 bytes of text.  An example string is:</t>

<figure><artwork><![CDATA[
              ----------------------------------------
              | 0x08 | t | x | t | v | e | r | = | 1 |
              ----------------------------------------
]]></artwork></figure>

</section>
</section>
<section anchor="attributes" title="New Link-Format Attributes">

<t>When using the CoRE Link Format to describe resources being
discovered by or posted to a resource directory service, additional
information about those resources is often useful. This specification
defines the following new attributes for use in the CoRE Link Format
<xref target="RFC6690"/> to enable the data-driven mappings described in Section 3:</t>

<figure><artwork type="ABNF"><![CDATA[
   link-extension    = ( "exp" )
   link-extension    = ( "ins" "=" (ptoken | quoted-string) )
                       ; The token or string is max 63 bytes
   link-extension    = ( "st" "=" (ptoken | quoted-string) )
                       ; The token or string is max 15 bytes
]]></artwork></figure>

<section anchor="export-attribute-exp" title="Export attribute “exp”">

<t>The Export “exp” attribute is used as a flag to indicate that a link description
MAY be exported from a resource directory to external directories.</t>

<t>The CoRE Link Format is used for many purposes between CoAP endpoints. Some
are useful mainly locally; for example checking the observability of a resource
before accessing it, determining the size of a resource, or traversing dynamic
resource structures. However, other links are very useful to be exported
to other directories, for example the entry point resource to a functional
service.  This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 6 of <xref target=" I-D.ietf-core-resource-directory"/>.</t>

</section>
<section anchor="resource-instance-attribute-ins" title="Resource Instance attribute “ins=”">

<t>The Resource Instance “ins=” attribute is an
identifier for this resource, which makes it possible
to distinguish it from other similar resources in a Resource Directory.
This attribute specifies the value to be used for the &lt;Instance&gt; portion of an exported DNS-SD Service Name (see Section 1.4), and SHOULD be unique across resources with the same Resource Type “rt=” attribute
in the domain in which it is used.</t>

<t>A Resource Instance SHOULD be a descriptive human readable string like
“Ceiling Light, Room 3”.  This attribute MUST NOT be more than 63 bytes in length. The resource identifier
attribute MUST NOT appear more than once in a link description.  This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7 of <xref target=" I-D.ietf-core-resource-directory"/>.</t>

</section>
<section anchor="service-type-attribute-st" title="Service Type attribute “st=”">

<t>The Service Type instance “st=” attribute specifies the value to be
used for the &lt;ServiceType&gt; portion of an exported DNS-SD Service Name (see Section 1.4).
This attribute MUST NOT be more than 15 bytes in length (see <xref target="RFC6335"/>, Section 5.1)
and MUST be present in the IANA Service Name registry <xref target="st"/>.</t>

</section>
</section>
<section anchor="dns-sd" title="Mapping CoRE Link Attributes to DNS-SD Record Fields">

<section anchor="mapping-resource-instance-attribute-ins-to-ltinstancegt" title="Mapping Resource Instance attribute “ins=” to &lt;Instance&gt;">

<t>The Resource Instance “ins=” attribute maps directly to the &lt;Instance&gt; part of
a DNS-SD Service Name.  It is stored directly in the DNS as a single
DNS label of canonical precomposed UTF-8 <xref target="RFC3629"/> “Net-Unicode”
(Unicode Normalization Form C) <xref target="RFC5198"/> text.  However, if the “ins=”
attribute is chosen to match the DNS host name of a service, it SHOULD
use the syntax defined in Section 3.5 of <xref target="RFC1034"/> and Section 2.1
of <xref target="RFC1123"/>.</t>

<t>The &lt;Instance&gt; part of the name of a service being offered on the
network SHOULD be configurable by the user setting up the service, so
that he or she may give it an informative name.  However, the device
or service SHOULD NOT require the user to configure a name before it
can be used.  A sensible choice of default name can allow the device
or service to be accessed in many cases without any manual
configuration at all (see Appendix D of <xref target="RFC6763"/>).</t>

<t>DNS labels are limited to 63 bytes in length and the entire
Service Name may not exceed 255 bytes.</t>

</section>
<section anchor="mapping-service-type-attribute-st-to-ltservicetypegt" title="Mapping Service Type attribute “st=” to &lt;ServiceType&gt;">

<t>The Service Type “st=” attribute maps directly to the &lt;ServiceType&gt;
   part of a DNS-SD Service Name.</t>

<t>In practice, the ServiceType should unambiguously identify
   interoperable devices.  It is up to individual SDOs to specify how to
   represent their registered Resource Type “rt=” values as registered
   application protocol names according to <xref target="RFC6335"/>.  The application
   name is then used as the value of the resource “st=” attribute.</t>

<t>The resulting application protocol name MUST be composed of at least
   a single Net-Unicode text string, without underscore ‘_’ or period
   ‘.’ and limited to 15 bytes in length (see Section 5.1 of <xref target="RFC6335"/>).
   This string is mapped to the DNS-SD &lt;ServiceType&gt; by prepending an
   underscore and appending a period followed by the “_udp” label.  For
   example, rt=”oic.d.light” might correspond to the registered
   application protocol name st=”oic-d-light” and would be mapped into
   Service Type “_oic-d-light._udp”.</t>

<t>The resulting string is used to form labels for DNS-SD records which
   are stored directly in the DNS.</t>

</section>
<section anchor="ltdomaingt-mapping" title="&lt;Domain&gt; Mapping">

<t>TBD: A method must be specified to determine which DNS zone the CoAP
service description should be exported to.  See, for example, Section 11 in
<xref target="RFC6763"/> and Section 2 in <xref target="I-D.sctl-service-registration"/>.</t>

</section>
<section anchor="txt-record-keyvalue-strings" title="TXT Record key=value strings">

<t>DNS-SD key/value pairs may be derived from CoRE Link Format
information and exported as key=value strings in a
DNS-SD TXT record (See Section 6.3 of <xref target="RFC6763"/>).</t>

<t>The resource &lt;URI&gt; is exported as key/value pair “path=&lt;URI&gt;”.</t>

<t>The Interface Description “if=” attribute is exported as key/value
pair “if=&lt;Interface Description&gt;”.</t>

<t>The DNS TXT record can be further populated by importing any other
resource description attributes as they share the same key=value
format specified in Section 6 of <xref target="RFC6763"/>.</t>

</section>
<section anchor="exporting-resource-links-into-dns-sd" title="Exporting resource links into DNS-SD">

<t>Assuming the ability to query a Resource Directory or multicast a GET
(?exp) over the local link, CoAP resource discovery may be used to
populate the DNS-SD database in an automated fashion.  CoAP resource
descriptions (links) can be exported to DNS-SD for exposure to
service discovery by using the Resource Instance attribute as the
basis for a unique Service Name, composed with the Service Type attribute as
the &lt;ServiceType&gt;, and registered in the appropriate &lt;Domain&gt;.  The agent
responsible for exporting records to the DNS zone file SHOULD be
authenticated to the DNS server.  The following example, using the
example lookup location /rd-lookup, shows an agent discovering a
resource to be exported:</t>

<figure><artwork><![CDATA[
 Req: GET /rd-lookup/res?exp

 Res: 2.05 Content
 <coap://[FDFD::1234]:5683/light/1>;
   exp;st=oic-d-light;rt="oic.d.light";ins="Spot";
             d="sector";ep="node1"
]]></artwork></figure>

<t>The agent subsequently registers the following DNS-SD RRs, assuming a
derived DNS zone name “office.example.com”:</t>

<figure><artwork><![CDATA[
_oic-d-light._udp.office.example.com      IN PTR 
         Spot._oic-d-light._udp.office.example.com 
Spot._oic-d-light._udp.office.example.com IN TXT
         txtver=1;path=/light/1;rt=oic.d.light;d=sector 
Spot._oic-d-light._udp.office.example.com IN SRV 
         0 0 5683 node1.office.example.com.  
node1.office.example.com.                 IN AAAA FDFD::1234
]]></artwork></figure>

</section>
</section>
<section anchor="exporting-resource-directory-service-to-dns" title="Exporting Resource Directory Service to DNS">

<t>In some cases it is required that one (or more) Resource Directories (RD) in a given DNS domain can be discoverable from DNS. The /.well-known/core resource of the RD should reflect this by specifying the “ins”, “exp”, and the “st” attributes in the the link of the RD service. This document specifies in <xref target="iana"/> 
two servicetypes: _rd-lookup-res._udp and _rd-lookup-ep._udp for resource types rt = core.rd-lookup-res and rt = core.rd-lookup-ep respectively. The default  coap and coaps ports are respectively: 5683 and 5684.</t>

<t>The value of the instance MAY be specified by the manager of the resource directories. In case of an unmanaged RD (for example in a home network) it is recommended that the ins parameter takes a value provided by an Authorization Server during the acceptance of the RD to the network (see for example section 7 of <xref target="I-D.ietf-core-resource-directory"/>).</t>

<t>With the assumption that the “ins” value is attributed by Authorization Server, and [FDFD::1234] is IP address of RD, Example links for RD are:</t>

<figure><artwork><![CDATA[
     Req: GET coap://[FDFD::1234]/.well-known/core?exp

     Res: 2.05 Content
     <rd-lookup/res>;
       exp;st=rd-lookup-res;rt="core.rd-lookup-res";
       ins="505567",
     <rd-lookup/ep>;
       exp;st=rd-lookup-ep;rt="core.rd-lookup-ep";
       ins="505572"
]]></artwork></figure>

<t>The link atributes can be exported to RR by the mapping process described in <xref target="dns-sd"/>.</t>

</section>
<section anchor="iana" title="IANA considerations">

<t>Two registries are affected by this document: (1) “RD Parameters” registry under “Core Parameters” registry, and (2) Service Name and Transport Protocol Port Number Registry</t>

<section anchor="rd-parameters-registry" title="RD Parameters Registry">

<t>This specification defines new parameters for the registry “RD
   Parameters” provided under “CoRE Parameters” (TBD).</t>

<figure><artwork><![CDATA[
   +----------------+-------+---------------+-----+--------------------+
   | Full name      | Short | Validity      | Use | Description        |
   +----------------+-------+---------------+-----+--------------------+
   | ServiceType    | st    |               | RLA | Name of the        |
   |                |       |               |     |Service Type,       |
   |                |       |               |     | max 63 bytes       |
   | Resource       | ins   |               | RLA | Instance identifier|
   | Instance       |       |               |     | of the resource    |
   |                |       |               |     |                    |
   | Export         | exp   |               | RLA | flag to indicate   |
   |                |       |               |     | exportation        |
   +----------------+-------+---------------+-----+--------------------+
]]></artwork></figure>

</section>
<section anchor="service-name-and-transport-protocol-port-number-registry" title="Service Name and Transport Protocol Port Number Registry">

<t>This specification defines new parameters for the Service Name and Transport Protocol Port Number Registry:</t>

<figure><artwork><![CDATA[
* _rd-lookup-res._udp at ports 5683 and 5684
* _rd-lookup-ep._udp at ports 5683 and 5684
]]></artwork></figure>

</section>
</section>
<section anchor="security-considerations" title="Security considerations">

<t>Malicious nodes can export fake link attributes to DNS. It is recommended that the RD can be authenticated, and is authorized to both join the network and  export its link attributes. 
Authentication is specified in <xref target="I-D.ietf-ace-oauth-authz"/>.</t>

</section>
<section anchor="contributors" title="Contributors">

<t>Keryy lynn was the initiator of, and major contributor to this document.
This document was split out from <xref target=" I-D.ietf-core-resource-directory"/>.
Zach Shelby was a co-author of the original version of this draft.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The authors wish to thank Stuart Cheshire, Ted Lemon, and David Thaler
for their thorough reviews and clarifying suggestions.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC1034" target='https://www.rfc-editor.org/info/rfc1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author>
<date year='1987' month='November' />
<abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>



<reference  anchor="RFC1035" target='https://www.rfc-editor.org/info/rfc1035'>
<front>
<title>Domain names - implementation and specification</title>
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author>
<date year='1987' month='November' />
<abstract><t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System.  It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1035'/>
<seriesInfo name='DOI' value='10.17487/RFC1035'/>
</reference>



<reference  anchor="RFC1123" target='https://www.rfc-editor.org/info/rfc1123'>
<front>
<title>Requirements for Internet Hosts - Application and Support</title>
<author initials='R.' surname='Braden' fullname='R. Braden' role='editor'><organization /></author>
<date year='1989' month='October' />
<abstract><t>This RFC is an official specification for the Internet community.  It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='3'/>
<seriesInfo name='RFC' value='1123'/>
<seriesInfo name='DOI' value='10.17487/RFC1123'/>
</reference>



<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 initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'><organization /></author>
<date year='1996' month='November' />
<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="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="RFC3629" target='https://www.rfc-editor.org/info/rfc3629'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization /></author>
<date year='2003' month='November' />
<abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract>
</front>
<seriesInfo name='STD' value='63'/>
<seriesInfo name='RFC' value='3629'/>
<seriesInfo name='DOI' value='10.17487/RFC3629'/>
</reference>



<reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>



<reference  anchor="RFC4944" target='https://www.rfc-editor.org/info/rfc4944'>
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'><organization /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'><organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4944'/>
<seriesInfo name='DOI' value='10.17487/RFC4944'/>
</reference>



<reference  anchor="RFC5198" target='https://www.rfc-editor.org/info/rfc5198'>
<front>
<title>Unicode Format for Network Interchange</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<author initials='M.' surname='Padlipsky' fullname='M. Padlipsky'><organization /></author>
<date year='2008' month='March' />
<abstract><t>The Internet today is in need of a standardized form for the transmission of internationalized &quot;text&quot; information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET.  This document specifies that format, using UTF-8 with normalization and specific line-ending sequences.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5198'/>
<seriesInfo name='DOI' value='10.17487/RFC5198'/>
</reference>



<reference  anchor="RFC6335" target='https://www.rfc-editor.org/info/rfc6335'>
<front>
<title>Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author>
<author initials='L.' surname='Eggert' fullname='L. Eggert'><organization /></author>
<author initials='J.' surname='Touch' fullname='J. Touch'><organization /></author>
<author initials='M.' surname='Westerlund' fullname='M. Westerlund'><organization /></author>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization /></author>
<date year='2011' month='August' />
<abstract><t>This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry.  It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.</t><t>This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP).  It also updates the DNS SRV specification to clarify what a service name is and how it is registered.  This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='165'/>
<seriesInfo name='RFC' value='6335'/>
<seriesInfo name='DOI' value='10.17487/RFC6335'/>
</reference>



<reference  anchor="RFC6763" target='https://www.rfc-editor.org/info/rfc6763'>
<front>
<title>DNS-Based Service Discovery</title>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization /></author>
<author initials='M.' surname='Krochmal' fullname='M. Krochmal'><organization /></author>
<date year='2013' month='February' />
<abstract><t>This document specifies how DNS resource records are named and structured to facilitate service discovery.  Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t></abstract>
</front>
<seriesInfo name='RFC' value='6763'/>
<seriesInfo name='DOI' value='10.17487/RFC6763'/>
</reference>



<reference  anchor="RFC6690" target='https://www.rfc-editor.org/info/rfc6690'>
<front>
<title>Constrained RESTful Environments (CoRE) Link Format</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<date year='2012' month='August' />
<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.  &quot;RESTful&quot; 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="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<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>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference  anchor="RFC8075" target='https://www.rfc-editor.org/info/rfc8075'>
<front>
<title>Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)</title>
<author initials='A.' surname='Castellani' fullname='A. Castellani'><organization /></author>
<author initials='S.' surname='Loreto' fullname='S. Loreto'><organization /></author>
<author initials='A.' surname='Rahman' fullname='A. Rahman'><organization /></author>
<author initials='T.' surname='Fossati' fullname='T. Fossati'><organization /></author>
<author initials='E.' surname='Dijk' fullname='E. Dijk'><organization /></author>
<date year='2017' month='February' />
<abstract><t>This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP).  This will enable an HTTP client to access resources on a CoAP server through the proxy.  This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response.  This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.</t></abstract>
</front>
<seriesInfo name='RFC' value='8075'/>
<seriesInfo name='DOI' value='10.17487/RFC8075'/>
</reference>



<reference  anchor="RFC8288" target='https://www.rfc-editor.org/info/rfc8288'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This specification defines a model for the relationships between resources on the Web (&quot;links&quot;) and the type of those relationships (&quot;link relation types&quot;).</t><t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t></abstract>
</front>
<seriesInfo name='RFC' value='8288'/>
<seriesInfo name='DOI' value='10.17487/RFC8288'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.ietf-core-resource-directory">
<front>
<title>CoRE Resource Directory</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='M' surname='Koster' fullname='Michael Koster'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='P' surname='Stok' fullname='Peter van der Stok'>
    <organization />
</author>

<author initials='C' surname='Amsuess' fullname='Christian Amsuess'>
    <organization />
</author>

<date month='July' day='2' year='2019' />

<abstract><t>In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-resource-directory-22' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-22.txt' />
</reference>



<reference anchor="I-D.sctl-service-registration">
<front>
<title>Service Registration Protocol for DNS-Based Service Discovery</title>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<author initials='T' surname='Lemon' fullname='Ted Lemon'>
    <organization />
</author>

<date month='July' day='15' year='2018' />

<abstract><t>The DNS-SD Service Registration Protocol uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets.  This eliminates the dependency on Multicast DNS as the foundation layer, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-sctl-service-registration-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-sctl-service-registration-02.txt' />
</reference>



<reference anchor="I-D.handrews-json-schema-hyperschema">
<front>
<title>JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON</title>

<author initials='H' surname='Andrews' fullname='Henry Andrews'>
    <organization />
</author>

<author initials='A' surname='Wright' fullname='Austin Wright'>
    <organization />
</author>

<date month='January' day='19' year='2018' />

<abstract><t>JSON Schema is a JSON-based format for describing JSON data using various vocabularies.  This document specifies a vocabulary for annotating JSON documents with hyperlinks.  These hyperlinks include attributes describing how to manipulate and interact with remote resources through hypermedia environments such as HTTP, as well as determining whether the link is usable based on the instance value. The hyperlink serialization format described in this document is also usable independent of JSON Schema.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-handrews-json-schema-hyperschema-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-handrews-json-schema-hyperschema-01.txt' />
</reference>



<reference anchor="I-D.ietf-ace-oauth-authz">
<front>
<title>Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)</title>

<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
    <organization />
</author>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='E' surname='Wahlstroem' fullname='Erik Wahlstroem'>
    <organization />
</author>

<author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<date month='March' day='27' year='2019' />

<abstract><t>This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth.  The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices.  Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-ace-oauth-authz-24' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-24.txt' />
</reference>


<reference anchor="OCF" target="https://openconnectivity.org/developer/specifications">
  <front>
    <title>OCF Specification 2.0</title>
    <author initials="O.C." surname="Foundation" fullname="Open Connectivity Foundation">
      <organization></organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="rt" target="https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#rt-link-target-att-value">
  <front>
    <title>Resource Type (rt=) Link Target Attribute Values</title>
    <author initials="." surname="IANA" fullname="IANA">
      <organization></organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="st" target="https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml">
  <front>
    <title>Service Name and Transport Protocol Port Number Registry</title>
    <author initials="." surname="IANA" fullname="IANA">
      <organization></organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">
  <front>
    <title>Architectural Styles and the Design of Network-based Software Architectures</title>
    <author initials="R." surname="Fielding" fullname="Roy Fielding">
      <organization>Ph.D. Dissertation, University of California, Irvine</organization>
    </author>
    <date year="2000"/>
  </front>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAI3gIV0AA71c63LbyJX+ryq9QxddFUsZkrpLlhzPRmPZO9pYsleSZzab
2poCiSaJCAQYXCTRY+fJ9t++2H7n0o0GSSmemc0q8YgCGqdPn/sN7PV662tV
UqX2xHy7vmbM6/zqjbmyZV4XQ2vOksIOq7yYn5izy+ve9ZmZRrNZko3X1+J8
mEVTPBYX0ajqJbYa9YZ5YXtF3IuzslfGve0DLIsqrNnd3jnubR/h/+trZRVl
8U9Rmme4URW1XV9LZgV/LKvd7e3j7d31tWFUnZiyitfXZskJ4VVWRTLEtedz
Wz6nC1U+bP8V21k1waU9vlDOp4UdlcGSMi+qhUvDfDqLWlBxZWqzCotwhZ+q
B82qLOdFQDfLq2SU2NhdjAobnZjzrLJFZqv1tfvxCZNyfe32Xj51zY92YN4l
2S3I1w1JXA7zO1vMuyvIDsB1NckLkKBnkgxofeibuygzsS3MdZXfEjrChg8W
ey/dywtGJCvrFGSv6NJswpTvfLO3Y/aPd/eP9g+P9szGpa0mtkjBm3Kza77Z
2zPHh4fbOwe7+y/MxtsiyoZ2s0PP22mUpCeglAIdzv+IXbFpiT372JAW1UVy
Yu7v7/uLt/QYF33zp7wExs0BLpLhJLJpcJ2Rv55GRXUzAdFKlQNrwYvDwwPz
Op3H1pze2YyECMxLKgjqRV5nVZRk5ofE3tPlwo6TPAMZToXDMTZ7fry/vb+n
LMd6kvCP16ct+uyYI4jswfZu72Bn7zA8u6LaF1T/WBKKFaPYh7D4Q77um9Np
+T//XZbNKV9PiqSsErApuIWDRlnyKaoYzzeZLcZz831U3FkszcbmOk9rutei
wPd5ytyqir7Z2d3aDw63s7273T7baU0KFLXOt78HKu73jo+Otw/3jlu87UfT
srZl+UfLuEw8Kv0IMpTlxRS43lnWzKu3r3e29/aDzwf+887unvu8u73vr+/u
7Bzj8zP+42B399Dd2DvcPfafj1/46/vH+36Dg53jF+7z4R5v9ow/Hxxt++tH
h37jw8Njf/1o92DXfX6xfeQRerH74oVH6Gjv+FD+OO+d9RvDlkJ3y95fS/CI
HoPZykYBJfzD2/6Pw6Ojg+bO7p7g0YZaqNL3Ym9r3aJyWKW90hZ3yZDWjSE4
hciIWzGBABT2XrDqlcMJGNibzGfQOP7c3i8CmJwMSo/+8wk36fb71295GYyo
+IEOrpjrmR3Cwg15P7Pb3+7omqgYk/R1JlU1K0+2tvKZzWALMuCe3EEBSc23
YntnU9wptsoQTqlAvFGjP0xPfxunI533gElWywM1byHIMcNQEN6vvGAVrxaO
4E3pDYhhNorq1SbbXnPD+JvTCuowqCtrfohSSPpjpyMTBmWN+FRRWSbjjP3D
FvNuFhVAGCZg6e/+w6Saps+KiqWmJ3B7UVX17mi/lXRYJsT56eXpwnF3xQQs
HPdahMRc4jEDmTA3MNjlDB7PfChyOMc8NR/or8t6OoB7uBJhmv/iYztpJPzK
Hm3QyxjkU7f6D9P015+YGXz15vpm4cynxXCSVJCQuohSOLx5aks+O/yYObOE
s8lHBn7tPi9ue4OotDEs6ai6h7M2wdOrue+oMCz79TDp27je+js8fhrDCm7N
6kG5FSclzlyxVG65Wz+FV/uzePSVB7/KIeQKo7nHHrDzYdI/61Og4AF3zccM
VqcoSTdwyNdRmsAWZUnUNedgQ2YX1GR7m5S91+uZaEBWZFjR315LiGzKPxO7
gMQQnSj4SS0xPyrmfdPEKH4ZQrQiv0tiUH+EjXvjAs4XpI4tvHCK/fK6Yp7A
SlSAQ/hG5h7BEO1oi665nyQpHPgyAkO4SQWOR8phlEaD1Bqo2CQHn3OT5jAs
VgGV8Lrraykx0WTC9RIYI3YoDaLVmg4BrAhJCIqDArK5oNYM8JS1AMJRMNuL
t2zhTeTshYgYBcPfiUAp0j6MQ7gBWxDDVQO/UTRM0qQiHIkCdWnp9DahUGv5
GCTkozp1nCAHA1sCGNh14/TDebmJE5oJGZh8DM+c16X5/ubmw9br/PSDsdld
UuSip33H7WkSx0RbckKITos8rods0ekU30XD23FBlpUW3ABBihQr5Z/D5k0A
12wQZTYN0ZYIRk/PTJRMQRZIFILgNPlEN+i0P/9MIL58gRw1ukYnACtrEIVY
SQ6UWUAPTBFOIfQPcIAfSfj0tj/umxe9QVLhSMMiJ1kqEAAR1+9BTpMmU2wB
rE8v6GyQ7fcXm3xKJwoK5PBd/uOH00vCTuKKL182+5r3QFBwFkABx6cRkIY4
V3lPP66vbVzsEtDZLHUODScZTkyE3xQDGgmXeNtBnagyQ/XzqdgDkkack6LT
2KakwUwF0mDdv2pzYX3ttNmtseUbxPFN03KuciKKcL58Yf4vCTEvoHAIPElI
W6COsWUJLOsZe4tQg5G8eaEGhhMKdmPj4pWyS7gmRaAaXT74LIe/GKR4hqSc
hCKNWg+CCqdCEuLwHPYvGZrWVn7p+pruOgBRTSgZovJ0jGGRVCBBSpIF/rTY
Q7bFFuDcpJ7ClrA+IV1gcuHRaZIlUzzJ5o8s65D2GCXjulD2AhMkOWxYBtgH
ngfGQ9TrKRuwIdnyppIc0ShIrjQmgY1tjzJGnIJ0gxSAlJ0yY5J2NpBjSEfm
jXLFYQzcUN8bu2oClipMCJlB8IED1LB/IQnIforMAPrwlkT91EN1WzJlERDI
1mKJbfG8ZN8Ej/LBRDHizNJzGJIivt3MUhgh3E1oM5ASRi3qwesASmP5BZ63
xbgLHYDjsA8kgaH8TUHtpDeqM7FSqv/KRrk7C3xFyT4quoOjYUWKdD8KgwB5
loPjfdY5ZSTORwsaaQN5AKYUfOAwk2yY1uxuZhHMClCLvDjiwwyfSX7UxFnK
rgxvQ0stDAVDcQcACReMuvE2va0skaFAUfbjrCJlQPCqkO8ZE4Nxj6oAgli0
yPzb9ftL8z2F/b1rjvu9v2Mgf/maVOG/Nlmqf3lQQHrH7j0S78YOGEmiml3H
O1oCQ0BFCnLrgWckv06p5YKrhvlpfHXbQZuv9s/ra486aCEmzg/HUbbsD5lO
OFQvYzA+LZcNTM+xZVrmTi+sM9xAa4hsmQsY4xz6AIYyvygZosOysxLr0Hde
d1bACmFnCg+YiitikkYIV7OFXEcOvVA9+pogQRjT5d3sQ0Qs7a6v0VozTBNe
Aa3we/DGVB+rs2Toj+Ip5U0SCcjAwmHCjZoOfDW0C1r2MO+INaS8Wz3Us2fm
huif5WkOt/nzs6r564ujzq2dU7wBhnUuPl7fdLry21y+589Xb/794/nVmzP6
fP396bt3/oOsWF/DX+8/vtMF9Kl59PX7i4s3l2fyNK6ahUsXp3/uiM3rvP9w
c/7+8vRdhyw1TpqUXAOVqJLODE4PVL1hJchpISwQ/R3gj0QdNNU+cHwySggR
cV7TGcwr2yEO1qUsJIHM8nsyy+qtIjIgGUQjInUo51mezSVw6uTDylYdFSYA
aQcFhf1bnUB28CGKmUeM5ghON03gKpiJUZqy/BI6pYRP2HpoZ1XAU5KDuiyD
o2goQeQRzu6+eEFHu9Ktyklep4DFmrK0aWtD4/db3kZDGiPmacUZGT4Md15A
9qNKlTGQJTJLP//8DwsvKpXnWeBLOcoBodM0v2erLxgXVpg1IvqCRemcqylv
1OectDIcMK3MhwnHO0Jvf4DAtwrdSXtfYk/yqmY2mZcc2ogfZHWkgMjkGUwt
bATO4f0cxVVuf9FcsVDDioRGNZoPSIbzJCxHh+wLMiS3wmyQb9oU2aNIhNnF
xRlQ3ydNsPdhdEhOokiISPlIS03m987PcS74UHXbVzlUJJgS7pTWIrYaagVq
R7joEV14VpL3rlCRb+Qz0Zx03tW7oZtYgL67AF284aliG9ExzV1i70WtIw4X
2QO6kIIzmU54ODOhlchIl4/WGPOqjT1SYcSDGw3qmwQFtF3Ev+P8avC4UyTe
nE3SfEbikyK00XoBZMn79/OYbMsoIVXd+HhF6SUTgAqvpG/kWwPH0CoO6WUq
d2915KCw9RHMEm3YCQ8YPBk81XFn1WeJLB2iZYew36LqWcf5iMWelC88iIPg
dMqHjACxvFTcI7BCCpoxyfjvimywF1kT5hquNtGEOnonCDQ0vs3LFhRiQhAQ
t7hPOnqu4Qu5EIBHDusQF1FRCM0+lKpVpU1HYSi6gTNzEhyVHHqS226yHTXA
mmOuMDsejnNQ7HOaTUX8VxBSVQHRDAk8IGtkxEEBWaZConT6o8+K+OPEZp6g
CIgDi0f5dkqOaW5u4e+yroMWUUyUF4nJuRHE6KZ32O0uiaS+lzPXud55PQfb
ppxzqQRTP+LLF/cR0UbX4SdBdSgWzUkAD2EGdm8qMitifJYZRYlpA4Fjp29x
YA1hW2DrkixsZP71zQ0939nq39s0lQIgn5prx5D9LMiVnHaIxLIviOZpHsUu
2vYRMMNZTvA5zxOjj+gJbpieyqAr1VBcL8JLBKVFwoUnPQvDoop5V1qZnGSc
NSlIK8GnOlyciEPQ0GZ7H7SWbJZSKZKoJhOV4geFMI1oey/FkRNnXv6E8KuF
5GTUugIJQ/6MkpQyCVqniShlHqw9QjKBwwozg97ZvnqgCyecj1gJeHXK1u5F
aJWAmbVx2YgFAwp0kZSLN3NFKMAjGkoxmrJ0+rvJ/88/MIRGT4hXJB4cTJRO
zFos8osD5REoUHUJBFWwApkSa9MINaEX0oxTieSTHEjqLkwsyvOF/p72JadN
1ByPnTkhQLyZ0MNztc8yJI6n26ITy+GgSVvIpHIFJeeYl+G0OzfAcAtne0wa
0xy4MTJOKAWXRup63uQFCEokucKzSCCYUOGJ48BplM25qFQObRbBJIEyEi4+
UrAiQmU50koqsRMJkCTUnBuUqbWc0GV5TAR2sjLAEe+TuJp0yXb6YmVQ8BC7
BUs/omNw4c7SRxJNr1SQFJweoakaaLWX8FixnaX5nG2Qz8qNFZ9miEkU0qyY
PTAbV2eb3kvDNVLC01C/bJ+b5RykGycZiSv5M7bkPjoVr0ZhdEkZlFIxzfPb
euayksZoSkkYnjUoGzp/vwLVxDlpDs0sB2VUeDFBBZ3TXIcNV+elpap6QP6E
xwYal1x6o9J1hGosZbN52Jkl4f+qTMO5YklW1tcoWwiQlawrM1dnjdloHYCz
fZ+akypiaSTFNHeurj9UVwnNKwo7xUOesG2uvvTVeMADrLsoTaiJxG4Q2L5k
ELTG1QgIEYXeiMOoyKcKxUVxT9RLv7qc2uQmrdRYOykUQVE1mURdImEu5dLf
AGA+3Fx1zfXVD2KYb/7jJizsaUkIZwkqUy0d9+WgDVfzb9U+tK8xiDky2Vxf
E7/PEcRDInMchEWSjShmK2puh7iIodQgkKq+dLwBaI3T0OaUddD+QgPhT6Td
NfI1rVSYkpqg5uwL1ddnnqwUM0kG60wQ2Lx7cGCoDKFqWtgwrXHZm/60ms2v
zB/OtYr8bf8PeotMN/6SIO1bp7et5xKXfNBpwZQt4ofX7CvmByzQ1SYCn6To
K4SrH8zVVVt12DRlru/NxS8qYmdB/ZcLwICPgPbK+GZlEKP7QQ7yQ1mTzgHQ
rZ1vccue8SAj9JSgUkA75JQhKSdifkvgIQEgcV89PKQMXIRAesnzHpWP8ru0
ehnQ8nfj6mWfrglF6U9nmO+TNKXsgxMbikBKPv8nW+S+QtDivDejbXhc8nBM
b3OqVGYNpZxJC8ZpPsBfpJdUc3RC3wIiHW9qUIOklF6G2aVWskUI5rw+aPpw
f9KQkwCr6ih1dRQcSDqOqo62aB9ngWSCDvCnOmhB4Qinc7nUJAzVK9JoYFPp
EkvoMAKTK7nsDkKMd625lZ0VZplo3R5lGwxoBs7aWJPGDPkHZWTkDrhAjOiA
GyJhik3LwkkwiX3V1tDmT43FYP/3r986wnoNWQ6pyhBTM03GkypwhI8dTwAN
sC7LEhdzdfJk6PN4qiG268AxPlcJXDjNEwXcBSCJBGupZwZCA0IHPFTNhW3M
odrCExKKYVPj82MuHttBovqGR4hpLhI1nZ/qeNZh80mGW6irNl0jQpEkOJmI
ekUkUc62Pa0iWlamsMty9B5x84KhiPHQxhR8C4cMhNzF6Z/piWke8ySpicVT
yaTEdJogns0zbiBrj0raDlz7RjYLO4JDeQ1ifdFuHlBcoQ2IMVye0lZ9InN0
C9Gq8jEPgXLNs6Tst4A7sS6ycgU9Op0gIJLPDinzRlwsmmiN7sgZO6yftxRe
a8dgIJVZdY4latNVSSSxJd2V4qdagS5XB3giQIRYm3Om1QtdztICt+0UnxyL
4k1FFWDY+BY55MYpftwaurIZ+huEk5OmEqsTLY1MJuWjsiMpmuufgUcc90dP
OMsVZ+uqnaI8KKJusG4Eq4sUAkcYEPiiSFxWjFNIrseq0nBNi57Eq4CVnHK4
lKYVNkRmhOBkUlNrMdYAgodwbDamjEZMAz8vauuz+4XQy0jJyjTCwiU1zkYR
3pVlNAYPrq31kdKhL9hKqLOp1oK7y9rPpiVhqVyS2ZK6GyzK4pfbLh5gvpsH
4aU2ANgtqCcAtx8qSM8r0iNJpdk+bASNbCj1CJyENPKYliYTUTPbEwTdhPqb
CIRqkm2JRypfbcZlCJSQlelMEQQlU+JgtntNAEe8tw9cVMicb2kgL8Ry7qf3
lT+rnv1sth+2X+BXhX8P+vsO/yz+Ffj3Cv92zOffti9NMF1C2Kjm1dN612lT
Sfr5WZPfc+uQy45NDL7UMQavfO2zyVsGVl5uCAoUcxKfmZSG2+MAPp1zXO0G
QWUwHkzhTFMrbhcL8lHFeFLVqW+Wm1tNF7zdh8pAiqCQRjaY3OlidVBPu74W
NuxoUiHjeYlKFaYXFzxuok3nhb6l65LssfD8HT/m9LvLt8xPHm/lOQ4ScmLp
K7NhOvYBrnbzqRUwsR3TedUxG7MqJ+/z2fytzkHknsjqpj6+6ucla7o8hoM3
ajONHszhnijCU5uX1T9n750DtzdRSRPfNw9sETy3hDrOA+pdoVizxnWDWf1H
aTSWSQKxohpgSW8hMCTra+oxLQPl/iTy8JUiS0LwQK+rUHuxKXx5z7ykMA4j
GU7I5mZWFxRLl8FUBk8Y+HbkdT61/GqMq6qS60fQQlVURGQvw8kDRMV2eOu0
NR+QRkUDSsQ1MGjKFQM7ImOORAt+gYkPjxtb6fc6CFTWbD/I9TUEjGyPsUon
z5rWjfFZOXD/HqaV6/BSxtLGDLblPE/PI1UrR2yuKcnygKCt+YqlhoLfW5yp
NrHIeqhJcQWCRjKUxY10SKHWz547G3B1Zt5JWeat641dWzcA29Lrw1/WH4dI
Nz1EF3MG0g3NftVZKtb5lXK/LeoRRNcHOYWWoLjm7HgnkcQUcSp1w4JyL9lx
Ka/UyLnpHsu88KFEqBIGSlqmWa4g9nWwoMGqXWSQ+ED47bWg0rSznSRAFrQP
SUUIp4grijDtFvROf39TKlNNNqFRdiRDNM0hfLGAB93aFfNOUYXU1WkVaL50
zPB/Dcq8RmvQt8ypBpGosTJ3iIp5mJL6duxE1ASmyS1267y2CU1zwXQgKO+a
qxzM2OusEGOd4ZEciAfEANQZb8JToh0/vifINVICy7IMDP7LRkUAkMZKjDZn
2sby/0Ozjn6xZjkBke5Ho1Rl1ehUa43P+njJ1wgwlSYXJHipcPIbhHhZlVaz
2vnKhtUCKyhPdD3gg/4OXDKnzQSMegWa7ClP6MWRNmJalp8DYFk5ApsLHatr
3FsQRII8ekQtQPIbGRRcyhutX5RJDsg/NoMEctFE/ALTiHisVGeSzl3x7bG6
BA0Br+CQlA0oroSkUZ3BgQsS8yDJ4AJnUwDzMx1c0HLVs483b3svtJ53uHuM
mLJzaaveR6zMY3r3ZEM/mkueZdWKFocS5rV26elFPopGJVnxDjeR3NW5kZaf
GFIATYWKoJFN6DZ5ephkdcnIiRFjmReTOUd+/7BKWff6Bz6nlAkCMcfNBBIn
1nJ/Z9eV12+eYElT0Q3xkiwDl0acYUjjv+nNNWbXD6OTmR3M3TskBZWZuKEA
E+RmBvi8ZU6ViIjmPzk4ncjMGHUViBZcJPLvLDJiIeXZTVhJT+lpxbYZmnTT
hA0i4IRDkrwEH1Xjs4Te5ZBmJHsZGTzPZHQAjEykUuXqZPworece4WO4iAeW
0E+4x6Eo1U7ELVKaRVdwuaYwqjXPT2U4qlOynTmFq0A8/WDOlioJ2jXR6vBi
r2TZR/nXzsg30QBOyxARB6gnbB+GFhB8pt5fsCZPmX5nR5Zqeis8wqIjeNSI
LAGjsrUK7mpTosWD86Ya1A0rWry9TH0idommA1A+r8ugTqkz9m4gmkRBZ/y9
mSKZzsPi//XZezbN4tBoAvKeG3XGBDU/KR67QnbQqQ2jInaCJVm7ZuHiwMBC
3Zv7OQWXyYBC4Ju03BQ8yZAybZlUUn6QSKJxwGoSfDizwCtH4OaNBS5RPdp0
cM4wbGvQSKF1o06+dBSYZ7a4GrV1vdIEDYrnPz3nmoctklzo87z/nGU80ILH
3HfgsRu9Yopt9vVs7IuatHk2E4hqzEnoVsUkA3pZw85cO03IHWDNjcuZv6/o
m7BMxn5F2gCs2tKAYUC+CUOCAtvUj/spRbAdrS43FVOH6teKkCkFYi/uKUTC
1M/C6PmhEyLSbVX+KXiwz5ivFpGGnixzNCFFrlYNGIV6Slnfb6QkQBDnwuhj
oUEzK7PQL7xwXwQCC/Td2QmMu3bhXcHZxZ+xlNokPbeafZB1/USlWalWUTvG
v9MQvPKitiSsaFR5n4i08N5CE4HucAE6fO+q5cRlqvzJt+uDlxO4J82R4K2d
vxIV9kVk31lf6BGzwacpJ0tFNa3BLFfkWuVBoOhPCIOxtBunMH7DoDbPNXGf
yPf3VvqyVgZFfPx4dc5MhLwsbBscxHSoo/AqWN/x0FYOZCFmGy1m9ivBr68J
fCyXyGkFsPZ+Cx0JjStGdcFp/iyf1fKS4YBngSh7YRsRvITYmnedaTTQzPKy
kZ5D4CINbzi19nzghv006KyuKqC0xy585Y9Q8ftLIYm0XTWSk++yrKeucuWq
Xlgh+efK4axwzlaGSxF0/wuovWn8RBDX2XjHrtTmgjKgm1hQWVWrQe8fCClD
a0wVYprTYyHMTORf3hxF5UQy6Rb4hTkxfnug3HRMCzTZbSCaDA9W83s0q14F
H8yDYv5TeVekA1VAWPoooI7WUcJQptv4TF9NeSQA4/n71SFTVweqfNShhjOc
3FxuttKCMb/hpi2uRF+FVtqIwLiJJJ/ksL0cUWPRZwjy/UAynFG1vGirwRn0
DbzB9NSk1zClOKlTXDzkSmK9VcDz8LUuWeL7krk/5tfolTE6VhiWMQMWN82m
K/u3Ex5xbWBu4SES2GBNeULfNHJAMw6Ve3nRmD8M84i+juEvb8/enp2cIPPa
/6+Tg8MXe1vsFrd2vn3pq/WA9xL+NvCaLxcd+ktOLK9nOT6uqPLHrzol61jn
pZ296tC05o6vvMjhy3pQutd+PPMXGzSukHBFw7ROv3kuQLyC5yjHCJ2cJjpt
+F5Fx1NvKQjoL68W5M8veaho4Vh01v5XAZEHv3499uO5qtZ22hzdecnuwzGJ
+BCw4WX8Ssj8a/akdv3Cptv4H8kEj9furHiub/SRJxYs/GAn7vo3cic1pMas
rzDM102myl1sniMu86nVJFXqrppI63w4icGGNqk3V84j8zCu1DHlxXASHy3p
ql11Kinfq0AxB4VvrP5Lk+Gttxe0pKmxVmFHNP4q9XeaX5Osy5le7tt1pV3V
9XkvN9TCV1bEDLITopgn2MW1Ndpfy9EUKzk+o++eQeQm75TpI/SeAQzET96A
UB2VpYTRCK7bmVwmi9pYJp59QnL7imJ522+BETO+4p7lodYZD1zZdC7kdCUL
Q4ZJR00px5Yx3UjI6585EbmkZfiw70OaVkLoq7hag27CDE1bpqDIWF5zaCWQ
YeuO8nL3FjaPnMlDMdF9I+xCsRxNSCa15rTpxbKZ8WfJVNyCGnjFLZhI0ddp
Sjfldiozf1rtu5apvWCwiQo3Mz+kVPkpYy6TafmLs8gQ27JdTP/HtXQJes2P
zq+z+ZWQzx9K+s9yiLBYzSdZdQwR9tAH0XPBy0w0cn7WhXFQZ8qBHp2DBrML
63rniw5xhXNbUtevc5Mtz7rsE1sCz15xWQ8Cj8he8mD74ODwqNNd3sLOntrB
zlZtYGer4B/tdpgwxikGW4zI25IVYePVVaMWUjtzX+Ow8L61lu2/hLZdvwyH
+gU8JhRb92UfPz9ju8N43Lsxera+/C0ToxEEzGlkYLxOzMbOpumAzR/89391
mvYDlyhM5zWZ3VULRLA2djfb7Ytf8C1erikbItC6ueKdaTdVQnMkzdeW+aaQ
xx7HYpaFmHul90dDbhsu2Lj57kyU0An8N4sDPd8s/G5fX1rOFxnSZ/O2TrWy
wj+fzfWEiPKZvsotiSl10usfS5pAChNU/fn8f45TWADlC8jK+Hf757O5eneK
/15qS4BI3cJp8QF/YRkS/zdMWbq/CVJrdmYBko9I3BPkEh4/nc/Kmmatg+Rv
fR1Oi97u159uxY+DpBM4zRMwNU+cbmkY51fjJCYt+qdJZjOC9Fssyy83Hr92
N5/w/H51lFdphNWKp1Y84eK/xx4QD3BthzXPHbe9AN28gCEZJvTNKfyyHrsg
YZYZIfxxHmqhb9zXBsbKIArGWR1ZK2Pvujl1fVvikzi4QY7Q5a+5htEuMqKl
Dg96uXYBDfqGjNMGuH7HVatgFURPC18G6hvkFFQwwLxgWvzJFvO5SedZZu61
lZFkSZVElLvlo66+PPdXeiOseVSCusBJuqkAH/ETsHKWIu6k7gPnK187KPGf
NCt7PbEpPPF9JG+D9YSAzmLom4ipm76V67Q/fVu1K2qb0yEFWamNxzzi7tN8
hkUNxXIiJ4lA6euqpubY64ktJwl9cc4NiPrOTt170WcRvCIShCiliqMqQ8Lv
MRZ5PaaXueldLv2+Exp6l7SqrMdj+nZdenvQfW/fIBrerv0vk4F0351bAAA=

-->

</rfc>

