One document matched: draft-rahman-core-advanced-rd-features-00.txt

CORE WG                                                        A. Rahman
Internet-Draft                                                   C. Wang
Intended status: Informational          InterDigital Communications, LLC
Expires: January 6, 2016                                    July 5, 2015


                  Advanced Resource Directory Features
               draft-rahman-core-advanced-rd-features-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 6, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Rahman & Wang            Expires January 6, 2016                [Page 1]

Internet-Draft    Advanced Resource Directory Features         July 2015


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology and Conventions . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Terminology and Conventions

   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 RFC 2119 [RFC2119].

   This document assumes readers are familiar with the terms and
   concepts that are used in [RFC6690], [RFC7252] and
   [I-D.ietf-core-resource-directory].

2.  Background

   The concept of the Resource Directory (RD) is described in
   [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
   [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.

   The relevant specification of interfaces in
   [I-D.ietf-core-resource-directory] is given using the CoAP protocol
   [RFC7252].  For example, all the response codes(i.e. success and
   error) for registering and looking up resources are CoAP based.  Also
   a multicast discovery interface is defined [RFC7390].  However, in
   theory, the RD interfaces can also be implemented using HTTP
   [RFC7252].

   The Core Link Format [RFC6690] describes the format of the payload of
   a CoAP Response that carries a set of CoAP URIs.  With relation to



Rahman & Wang            Expires January 6, 2016                [Page 2]

Internet-Draft    Advanced Resource Directory Features         July 2015


   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).

3.  Proposal

   It is proposed that the RD should also support the following
   additional features:

   1.  Explicit HTTP interfaces - As explained previously the current
   CoRE specifications are written explicitly with CoAP examples.  The
   specifications should be expanded to also explicitly support HTTP
   (e.g.  HTTP request and response codes).  There may be some RD
   interfaces, such as multicast and Group Function, that may not be
   supported by HTTP and those should also be explicitly identified and
   excluded.

   2.  Mirror Server - The CoRE WG has previously discussed the concept
   of a mirror server in relation to supporting sleepy devices.
   Specifically, [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.

   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.

   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.

   5.  Indication of transport protocol - Several proposals exist(e.g.
   [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.







Rahman & Wang            Expires January 6, 2016                [Page 3]

Internet-Draft    Advanced Resource Directory Features         July 2015


4.  Summary

   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).

5.  Acknowledgements

   TBD.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   Not applicable.

8.  References

8.1.  Normative References

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
              Resource Directory", draft-ietf-core-resource-directory-03
              (work in progress), June 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [I-D.silverajan-core-coap-alternative-transports]
              Silverajan, B. and T. Savolainen, "CoAP Communication with
              Alternative Transports", draft-silverajan-core-coap-
              alternative-transports-08 (work in progress), June 2015.

   [I-D.vial-core-mirror-server]
              Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
              server-01 (work in progress), April 2013.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, August 2012.





Rahman & Wang            Expires January 6, 2016                [Page 4]

Internet-Draft    Advanced Resource Directory Features         July 2015


   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
              2014.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

   [RFC7390]  Rahman, A. and E. Dijk, "Group Communication for the
              Constrained Application Protocol (CoAP)", RFC 7390,
              October 2014.

Authors' Addresses

   Akbar Rahman
   InterDigital Communications, LLC

   Email: akbar.rahman@interdigital.com


   Chonggang Wang
   InterDigital Communications, LLC

   Email: chonggang.wang@interdigital.com




























Rahman & Wang            Expires January 6, 2016                [Page 5]