Subject: [core] The Profile Description and Minimum Request Interval drafts

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 15 Nov 2012 02:44:32 +0000

Hello all,

Since there was no time in Atlanta to discuss the Profile Format and Minimum Request Interval drafts, I would like to raise awareness through the list. Below summaries of both drafts.

I look forward to your comments!

Best regards,
Bert

Profile Description
===================

http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile-description/

This draft provides a JSON format for signalling the server's capabilities. It currently can signal supported options, media types and block sizes, but other items can be added. It also provides a lookup mechanism by filtering on specific fields through a URI-Query.

To acquire the profile data of resources on a particular service, the .well-known/profile URI-path is introduced. For example, to get all information from sensors served by www.example.org, we can do a GET to http://www.example.org/.well-known/profile.

An example is as follows:

Request:
GET coap://www.example.org/.well-known/profile 

Response:
2.05 Content (application/json) 
{ 
  "profile": 
  { 
    "path":"cam",
    "op":[3,4,7,11,12,19,23,35], 
    "cf":[0,40,50] 
    "b2s":[4,5] 
  }
}

This is the profile of a camera sensor at "coap://www.example.org/cam", that supports the "Uri-Host" (3), "ETag" (4), "Uri-Port" (7), "Uri-Path" (11), "Content-Format" (12), "Token" (19), "Block2" (23) and "Proxy-Uri" (35) options. The supported content formats are "text/plain" (0), "application/ link-format" (40) and "application/json" (50). The supported Block2 can use 256 or 512 byte blocks.

Minimum Request Interval
========================

http://datatracker.ietf.org/doc/draft-greevenbosch-core-minimum-request-interval/

The "MinimumRequestInterval" option can be used to indicate the minimum time between two requests in a transaction. The mechanism was originally intended for Block, but is now also usable for other transactions, such as browsing a server.

In a request, the option contains the time interval between requests that the client is using. In a response, the option contains the minimum interval that the client must obey.

The goal is to reduce the server load and network traffic by slowing down the client, without delaying associated ACKs.