draft-jinchoe-resource-model-indication.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->

<!DOCTYPE rfc SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/rfc2629.dtd" [
<!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 RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC6690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6690.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC7049 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY RFC7159 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- 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="yes" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="info" docName="draft-jinchoe-resource-model-indication-latest" ipr="trust200902" submissionType="independent">
  <!-- 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="Resource Model Indication with CoAP">Resource Model Indication with CoAP</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="JinHyeock Choi" initials="JH." surname="Choi">
      <organization abbrev="Samsung">Samsung Electronics Co., Ltd.</organization>
      <address>
        <postal>
          <street>129 Samsung-ro</street>
          <city>Suwon</city>
          <region>Gyeonggi</region>
          <code>443-742</code>
          <country>Korea</country>
        </postal>
        <email>jinchoe@samsung.com</email>
        </address>
    </author>

    <author fullname="Gabor Bajko" initials="G." surname="Bajko">
      <organization abbrev="MediaTek">MediaTek USA Inc.</organization>
      <address>
        <postal>
          <street>2860 Junction Ave</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>USA</country>
        </postal>
        <email>gabor.bajko@mediatek.com</email>
        </address>
    </author>

	<author fullname="D. Thakore" initials="D." surname="Thakore">
      <organization abbrev="CableLabs">Cable Television Laboratories, Inc.</organization>
      <address>
        <postal>
          <street>858 Coal Creek Circle</street>
          <city>Louisville</city>
          <region>CO</region>
          <code>80023</code>
          <country>USA</country>
        </postal>
        <email>d.thakore@cablelabs.com</email>
        </address>
    </author>
	
    <author fullname="Michael Koster" initials="M." surname="Koster">
      <organization abbrev="SmartThings">SmartThings, Inc.</organization>
      <address>
        <postal>
          <street>456 University Ave #200</street>
          <city>Palo Alto</city>
          <region>CA</region>
          <code>94301</code>
          <country>USA</country>
        </postal>
        <email>michael.koster@smartthings.com</email>
        </address>
    </author>
 

    <date month="Feburary" year="2016" />
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->
    <area>Applications and Real-Time</area>    
    <!-- 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. -->
    <workgroup>CoRE Working Group</workgroup>
    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->    
    <keyword>IoT</keyword>
    <keyword>Resource model</keyword>
    <keyword>CoAP</keyword>
    
    <abstract>
      <t>
        There has been much interest in "Internet of Things (IoT)" 
		and multiple standards  are under development that utilize the 
		RESTful architectural style.
		In REST, IoT devices need to understand 
		each other's resources, both the semantic meaning and syntactic form, 
		to interact properly.
		For interoperability among different standards, 
		it is of help for CoAP endpoints to indicate 
		the resource models they support. 
		This document presents a scheme for IoT devices 
		to exchange their resource model information 
		and requests IANA to register new Internet media types 
		&amp; CoAP Content-Format identifier for resource model indication.   
      </t>
    </abstract>
    
  </front>

  <!-- ***** MAIN MATTER ***** -->
  <middle>

    <section title="Introduction">
	  <section title="IoT trend">
	    <t>
          The term "Internet of Things (IoT)" denotes a trend
		  where a large number of devices, i.e sensors and actuators,   
		  are embedded in physical world and networked by Internet protocols 
		  to provide services such as smart home or connected health.  
		  Users can access the networked devices 
		  to acquire the real world information (e.g. monitoring heartbeat rate) 
		  and control the physical environments (e.g. adjusting room temperature). 
		</t>
      
		<t>
          IoT gains traction among academia, industry and government circles
		  for its business potential and social impact. 
		  Cisco promotes the "Internet of Everything (IoE)", 
		  the networked connection of people, process, data, and things
		  <xref target="IoE"></xref>, 
		  GE initiates "Industrial Internet", 
		  the integration of complex physical machinery with networked sensors and software, 
		  to organize Industrial Internet Consortium
		  <xref target="IIC"></xref>.                 
		</t>
            
		<t>
          IoT requires standardization for interoperability among diverse devices
		  and multiple standards are under development currently. 
		  IETF defines network and web transfer protocol 
		  (e.g. 6lowpan <xref target="RFC6775"></xref> 
		  and CoAP <xref target="RFC6690"></xref>, <xref target="RFC7252"></xref>), 
		  oneM2M <xref target="oneM2M"></xref> produces technical specifications 
		  for a common M2M Service Layer <xref target="oneM2M-TS0001"></xref>, <xref target="oneM2M-TS0004"></xref>, 
		  IPSO Alliance <xref target="IPSO"></xref> publishes 
		  Smart Object Guideline <xref target="IPSOSmartObjects"></xref>
		  and "Open Interconnect Consortium (OIC)" constructs 
		  standards <xref target="OICSPEC"></xref> and certification for IoT devices <xref target="OCF"></xref>. 
		</t>
      </section>      

	  <section title="REST and interoperability">
	    <t>
		  Multitude of IoT standards are based on
		  "Representational State Transfer (REST)", 
		  which is a software architecture style with a coordinated set of constraints 
		  for the design of components in a distributed hypermedia system
		  <xref target="REST"></xref>. 
		  In REST based IoT, 
		  a real world entity is represented as resource in a server,  
		  which a client accesses and manipulates 
		  the resource through representations 
		  to interact with the entity, 
		  i.e. sensing and controlling the physical environments. 
		  Moreover several IoT standards adopt 
		  the common network and web transfer protocols.
		  oneM2M, IPSO and OIC all use CoAP and IP/ UDP, 
		  <xref target="oneM2M-TS0008"></xref>, <xref target="IPSO"></xref>, <xref target="OCF"></xref>
		  so any client and server supporting those standards 
		  can exchange request and response messages. 
	    </t>
		
		<t>
		  However in order to interact properly, 
		  it's not sufficient for IoT devices to be able to transfer CoAP messages.  
		  IoT devices should understand each other's resources 
		  and be aware of their semantic meaning and syntactic form.  
		  Currently each standard defines its own "resource model" 
		  and specifies a different scheme 
		  to construct resources from physical entities such as light
		  <xref target="OICSPEC"></xref>, 
		  <xref target="IPSOFramework"></xref>, <xref target="IPSOSmartObjects"></xref>, 
		  <xref target="oneM2M-TS0001"></xref>. 
		  Hence client and server adopting different standards 
		  can't perform meaningful interaction, i.e.   
		  the client can't manipulate the resource representation in the server. 
	    </t>

	    <t>		
		  For wider interoperability among multiple standards, 
		  IoT devices need to understand each other's resource model
		  to process CoAP request and response message properly. 
		  To interpret resources correctly,  
		  client and server need to determine 
		  which resource model each other follows in the first place. 
		  The client should be aware of 
		  whether its corresponding server adopts oneM2M or OIC model and vice versa.  
		</t>

		<t>
		  CoAP provides a scheme to notify the Content-Format information    
		  which CoAP endpoints, i.e. client or server, support.   
		  A client can use the CoAP Accept Option to inform a server  
		  which Content-Format is acceptable and 
		  the server returns the preferred Content-Format if available. 
		  The Content-Format Option in a response message 
		  indicates the representation format of the payload
		  <xref target="RFC7252"></xref>. 
		</t>

		<t>
		  With a similar approach this document presents a way
		  for CoAP endpoints to exchange the resource model information 
		  among each other.
		  Also this document requests from IANA 
		  new Internet media types and numeric Content-Format identifier 
		  indicating resource model for OIC (e.g. application/vnd.oic+json).  	  
    	</t>
      </section>  	  
	  
	  <section title="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"></xref>.
        </t>
      </section>	  
      
    </section>

    <section title="Resource model indication">
	  <section title="Different resource models">
	    <t>
		  In REST based IoT, 
		  a physical or software artefact or concept 
		  that needs to be made visible and manipulated 
		  is represented as resource. 
		  The resource encapsulates and presents the salient aspect of an entity
		  with attributes or properties.  
		  For example, the notable feature of a smart light 
		  can be represented as "light control" resource 
		  with the attributes of "On/off", exposing the power state of the light 
		  and "Dimmer", the brightness.  
		</t>
		
		<t>
		  A scheme to construct resource from entity is denoted as 
		  "resource model", "data model" or "application profile". 
		  Take notice that there is no consensus on terminology, 
		  so the terms "resource", "resource type", "attribute" and "property" 
		  convey different meanings in different organizations.  
		</t>	

		<t>
		  Currently several standard bodies or Industrial alliance 
		  such as oneM2M, IPSO, OIC 
		  specifies resource model in a different way. 
		  For example, a smart light can be represented as 
		  an IPSO Smart Object in JSON as below:    
		</t>
		
		  <figure>          
		  <artwork>

          {
            "3311": {
              "description": "IPSO light control",
              "instances": {
                "0": {
                  "resources": {
                    "5850": {
                      "description": "On/Off",
                      "value": 0
                    },
                    "5851": {
                      "description": "Dimmer",
                      "value": 70
                    }
                  } 
                }
              }
            }
          } 
     
		  </artwork>
		  </figure>

		<t>
		  In the above, "3311" is an "Object ID" defining object type, 
		  "0" an "Object Instance", designating one or more instances, 
		  "5850", "5851", "Resource ID", defining resource type. 
		  Also IPSO embeds resource information in data path
		  so "On/Off" resource has predetermined data path of "3311/0/5850"
		  and "Dimmer" resource datapath of "3311/0/5851" 
		  <xref target="IPSOSmartObjects"></xref>.  
		</t>

		<t>
		  Whereas other SDOs (e.g. oneM2M or OIC) adopt opaque datapath and  
		  separate attribute to indicate resource type (object type in IPSO terminology)
		  <xref target="OICSPEC"></xref>, <xref target="oneM2M-TS0001"></xref>, <xref target="RFC6690"></xref>.  
		  Under this framework, a smart light in OIC may be represented in JSON as below: 
		</t>

		  <figure>          
		  <artwork>

			{
				"rt": "oic.r.switch.binary",
				"if": "oic.if.a oic.if.baseline",
				"n": "myRoomLightSwitch",
				"value": false
			}
			
			{
				"rt": "oic.r.light.brightness",
				"if": "oic.if.a oic.if.basline",
				"n": "myRoomLightBrightness",
				"brightness": 70
			}

		  </artwork>
		  </figure>

		<t>
		  Take notice that the same salient features of a smart light, 
		  power on/off and brightness, 
		  are turned into two different resources (or resource instances).  
		</t>
      </section>	  

	  <section title="A scheme to exchange resource model information">
	    <t>
		  IoT devices, i.e. client and server, need to understand 
		  the resource model which their corresponding device supports    
		  to be able to interoperate with each other.
		</t>
		
		<t>
		  For the initial step,  
		  it will help interoperability if IoT devices 
		  indicated the resource model they supported.
		  Then clients and servers may choose a common resource model for interaction,  
		  or in the absence of such a common model, 
		  rely on translation between the models, 
		  possibly with the assistance of a 3rd party. 
		</t>
		
		<t>
		  This document presents a scheme for CoAP endpoints, 
		  client and server,  
		  to exchange resource model they support. 
		</t>
		
		<t>
		  First, the Internet media type and Content-Format identifier 
		  are used to indicate a specific resource model.  
		  The Internet media types can be defined to indicate 
		  the resource models, potentially with content-coding, 
		  such as "application/ipso+json", 
		  then assigned numeric Content-Format identifiers 
		  such as "123123" to minimize payload overhead for CoAP usage.  
		</t>
						
		<t>
		  Second, CoAP Accept and Content-Format Option are used to 
		  exchange the Content-Format identifiers 
		  indicating the resource models which CoAP endpoints prefer or support. 
		  A client includes the CoAP Accept option to inform a server
		  which resource model, potentially with content-encoding, is acceptable
		  and the server returns the payload in the preferred resource model if available. 
		  The Content-Format Option indicates the resource model which the payload follows.  
		</t>
		
		<t>
		  Third, a known resource is used as an entry point 
		  for resource model exchange.  
		  Resource discovery in CoRE is accomplished 
		  through a well-known resource "/.well-known/core". 
		  OIC relies on a knwon resource URI "/oic/res" for initial discovery. Any client that wants 
		  to discover OIC resources uses this URI to discover other OIC resources.  
		  A client sends a CoAP GET request 
		  targeting the known resource URI with Accept Option 
		  and servers respond with Content-Format Option. 
 		</t>

      </section>	

	  <section title="Content-Format request for OIC resource model">
	    <t>
		  The Open Interconnect Consortium (OIC) is an industry group 
		  with the objective of specifying standards and certification 
		  for devices involved in the Internet of Things based around CoAP
		  <xref target="OICSPEC"></xref>. 
		</t>
		
		<t>
		  OIC is currently developing resource model for IoT services (e.g. smart home)
		  and strives to align with other standard bodies such as oneM2M or IPSO, 
		  so that OIC devices can interoperate with the devices following different standards.  
		  For this purpose, OIC prepares a scheme to exchange resource model information
		  as describes in the previous sections. 
		</t>
		
		<t>
		  The resource mode indication scheme requires 
		  new Internet media types and CoAP Content-Format identifiers 
		  which can indicate OIC resource models with content encoding. 
		  Hence OIC requests from IANA the new Internet media types as below. 
		</t>
		
		<t>
	      <list style="symbols">					
			<t>
			  application/vnd.oic
			  <vspace />
			</t>
			<t>
			  application/vnd.oic+json
			  <vspace />
			</t>
			<t>
			  applicatoin/vnd.oic+cbor  
			</t>
		  </list>		
		</t>

      </section>	
     
    </section>
 
    <section anchor="IANA" title="IANA Considerations">
	  <section title="New OIC resource model Internet media type">
		<t>
		  This specification registers a new Internet media type 
		  for OIC resource model, "application/vnd.oic". 
		</t>
		
		<t>
		  Type name: application
		</t>

		<t>
		  Subtype name: vnd.oic
		</t>
		
		<t>
		  Required parameters: None		
		</t>

		<t>
		  Optional parameters: None
		</t>
		
		<t>
		  Encoding considerations: None
		</t>
		
		<t>
		  Security considerations: As defined in this specification
		</t>
		
		<t>		
		  Interoperability considerations: None 
		</t>

		<t>
		  Published specification: This specification.
		</t>
		
		<t>
		  Applications that use this media type: OIC vertical applications (e.g. Smart Home) 
		</t>

		<t>
		  Additional information:
		<list>
			<t> 
			  Magic number(s): N/A 
			  <vspace />
			</t>
			<t> 
			  File extension(s): N/A
			  <vspace />
			</t>
			<t>
              Macintosh file type code(s):	  
			</t>
        </list>
		</t>
		
		<t>
		 Person &amp; email address to contact for further information:
         JinHyeock&nbsp;Choi &lt;jinchoe@samsung.com&gt;  
		</t>

		<t>
		  Intended usage: COMMON
		</t>
		
		<t>
			Author(s): JinHyeock Choi
		</t>
		
		<t>
		  Change controller: 
		</t>
	  </section>

	  <section title="New OIC resource model in JSON Internet media type">
		<t>
		  This specification registers a new Internet media type 
		  for OIC resource model, "application/vnd.oic+json". 
		</t>
		
		<t>
		  Type name: application
		</t>

		<t>
		  Subtype name: vnd.oic+json
		</t>
		
		<t>
		  Required parameters: None		
		</t>

		<t>
		  Optional parameters: None
		</t>
		
		<t>
		  Encoding considerations: JSON
		</t>
		
		<t>
		  Security considerations: As defined in this specification
		</t>
		
		<t>		
		  Interoperability considerations: None 
		</t>

		<t>
		  Published specification: This specification.
		</t>
		
		<t>
		  Applications that use this media type: OIC vertical applications (e.g. Smart Home) 
		</t>

		<t>
		  Additional information:
		<list>
			<t> 
			  Magic number(s): N/A 
			  <vspace />
			</t>
			<t> 
			  File extension(s): N/A
			  <vspace />
			</t>
			<t>
              Macintosh file type code(s):	  
			</t>
        </list>
		</t>
		
        <t>
		 Person &amp; email address to contact for further information:
         JinHyeock&nbsp;Choi &lt;jinchoe@samsung.com&gt;  
		</t>

		<t>
		  Intended usage: COMMON
		</t>
		
		<t>
			Authors: JinHyeock Choi
		</t>
		
		<t>
		  Change controller:
		</t>
	  </section>

	  <section title="New OIC resource model in CBOR Internet media type">
		<t>
		  This specification registers a new Internet media type 
		  for OIC resource model, "application/vnd.oic+cbor". 
		</t>
		
		<t>
		  Type name: application
		</t>

		<t>
		  Subtype name: vnd.oic
		</t>
		
		<t>
		  Required parameters: None		
		</t>

		<t>
		  Optional parameters: None
		</t>
		
		<t>
		  Encoding considerations: CBOR
		</t>
		
		<t>
		  Security considerations: As defined in this specification
		</t>
		
		<t>		
		  Interoperability considerations: None 
		</t>

		<t>
		  Published specification: This specification.
		</t>
		
		<t>
		  Applications that use this media type: OIC vertical applications (e.g. Smart Home) 
		</t>

		<t>
		  Additional information:
		<list>
			<t> 
			  Magic number(s): N/A 
			  <vspace />
			</t>
			<t> 
			  File extension(s): N/A
			  <vspace />
			</t>
			<t>
              Macintosh file type code(s):	  
			</t>
        </list>
		</t>
		
		<t>
		   Person email address to contact for further information:
		</t>
		
		<t>
		 Person &amp; email address to contact for further information:
         JinHyeock&nbsp;Choi &lt;jinchoe@samsung.com&gt;  
		</t>

		<t>
		  Intended usage: COMMON
		</t>
		
		<t>
			Authors: JinHyeock Choi
		</t>
		
		<t>
		  Change controller:
		</t>
	  </section>
	  
    </section>
	
    <section anchor="Security" title="Security Considerations">
      <t>
        TBD
	  </t>
    </section>
    
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        TBD
      </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">
      &RFC2119;
	  &RFC4288;
	  &RFC7252;
	  
      <?rfc include="reference.RFC.3552.xml"?> 
  
      
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      &RFC2629;   
      &RFC5226;
	  &RFC6690;
	  &RFC6775;
	  &RFC7049;
	  &RFC7159;
            
	  		

	  <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 T. Fielding">
                <organization />
            </author>
            <date year="2000" />
        </front>
      </reference>
  
      <reference anchor="IPSO" target="http://www.ipso-alliance.org/">
        <front>
          <title>IPSO Alliance Home Page</title>
		  <author>
		  	<organization>IPSO</organization>
		  </author>
		  <date/>
        </front>
      </reference>         
  	  	  
	  <reference anchor="IPSOFramework" target="http://www.ipso-alliance.org/wp-content/media/draft-ipso-app-framework-04.pdf">
        <front>
          <title>The IPSO Application Framework</title>
          <author initials="Z." surname="Shelby">
            <organization>Sensinode</organization>
          </author>
          <author initials="C." surname="Chauvenet">
            <organization>Watteco</organization>
          </author>
          <date year="2012" month="August"/>
        </front>
      </reference>
	  
	  <reference anchor="IPSOSmartObjects" target="http://www.ipso-alliance.org/smart-object-guidelines">
        <front>
          <title>IPSO SmartObject Guideline</title>
          <author>
          	<organization>IPSO</organization>
          </author>
          <date year="2014" month="September"/>
        </front>
      </reference>

      <reference anchor="OCF" target="http://openconnectivity.org/">
        <front>
          <title>Open Connectivity Foundation</title>
		  <author>
		  	<organization>Open Connectivity Foundation</organization>
		  </author>
		  <date/>
        </front>
      </reference>          
	  
    	<reference anchor="OICSPEC" target="http://openconnectivity.org/resources/specifications">
        <front>
          <title>OIC SPECIFICATION 1.0</title>
		  <author>
		  	<organization>Open Connectivity Foundation</organization>
		  </author>
		  <date/>
        </front>
      </reference>  

	  <reference anchor="oneM2M" target="http://www.onem2m.org/">
        <front>
          <title>oneM2M Home Page</title>
		  <author>
		  	<organization>oneM2M</organization>
		  </author>
		  <date/>
        </front>
      </reference>    
	  
	  <reference anchor="oneM2M-TS0001" target="http://www.onem2m.org/images/files/deliverables/TS-0001-Functional_Architecture-V1_6_1.pdf">
        <front>
          <title>Functional Architecture</title>
          <author>
          	<organization>oneM2M</organization>
          </author>
          <date year="2015" month="January"/>
        </front>
      </reference>

	  <reference anchor="oneM2M-TS0004" target="http://www.onem2m.org/images/files/deliverables/TS-0004-Service_Layer_Core_Protocol-V1_0_1.ZIP">
        <front>
          <title>Service Layer Core Protocol Specification</title>
          <author>
          	<organization>oneM2M</organization>
          </author>
          <date year="2015" month="January"/>
        </front>
      </reference>

	  <reference anchor="oneM2M-TS0008" target="http://www.onem2m.org/images/files/deliverables/TS-0008-CoAP_Protocol_Binding-V1_0_1.pdf">
        <front>
          <title>CoAP Protocol Binding</title>
          <author>
          	<organization>OneM2M</organization>
          </author>
          <date year="2015" month="January"/>
        </front>
      </reference>
	  
	  <reference anchor="IIC" target="http://www.industrialinternetconsortium.org/">
        <front>
          <title>Industrial Internet Consortium (IIC) Home Page</title>
		  <author>
		  	<organization>IIC</organization>
		  </author>
		  <date/>
        </front>
      </reference>   
 
 	  <reference anchor="IoE" target="http://ioeassessment.cisco.com/">
        <front>
          <title>Internet of Everything (IoE) Home Page</title>
		  <author>
		  	<organization>IoE</organization>
		  </author>
		  <date/>
        </front>
      </reference>   
 
    </references>



<!-- Change Log

v00 2012-10-11  EBD   Initial version
  
-->
  </back>
</rfc>