One document matched: draft-rahman-core-advanced-rd-features-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC6690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6690.xml">
<!ENTITY RFC7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC7390 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7390.xml">
<!ENTITY I-D.ietf-core-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-resource-directory.xml">
<!ENTITY I-D.vial-core-mirror-server SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vial-core-mirror-server.xml">
<!ENTITY I-D.silverajan-core-coap-alternative-transports SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.silverajan-core-coap-alternative-transports.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-rahman-core-advanced-rd-features-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ************************* Front Matter ************************ -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Advanced Resource Directory Features">Advanced Resource Directory Features</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Akbar Rahman" initials="A."
surname="Rahman">
<organization>InterDigital Communications, LLC</organization>
<address>
<email>akbar.rahman@interdigital.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Chonggang Wang" initials="C."
surname="Wang">
<organization>InterDigital Communications, LLC</organization>
<address>
<email>chonggang.wang@interdigital.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="18" month="March" year="2016" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>CORE WG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>The Resource Directory (RD) is a key element for successful deployments
of constrained networks. Similar to the HTTP web search engines
(e.g. Google, Bing), the RD for CoAP should also support useful search query
responses beyond a basic listing of relevant links. This document
proposes several new features to be considered for the RD.
The only goal of this document is to trigger discussion in the
CoRE WG so that all relevant features for RD evolution
are taken into account during CoRE re-charter activities.</t>
</abstract>
</front>
<!-- ************************** Main Body ************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<middle>
<section title="Terminology and Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
<t>This document assumes readers are familiar with the terms
and concepts that are used in <xref target="RFC6690"/>, <xref target="RFC7252"/>
and <xref target="I-D.ietf-core-resource-directory"/>.</t>
</section>
<section anchor="Background" title="Background">
<t>The concept of the Resource Directory (RD) is described in <xref target="I-D.ietf-core-resource-directory"/>. It is
defined as a node which hosts descriptions of resources held on other servers, allowing
lookups to be performed for those resources. The <xref target="I-D.ietf-core-resource-directory"/>
specifies the web interfaces that a Resource Directory supports in order for devices to discover
the RD and to register, maintain, lookup and remove resources descriptions.</t>
<t>The relevant specification of interfaces in <xref target="I-D.ietf-core-resource-directory"/>
is given using the CoAP protocol <xref target="RFC7252"/> for all interfaces. Also, HTTP protocol <xref target="RFC7230"/> support
is given for some interfaces. For example, all the response codes(i.e. success
and error) for registering and looking up resources support both CoAP and HTTP. However, the important multicast
discovery interface does not support HTTP. The Group interface also does not support HTTP.
</t>
<t>The CoRE Link Format <xref target="RFC6690"/> describes the format of the payload of a CoAP
message that carries a set of CoAP URIs. With relation to the RD, the CoRE Link Format
is be used by a device to carry (encode) the set of URIs it wants to register with an RD. Also,
the CoRE Link Format is used to carry (encode) the set of URIs returned by a RD for a
lookup query (including the initial multicast discovery request). While in theory the
CoRE Link Format <xref target="RFC6690"/> specification states that it may be used with HTTP,
in practice many details still need to be fleshed out and specified before this can be realized.
</t>
</section>
<section anchor="Proposal" title="Proposal">
<t>It is proposed that the RD should also support the following additional features:</t>
<t>1. Explicit HTTP Support - Though there is some support of HTTP in
<xref target="I-D.ietf-core-resource-directory"/>, the specification should
be further expanded to also explicitly support HTTP for the Discovery and perhaps the Group Functions.
Also, the RD function is intimately tied to the CoRE Link Format <xref target="RFC6690"/> which does
not have any explicit support of HTTP at all. So the CoRE Link Format definitely needs to be updated
to support HTTP explicitly. </t>
<t>2. Mirror Server - The CoRE WG has previously discussed the concept of a mirror server in relation to
supporting sleepy devices. Specifically, <xref target="I-D.vial-core-mirror-server"/> recommends to create a new class of RDs
which store the actual resource representations (as opposed to simply storing the URI) in a special type
of RD called the Mirror Server. Communicating devices can both lookup the resource, and then also fetch directly the
resource representation, from the Mirror Server regardless of the state of the sleepy server.</t>
<t>3. Re-direction to another RD - A given RD may not have the URIs being queried for registered in its
database. The given RD should have the capability to re-direct the querying client to another RD which may have the
information of interest.</t>
<t>4. URI Ranking - Current Internet search engines (e.g. Google) have extensive methods for ranking the URIs
returned to a human initiated search query. For example, the concept of Search Engine Optimization (SEO) has spawned a large
industry in the web world for specifically this purpose. The concept of URI ranking (to indicate the "value" of the URI) should
also be supported by the RD.</t>
<t>5. Indication of transport protocol - Several proposals exist(e.g. <xref target="I-D.silverajan-core-coap-alternative-transports"/>)
in the CoRE WG to support alternative transports (e.g. TCP, SMS) for CoAP beyond the current UDP transport. It
would be very useful if search results from a RD indicated the type of transport supported by a given URI.</t>
<t>6. Privacy Model - IoT devices may often contain sensitive information (e.g. health monitoring device) or affect human
safety (e.g. traffic light controllers, elevator actuators). When the resources of a device is registered with a given RD and domain, should anyone
at all be able to easily discover the resources associated with the device? Does this cause privacy or security concerns in certain RD lookup scenarios?
Currently, <xref target="I-D.ietf-core-resource-directory"/> has a very brief mention that endpoint and clients should be
authenticated and access controlled. However, a more complete privacy model should be developed to address this very important issue.</t>
</section>
<section anchor="Summary" title="Summary">
<t>The proposed set of feature extensions for the RD will improve the constrained environment search capability and make
deployments more efficient. These RD feature extensions should be individually considered during the CoRE re-charter discussions. Evolution
and forward thinking is required for the CoRE RD, as constantly occurs in the current Internet for HTTP web search engines (e.g. Google).</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Not applicable. </t>
</section>
</middle>
<!-- ************************** Back Matter ************************ -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&I-D.ietf-core-resource-directory;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC6690;
&RFC7230;
&RFC7252;
&RFC7390;
&I-D.vial-core-mirror-server;
&I-D.silverajan-core-coap-alternative-transports;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:55 |