Subject: [core] Fwd: New Version Notification for draft-shelby-core-coap-01

From: Zach Shelby <[email-masked]>
Date: Mon, 10 May 2010 10:19:30 +0300

Hi,

Version -01 of draft-shelby-core-coap is now available:

http://www.ietf.org/id/draft-shelby-core-coap-01.txt

This has gone through a lot of little revisions after Anaheim based on the list discussions, comments on -00, discussions with the chairs and quite a bit of implementation validation. We hope -01 fixes most of the issues and provides the main improvements requested so far. My goal is to keep this stable for a longer time to give people a chance to get some implementation experience (have heard of 5 implementations so far). Next update planned before the Maastricht cutoff.

Here is a summary of the major changes in -01:

- Method names now GET, PUT, POST, DELETE
- Unified the message header and added a notify message type.
- Completed the SUBMIT method and option
- Improved the option TLV header, added Etag, Date and Subscription-lifetime Options
- Added a Magic byte header for TCP and packed UDP
- Wrote initial subscription, discovery and proxy sections
- Plenty of simplification, optimization and bug fixes 

And of course still plenty of TODOs, the main ones are:

- HTTP Mapping
- Proxying
- Complete Examples section 
- Define the TLS and DTLS bindings (help!) 

Zach, Brian and Don

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: May 10, 2010 10:05:25 GMT+03:00
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for draft-shelby-core-coap-01 
> 
> 
> A new version of I-D, draft-shelby-core-coap-01.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-shelby-core-coap
> Revision:	 01
> Title:		 Constrained Application Protocol (CoAP)
> Creation_date:	 2010-05-10
> WG ID:		 Independent Submission
> Number_of_pages: 33
> 
> Abstract:
> This document specifies the Constrained Application Protocol (CoAP),
> a specialized transfer protocol for use with constrained networks and
> nodes for machine-to-machine applications such as smart energy and
> building automation.  These constrained nodes often have 8-bit
> microcontrollers with small amounts of ROM and RAM, while networks
> such as 6LoWPAN often have high packet error rates and typical
> throughput of 10s of kbps.  CoAP provides request/reply and
> subscribe/notify interaction models between appliciation end-points,
> supports built-in resource discovery, and includes key web concepts
> such as URIs and RESTful methods.  CoAP easily translates to HTTP for
> integration with the web while meeting specialized requirements such
> as multicast support, very low overhead and simplicity for
> constrained environments.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
Zach Shelby, Head of Research, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: [email-masked]
Date: Tue, 11 May 2010 10:11:56 +0200

Hi,

First of all congratulations for your work.

I have few comments about the subscribe/notify mechanism and the resource
directory.

As far as I understand the specification, a client will receive its
notifications on the same port as the subscribe request. As an implementer
I would like to handle all asynchronous notifications on a dedicated port
and perform synchronous GET, POST, PUT, DELETE on a different port. The
current specification allows to do this for the UDP binding as it is
connectionless but for the TCP binding I must keep the connection I used
for the subscribe request alive. Just tell me if it is not the good
approach because  I know TCP is not a major concern for COAP.

How can I define a fine grained notification? Is it completlty left to the
application so I must define a message format to describe precise
notification rules and include this message into the subscribe payload or
will you provide a framework later? Typical notification options would be:
minimal delay between 2 notifications to prevent from overwhelming the
network, an increment as the minimal change for noisy inputs, a maximum
delay between notifications for periodic notifications and keep alive
signals ...

How do you manage the lifetime of resources in the resource directory?
The /.well-known/resources will probably not change very often so a simple
subscription/notification would be useless. Moreover a periodic POST from
devices seems not very efficient because the link format is quite verbose
to be repeated without a real need. We could reuse the cacheability of COAP
to avoid large data transfer but only the get method is cacheable. That
means the directory agent should have a list of all devices. This imply
some kind of registration mechanism to the directory.

Best regards,
Matthieu VIAL

             Zach Shelby                                                   
             <[email-masked]                                             
             om>                                                         A 
             Envoyé par :              core <[email-masked]>                
             core-bounces@ietf                                          cc 
             .org                                                          
                                                                     Objet 
                                       [core] Fwd: New Version             
             10/05/2010 09:19          Notification for                    
                                       draft-shelby-core-coap-01           

                                                                           

Hi,

This has gone through a lot of little revisions after Anaheim based on the
list discussions, comments on -00, discussions with the chairs and quite a
bit of implementation validation. We hope -01 fixes most of the issues and
provides the main improvements requested so far. My goal is to keep this
stable for a longer time to give people a chance to get some implementation
experience (have heard of 5 implementations so far). Next update planned
before the Maastricht cutoff.

- Method names now GET, PUT, POST, DELETE
- Unified the message header and added a notify message type.
- Completed the SUBMIT method and option
- Improved the option TLV header, added Etag, Date and
Subscription-lifetime Options
- Added a Magic byte header for TCP and packed UDP
- Wrote initial subscription, discovery and proxy sections
- Plenty of simplification, optimization and bug fixes

- HTTP Mapping
- Proxying

Zach, Brian and Don

Begin forwarded message:

> A new version of I-D, draft-shelby-core-coap-01.txt has been successfully
submitted by Zach Shelby and posted to the IETF repository.

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

---

From: Zach Shelby <[email-masked]>
Date: Wed, 12 May 2010 00:16:43 +0300

Hi,

On May 11, 2010, at 11:11 , [email-masked] wrote:

> I have few comments about the subscribe/notify mechanism and the resource directory.
> 
> As far as I understand the specification, a client will receive its notifications on the same port as the subscribe request. As an implementer I would like to handle all asynchronous notifications on a dedicated port and perform synchronous GET, POST, PUT, DELETE on a different port. The current specification allows to do this for the UDP binding as it is connectionless but for the TCP binding I must keep the connection I used for the subscribe request alive. Just tell me if it is not the good approach because I know TCP is not a major concern for COAP.

Argh, yet again some problems with TCP. Surely a way to make that work of course, but it would need more text... 

> 
> How can I define a fine grained notification? Is it completlty left to the application so I must define a message format to describe precise notification rules and include this message into the subscribe payload or will you provide a framework later? Typical notification options would be: minimal delay between 2 notifications to prevent from overwhelming the network, an increment as the minimal change for noisy inputs, a maximum delay between notifications for periodic notifications and keep alive signals ...

For sure MIN_NOTIFY_INTERVAL and MAX_NOTIFY_INTERVAL variables should be added, maybe with a recommended default. With regards to having more knobs to turn here, I could envision having e.g. a Subscription-interval Option in addition to Subscription-lifetime. Now that said, anything more complicated is probably out of scope for CoRE. At least the transfer protocol shouldn't involve itself with data thresholds etc.  

> 
> How do you manage the lifetime of resources in the resource directory? The /.well-known/resources will probably not change very often so a simple subscription/notification would be useless. Moreover a periodic POST from devices seems not very efficient because the link format is quite verbose to be repeated without a real need. We could reuse the cacheability of COAP to avoid large data transfer but only the get method is cacheable. That means the directory agent should have a list of all devices. This imply some kind of registration mechanism to the directory.

This is a good discussion to have. At least the Etag can help here to prevent all data from being sent each time, and even a subscription could be useful in some cases. What I also had in mind was that a directory can act as a RESTful repository which can store the descriptions of others. In the end here we have to make an analysis of real resource discovery scenarios, how they work with these mechanisms, and then see if we're really missing something. Someone should write a draft like that by the way... 

Zach

> 
> Best regards,
> Matthieu VIAL
> 
> 
> Zach Shelby <[email-masked]>
> 
> 
> 
> 
> Zach Shelby <[email-masked]> 
> Envoyé par : [email-masked]
> 10/05/2010 09:19
> 
> A
> core <[email-masked]>
> cc
> Objet
> [core] Fwd: New Version Notification for draft-shelby-core-coap-01
> 
> Hi,
>

---

From: "Oflynn, Colin" <[email-masked]>
Date: Tue, 11 May 2010 19:31:12 -0600

Hello,

>I could envision having e.g. a Subscription-interval Option in addition to Subscription-lifetime.

More buttons, people love buttons ;-)

In all seriousness though: I think this can also be solved with REST itself in a way. Perhaps elements that you can subscribe to have some information you can get. They might have like a "subscribe options" that lists various information & options. When you do the subscribe you use those options as part of the subscribe message.

So for instance you get the "subscription options" for a node, which indicates it's "notify timebase" is in increments of 15 seconds. The default is to notify at minimum every 4 timebases (ie: 60 seconds). Then when you subscribe, you ask to subscribe with your minimum of 10 timebases (150 seconds). 

I would suggest keeping it as a general as possible. In this case you have 'subscription options' a subscriber reads, then uses that to pass some specific data/elements. We could define at as a start the "notify timebase", "minimum notify time", and "maximum notify time". But you can extend that later or move it to another draft... What do you think?

Regards,

  -Colin

-----Original Message-----
From: [email-masked] on behalf of Zach Shelby
Sent: Tue 11/05/2010 22:16
To: [email-masked]
Cc: core
Subject: Re: [core] RE Fwd: New Version Notification fordraft-shelby-core-coap-01
 
Hi,

Zach