Subject: [core] Fwd: New Version Notification for draft-ietf-core-coap-00

From: Zach Shelby <[email-masked]>
Date: Mon, 7 Jun 2010 18:00:05 +0300

Hi,

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

A new version of the (now working group) document for CoAP has been posted (note it became -00 again as it now has a draft-ietf name). We integrated a bunch of editorial comments, removed the TCP binding, removed the Magic Byte header and Uri-Code for now, and marked the Sub/Notify feature as Experimental while we are discussing the new design in the WG. Managed to make a doc a couple pages shorter ;-) Next step is to make WG trac tickets for all the open issues and TODOs, these we should plan to close by the next release of the doc planned for the end of June. 

   Changes from shelby-01 to ietf-00:

      o Removed the TCP binding section, left open for the future.

      o Fixed a bug in the example.

      o Marked current Sub/Notify as (Experimental) while under WG
      discussion.

      o Temporarily removed the Magic Byte header as TCP is no longer
      included as a binding.

      o Removed the Uri-code Option as different URI encoding schemes
      are being discussed.

      o Changed the rel= field to desc= for resource discovery.

      o Changed the maximum message size to 1024 bytes to allow for IP/
      UDP headers.

      o Made the URI slash optimization and method impotence MUSTs

      o Minor editing and bug fixing.

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: June 7, 2010 5:52:00 PM GMT+03:00
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for draft-ietf-core-coap-00 
> 
> 
> A new version of I-D, draft-ietf-core-coap-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-ietf-core-coap
> Revision:	 00
> Title:		 Constrained Application Protocol (CoAP)
> Creation_date:	 2010-06-07
> WG ID:		 core
> Number_of_pages: 30
> 
> 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 kbit/s.  CoAP provides request/reply and
> subscribe/notify interaction models between application 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, Chief Nerd, 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: John Mani <[email-masked]>
Date: Mon, 07 Jun 2010 11:21:33 -0700

Hi, are there any implementations (experimental, opensource, commercial or
otherwise) in progress for CoAP?

Thanx
-john

On 6/7/10 8:00 AM, "Zach Shelby" <[email-masked]> wrote:

> A new version of the (now working group) document for CoAP has been posted
> (note it became -00 again as it now has a draft-ietf name). We integrated a
> bunch of editorial comments, removed the TCP binding, removed the Magic Byte
> header and Uri-Code for now, and marked the Sub/Notify feature as Experimental
> while we are discussing the new design in the WG. Managed to make a doc a
> couple pages shorter ;-) Next step is to make WG trac tickets for all the open
> issues and TODOs, these we should plan to close by the next release of the doc
> planned for the end of June.
> 
>> A new version of I-D, draft-ietf-core-coap-00.txt has been successfully
>> submitted by Zach Shelby and posted to the IETF repository.
>>

---

From: "Scholz, Andreas" <[email-masked]>
Date: Tue, 8 Jun 2010 11:44:19 +0200

The following considerations are all from an automation point of view, i.e., I want to use subscriptions not for collecting monitoring values, but for connecting sensors and actuators.

I have a practical question concerning the subscription mechanism. Assume I want to use subscriptions to establish a M2M communication, e.g. to connect a light switch to a light bulb. In order to receive notifications whenever the switch is pressed, the light bulb has to subscribe to a resource on the switch. 

How is this done in a practical setting? The user creating this subscription is sitting at a control pc connected to the network (Such subscriptions cannot be established automatically, because the decission which switch is connected to which lamp is often solely driven by user preferences). I can see two ways for creating this subscription:

Option 1: "3rd party subscription"
The user issues a subscribe to the switch resource *on behalf* of the lamp. The lamp will receive the corresponding notifications (and perhaps may also cancel the subscription?). This would require an extension of the currently proposed subscription message.

Option 2: "triggered subscription"
The user tells the light to subscribe at the switch. But how? One solution that comes to my mind is to define a "subscribe to target" endpoint on the light and the user posts the address of the switch to this endpoint. The light will then subscribe to the posted address. I am a little bit concerned that this will lead to a multitude of different "subscribe to target" endpoints with different interfaces. 

Are there other solutions? 

Perhaps this question is also related to the other discussions concerning sub/notify. If CoAP is aimed at networks with a central controller that controls all devices, the current subscription mechanism is sufficient (the controller could even pull all devices so we do not need subscriptions at all). This resembles more or less the traditional, centralized architecture of control applications.

The alternative (and in my opinion more appealing) solution is to allow a distribution of the control logic on the nodes in the network. These distributed parts are then linked together via subscriptions. The tricky part here is that the management will still be performed from a central station.

Andreas

_______________________________________________
Andreas Scholz
Siemens AG
Corporate Technology
Communication Systems & Control Networks
CT T DE IT2
Otto-Hahn-Ring 6
81739 Munich, Germany
Tel.: +49 (89) 636-29302
Fax: +49 (89) 636-51115
mailto:[email-masked]

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Monday, June 07, 2010 5:00 PM
To: core
Subject: [core] Fwd: New Version Notification for draft-ietf-core-coap-00

Hi,

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Jun 2010 13:40:37 +0300

Hi,

> 4.2.  Default Port
> 
>    CoAP SHOULD use a default port of 61616 which is within the
>    compressed UDP port space defined in [RFC4944].  As this port is in
>    the dynamic port space, it however can not be reserved for CoAP use.

it's a bit unfortunate that all the RFC4944 ports are in the dynamic range, because we would probably like to reserve a port for CoAP. In retrospect, it would have been nicer had we burned 16 port numbers in the registered range...

Lars

---

From: Zach Shelby <[email-masked]>
Date: Fri, 11 Jun 2010 13:49:32 +0300

> it's a bit unfortunate that all the RFC4944 ports are in the dynamic range, because we would probably like to reserve a port for CoAP. In retrospect, it would have been nicer had we burned 16 port…

Yep :-( 

I was just about to make a ticket on this Lars. What do you suggest we do here, I mean we can live with ports outside of 61616-61632. Should we define a default CoAP port in the registered range, and then recommend (SHOULD/MUST?) that a port in the LoWPAN range is also supported on 6LoWPAN end-nodes? 

Or can we ask IANA for an exception here and request that part of the LoWPAN port range be reserved for registration - a long shot, I know...

Zach

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Jun 2010 13:59:38 +0300

Hi,

> I was just about to make a ticket on this Lars. What do you suggest we do here, I mean we can live with ports outside of 61616-61632. Should we define a default CoAP port in the registered range, a…

I think you should definitely (also) ask for a port in the registered range, for deployments that may need this. Whether you want to recommend this port as the default I don't know, because the compression then becomes slightly less efficient.

> Or can we ask IANA for an exception here and request that part of the LoWPAN port range be reserved for registration - a long shot, I know...

Not possible, I'm afraid. IANA won't assign ports above 49152.

Lars