[core] The Profile Description and Minimum Request Interval drafts

Bert Greevenbosch <Bert.Greevenbosch@huawei.com> Thu, 15 November 2012 02:44 UTC

Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA91F041A for <core@ietfa.amsl.com>; Wed, 14 Nov 2012 18:44:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nryh40JUfgn3 for <core@ietfa.amsl.com>; Wed, 14 Nov 2012 18:44:39 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFDB21F853C for <core@ietf.org>; Wed, 14 Nov 2012 18:44:39 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMU79660; Thu, 15 Nov 2012 02:44:37 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 02:44:23 +0000
Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 02:44:35 +0000
Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 10:44:31 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: "core@ietf.org" <core@ietf.org>
Thread-Topic: The Profile Description and Minimum Request Interval drafts
Thread-Index: Ac3C2yNltfzFRkjuQra7R7RmB0Y8gw==
Date: Thu, 15 Nov 2012 02:44:32 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB629123711@szxeml509-mbx>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.110.143]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [core] The Profile Description and Minimum Request Interval drafts
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 02:44:40 -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.