From zach@sensinode.com Mon Mar 1 13:30:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE3828C591; Mon, 1 Mar 2010 13:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L1EMEHvlxjJ; Mon, 1 Mar 2010 13:30:22 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9C20628C5DC; Mon, 1 Mar 2010 13:30:17 -0800 (PST) Received: from [213.145.205.238] ([213.145.205.238]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o21LU9PE002764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Mar 2010 23:30:11 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Mar 2010 23:30:11 +0200 References: <20100301212435.28BDD28C1B5@core3.amsl.com> To: 6LoWAPP <6lowapp@ietf.org>, core@ietf.org Message-Id: <489285BF-8B4B-45E2-B0F9-625CCC45FA21@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [core] Fwd: New Version Notification for draft-shelby-core-coap-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 21:30:24 -0000 http://www.ietf.org/id/draft-shelby-core-coap-00.txt Here is a very early draft of a CoAP protocol specification based on the = requirements and initial ideas formulated in = draft-shelby-core-coap-req-00 and the previous work by Brian in = draft-frank-6lowapp-chopan. Looking forward to lots of good discussion = around CoAP, and as you can see from all the TODOs and TBDs - lots of WG = stuff to do here!=20 At the same time I'd like to request a time-slot to present this in = Anaheim. Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 1, 2010 23:24:35 GMT+02:00 > To: zach@sensinode.com > Cc: brian.tridium@gmail.com > Subject: New Version Notification for draft-shelby-core-coap-00=20 >=20 >=20 > A new version of I-D, draft-shelby-core-coap-00.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-coap > Revision: 00 > Title: Constrained Application Protocol (CoAP) > Creation_date: 2010-03-01 > WG ID: Independent Submission > Number_of_pages: 17 >=20 > Abstract: > This document specifies the Constrained Application Protocol (CoAP), > a RESTful protocol for use with constrained networks and nodes. 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. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From Colin.OFlynn@atmel.com Mon Mar 1 23:22:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6167828C6E9; Mon, 1 Mar 2010 23:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QByM3q2ytG0k; Mon, 1 Mar 2010 23:22:06 -0800 (PST) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 73D0028C6E0; Mon, 1 Mar 2010 23:22:06 -0800 (PST) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o227K5P0013087; Mon, 1 Mar 2010 23:20:06 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB9D9.06CD064C" Date: Tue, 2 Mar 2010 00:21:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-D: Initial Configuration of Resource-Constrained Devices (aka: Bootstrapping / Commissioning) Thread-Index: Acq52QauWhYparFBSh2geEx+R60x5Q== From: "Oflynn, Colin" To: , <6lowapp@ietf.org> Subject: [core] New I-D: Initial Configuration of Resource-Constrained Devices (aka: Bootstrapping / Commissioning) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 07:22:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB9D9.06CD064C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/id/draft-oflynn-core-bootstrapping-00.txt Lots to do in here still. Note this was posted yesterday, but I didn't = get around to forwarding the announcement. This updates the previous = 6lowapp bootstrapping document a bit too, but is posted as a new I-D to = move to the CoRE group. Regards, -Colin Filename: draft-oflynn-core-bootstrapping Version: 00 Title: Initial Configuration of Resource-Constrained Devices Creation_date: 2010-02-28 WG ID: Individual Submission Number_of_pages: 28 Abstract: The Internet of Things is marching its way towards completion. Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP connectivity. IEEE Standards ensure connectivity at lower layers for resource-constrained devices. Yet a central problem remains at a more basic layer without a suitable answer: how to initially configure the network. Without configuration the network never advances beyond a large box of nodes. Current solutions tend to be specific to a certain vendor, node type, or application. This document outlines exactly what problems are faced in solving this problem. General problems faced in any low-power wireless network are outlined first; followed by how these apply to bootstrapping. A selection of currently proposed techniques is presented. From these a more generic approach is presented, which can solve the problem for a wide range of situations. An emphasis is on performing this bootstrapping in a secure manner. This document does not cover operation of the network securely. This document does provide the basis for allowing the network to operate securely however, by providing standard methods for key exchanges and authentication. Submitter: Colin O'Flynn (colin.oflynn@atmel.com) Author(s): Colin O'Flynn, colin.oflynn@atmel.com Behcet Sarikaya, sarikaya@ieee.org ------_=_NextPart_001_01CAB9D9.06CD064C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New I-D: Initial Configuration of Resource-Constrained Devices = (aka: Bootstrapping / Commissioning)

ht= tp://www.ietf.org/id/draft-oflynn-core-bootstrapping-00.txt

Lots to do in here still. Note this was posted yesterday, but I didn't = get around to forwarding the announcement. This updates the previous = 6lowapp bootstrapping document a bit too, but is posted as a new I-D to = move to the CoRE group.

Regards,

  -Colin


Filename:          = draft-oflynn-core-bootstrapping
Version:           = 00
Title:           &= nbsp; Initial Configuration of Resource-Constrained Devices
Creation_date:     2010-02-28
WG = ID:           &nbs= p; Individual Submission
Number_of_pages: 28
Abstract:
The Internet of Things is marching its way towards completion.  = Nodes
can use standards from the 6LoWPAN and ROLL WG to achieve IP
connectivity.  IEEE Standards ensure connectivity at lower layers = for
resource-constrained devices.  Yet a central problem remains at = a
more basic layer without a suitable answer: how to initially
configure the network.  Without configuration the network never
advances beyond a large box of nodes.  Current solutions tend to = be
specific to a certain vendor, node type, or application.

This document outlines exactly what problems are faced in solving
this problem.  General problems faced in any low-power wireless
network are outlined first; followed by how these apply to
bootstrapping.  A selection of currently proposed techniques is
presented.  From these a more generic approach is presented, = which
can solve the problem for a wide range of situations.

An emphasis is on performing this bootstrapping in a secure manner.
This document does not cover operation of the network securely.  = This
document does provide the basis for allowing the network to operate
securely however, by providing standard methods for key exchanges = and
authentication.

Submitter: Colin O'Flynn (colin.oflynn@atmel.com)

Author(s):
Colin O'Flynn, colin.oflynn@atmel.com
Behcet Sarikaya, sarikaya@ieee.org

------_=_NextPart_001_01CAB9D9.06CD064C-- From apezzuto@cisco.com Tue Mar 2 14:47:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C55328C29A for ; Tue, 2 Mar 2010 14:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxMb4dMO3KSY for ; Tue, 2 Mar 2010 14:47:56 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0861628C1C1 for ; Tue, 2 Mar 2010 14:47:55 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKokjUutJV2c/2dsb2JhbACbCXOmCZhIhHsE X-IronPort-AV: E=Sophos;i="4.49,569,1262563200"; d="scan'208";a="90133107" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2010 22:47:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o22MlsHV013079; Tue, 2 Mar 2010 22:47:55 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 23:47:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Mar 2010 23:47:52 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC01635092@XMB-AMS-106.cisco.com> In-Reply-To: <489285BF-8B4B-45E2-B0F9-625CCC45FA21@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Fwd: New Version Notification for draft-shelby-core-coap-00 Thread-Index: Acq5huGTbktdIA7ZR5erNobGRtkoQQAqDciA References: <20100301212435.28BDD28C1B5@core3.amsl.com> <489285BF-8B4B-45E2-B0F9-625CCC45FA21@sensinode.com> From: "Adriano Pezzuto (apezzuto)" To: "Zach Shelby" , X-OriginalArrivalTime: 02 Mar 2010 22:47:54.0003 (UTC) FILETIME=[6521FE30:01CABA5A] Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-coap-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:47:57 -0000 Hello Zach, may be useful to have also an explicit SUBSCRIBE method in addition to = the other methods listed in section 3.1. The SUBSCRIBE and NOTIFY = methods can be used in combination for asynch data notification. The = SUBSCRIBE request header will include the URI for the further NOTIFY = requests to subscribing node and other some useful info. An example may help (please, consider this only as an example: details = can be tuned). Let to have a source CoAP node having a light sensor and a target CoAP = node having a dimmer for awnings. The source node is controlling the = awnings on the target node when the light sun is too heavy (a threshold = is defined on the light sensor that triggers ON/OFF commands to the = dimmer). The source node has a read-only resource addressed by the URI = coap://source-node/light-sensor while the target node has a read-write = resource addressed by coap://target-node/awnings-dimmer.=20 Source <---------------------- CoAP ----------------------> Target <- SUBSCRIBE Request = CoAP/1.0 URI = coap://source-node/light-sensor Request header: = /target-node/awnings-dimmer Request header: = threshold for light-sensor CoAP/1.0 202 (Accepted) -> Response header: /source-node/light-sensor .... the threshold on light-sensor is set=20 .... light-sensor threshold is crossed triggering a data notification .... NOTIFY Request CoAP/1.0 -> URI coap://target-node/awnings-dimmer Entity body: 'DIMMER ON' command <- CoAP/1.0 200 (OK) .... = =20 awnings-dimmer is = switched ON .................... Hope this help, Adriano -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Zach Shelby Sent: luned=EC 1 marzo 2010 22.30 To: 6LoWAPP; core@ietf.org Subject: [core] Fwd: New Version Notification for = draft-shelby-core-coap-00 http://www.ietf.org/id/draft-shelby-core-coap-00.txt Here is a very early draft of a CoAP protocol specification based on the = requirements and initial ideas formulated in = draft-shelby-core-coap-req-00 and the previous work by Brian in = draft-frank-6lowapp-chopan. Looking forward to lots of good discussion = around CoAP, and as you can see from all the TODOs and TBDs - lots of WG = stuff to do here!=20 At the same time I'd like to request a time-slot to present this in = Anaheim. Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 1, 2010 23:24:35 GMT+02:00 > To: zach@sensinode.com > Cc: brian.tridium@gmail.com > Subject: New Version Notification for draft-shelby-core-coap-00=20 >=20 >=20 > A new version of I-D, draft-shelby-core-coap-00.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-coap > Revision: 00 > Title: Constrained Application Protocol (CoAP) > Creation_date: 2010-03-01 > WG ID: Independent Submission > Number_of_pages: 17 >=20 > Abstract: > This document specifies the Constrained Application Protocol (CoAP), > a RESTful protocol for use with constrained networks and nodes. 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. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From hgs@cs.columbia.edu Tue Mar 2 14:50:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4891228C226 for ; Tue, 2 Mar 2010 14:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkgT0PXjZRrT for ; Tue, 2 Mar 2010 14:50:06 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id DA28528C1C1 for ; Tue, 2 Mar 2010 14:50:05 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o22Mo3MA023669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Mar 2010 17:50:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne In-Reply-To: <0D212BD466921646B58854FB79092CEC01635092@XMB-AMS-106.cisco.com> Date: Tue, 2 Mar 2010 17:50:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <23F85DBE-E949-4552-8DC8-26EA94C7F8B7@cs.columbia.edu> References: <20100301212435.28BDD28C1B5@core3.amsl.com> <489285BF-8B4B-45E2-B0F9-625CCC45FA21@sensinode.com> <0D212BD466921646B58854FB79092CEC01635092@XMB-AMS-106.cisco.com> To: "Adriano Pezzuto (apezzuto)" X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-coap-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:50:07 -0000 Looking at the message flow, you are well on your way to re-invent SIP = :-) (or XMPP, for that matter). On Mar 2, 2010, at 5:47 PM, Adriano Pezzuto (apezzuto) wrote: > Hello Zach, >=20 > may be useful to have also an explicit SUBSCRIBE method in addition to = the other methods listed in section 3.1. The SUBSCRIBE and NOTIFY = methods can be used in combination for asynch data notification. The = SUBSCRIBE request header will include the URI for the further NOTIFY = requests to subscribing node and other some useful info. >=20 > An example may help (please, consider this only as an example: details = can be tuned). >=20 > Let to have a source CoAP node having a light sensor and a target CoAP = node having a dimmer for awnings. The source node is controlling the = awnings on the target node when the light sun is too heavy (a threshold = is defined on the light sensor that triggers ON/OFF commands to the = dimmer). > The source node has a read-only resource addressed by the URI = coap://source-node/light-sensor while the target node has a read-write = resource addressed by coap://target-node/awnings-dimmer.=20 >=20 > Source <---------------------- CoAP ----------------------> Target >=20 > <- SUBSCRIBE Request = CoAP/1.0 > URI = coap://source-node/light-sensor > Request header: = /target-node/awnings-dimmer > Request header: = threshold for light-sensor > CoAP/1.0 202 (Accepted) -> > Response header: /source-node/light-sensor > .... > the threshold on light-sensor is set=20 > .... > light-sensor threshold is crossed triggering a data notification > .... >=20 > NOTIFY Request CoAP/1.0 -> > URI coap://target-node/awnings-dimmer > Entity body: 'DIMMER ON' command >=20 > <- CoAP/1.0 200 (OK) > .... = =20 > awnings-dimmer is = switched ON >=20 > .................... >=20 >=20 > Hope this help, > Adriano >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Zach Shelby > Sent: luned=EC 1 marzo 2010 22.30 > To: 6LoWAPP; core@ietf.org > Subject: [core] Fwd: New Version Notification for = draft-shelby-core-coap-00 >=20 > http://www.ietf.org/id/draft-shelby-core-coap-00.txt >=20 > Here is a very early draft of a CoAP protocol specification based on = the requirements and initial ideas formulated in = draft-shelby-core-coap-req-00 and the previous work by Brian in = draft-frank-6lowapp-chopan. Looking forward to lots of good discussion = around CoAP, and as you can see from all the TODOs and TBDs - lots of WG = stuff to do here!=20 >=20 > At the same time I'd like to request a time-slot to present this in = Anaheim. >=20 > Zach >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool >> Date: March 1, 2010 23:24:35 GMT+02:00 >> To: zach@sensinode.com >> Cc: brian.tridium@gmail.com >> Subject: New Version Notification for draft-shelby-core-coap-00=20 >>=20 >>=20 >> A new version of I-D, draft-shelby-core-coap-00.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >>=20 >> Filename: draft-shelby-core-coap >> Revision: 00 >> Title: Constrained Application Protocol (CoAP) >> Creation_date: 2010-03-01 >> WG ID: Independent Submission >> Number_of_pages: 17 >>=20 >> Abstract: >> This document specifies the Constrained Application Protocol (CoAP), >> a RESTful protocol for use with constrained networks and nodes. 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. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" > Mobile: +358 40 7796297 >=20 > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND >=20 > This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From braun@net.in.tum.de Wed Mar 3 01:25:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8353A899A; Wed, 3 Mar 2010 01:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3yINWSN4vTV; Wed, 3 Mar 2010 01:25:31 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 9B7463A85CF; Wed, 3 Mar 2010 01:25:31 -0800 (PST) Received: from honshu.net.in.tum.de (honshu.net.in.tum.de [131.159.20.100]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 8C93421102B4; Wed, 3 Mar 2010 10:25:21 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1077) From: Lothar Braun Date: Wed, 3 Mar 2010 10:25:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <98476DC1-5D72-46E0-931E-11994A2550A8@net.in.tum.de> References: <20100301094119.0F8423A8B2F@core3.amsl.com> To: 6LoWAPP <6lowapp@ietf.org> X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV using ClamSMTP Cc: core@ietf.org Subject: [core] Fwd: New Version Notification for draft-braun-core-compressed-ipfix-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 09:25:32 -0000 Hi all, we have submitted a new draft on Compressed IPFIX for smart meters in = constrained networks: http://tools.ietf.org/id/draft-braun-core-compressed-ipfix-00.txt This draft replaces draft-schmitt-6lowapp-ipfix-ws. It was already = submitted on monday, but I did not find the time to announce it until = now.=20 I would like to have a 5 min time slot to present it in Anaheim. Best regards, Lothar Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 1, 2010 10:41:19 AM GMT+01:00 > To: braun@net.in.tum.de > Cc: schmitt@net.in.tum.de,bclaise@cisco.com,carle@net.in.tum.de > Subject: New Version Notification for = draft-braun-core-compressed-ipfix-00=20 >=20 >=20 > A new version of I-D, draft-braun-core-compressed-ipfix-00.txt has = been successfuly submitted by Lothar Braun and posted to the IETF = repository. >=20 > Filename: draft-braun-core-compressed-ipfix > Revision: 00 > Title: Compressed IPFIX for smart meters in = constrained networks > Creation_date: 2010-03-01 > WG ID: Independent Submission > Number_of_pages: 25 >=20 > Abstract: > This document specifies the Compressed IPFIX protocol that serves for > transmitting measurement data in 6LoWPAN networks [RFC4944]. > Compressed IPFIX is derived from IPFIX [RFC5101] and adopted to the > needs of constrained networks. This documents defines how the > Compressed IPFIX Data and Template Records are transmitted in 6LoWPAN > networks and how Compressed IPFIX data can be converted into > uncompressed IPFIX data. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From alexandru.petrescu@gmail.com Wed Mar 3 04:38:40 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C7A3A8D9A for ; Wed, 3 Mar 2010 04:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+5oz6MKjc-N for ; Wed, 3 Mar 2010 04:38:37 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id E17523A880D for ; Wed, 3 Mar 2010 04:38:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o23Ccacx025530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Mar 2010 13:38:36 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o23Ccaox030235 for ; Wed, 3 Mar 2010 13:38:36 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o23CcZrQ029124 for ; Wed, 3 Mar 2010 13:38:36 +0100 Message-ID: <4B8E584B.1050204@gmail.com> Date: Wed, 03 Mar 2010 13:38:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: core@ietf.org References: <20100301212435.28BDD28C1B5@core3.amsl.com> <489285BF-8B4B-45E2-B0F9-625CCC45FA21@sensinode.com> <0D212BD466921646B58854FB79092CEC01635092@XMB-AMS-106.cisco.com> <23F85DBE-E949-4552-8DC8-26EA94C7F8B7@cs.columbia.edu> In-Reply-To: <23F85DBE-E949-4552-8DC8-26EA94C7F8B7@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-coap-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 12:38:40 -0000 :-) Looking at the draft text below, you're well on your way to re-invent IPv6: "The base header may be followed by options in ICMP-style Type-Length-Value format. :-) Alex (for some reason I am subscribed to this list, and I can't remember whether I've subscribed intentionally or someone else subscribed me, sorry.) Le 02/03/2010 23:50, Henning Schulzrinne a écrit : > Looking at the message flow, you are well on your way to re-invent SIP :-) (or XMPP, for that matter). > > On Mar 2, 2010, at 5:47 PM, Adriano Pezzuto (apezzuto) wrote: > >> Hello Zach, >> >> may be useful to have also an explicit SUBSCRIBE method in addition to the other methods listed in section 3.1. The SUBSCRIBE and NOTIFY methods can be used in combination for asynch data notification. The SUBSCRIBE request header will include the URI for the further NOTIFY requests to subscribing node and other some useful info. >> >> An example may help (please, consider this only as an example: details can be tuned). >> >> Let to have a source CoAP node having a light sensor and a target CoAP node having a dimmer for awnings. The source node is controlling the awnings on the target node when the light sun is too heavy (a threshold is defined on the light sensor that triggers ON/OFF commands to the dimmer). >> The source node has a read-only resource addressed by the URI coap://source-node/light-sensor while the target node has a read-write resource addressed by coap://target-node/awnings-dimmer. >> >> Source<---------------------- CoAP ----------------------> Target >> >> <- SUBSCRIBE Request CoAP/1.0 >> URI coap://source-node/light-sensor >> Request header: /target-node/awnings-dimmer >> Request header: threshold for light-sensor >> CoAP/1.0 202 (Accepted) -> >> Response header: /source-node/light-sensor >> .... >> the threshold on light-sensor is set >> .... >> light-sensor threshold is crossed triggering a data notification >> .... >> >> NOTIFY Request CoAP/1.0 -> >> URI coap://target-node/awnings-dimmer >> Entity body: 'DIMMER ON' command >> >> <- CoAP/1.0 200 (OK) >> .... >> awnings-dimmer is switched ON >> >> .................... >> >> >> Hope this help, >> Adriano >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zach Shelby >> Sent: lunedì 1 marzo 2010 22.30 >> To: 6LoWAPP; core@ietf.org >> Subject: [core] Fwd: New Version Notification for draft-shelby-core-coap-00 >> >> http://www.ietf.org/id/draft-shelby-core-coap-00.txt >> >> Here is a very early draft of a CoAP protocol specification based on the requirements and initial ideas formulated in draft-shelby-core-coap-req-00 and the previous work by Brian in draft-frank-6lowapp-chopan. Looking forward to lots of good discussion around CoAP, and as you can see from all the TODOs and TBDs - lots of WG stuff to do here! >> >> At the same time I'd like to request a time-slot to present this in Anaheim. >> >> Zach >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: March 1, 2010 23:24:35 GMT+02:00 >>> To: zach@sensinode.com >>> Cc: brian.tridium@gmail.com >>> Subject: New Version Notification for draft-shelby-core-coap-00 >>> >>> >>> A new version of I-D, draft-shelby-core-coap-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. >>> >>> Filename: draft-shelby-core-coap >>> Revision: 00 >>> Title: Constrained Application Protocol (CoAP) >>> Creation_date: 2010-03-01 >>> WG ID: Independent Submission >>> Number_of_pages: 17 >>> >>> Abstract: >>> This document specifies the Constrained Application Protocol (CoAP), >>> a RESTful protocol for use with constrained networks and nodes. 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. >>> >>> >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From hgs@cs.columbia.edu Wed Mar 3 18:04:33 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E6D28C4DA; Wed, 3 Mar 2010 18:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f95XjVeD-1Ol; Wed, 3 Mar 2010 18:04:31 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 73E7A28C25C; Wed, 3 Mar 2010 18:04:25 -0800 (PST) Received: from new-host-3.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2424LAT002970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 21:04:22 -0500 (EST) From: Henning Schulzrinne Content-Type: multipart/alternative; boundary=Apple-Mail-1--549230745 Date: Wed, 3 Mar 2010 21:04:21 -0500 References: <4B8F144B.5040903@lbl.gov> To: recipe@ietf.org, core@ietf.org Message-Id: <482A935F-8296-4A1F-9D37-CC9F187D1FFF@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [core] 'Internet of Things' research group bar BoF X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 02:04:33 -0000 --Apple-Mail-1--549230745 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI. > Subject: 'Internet of Things' research group bar BoF > Date: Tue, 02 Mar 2010 09:03:45 -0500 > From: Aaron Falk > I'm planning a very informal bar BoF at the Anaheim IETF to discuss the > possibility of an IRTF research group on topics under the general > heading of 'Internet of Things'. I define this space broadly to include > embedded sensing, RFIDs, building systems (including HVAC, security, > lighting, etc), cameras & imaging, and industrial/manufacturing > systems. I think this is a fairly large space that is a good candidate > for an IRTF research group. While IRTF research groups are shaped by > the interests of the participants, in my opinion, such an activity would > be well served by a focus on developing an architecture, thus enabling a > common framework and terminology. > > Feel free to forward to those who might be interested. The logistics > will be based on the response to the poll at [1] and will be posted on > the IETF bulletin board at at the IRTF wiki [2]. > > --aaron > Chair, IRTF > > [1] Scheduling poll: http://www.doodle.com/2q3cfv8snvder2wn > [2] IRTF wiki: http://tools.ietf.org/group/irtf/trac/wiki. --Apple-Mail-1--549230745 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
FYI.

Subject: 'Internet of Things' research group bar BoF
Date: Tue, 02 Mar 2010 09:03:45 -0500
From: Aaron Falk <falk@bbn.com>
I'm planning a very informal bar BoF at the Anaheim IETF to discuss the
possibility of an IRTF research group on topics under the general
heading of 'Internet of Things'.  I define this space broadly to include
embedded sensing, RFIDs, building systems (including HVAC, security,
lighting, etc), cameras & imaging, and industrial/manufacturing
systems.  I think this is a fairly large space that is a good candidate
for an IRTF research group.  While IRTF research groups are shaped by
the interests of the participants, in my opinion, such an activity would
be well served by a focus on developing an architecture, thus enabling a
common framework and terminology. 

Feel free to forward to those who might be interested.  The logistics
will be based on the response to the poll at [1] and will be posted on
the IETF bulletin board at at the IRTF wiki [2].

--aaron
  Chair, IRTF

[1] Scheduling poll: http://www.doodle.com/2q3cfv8snvder2wn
[2] IRTF wiki: http://tools.ietf.org/group/irtf/trac/wiki.

--Apple-Mail-1--549230745-- From braun@net.in.tum.de Sun Mar 7 23:41:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F84B3A686E; Sun, 7 Mar 2010 23:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHKTvO7O32pz; Sun, 7 Mar 2010 23:41:39 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 928813A677D; Sun, 7 Mar 2010 23:41:39 -0800 (PST) Received: from honshu.net.in.tum.de (honshu.net.in.tum.de [131.159.20.100]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 8675E200A793; Mon, 8 Mar 2010 08:41:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Lothar Braun In-Reply-To: <98476DC1-5D72-46E0-931E-11994A2550A8@net.in.tum.de> Date: Mon, 8 Mar 2010 08:41:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25D89985-5131-479A-BF4C-15499CD29336@net.in.tum.de> References: <20100301094119.0F8423A8B2F@core3.amsl.com> <98476DC1-5D72-46E0-931E-11994A2550A8@net.in.tum.de> To: 6LoWAPP <6lowapp@ietf.org> X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV using ClamSMTP Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-braun-core-compressed-ipfix-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 07:41:41 -0000 Hi all,=20 we submitted an update on the draft "Compressed IPFIX for smart meters = in constrained networks": http://tools.ietf.org/html/draft-braun-core-compressed-ipfix-01 Best regards, Lothar On Mar 3, 2010, at 10:25 AM, Lothar Braun wrote: > Hi all, >=20 > we have submitted a new draft on Compressed IPFIX for smart meters in = constrained networks: >=20 > http://tools.ietf.org/id/draft-braun-core-compressed-ipfix-00.txt >=20 > This draft replaces draft-schmitt-6lowapp-ipfix-ws. It was already = submitted on monday, but I did not find the time to announce it until = now.=20 > I would like to have a 5 min time slot to present it in Anaheim. >=20 > Best regards, > Lothar >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool >> Date: March 1, 2010 10:41:19 AM GMT+01:00 >> To: braun@net.in.tum.de >> Cc: schmitt@net.in.tum.de,bclaise@cisco.com,carle@net.in.tum.de >> Subject: New Version Notification for = draft-braun-core-compressed-ipfix-00=20 >>=20 >>=20 >> A new version of I-D, draft-braun-core-compressed-ipfix-00.txt has = been successfuly submitted by Lothar Braun and posted to the IETF = repository. >>=20 >> Filename: draft-braun-core-compressed-ipfix >> Revision: 00 >> Title: Compressed IPFIX for smart meters in = constrained networks >> Creation_date: 2010-03-01 >> WG ID: Independent Submission >> Number_of_pages: 25 >>=20 >> Abstract: >> This document specifies the Compressed IPFIX protocol that serves for >> transmitting measurement data in 6LoWPAN networks [RFC4944]. >> Compressed IPFIX is derived from IPFIX [RFC5101] and adopted to the >> needs of constrained networks. This documents defines how the >> Compressed IPFIX Data and Template Records are transmitted in 6LoWPAN >> networks and how Compressed IPFIX data can be converted into >> uncompressed IPFIX data. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 > -- > Lothar Braun > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18010 Fax: +49 89 289-18033 > E-mail: braun@net.in.tum.de=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From rstruik@certicom.com Tue Mar 9 05:34:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1383A681C; Tue, 9 Mar 2010 05:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2urA6ha5z5FT; Tue, 9 Mar 2010 05:34:45 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 496873A67F0; Tue, 9 Mar 2010 05:34:44 -0800 (PST) X-AuditID: 0a401fcb-b7b5cae0000009f8-7b-4b964e78594b Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 09.5A.02552.87E469B4; Tue, 9 Mar 2010 08:34:48 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 08:34:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 9 Mar 2010 08:34:24 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4045E0C20@XCH57YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-struik-6lowapp-security-considerations Thread-Index: Acq/I0QKpx2BSsNnTbSu9OQLkhCOAAAaZUvg From: "Rene Struik" To: <6lowapp@ietf.org>, X-OriginalArrivalTime: 09 Mar 2010 13:34:47.0740 (UTC) FILETIME=[49785FC0:01CABF8D] X-Brightmail-Tracker: AAAAAA== Subject: [core] draft-struik-6lowapp-security-considerations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 13:34:47 -0000 RGVhciBjb2xsZWFndWVzOg0KDQpGWUkgLSBJIHBvc3RlZCBhIGxpdHRsZSB1cGRhdGUgdG8gbXkg cHJldmlvdXMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZG9jdW1lbnQuDQoNCkJlc3QgcmVnYXJk cywgUmVuZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3Vi bWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IE1vbmRh eSwgTWFyY2ggMDgsIDIwMTAgNzo1NiBQTQ0KVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K Q2M6IFJlbmUgU3RydWlrDQpTdWJqZWN0OiBNYW51YWwgUG9zdCBSZXF1ZXN0ZWQgZm9yIGRyYWZ0 LXN0cnVpay02bG93YXBwLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25zIA0KDQpNYW51YWwgUG9zdGlu ZyBSZXF1ZXN0ZWQgZm9yIGZvbGxvd2luZyBJbnRlcm5ldC1EcmFmdDoNCg0KSS1EIFN1Ym1pc3Np b24gVG9vbCBVUkw6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaWRzdC9zdGF0dXMuY2dp P3N1Ym1pc3Npb25faWQ9MjI3OTANCg0KDQpGaWxlbmFtZToJICAgZHJhZnQtc3RydWlrLTZsb3dh cHAtc2VjdXJpdHktY29uc2lkZXJhdGlvbnMNClZlcnNpb246CSAgIDAxDQpTdGFnaW5nIFVSTDoJ ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zdGFnaW5nL2RyYWZ0LXN0cnVpay02bG93YXBwLXNlY3Vy aXR5LWNvbnNpZGVyYXRpb25zLTAxLnR4dA0KVGl0bGU6CQkgICBTZWN1cml0eSBBcmNoaXRlY3R1 cmFsIERlc2lnbiBDb25zaWRlcmF0aW9ucyBmb3IgTG93LVBvd2VyIFdpcmVsZXNzIFNlbnNvciBO ZXR3b3Jrcw0KQ3JlYXRpb25fZGF0ZToJICAgMjAxMC0wMy0wOA0KV0cgSUQ6CQkgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCk51bWJlcl9vZl9wYWdlczogMzINCkFic3RyYWN0Og0KV2UgZGlzY3Vz cyBzZWN1cml0eSBhcmNoaXRlY3R1cmFsIGRlc2lnbiBjb25zaWRlcmF0aW9ucyBmb3INCiAgZ2Vu ZXJhbC1wdXJwb3NlIG11bHRpLWhvcCBhZC1ob2MgbmV0d29ya3MuIFRoZSBzZWN1cml0eQ0KICBh cmNoaXRlY3R1cmUgZml0cyBleHRyZW1lbHkgY29uc3RyYWluZWQgd2lyZWxlc3MgZW52aXJvbm1l bnRzLA0KICBzdWNoIGFzIHNlbnNvciBuZXR3b3Jrcywgd2hpbGUgcmVtYWluaW5nIHVuaWZvcm0g YW5kIGdlbmVyYWwNCiAgZW5vdWdoIHRvIGZpdCBhbnkgd2lyZWxlc3MgbmV0d29yay4gVGhlIGRl c2lnbiBpcyB0YWlsb3JlZCB0b3dhcmRzDQogIGxvdyBvdmVyYWxsIGltcGxlbWVudGF0aW9uIGNv c3QsIHN1cHBvcnRzIHNlbWktYXV0b21hdGljIGxpZmVjeWNsZQ0KICBtYW5hZ2VtZW50LCBpbmNs dWRpbmcgZWFzZSBvZiBpbnN0YWxsYXRpb24gYW5kIGNvbmZpZ3VyYXRpb24sDQogIHNjYWxhYmls aXR5LCBzdXJ2aXZhYmlsaXR5LCBtb2JpbGl0eSwgYW5kIGlzIGFkYXB0YWJsZSB0b3dhcmRzDQog IG5ldHdvcmsgdG9wb2xvZ3kgY2hhbmdlcyBhbmQgdG93YXJkcyBkaWZmZXJlbnQgdHJ1c3QgbW9k ZWxzDQogIHVuZGVybHlpbmcgbmV0d29yayBvcGVyYXRpb25zLg0KDQpTdWJtaXR0ZXI6IFJlbmUg U3RydWlrIChyc3RydWlrQGNlcnRpY29tLmNvbSkNCg== From root@core3.amsl.com Tue Mar 9 11:00:02 2010 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1DDDF3A690C; Tue, 9 Mar 2010 11:00:02 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100309190002.1DDDF3A690C@core3.amsl.com> Date: Tue, 9 Mar 2010 11:00:02 -0800 (PST) Cc: core@ietf.org Subject: [core] WG Action: Constrained RESTful Environments (core) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 19:00:02 -0000 A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. Constrained RESTful Environments (core) ---------------------------------------- Last Modified: 2010-03-09 Chair(s): Cullen Jennings Carsten Bormann Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Archive: http://www.ietf.org/mail-archive/web/core/current/maillist.html Description of Working Group: CoRE is providing a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node. More generally, we speak of constrained networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have subscribed to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the WG.) As part of the framework for building these applications, the WG will define a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP will be designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. CoAP targets the type of operating environments defined in the ROLL and 6LOWPAN working groups which have additional constraints compared to normal IP networks, but the CoAP protocol will also operate over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. The WG will define a mapping from CoAP to an HTTP REST API; this mapping will not depend on a specific application. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the unconstrained network. CoAP will support various forms of "caching". For example, if a temperature sensor is normally asleep but wakes up every five minutes and sends the current temperature to a proxy that has subscribed, when the proxy receives a request over HTTP for that temperature resource, it can respond with the last seen value instead of trying to query the Device which is currently asleep. The initial work item of the WG is to define a protocol specification for CoAP that includes: 1) The ability to create, read, update and delete a Resource on a Device. 2) The ability to allow a Device to publish a value or event to another Device that has subscribed to be notified of changes, as well as the way for a Device to subscribe to receive publishes from another Device. 3) The ability to support a non-reliable multicast message to be sent to a group of Devices to manipulate a resource on all the Devices in the group. 4) The core CoAP functionality MUST operate well over UDP and UDP MUST be implemented on CoAP Devices. There may be OPTIONAL functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. Applications which require the optional TCP features will limit themselves to a narrower subset of deployment cases. 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. 6) Specification for the HTTP REST based API and translation to communicate with Devices. Translation should make use of Device description information and should not need code updates to deal with new Devices. 7) Consider operational and manageability aspects of the protocol and at a minimum provide a way to tell if a Device is powered on or not. The working group will not develop a reliable multicast solution, and will not develop a general service discovery solution. There is a desire for discovery and configuration features, but the working group has not yet closed in on an specific approach. Thus, the WG may explore these topics and adopt drafts that define requirements or set problem statements, but will not adopt implementable specifications without a recharter. Security, particularly keying of new Devices, is very challenging for these applications. The WG will work to select approaches to security bootstrapping which are realistic given the constraints and requirements of the network. To ensure that any two nodes can join together, all nodes must implement at least one universal bootstrapping method. Security can be achieved using either session security or object security. For both object and session security, the WG will work with the security area to select appropriate security framework and protocol as well as selecting a minimal required to implement cipher suite. CoAP will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. The WG will coordinate on requirements from many organizations including OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, ASHRAE/BACnet; other SDOs and organizations. The WG will closely coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate groups in the IETF OPS and Security areas. Goals and Milestones: Apr 2010 Select WG document for basis of the CoAP protocol Dec 2010 CoAP protocol specification with mapping to HTTP Rest API submitted to IESG as PS Dec 2010 Constrained security bootstrapping specification submitted to IESG as PS Jan 2011 Recharter to add things reduced out of initial scope From zach@sensinode.com Tue Mar 9 12:29:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D97D3A69AC; Tue, 9 Mar 2010 12:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDp5ZrMNyKOR; Tue, 9 Mar 2010 12:29:24 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id AA04B3A69C2; Tue, 9 Mar 2010 12:29:23 -0800 (PST) Received: from [192.168.1.2] (line-6937.dyn.kponet.fi [85.29.73.115]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o29KTMO4001169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Mar 2010 22:29:23 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <20100309190002.1DDDF3A690C@core3.amsl.com> Date: Tue, 9 Mar 2010 22:29:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71D3564A-D77E-4653-80C7-635901B20469@sensinode.com> References: <20100309190002.1DDDF3A690C@core3.amsl.com> To: IESG Secretary X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org, ietf-announce@ietf.org Subject: Re: [core] WG Action: Constrained RESTful Environments (core) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 20:29:29 -0000 Awesome! Congratulations everyone, looking forward to the first WG = meeting in Anaheim.=20 Zach On Mar 9, 2010, at 21:00 , IESG Secretary wrote: > A new IETF working group has been formed in the Applications Area. = For > additional information, please contact the Area Directors or the WG > Chairs. >=20 > Constrained RESTful Environments (core) > ---------------------------------------- > Last Modified: 2010-03-09 >=20 > Chair(s): >=20 > Cullen Jennings > Carsten Bormann >=20 > Applications Area Director(s): >=20 > Lisa Dusseault > Alexey Melnikov >=20 > Applications Area Advisor: >=20 > Lisa Dusseault >=20 > Mailing Lists: >=20 > General Discussion: core@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/core > Archive: = http://www.ietf.org/mail-archive/web/core/current/maillist.html >=20 > Description of Working Group: >=20 > CoRE is providing a framework for resource-oriented applications > intended to run on constrained IP networks. A constrained IP network > has limited packet sizes, may exhibit a high degree of packet loss, = and > may have a substantial number of devices that may be powered off at = any > point in time but periodically "wake up" for brief periods of time. > These networks and the nodes within them are characterized by severe > limits on throughput, available power, and particularly on the > complexity that can be supported with limited code size and limited = RAM > per node. More generally, we speak of constrained networks whenever at > least some of the nodes and networks involved exhibit these > characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) > are an example of this type of network. Constrained networks can occur > as part of home and building automation, energy management, and the > Internet of Things. >=20 > The CoRE working group will define a framework for a limited class of > applications: those that deal with the manipulation of simple = resources > on constrained networks. This includes applications to monitor simple > sensors (e.g. temperature sensors, light switches, and power meters), = to > control actuators (e.g. light switches, heating controllers, and door > locks), and to manage devices. >=20 > The general architecture consists of nodes on the constrained network, > called Devices, that are responsible for one or more Resources that = may > represent sensors, actuators, combinations of values or other > information. Devices send messages to change and query resources on > other Devices. Devices can send notifications about changed resource > values to Devices that have subscribed to receive notification about > changes. A Device can also publish or be queried about its > resources. (Typically a single physical host on the network would have > just one Device but a host might represent multiple logical Devices. > The specific terminology to be used here is to be decided by the WG.) > As part of the framework for building these applications, the WG will > define a Constrained Application Protocol (CoAP) for the manipulation = of > Resources on a Device. >=20 > CoAP will be designed for use between Devices on the same constrained > network, between Devices and general nodes on the Internet, and = between > Devices on different constrained networks both joined by an > internet. CoAP targets the type of operating environments defined in = the > ROLL and 6LOWPAN working groups which have additional constraints > compared to normal IP networks, but the CoAP protocol will also = operate > over traditional IP networks. >=20 > There also may be proxies that interconnect between other Internet > protocols and the Devices using the CoAP protocol. The WG will define = a > mapping from CoAP to an HTTP REST API; this mapping will not depend on = a > specific application. It is worth noting that proxy does not have to > occur at the boundary between the constrained network and the more > general network, but can be deployed at various locations in the > unconstrained network. >=20 > CoAP will support various forms of "caching". For example, if a > temperature sensor is normally asleep but wakes up every five minutes > and sends the current temperature to a proxy that has subscribed, when > the proxy receives a request over HTTP for that temperature resource, = it > can respond with the last seen value instead of trying to query the > Device which is currently asleep. >=20 > The initial work item of the WG is to define a protocol specification > for CoAP that includes: >=20 > 1) The ability to create, read, update and delete a Resource on a > Device. >=20 > 2) The ability to allow a Device to publish a value or event to = another > Device that has subscribed to be notified of changes, as well as the > way for a Device to subscribe to receive publishes from another > Device. >=20 > 3) The ability to support a non-reliable multicast message to be sent = to > a group of Devices to manipulate a resource on all the Devices in the > group. >=20 > 4) The core CoAP functionality MUST operate well over UDP and UDP MUST > be implemented on CoAP Devices. There may be OPTIONAL functions in > CoAP (e.g. delivery of larger chunks of data) which if implemented are > implemented over TCP. Applications which require the optional TCP > features will limit themselves to a narrower subset of deployment > cases. >=20 > 5) A definition of how to use CoAP to advertise about or query for a > Device's description. This description may include the device name and > a list of its Resources, each with a URL, an interface description URI > (pointing e.g. to a Web Application Description Language (WADL) > document) and an optional name or identifier. The name taxonomy used > for this description will be consistent with other IETF work, > e.g. draft-cheshire-dnsext-dns-sd. >=20 > 6) Specification for the HTTP REST based API and translation to > communicate with Devices. Translation should make use of Device > description information and should not need code updates to deal with > new Devices. >=20 > 7) Consider operational and manageability aspects of the protocol and = at > a minimum provide a way to tell if a Device is powered on or not. >=20 > The working group will not develop a reliable multicast solution, and > will not develop a general service discovery solution. There is a = desire > for discovery and configuration features, but the working group has = not > yet closed in on an specific approach. Thus, the WG may explore these > topics and adopt drafts that define requirements or set problem > statements, but will not adopt implementable specifications without a > recharter. >=20 > Security, particularly keying of new Devices, is very challenging for > these applications. The WG will work to select approaches to security > bootstrapping which are realistic given the constraints and = requirements > of the network. To ensure that any two nodes can join together, all > nodes must implement at least one universal bootstrapping method. >=20 > Security can be achieved using either session security or object > security. For both object and session security, the WG will work with > the security area to select appropriate security framework and = protocol > as well as selecting a minimal required to implement cipher suite. = CoAP > will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. >=20 > The WG will coordinate on requirements from many organizations = including > OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, > ASHRAE/BACnet; other SDOs and organizations. The WG will closely > coordinate with other IETF WGs including ROLL, 6LoWPAN, and = appropriate > groups in the IETF OPS and Security areas. >=20 > Goals and Milestones: >=20 > Apr 2010 Select WG document for basis of the CoAP protocol > Dec 2010 CoAP protocol specification with mapping to HTTP Rest API > submitted to IESG as PS > Dec 2010 Constrained security bootstrapping specification submitted to > IESG as PS > Jan 2011 Recharter to add things reduced out of initial scope > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From cabo@tzi.org Tue Mar 9 13:11:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C947A3A69BD for ; Tue, 9 Mar 2010 13:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBrZsGAbBNiT for ; Tue, 9 Mar 2010 13:11:44 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D03333A68F7 for ; Tue, 9 Mar 2010 13:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o29LBepU020374 for ; Tue, 9 Mar 2010 22:11:40 +0100 (CET) Received: from [192.168.10.109] (bl8-111-5.dsl.telepac.pt [85.241.111.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C1245E3FD; Tue, 9 Mar 2010 22:11:39 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Carsten Bormann Date: Tue, 9 Mar 2010 21:56:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1AC38661-947E-435E-A5A7-2E854A280DE4@tzi.org> References: <20100309202558.ABDD13A69AC@core3.amsl.com> To: core@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [core] Fwd: CORE - Requested session has been scheduled for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 21:11:45 -0000 As has been announced to the new core@ietf.org WG, the CORE WG has been = officially created. Thanks to all contributors for the enormous amount of input we got in = the BOF stage! What used to be a 6lowapp BOF session in Anaheim now officially is a WG = meeting: > CORE Session 1 (2.5 hours) > Thursday, Morning Session I 0900-1130 > Room Name: California C I'm in the process of putting together the session agenda, so if you = haven't put in your request under the name "6lowapp", please do now by = mailing the chairs. (I apologize if I'm a bit slow *answering* mail -- I have only limited = e-mail access during my vacation, but I will answer.) Please remember that a WG meeting has very limited time, so please do = indicate the time needed and the objective you want the WG to achieve in = the discussion -- "presenting a draft" is rarely a useful objective. I would also like to point to the 6LoWPAN and ROLL meetings on Monday, = so I expect to see quite a few informal hallway meetings during the IETF = week that we will be able to capitalize on. Gruesse aus Madeira, Carsten From fluffy@cisco.com Wed Mar 10 14:22:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C263A69BD for ; Wed, 10 Mar 2010 14:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz6BDsH4QEON for ; Wed, 10 Mar 2010 14:22:34 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D10423A68C6 for ; Wed, 10 Mar 2010 14:22:33 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJOql0urR7Ht/2dsb2JhbACaVnOjBZhPhHkEgxc X-IronPort-AV: E=Sophos;i="4.49,616,1262563200"; d="scan'208";a="245882994" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 10 Mar 2010 22:22:39 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2AMMc56004135; Wed, 10 Mar 2010 22:22:38 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings Date: Wed, 10 Mar 2010 15:22:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> To: core@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 22:22:35 -0000 Hi All,=20 Carsten and I are starting to put together the Agenda for our first = meeting. Below if the rough draft proposal and is highly likely to = change but we need input from the group. Are there other things that = need discussion time? What are the hot topics that we need to sort out? = Drop us some email and let us know how to make a great first meeting.=20 Thanks, Cullen Agenda CORE WG=20 IETF-77, Anaheim, CA, USA ----------------------------------- DRAFT Agenda created March 10 Time: Thursday, Mar 25, 9:00 to 11:30 Chairs: Carsten Bormann Cullen Jennings Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Wiki & Status:=20 http://tools.ietf.org/wg/core/ Agenda Bash and Status (Chairs 10 min) - Note takers - Jabber Scribes CoAP requirements and protocol proposal (Zach Shelby 50 min) draft-shelby-core-coap-req-00.txt draft-shelby-core-coap-00.txt Bootstrap discussion (Colin Oflynn 30 min) draft-oflynn-core-bootstrapping-00 Compressed IPfix (Lothar Braun 30 min) draft-braun-core-compressed-ipfix-01.txt Other Topics (Working Group 30 min) From d.sturek@att.net Wed Mar 10 14:40:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4863A6819 for ; Wed, 10 Mar 2010 14:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3b2-XNTs3hc for ; Wed, 10 Mar 2010 14:40:20 -0800 (PST) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id A9AE13A6812 for ; Wed, 10 Mar 2010 14:40:17 -0800 (PST) Received: (qmail 3191 invoked from network); 10 Mar 2010 22:40:20 -0000 Received: from adsl-69-224-122-163.dsl.sndg02.pacbell.net (d.sturek@69.224.122.163 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 10 Mar 2010 14:40:20 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: pxPdGjIVM1k8ygvGL7b2D9wnRHkj5kWkGaeS4StcdCtftB6X88H.JewpaeQxWhRTwRPEdh2k9hqUsvu4SAbJ7_vE50gsmUg0MGZ0Q0eyr0DLQHi8afcIH3XCAKfUdQ9J8yvCwnXo.jNjLDmKz2GDypE5NX6iMwOsMRWAH8a4bJkbXpnvdBrdMkyb6aLBkxgP9SKBxNAFp6Oc5z4wTDbMek6n5BMAKZGB4BqCZc5upaRTZWEGt_5f9qzJr8emxw2iaJlF_HAFJ_Pbqg25T3mapazWFYcuIPLNWINdcwfiQmuWQ6tRxlU- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" , References: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> In-Reply-To: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> Date: Wed, 10 Mar 2010 14:40:18 -0800 Message-ID: <02b601cac0a2$a99c2ce0$fcd486a0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrAoEK1sBdsE4mKSqSssYGvunebIQAAW/8Q Content-Language: en-us Subject: Re: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 22:40:21 -0000 Hi Cullen, Here are a few points that I think need some discussion time in Anaheim: 1) Resource discovery - I spent a good amount of time trying to find something that would work within Smart Energy (looking at SLP, m-DNS, SSDP, even writing an I-D around an optimized SLP). None of these solutions look real attractive "as-is". Can we use some time to re-confirm the requirements for Resource Discovery and either focus some effort in creating an optimized solution or identifying what existing solution we could modify and use? 2) Directory agent/User agent design - This is related to Resource discovery but has to do with caching for sleeping devices (a common problem in constrained environments). Directory agent only solutions are not popular since they add resources to selected devices on the network (whose manufacturers would prefer were cheaper!) while User agent solutions alone don't address caching. It would be nice to find a solution (like m-DNS) where both is possible I think both of these topics could be addressed in Zach's speaking slot given they are part of the original problem statement. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, March 10, 2010 2:23 PM To: core@ietf.org Subject: [core] CORE Draft Agenda for IETF 77 Hi All, Carsten and I are starting to put together the Agenda for our first meeting. Below if the rough draft proposal and is highly likely to change but we need input from the group. Are there other things that need discussion time? What are the hot topics that we need to sort out? Drop us some email and let us know how to make a great first meeting. Thanks, Cullen Agenda CORE WG IETF-77, Anaheim, CA, USA ----------------------------------- DRAFT Agenda created March 10 Time: Thursday, Mar 25, 9:00 to 11:30 Chairs: Carsten Bormann Cullen Jennings Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Wiki & Status: http://tools.ietf.org/wg/core/ Agenda Bash and Status (Chairs 10 min) - Note takers - Jabber Scribes CoAP requirements and protocol proposal (Zach Shelby 50 min) draft-shelby-core-coap-req-00.txt draft-shelby-core-coap-00.txt Bootstrap discussion (Colin Oflynn 30 min) draft-oflynn-core-bootstrapping-00 Compressed IPfix (Lothar Braun 30 min) draft-braun-core-compressed-ipfix-01.txt Other Topics (Working Group 30 min) _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From charles.palmer@onzo.com Wed Mar 10 14:42:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9323A6835 for ; Wed, 10 Mar 2010 14:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Frx4hVvDRLS for ; Wed, 10 Mar 2010 14:42:21 -0800 (PST) Received: from service38.mimecast.com (service38.mimecast.com [212.2.3.166]) by core3.amsl.com (Postfix) with SMTP id B3E243A6819 for ; Wed, 10 Mar 2010 14:42:20 -0800 (PST) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Wed, 10 Mar 2010 22:42:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Mar 2010 22:42:22 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CORE Draft Agenda for IETF 77 Thread-Index: AcrAoDjgJGIHFDpdT6qzKeYobTx2TwAABung References: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> From: "Charles Palmer" To: "Cullen Jennings" , X-MC-Unique: 110031022422400302 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 22:42:22 -0000 Hi Cullen Security? - what is the scope of security within CoRE, and what security topics will be dealt with by others? My group is looking at the extent to which existing security measures that have evolved within the financial services industry (in particular GlobalPlatform on tamper-resistant hardware) could be useful tools for devices such as smart meters where there are valuable assets to protect, and ample opportunities for Malory to access the devices. There seem to be parallels between M2M and smart cards. Would IETF 77 be an opportunity to exchange views? Regards - Charles Palmer=20 Onzo Limited (Project Hydra Project Manager)=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 10 March 2010 22:23 To: core@ietf.org Subject: [core] CORE Draft Agenda for IETF 77 Hi All,=20 Carsten and I are starting to put together the Agenda for our first meeting. Below if the rough draft proposal and is highly likely to change but we need input from the group. Are there other things that need discussion time? What are the hot topics that we need to sort out? Drop us some email and let us know how to make a great first meeting.=20 Thanks, Cullen Agenda CORE WG=20 IETF-77, Anaheim, CA, USA ----------------------------------- DRAFT Agenda created March 10 Time: =09Thursday, Mar 25, 9:00 to 11:30 Chairs: =09Carsten Bormann =09Cullen Jennings Mailing Lists: =09General Discussion: core@ietf.org =09To Subscribe: https://www.ietf.org/mailman/listinfo/core Wiki & Status:=20 =09http://tools.ietf.org/wg/core/ Agenda Bash and Status (Chairs 10 min) =09- Note takers =09- Jabber Scribes CoAP requirements and protocol proposal (Zach Shelby 50 min) =09draft-shelby-core-coap-req-00.txt =09draft-shelby-core-coap-00.txt Bootstrap discussion (Colin Oflynn 30 min) =09draft-oflynn-core-bootstrapping-00 Compressed IPfix (Lothar Braun 30 min) =09draft-braun-core-compressed-ipfix-01.txt Other Topics (Working Group 30 min) _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- From rstruik@certicom.com Wed Mar 10 14:45:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA32D3A6835 for ; Wed, 10 Mar 2010 14:45:32 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2THChROLtBSA for ; Wed, 10 Mar 2010 14:45:32 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id BB54F3A6819 for ; Wed, 10 Mar 2010 14:45:31 -0800 (PST) X-AuditID: 0a401fcb-b7b5cae0000009f8-36-4b98210ff6ba Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id AA.05.02552.F01289B4; Wed, 10 Mar 2010 17:45:35 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 17:45:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2010 17:45:20 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4046E4BDE@XCH57YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CORE Draft Agenda for IETF 77 Thread-Index: AcrAoDjgJGIHFDpdT6qzKeYobTx2TwAABungAACurjA= References: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> From: "Rene Struik" To: "Charles Palmer" , "Cullen Jennings" , X-OriginalArrivalTime: 10 Mar 2010 22:45:35.0674 (UTC) FILETIME=[65FCA9A0:01CAC0A3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 22:45:32 -0000 Hi Charles: The following two drafts may be of interest to you:=20 -draft-struik-6lowapp-security-considerations=20 -draft-oflyn-core-bootstrapping=20 Best regards, Rene -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Charles Palmer Sent: Wednesday, March 10, 2010 5:42 PM To: Cullen Jennings; core@ietf.org Subject: Re: [core] CORE Draft Agenda for IETF 77 Hi Cullen Security? - what is the scope of security within CoRE, and what security topics will be dealt with by others? My group is looking at the extent to which existing security measures that have evolved within the financial services industry (in particular GlobalPlatform on tamper-resistant hardware) could be useful tools for devices such as smart meters where there are valuable assets to protect, and ample opportunities for Malory to access the devices. There seem to be parallels between M2M and smart cards. Would IETF 77 be an opportunity to exchange views? Regards - Charles Palmer=20 Onzo Limited (Project Hydra Project Manager)=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 10 March 2010 22:23 To: core@ietf.org Subject: [core] CORE Draft Agenda for IETF 77 Hi All,=20 Carsten and I are starting to put together the Agenda for our first meeting. Below if the rough draft proposal and is highly likely to change but we need input from the group. Are there other things that need discussion time? What are the hot topics that we need to sort out? Drop us some email and let us know how to make a great first meeting.=20 Thanks, Cullen Agenda CORE WG=20 IETF-77, Anaheim, CA, USA ----------------------------------- DRAFT Agenda created March 10 Time: Thursday, Mar 25, 9:00 to 11:30 Chairs: Carsten Bormann Cullen Jennings Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Wiki & Status:=20 http://tools.ietf.org/wg/core/ Agenda Bash and Status (Chairs 10 min) - Note takers - Jabber Scribes CoAP requirements and protocol proposal (Zach Shelby 50 min) draft-shelby-core-coap-req-00.txt draft-shelby-core-coap-00.txt Bootstrap discussion (Colin Oflynn 30 min) draft-oflynn-core-bootstrapping-00 Compressed IPfix (Lothar Braun 30 min) draft-braun-core-compressed-ipfix-01.txt Other Topics (Working Group 30 min) _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. The =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged information, and is intended solely for the addressee(s). If you have received this email in =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or=20 distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Wed Mar 10 16:48:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A533A6A33 for ; Wed, 10 Mar 2010 16:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIvmoEB5xAaZ for ; Wed, 10 Mar 2010 16:48:18 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D9A8F3A62C1 for ; Wed, 10 Mar 2010 16:48:18 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMrMl0urR7Ht/2dsb2JhbACaV3OjTYsKCY02gk0cghAEgxc X-IronPort-AV: E=Sophos;i="4.49,617,1262563200"; d="scan'208";a="98501553" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 11 Mar 2010 00:48:24 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2B0mNDG006302; Thu, 11 Mar 2010 00:48:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings Date: Wed, 10 Mar 2010 17:48:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <72CA9460-BE57-4744-9E38-182B78E9227F@cisco.com> To: core@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [core] Agenda Requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 00:48:19 -0000 The important part of this email is "There's still time to send in = agenda requests."=20 I realize there might have been some confusion about requesting agenda = time and that's normal as we get a new working group up and going. = Typically we try and use agenda time to resolve technical issues that = have been discussed on the list and need face to face time to get sorted = out. I really shy away from educational sessions about a draft and = assume that everyone who cares has read the drafts on the agenda before = the meeting. We have a lot of time (2.5 hours) this time so I think we = should be able to make some good progress.=20 There's still time to send in agenda requests. Send an email to both = chairs (Carsten and I) and if you were feeling really kind you might set = the subject to something like "Core Agenda Request: your-draft-name" as = that makes it easy to keep track of things. If at all possible, please = get them in the next day or two as this allows us to update the agenda = and make sure that everyone has adequate time to read all the drafts. = Keep in mind some people are reading the drafts for a bunch of WGs so a = week to read them all is not a long time. Its good if the requests = clearly identify the draft being discussed and what the key point you = want to get the working group to decide by discussing the draft as well = as a rough idea of how much time you would like.=20 As you read the drafts, please do start threads on technical issues we = need to resolve on the list. Some times at the early stages of a working = group, there are so many open problems that we can't tackle them all at = once so chairs some times end up sorting them into bins of 1) this will = resolve by itself on the list, no face to face time needed 2) this needs = face to face time and looks like we could make progress 3) no hope of = making progress on this until a bunch of other things get decided so = this gets deferred to later. Do what you can get the mailing list to = focus on the deciding the important things.=20 Chairs mess up at times and the IETF process is really good at = correcting things where the wrong path was taken. If something does not = seem right, drop an email to Carsten and I or if you need a right now = response my mobile is +1 408 421 9990. If chairs don't resolve things, = drop an email to Apps Area Directors and ask them to help.=20 Thanks, Cullen From zach@sensinode.com Thu Mar 11 00:06:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FDA3A6B4B for ; Thu, 11 Mar 2010 00:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFJI-MVU4pW4 for ; Thu, 11 Mar 2010 00:06:45 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2C77B3A6B4D for ; Thu, 11 Mar 2010 00:06:35 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o2B86Wvv018344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Mar 2010 10:06:33 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <02b601cac0a2$a99c2ce0$fcd486a0$@sturek@att.net> Date: Thu, 11 Mar 2010 10:06:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> <02b601cac0a2$a99c2ce0$fcd486a0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 08:06:47 -0000 Hi Don, Sure, I think we should discuss these points during the WG meeting and = I'd be happy to include them in my slot on CoAP. We have a (currently = blank) resource discovery section in the I-D, and need to move forward = on that as a result of Anaheim. Same goes for subscription. There are two issues to be considered there: 1. Discovery of CoAP resources, this is clearly in the charter and could = include both directory agent/user agent models. 2. Pointing to a service discovery technique that should be used in case = you don't even know if/who is running a CoAP service is something we can = do. We can't modify or create a protocol for this without re-chartering. Could I suggest that you help me out with a few slides regarding = resource discovery (1.)? I'll be on vacation for the next week, but = let's do this together in the first days of Anaheim. Zach On Mar 11, 2010, at 0:40 , Don Sturek wrote: > Hi Cullen, >=20 > Here are a few points that I think need some discussion time in = Anaheim: > 1) Resource discovery - I spent a good amount of time trying to find > something that would work within Smart Energy (looking at SLP, m-DNS, = SSDP, > even writing an I-D around an optimized SLP). None of these solutions = look > real attractive "as-is". Can we use some time to re-confirm the > requirements for Resource Discovery and either focus some effort in = creating > an optimized solution or identifying what existing solution we could = modify > and use? > 2) Directory agent/User agent design - This is related to Resource > discovery but has to do with caching for sleeping devices (a common = problem > in constrained environments). Directory agent only solutions are not > popular since they add resources to selected devices on the network = (whose > manufacturers would prefer were cheaper!) while User agent solutions = alone > don't address caching. It would be nice to find a solution (like = m-DNS) > where both is possible >=20 > I think both of these topics could be addressed in Zach's speaking = slot > given they are part of the original problem statement. >=20 > Don >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Cullen Jennings > Sent: Wednesday, March 10, 2010 2:23 PM > To: core@ietf.org > Subject: [core] CORE Draft Agenda for IETF 77 >=20 >=20 > Hi All,=20 >=20 > Carsten and I are starting to put together the Agenda for our first = meeting. > Below if the rough draft proposal and is highly likely to change but = we need > input from the group. Are there other things that need discussion = time? What > are the hot topics that we need to sort out? Drop us some email and = let us > know how to make a great first meeting.=20 >=20 > Thanks, Cullen >=20 >=20 > Agenda CORE WG=20 > IETF-77, Anaheim, CA, USA > ----------------------------------- > DRAFT Agenda created March 10 >=20 > Time: > Thursday, Mar 25, 9:00 to 11:30 >=20 > Chairs: > Carsten Bormann > Cullen Jennings >=20 > Mailing Lists: > General Discussion: core@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/core >=20 > Wiki & Status:=20 > http://tools.ietf.org/wg/core/ >=20 >=20 >=20 > Agenda Bash and Status (Chairs 10 min) > - Note takers > - Jabber Scribes >=20 >=20 > CoAP requirements and protocol proposal (Zach Shelby 50 min) > draft-shelby-core-coap-req-00.txt > draft-shelby-core-coap-00.txt >=20 >=20 > Bootstrap discussion (Colin Oflynn 30 min) > draft-oflynn-core-bootstrapping-00 >=20 >=20 > Compressed IPfix (Lothar Braun 30 min) > draft-braun-core-compressed-ipfix-01.txt >=20 >=20 > Other Topics (Working Group 30 min) >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From jpv@cisco.com Thu Mar 11 04:11:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724413A6888 for ; Thu, 11 Mar 2010 04:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4906FDWnI6l for ; Thu, 11 Mar 2010 04:11:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 80E4C3A6808 for ; Thu, 11 Mar 2010 04:11:14 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAKJsmEuQ/uCWe2dsb2JhbAAumisVAQELCyQGHKMYmGaEegQ X-IronPort-AV: E=Sophos;i="4.49,620,1262563200"; d="scan'208";a="57923517" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2010 12:11:18 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2BCBI1w022288; Thu, 11 Mar 2010 12:11:18 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 13:11:18 +0100 Received: from [64.103.29.99] ([64.103.29.99]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 13:11:18 +0100 Message-Id: <1B4354B1-8850-4995-A0E9-394E4D49F366@cisco.com> From: JP Vasseur To: d.sturek@att.net In-Reply-To: <02b601cac0a2$a99c2ce0$fcd486a0$@sturek@att.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 08:11:02 +0100 References: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> <02b601cac0a2$a99c2ce0$fcd486a0$@sturek@att.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Mar 2010 12:11:18.0270 (UTC) FILETIME=[F46B69E0:01CAC113] Cc: core@ietf.org Subject: Re: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 12:11:16 -0000 Hi, On Mar 10, 2010, at 11:40 PM, Don Sturek wrote: > Hi Cullen, > > Here are a few points that I think need some discussion time in > Anaheim: > 1) Resource discovery - I spent a good amount of time trying to find > something that would work within Smart Energy (looking at SLP, m- > DNS, SSDP, > even writing an I-D around an optimized SLP). None of these > solutions look > real attractive "as-is". Can we use some time to re-confirm the > requirements for Resource Discovery and either focus some effort in > creating > an optimized solution or identifying what existing solution we could > modify > and use? I strongly agree with Don here. Well ... you know this I was pushing to get it in the charter (thanks to the chairs). This is an important topic indeed. > 2) Directory agent/User agent design - This is related to Resource > discovery but has to do with caching for sleeping devices (a common > problem > in constrained environments). Directory agent only solutions are not > popular since they add resources to selected devices on the network > (whose > manufacturers would prefer were cheaper!) while User agent solutions > alone > don't address caching. It would be nice to find a solution (like m- > DNS) > where both is possible Same here. > > I think both of these topics could be addressed in Zach's speaking > slot > given they are part of the original problem statement. > > Don > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of > Cullen Jennings > Sent: Wednesday, March 10, 2010 2:23 PM > To: core@ietf.org > Subject: [core] CORE Draft Agenda for IETF 77 > > > Hi All, > > Carsten and I are starting to put together the Agenda for our first > meeting. > Below if the rough draft proposal and is highly likely to change but > we need > input from the group. Are there other things that need discussion > time? What > are the hot topics that we need to sort out? Drop us some email and > let us > know how to make a great first meeting. > > Thanks, Cullen > > > Agenda CORE WG > IETF-77, Anaheim, CA, USA > ----------------------------------- > DRAFT Agenda created March 10 > > Time: > Thursday, Mar 25, 9:00 to 11:30 > > Chairs: > Carsten Bormann > Cullen Jennings > > Mailing Lists: > General Discussion: core@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/core > > Wiki & Status: > http://tools.ietf.org/wg/core/ > > > > Agenda Bash and Status (Chairs 10 min) > - Note takers > - Jabber Scribes > > > CoAP requirements and protocol proposal (Zach Shelby 50 min) > draft-shelby-core-coap-req-00.txt > draft-shelby-core-coap-00.txt > > > Bootstrap discussion (Colin Oflynn 30 min) > draft-oflynn-core-bootstrapping-00 > > > Compressed IPfix (Lothar Braun 30 min) > draft-braun-core-compressed-ipfix-01.txt > > > Other Topics (Working Group 30 min) > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From dberenguer@usapiens.com Sat Mar 13 12:31:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DFC3A67F9 for ; Sat, 13 Mar 2010 12:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znx++KLIRkxN for ; Sat, 13 Mar 2010 12:31:11 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 113CF3A67A4 for ; Sat, 13 Mar 2010 12:31:10 -0800 (PST) Received: by wwf26 with SMTP id 26so175772wwf.31 for ; Sat, 13 Mar 2010 12:31:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.93.1 with SMTP id k1mr1077735wef.151.1268512274074; Sat, 13 Mar 2010 12:31:14 -0800 (PST) Date: Sat, 13 Mar 2010 21:31:14 +0100 Message-ID: <79fe8d321003131231j70889aafkde1e0d12cbafb8c3@mail.gmail.com> From: Daniel Berenguer To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] How many endpoint values into a single 6LowPAN message? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 20:31:12 -0000 >From the description of the working group: 2) The ability to allow a Device to publish a value or event to another Device that has subscribed to be notified of changes, as well as the way for a Device to subscribe to receive publishes from another Device. I wonder whether the WG is thinking in transporting one value per 6LowPAN message or will try to package several values into a single message. Based on my limited experience, working with simple message/value pairs makes implementations (and integrations within the wireless network) much easier and interoperability is less of a problem. With this simple approach, interoperability would even be possible without the definition of functional profiles, just following a basic data structure in every message. Of course, this is true only for M2M applications but I understand that this is the main goal of the CoAP protocol. Thanks for your work. Daniel. From A01127488@itesm.mx Wed Mar 17 12:18:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9840C3A6A47 for ; Wed, 17 Mar 2010 12:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.966 X-Spam-Level: * X-Spam-Status: No, score=1.966 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MX=0.535, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRvcsf2gnT4A for ; Wed, 17 Mar 2010 12:18:08 -0700 (PDT) Received: from as2b.itesm.mx (as2b.itesm.mx [200.34.203.18]) by core3.amsl.com (Postfix) with ESMTP id AE8B83A6851 for ; Wed, 17 Mar 2010 12:18:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,261,1267423200"; d="scan'208";a="124730506" Received: from [10.49.157.64] by itesm.mx with HTTP; Wed, 17 Mar 2010 13:17:52 -0600 Date: Wed, 17 Mar 2010 13:17:52 -0600 Message-ID: <4B668AEF00032A8E@mailserver2.itesm.mx> From: =?iso-8859-1?Q?Patricia=20E=2E=20Figueroa=20Mill=E1n?= To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [core] Chopan and CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: A01127488@itesm.mx List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 19:18:09 -0000 Greetings, I have read the Chopan - Compressed HTTP Over PANs [draft-frank-6lowpan-c= hopan] and Constrained Application Protocol (CoAP) [draft-shelby-core-coap] draf= ts and a question has come up to me. What is the main difference between the= two works? From my point of view, Chopan can deliver the same information= as CoAP. Is this correct? Thanks in advance. Patty Figueroa From rstruik@certicom.com Wed Mar 17 15:20:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92523A6821 for ; Wed, 17 Mar 2010 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK7UveGgX++o for ; Wed, 17 Mar 2010 15:20:19 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 963603A68E8 for ; Wed, 17 Mar 2010 15:20:17 -0700 (PDT) X-AuditID: 0a666446-b7b33ae0000009f9-96-4ba155a1dbfd Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 86.B0.02553.1A551AB4; Wed, 17 Mar 2010 18:20:17 -0400 (EDT) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 18:20:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2010 18:20:14 -0400 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4049AD02A@XCH57YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CORE and draft-struik-6lowapp-security-considerations-00.txt Thread-Index: AcrBMuMJHWu7Z9Y/TVmg3v6UWG0tVAEsbN8QAA6qGtA= From: "Rene Struik" To: "Carsten Bormann" X-OriginalArrivalTime: 17 Mar 2010 22:20:16.0902 (UTC) FILETIME=[059EB260:01CAC620] X-Brightmail-Tracker: AAAAAA== Cc: core@ietf.org Subject: [core] FW: CORE and draft-struik-6lowapp-security-considerations-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 22:20:22 -0000 Dear Carsten, Cullen: I just reviewed the agenda for the 6lowapp meeting at IETF-77 and, to my surprise, noticed that the presentation slot you presumably allocated to me was not there. Please correct. Cell: +1 (416) 433-7880 Best regards, Rene Agenda CORE WG=20 IETF-77, Anaheim, CA, USA ----------------------------------- DRAFT Agenda created March 10 Time: Thursday, Mar 25, 9:00 to 11:30 Chairs: Carsten Bormann Cullen Jennings Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Wiki & Status:=20 http://tools.ietf.org/wg/core/ Agenda Bash and Status (Chairs 10 min) - Note takers - Jabber Scribes CoAP requirements and protocol proposal (Zach Shelby 50 min) draft-shelby-core-coap-req-00.txt draft-shelby-core-coap-00.txt Bootstrap discussion (Colin Oflynn 30 min) draft-oflynn-core-bootstrapping-00 Compressed IPfix (Lothar Braun 30 min) draft-braun-core-compressed-ipfix-01.txt Other Topics (Working Group 30 min) -----Original Message----- From: Rene Struik=20 Sent: Wednesday, March 17, 2010 11:16 AM To: Carsten Bormann Cc: Cullen Jennings; Zach Shelby Subject: RE: CORE and draft-struik-6lowapp-security-considerations-00.txt Any update? -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Thursday, March 11, 2010 10:53 AM To: Rene Struik Subject: Re: CORE and draft-struik-6lowapp-security-considerations-00.txt Rene, sorry for short-changing you again -- I fell ill yesterday and the agenda was made up by Cullen. We'll fix this. Gruesse, Carsten -----Original Message----- From: Rene Struik=20 Sent: Wednesday, March 10, 2010 11:24 PM To: 'fluffy@cisco.com' Cc: 'zach@sensinode.com'; 'cabo@tzi.org' Subject: Re: CORE and draft-struik-6lowapp-security-considerations-00.txt Hi Cullen: The draft (btw - I submitted rev01 this Monday) discusses a security architectural design that encompasses the whole system lifecycle and would apply to 6lowapp, roll, but I wanted to discuss only one aspect of this at the meeting, viz. configuration/provisioning, since that unambiguously falls into the 6lowapp/core realm. Please also note my prior email to Carsten Bormann on this.=20 There may be some opportunity to lift this topic out and to do some joint work with Colin o Flynn, whose bootstrapping doc is a subset of configuration - will have to see, but guess we could collaborate here. Rene Rene Struik Certicom Research Cell: +1 (416) 433-7880 -----Original Message----- From: Rene Struik=20 Sent: Wednesday, March 10, 2010 5:30 PM To: Cullen Jennings; Zach Shelby; Carsten Bormann Subject: RE: [core] CORE Draft Agenda for IETF 77 Hi Cullen: I am somewhat confused as to whom to ask timeslots. I asked Carsten Bormann twice (Tue March 9, 2010; Mon Feb 22, 2009); moreover, I believe I asked the same for the previous IETF-76 meeting (but was not on the agenda). I would be really happy if you would allow me some time to present. Best regards, Rene -----Original Message----- From: Rene Struik=20 Sent: Tuesday, March 09, 2010 5:35 PM To: Carsten Bormann Cc: Zach Shelby Subject: RE: [core] Fwd: CORE - Requested session has been scheduled for IETF 77 Hi Carsten: I would like to discuss security and ease of use topics (provisioning/configuration related) and would like to request a 20-minute timeslot for this. Please also cf. my previous request. Best regards, Rene -----Original Message----- From: Rene Struik=20 Sent: Monday, February 22, 2010 9:31 AM To: Carsten Bormann Subject: RE: [6lowapp] Agenda in Anaheim Hi Carsten: I would potentially (pending travel approval) like to present the 6lowapp draft on security considerations that I posted in October. Best regards, Rene -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, March 10, 2010 5:23 PM To: core@ietf.org Subject: [core] CORE Draft Agenda for IETF 77 Hi All,=20 Carsten and I are starting to put together the Agenda for our first meeting. Below if the rough draft proposal and is highly likely to change but we need input from the group. Are there other things that need discussion time? What are the hot topics that we need to sort out? Drop us some email and let us know how to make a great first meeting.=20 Thanks, Cullen Agenda CORE WG=20 IETF-77, Anaheim, CA, USA ----------------------------------- DRAFT Agenda created March 10 Time: Thursday, Mar 25, 9:00 to 11:30 Chairs: Carsten Bormann Cullen Jennings Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Wiki & Status:=20 http://tools.ietf.org/wg/core/ Agenda Bash and Status (Chairs 10 min) - Note takers - Jabber Scribes CoAP requirements and protocol proposal (Zach Shelby 50 min) draft-shelby-core-coap-req-00.txt draft-shelby-core-coap-00.txt Bootstrap discussion (Colin Oflynn 30 min) draft-oflynn-core-bootstrapping-00 Compressed IPfix (Lothar Braun 30 min) draft-braun-core-compressed-ipfix-01.txt Other Topics (Working Group 30 min) _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From alexey.melnikov@isode.com Thu Mar 18 15:58:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE0F3A6B93 for ; Thu, 18 Mar 2010 15:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3TvY-4IoXzf for ; Thu, 18 Mar 2010 15:58:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4C1D23A6BB6 for ; Thu, 18 Mar 2010 15:58:43 -0700 (PDT) Received: from [192.168.1.128] (c-98-234-189-190.hsd1.ca.comcast.net [98.234.189.190]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 18 Mar 2010 22:58:54 +0000 Message-ID: <4BA2B030.4030709@isode.com> Date: Thu, 18 Mar 2010 22:58:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Comments on draft-shelby-core-coap-req-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 22:58:44 -0000 REQ13: Internet media type and transfer encoding type support. [I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei] Why is support for multiple Content-Transfer-Encodings is needed? Any C-T-E other than 8bit increases size of messages and cost of implementation, which are 2 other requirements mentioned in the document. 2.2. Basic Messages It is assumed that basic Request and Response messages will be required by the CoAP protocol. This also provides a natural mapping to HTTP (See Section 2.10) and the response may be useful as an acknowledgement in UDP reliability (See Section 2.8.1). It can be considered that CoAP methods are different kinds of Request messages, therefore a separate Request message is not needed. I don't understand the last sentence. 2.4. Content-type encoding In order to support hetergenous uses, it is important that CoAP is transparent to the use of different application payloads. In order for the application process receiving a packet to properly parse a payload, its content-type and encoding should be explicitly known from the header (as e.g. with HTTP). The use of typical binary encodings for XML is discussed in [I-D.shelby-6lowapp-encoding], which includes recommendations for header indication. The draft recommends the indication of at least 10 Internet media types (MIME) [RFC2046] and 2 content transfer encodings. As above, I am not convinced that you need to support multiple C-T-E in COAP. It is obvious that string names of Internet media types [RFC2046] are not appropriate for use in the CoAP header. Well, and URIs are Ok why? But then how to make this small yet extensible? One possible solution is to simply assign codes to a small subset of common MIME and content transfer encoding types and have IANA maintain that. A field of 16-bits should be sufficient for encoding both media and content transfer encoding types. For extending some types, magic numbers can also be used from the beginning of the payload (as defined in associated Internet media type RFCs). This could be indicated by a header value something like "See magic numbers". Hmm. The list of MIME types is small and can be easily encoded. It hardly ever changes. I suppose subtypes can be enumerated. If this is going to be an extension to the existing MIME media type registry, I suggest discussing this with Ned Freed and John Klensin. 2.5. URLs The Universal Resource Locator (URL) [RFC3986] is an important feature of the REST architecture, the relative part of the URL indicates which resource on the server is being manipulated. It is surely useful for CoAP to support string URLs, which requires a variable length-value field. Although URLs can be designed for compactness, this still often results in 10s of bytes of overhead. The encoding of the URL string also needs to be considered, as this is becoming increasingly complex. It is recommended that only US- ASCII is supported in URL strings for CoAP as defined in [RFC3986], Basically you are saying that you want URIs, but not IRIs. And RFC 3986 only describes URIs. or even a stricter subset as URL parsing I recommend against putting further restrictions to URIs. URI/IRI/URN are already complex, this will make the UR* world even more complicated. I also don't think that this WG is the right place to define restrictions on URIs. is complex and may result in security problems on constrained devices. This is true. This might mean that URIs is not what you want. But I would be afraid to recommend that you design something new. This task itself might take years. Regards, Alexey From oobles@gmail.com Thu Mar 18 16:01:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E216D3A69F7; Thu, 18 Mar 2010 16:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4pFNnLPDNh2; Thu, 18 Mar 2010 16:01:27 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 1334B3A6952; Thu, 18 Mar 2010 16:01:27 -0700 (PDT) Received: by iwn16 with SMTP id 16so1004112iwn.17 for ; Thu, 18 Mar 2010 16:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fn1/30Xra8nlr/sGKUG/7XuHbn+mQuusH6MqP+G3Dls=; b=Hgc62pMiTEB+/b9fOWpy/D2+GhI38i69g45qdp/g6RgbeNnS1OzFurxYmSUaUpGgeQ unqC4GUdF/yo1K7Tu1xRNegg81SCZ/LD2kaRJvhfxxZIGddb4KfMrtpQs0Rv4AFwXVep 6eypp/wSc2MALtOQEgjQ5nn1gAc99BINgt+pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qmBPW4dtX38Ujh/NxjBInsBmWRmJHFjfMWyUX3pHR4/a6Tj7cd1VYioFetWLkVzlki AkSgIrSe1vBgKC5ftirxFxTLrDXB8lnOuPLbuiSvWzZWPwdRdjZvJ2ZL/MH1yGnta+TO MOrhWDj8xuKAsqW+cbthe302ChcRcUM77vbkE= MIME-Version: 1.0 Received: by 10.231.160.149 with SMTP id n21mr979902ibx.93.1268953295625; Thu, 18 Mar 2010 16:01:35 -0700 (PDT) In-Reply-To: <489285BF-8B4B-45E2-B0F9-625CCC45FA21@sensinode.com> References: <20100301212435.28BDD28C1B5@core3.amsl.com> <489285BF-8B4B-45E2-B0F9-625CCC45FA21@sensinode.com> Date: Fri, 19 Mar 2010 10:01:35 +1100 Message-ID: <7f996c491003181601q6ccbc89tdaffbe4ec12e2e10@mail.gmail.com> From: David Ryan To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org, 6LoWAPP <6lowapp@ietf.org> Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-coap-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 23:01:29 -0000 Hi All, I sent the following questions and feedback to Brian and Zach who suggested I forward this to the list for further discussion. I won't be at the meeting in Anaheim next week, so here's my input. First off, a question regarding the compression of the protocol. You've managed to compress the header into 4 bytes. Obviously the size of the header is going to be important. In the priority list of features, is this the most important? Would another byte or two hurt? I notice between Chopan and COAP you've dropped the magic number headers. This must have been a conscious decision. I would have liked to see a one byte magic value to identify the packet or TCP stream. This would at least give a server a chance to throw away the request if it receives a bad message. In regard to version. Two bits only leaves four possible versions. Extending this to 4 bits would at least extend this to 16 versions. This goes back to the original point regarding size of header. Back in 2008 I did a thought experiment on a binary REST based protocol. Details available at: http://blog.livemedia.com.au/search?updated-min=3D2008-01-01T00%3A00%3A00%2= B11%3A00&updated-max=3D2009-01-01T00%3A00%3A00%2B11%3A00&max-results=3D7 Many of the elements are not applicable to COAP, but there might be one or two features I developed which could be worth discussing. One element of this through experiment was to include a "slotsAvailable" in the response. As the "transactionid" field allows multiple requests to be sent to a single recipient, the "slotsAvailable" in the response allows a client to limit the number of requests sent. I'd suggest 4 bits in the response. If the server can handle more than 16 requests it can return 16 in all responses. A small device might return 1 at all times. Another concept I thought about was to have a bit field for protocol features. This may not be applicable in this case, however, something to put on the back burner. The idea is that a small device might only respond to a limited set of features (or options). A bit field can be used to identify in the request which features are being used and in the response what features the server can handle. I was also surprised that the protocol doesn't include the URI path in the main part of the header. I must admit I'm still trying to understand how the index based approach to URI paths will work in your proposal. I tried taking your proposal and combined it with a few of the above changes and came up with the following: Packet preamble/magic (1 byte) version (4 bits) features (4 bits) response (1 bit) options (1 bit) asynchronous (1 bit) locationType (1 bit) (0 URI location field enabled, 1 location specified in options) method/slots (4 bits) (method type in request/slots available in respons= e) transactionId (16 bits) location (URI location if locationType 0) options length (8 bits - length) ... options ... payload length (variable length int) ...payload data... The base header in this case is 5 bytes instead of the 4 bytes. I also suggested that the number of options is at the start of the options list. This allows the server to quickly decide if the packet can be handled and all the option list can be processed. In a constrained device only a selected number of options could be processed. This removes the need for the 0 byte end of options byte. I have also used a variable length integer for the payload. This is to allow the protocol to move to TCP with larger packets. Regards, David. On Tue, Mar 2, 2010 at 8:30 AM, Zach Shelby wrote: > http://www.ietf.org/id/draft-shelby-core-coap-00.txt > > Here is a very early draft of a CoAP protocol specification based on the = requirements and initial ideas formulated in draft-shelby-core-coap-req-00 = and the previous work by Brian in draft-frank-6lowapp-chopan. Looking forwa= rd to lots of good discussion around CoAP, and as you can see from all the = TODOs and TBDs - lots of WG stuff to do here! > > At the same time I'd like to request a time-slot to present this in Anahe= im. > > Zach > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: March 1, 2010 23:24:35 GMT+02:00 >> To: zach@sensinode.com >> Cc: brian.tridium@gmail.com >> Subject: New Version Notification for draft-shelby-core-coap-00 >> >> >> A new version of I-D, draft-shelby-core-coap-00.txt has been successfuly= submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0draft-shelby-core-coap >> Revision: =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Constrained Application Protocol = (CoAP) >> Creation_date: =A0 =A0 =A0 =A0 2010-03-01 >> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Independent Submission >> Number_of_pages: 17 >> >> Abstract: >> This document specifies the Constrained Application Protocol (CoAP), >> a RESTful protocol for use with constrained networks and nodes. =A0CoAP >> 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. >> >> > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain le= gally privileged information. If you are not the intended recipient, please= contact the sender and delete the e-mail from your system without producin= g, distributing or retaining copies thereof. > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From fluffy@cisco.com Fri Mar 19 17:21:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2383A65A6 for ; Fri, 19 Mar 2010 17:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.491 X-Spam-Level: X-Spam-Status: No, score=-108.491 tagged_above=-999 required=5 tests=[AWL=-1.622, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbt1yIstj5Nx for ; Fri, 19 Mar 2010 17:21:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4C2C13A67B2 for ; Fri, 19 Mar 2010 17:21:48 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEOyo0urRN+K/2dsb2JhbACbPnOiPJkIAoJSgigEgx0 X-IronPort-AV: E=Sophos;i="4.51,277,1267401600"; d="scan'208";a="499759304" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2010 00:22:02 +0000 Received: from sjc-vpn3-385.cisco.com (sjc-vpn3-385.cisco.com [10.21.65.129]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2K0M2MJ020357; Sat, 20 Mar 2010 00:22:02 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 19 Mar 2010 17:22:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70AF9402-C10B-473C-8508-2483513ED961@cisco.com> References: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> To: Charles Palmer X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 00:21:51 -0000 Hi, For the most part, you don't hear many discussions about physical = security or tamper resistant hardware at IETF. Mostly IETF leaves that = to other groups... That said, as this early stage in a WG I, imagine = the implications of this have some relevance to the security work this = group is doing. I should point out I'm not one of the IETF security = people so not aware of all the stuff going on. I suspect you would find = some people with plenty of knowledge and/or interest in this at IETF but = it's not a main focus of any IETF work. Hope that helps, Cullen =20 On Mar 10, 2010, at 14:42 , Charles Palmer wrote: > Hi Cullen >=20 > Security? - what is the scope of security within CoRE, and what = security > topics will be dealt with by others? >=20 > My group is looking at the extent to which existing security measures > that have evolved within the financial services industry (in = particular > GlobalPlatform on tamper-resistant hardware) could be useful tools for > devices such as smart meters where there are valuable assets to = protect, > and ample opportunities for Malory to access the devices. There seem = to > be parallels between M2M and smart cards. Would IETF 77 be an > opportunity to exchange views? >=20 > Regards - Charles Palmer=20 > Onzo Limited (Project Hydra Project Manager)=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Cullen Jennings > Sent: 10 March 2010 22:23 > To: core@ietf.org > Subject: [core] CORE Draft Agenda for IETF 77 >=20 >=20 > Hi All,=20 >=20 > Carsten and I are starting to put together the Agenda for our first > meeting. Below if the rough draft proposal and is highly likely to > change but we need input from the group. Are there other things that > need discussion time? What are the hot topics that we need to sort = out? > Drop us some email and let us know how to make a great first meeting.=20= >=20 > Thanks, Cullen >=20 >=20 > Agenda CORE WG=20 > IETF-77, Anaheim, CA, USA > ----------------------------------- > DRAFT Agenda created March 10 >=20 > Time: > Thursday, Mar 25, 9:00 to 11:30 >=20 > Chairs: > Carsten Bormann > Cullen Jennings >=20 > Mailing Lists: > General Discussion: core@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/core >=20 > Wiki & Status:=20 > http://tools.ietf.org/wg/core/ >=20 >=20 >=20 > Agenda Bash and Status (Chairs 10 min) > - Note takers > - Jabber Scribes >=20 >=20 > CoAP requirements and protocol proposal (Zach Shelby 50 min) > draft-shelby-core-coap-req-00.txt > draft-shelby-core-coap-00.txt >=20 >=20 > Bootstrap discussion (Colin Oflynn 30 min) > draft-oflynn-core-bootstrapping-00 >=20 >=20 > Compressed IPfix (Lothar Braun 30 min) > draft-braun-core-compressed-ipfix-01.txt >=20 >=20 > Other Topics (Working Group 30 min) >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > -------------------------------- > Onzo is a limited company number 06097997 registered in England & = Wales. The =20 > registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >=20 > This email message may contain confidential and/or privileged = information, and > is intended solely for the addressee(s). If you have received this = email in =20 > error, please notify Onzo immediately. Unauthorised copying, = disclosure or=20 > distribution of the material in this email is forbidden. > -------------------------------- >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Fri Mar 19 17:30:02 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BA93A672E for ; Fri, 19 Mar 2010 17:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.663 X-Spam-Level: X-Spam-Status: No, score=-109.663 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3kukwVD466Y for ; Fri, 19 Mar 2010 17:29:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 795213A685B for ; Fri, 19 Mar 2010 17:29:58 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOezo0urR7Hu/2dsb2JhbACbPnOiMpkIhHwEgx0 X-IronPort-AV: E=Sophos;i="4.51,277,1267401600"; d="scan'208";a="103151549" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2010 00:30:12 +0000 Received: from sjc-vpn3-385.cisco.com (sjc-vpn3-385.cisco.com [10.21.65.129]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2K0UCwM028875; Sat, 20 Mar 2010 00:30:12 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 19 Mar 2010 17:30:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A0ED748-26E8-4F09-9C17-DE85E67F23B3@cisco.com> <02b601cac0a2$a99c2ce0$fcd486a0$@sturek@att.net> To: Zach Shelby X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] CORE Draft Agenda for IETF 77 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 00:30:02 -0000 This is clearly a topic where we need some more discussion. Zach, Don, = can the two of you decide how best to run the discussion? If it makes = sense for both of you to present, let me know. I'll assume this is in = the slot where Zach is speaking right now. If we need to add a bit more = time to this slot, I think we can do this.=20 I'll have a new agenda up tomorrow.=20 On Mar 11, 2010, at 24:06 , Zach Shelby wrote: > Hi Don, >=20 > Sure, I think we should discuss these points during the WG meeting and = I'd be happy to include them in my slot on CoAP. We have a (currently = blank) resource discovery section in the I-D, and need to move forward = on that as a result of Anaheim. Same goes for subscription. >=20 > There are two issues to be considered there: > 1. Discovery of CoAP resources, this is clearly in the charter and = could include both directory agent/user agent models. > 2. Pointing to a service discovery technique that should be used in = case you don't even know if/who is running a CoAP service is something = we can do. We can't modify or create a protocol for this without = re-chartering. >=20 > Could I suggest that you help me out with a few slides regarding = resource discovery (1.)? I'll be on vacation for the next week, but = let's do this together in the first days of Anaheim. >=20 > Zach >=20 > On Mar 11, 2010, at 0:40 , Don Sturek wrote: >=20 >> Hi Cullen, >>=20 >> Here are a few points that I think need some discussion time in = Anaheim: >> 1) Resource discovery - I spent a good amount of time trying to find >> something that would work within Smart Energy (looking at SLP, m-DNS, = SSDP, >> even writing an I-D around an optimized SLP). None of these = solutions look >> real attractive "as-is". Can we use some time to re-confirm the >> requirements for Resource Discovery and either focus some effort in = creating >> an optimized solution or identifying what existing solution we could = modify >> and use? >> 2) Directory agent/User agent design - This is related to Resource >> discovery but has to do with caching for sleeping devices (a common = problem >> in constrained environments). Directory agent only solutions are not >> popular since they add resources to selected devices on the network = (whose >> manufacturers would prefer were cheaper!) while User agent solutions = alone >> don't address caching. It would be nice to find a solution (like = m-DNS) >> where both is possible >>=20 >> I think both of these topics could be addressed in Zach's speaking = slot >> given they are part of the original problem statement. >>=20 >> Don >>=20 >>=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >> Cullen Jennings >> Sent: Wednesday, March 10, 2010 2:23 PM >> To: core@ietf.org >> Subject: [core] CORE Draft Agenda for IETF 77 >>=20 >>=20 >> Hi All,=20 >>=20 >> Carsten and I are starting to put together the Agenda for our first = meeting. >> Below if the rough draft proposal and is highly likely to change but = we need >> input from the group. Are there other things that need discussion = time? What >> are the hot topics that we need to sort out? Drop us some email and = let us >> know how to make a great first meeting.=20 >>=20 >> Thanks, Cullen >>=20 >>=20 >> Agenda CORE WG=20 >> IETF-77, Anaheim, CA, USA >> ----------------------------------- >> DRAFT Agenda created March 10 >>=20 >> Time: >> Thursday, Mar 25, 9:00 to 11:30 >>=20 >> Chairs: >> Carsten Bormann >> Cullen Jennings >>=20 >> Mailing Lists: >> General Discussion: core@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/core >>=20 >> Wiki & Status:=20 >> http://tools.ietf.org/wg/core/ >>=20 >>=20 >>=20 >> Agenda Bash and Status (Chairs 10 min) >> - Note takers >> - Jabber Scribes >>=20 >>=20 >> CoAP requirements and protocol proposal (Zach Shelby 50 min) >> draft-shelby-core-coap-req-00.txt >> draft-shelby-core-coap-00.txt >>=20 >>=20 >> Bootstrap discussion (Colin Oflynn 30 min) >> draft-oflynn-core-bootstrapping-00 >>=20 >>=20 >> Compressed IPfix (Lothar Braun 30 min) >> draft-braun-core-compressed-ipfix-01.txt >>=20 >>=20 >> Other Topics (Working Group 30 min) >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" > Mobile: +358 40 7796297 >=20 > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND >=20 > This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 >=20 >=20 >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Fri Mar 19 17:42:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E3B3A6888 for ; Fri, 19 Mar 2010 17:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.66 X-Spam-Level: X-Spam-Status: No, score=-109.66 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E4NtQo1vUUj for ; Fri, 19 Mar 2010 17:42:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C247A3A672E for ; Fri, 19 Mar 2010 17:42:48 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGu3o0urR7H+/2dsb2JhbACbPnOiKYsUCY1rgmmCEwSDHQ X-IronPort-AV: E=Sophos;i="4.51,277,1267401600"; d="scan'208";a="103155302" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2010 00:43:02 +0000 Received: from sjc-vpn3-385.cisco.com (sjc-vpn3-385.cisco.com [10.21.65.129]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2K0h2Kg022711; Sat, 20 Mar 2010 00:43:02 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC4049AD02A@XCH57YKF.rim.net> Date: Fri, 19 Mar 2010 17:43:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89398737-3CB4-429A-829E-7BA2A709BCB9@cisco.com> References: <7E1DF37F1F42AB4E877E492C308E6AC4049AD02A@XCH57YKF.rim.net> To: Rene Struik X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] CORE and draft-struik-6lowapp-security-considerations-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 00:42:49 -0000 Ah, It's my fault Rene. I had it on my todo list for a week to go fix = this part of the agenda. The questions I'm not sure about is how it to = mix/sequence your presentation and Colin's presentation.=20 But I'm not really sure the right amount of time to allocate for theses = two and I'm not sure the best way to cover both at the same time. I do = want to talk about them in one presentation as there is lots over = overlap in the discussion. Can you and Colin see if you can figure out a = proposal for best way to run the discussion on these two drafts? Perhaps = one way would be to have you take 10 minutes before Colin and preset the = security big picture then have Colin cover the part from his draft? = Thoughts from anyone on best way to structure the time and have a = productive discussion?=20 Again - new agenda tomorrow. But yes, one way or the other, there will = be some time on the agenda for this. Cullen On Mar 17, 2010, at 15:20 , Rene Struik wrote: > Dear Carsten, Cullen: >=20 > I just reviewed the agenda for the 6lowapp meeting at IETF-77 and, to = my > surprise, noticed that the presentation slot you presumably allocated = to > me was not there. Please correct. >=20 > Cell: +1 (416) 433-7880 >=20 > Best regards, Rene >=20 > Agenda CORE WG=20 > IETF-77, Anaheim, CA, USA > ----------------------------------- > DRAFT Agenda created March 10 >=20 > Time: > Thursday, Mar 25, 9:00 to 11:30 >=20 > Chairs: > Carsten Bormann > Cullen Jennings >=20 > Mailing Lists: > General Discussion: core@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/core >=20 > Wiki & Status:=20 > http://tools.ietf.org/wg/core/ >=20 >=20 >=20 > Agenda Bash and Status (Chairs 10 min) > - Note takers > - Jabber Scribes >=20 >=20 > CoAP requirements and protocol proposal (Zach Shelby 50 min) > draft-shelby-core-coap-req-00.txt > draft-shelby-core-coap-00.txt >=20 >=20 > Bootstrap discussion (Colin Oflynn 30 min) > draft-oflynn-core-bootstrapping-00 >=20 >=20 > Compressed IPfix (Lothar Braun 30 min) > draft-braun-core-compressed-ipfix-01.txt >=20 >=20 > Other Topics (Working Group 30 min) >=20 >=20 From Colin.OFlynn@atmel.com Sat Mar 20 00:52:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F20A3A696C for ; Sat, 20 Mar 2010 00:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk2bFJlp3nzy for ; Sat, 20 Mar 2010 00:52:36 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 609763A6886 for ; Sat, 20 Mar 2010 00:52:35 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o2K7ocSh020225; Sat, 20 Mar 2010 00:50:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC802.48C9D854" Date: Sat, 20 Mar 2010 01:48:27 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CORE anddraft-struik-6lowapp-security-considerations-00.txt Thread-Index: AcrHxlLYIq4RWXThRmChK8tGEqbK8wAO2dDO References: <7E1DF37F1F42AB4E877E492C308E6AC4049AD02A@XCH57YKF.rim.net> <89398737-3CB4-429A-829E-7BA2A709BCB9@cisco.com> From: "Oflynn, Colin" To: "Cullen Jennings" , "Rene Struik" Cc: core@ietf.org Subject: Re: [core] CORE anddraft-struik-6lowapp-security-considerations-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 07:52:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC802.48C9D854 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cullen & Rene, I was going to offer to squeeze up my time slot if needed anyway ;-) I think it makes more sense for Rene to go first, as I'll build on his = security architecture. I would propose the following sort of = presentation within the 30min period: 10 mins Rene 10 mins Colin 10 mins Discussion / Extra Material If you need more time Rene I can squeeze mine down, or we can make it = more just a presentation & no questions! I'm not sure how the IETF = presentations normally run. Also: is there projector facilities etc provided? Anything specific we = should know? Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Cullen Jennings Sent: Sat 20/03/2010 00:43 To: Rene Struik Cc: core@ietf.org Subject: Re: [core] CORE = anddraft-struik-6lowapp-security-considerations-00.txt =20 Ah, It's my fault Rene. I had it on my todo list for a week to go fix = this part of the agenda. The questions I'm not sure about is how it to = mix/sequence your presentation and Colin's presentation.=20 But I'm not really sure the right amount of time to allocate for theses = two and I'm not sure the best way to cover both at the same time. I do = want to talk about them in one presentation as there is lots over = overlap in the discussion. Can you and Colin see if you can figure out a = proposal for best way to run the discussion on these two drafts? Perhaps = one way would be to have you take 10 minutes before Colin and preset the = security big picture then have Colin cover the part from his draft? = Thoughts from anyone on best way to structure the time and have a = productive discussion?=20 Again - new agenda tomorrow. But yes, one way or the other, there will = be some time on the agenda for this. Cullen On Mar 17, 2010, at 15:20 , Rene Struik wrote: > Dear Carsten, Cullen: >=20 > I just reviewed the agenda for the 6lowapp meeting at IETF-77 and, to = my > surprise, noticed that the presentation slot you presumably allocated = to > me was not there. Please correct. >=20 > Cell: +1 (416) 433-7880 >=20 > Best regards, Rene >=20 > Agenda CORE WG=20 > IETF-77, Anaheim, CA, USA > ----------------------------------- > DRAFT Agenda created March 10 >=20 > Time: > Thursday, Mar 25, 9:00 to 11:30 >=20 > Chairs: > Carsten Bormann > Cullen Jennings >=20 > Mailing Lists: > General Discussion: core@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/core >=20 > Wiki & Status:=20 > http://tools.ietf.org/wg/core/ >=20 >=20 >=20 > Agenda Bash and Status (Chairs 10 min) > - Note takers > - Jabber Scribes >=20 >=20 > CoAP requirements and protocol proposal (Zach Shelby 50 min) > draft-shelby-core-coap-req-00.txt > draft-shelby-core-coap-00.txt >=20 >=20 > Bootstrap discussion (Colin Oflynn 30 min) > draft-oflynn-core-bootstrapping-00 >=20 >=20 > Compressed IPfix (Lothar Braun 30 min) > draft-braun-core-compressed-ipfix-01.txt >=20 >=20 > Other Topics (Working Group 30 min) >=20 >=20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CAC802.48C9D854 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] CORE = anddraft-struik-6lowapp-security-considerations-00.txt

Hi Cullen & Rene,

I was going to offer to squeeze up my time slot if needed anyway ;-)

I think it makes more sense for Rene to go first, as I'll build on his = security architecture. I would propose the following sort of = presentation within the 30min period:

10 mins Rene
10 mins Colin
10 mins Discussion / Extra Material

If you need more time Rene I can squeeze mine down, or we can make it = more just a presentation & no questions! I'm not sure how the IETF = presentations normally run.

Also: is there projector facilities etc provided? Anything specific we = should know?

Regards,

  -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of Cullen Jennings
Sent: Sat 20/03/2010 00:43
To: Rene Struik
Cc: core@ietf.org
Subject: Re: [core] CORE = anddraft-struik-6lowapp-security-considerations-00.txt


Ah, It's my fault Rene. I had it on my todo list for a week to go fix = this part of the agenda. The questions I'm not sure about is how it to = mix/sequence your presentation and Colin's presentation.

But I'm not really sure the right amount of time to allocate for theses = two and I'm not sure the best way to cover both at the same time. I do = want to talk about them in one presentation as there is lots over = overlap in the discussion. Can you and Colin see if you can figure out a = proposal for best way to run the discussion on these two drafts? Perhaps = one way would be to have you take 10 minutes before Colin and preset the = security big picture then have Colin cover the part from his draft? = Thoughts from anyone on best way to structure the time and have a = productive discussion?

Again - new agenda tomorrow. But yes, one way or the other, there will = be some time on the agenda for this.

Cullen


On Mar 17, 2010, at 15:20 , Rene Struik wrote:

> Dear Carsten, Cullen:
>
> I just reviewed the agenda for the 6lowapp meeting at IETF-77 and, = to my
> surprise, noticed that the presentation slot you presumably = allocated to
> me was not there. Please correct.
>
> Cell: +1 (416) 433-7880
>
> Best regards, Rene
>
> Agenda CORE WG
> IETF-77, Anaheim, CA, USA
> -----------------------------------
> DRAFT Agenda created March 10
>
> Time:
>       Thursday, Mar 25, 9:00 to 11:30
>
> Chairs:
>       Carsten Bormann = <cabo@tzi.org>
>       Cullen Jennings = <fluffy@cisco.com>
>
> Mailing Lists:
>       General Discussion: = core@ietf.org
>       To = Subscribe:       https://www.ietf.org/= mailman/listinfo/core
>
> Wiki & Status:
>       http://tools.ietf.org/wg/core/
>
>
>
> Agenda Bash and = Status          (Chairs 10 = min)
>       - Note takers
>       - Jabber Scribes
>
>
> CoAP requirements and protocol proposal (Zach Shelby 50 min)
>       = draft-shelby-core-coap-req-00.txt
>       draft-shelby-core-coap-00.txt
>
>
> Bootstrap discussion (Colin Oflynn 30 min)
>       = draft-oflynn-core-bootstrapping-00
>
>
> Compressed IPfix (Lothar Braun 30 min)
>       = draft-braun-core-compressed-ipfix-01.txt
>
>
> Other Topics (Working Group 30 min)
>
>

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/= mailman/listinfo/core

------_=_NextPart_001_01CAC802.48C9D854-- From fluffy@cisco.com Sat Mar 20 12:44:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22533A6903 for ; Sat, 20 Mar 2010 12:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.956 X-Spam-Level: X-Spam-Status: No, score=-108.956 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60eppxco+Asg for ; Sat, 20 Mar 2010 12:44:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C4E543A67EE for ; Sat, 20 Mar 2010 12:44:58 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACPCpEurRN+J/2dsb2JhbACbPXOjQZhPhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="500037882" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2010 19:45:13 +0000 Received: from sjc-vpn1-1009.cisco.com (sjc-vpn1-1009.cisco.com [10.21.99.241]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2KJjDK5019782 for ; Sat, 20 Mar 2010 19:45:13 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 20 Mar 2010 12:45:13 -0700 Message-Id: <036B5890-0EA7-4203-AAA2-05BDC55CA779@cisco.com> To: core@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [core] Presentations in CORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 19:45:00 -0000 Here is a bit of information for folks on upcoming meeting - = particularly folks presenting. There will be a projector at front of the = room. Typically slides are in powerpoint, keynote, or PDF if all else = fails. The chairs will make the slides available before the meeting on = the website at: https://datatracker.ietf.org/meeting/77/materials.html My preference is, if at all possible, to get a draft of any slides = emailed to both chairs by 48 hours before the meeting starts. This gives = us a chance to glance at them and catch things like any huge overlaps = between different presenters. We will try and have the slides posted to = the web site 24 hours before the meeting starts. There are times where = someone will be handing us slides 20 minutes before the meeting on a USB = stick because some discussion or change of events required slides to be = updated. This does happen and if slides need to be changed, expect this = to happen. One of the reasons for having the slides up early is it makes = it easier for people to get the slides translated from English to their = language of choice before the meeting starts.=20 We will try to present the slides off one of the chairs computers so = that we can minimize the time to swapping computers between = presentations. However, sometimes this is not possible so, if you are = presenting, come with a computer you can connect to a projector if = needed.=20 If this is your first time at an IETF meeting, you might find some = useful information in=20 http://www.ietf.org/tao.html All the presentation and discussion in the meeting are covered under the = IETF Note Well statement so make sure you are aware of that (happy to = send pointers to anyone that needs it).=20 There should be a streaming audio feed for the meeting that remote = people can listen too and a jabber chat room were remote people can = submit questions and everyone can use for sidebar conversations.=20 You can find links to jabber rooms, downloads, audio feed, etc at=20 http://tools.ietf.org/agenda/77/#THURSDAY Looking forward to the meeting,=20 Cullen From fluffy@cisco.com Sat Mar 20 12:48:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA0E3A68F7 for ; Sat, 20 Mar 2010 12:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.657 X-Spam-Level: X-Spam-Status: No, score=-109.657 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ7tRji5Es-z for ; Sat, 20 Mar 2010 12:48:20 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 91CF83A67EE for ; Sat, 20 Mar 2010 12:48:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANLDpEurR7H+/2dsb2JhbACbPnOjPosUCY0wgmqCEwSDHg X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="103360552" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2010 19:48:35 +0000 Received: from sjc-vpn1-1009.cisco.com (sjc-vpn1-1009.cisco.com [10.21.99.241]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2KJmZJU029312; Sat, 20 Mar 2010 19:48:35 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sat, 20 Mar 2010 12:48:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82B0697F-0430-4731-8D80-152E72ECD814@cisco.com> References: <7E1DF37F1F42AB4E877E492C308E6AC4049AD02A@XCH57YKF.rim.net> <89398737-3CB4-429A-829E-7BA2A709BCB9@cisco.com> To: "Oflynn, Colin" , Rene Struik X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] CORE anddraft-struik-6lowapp-security-considerations-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 19:48:22 -0000 Let's make this 15 min, 15 min, 15 minutes. It's really important to be = able to get discussion going and find out if there is agreement around = ideas and proposals. We will also end up being clarifying questions and = such during the presentation. It's really hard to get 7 minutes of = material presented in less than 15 minutes of time at IETF so I added = more time to this. If we end up using less time than needed, that's = fine.=20 On Mar 20, 2010, at 24:48 , Oflynn, Colin wrote: > Hi Cullen & Rene, >=20 > I was going to offer to squeeze up my time slot if needed anyway ;-) >=20 > I think it makes more sense for Rene to go first, as I'll build on his = security architecture. I would propose the following sort of = presentation within the 30min period: >=20 > 10 mins Rene > 10 mins Colin > 10 mins Discussion / Extra Material >=20 > If you need more time Rene I can squeeze mine down, or we can make it = more just a presentation & no questions! I'm not sure how the IETF = presentations normally run. >=20 > Also: is there projector facilities etc provided? Anything specific we = should know? >=20 > Regards, >=20 > -Colin >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org on behalf of Cullen Jennings > Sent: Sat 20/03/2010 00:43 > To: Rene Struik > Cc: core@ietf.org > Subject: Re: [core] CORE = anddraft-struik-6lowapp-security-considerations-00.txt >=20 >=20 > Ah, It's my fault Rene. I had it on my todo list for a week to go fix = this part of the agenda. The questions I'm not sure about is how it to = mix/sequence your presentation and Colin's presentation. >=20 > But I'm not really sure the right amount of time to allocate for = theses two and I'm not sure the best way to cover both at the same time. = I do want to talk about them in one presentation as there is lots over = overlap in the discussion. Can you and Colin see if you can figure out a = proposal for best way to run the discussion on these two drafts? Perhaps = one way would be to have you take 10 minutes before Colin and preset the = security big picture then have Colin cover the part from his draft? = Thoughts from anyone on best way to structure the time and have a = productive discussion? >=20 > Again - new agenda tomorrow. But yes, one way or the other, there will = be some time on the agenda for this. >=20 > Cullen >=20 >=20 > On Mar 17, 2010, at 15:20 , Rene Struik wrote: >=20 > > Dear Carsten, Cullen: > > > > I just reviewed the agenda for the 6lowapp meeting at IETF-77 and, = to my > > surprise, noticed that the presentation slot you presumably = allocated to > > me was not there. Please correct. > > > > Cell: +1 (416) 433-7880 > > > > Best regards, Rene > > > > Agenda CORE WG > > IETF-77, Anaheim, CA, USA > > ----------------------------------- > > DRAFT Agenda created March 10 > > > > Time: > > Thursday, Mar 25, 9:00 to 11:30 > > > > Chairs: > > Carsten Bormann > > Cullen Jennings > > > > Mailing Lists: > > General Discussion: core@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/core > > > > Wiki & Status: > > http://tools.ietf.org/wg/core/ > > > > > > > > Agenda Bash and Status (Chairs 10 min) > > - Note takers > > - Jabber Scribes > > > > > > CoAP requirements and protocol proposal (Zach Shelby 50 min) > > draft-shelby-core-coap-req-00.txt > > draft-shelby-core-coap-00.txt > > > > > > Bootstrap discussion (Colin Oflynn 30 min) > > draft-oflynn-core-bootstrapping-00 > > > > > > Compressed IPfix (Lothar Braun 30 min) > > draft-braun-core-compressed-ipfix-01.txt > > > > > > Other Topics (Working Group 30 min) > > > > >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Sat Mar 20 12:52:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F98E3A67AE for ; Sat, 20 Mar 2010 12:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.655 X-Spam-Level: X-Spam-Status: No, score=-109.655 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d72rvTsON4+n for ; Sat, 20 Mar 2010 12:52:00 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8B62C3A67A1 for ; Sat, 20 Mar 2010 12:52:00 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANLDpEurR7Hu/2dsb2JhbACbPnOjPphNhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="103361243" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2010 19:52:15 +0000 Received: from sjc-vpn1-1009.cisco.com (sjc-vpn1-1009.cisco.com [10.21.99.241]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2KJqFQs025213; Sat, 20 Mar 2010 19:52:15 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 20 Mar 2010 12:52:15 -0700 Message-Id: To: core@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [core] New CORE Agenda - 2010-03-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 19:52:01 -0000 Latest agenda is below ... If folks thinks we need changes to this, let = Carsten and I know.=20 Thanks, Cullen Agenda CORE WG=20 IETF-77, Anaheim, CA, USA ----------------------------------- DRAFT Agenda created March 20 Time: Thursday, Mar 25, 9:00 to 11:30 Chairs: Carsten Bormann Cullen Jennings Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Wiki & Status:=20 http://tools.ietf.org/wg/core/ Agenda Bash and Status (Chairs 5 min) - Note takers - Jabber Scribes CoAP requirements and protocol proposal (Zach Shelby 55 min) draft-shelby-core-coap-req-00.txt=20 draft-shelby-core-coap-00.txt Includes discussion of resource discover and design of directory and user agents. Bootstrap & Secuirty discussion (Rene Struik & Colin Oflynn 45 min) draft-struik-6lowapp-security-considerations-00 draft-oflynn-core-bootstrapping-00 Compressed IPfix (Lothar Braun 20 min) draft-braun-core-compressed-ipfix-01.txt Other Topics (Working Group 25 min) From bobd@echelon.com Tue Mar 23 09:48:26 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CBA23A69DE for ; Tue, 23 Mar 2010 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.97 X-Spam-Level: * X-Spam-Status: No, score=1.97 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwECHepcftRb for ; Tue, 23 Mar 2010 09:48:14 -0700 (PDT) Received: from monk.echelon.com (monk.echelon.com [12.191.56.29]) by core3.amsl.com (Postfix) with ESMTP id 4573E3A6886 for ; Tue, 23 Mar 2010 09:48:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {3C0C0442-108D-4360-8F84-9D6DD26E43A6} MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACAA8.AC97426B" x-cr-hashedpuzzle: AVDH BBKF B0a6 CRoR Cpkz DdUw DzuQ Ex5w E/Yt E/x/ Fq5D FvOo F6fo GVBo GjhB G/t9; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {3C0C0442-108D-4360-8F84-9D6DD26E43A6}; YgBvAGIAZABAAGUAYwBoAGUAbABvAG4ALgBjAG8AbQA=; Tue, 23 Mar 2010 16:48:31 GMT; QwBvAG0AbQBlAG4AdABzACAAbwBuACAAZAByAGEAZgB0AC0AcwBoAGUAbABiAHkALQBjAG8AcgBlAC0AYwBvAGEAcAAtAHIAZQBxAC0AMAAwAC4AdAB4AHQA Content-class: urn:content-classes:message Date: Tue, 23 Mar 2010 09:48:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-shelby-core-coap-req-00.txt Thread-Index: AcrKqKu7jbyZdwtvTGGNzkzH21c9RA== From: "Bob Dolin" To: Subject: [core] Comments on draft-shelby-core-coap-req-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:48:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACAA8.AC97426B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This didn't appear to go through last night, so I am re-sending. I apologize in advance if you are receiving this twice. =20 =20 Comments on CoAP Requirements and Features, draft-shelby-core-coap-req-00,=20 issued on February 18, 2010. =20 Bob Dolin Echelon Corporation =20 After reading this document, I have to say that the requirements stated within it=20 are insufficient to serve the markets that my company does. Those markets are,=20 I believe, what the expansion of IP to the "internet of things" is intended to address.=20 Essential to this market is a uniform set of protocol services that interoperate, to enable applications to be easily developed with the result that a bunch of intelligent=20 objects, made by different companies, and integrated together by an unsophisticated user=20 work as expected. =20 Below, are some more detailed observations. =20 The document contains the following abstract: =20 Abstract =20 This document considers the requirements and resulting features needed for the design of the Constrained Application Protocol (CoAP). Starting from requirements for energy and building automation applications, the basic features are identified along with an analysis of possible realizations. The goal of the document is to provide a basis for protocol design and related discussion. =20 [bobd] I think this abstract is overly constrained in its scope, or other parts of this document far exceed the scope alluded to in the abstract. It says that its focus is on energy and building automation applications. However, the scope of IP for resource constrained devices, or IP for Smart Objects goes well beyond building automation and energy applications to generic sensing, monitoring and control of "things." I believe that the abstract should be to support the IP connectivity of smart objects, or something=20 like that to encompass the broader "internet of things," or generic M2M=20 applications or something along those lines. =20 In the requirements section of the document it says: =20 REQ9: CoAP will support a non-reliable multicast message to be sent to a group of Devices to manipulate a resource on all the Devices simultaneously [charter]. The use of multicast to query and advertise descriptions must be supported, along with the support of unicast responses [I-D.sturek-6lowapp-smartenergy]. =20 REQ11: Reliability must be possible for application layer messages over UDP [I-D.sturek-6lowapp-smartenergy]. =20 [bobd] These, along with the attendant features of duplicate packet=20 detection, transaction timing, retry counts and retry timers are transport layer services and are not part of an application layer protocol. These=20 transport layer services should not be forced upon every application author=20 to code up, get right, and interoperate with the other implementations. Typical application developers have application domain knowledge. Typical protocol engineers know about protocols, but do not have application domain knowledge for every application that may use their protocol. It is unreasonable to expect either group to do a good job on the other's area of expertise. =20 In the general case of IP for smart objects, I would expect (and my company has experienced) that developers move applications that were directly wired, no network, to one where the I/Os, and controllers are physically separate and interconnected with a communication network. In this more general case, the=20 application may be thought of as a single state machine where the advancement to the next state is based upon reliable messaging -- if the message didn't get there, perhaps a shut down or a safety interlock should be actuated rather than just going on. In this environment, reliable unicasting and reliable multicasting with duplicate message detection (to support non-idempotent messages)are required. Thus, the set of requirements in this draft does not meet the general requirements=20 for creating general, intelligent, distributed applications. =20 Given that features are needed from both a transport and from an application layer, the effort should be split into defining a transport protocol for resource constrained devices and an application protocol for resource constrained devices. =20 Later on in the document it says: =20 REQ12: Latency times should be mimimized of the Home Area Network (HAN), and ideally a typical exchange should consist of just a single request and a single response message. [I-D.sturek-6lowapp-smartenergy] =20 [bobd] One technique to reduce latency is to support multicast request/response in the transport layer. It is a slight generalization to reliable multicast where a simple acknowledgement is replaced with an application generated response. In this way, a single request could be sent to, say 10 nodes, and each node would respond, for a total number of messages of 11, versus a unicast to each, with a=20 total number of messages being 20. Multicast request/response service should be=20 required. =20 Further down, the document states: =20 2.8.1. UDP =20 The goal of binding CoAP to UDP is to provide the bare minimum features for the protocol to operate over UDP, going nowhere near trying to re-create the full feature set of TCP. The bare minimum features required would be: =20 o Stop-and-wait would be sufficient for reliability. A simple response message itself would suffice as an acknowledgement with retransmission support. Not all requests require reliability, thus this should be optional. Performance is not the key here and for more sophisticated reliability and flow control TCP could be used. [bobd] Stop-and-wait is not sufficient for a general purpose application even in building automation. Consider the case of a node that has as a primary responsibility, communicating with some set of other nodes and pinging them for their application status -- maybe to display on a web page. Consider that the set of nodes is large, say 50 or even 100 -- a large building may have over 1,000 VAV (variable air volume) controllers in it, so monitoring just a hundred nodes is not far-fetched. Now, consider that one node isn't=20 responding. With stop-and-wait, the monitor node cannot move on to ask the=20 next node's status until all the timeouts and retries have been exhausted on the first node. Now consider that there is a link failure and multiple nodes aren't responding. With only stop-and-wait services, the monitoring node's=20 performance will be unacceptable. Also, I have the same comment that retries and such are NOT part of the application layer in the ISO model. =20 Next the document says: =20 o A sequence number (transaction ID) is needed to match responses to open requests and would be generated by the client. A 12-16 bit unsigned interger would be sufficient. [I-D.frank-6lowapp-chopan] also considered this solution. [bobd] This doesn't belong in an application layer, it is a transport service. This seems pretty simple, but what about the error/edge cases, like a client that is using sequence number X and has a message outstanding, and then restarts, and=20 issues its next request using sequence number X. Should sequence numbers be=20 persistent across resets, or should one be reserved to only use after a reset, which one? What happens when different application developers use different conventions? Interoperability can be a real nightmare when such decisions are left to each=20 application implementer. This working group needs to define a distinct transport layer and a distinct application layer with well defined services for each. =20 Next the document says: =20 o Multicast support. Providing reliability with a multicast destination address would be very complex. Therefore the goal is to provide a non-reliable multicast service. In many cases there may not be a response to a multicast message. A multicast command might result in an action being taken at a device, but no response being sent. Therefore a multicast request may be answered with a unicast response, however without reliability (retransmission e.g.). =20 [bobd] I read this as, reliable multicast is really hard, and we need it, but since it is really hard, we will define away the requirement, even though we need it. Actually, reliable multicast, reliable request/response, and multicast repeated-but-unacked services are all a part of the distinct (as in separate from the network layer and application layer) transport layer of ISO/IEC 14908-1, and=20 an optimized implementation of that standard fits in 12K bytes for the MAC through L2 through L7, and consumes only 512 bytes for the RAM.=20 So, it doesn't have to be hard or complex, one could simply integrate what has=20 already been done. Granted, in that protocol specification, commonly called the=20 LonWorks(r) protocol or LonTalk(r) protocol, multicast groups cannot be of arbitrary=20 size if reliable services are used, instead the specification does support groups=20 of up to 64 members. The transport protocol itself has no such limitation. If there is interest, I could put together an internet draft of such a transport layer that=20 depends only upon the services of an underlying UDP/IPv6 layer. =20 =20 ------_=_NextPart_001_01CACAA8.AC97426B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This didn’t appear to go through last = night, so I am re-sending. I apologize in advance if you are receiving this = twice.

 

 

Comments on CoAP Requirements and Features, draft-shelby-core-coap-req-00,

issued on February 18, = 2010.

 

Bob Dolin

Echelon Corporation

 

After reading this document, I have to say = that the requirements stated within it

are insufficient to serve the markets that my company does. Those markets are,

I believe, what the expansion of IP to the "internet of things" is intended to address. =

Essential to this market is a uniform set of protocol services that interoperate, to

enable applications to be easily developed = with the result that a bunch of intelligent

objects, made by different companies, and = integrated together by an unsophisticated user

work as expected.

 

Below, are some more detailed = observations.

 

The document contains the following = abstract:

 

Abstract

 

   This document considers the requirements and resulting features

   needed for the design of the Constrained Application Protocol (CoAP).

   Starting from requirements for = energy and building automation

   applications, the basic features = are identified along with an

   analysis of possible = realizations.  The goal of the document is to

   provide a basis for protocol = design and related discussion.

 

[bobd] I think this abstract is overly = constrained in its scope, or other

parts of this document far exceed the scope = alluded to in the abstract. It says

that its focus is on energy and building = automation applications. However,

the scope of IP for resource constrained = devices, or IP for Smart Objects

goes well beyond building automation and = energy applications to generic

sensing, monitoring and control of "things." I believe that the abstract

should be to support the IP connectivity of = smart objects, or something

like that to encompass the broader = "internet of things," or generic M2M

applications or something along those = lines.

 

In the requirements section of the document = it says:

 

   REQ9:   CoAP will = support a non-reliable multicast message to be sent

           to a group of Devices to manipulate a resource on all = the

           Devices simultaneously [charter].  The use of multicast = to

           query and advertise descriptions must be supported, = along

           with the support of unicast responses

           [I-D.sturek-6lowapp-smartenergy].

 

   REQ11:  Reliability must be possible for application layer messages

           over UDP [I-D.sturek-6lowapp-smartenergy].

 

[bobd] These, along with the attendant = features of duplicate packet

detection, transaction timing, retry counts = and retry timers are transport

layer services and are not part of an = application layer protocol. These

transport layer services should not be forced = upon every application author

to code up, get right, and interoperate with = the other implementations.

Typical application developers have = application domain knowledge. Typical

protocol engineers know about protocols, but = do not have application

domain knowledge for every application that = may use their protocol. It is

unreasonable to expect either group to do a = good job on the other's area

of expertise.

 

In the general case of IP for smart objects, = I would expect (and my company

has experienced) that developers move = applications that were directly wired,

no network, to one where the I/Os, and = controllers are physically separate and

interconnected with a communication network. = In this more general case, the

application may be thought of as a single = state machine where the advancement

to the next state is based upon reliable = messaging -- if the message didn't get

there, perhaps a shut down or a safety = interlock should be actuated rather than

just going on. In this environment, reliable unicasting and reliable multicasting

with duplicate message detection (to support non-idempotent messages)are required.

Thus, the set of requirements in this draft = does not meet the general requirements

for creating general, intelligent, = distributed applications.

 

Given that features are needed from both a = transport and from an application layer,

the effort should be split into defining a = transport protocol for resource constrained

devices and an application protocol for = resource constrained devices.

 

Later on in the document it = says:

 

   REQ12:  Latency times = should be mimimized of the Home Area Network

           (HAN), and ideally a typical exchange should consist of = just

           a single request and a single response message.

           [I-D.sturek-6lowapp-smartenergy]

 

[bobd] One technique to reduce latency is to = support multicast request/response

in the transport layer. It is a slight generalization to reliable multicast where

a simple acknowledgement is replaced with an application generated response.

In this way, a single request could be sent = to, say 10 nodes, and each node would

respond, for a total number of messages of = 11, versus a unicast to each, with a

total number of messages being 20. Multicast = request/response service should be

required.

 

Further down, the document = states:

 

2.8.1.  UDP

 

   The goal of binding CoAP to UDP = is to provide the bare minimum

   features for the protocol to = operate over UDP, going nowhere near

   trying to re-create the full = feature set of TCP.  The bare minimum

   features required would = be:

 

   o  Stop-and-wait would be sufficient for reliability.  A simple

      response = message itself would suffice as an acknowledgement with

      retransmission support.  Not all requests require = reliability,

      thus this = should be optional.  Performance is not the key here = and

      for more sophisticated reliability and flow control TCP could = be

      = used.

[bobd] Stop-and-wait is not sufficient for a = general purpose application

even in building automation. Consider the = case of a node that has as a primary

responsibility, communicating with some set = of other nodes and pinging

them for their application status -- maybe to display on a web page. Consider

that the set of nodes is large, say 50 or = even 100 -- a large building may

have over 1,000 VAV (variable air volume) controllers in it, so monitoring

just a hundred nodes is not far-fetched. Now, consider that one node isn't

responding. With stop-and-wait, the monitor = node cannot move on to ask the

next node's status until all the timeouts and retries have been exhausted on

the first node. Now consider that there is a = link failure and multiple nodes

aren't responding. With only stop-and-wait = services, the monitoring node's

performance will be unacceptable. Also, I = have the same comment that

retries and such are NOT part of the = application layer in the ISO model.

 

Next the document says:

 

   o  A sequence number = (transaction ID) is needed to match responses to

      open requests = and would be generated by the client.  A 12-16 = bit

      unsigned = interger would be sufficient.  = [I-D.frank-6lowapp-chopan]

      also = considered this solution.

[bobd] This doesn't belong in an application = layer, it is a transport service.

This seems pretty simple, but what about the error/edge cases, like a client that

is using sequence number X and has a message outstanding, and then restarts, and

issues its next request using sequence number = X. Should sequence numbers be

persistent across resets, or should one be = reserved to only use after a reset, which

one? What happens when different application developers use different conventions?

Interoperability can be a real nightmare when = such decisions are left to each

application implementer. This working group = needs to define a distinct transport

layer and a distinct application layer with = well defined services for each.

 

Next the document says:

 

   o  Multicast support.  Providing reliability with a multicast

      destination = address would be very complex.  Therefore the goal is

      to provide a non-reliable multicast service.  In many cases = there

      may not be a = response to a multicast message.  A multicast command

      might result = in an action being taken at a device, but no response

      being = sent.  Therefore a multicast request may be answered with = a

      unicast = response, however without reliability (retransmission

      = e.g.).

 

[bobd] I read this as, reliable multicast is = really hard, and we need it, but

since it is really hard, we will define away = the requirement, even though we

need it.  Actually, reliable multicast, reliable request/response, and multicast

repeated-but-unacked services are all a part = of the distinct (as in separate from

the network layer and application layer) = transport layer of ISO/IEC 14908-1, and

an optimized implementation of that standard = fits in 12K bytes for the

MAC through L2 through L7, and consumes only = 512 bytes for the RAM.

So, it doesn't have to be hard or complex, = one could simply integrate what has

already been done. Granted, in that protocol specification, commonly called the

LonWorks(r) protocol or LonTalk(r) protocol, multicast groups cannot be of arbitrary

size if reliable services are used, instead = the specification does support groups

of up to 64 members. The transport protocol = itself has no such limitation. If there

is interest, I could put together an internet = draft of such a transport layer that

depends only upon the services of an = underlying UDP/IPv6 layer.

 

 

------_=_NextPart_001_01CACAA8.AC97426B-- From gtolle@archrock.com Tue Mar 23 10:12:36 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDBC3A6A0C for ; Tue, 23 Mar 2010 10:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvLdm-6IqjU2 for ; Tue, 23 Mar 2010 10:12:35 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D27C03A6965 for ; Tue, 23 Mar 2010 10:12:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 47DE4AF9C6 for ; Tue, 23 Mar 2010 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La0Iz4XEj5fh for ; Tue, 23 Mar 2010 10:12:16 -0700 (PDT) Received: from [10.0.1.5] (69-12-137-125.dsl.static.sonic.net [69.12.137.125]) by mail.sf.archrock.com (Postfix) with ESMTP id 59A28AF99D for ; Tue, 23 Mar 2010 10:12:16 -0700 (PDT) Message-Id: <7B14CE14-E869-47B1-9767-05166EEC3481@archrock.com> From: Gilman Tolle To: core@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Mar 2010 10:12:15 -0700 X-Mailer: Apple Mail (2.936) Subject: [core] New I-D of interest to the list: draft-tolle-core-ebhttp X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:12:36 -0000 Dear WG members, I just submitted a new draft for a protocol that may be of interest to the CoRE working group. Still plenty in here to do, but it sketches out an efficient-HTTP approach to naming and transport of data items in constrained networks. A protocol like this could serve as an extensible foundation for higher-level resource discovery and application interoperability. It tries to build on as much existing work as possible, while remaining compact and usable within the networks CoRE focuses on. Thank you for your consideration, and I'm looking forward to working with the group. Gil --- http://tools.ietf.org/html/draft-tolle-core-ebhttp-00 Filename: draft-tolle-core-ebhttp Revision: 00 Title: Embedded Binary HTTP (EBHTTP) Creation_date: 2010-03-23 WG ID: Independent Submission Number_of_pages: 11 Abstract: Embedded Binary HTTP (EBHTTP) is a binary-formatted, space-efficient, stateless encoding of the standard HTTP/1.1 protocol. EBHTTP is intended for transport of small named data items, such as sensor readings, between resource-constrained nodes. From oobles@gmail.com Wed Mar 24 04:16:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C9F3A6A2E for ; Wed, 24 Mar 2010 04:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUm+jn4NUeYu for ; Wed, 24 Mar 2010 04:16:42 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id 2C49D3A67B5 for ; Wed, 24 Mar 2010 04:16:41 -0700 (PDT) Received: by iwn35 with SMTP id 35so4739173iwn.31 for ; Wed, 24 Mar 2010 04:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=a12fpZwZ4fYsExNlECxKDhKQavQdeJrRrSQ2G6K2LE4=; b=a+UNQwpHDTz5CR1OkJzFJuhk8PYrwqwaDrlB6clsA2DZowBGLyX4mMMxoA/3Bl79G9 moTI294epKMXLFTsfuEVhPTFyCJlpHACUemq+0KwZpCGnvLtpWvPJmo1kiwJpdm/256Q usPa0yfBmbtXm0+aw600UyeEbUdTFRx7Itcdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BrrPdlZOfReqtA2Ceay4oi+apBW8yuQfdu68hxgjusZYTmzuUCiZ9tI7RiYCRwRP98 bL3zfjrDeix7uHakmoffTjEb0D+FfgUaL7ea5RQISL7yCq5/7nPHFVHAc0Ob2LQ9dRx9 9v4EoI1ZKLt6+VLLt8H39QMMDq4C+ZDEpR2sc= MIME-Version: 1.0 Received: by 10.231.143.12 with SMTP id s12mr342394ibu.38.1269429418343; Wed, 24 Mar 2010 04:16:58 -0700 (PDT) Date: Wed, 24 Mar 2010 22:16:58 +1100 Message-ID: <7f996c491003240416w63f40f70x1b22d88edffb420@mail.gmail.com> From: David Ryan To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: [core] COAP basic implementation. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 11:16:44 -0000 Hi All, Following the feedback below, I have started to develop an implementation in Java of the COAP protocol. The implementation uses the proposed changes I discussed below. In its current form it shows a client and server implementation with a simple echo server. It is quite rough at the moment, but thought given the meeting coming up at Anaheim tomorrow, it might be of interest to some. COAP options are not currently implemented. I will be working on them in the coming week. I will also be developing better JUnit tests to improve coverage and show more examples of how the protocol could be used. All code is released under a BSD license. One of the questions that came up during implementation was what is a malformed request? How does the server tell and under what situations should an error response be sent? Also, should a request have to come from a client using the COAP port, or should the server send responses to the client port that sent it? You can find the download under Colony COAP near the bottom of http://www.einet.com.au/Downloads Comments and feedback appreciated. Regards, David. On Fri, Mar 19, 2010 at 10:01 AM, David Ryan wrote: > Hi All, > > I sent the following questions and feedback to Brian and Zach who > suggested I forward this to the list for further discussion. =A0I won't > be at the meeting in Anaheim next week, so here's my input. > > First off, a question regarding the compression of the protocol. > You've managed to compress the header into 4 bytes. =A0Obviously the > size of the header is going to be important. =A0In the priority list of > features, is this the most important? =A0Would another byte or two hurt? > > I notice between Chopan and COAP you've dropped the magic number > headers. =A0This must have been a conscious decision. I would have liked > to see a one byte magic value to identify the packet or TCP stream. > This would at least give a server a chance to throw away the request > if it receives a bad message. > > In regard to version. =A0Two bits only leaves four possible versions. > Extending this to 4 bits would at least extend this to 16 versions. > This goes back to the original point regarding size of header. > > Back in 2008 I did a thought experiment on a binary REST based > protocol. =A0Details available at: > > http://blog.livemedia.com.au/search?updated-min=3D2008-01-01T00%3A00%3A00= %2B11%3A00&updated-max=3D2009-01-01T00%3A00%3A00%2B11%3A00&max-results=3D7 > > Many of the elements are not applicable to COAP, but there might be > one or two features I developed which could be worth discussing. > > One element of this through experiment was to include a "slotsAvailable" > in the response. =A0As the "transactionid" field allows multiple > requests to be sent to a single recipient, the "slotsAvailable" in the > response allows a client to limit the number of requests sent. =A0I'd > suggest 4 bits in the response. =A0If the server can handle more than 16 > requests it can return 16 in all responses. =A0A small device might > return 1 at all times. > > Another concept I thought about was to have a bit field for protocol > features. =A0This may not be applicable in this case, however, something > to put on the back burner. =A0The idea is that a small device might only > respond to a limited set of features (or options). =A0A bit field can be > used to identify in the request which features are being used and in > the response what features the server can handle. > > I was also surprised that the protocol doesn't include the URI path in > the main part of the header. =A0I must admit I'm still trying to > understand how the index based approach to URI paths will work in your > proposal. > > I tried taking your proposal and combined it with a few of the above > changes and came up with the following: > > Packet > =A0preamble/magic =A0(1 byte) > > =A0version (4 bits) > =A0features (4 bits) > > =A0response (1 bit) > =A0options (1 bit) > =A0asynchronous (1 bit) > =A0locationType (1 bit) =A0 =A0 (0 URI location field enabled, 1 location > specified in options) > =A0method/slots (4 bits) =A0(method type in request/slots available in re= sponse) > > =A0transactionId (16 bits) > > =A0location (URI location if locationType 0) > > =A0options length (8 bits - length) > =A0... options ... > > =A0payload length (variable length int) > =A0...payload data... > > > The base header in this case is 5 bytes instead of the 4 bytes. > > I also suggested that the number of options is at the start of the > options list. =A0This allows the server to quickly decide if the packet > can be handled and all the option list can be processed. =A0In a > constrained device only a selected number of options could be > processed. =A0This removes the need for the 0 byte end of options byte. > > I have also used a variable length integer for the payload. =A0This is > to allow the protocol to move to TCP with larger packets. > > Regards, > David. > > > On Tue, Mar 2, 2010 at 8:30 AM, Zach Shelby wrote: >> http://www.ietf.org/id/draft-shelby-core-coap-00.txt >> >> Here is a very early draft of a CoAP protocol specification based on the= requirements and initial ideas formulated in draft-shelby-core-coap-req-00= and the previous work by Brian in draft-frank-6lowapp-chopan. Looking forw= ard to lots of good discussion around CoAP, and as you can see from all the= TODOs and TBDs - lots of WG stuff to do here! >> >> At the same time I'd like to request a time-slot to present this in Anah= eim. >> >> Zach >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: March 1, 2010 23:24:35 GMT+02:00 >>> To: zach@sensinode.com >>> Cc: brian.tridium@gmail.com >>> Subject: New Version Notification for draft-shelby-core-coap-00 >>> >>> >>> A new version of I-D, draft-shelby-core-coap-00.txt has been successful= y submitted by Zach Shelby and posted to the IETF repository. >>> >>> Filename: =A0 =A0 =A0draft-shelby-core-coap >>> Revision: =A0 =A0 =A000 >>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Constrained Application Protocol= (CoAP) >>> Creation_date: =A0 =A0 =A0 =A0 2010-03-01 >>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Independent Submission >>> Number_of_pages: 17 >>> >>> Abstract: >>> This document specifies the Constrained Application Protocol (CoAP), >>> a RESTful protocol for use with constrained networks and nodes. =A0CoAP >>> 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. >>> >>> >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet= " >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may contain l= egally privileged information. If you are not the intended recipient, pleas= e contact the sender and delete the e-mail from your system without produci= ng, distributing or retaining copies thereof. >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > From Vipul.Gupta@Sun.COM Wed Mar 24 09:49:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176CB3A6A74 for ; Wed, 24 Mar 2010 09:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS6rDcEAndMm for ; Wed, 24 Mar 2010 09:49:58 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id E6BCD3A6920 for ; Wed, 24 Mar 2010 09:49:57 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2OGoICU000229 for ; Wed, 24 Mar 2010 09:50:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00F00PERCR00@fe-sfbay-10.sun.com> for core@ietf.org; Wed, 24 Mar 2010 09:50:18 -0700 (PDT) Received: from [10.0.1.4] (adsl-67-127-59-133.dsl.pltn13.pacbell.net [67.127.59.133]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00BYJPFTCJ10@fe-sfbay-10.sun.com> for core@ietf.org; Wed, 24 Mar 2010 09:50:18 -0700 (PDT) Date: Wed, 24 Mar 2010 09:50:17 -0700 From: Vipul Gupta Sender: Vipul.Gupta@Sun.COM To: core@ietf.org Message-id: <6AE34AF5-2E88-40A9-9E48-ED3F202CFEEC@sun.com> X-Mailer: Apple Mail (2.1077) Subject: [core] CHTTP/Sleep-Proxy Demo on Sun SPOTs at IETF X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:49:59 -0000 Hi Folks, I'm a researcher at Sun Labs, Oracle, and I have prototyped several of the concepts floating around in this group's discussions -- RESTful sensor/actuator services, Compressed HTTP, sleep proxy/gateway -- for the Sun SPOT platform. This experience brought up a number of issues from minor ones like typos in the chttp draft, to larger ones like gateway discovery and the potential benefit of standardizing some small set of URIs for a device -- e.g. /info where one may obtain information on its manufacturer/model/serialNo etc, or /svc where one may obtain a list of available services. I haven't yet gotten around to putting these thoughts down in an email or ID but I'll be at the IETF tomorrow and hope to meet several of you in person. If anyone is interested in seeing/discussing this demo (I'm attending the IETF only on Thu), please email me. Here's additional information on Sun SPOTs and the demo. Sun SPOTs (http://www.sunspotworld.com) are small, wireless (802.15.4), battery-powered devices that can be programmed in Java ME using standard tools like NetBeans/Eclipse on any of the major development platforms (Windows, Mac, Linux, Solaris). They have proven to be quite popular with students, researchers and hobbyists, e.g. search for "spaughts" (deliberately spelt this way to avoid confusion with the astronomical phenomenon) on either Flickr or YouTube for a sampling of the wide variety of projects that use these devices. The Sun SPOTs come bundled with several demos and one of these is called SPOTWeb (video available at http://blogs.sun.com/vipul/entry/sun_spots_spotweb_and_sensor) which lets users interact with a network of Sun SPOTs via a browser. Users can monitor sensor readings, deploy new code and even pause/resume installed applications. The original implementation of SPOTWeb isn't RESTful, nor does it deal with sleeping devices. The prototype mentioned above is trying to address these shortcomings. The demo shows the ability to GET light and temp readings from a SPOT via a browser or cURL and the ability to turn on/off or change colors on its LEDs using PUTs. When the device sleeps, the gateway can either satisfy requests from its resource cache (assuming what's available in the cache is fresh enough for the client) or queue them up for later processing. The response to queued requests includes a URL where the client can monitor the request status. Pending requests are processed when the device wakes up next. Interactions between the gateway and the device may use either regular HTTP or CHTTP (as per draft-frank-6lowpan-chopan-00) and are carried over UDP/IPv6/6lowPAN/802.15.4. regards, vipul -- http://research.sun.com/people/mybio.php?c=509 From zach@sensinode.com Wed Mar 24 10:03:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562933A6CAF for ; Wed, 24 Mar 2010 10:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhKGsL8VagG5 for ; Wed, 24 Mar 2010 10:03:15 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A2AB83A6872 for ; Wed, 24 Mar 2010 10:03:10 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-31.meeting.ietf.org (dhcp-wireless-open-abg-26-31.meeting.ietf.org [130.129.26.31]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o2OH3MP1005551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Mar 2010 19:03:25 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <7f996c491003240416w63f40f70x1b22d88edffb420@mail.gmail.com> Date: Wed, 24 Mar 2010 10:03:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7f996c491003240416w63f40f70x1b22d88edffb420@mail.gmail.com> To: David Ryan X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] COAP basic implementation. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:03:17 -0000 Awesome David, nice work! We are also working on a couple = implementations in the SENSEI project.=20 On Mar 24, 2010, at 4:16 , David Ryan wrote: >=20 > One of the questions that came up during implementation was what is a > malformed request? How does the server tell and under what situations > should an error response be sent? =20 These need to be defined, contribs welcome.=20 > Also, should a request have to come > from a client using the COAP port, or should the server send responses > to the client port that sent it? The latter.=20 Zach >=20 > You can find the download under Colony COAP near the bottom of > http://www.einet.com.au/Downloads >=20 > Comments and feedback appreciated. >=20 > Regards, > David. >=20 >=20 > On Fri, Mar 19, 2010 at 10:01 AM, David Ryan wrote: >> Hi All, >>=20 >> I sent the following questions and feedback to Brian and Zach who >> suggested I forward this to the list for further discussion. I won't >> be at the meeting in Anaheim next week, so here's my input. >>=20 >> First off, a question regarding the compression of the protocol. >> You've managed to compress the header into 4 bytes. Obviously the >> size of the header is going to be important. In the priority list of >> features, is this the most important? Would another byte or two = hurt? >>=20 >> I notice between Chopan and COAP you've dropped the magic number >> headers. This must have been a conscious decision. I would have = liked >> to see a one byte magic value to identify the packet or TCP stream. >> This would at least give a server a chance to throw away the request >> if it receives a bad message. >>=20 >> In regard to version. Two bits only leaves four possible versions. >> Extending this to 4 bits would at least extend this to 16 versions. >> This goes back to the original point regarding size of header. >>=20 >> Back in 2008 I did a thought experiment on a binary REST based >> protocol. Details available at: >>=20 >> = http://blog.livemedia.com.au/search?updated-min=3D2008-01-01T00%3A00%3A00%= 2B11%3A00&updated-max=3D2009-01-01T00%3A00%3A00%2B11%3A00&max-results=3D7 >>=20 >> Many of the elements are not applicable to COAP, but there might be >> one or two features I developed which could be worth discussing. >>=20 >> One element of this through experiment was to include a = "slotsAvailable" >> in the response. As the "transactionid" field allows multiple >> requests to be sent to a single recipient, the "slotsAvailable" in = the >> response allows a client to limit the number of requests sent. I'd >> suggest 4 bits in the response. If the server can handle more than = 16 >> requests it can return 16 in all responses. A small device might >> return 1 at all times. >>=20 >> Another concept I thought about was to have a bit field for protocol >> features. This may not be applicable in this case, however, = something >> to put on the back burner. The idea is that a small device might = only >> respond to a limited set of features (or options). A bit field can = be >> used to identify in the request which features are being used and in >> the response what features the server can handle. >>=20 >> I was also surprised that the protocol doesn't include the URI path = in >> the main part of the header. I must admit I'm still trying to >> understand how the index based approach to URI paths will work in = your >> proposal. >>=20 >> I tried taking your proposal and combined it with a few of the above >> changes and came up with the following: >>=20 >> Packet >> preamble/magic (1 byte) >>=20 >> version (4 bits) >> features (4 bits) >>=20 >> response (1 bit) >> options (1 bit) >> asynchronous (1 bit) >> locationType (1 bit) (0 URI location field enabled, 1 location >> specified in options) >> method/slots (4 bits) (method type in request/slots available in = response) >>=20 >> transactionId (16 bits) >>=20 >> location (URI location if locationType 0) >>=20 >> options length (8 bits - length) >> ... options ... >>=20 >> payload length (variable length int) >> ...payload data... >>=20 >>=20 >> The base header in this case is 5 bytes instead of the 4 bytes. >>=20 >> I also suggested that the number of options is at the start of the >> options list. This allows the server to quickly decide if the packet >> can be handled and all the option list can be processed. In a >> constrained device only a selected number of options could be >> processed. This removes the need for the 0 byte end of options byte. >>=20 >> I have also used a variable length integer for the payload. This is >> to allow the protocol to move to TCP with larger packets. >>=20 >> Regards, >> David. >>=20 >>=20 >> On Tue, Mar 2, 2010 at 8:30 AM, Zach Shelby = wrote: >>> http://www.ietf.org/id/draft-shelby-core-coap-00.txt >>>=20 >>> Here is a very early draft of a CoAP protocol specification based on = the requirements and initial ideas formulated in = draft-shelby-core-coap-req-00 and the previous work by Brian in = draft-frank-6lowapp-chopan. Looking forward to lots of good discussion = around CoAP, and as you can see from all the TODOs and TBDs - lots of WG = stuff to do here! >>>=20 >>> At the same time I'd like to request a time-slot to present this in = Anaheim. >>>=20 >>> Zach >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: IETF I-D Submission Tool >>>> Date: March 1, 2010 23:24:35 GMT+02:00 >>>> To: zach@sensinode.com >>>> Cc: brian.tridium@gmail.com >>>> Subject: New Version Notification for draft-shelby-core-coap-00 >>>>=20 >>>>=20 >>>> A new version of I-D, draft-shelby-core-coap-00.txt has been = successfuly submitted by Zach Shelby and posted to the IETF repository. >>>>=20 >>>> Filename: draft-shelby-core-coap >>>> Revision: 00 >>>> Title: Constrained Application Protocol (CoAP) >>>> Creation_date: 2010-03-01 >>>> WG ID: Independent Submission >>>> Number_of_pages: 17 >>>>=20 >>>> Abstract: >>>> This document specifies the Constrained Application Protocol = (CoAP), >>>> a RESTful protocol for use with constrained networks and nodes. = 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. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat. >>>>=20 >>>>=20 >>>=20 >>> -- >>> http://www.sensinode.com >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" >>> Mobile: +358 40 7796297 >>>=20 >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti, FINLAND >>>=20 >>> This e-mail and all attached material are confidential and may = contain legally privileged information. If you are not the intended = recipient, please contact the sender and delete the e-mail from your = system without producing, distributing or retaining copies thereof. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From cabo@tzi.org Thu Mar 25 06:31:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9727C3A689D for ; Thu, 25 Mar 2010 06:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.048 X-Spam-Level: X-Spam-Status: No, score=-4.048 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC8j6LCuHHHD for ; Thu, 25 Mar 2010 06:31:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 145FB3A6820 for ; Thu, 25 Mar 2010 06:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o2PDV83R005714 for ; Thu, 25 Mar 2010 14:31:08 +0100 (CET) Received: from dhcp-wireless-open-abg-24-141.meeting.ietf.org (dhcp-wireless-open-abg-24-141.meeting.ietf.org [130.129.24.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 9B62CE5C0; Thu, 25 Mar 2010 14:31:07 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 06:31:03 -0700 To: core@ietf.org Message-Id: <5F4A8C83-5914-4A45-9945-1E381C7AE7DA@tzi.org> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [core] Slides for IETF77 available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 13:31:06 -0000 I have uploaded the slideset for the CoRE meeting at IETF77: http://www.ietf.org/proceedings/10mar/slides/core-0.pdf Presenters: If the slides you want to present are not in there (or are = the wrong version), now would be a good time to send me an update! See you at 0900T (1600Z) in room California C! If you can't be there, the audio is at: http://videolab.uoregon.edu/events/ietf/ietf773.m3u and the Jabber room at: xmpp:core@jabber.ietf.org?join Gruesse, Carsten From fluffy@cisco.com Thu Mar 25 10:28:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F17B3A6E9B for ; Thu, 25 Mar 2010 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.993 X-Spam-Level: X-Spam-Status: No, score=-107.993 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWSP7G9e4rkk for ; Thu, 25 Mar 2010 10:28:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5A0D83A6EA0 for ; Thu, 25 Mar 2010 10:18:45 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEMAO03q0urR7Hu/2dsb2JhbACbKHADpi6ZDoR9BIMe X-IronPort-AV: E=Sophos;i="4.51,308,1267401600"; d="scan'208";a="311698106" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2010 17:18:58 +0000 Received: from [10.21.76.101] ([10.21.76.101]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2PHIrFP005149 for ; Thu, 25 Mar 2010 17:18:53 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 10:18:53 -0700 Message-Id: To: core@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [core] additional slides X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:28:21 -0000 some new slides have been uploaded for a later talk = athttp://www.ietf.org/proceedings/10mar/slides/core-1.pdf = andhttp://www.ietf.org/proceedings/10mar/slides/core-2.ppt From stpeter@stpeter.im Thu Mar 25 11:37:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A343A6D5D for ; Thu, 25 Mar 2010 11:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv-gumNxGvMs for ; Thu, 25 Mar 2010 11:37:10 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E52E93A6BBD for ; Thu, 25 Mar 2010 11:35:07 -0700 (PDT) Received: from dhcp-wireless-open-abg-29-126.meeting.ietf.org (128-107-239-233.cisco.com [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD27340E15 for ; Thu, 25 Mar 2010 12:35:29 -0600 (MDT) Message-ID: <4BABACF0.6000008@stpeter.im> Date: Thu, 25 Mar 2010 11:35:28 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: core@ietf.org X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070508010008050204010509" Subject: [core] i18n? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:37:14 -0000 This is a cryptographically signed message in MIME format. --------------ms070508010008050204010509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I noticed discussion of naming, URIs, and the like. Will we have internationalization issues? Folks here might want to pay attention to the newprep discussions: https://www.ietf.org/mailman/listinfo/newprep Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070508010008050204010509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMyNTE4MzUyOFowIwYJKoZIhvcNAQkEMRYEFPpvxSHaSqMT/r87yraE SimldrbzMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAHb2j4YO2RFlMGoVy8W7L0qjL5nxjVW5peNVk63lY g0BxUSTxCmzoP+oHWr3CXPzmm8rW9Gad4zThutw0OWMwwNRE/LhShmGMr3xBkaTW2lKxgsfs yr6KGyQw+VO6urWzNDukN9z9UnF6fbxYP5lEY7jgElhbLp6ZO03OYGh1m0XqpyqAKY5FVRtj icv3kTsDzyx1/geXKMkvwDZZLT9J8zCcNpticKOVxHRwgkTr7EeWsByKyg4vKl8w3o80hzL7 kevp7KWTIY6whhLVP8ZwJtVbrnsm0jRHSfVaQtxFPr4+Wnsa6UkT+mWa4BVar+hM9AIVylav xi1NT/IGt5c4JwAAAAAAAA== --------------ms070508010008050204010509-- From tena@huawei.com Thu Mar 25 11:37:46 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2453A6EAB for ; Thu, 25 Mar 2010 11:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.925 X-Spam-Level: X-Spam-Status: No, score=-96.925 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyBdYJwPqYU2 for ; Thu, 25 Mar 2010 11:37:45 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 492F63A68D1 for ; Thu, 25 Mar 2010 11:35:50 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZU008IGP01TS@szxga02-in.huawei.com> for core@ietf.org; Fri, 26 Mar 2010 02:36:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZU0083MP01MK@szxga02-in.huawei.com> for core@ietf.org; Fri, 26 Mar 2010 02:36:01 +0800 (CST) Received: from dhcp-wireless-open-abg-25-219.meeting.ietf.org (dhcp-wireless-open-abg-25-219.meeting.ietf.org [130.129.25.219]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZU00LVQOZZ87@szxml02-in.huawei.com>; Fri, 26 Mar 2010 02:36:01 +0800 (CST) Date: Thu, 25 Mar 2010 11:35:53 -0700 From: Tina TSOU To: core@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: multipart/alternative; boundary="Boundary_(ID_bg7uslP/emuNm8eRQ3HstA)" References: <1EC05989-6A92-4A7D-8A11-22B736E83D9C@huawei.com> Cc: Tom Taylor , young Subject: [core] Fwd: Discussion on draft-tsou-network-configuration-problem-statement-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:37:46 -0000 --Boundary_(ID_bg7uslP/emuNm8eRQ3HstA) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi, Here is the link of my draft related to bootstrapping. > Presentation: > > http://www.ietf.org/proceedings/10mar/slides/opsawg-2.ppt > > Problem Statement for Plug-and-Play Deployment of Network Devices > > I-D: > > http://www.ietf.org/id/draft-tsou-network-configuration-problem-statement-03.txt As I said at the mic, there are two aspects in the basic problem, there are more interoperability and security requirement to be considered. They are in my presentations. B. R. Tina http://tinatsou.weebly.com/contact.html Begin forwarded message: > From: Tina TSOU > Date: March 24, 2010 1:06:44 PM PDT > To: opsawg@ietf.org > Cc: Juergen Schoenwaelder > Subject: Discussion on draft-tsou-network-configuration-problem- > statement-03 > > Hi all, > I apologized that I missed the presentation in OPSA WG session I > this morning. It was because that I was about to chair HOKEY session > in California D, when it was item 7 (previous to ours) in OPSA, my > co-author Richard Young went to California D to call me to come, > when we ran into OPSA WG California A, the meeting just finished. > C'est la vie. Another co-author Juergen Schoenwaelder did not come > to Anaheim meeting. > > C'est la vie. > > BTW, this draft will be discussed in WG CORE in California C on Thu > morning session I. > > I talked to Scott, he said we could drop an email to the list for > discussion. > > Presentation: > > http://www.ietf.org/proceedings/10mar/slides/opsawg-2.ppt > > Problem Statement for Plug-and-Play Deployment of Network Devices > > I-D: > > http://www.ietf.org/id/draft-tsou-network-configuration-problem-statement-03.txt > > > B. R. > Tina > http://tinatsou.weebly.com/contact.html > > > > > > > --Boundary_(ID_bg7uslP/emuNm8eRQ3HstA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi, 
Here is the link of my draft related to bootstrapping.



< div>

As I said at the mic, there are two aspects in the basic problem, there are more interoperability and security requirement to be considered.

They are in my presentations.


B. R.
Tina


Begin forwarded message:

From: Tina TSOU <tena@huawei.com>
Date: March 24, 2010 1:06:44 PM PDT
< e="3" color="#000000" style="font: 12.0px Helvetica; color: #000000">Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Subject: Discussion on draft-tsou-network-configuration-problem-statement-03

Hi all,
I apologized that I missed the presentation in OPSA WG session I this morning. It was because that I was ab n in California D, when it was item 7 (previous to ours) in OPSA, my co-author Richard Young went to California D to call me to come, when we ran into OPSA WG California A, the meeting just finished. C'est la vie. Another co-author Juergen Schoenwaelder did not come to Anaheim meeting.

C'est la vie.

BTW, this draft will be discussed in WG CORE in California C on Thu morning session I.

I talked to Scott, he said we could drop an email to the list for discussion.

Presentation:


Problem Statement for Plug-and-Play Deployment of Network Devices

I-D:



--Boundary_(ID_bg7uslP/emuNm8eRQ3HstA)-- From cabo@tzi.org Thu Mar 25 13:20:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4C03A6C88 for ; Thu, 25 Mar 2010 13:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.405 X-Spam-Level: X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjAGM2OhPlwl for ; Thu, 25 Mar 2010 13:20:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id F3AE63A6C40 for ; Thu, 25 Mar 2010 13:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o2PKJvCS019732; Thu, 25 Mar 2010 21:19:57 +0100 (CET) Received: from dhcp-wireless-open-a-41-36.meeting.ietf.org (dhcp-wireless-open-a-41-36.meeting.ietf.org [130.129.41.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id AC6F1E7BA; Thu, 25 Mar 2010 21:19:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4BABACF0.6000008@stpeter.im> Date: Thu, 25 Mar 2010 13:19:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BABACF0.6000008@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] i18n? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 20:20:57 -0000 On Mar 25, 2010, at 11:35, Peter Saint-Andre wrote: > Will we have > internationalization issues?=20 Yes. Anything that uses URIs (or should that be IRIs?) with components that = are naturally user-specified (coap://.../temperature/K=FCche) will have = those issues. That's certainly on the list of things to look at. Gruesse, Carsten From d.sturek@att.net Thu Mar 25 19:26:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403243A67A2 for ; Thu, 25 Mar 2010 19:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.822 X-Spam-Level: ** X-Spam-Status: No, score=2.822 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNTyxwuvhDE9 for ; Thu, 25 Mar 2010 19:26:33 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 917B13A66B4 for ; Thu, 25 Mar 2010 19:26:33 -0700 (PDT) Received: (qmail 69512 invoked from network); 26 Mar 2010 02:26:53 -0000 Received: from adsl-69-224-191-11.dsl.sndg02.pacbell.net (d.sturek@69.224.191.11 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 25 Mar 2010 19:26:53 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: SLMMZCwVM1mOs5_ak9HXW7qY.TbxVN09m0cXv7lFU9PDh5kCiCJ88PB6HQiTQR8sCDWjSnnHYOUmItGAbAB9W.Ya8QdQGmi4nw6nYUiUaIoXba3EtmE2IVI49u_IZS1v69HagzEo4I0eM0IXS5wZQG3lhSkFWkc4OrMJbbc6N8I25b_psxbuXI28rNDXYjBLsvZjfxvjLqo.huTVDMmdF48QFrbtW66TUf2FeVQ_7ndnEOxKQ7bMwv0YfD._BOQVBPINbeUh10B6VlDStQCB1q6MowAQUUfiF0x5Bmr2uLwxnVFWxEI- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , "'Peter Saint-Andre'" References: <4BABACF0.6000008@stpeter.im> In-Reply-To: Date: Thu, 25 Mar 2010 19:26:50 -0700 Message-ID: <015401cacc8b$cad68fa0$6083aee0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrMWLwx8zbsgVtLS5C9s5aVykgKqAAMtDcg Content-Language: en-us Cc: core@ietf.org Subject: Re: [core] i18n? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 02:26:34 -0000 Keep in mind that the IRIs (or URI's?) in constrained devices are = unlikely to be viewed by anyone. It is not likely that anyone with a browser = will be viewing these. Now the data content in the payload is another matter..... Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, March 25, 2010 1:20 PM To: Peter Saint-Andre Cc: core@ietf.org Subject: Re: [core] i18n? On Mar 25, 2010, at 11:35, Peter Saint-Andre wrote: > Will we have > internationalization issues?=20 Yes. Anything that uses URIs (or should that be IRIs?) with components that = are naturally user-specified (coap://.../temperature/K=FCche) will have = those issues. That's certainly on the list of things to look at. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From apezzuto@cisco.com Fri Mar 26 02:09:09 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BEC3A69E9 for ; Fri, 26 Mar 2010 02:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYGIZ6RwsQhd for ; Fri, 26 Mar 2010 02:09:08 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0030E3A6896 for ; Fri, 26 Mar 2010 02:09:06 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJUWrEurR7H+/2dsb2JhbACbK3OlGZkWhH4E X-IronPort-AV: E=Sophos;i="4.51,313,1267401600"; d="scan'208";a="218025394" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2010 09:09:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2Q99FSi025372 for ; Fri, 26 Mar 2010 09:09:30 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 10:09:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {64FBCC09-07E2-4322-8B79-AC01F6C7F929} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: buk= AeBf Dbc5 D5rk ECTs ELQj Evbe FZTg F4MU GMfv GMvV HAWM HZAe H2Ii IwfE I/fM; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {64FBCC09-07E2-4322-8B79-AC01F6C7F929}; YQBwAGUAegB6AHUAdABvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 26 Mar 2010 09:09:25 GMT; QwBvAEEAUAAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzACAAYQBuAGQAIABIAFQAVABQACAAaQB3AGYA Content-class: urn:content-classes:message Date: Fri, 26 Mar 2010 10:09:25 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CoAP requirements and HTTP iwf Thread-Index: AcrMxAgxob0ouQv0SS+I/WEtUZFC5Q== From: "Adriano Pezzuto (apezzuto)" To: X-OriginalArrivalTime: 26 Mar 2010 09:09:28.0649 (UTC) FILETIME=[09F99B90:01CACCC4] Subject: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 09:09:09 -0000 Hello, a great session in Anaheim! For what concerns CoAP and HTTP mapping (REQ7: of draft-shelby-core-coap-req-00), I understood that there is not "the" CoAP-HTTP mapping but more possible ways to do the mapping are possible. Also, further mappings, e.g. CoAP-XMPP, CoAP-SIP, .. might be defined in the future, if required. What about to split the CoAP specs from the CoaP-*P mapping specs? I mean to have different specs for CoAP core protocol, CoAP-HTTP mapping, CoAP-XMPP mapping, CoAP-*P mapping and so on. Not sure if this make sense ... regards, Adriano From Michael.Stuber@itron.com Fri Mar 26 06:37:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6D03A689D for ; Fri, 26 Mar 2010 06:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyNXpJQrZFUU for ; Fri, 26 Mar 2010 06:37:10 -0700 (PDT) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 5CFC63A67F0 for ; Fri, 26 Mar 2010 06:37:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Mar 2010 06:37:33 -0700 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02A97D2B@SPO-EXVS-02.itron.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoAP requirements and HTTP iwf Thread-Index: AcrMxAgxob0ouQv0SS+I/WEtUZFC5QAJNvmw References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> From: "Stuber, Michael" To: "Adriano Pezzuto (apezzuto)" , Subject: Re: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 13:37:11 -0000 A well defined mapping between CoAP and HTTP is a core requirement. >From a document structure standpoint, either way is fine, but I wouldn't want to split it out only to have it languish. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Adriano Pezzuto (apezzuto) Sent: Friday, March 26, 2010 2:09 AM To: core@ietf.org Subject: [core] CoAP requirements and HTTP iwf Hello, a great session in Anaheim! For what concerns CoAP and HTTP mapping (REQ7: of draft-shelby-core-coap-req-00), I understood that there is not "the" CoAP-HTTP mapping but more possible ways to do the mapping are possible. Also, further mappings, e.g. CoAP-XMPP, CoAP-SIP, .. might be defined in the future, if required. What about to split the CoAP specs from the CoaP-*P mapping specs? I mean to have different specs for CoAP core protocol, CoAP-HTTP mapping, CoAP-XMPP mapping, CoAP-*P mapping and so on. Not sure if this make sense ... regards, Adriano _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From d.sturek@att.net Fri Mar 26 06:47:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1803A6405 for ; Fri, 26 Mar 2010 06:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.395 X-Spam-Level: ** X-Spam-Status: No, score=2.395 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa-FWUmYexUK for ; Fri, 26 Mar 2010 06:47:13 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 470E73A63EC for ; Fri, 26 Mar 2010 06:47:12 -0700 (PDT) Received: (qmail 85614 invoked from network); 26 Mar 2010 13:47:30 -0000 Received: from Studio (d.sturek@69.225.120.125 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 26 Mar 2010 06:47:30 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: OsEa0NUVM1lxFxi73pcG56S3CcdlQ2o8IOSAQ13OghWVTBSYYw1ECaiPRWlkt05XykO7fr_mn0KInomz_z55HwL_laKTTtfF60DIm_vy0ucZpWItpVOGGCvSem0ZxRWnMKxMlgQgUQ83wnhNFWodUPl.20yGAVP9ZRZ6xOx4mKqN7kZ66SG9xsCDrd.ku7wUFE4u9oac1mU1z.nnrBhVQ9bihR6kXIn6qiFT3oYRsaH1Rqt4jqy3QAbUzudc4mYAF5QOWV7EN.uaxSGsGLOQau4oRw00We2YKZf4yifJ_VQlpIR4wPDd X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Adriano Pezzuto \(apezzuto\)'" , References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> Date: Fri, 26 Mar 2010 06:47:27 -0700 Message-ID: <009601caccea$e0443360$a0cc9a20$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrMxAgxob0ouQv0SS+I/WEtUZFC5QAJfQ+A Content-Language: en-us Subject: Re: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 13:47:14 -0000 If I recall, the CoRE charter removed the mapping devices (CoGII is what I think they were back in the original CoAP charter). I think CoRE only focused on development of a RESTful architecture implementation over transports that are not constrained to be TCP (ie, UDP is supported). I think we will make a mistake by having a discussion on mapping to HTTP since the discussion below will take place ("what about XMPP mappings", "what about SIP mappings", etc.). If we architect CoRE for mappings to all of these other standards I am doubtful it ever achieves it primary goal of a simple RESTful protocol implementation for constrained devices. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Adriano Pezzuto (apezzuto) Sent: Friday, March 26, 2010 2:09 AM To: core@ietf.org Subject: [core] CoAP requirements and HTTP iwf Hello, a great session in Anaheim! For what concerns CoAP and HTTP mapping (REQ7: of draft-shelby-core-coap-req-00), I understood that there is not "the" CoAP-HTTP mapping but more possible ways to do the mapping are possible. Also, further mappings, e.g. CoAP-XMPP, CoAP-SIP, .. might be defined in the future, if required. What about to split the CoAP specs from the CoaP-*P mapping specs? I mean to have different specs for CoAP core protocol, CoAP-HTTP mapping, CoAP-XMPP mapping, CoAP-*P mapping and so on. Not sure if this make sense ... regards, Adriano _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Fri Mar 26 07:19:51 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112193A68E9 for ; Fri, 26 Mar 2010 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.421 X-Spam-Level: X-Spam-Status: No, score=-4.421 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwPqoJc+L-RW for ; Fri, 26 Mar 2010 07:19:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 346363A68BA for ; Fri, 26 Mar 2010 07:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o2QEJheG013750; Fri, 26 Mar 2010 15:19:43 +0100 (CET) Received: from dhcp-wireless-open-abg-24-141.meeting.ietf.org (dhcp-wireless-open-abg-24-141.meeting.ietf.org [130.129.24.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 01F37EABE; Fri, 26 Mar 2010 15:19:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <009601caccea$e0443360$a0cc9a20$@sturek@att.net> Date: Fri, 26 Mar 2010 07:19:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98F0CF26-BF0E-4D97-9BE4-3C99BE3D7A5C@tzi.org> References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 14:19:51 -0000 On Mar 26, 2010, at 06:47, Don Sturek wrote: > If I recall, the CoRE charter removed the mapping devices (CoGII is = what I > think they were back in the original CoAP charter). =20 Indeed, we got rid of the "CoGII" term, because we don't need to name = the devices that perform this function. However, http://datatracker.ietf.org/wg/core/charter/ says: > The WG will define a > mapping from CoAP to an HTTP REST API; this mapping will not depend on = a > specific application. In other words: -- HTTP mapping in scope -- XMPP etc. mapping out of scope With a view to achieving good protocol quality for CoAP itself, I would = not mind if an individual or group contributed, say, an XMPP mapping = document, and we can spend working group time to discuss how this = informs the development of CoAP. The mapping itself is just not a = deliverable of the WG. Note that the charter also says we can look for = additional items to work on once the current deliverables are done (Jan = 2011), and if we already have such a document and like it, completing it = would be a natural additional work item. Gruesse, Carsten From robert.cragie@gridmerge.com Fri Mar 26 07:51:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4243A6827 for ; Fri, 26 Mar 2010 07:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnig3JtSgHt0 for ; Fri, 26 Mar 2010 07:51:34 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 5E4A13A680F for ; Fri, 26 Mar 2010 07:51:33 -0700 (PDT) Received: from 72-254-61-93.client.stsn.net ([72.254.61.93] helo=[10.7.39.29]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NvAt2-0002Ua-Ce; Fri, 26 Mar 2010 14:51:51 +0000 Message-ID: <4BACC9FF.1010606@gridmerge.com> Date: Fri, 26 Mar 2010 07:51:43 -0700 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: d.sturek@att.net References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net> In-Reply-To: <009601caccea$e0443360$a0cc9a20$@sturek@att.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060204060609050305030601" Cc: core@ietf.org Subject: Re: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 14:51:35 -0000 This is a cryptographically signed message in MIME format. --------------ms060204060609050305030601 Content-Type: multipart/alternative; boundary="------------040307060100040100090405" This is a multi-part message in MIME format. --------------040307060100040100090405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I guess there are two approaches: 1. Do a clean-room protocol design specification based on the specific requirements for CoAP 2. Analyse existing relevant protocols, i.e. HTTP and others (such as those listed by Adrian) and distil the essence of them into the design specification You could summarise these approaches as (1) purist and (2) practical=20 approach. The main issue with (1) is that we could end up with a protocol which=20 doesn't map cleanly to anything. This in itself may not be a problem if=20 mapping essentially always means proxying at an application gateway. The main issue with (2) is what Don says below, i.e. it may be a=20 compromise which doesn't meet the primary requirements. On the other=20 hand, if done correctly, it could provide the optimum protocol for=20 mapping onto a few key existing protocols. One advantage of the RESTful style is that it does provide constraints=20 on a protocol usage, so any existing protocol which can be used=20 RESTfully is probably going to end up mapping at least fairly cleanly to = whatever is developed for CoAP. Regarding HTTP specifically: due to its proliferation, I cannot see how=20 we can avoid putting emphasis on mapping to it, so I actually think what = we are doing now is right, i.e. providing a mapping to HTTP as mandatory = and making mappings to other protocols optional and in separate documents= =2E Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 26/03/2010 6:47 AM, Don Sturek wrote: > If I recall, the CoRE charter removed the mapping devices (CoGII is wha= t I > think they were back in the original CoAP charter). I think CoRE only > focused on development of a RESTful architecture implementation over > transports that are not constrained to be TCP (ie, UDP is supported). > > I think we will make a mistake by having a discussion on mapping to HTT= P > since the discussion below will take place ("what about XMPP mappings",= > "what about SIP mappings", etc.). > > If we architect CoRE for mappings to all of these other standards I am > doubtful it ever achieves it primary goal of a simple RESTful protocol > implementation for constrained devices. > > Don > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= > Adriano Pezzuto (apezzuto) > Sent: Friday, March 26, 2010 2:09 AM > To: core@ietf.org > Subject: [core] CoAP requirements and HTTP iwf > > Hello, > a great session in Anaheim! > > For what concerns CoAP and HTTP mapping (REQ7: of > draft-shelby-core-coap-req-00), I understood that there is not "the" > CoAP-HTTP mapping but more possible ways to do the mapping are possible= =2E > Also, further mappings, e.g. CoAP-XMPP, CoAP-SIP, .. might be > defined in the future, if required. > > What about to split the CoAP specs from the CoaP-*P mapping specs? I > mean to have different specs for CoAP core protocol, CoAP-HTTP mapping,= > CoAP-XMPP mapping, CoAP-*P mapping and so on. > > Not sure if this make sense ... > > regards, > Adriano > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > =20 --------------040307060100040100090405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess there are two approaches:
  1. Do a clean-room protocol design specification based on the specific requirements for CoAP
  2. Analyse existing relevant protocols, i.e. HTTP and others (such as those listed by Adrian) and distil the essence of them into the design specification
You could summarise these approaches as (1) purist and (2) practical approach.

The main issue with (1) is that we could end up with a protocol which doesn't map cleanly to anything. This in itself may not be a problem if mapping essentially always means proxying at an application gateway.
The main issue with (2) is what Don says below, i.e. it may be a compromise which doesn't meet the primary requirements. On the other hand, if done correctly, it could provide the optimum protocol for mapping onto a few key existing protocols.

One advantage of the RESTful style is that it does provide constraints on a protocol usage, so any existing protocol which can be used RESTfully is probably going to end up mapping at least fairly cleanly to whatever is developed for CoAP.

Regarding HTTP specifically: due to its proliferation, I cannot see how we can avoid putting emphasis on mapping to it, so I actually think what we are doing now is right, i.e. providing a mapping to HTTP as mandatory and making mappings to other protocols optional and in separate documents.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 26/03/2010 6:47 AM, Don Sturek wrote: 
If I recall, the CoRE charter removed the mapping device=
s (CoGII is what I
think they were back in the original CoAP charter).  I think CoRE only
focused on development of a RESTful architecture implementation over
transports that are not constrained to be TCP (ie, UDP is supported).

I think we will make a mistake by having a discussion on mapping to HTTP
since the discussion below will take place ("what about XMPP mappings",
"what about SIP mappings", etc.). =20

If we architect CoRE for mappings to all of these other standards I am
doubtful it ever achieves it primary goal of a simple RESTful protocol
implementation for constrained devices.

Don


-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of
Adriano Pezzuto (apezzuto)
Sent: Friday, March 26, 2010 2:09 AM
To: c=
ore@ietf.org
Subject: [core] CoAP requirements and HTTP iwf

Hello,
a great session in Anaheim!

For what concerns CoAP and HTTP mapping (REQ7: of
draft-shelby-core-coap-req-00), I understood that there is not "the"
CoAP-HTTP mapping but more possible ways to do the mapping are possible.
Also, further mappings, e.g.  CoAP-XMPP,   CoAP-SIP, ..  might be
defined in the future, if required.

What about to split the CoAP specs from the  CoaP-*P mapping specs? I
mean to have different specs for CoAP core protocol, CoAP-HTTP mapping,
CoAP-XMPP mapping, CoAP-*P mapping and so on.

Not sure if this make sense ...

regards,
Adriano
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------040307060100040100090405-- --------------ms060204060609050305030601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MjYxNDUxNDNaMCMGCSqGSIb3DQEJBDEWBBRFty7dCCGO13Rb96u5R1bdMQ+SVzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAA2P0e3iV7wwZK3U3KFmyNJnYgAzQj0BalgMbxBYptL0sE2PtrBxSPVBsrP46+0aKqN0 HRnqmwFyhgAwnZvHMRm4O9vssY4ypeRo6TnSoRXglFtebsYxAblWSFRi/kGNxKZOg5cBZhGv PeNy19gAWfhopJ8i6O26CCw4By6hb/bWXY3zhrAeFrAZZr+d6oA0E6eibYODBNSBDXI2YxBY Z79pLJ89nNxic/sRlNWbdiC5rKlz/wkVTgI9YI54bskJQzDnziRrRi9vvm70vgwFVng6NURd UujDzx3fQ4TNn37XCkiOC6c1DCN22Qpt1+6m171TEpY77eQ9kn9wJTrLaJ8AAAAAAAA= --------------ms060204060609050305030601-- From d.sturek@att.net Fri Mar 26 07:53:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC31E3A6B11 for ; Fri, 26 Mar 2010 07:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.869 X-Spam-Level: ** X-Spam-Status: No, score=2.869 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFokg90ARiu1 for ; Fri, 26 Mar 2010 07:53:44 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3DAFD3A680F for ; Fri, 26 Mar 2010 07:53:44 -0700 (PDT) Received: (qmail 7633 invoked from network); 26 Mar 2010 14:54:05 -0000 Received: from adsl-69-225-120-125.dsl.sndg02.pacbell.net (d.sturek@69.225.120.125 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2010 07:54:04 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 8iKa1jUVM1kVEMzIDUHU_f8hHOhDiym_ZjpHcN0_0snZXjwguQXxpOtHdyr.SGN83RPOQLYJ8H4ucsKwu9IafSQOak8dCtNNqqA29rh3pF7QKHD76b7CpmvINCnefEoqpBaNinQsSiqPJlWCn3HRHDlTzXGT6K48Bn9CkwRxVOQE_qP8nYGpJCK9NjbNTBtzf2LT5FuMjen6yu_INWEAXe7o34VcXKAdJ3TxACX0ad5C2MyIKIhd3auZB4y74iySvd9jo0UmQsy.0DGFkr7t8mpv4FZSkFLlKc9RvoefR60HjbGB.A-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net> <4BACC9FF.1010606@gridmerge.com> In-Reply-To: <4BACC9FF.1010606@gridmerge.com> Date: Fri, 26 Mar 2010 07:54:02 -0700 Message-ID: <00c901caccf4$2d066200$87132600$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CACCB9.80A78A00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrM89/1ytwzZxXzRh+eeuO529OMNgAABOcA Content-Language: en-us Cc: core@ietf.org Subject: Re: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 14:53:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01CACCB9.80A78A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, I am fine with having the CoRE mapping to HTTP in the charter. I forgot it was still there after CoGII was removed. My point is that I would not want to try to have mappings to HTTP, SIP, XMPP as I don't think we would actually get anything done. Don From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: Friday, March 26, 2010 7:52 AM To: d.sturek@att.net Cc: 'Adriano Pezzuto (apezzuto)'; core@ietf.org Subject: Re: [core] CoAP requirements and HTTP iwf I guess there are two approaches: 1. Do a clean-room protocol design specification based on the specific requirements for CoAP 2. Analyse existing relevant protocols, i.e. HTTP and others (such as those listed by Adrian) and distil the essence of them into the design specification You could summarise these approaches as (1) purist and (2) practical approach. The main issue with (1) is that we could end up with a protocol which doesn't map cleanly to anything. This in itself may not be a problem if mapping essentially always means proxying at an application gateway. The main issue with (2) is what Don says below, i.e. it may be a compromise which doesn't meet the primary requirements. On the other hand, if done correctly, it could provide the optimum protocol for mapping onto a few key existing protocols. One advantage of the RESTful style is that it does provide constraints on a protocol usage, so any existing protocol which can be used RESTfully is probably going to end up mapping at least fairly cleanly to whatever is developed for CoAP. Regarding HTTP specifically: due to its proliferation, I cannot see how we can avoid putting emphasis on mapping to it, so I actually think what we are doing now is right, i.e. providing a mapping to HTTP as mandatory and making mappings to other protocols optional and in separate documents. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 26/03/2010 6:47 AM, Don Sturek wrote: If I recall, the CoRE charter removed the mapping devices (CoGII is what I think they were back in the original CoAP charter). I think CoRE only focused on development of a RESTful architecture implementation over transports that are not constrained to be TCP (ie, UDP is supported). I think we will make a mistake by having a discussion on mapping to HTTP since the discussion below will take place ("what about XMPP mappings", "what about SIP mappings", etc.). If we architect CoRE for mappings to all of these other standards I am doubtful it ever achieves it primary goal of a simple RESTful protocol implementation for constrained devices. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Adriano Pezzuto (apezzuto) Sent: Friday, March 26, 2010 2:09 AM To: core@ietf.org Subject: [core] CoAP requirements and HTTP iwf Hello, a great session in Anaheim! For what concerns CoAP and HTTP mapping (REQ7: of draft-shelby-core-coap-req-00), I understood that there is not "the" CoAP-HTTP mapping but more possible ways to do the mapping are possible. Also, further mappings, e.g. CoAP-XMPP, CoAP-SIP, .. might be defined in the future, if required. What about to split the CoAP specs from the CoaP-*P mapping specs? I mean to have different specs for CoAP core protocol, CoAP-HTTP mapping, CoAP-XMPP mapping, CoAP-*P mapping and so on. Not sure if this make sense ... regards, Adriano _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_00CA_01CACCB9.80A78A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

I am fine with having the CoRE mapping to HTTP in the = charter.  I forgot it was still there after CoGII was = removed.

 

My point is that I would not want to try to have mappings = to HTTP, SIP, XMPP as I don’t think we would actually get anything = done.

 

Don

 

From: Robert Cragie = [mailto:robert.cragie@gridmerge.com]
Sent: Friday, March 26, 2010 7:52 AM
To: d.sturek@att.net
Cc: 'Adriano Pezzuto (apezzuto)'; core@ietf.org
Subject: Re: [core] CoAP requirements and HTTP = iwf

 

I guess there are two approaches:

  1. Do a clean-room protocol design = specification based on the specific requirements for CoAP
  2. Analyse existing relevant protocols, i.e. = HTTP and others (such as those listed by Adrian) and distil the essence = of them into the design specification

You could summarise = these approaches as (1) purist and (2) practical approach.

The main issue with (1) is that we could end up with a protocol which = doesn't map cleanly to anything. This in itself may not be a problem if mapping essentially always means proxying at an application gateway.
The main issue with (2) is what Don says below, i.e. it may be a = compromise which doesn't meet the primary requirements. On the other hand, if done correctly, it could provide the optimum protocol for mapping onto a few = key existing protocols.

One advantage of the RESTful style is that it does provide constraints = on a protocol usage, so any existing protocol which can be used RESTfully is probably going to end up mapping at least fairly cleanly to whatever is developed for CoAP.

Regarding HTTP specifically: due to its proliferation, I cannot see how = we can avoid putting emphasis on mapping to it, so I actually think what we are = doing now is right, i.e. providing a mapping to HTTP as mandatory and making = mappings to other protocols optional and in separate documents.

Robert

Robert Cragie (Pacific Gas & = Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 26/03/2010 6:47 AM, Don Sturek wrote: 

If I recall, the CoRE charter removed the mapping devices (CoGII is =
what I
think they were back in the original CoAP =
charter).  I think CoRE only
focused on =
development of a RESTful architecture implementation =
over
transports that are not constrained to be TCP =
(ie, UDP is =
supported).
 
I think we =
will make a mistake by having a discussion on mapping to =
HTTP
since the discussion below will take place =
("what about XMPP mappings",
"what =
about SIP mappings", etc.).  =

 
If we architect CoRE =
for mappings to all of these other standards I =
am
doubtful it ever achieves it primary goal of a =
simple RESTful protocol
implementation for =
constrained =
devices.
 
Don<=
/pre>
 
 
-----Or=
iginal Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =
On Behalf Of
Adriano Pezzuto =
(apezzuto)
Sent: Friday, March 26, 2010 2:09 =
AM
To: core@ietf.org
Subj=
ect: [core] CoAP requirements and HTTP =
iwf
 
Hello,
a great session in =
Anaheim!
 
For what =
concerns CoAP and HTTP mapping (REQ7: =
of
draft-shelby-core-coap-req-00), I understood =
that there is not "the"
CoAP-HTTP mapping =
but more possible ways to do the mapping are =
possible.
Also, further mappings, e.g.  =
CoAP-XMPP,   CoAP-SIP, ..  might =
be
defined in the future, if =
required.
 
What about to =
split the CoAP specs from the  CoaP-*P mapping specs? =
I
mean to have different specs for CoAP core =
protocol, CoAP-HTTP mapping,
CoAP-XMPP mapping, =
CoAP-*P mapping and so =
on.
 
Not sure if this =
make sense =
...
 
regards,<=
/pre>
Adriano
__________________________________=
_____________
core mailing =
list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
_______________________________________________
co=
re mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
 
------=_NextPart_000_00CA_01CACCB9.80A78A00-- From mark@coactus.com Fri Mar 26 09:08:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476AC3A6B80 for ; Fri, 26 Mar 2010 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.847 X-Spam-Level: X-Spam-Status: No, score=-100.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8L9IpVkS7pZ for ; Fri, 26 Mar 2010 09:08:06 -0700 (PDT) Received: from mail-px0-f197.google.com (mail-px0-f197.google.com [209.85.216.197]) by core3.amsl.com (Postfix) with ESMTP id 946CA3A6B9E for ; Fri, 26 Mar 2010 09:06:54 -0700 (PDT) Received: by pxi35 with SMTP id 35so7166598pxi.19 for ; Fri, 26 Mar 2010 09:07:14 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.231.152.144 with HTTP; Fri, 26 Mar 2010 09:07:13 -0700 (PDT) Date: Fri, 26 Mar 2010 12:07:13 -0400 X-Google-Sender-Auth: aef044a20ddda6e2 Received: by 10.141.12.7 with SMTP id p7mr1063977rvi.235.1269619634021; Fri, 26 Mar 2010 09:07:14 -0700 (PDT) Message-ID: From: Mark Baker To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:08:07 -0000 Hello. I've seen a handful of HTTP-like protocols over UDP proposed, but I'm curious why I haven't seen any mention of doing plain old HTTP over UDP, like this; http://tools.ietf.org/html/draft-goland-http-udp-00 Has such an approach been considered and rejected? Mark. From hgs@cs.columbia.edu Fri Mar 26 09:09:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5C33A6B77 for ; Fri, 26 Mar 2010 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.876 X-Spam-Level: X-Spam-Status: No, score=-3.876 tagged_above=-999 required=5 tests=[AWL=1.593, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdCDMoHyMz+j for ; Fri, 26 Mar 2010 09:09:15 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id E35693A69D1 for ; Fri, 26 Mar 2010 09:08:06 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2QG8R9E011081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Mar 2010 12:08:29 -0400 (EDT) References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net> <98F0CF26-BF0E-4D97-9BE4-3C99BE3D7A5C@tzi.org> In-Reply-To: <98F0CF26-BF0E-4D97-9BE4-3C99BE3D7A5C@tzi.org> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <3DE72B4F-CCF4-409C-B37F-6A031156CD20@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Date: Fri, 26 Mar 2010 12:08:27 -0400 To: Carsten Bormann X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: core@ietf.org Subject: Re: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:09:16 -0000 Given the rather awkward ways that HTTP provides event notification, I = think the technically sensible notion is to have a combination of an = event-based mechanism (SIP, XMPP) with a get/set protocol (HTTP). Henning On Mar 26, 2010, at 10:19 AM, Carsten Bormann wrote: > On Mar 26, 2010, at 06:47, Don Sturek wrote: >=20 >> If I recall, the CoRE charter removed the mapping devices (CoGII is = what I >> think they were back in the original CoAP charter). =20 >=20 > Indeed, we got rid of the "CoGII" term, because we don't need to name = the devices that perform this function. However, > http://datatracker.ietf.org/wg/core/charter/ > says: >=20 >> The WG will define a >> mapping from CoAP to an HTTP REST API; this mapping will not depend = on a >> specific application. >=20 > In other words: > -- HTTP mapping in scope > -- XMPP etc. mapping out of scope >=20 > With a view to achieving good protocol quality for CoAP itself, I = would not mind if an individual or group contributed, say, an XMPP = mapping document, and we can spend working group time to discuss how = this informs the development of CoAP. The mapping itself is just not a = deliverable of the WG. Note that the charter also says we can look for = additional items to work on once the current deliverables are done (Jan = 2011), and if we already have such a document and like it, completing it = would be a natural additional work item. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From apezzuto@cisco.com Fri Mar 26 09:13:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2043A6B78 for ; Fri, 26 Mar 2010 09:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.169 X-Spam-Level: X-Spam-Status: No, score=-8.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pYf4LFfKNv0 for ; Fri, 26 Mar 2010 09:13:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3E08A3A6B9B for ; Fri, 26 Mar 2010 09:12:07 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAPB5rEuQ/uCWe2dsb2JhbACbJhUBAQsLJAYcpyyZGIR+BA X-IronPort-AV: E=Sophos;i="4.51,315,1267401600"; d="scan'208";a="58613149" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2010 16:12:29 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2QGCSZf003392; Fri, 26 Mar 2010 16:12:29 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 17:12:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Mar 2010 17:12:26 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC0196C6C9@XMB-AMS-106.cisco.com> In-Reply-To: <4BACC9FF.1010606@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoAP requirements and HTTP iwf Thread-Index: AcrM8+imKFo+hcInTxmJ7MsPLzaxLQAA/4+A References: <0D212BD466921646B58854FB79092CEC0196C3BC@XMB-AMS-106.cisco.com> <009601caccea$e0443360$a0cc9a20$@sturek@att.net> <4BACC9FF.1010606@gridmerge.com> From: "Adriano Pezzuto (apezzuto)" To: , X-OriginalArrivalTime: 26 Mar 2010 16:12:27.0986 (UTC) FILETIME=[213D1B20:01CACCFF] Subject: Re: [core] CoAP requirements and HTTP iwf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:13:53 -0000 > Regarding HTTP specifically: due to its proliferation, I cannot see = how we can avoid putting emphasis on mapping to it, so I actually > think what we are doing now is right, i.e. providing a mapping to HTTP = as mandatory and making mappings to other protocols optional and > in separate documents. Agree. Due to HTTP ubiquity, a good CoAP-HTTP mapping looks one of the key = requirement for CoAP success. Other mappings are optional and not = necessarily within this WG. Adriano -----Original Message----- From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: venerd=EC 26 marzo 2010 15.52 To: d.sturek@att.net Cc: Adriano Pezzuto (apezzuto); core@ietf.org Subject: Re: [core] CoAP requirements and HTTP iwf I guess there are two approaches: 1. Do a clean-room protocol design specification based on the specific = requirements for CoAP 2. Analyse existing relevant protocols, i.e. HTTP and others (such as = those listed by Adrian) and distil the essence of them into the design = specification You could summarise these approaches as (1) purist and (2) practical = approach. The main issue with (1) is that we could end up with a protocol which = doesn't map cleanly to anything. This in itself may not be a problem if = mapping essentially always means proxying at an application gateway. The main issue with (2) is what Don says below, i.e. it may be a = compromise which doesn't meet the primary requirements. On the other = hand, if done correctly, it could provide the optimum protocol for = mapping onto a few key existing protocols. One advantage of the RESTful style is that it does provide constraints = on a protocol usage, so any existing protocol which can be used = RESTfully is probably going to end up mapping at least fairly cleanly to = whatever is developed for CoAP. Regarding HTTP specifically: due to its proliferation, I cannot see how = we can avoid putting emphasis on mapping to it, so I actually think what = we are doing now is right, i.e. providing a mapping to HTTP as mandatory = and making mappings to other protocols optional and in separate = documents. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com -----Original Message----- On 26/03/2010 6:47 AM, Don Sturek wrote:=20 If I recall, the CoRE charter removed the mapping devices (CoGII is what = I think they were back in the original CoAP charter). I think CoRE only focused on development of a RESTful architecture implementation over transports that are not constrained to be TCP (ie, UDP is supported). I think we will make a mistake by having a discussion on mapping to HTTP since the discussion below will take place ("what about XMPP mappings", "what about SIP mappings", etc.). =20 If we architect CoRE for mappings to all of these other standards I am doubtful it ever achieves it primary goal of a simple RESTful protocol implementation for constrained devices. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Adriano Pezzuto (apezzuto) Sent: Friday, March 26, 2010 2:09 AM To: core@ietf.org Subject: [core] CoAP requirements and HTTP iwf Hello, a great session in Anaheim! For what concerns CoAP and HTTP mapping (REQ7: of draft-shelby-core-coap-req-00), I understood that there is not "the" CoAP-HTTP mapping but more possible ways to do the mapping are possible. Also, further mappings, e.g. CoAP-XMPP, CoAP-SIP, .. might be defined in the future, if required. What about to split the CoAP specs from the CoaP-*P mapping specs? I mean to have different specs for CoAP core protocol, CoAP-HTTP mapping, CoAP-XMPP mapping, CoAP-*P mapping and so on. Not sure if this make sense ... regards, Adriano _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 From robert.cragie@gridmerge.com Fri Mar 26 09:17:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271643A6BB4 for ; Fri, 26 Mar 2010 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRIu7O47BfJH for ; Fri, 26 Mar 2010 09:17:03 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 702BD3A6B53 for ; Fri, 26 Mar 2010 09:15:21 -0700 (PDT) Received: from 72-254-61-93.client.stsn.net ([72.254.61.93] helo=[10.7.39.29]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NvCCF-0006lo-NX for core@ietf.org; Fri, 26 Mar 2010 16:15:44 +0000 Message-ID: <4BACDDAB.9090506@gridmerge.com> Date: Fri, 26 Mar 2010 09:15:39 -0700 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: core@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060605030202020207080003" Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:17:05 -0000 This is a cryptographically signed message in MIME format. --------------ms060605030202020207080003 Content-Type: multipart/alternative; boundary="------------060203010508030607060000" This is a multi-part message in MIME format. --------------060203010508030607060000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable It would seem reasonable to do this but HTTP is quite verbose so the aim = is to compress the verbose text-based HTTP along with the content, which = means that a request/response is more likely to fit into a UDP datagram, = which is the aim for constrained environments. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 26/03/2010 9:07 AM, Mark Baker wrote: > Hello. I've seen a handful of HTTP-like protocols over UDP proposed, > but I'm curious why I haven't seen any mention of doing plain old HTTP > over UDP, like this; > > http://tools.ietf.org/html/draft-goland-http-udp-00 > > Has such an approach been considered and rejected? > > Mark. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > =20 --------------060203010508030607060000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It would seem reasonable to do this but HTTP is quite verbose so the aim is to compress the verbose text-based HTTP along with the content, which means that a request/response is more likely to fit into a UDP datagram, which is the aim for constrained environments.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 26/03/2010 9:07 AM, Mark Baker wrote: 
Hello.  I've seen a handful of HTTP-like protocols over =
UDP proposed,
but I'm curious why I haven't seen any mention of doing plain old HTTP
over UDP, like this;

http://tools.ietf.org/html/draft-goland-http-udp-0=
0

Has such an approach been considered and rejected?

Mark.
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------060203010508030607060000-- --------------ms060605030202020207080003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MjYxNjE1MzlaMCMGCSqGSIb3DQEJBDEWBBSiW7HpHG2IIv6hZJ9mA7+BFJ3EmzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAAAIjQhbpy2y/7ngB1fmyA8++oPCLU9mMON+qy+NcHPu9yRGbihZpDaw3Dzlq/eUUhBg 1T38VzF3zvDRHFVm7Q/LOi0fJT2SpYtU0Y9LjO4u5fFDCt7QayCM90qDBfBesrpiiDM/bVxf OFpnftNh3misp8cxaoMot5TOjDOMZHzCxt4Ce0npt3fBpBxSHKYYE874RjZaOO9EJVB9ffQh HuWvEF/PeN5cej5X0+jhiKKFNbXGG/jo1UaSWZ05KLGgbzzDETn2YFyw/gXKnDZaWKKwILQb RbQU0ig/OWOdtqq8OD5RSMfhiD9JMhTF1b5zr3l+yARpxfnt4uzkZQxwkYkAAAAAAAA= --------------ms060605030202020207080003-- From L.Wood@surrey.ac.uk Fri Mar 26 09:25:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A86B3A6C23 for ; Fri, 26 Mar 2010 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa+MmUvNEw3M for ; Fri, 26 Mar 2010 09:25:37 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 3D9283A6BCC for ; Fri, 26 Mar 2010 09:20:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-5.tower-78.messagelabs.com!1269620421!2659890!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 23863 invoked from network); 26 Mar 2010 16:20:22 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-5.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 26 Mar 2010 16:20:22 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 26 Mar 2010 16:20:21 +0000 From: To: , Date: Fri, 26 Mar 2010 16:20:24 +0000 Thread-Topic: [core] HTTP over UDP Thread-Index: AcrM/pYZcXPNx+GsTFO4BKN6Znua+wAASwkw Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:25:44 -0000 UDP doesn't have the necessary streaming semantics; as soon as the message exceeds one UDP segment, more than UDP can provide is needed. There has been discussion elsewhere of splitting HTTP from TCP and running HTTP over other protocols, including UDP-based protocols that implement the necessary streaming. See http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn L. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Mar= k Baker Sent: 26 March 2010 16:07 To: core Subject: [core] HTTP over UDP Hello. I've seen a handful of HTTP-like protocols over UDP proposed, but I'm curious why I haven't seen any mention of doing plain old HTTP over UDP, like this; http://tools.ietf.org/html/draft-goland-http-udp-00 Has such an approach been considered and rejected? Mark. From mark@coactus.com Fri Mar 26 11:09:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D6B3A6B02 for ; Fri, 26 Mar 2010 11:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.547 X-Spam-Level: X-Spam-Status: No, score=-99.547 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2G7o2atQf1c for ; Fri, 26 Mar 2010 11:09:28 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 685D93A6800 for ; Fri, 26 Mar 2010 11:09:27 -0700 (PDT) Received: by pwi10 with SMTP id 10so5351031pwi.31 for ; Fri, 26 Mar 2010 11:09:48 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.231.152.144 with HTTP; Fri, 26 Mar 2010 11:09:47 -0700 (PDT) In-Reply-To: <4BACDDAB.9090506@gridmerge.com> References: <4BACDDAB.9090506@gridmerge.com> Date: Fri, 26 Mar 2010 14:09:47 -0400 X-Google-Sender-Auth: 11c60fd1e30609cf Received: by 10.142.6.37 with SMTP id 37mr611031wff.129.1269626987411; Fri, 26 Mar 2010 11:09:47 -0700 (PDT) Message-ID: From: Mark Baker To: "robert.cragie" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:09:29 -0000 Robert, On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie wrote: > It would seem reasonable to do this but HTTP is quite verbose so the aim is > to compress the verbose text-based HTTP along with the content, which means > that a request/response is more likely to fit into a UDP datagram, which is > the aim for constrained environments. I understand. I just wanted to check that there wasn't any explicit requirement being violated. FWIW, this group isn't the first to want to do HTTP-like things in a constrained environment. The WAPforum developed a whole stack of HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively deprecate them in 2001, replacing them with the real deal. If anybody's interested, here's their HTTP-like protocol, WSP; http://www.openmobilealliance.net/technical/release_program/docs/Browser_Protocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf The target environment for CoRE is obviously different from that of WAP in some ways, but I think the lesson is the same. Mark. From L.Wood@surrey.ac.uk Fri Mar 26 11:14:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A533A6982 for ; Fri, 26 Mar 2010 11:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.169 X-Spam-Level: X-Spam-Status: No, score=-5.169 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzY7njZ26rpC for ; Fri, 26 Mar 2010 11:14:25 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 827313A6901 for ; Fri, 26 Mar 2010 11:14:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-3.tower-82.messagelabs.com!1269627286!2965263!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 26415 invoked from network); 26 Mar 2010 18:14:47 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-3.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 26 Mar 2010 18:14:47 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 26 Mar 2010 18:14:46 +0000 From: To: , Date: Fri, 26 Mar 2010 18:14:49 +0000 Thread-Topic: [core] HTTP over UDP Thread-Index: AcrND45GQ1CTPMB/TEuradLCdIyVuQAAJafw Message-ID: References: <4BACDDAB.9090506@gridmerge.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core@ietf.org Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:14:27 -0000 http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html section 2.5 covers WSP - and BEEP has similar territory, these days. What lessons do you think WAP taught us? -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Mar= k Baker Sent: 26 March 2010 18:10 To: robert.cragie Cc: core Subject: Re: [core] HTTP over UDP Robert, On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie wrote: > It would seem reasonable to do this but HTTP is quite verbose so the=20 > aim is to compress the verbose text-based HTTP along with the content,=20 > which means that a request/response is more likely to fit into a UDP=20 > datagram, which is the aim for constrained environments. I understand. I just wanted to check that there wasn't any explicit requir= ement being violated. FWIW, this group isn't the first to want to do HTTP-like things in a constr= ained environment. The WAPforum developed a whole stack of HTML/HTTP/TCP/T= LS-like protocols in the late 90s, only to effectively deprecate them in 20= 01, replacing them with the real deal. If anybody's interested, here's the= ir HTTP-like protocol, WSP; http://www.openmobilealliance.net/technical/release_program/docs/Browser_Pr= otocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf The target environment for CoRE is obviously different from that of WAP in = some ways, but I think the lesson is the same. Mark. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Michael.Stuber@itron.com Fri Mar 26 11:29:40 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922A43A6A5A for ; Fri, 26 Mar 2010 11:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-923UEUbej1 for ; Fri, 26 Mar 2010 11:29:39 -0700 (PDT) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 7E4493A6A04 for ; Fri, 26 Mar 2010 11:29:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Mar 2010 11:30:01 -0700 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02A97E7F@SPO-EXVS-02.itron.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] HTTP over UDP Thread-Index: AcrND4+BkBTb106tTUWnQoez523JTAAAYkFg References: <4BACDDAB.9090506@gridmerge.com> From: "Stuber, Michael" To: "Mark Baker" , "robert.cragie" Cc: core Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:29:40 -0000 It's a good point, but the mobile guys have had the advantage of continuingly increasing capabilities at the handset and the network, and a fast refresh cycle. Right now there are around 35 million meters under contract which will have 802.15.4 radios, and are expected to have a minimum service life of 15 years -- 20 in most cases. Deployment is moving forward apace, and the majority of these will be in place by 2012. I full recognize that we may move to the "real deal" on a future generation, but we need CoAP to service what is being installed today. Besides, about the time that today's "internet of things" has taken the leap into bigger CPUs, faster networks, and generally less constrained devices, somebody will decide that want to do IPv6 to cardboard boxes or shoes, or something else where costs will dictate the use of tiny constrained parts -- ones that will presumably be an order of magnitude cheaper at that point. I think they'll be uses for CoAP for a very long time. As long as we continue to push technology into smaller, cheaper, and more ubiquitous locations, it can add value. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Mark Baker Sent: Friday, March 26, 2010 11:10 AM To: robert.cragie Cc: core Subject: Re: [core] HTTP over UDP Robert, On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie wrote: > It would seem reasonable to do this but HTTP is quite verbose so the=20 > aim is to compress the verbose text-based HTTP along with the content, > which means that a request/response is more likely to fit into a UDP=20 > datagram, which is the aim for constrained environments. I understand. I just wanted to check that there wasn't any explicit requirement being violated. FWIW, this group isn't the first to want to do HTTP-like things in a constrained environment. The WAPforum developed a whole stack of HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively deprecate them in 2001, replacing them with the real deal. If anybody's interested, here's their HTTP-like protocol, WSP; http://www.openmobilealliance.net/technical/release_program/docs/Browser _Protocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf The target environment for CoRE is obviously different from that of WAP in some ways, but I think the lesson is the same. Mark. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Fri Mar 26 11:33:56 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634C53A6C32 for ; Fri, 26 Mar 2010 11:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS0RNimR9NRT for ; Fri, 26 Mar 2010 11:33:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2973E3A6B45 for ; Fri, 26 Mar 2010 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o2QIY3NZ010019; Fri, 26 Mar 2010 19:34:03 +0100 (CET) Received: from dhcp-wireless-open-a-41-36.meeting.ietf.org (dhcp-wireless-open-a-41-36.meeting.ietf.org [130.129.41.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2896CEB77; Fri, 26 Mar 2010 19:34:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 26 Mar 2010 11:33:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7176665E-C3E5-469E-AFFC-50701E340089@tzi.org> References: <4BACDDAB.9090506@gridmerge.com> To: X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:33:56 -0000 On Mar 26, 2010, at 11:14, wrote: > What lessons do you think WAP taught us? One could write a book about that. The most significant contributor to the failure of WAP was the attempt = to reinvent HTML (i.e., WML). Also contributing: -- heavy mission creep (WAP was originally designed to run atop SMS!) -- error 33 -- see http://en.wikipedia.org/wiki/Error_33 -- failure to anticipate the importance of IP CoRE is set up with a view to not making any of these mistakes. Gruesse, Carsten From d.sturek@att.net Fri Mar 26 11:34:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EF33A68C3 for ; Fri, 26 Mar 2010 11:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.488 X-Spam-Level: * X-Spam-Status: No, score=1.488 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGI5vNfOsdRv for ; Fri, 26 Mar 2010 11:34:57 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id 6AAB73A680E for ; Fri, 26 Mar 2010 11:34:57 -0700 (PDT) Received: (qmail 92536 invoked from network); 26 Mar 2010 18:35:18 -0000 Received: from Studio (d.sturek@69.225.120.125 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 26 Mar 2010 11:35:18 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: HzPaRVQVM1mAHdfGFZY_8rCIprffs_Pv6XfA3EOZ2h75L_ffOm5GyQ6RBhXVKgwC0iaurgul8TjNQz69kCV.gs.iSIKQvsHoFhdvKaqv8MppiUkhTsbcv7crSp64yK9pK07fWCijErF2GO.jAvmezkyboD1rG3GkU75hbB4DEbPgRzwpkaUqpH0I20OUw90y83Q0fpoj_euZB0SUEQwHgkJ3nY2g2cRAQZPr9oPe7jG5qMajbRGDuIAZdI.92SvKdEKL7VN9skaTyooXRw8GuvoPX8aC.0odeQA9pumb.1CIKeg.8A-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: , , References: <4BACDDAB.9090506@gridmerge.com> In-Reply-To: Date: Fri, 26 Mar 2010 11:35:15 -0700 Message-ID: <017c01cacd13$14aaa1c0$3dffe540$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrND45GQ1CTPMB/TEuradLCdIyVuQAAJafwAACf2eA= Content-Language: en-us Cc: core@ietf.org Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:34:58 -0000 Actually, WAP taught us a few very important lessons (having worked in cellular in the past): 1) There is an actual market for web services on phones. While obvious today, it was not obvious at the time 2) Chipset vendors and handset vendors can actually produce platforms that can support things like full HTML, HTTP, etc in a cost effective manner that meets the cost demands of the consumer space and contain features that people will pay for. I don't think any of the above was obvious when WAP was born. I am unclear todays HTTP/HTML phones would have existed without the experience of the cellular industry with WAP. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of L.Wood@surrey.ac.uk Sent: Friday, March 26, 2010 11:15 AM To: distobj@acm.org; robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] HTTP over UDP http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html section 2.5 covers WSP - and BEEP has similar territory, these days. What lessons do you think WAP taught us? -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Mark Baker Sent: 26 March 2010 18:10 To: robert.cragie Cc: core Subject: Re: [core] HTTP over UDP Robert, On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie wrote: > It would seem reasonable to do this but HTTP is quite verbose so the > aim is to compress the verbose text-based HTTP along with the content, > which means that a request/response is more likely to fit into a UDP > datagram, which is the aim for constrained environments. I understand. I just wanted to check that there wasn't any explicit requirement being violated. FWIW, this group isn't the first to want to do HTTP-like things in a constrained environment. The WAPforum developed a whole stack of HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively deprecate them in 2001, replacing them with the real deal. If anybody's interested, here's their HTTP-like protocol, WSP; http://www.openmobilealliance.net/technical/release_program/docs/Browser_Pro tocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf The target environment for CoRE is obviously different from that of WAP in some ways, but I think the lesson is the same. Mark. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From shidan@gmail.com Fri Mar 26 11:49:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D533A6A2F for ; Fri, 26 Mar 2010 11:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swbX4a+Sfz6J for ; Fri, 26 Mar 2010 11:49:16 -0700 (PDT) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by core3.amsl.com (Postfix) with ESMTP id 61AFD3A69B8 for ; Fri, 26 Mar 2010 11:49:16 -0700 (PDT) Received: by ewy21 with SMTP id 21so2284329ewy.5 for ; Fri, 26 Mar 2010 11:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=P7nanBuWMyAttOff4cR4jQqtMzT8zcMpDfspQk+xfXg=; b=hDU5hHo82bkvjjB+hAtJY34BhmYpnom87fgf38JuyTe6h7G004BEvsztxrdcD26gzh FqDYx+CgUXLpCvyuQasDHFg8rw2bz+QrPLOB9LytV9L4ksE1znnbajNnlSTUymA4oI2P xrPADyuVQnIncWQ70MAbCtNUeBRRyhtYVimAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=H7/ramYrltLUCXwoL1FhBgiSLWc5spz0BWvuEqjQvh/L/aFIhMHLdqHTUyNSTDHa7V pQHyXctgHFGrKcrRyV/nr6ufR983NpKF9+PiGug8qB7L1ea2Tkfv5HazcktEEOJxnFrY qUeGYCG/8H5DmrMIXi4Ey017cq0x8bfqfm61k= Received: by 10.213.44.5 with SMTP id y5mr768930ebe.99.1269629374929; Fri, 26 Mar 2010 11:49:34 -0700 (PDT) Received: from [10.140.213.16] ([24.114.232.27]) by mx.google.com with ESMTPS id 15sm805106ewy.0.2010.03.26.11.49.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Mar 2010 11:49:34 -0700 (PDT) References: <4BACDDAB.9090506@gridmerge.com> <017c01cacd13$14aaa1c0$3dffe540$@sturek@att.net> Message-Id: From: Shidan Gouran To: "d.sturek@att.net" In-Reply-To: <017c01cacd13$14aaa1c0$3dffe540$@sturek@att.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 26 Mar 2010 14:49:16 -0400 Cc: "core@ietf.org" , "" Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:49:18 -0000 The cellular industry had the freedom to evolve with market demands, utilities don't have this freedom, we are stuck with whatever is defined today for atleast another decade after deployment. I think that's why it's more important to plan this out a bit further. Defining officially Interfaces to HTTP, SIP and XMPP won't hurt with this and probably help quite a bit in fact. I think, as currently defined, Coap might become the end to end standard for a significant number of deployments and it's not the optimal standard for this purpose. Sent from my phone On Mar 26, 2010, at 2:35 PM, "Don Sturek" wrote: > Actually, WAP taught us a few very important lessons (having worked in > cellular in the past): > 1) There is an actual market for web services on phones. While > obvious > today, it was not obvious at the time > 2) Chipset vendors and handset vendors can actually produce > platforms that > can support things like full HTML, HTTP, etc in a cost effective > manner that > meets the cost demands of the consumer space and contain features that > people will pay for. > > I don't think any of the above was obvious when WAP was born. I am > unclear > todays HTTP/HTML phones would have existed without the experience of > the > cellular industry with WAP. > > Don > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of > L.Wood@surrey.ac.uk > Sent: Friday, March 26, 2010 11:15 AM > To: distobj@acm.org; robert.cragie@gridmerge.com > Cc: core@ietf.org > Subject: Re: [core] HTTP over UDP > > http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html > > section 2.5 covers WSP - and BEEP has similar territory, these days. > > What lessons do you think WAP taught us? > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of Mark > Baker > Sent: 26 March 2010 18:10 > To: robert.cragie > Cc: core > Subject: Re: [core] HTTP over UDP > > Robert, > > On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie > wrote: >> It would seem reasonable to do this but HTTP is quite verbose so the >> aim is to compress the verbose text-based HTTP along with the >> content, >> which means that a request/response is more likely to fit into a UDP >> datagram, which is the aim for constrained environments. > > I understand. I just wanted to check that there wasn't any explicit > requirement being violated. > > FWIW, this group isn't the first to want to do HTTP-like things in a > constrained environment. The WAPforum developed a whole stack of > HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively > deprecate them in 2001, replacing them with the real deal. If > anybody's > interested, here's their HTTP-like protocol, WSP; > > http://www.openmobilealliance.net/technical/release_program/docs/Browser_Pro > tocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf > > The target environment for CoRE is obviously different from that of > WAP in > some ways, but I think the lesson is the same. > > Mark. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From mark@coactus.com Fri Mar 26 11:57:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168843A6B50 for ; Fri, 26 Mar 2010 11:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.197 X-Spam-Level: X-Spam-Status: No, score=-100.197 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsbRE6nRGgEc for ; Fri, 26 Mar 2010 11:57:36 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 0E5313A6B20 for ; Fri, 26 Mar 2010 11:57:34 -0700 (PDT) Received: by iwn29 with SMTP id 29so4834569iwn.17 for ; Fri, 26 Mar 2010 11:57:56 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.231.152.144 with HTTP; Fri, 26 Mar 2010 11:57:55 -0700 (PDT) In-Reply-To: References: <4BACDDAB.9090506@gridmerge.com> Date: Fri, 26 Mar 2010 14:57:55 -0400 X-Google-Sender-Auth: 0311bece2a869cd9 Received: by 10.231.159.207 with SMTP id k15mr591752ibx.75.1269629875771; Fri, 26 Mar 2010 11:57:55 -0700 (PDT) Message-ID: From: Mark Baker To: "L.Wood" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:57:37 -0000 On Fri, Mar 26, 2010 at 2:14 PM, wrote: > http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html > > section 2.5 covers WSP - and BEEP has similar territory, these days. > > What lessons do you think WAP taught us? Primarily, that deviating from existing, pervasively deployed standards, has very large costs. FWIW, the two biggest deviations which killed WAP - speaking as somebody who was actively involved in steering WAP towards the W3C/IETF stack - were WML, which HTML developers were not interested in learning, and the lack of an end-to-end security solution since WSP/WTLS traffic had to converted and re-encrypted to HTTP/TLS at a carrier gateway. Mark. From RNATALE@mitre.org Fri Mar 26 12:27:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA193A68C2 for ; Fri, 26 Mar 2010 12:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.869 X-Spam-Level: X-Spam-Status: No, score=-3.869 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT0dxidC425F for ; Fri, 26 Mar 2010 12:27:43 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 983563A6898 for ; Fri, 26 Mar 2010 12:27:43 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2QJS6wl001568 for ; Fri, 26 Mar 2010 15:28:07 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2QJS6i2001565; Fri, 26 Mar 2010 15:28:06 -0400 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 26 Mar 2010 15:28:06 -0400 From: "Natale, Bob" To: Shidan Gouran Date: Fri, 26 Mar 2010 15:28:05 -0400 Thread-Topic: [core] HTTP over UDP Thread-Index: AcrNFRnqUsSNvHcNQrmtEHvVJUGYDQABSNcA Message-ID: <17969D855F28964C88D177D45B6CDF11047D992362@IMCMBX2.MITRE.ORG> References: <4BACDDAB.9090506@gridmerge.com> <017c01cacd13$14aaa1c0$3dffe540$@sturek@att.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=MD5; boundary="----=_NextPart_000_0000_01CACCF8.EB5DCFF0" MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 19:27:45 -0000 ------=_NextPart_000_0000_01CACCF8.EB5DCFF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am sorry for not understanding, but what is the "it" that's "not the optimal standard for this purpose" in your last sentence below? Cheers, BobN -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Shidan Gouran Sent: Friday, March 26, 2010 2:49 PM To: d.sturek@att.net Cc: core@ietf.org; Subject: Re: [core] HTTP over UDP The cellular industry had the freedom to evolve with market demands, utilities don't have this freedom, we are stuck with whatever is defined today for atleast another decade after deployment. I think that's why it's more important to plan this out a bit further. Defining officially Interfaces to HTTP, SIP and XMPP won't hurt with this and probably help quite a bit in fact. I think, as currently defined, Coap might become the end to end standard for a significant number of deployments and it's not the optimal standard for this purpose. Sent from my phone On Mar 26, 2010, at 2:35 PM, "Don Sturek" wrote: > Actually, WAP taught us a few very important lessons (having worked in > cellular in the past): > 1) There is an actual market for web services on phones. While > obvious > today, it was not obvious at the time > 2) Chipset vendors and handset vendors can actually produce > platforms that > can support things like full HTML, HTTP, etc in a cost effective > manner that > meets the cost demands of the consumer space and contain features that > people will pay for. > > I don't think any of the above was obvious when WAP was born. I am > unclear > todays HTTP/HTML phones would have existed without the experience of > the > cellular industry with WAP. > > Don > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of > L.Wood@surrey.ac.uk > Sent: Friday, March 26, 2010 11:15 AM > To: distobj@acm.org; robert.cragie@gridmerge.com > Cc: core@ietf.org > Subject: Re: [core] HTTP over UDP > > http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html > > section 2.5 covers WSP - and BEEP has similar territory, these days. > > What lessons do you think WAP taught us? > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of Mark > Baker > Sent: 26 March 2010 18:10 > To: robert.cragie > Cc: core > Subject: Re: [core] HTTP over UDP > > Robert, > > On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie > wrote: >> It would seem reasonable to do this but HTTP is quite verbose so the >> aim is to compress the verbose text-based HTTP along with the >> content, >> which means that a request/response is more likely to fit into a UDP >> datagram, which is the aim for constrained environments. > > I understand. I just wanted to check that there wasn't any explicit > requirement being violated. > > FWIW, this group isn't the first to want to do HTTP-like things in a > constrained environment. The WAPforum developed a whole stack of > HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively > deprecate them in 2001, replacing them with the real deal. If > anybody's > interested, here's their HTTP-like protocol, WSP; > > http://www.openmobilealliance.net/technical/release_program/docs/Browser_Pro > tocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf > > The target environment for CoRE is obviously different from that of > WAP in > some ways, but I think the lesson is the same. > > Mark. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0000_01CACCF8.EB5DCFF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAQAAoIIKujCC A2QwggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYD VQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJv b3QgQ0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJl Lm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jw b3JhdGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiE Jv5vMtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNX nOLjXtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsA l5WnxwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUH RCtCblrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjW nwE8A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0O BBYEFMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwk fJXuXNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJd v51aHTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liB l8jxpN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsC AhGhdnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spU LZfBnQYdEpyz5tgh7Y2qMIIDZjCCAk6gAwIBAgICOLowDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UE ChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0xMDAyMDQyMDI3MTJaFw0xMTA3MjkyMDI3 MTJaMFkxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZImiZPyLGQB ARMHcm5hdGFsZTEZMBcGA1UEAxMQTmF0YWxlIFJvYmVydCBDLjCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAykCIY/i6G3fsihaJQ1GoIuqLTyccqLy56TJr4W/1THtY36hh8s1fq2lJS4n2MGY5 C/pKNvT+IlDUvyPJ+SvK2mDMBbbj8e46/2nx/vpojNRYH8YJP7UOwI00hH3sf+a36mgxL3PZEkZt RnE+UA6n+OdsH6uFjJsuA6KiJOhOfQUCAwEAAaOBtzCBtDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0O BBYEFPfmRD/TuNHnDvnutHS6ForR8Bv3MB8GA1UdIwQYMBaAFIe0D0iNYjNCwS1RGkgewp67CrGt MEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly93d3cubWl0cmUub3JnL3RlY2gvbWlpL3BraS9jYTFf bWl0cmVfb3JnLmNybDAcBgNVHREEFTATgRFybmF0YWxlQG1pdHJlLm9yZzANBgkqhkiG9w0BAQUF AAOCAQEAwqRTwtWmv2Ux/+QE5ppU2yWwvchihOTxWAalzXaoXqmr7Ia2X7NgWts/gpB/2L9EtiIs 7BfvEOET+klgb0n/I8klMW2ylQXq0P0kHSpQnYXeqmAOjL7Bv4E3c4vZWDJHQZvMS3bxrtqIi1ZS BOx3EVfM23vD3upnPJL9MsnCQa9RG8j8bfkNxzM79qBKqImdqpsM+HjQYeVHo6dOoX7ssk8mjJlz 4kJUT6N8aWNMm/TcngyogZVqh/zqjHihkJ+Bf9N6iPXlFO2INAD0me+i5ADEQlqFIZ/hCFhZrjx9 RTiKCSZZewI9zFgD8xqzb2zVIR2FXc4JsNzaTfn0xOjplDCCA+QwggLMoAMCAQICAQUwDQYJKoZI hvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRo b3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTAeFw0wNjA2MDMxNzEz MjJaFw0xMjA2MDMxNzEzMjJaMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlm aWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI8HtWXRCCqBC3S7xDZ25Gzt5lQ+eGV+Uo 8U8xcYb6KoakiZizqd9sU+yfSrwWqSUWyb9QRXYklDdztKvB+up70KsJtUWHvrU7Fkjt+dRaJRqw 0/Yg0bX1oB+tDwigmwAS0bMd4hpxL4zkI3gLTJ9QLoKkFlNz1mV2MtRq28mvjTsrWL7taetGwxUq EgJ+CaI79eJVH1h5fLN5GoWsvLpi0kIm4l3RBF/Aq0pGl6TmhTrsjOvsKUcO08mztQ5OMxgFLZ9P PO0L7DA5Onr4DdlsTKa5BwBlHCYaSNUF7ZHwyJfbpHTYiKDP73TdkAv/pum/HQOeSuVHZQWvUoEZ 8GqZAgMBAAGjgbEwga4wEgYDVR0TAQH/BAgwBgEB/wIBAjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0O BBYEFIe0D0iNYjNCwS1RGkgewp67CrGtMB8GA1UdIwQYMBaAFMdwUQDYTf7kAdRolsU9n5qX/nQv MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly93d3cubWl0cmUub3JnL3RlY2gvbWlpL3BraS9yb290 Y2ExX21pdHJlX29yZy5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE1ubuuuKezdIgI9u15f2pI3X5Ek KWqLH+nDcgB7u7rQsrRX2NVn0TZr5zQxmJKiN1zBTmtfEjY4jbDAh/rBUGjvqMg5z4iJBGUL5Xxh q0aaiJuo//xYM/OW539ZADOSOtTae6Hwp3Ikb6fWQf/rvvYtutrYIiTya7wXKl5oHk/a4gnN0T48 ajzZmLJTrzS6SIn3IXpSYRe5yIHvu0ZAFHEyXp4/MisCtCd/jxKYGEUPldgutq546IbsT4DMP32K DUzpYdzFZe2ncMitWoT8NmvXjo0loJaqD02gTXhyakSWWelYu0ueflQFgn5AKjOZt7VIlc47KdnR XEycZ2Hs2qAxggK0MIICsAIBATBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENB LTECAji6MAwGCCqGSIb3DQIFBQCgggGkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMyNjE5MjgwMFowHwYJKoZIhvcNAQkEMRIEENZT9cozZXcpZlJSZ3SVDKEw XwYJKoZIhvcNAQkPMVIwUDAOBggqhkiG9w0DAgICAIAwCwYJYIZIAWUCAQEEMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMHIGCSsGAQQBgjcQBDFlMGMw XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICOLowdAYLKoZIhvcNAQkQAgsx ZaBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAji6MA0GCSqGSIb3DQEB AQUABIGAXINSIPfncvblsijZE/O8KA2ZvOvh8v6eMTg0PJBv/MneHdT/6VNWPN3/czpF2iDxcGiT M60DW6ydnn82ahQ9pEyW6K8QHNCMZrdSnYnLkQM2dJlpD/zOY6VI99JIgWX3mWXPU5bYJjgAeM3C cv5l5UsDcGYJNx1tBF0oiAeoskcAAAAAAAA= ------=_NextPart_000_0000_01CACCF8.EB5DCFF0-- From shidan@gmail.com Fri Mar 26 14:31:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347EE3A6B8C for ; Fri, 26 Mar 2010 14:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2MDs1hCIZ4m for ; Fri, 26 Mar 2010 14:31:23 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id DA0B83A67D3 for ; Fri, 26 Mar 2010 14:31:22 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so1882290qwi.31 for ; Fri, 26 Mar 2010 14:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=G0M2tzzyi+bxk8rKKRpms3zUGmRs/hQ+qOxslfk55K4=; b=Ok2lDrvDwCZTWARI0+oA6wA17RX2TlfGN/Un600B+/EMRUHDehK+ttrhhUWBLCfNMM nw/QhYXpXj46St4HmpPXoCK+HO0LA/qZpkznv17yXhOetqMGxh1YBG7AC5AnjDT7A07G l2bg4+tRj4aeeEezIP8UvikIRniQxdJqSeM1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=X+09gVAzZHFCHAqCgIUXvQUIcbi0c4qivCndtdSPWCZj9dz+tkBsx3BJGumr8cZbNc bqWPF14O2rOv9gCanLh3UVtreHYRdpUw6hKF0fbs7rplYkTVJcVPkV2gUg42g/gyCPHY 2iA1Vdv5r30nkB8zvzEocahp1/cwwuBPUUgqg= Received: by 10.224.106.229 with SMTP id y37mr522448qao.176.1269639099173; Fri, 26 Mar 2010 14:31:39 -0700 (PDT) Received: from [10.140.213.16] ([24.114.232.27]) by mx.google.com with ESMTPS id 26sm3356293qwa.33.2010.03.26.14.31.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Mar 2010 14:31:37 -0700 (PDT) References: <4BACDDAB.9090506@gridmerge.com> <017c01cacd13$14aaa1c0$3dffe540$@sturek@att.net> <17969D855F28964C88D177D45B6CDF11047D992362@IMCMBX2.MITRE.ORG> Message-Id: From: Shidan Gouran To: "Natale, Bob" In-Reply-To: <17969D855F28964C88D177D45B6CDF11047D992362@IMCMBX2.MITRE.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 26 Mar 2010 17:31:18 -0400 Cc: "core@ietf.org" Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 21:31:25 -0000 CoRe as an end to end protocol on the AMI network. Sent from my phone On Mar 26, 2010, at 3:28 PM, "Natale, Bob" wrote: > I am sorry for not understanding, but what is the "it" that's "not the > optimal standard for this purpose" in your last sentence below? > > Cheers, > BobN > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of > Shidan Gouran > Sent: Friday, March 26, 2010 2:49 PM > To: d.sturek@att.net > Cc: core@ietf.org; > Subject: Re: [core] HTTP over UDP > > The cellular industry had the freedom to evolve with market demands, > utilities don't have this freedom, we are stuck with whatever is > defined today for atleast another decade after deployment. I think > that's why it's more important to plan this out a bit further. > Defining officially Interfaces to HTTP, SIP and XMPP won't hurt with > this and probably help quite a bit in fact. > > I think, as currently defined, Coap might become the end to end > standard for a significant number of deployments and it's not the > optimal standard for this purpose. > > Sent from my phone > > On Mar 26, 2010, at 2:35 PM, "Don Sturek" wrote: > >> Actually, WAP taught us a few very important lessons (having worked >> in >> cellular in the past): >> 1) There is an actual market for web services on phones. While >> obvious >> today, it was not obvious at the time >> 2) Chipset vendors and handset vendors can actually produce >> platforms that >> can support things like full HTML, HTTP, etc in a cost effective >> manner that >> meets the cost demands of the consumer space and contain features >> that >> people will pay for. >> >> I don't think any of the above was obvious when WAP was born. I am >> unclear >> todays HTTP/HTML phones would have existed without the experience of >> the >> cellular industry with WAP. >> >> Don >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf >> Of >> L.Wood@surrey.ac.uk >> Sent: Friday, March 26, 2010 11:15 AM >> To: distobj@acm.org; robert.cragie@gridmerge.com >> Cc: core@ietf.org >> Subject: Re: [core] HTTP over UDP >> >> http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html >> >> section 2.5 covers WSP - and BEEP has similar territory, these days. >> >> What lessons do you think WAP taught us? >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf >> Of Mark >> Baker >> Sent: 26 March 2010 18:10 >> To: robert.cragie >> Cc: core >> Subject: Re: [core] HTTP over UDP >> >> Robert, >> >> On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie >> wrote: >>> It would seem reasonable to do this but HTTP is quite verbose so the >>> aim is to compress the verbose text-based HTTP along with the >>> content, >>> which means that a request/response is more likely to fit into a UDP >>> datagram, which is the aim for constrained environments. >> >> I understand. I just wanted to check that there wasn't any explicit >> requirement being violated. >> >> FWIW, this group isn't the first to want to do HTTP-like things in a >> constrained environment. The WAPforum developed a whole stack of >> HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively >> deprecate them in 2001, replacing them with the real deal. If >> anybody's >> interested, here's their HTTP-like protocol, WSP; >> >> > http://www.openmobilealliance.net/technical/release_program/docs/Browser_Pro >> tocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf >> >> The target environment for CoRE is obviously different from that of >> WAP in >> some ways, but I think the lesson is the same. >> >> Mark. >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From d.sturek@att.net Fri Mar 26 14:38:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F153A6A34 for ; Fri, 26 Mar 2010 14:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.334 X-Spam-Level: ** X-Spam-Status: No, score=2.334 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SUYjjQzwqug for ; Fri, 26 Mar 2010 14:38:43 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 9D1943A6A92 for ; Fri, 26 Mar 2010 14:38:40 -0700 (PDT) Received: (qmail 28679 invoked from network); 26 Mar 2010 21:39:02 -0000 Received: from Studio (d.sturek@69.225.120.125 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 26 Mar 2010 14:39:01 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: uLQItzkVM1mbt9mxf0MXd4GwzWt_pZjLFGycNgjX.JnBMZZ1pkgUqrrphaEtiUDhZcHgnTxs5YcB.VSQEfLmDk0kxwaC_Umn.DC6xYXUZcCd83JdcEZI7P8Z3FlWcDp50J.8am9CQSMz68_HD7S15RgzmWO6DOEFMywuS7Nm82jedx2oU7eo0RgGj4miNO82mJe52qR.caMC0ZvVr2vQpuSRPM8X1gfFFLMoaugVceScnuHmqFGt.4p5D3Ser8ZBOyAt3XpH.MSgMO53_OEDpUqd X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Stuber, Michael'" , "'Mark Baker'" , "'robert.cragie'" References: <4BACDDAB.9090506@gridmerge.com> <05C6A38D732F1144A8C4016BA4416BFE02A97E7F@SPO-EXVS-02.itron.com> In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE02A97E7F@SPO-EXVS-02.itron.com> Date: Fri, 26 Mar 2010 14:38:58 -0700 Message-ID: <002d01cacd2c$bedbc750$3c9355f0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrND4+BkBTb106tTUWnQoez523JTAAAYkFgAAbG2dA= Content-Language: en-us Cc: 'core' Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 21:38:44 -0000 Hi Michael, A couple of points on your note: 1) While smart meters are being deployed now, HAN devices to communicate to them are not quite yet. It won't be only meters that will communicate with these HAN devices. I could see deployment of full HTTP/TCP in HAN devices that use access points that are not the meter supporting full web services 2) Not all smart meters being deployed now are constrained and can also support full HTTP/TCP. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Stuber, Michael Sent: Friday, March 26, 2010 11:30 AM To: Mark Baker; robert.cragie Cc: core Subject: Re: [core] HTTP over UDP It's a good point, but the mobile guys have had the advantage of continuingly increasing capabilities at the handset and the network, and a fast refresh cycle. Right now there are around 35 million meters under contract which will have 802.15.4 radios, and are expected to have a minimum service life of 15 years -- 20 in most cases. Deployment is moving forward apace, and the majority of these will be in place by 2012. I full recognize that we may move to the "real deal" on a future generation, but we need CoAP to service what is being installed today. Besides, about the time that today's "internet of things" has taken the leap into bigger CPUs, faster networks, and generally less constrained devices, somebody will decide that want to do IPv6 to cardboard boxes or shoes, or something else where costs will dictate the use of tiny constrained parts -- ones that will presumably be an order of magnitude cheaper at that point. I think they'll be uses for CoAP for a very long time. As long as we continue to push technology into smaller, cheaper, and more ubiquitous locations, it can add value. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Mark Baker Sent: Friday, March 26, 2010 11:10 AM To: robert.cragie Cc: core Subject: Re: [core] HTTP over UDP Robert, On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie wrote: > It would seem reasonable to do this but HTTP is quite verbose so the > aim is to compress the verbose text-based HTTP along with the content, > which means that a request/response is more likely to fit into a UDP > datagram, which is the aim for constrained environments. I understand. I just wanted to check that there wasn't any explicit requirement being violated. FWIW, this group isn't the first to want to do HTTP-like things in a constrained environment. The WAPforum developed a whole stack of HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively deprecate them in 2001, replacing them with the real deal. If anybody's interested, here's their HTTP-like protocol, WSP; http://www.openmobilealliance.net/technical/release_program/docs/Browser _Protocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf The target environment for CoRE is obviously different from that of WAP in some ways, but I think the lesson is the same. Mark. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Michael.Stuber@itron.com Fri Mar 26 14:55:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E693A6A0C for ; Fri, 26 Mar 2010 14:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtiEOABLdqOi for ; Fri, 26 Mar 2010 14:55:57 -0700 (PDT) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 75ADE3A69AA for ; Fri, 26 Mar 2010 14:55:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Mar 2010 14:56:19 -0700 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02A97F93@SPO-EXVS-02.itron.com> In-Reply-To: <002d01cacd2c$bedbc750$3c9355f0$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] HTTP over UDP Thread-Index: AcrND4+BkBTb106tTUWnQoez523JTAAAYkFgAAbG2dAAAJ7OcA== References: <4BACDDAB.9090506@gridmerge.com> <05C6A38D732F1144A8C4016BA4416BFE02A97E7F@SPO-EXVS-02.itron.com> <002d01cacd2c$bedbc750$3c9355f0$@sturek@att.net> From: "Stuber, Michael" To: , "Mark Baker" , "robert.cragie" Cc: core Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 21:55:58 -0000 Don, I realize that you and I disagree on this, but my point about 35 million units with 802.15.4 was specifically about 802.15.4. I feel that HTTP/TCP is an inappropriate technology on 802.15.4 HAN devices, regardless of the resources backing it. I believe that large multi-packet transactions that will be required when running HTTP/TCP over 802.15.4 will not scale well, hence my strong interest in CoAP. You raise a very good point though, the 35 million devices I reference is just the tip of the iceberg. These smart meters will be the first wave, with many, many additional devices connecting to them. -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Friday, March 26, 2010 2:39 PM To: Stuber, Michael; 'Mark Baker'; 'robert.cragie' Cc: 'core' Subject: RE: [core] HTTP over UDP Hi Michael, A couple of points on your note: 1) While smart meters are being deployed now, HAN devices to communicate to them are not quite yet. It won't be only meters that will communicate with these HAN devices. I could see deployment of full HTTP/TCP in HAN devices that use access points that are not the meter supporting full web services 2) Not all smart meters being deployed now are constrained and can also support full HTTP/TCP. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Stuber, Michael Sent: Friday, March 26, 2010 11:30 AM To: Mark Baker; robert.cragie Cc: core Subject: Re: [core] HTTP over UDP It's a good point, but the mobile guys have had the advantage of continuingly increasing capabilities at the handset and the network, and a fast refresh cycle. Right now there are around 35 million meters under contract which will have 802.15.4 radios, and are expected to have a minimum service life of 15 years -- 20 in most cases. Deployment is moving forward apace, and the majority of these will be in place by 2012. I full recognize that we may move to the "real deal" on a future generation, but we need CoAP to service what is being installed today. Besides, about the time that today's "internet of things" has taken the leap into bigger CPUs, faster networks, and generally less constrained devices, somebody will decide that want to do IPv6 to cardboard boxes or shoes, or something else where costs will dictate the use of tiny constrained parts -- ones that will presumably be an order of magnitude cheaper at that point. I think they'll be uses for CoAP for a very long time. As long as we continue to push technology into smaller, cheaper, and more ubiquitous locations, it can add value. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Mark Baker Sent: Friday, March 26, 2010 11:10 AM To: robert.cragie Cc: core Subject: Re: [core] HTTP over UDP Robert, On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie wrote: > It would seem reasonable to do this but HTTP is quite verbose so the=20 > aim is to compress the verbose text-based HTTP along with the content, > which means that a request/response is more likely to fit into a UDP=20 > datagram, which is the aim for constrained environments. I understand. I just wanted to check that there wasn't any explicit requirement being violated. FWIW, this group isn't the first to want to do HTTP-like things in a constrained environment. The WAPforum developed a whole stack of HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively deprecate them in 2001, replacing them with the real deal. If anybody's interested, here's their HTTP-like protocol, WSP; http://www.openmobilealliance.net/technical/release_program/docs/Browser _Protocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf The target environment for CoRE is obviously different from that of WAP in some ways, but I think the lesson is the same. Mark. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From erik.guttman@gmail.com Mon Mar 29 04:48:41 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12023A6923 for ; Mon, 29 Mar 2010 04:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDgnKeQiNnfG for ; Mon, 29 Mar 2010 04:48:40 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 8E04A3A68BE for ; Mon, 29 Mar 2010 04:48:39 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so788567fgb.13 for ; Mon, 29 Mar 2010 04:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=WP/8+oHqtZhm0j2Ywg1slDBfAxsJJHyHruX1WrKwu1s=; b=I7pPETCxcBdcKULY/ReBUoG99Ya/lCgccFuc3XDKYdIGYQl2msUkVpFqt8ANyjD9lz wA9sDKlJgrDK0i9Q6ZWPcoEjzLXw0tL+CFUUxMk9BI0Q+FHfB5qTN43L4A1L9f/rXgTe QJcy4iySYsOcpQMfDret/WB+ogw4t2IUQ07fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=TS/H0qzVoCGDcfKBvUzai9H/t7ugNThGGdGR2YMp0xf2zcw+fwZtsrDC32Ygx0F0LA 55NYt2JUZvTYrLqRK36GtfAa/aOOpGEgdupHxAaY96iiSeM0Shjmtwtex7ywKnqJq3Q6 9QtHG0PSGA6RngjOWJj3CViTHdJXvASPIDyh4= Received: by 10.87.65.9 with SMTP id s9mr3453585fgk.0.1269863343271; Mon, 29 Mar 2010 04:49:03 -0700 (PDT) Received: from [192.168.1.106] (pD954BE7D.dip.t-dialin.net [217.84.190.125]) by mx.google.com with ESMTPS id l19sm4301967fgb.21.2010.03.29.04.49.00 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 04:49:01 -0700 (PDT) Message-ID: <4BB093AB.3010100@gmail.com> Date: Mon, 29 Mar 2010 13:48:59 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: core@ietf.org Content-Type: multipart/alternative; boundary="------------090002020803010807010300" Subject: [core] UDP 'overflow' X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 11:48:41 -0000 This is a multi-part message in MIME format. --------------090002020803010807010300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I wanted to share some thoughts on UDP requests that may result in responses that cannot fit in an UDP response. In DNS, the response is truncated. A 'TC' flag indicates this trucation to the client. The client may resend the request using TCP. In SLPv2 [rfc2608], the response is truncated also, and an 'O' indicates overflow to the 'user agent.' The UA may resend the request using TCP. One advantage of this approach is that a query may be sent using multicast and several responses may be returned. Where overflow occurs, the client may obtain the overflowed information using unicast from specific responders. Henning observed during the WG session the /stateful/ nature of this overflow-caused retransmitted request. The responder must either (a) return something potentially completely different upon the subsequent request or (b) /cache /the response from the first request as the state of the responder may change between the initial and subsequent request from the client. Perhaps the semantics of (a) suffice? For DNS this is fine. In SLPv2, the UA may issue a request subsequently to an overflow with /the same XID/. There is no explicit requirement that the response to the retransmitted query is identical to the first response. The XID is included so as to allow the responder (service agent or directory agent) to cache the reply and thereby optimize processing time. So arguably, SLPv2 tolerates semantics (a) also. One consideration I had regarding UDP transport for CoAP for payloads exceeding a single datagram: a lockstep approach was mentioned. I wonder if for such transfers one could simply use TFTP (RFC 1350) which is well worked out and has minimal implementation requirements. For example, CoAP could provide a URL to a TFTP accessible resource exceeding the datagram MTU. Of course TFTP assumes a 512 byte block size - this would have to be adjusted for constrained links. If CoAP relies upon transport security, this could also secure TFTP. Best regards, Erik --------------090002020803010807010300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I wanted to share some thoughts on UDP requests that may result in responses that cannot fit in an UDP response.

In DNS, the response is truncated. A 'TC' flag indicates this trucation to the client. The client may resend the request using TCP.

In SLPv2 [rfc2608], the response is truncated also, and an 'O' indicates overflow to the 'user agent.' The UA may resend the request using TCP.

One advantage of this approach is that a query may be sent using multicast and several responses may be returned. Where overflow occurs, the client may obtain the overflowed information using unicast from specific responders.

Henning observed during the WG session the stateful nature of this overflow-caused retransmitted request. The responder must either (a) return something potentially completely different upon the subsequent request or (b) cache the response from the first request as the state of the responder may change between the initial and subsequent request from the client.

Perhaps the semantics of (a) suffice? For DNS this is fine. In SLPv2, the UA may issue a request subsequently to an overflow with the same XID. There is no explicit requirement that the response to the retransmitted query is identical to the first response. The XID is included so as to allow the responder (service agent or directory agent) to cache the reply and thereby optimize processing time. So arguably, SLPv2 tolerates semantics (a) also.

One consideration I had regarding UDP transport for CoAP for payloads exceeding a single datagram: a lockstep approach was mentioned. I wonder if for such transfers one could simply use TFTP (RFC 1350) which is well worked out and has minimal implementation requirements. For example, CoAP could provide a URL to a TFTP accessible resource exceeding the datagram MTU. Of course TFTP assumes a 512 byte block size - this would have to be adjusted for constrained links. If CoAP relies upon transport security, this could also secure TFTP.

Best regards,

Erik  --------------090002020803010807010300-- From cabo@tzi.org Mon Mar 29 05:05:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2D73A6863 for ; Mon, 29 Mar 2010 05:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCL3MObgbh4I for ; Mon, 29 Mar 2010 05:05:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E50A63A688A for ; Mon, 29 Mar 2010 05:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o2TC5aw6003821; Mon, 29 Mar 2010 14:05:36 +0200 (CEST) Received: from [192.168.217.101] (p5489BE6C.dip.t-dialin.net [84.137.190.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C50BFEFF2; Mon, 29 Mar 2010 14:05:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4BB093AB.3010100@gmail.com> Date: Mon, 29 Mar 2010 14:05:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6617E33E-DBDD-4B4E-91CD-19621921A167@tzi.org> References: <4BB093AB.3010100@gmail.com> To: Erik Guttman X-Mailer: Apple Mail (2.1077) Cc: core@ietf.org Subject: Re: [core] UDP 'overflow' X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:05:21 -0000 Hi Erik, > Henning observed during the WG session the stateful nature of this = overflow-caused retransmitted request. The responder must either (a) = return something potentially completely different upon the subsequent = request or (b) cache the response from the first request as the state of = the responder may change between the initial and subsequent request from = the client. >=20 > Perhaps the semantics of (a) suffice? For DNS this is fine. In SLPv2, = the UA may issue a request subsequently to an overflow with the same = XID. There is no explicit requirement that the response to the = retransmitted query is identical to the first response. The XID is = included so as to allow the responder (service agent or directory agent) = to cache the reply and thereby optimize processing time. So arguably, = SLPv2 tolerates semantics (a) also. Indeed, (a) is what I had in mind when suggesting this at the = microphone. When do long (> reasonable MSS) resource representations potentially = occur in CoRE? 1) for discovery and resource description documents. These change = rarely enough that (a) is not a problem. 2) for long frequently changing representations. E.g., a JPEG image = from a Webcam. This would be a candidate for TCP, IMO, if not HTTP = outright (webcams are generally available with HTTP access, today). CoAP might have something like (but not necessarily equal to) strong = ETags in order to reliably find out when/prevent that subsequent range = requests return parts of a different representation. A truncated = representation might also include a URI to a frozen resource (~ = Location:) or be an outright redirect, facilitating (b).=20 > One consideration I had regarding UDP transport for CoAP for payloads = exceeding a single datagram: a lockstep approach was mentioned. I wonder = if for such transfers one could simply use TFTP (RFC 1350) which is well = worked out and has minimal implementation requirements. Actually, range requests are close enough in protocol workings to TFTP = (actually, simpler) that I don't think it is necessary to introduce = another protocol here. > For example, CoAP could provide a URL to a TFTP accessible resource = exceeding the datagram MTU. Of course TFTP assumes a 512 byte block size = - this would have to be adjusted for constrained links. If CoAP relies = upon transport security, this could also secure TFTP.=20 Two reasons to do this in CoAP itself. Gruesse, Carsten From hgs@cs.columbia.edu Mon Mar 29 05:47:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226023A6A5B for ; Mon, 29 Mar 2010 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCXvTGLSmrpo for ; Mon, 29 Mar 2010 05:47:36 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 4675A3A6898 for ; Mon, 29 Mar 2010 05:47:36 -0700 (PDT) Received: from new-host-3.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2TCm2CK004667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 08:48:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <6617E33E-DBDD-4B4E-91CD-19621921A167@tzi.org> Date: Mon, 29 Mar 2010 08:48:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB093AB.3010100@gmail.com> <6617E33E-DBDD-4B4E-91CD-19621921A167@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: Erik Guttman , core@ietf.org Subject: Re: [core] UDP 'overflow' X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:47:39 -0000 What's the MSS assumption for CoRE? If we have object signing (about the only way to get e2e security if you = have a protocol translator), even the smallest object quickly exceeds = 200 bytes. I think there are other cases where you are likely to get larger = objects: - sensors that capture measurement traces and get polled periodically = (more efficient than polling for every single measurement) - non-trivial devices that have more extensive state (e.g., more complex = machinery) The problem with the etag mechanism is that it simply tells you that you = failed - but there may be no way to succeed if the cache duration = happens to be smaller than the delay from first to last request. This = seems like a recipe for rather unpleasant failures. Since we assume = small memory devices (otherwise, we wouldn't be having this whole = discussion...), caching objects for larger intervals seems like a rather = dubious assumption. After all, if you buffer 500 bytes, you can = implement a complete TCP/IP stack instead - twice (see = http://www.ietf.org/mail-archive/web/ietf/current/msg10705.html after = random googling: "TCP/IP code itself fits in about 256 bytes").=20 Henning On Mar 29, 2010, at 8:05 AM, Carsten Bormann wrote: > Hi Erik, >=20 >> Henning observed during the WG session the stateful nature of this = overflow-caused retransmitted request. The responder must either (a) = return something potentially completely different upon the subsequent = request or (b) cache the response from the first request as the state of = the responder may change between the initial and subsequent request from = the client. >>=20 >> Perhaps the semantics of (a) suffice? For DNS this is fine. In SLPv2, = the UA may issue a request subsequently to an overflow with the same = XID. There is no explicit requirement that the response to the = retransmitted query is identical to the first response. The XID is = included so as to allow the responder (service agent or directory agent) = to cache the reply and thereby optimize processing time. So arguably, = SLPv2 tolerates semantics (a) also. >=20 > Indeed, (a) is what I had in mind when suggesting this at the = microphone. >=20 > When do long (> reasonable MSS) resource representations potentially = occur in CoRE? >=20 > 1) for discovery and resource description documents. These change = rarely enough that (a) is not a problem. > 2) for long frequently changing representations. E.g., a JPEG image = from a Webcam. This would be a candidate for TCP, IMO, if not HTTP = outright (webcams are generally available with HTTP access, today). >=20 > CoAP might have something like (but not necessarily equal to) strong = ETags in order to reliably find out when/prevent that subsequent range = requests return parts of a different representation. A truncated = representation might also include a URI to a frozen resource (~ = Location:) or be an outright redirect, facilitating (b).=20 >=20 >> One consideration I had regarding UDP transport for CoAP for payloads = exceeding a single datagram: a lockstep approach was mentioned. I wonder = if for such transfers one could simply use TFTP (RFC 1350) which is well = worked out and has minimal implementation requirements. >=20 > Actually, range requests are close enough in protocol workings to TFTP = (actually, simpler) that I don't think it is necessary to introduce = another protocol here. >=20 >> For example, CoAP could provide a URL to a TFTP accessible resource = exceeding the datagram MTU. Of course TFTP assumes a 512 byte block size = - this would have to be adjusted for constrained links. If CoAP relies = upon transport security, this could also secure TFTP.=20 >=20 > Two reasons to do this in CoAP itself. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From spencer@wonderhamster.org Tue Mar 30 14:20:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC783A6A21 for ; Tue, 30 Mar 2010 14:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjVsVPew9ZMW for ; Tue, 30 Mar 2010 14:20:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 4A7283A6A4D for ; Tue, 30 Mar 2010 14:20:19 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LuOhb-1NXBYV1CiN-011jYW; Tue, 30 Mar 2010 17:20:44 -0400 Message-ID: <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> From: "Spencer Dawkins" To: "Mark Baker" , "L.Wood" References: <4BACDDAB.9090506@gridmerge.com> Date: Tue, 30 Mar 2010 16:20:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+ThxWLEUqjRY4rOlD4QXT9joMWFhnnkjwggrO aM/Ek9FUks0F5iB4KBW+I94puqLyc2zkjcXByAGrH6V1ZFLgee wLYal2TQtkMiCc3ThEchVnHamnQMDn7okptVa6pkDg= Cc: core Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 21:20:21 -0000 Speaking as co-chair of PILC, which considered the WAP transport protocols and decided to focus on TCP instead ... >> What lessons do you think WAP taught us? > > Primarily, that deviating from existing, pervasively deployed > standards, has very large costs. > > FWIW, the two biggest deviations which killed WAP - speaking as > somebody who was actively involved in steering WAP towards the > W3C/IETF stack - were WML, which HTML developers were not interested > in learning, and the lack of an end-to-end security solution since > WSP/WTLS traffic had to converted and re-encrypted to HTTP/TLS at a > carrier gateway. I would agree that these were significant problems, and maybe even the top two. I would add a third - "wishing that everything would fit in a datagram, even when we see problems with that on the horizon". And I'm spending a decent amount of time as co-chair of MARTINI trying to unravel what we do when request (and, more seriously, response) sizes exceed what we can do in UDP, because a lot of SIP deployments don't handle the switch to TCP gracefully... All I'm suggesting is that you guys make decisions about transport carefully. Thanks, Spencer From dhorwitz@echelon.com Tue Mar 30 17:03:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70B93A6C33 for ; Tue, 30 Mar 2010 17:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJknlBhlRsCB for ; Tue, 30 Mar 2010 17:03:01 -0700 (PDT) Received: from monk.echelon.com (monk.echelon.com [12.191.56.29]) by core3.amsl.com (Postfix) with ESMTP id 2B0523A6C2C for ; Tue, 30 Mar 2010 17:03:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 17:03:29 -0700 Message-ID: In-Reply-To: <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] HTTP over UDP Thread-Index: AcrQTuHmnt45aAisT9mUA3c1wZpeCQAFZfoQ References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> From: "Dave Horwitz" To: "core" Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 00:03:01 -0000 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Spencer Dawkins > Sent: Tuesday, March 30, 2010 2:20 PM > To: Mark Baker; L.Wood > Cc: core > Subject: Re: [core] HTTP over UDP >=20 > Speaking as co-chair of PILC, which considered the WAP transport > protocols > and decided to focus on TCP instead ... >=20 > >> What lessons do you think WAP taught us? > > > > Primarily, that deviating from existing, pervasively deployed > > standards, has very large costs. > > > > FWIW, the two biggest deviations which killed WAP - speaking as > > somebody who was actively involved in steering WAP towards the > > W3C/IETF stack - were WML, which HTML developers were not interested > > in learning, and the lack of an end-to-end security solution since > > WSP/WTLS traffic had to converted and re-encrypted to HTTP/TLS at a > > carrier gateway. >=20 > I would agree that these were significant problems, and maybe even the > top > two. >=20 > I would add a third - "wishing that everything would fit in a datagram, > even > when we see problems with that on the horizon". >=20 > And I'm spending a decent amount of time as co-chair of MARTINI trying > to > unravel what we do when request (and, more seriously, response) sizes > exceed > what we can do in UDP, because a lot of SIP deployments don't handle > the > switch to TCP gracefully... >=20 > All I'm suggesting is that you guys make decisions about transport > carefully. I've been confused about the "TCP optional" part since the meeting. It was implied that if you wanted to do "some things" you might have to do them using TCP. It was also said that TCP cannot (or will not) be implemented on some constrained devices. How is this reconciled? And can we define what "those things" are that can't/won't be done on the constrained devices? -Dave From dotis@mail-abuse.org Tue Mar 30 17:16:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E483A6BDA for ; Tue, 30 Mar 2010 17:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeKMsVFyy9NR for ; Tue, 30 Mar 2010 17:16:44 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 71F853A69BB for ; Tue, 30 Mar 2010 17:16:34 -0700 (PDT) Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 52605A9443B for ; Wed, 31 Mar 2010 00:17:00 +0000 (UTC) Message-ID: <4BB2947B.4060709@mail-abuse.org> Date: Tue, 30 Mar 2010 17:16:59 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Desired Transport properties X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 00:16:47 -0000 The suggestion made at the WG meeting in Anaheim was to use a UDP overlay having SCTP constructs. This approach would allow efficient transfers of various types, where not all features of SCTP would need to be supported. Such an SCTP-lite over UDP might omit implicit associations and multi-homing and still offer many important advantages: 1) Good error detection with the CRC32c algorithm supported by 1 and 10Gb/sec NICs, and modern math coprocessors. This algorithm is suitable for use with jumbo frames and supports extremely high volume centralized services. When supplementary error detection is appended to objects contained within poorly checked transports, partial object reception prior to the checking of enclosed objects imposes complex and expensive recovery processes, where entire objects will then likely need to be retransmitted by the application. In the past, some providers ignored possible errors just to avoid complex recoveries. Determining the rarity of these cases proved difficult, when reporting and logging were also squelched to avoid equally vexing support issues. For a transport designed to control power sub-systems, error detection and recovery is extremely important. Only when good error detection is directly supported by the transport, will data integrity and protocol simplicity be assured. Error detection schemes used by either UDP or TCP fail in as much as 2% of bus specific bit errors that might be caused by weak drivers or bus timing skew. With many systems dropping bus parity to reduce cost, bus specific bit errors remain common, and are likely to have a similar modulo to that of UDP and TCP checksums. 2) Data Framing (headers included with every packet) greatly assists data handling. Reassembly and placement is facilitated by having headers within the packet that identify the data elements. Offsets can be included to facilitate direct placement, even when packets are received out-of-order. Low bandwidth mesh network configurations should not be expected to retain packet ordering. Past efforts aimed at efficiently implementing RDMA over TCP failed largely due to the complexities imposed by a lack of data framing, good error detection, with the subsequent buffering and complex handling this imposed. Although direct placement is normally used in many low level devices, byte stream transports add significant complexities that prohibit economical use of this resource friendly mode of operation. 3) Minimized retry is achieved by providing explicit acknowledgment of data objects, in conjunction with selective reliability modes. For example, when data is multi-cast in an unreliable fashion, specific data-element identifiers then permit data recovery over a different path when desired. 4) Short messages can be bundled to improve throughput and to reduce packet rates. 5) APIs have been developed which can be adopted to an SCTP-lite transport. This API offers a means to map existing TCP or UDP sockets APIs while also supporting access to new features. Existing TCP applications can migrate to this API while having few (if any) changes. This would ensure that having only UDP support will not impact use of higher level protocols, such as HTTP. See http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-22 6) Improved data throughput. The congestion algorithm used by SCTP, in conjunction with its explicit acknowledgment, offers a more efficient use of both low and high bandwidth networks. 7) Anti-spoofing, and DoS resistance has been achieved by the initial exchange of "cookie" tokens. These tokens offer spoofing resistance, and safely establish connections (associations) in fewer exchanges than what is typically otherwise achieved. 8) Existing procedures and structures to establish secure associations. Evolution of extensions might include: 9) Implicit Associations and non-blocking socket operations. These modes of operation allow servers greater scalability by avoiding overhead related to establishing a connection. 10) Multi-homing by the transport takes reliability to the next level by offering rapid fail-over that is router independent. -Doug From stpeter@stpeter.im Tue Mar 30 20:11:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7C83A682F for ; Tue, 30 Mar 2010 20:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y1n0VLOUrlu for ; Tue, 30 Mar 2010 20:11:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6ACB83A67F8 for ; Tue, 30 Mar 2010 20:11:30 -0700 (PDT) Received: from squire.local (dsl-175-172.dynamic-dsl.frii.net [216.17.175.172]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B143340D3A for ; Tue, 30 Mar 2010 21:11:59 -0600 (MDT) Message-ID: <4BB2BD76.1010300@stpeter.im> Date: Tue, 30 Mar 2010 21:11:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: core@ietf.org References: <6AE34AF5-2E88-40A9-9E48-ED3F202CFEEC@sun.com> In-Reply-To: <6AE34AF5-2E88-40A9-9E48-ED3F202CFEEC@sun.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080202060800090301040506" Subject: Re: [core] CHTTP/Sleep-Proxy Demo on Sun SPOTs at IETF X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 03:11:32 -0000 This is a cryptographically signed message in MIME format. --------------ms080202060800090301040506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/24/10 10:50 AM, Vipul Gupta wrote: > the potential benefit of standardizing some small set of URIs for a > device -- e.g. /info where one may obtain information on its > manufacturer/model/serialNo etc, or /svc where one may obtain a list > of available services. You might look into the well-known URIs spec (soon to be RFC 5785): http://tools.ietf.org/html/draft-nottingham-site-meta-05 Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080202060800090301040506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMzMTAzMTE1MFowIwYJKoZIhvcNAQkEMRYEFJYJvPQydZFzNv8gDzS7 vjaVi5ZRMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAV7RkjYAqtx1uWS7isckTlFunS2MxxbHq4SKY4XGx FE21Km5B47GBX9WtJQ2BeFVHa+wcieC2ATVgsKnFAh4oMM/KuLj0wvNhtGlhGIP0xproO1ct FLuQn0zBlCy8/LfO2LoRp+bp4yUntxmqJng8GNbKLuGcI358w1CTBr7OcqJkPZVXnGHRZn+b 1gMKBC63BEhUfntpOGx3Y1VQfD6Y+aADafrwRHuC4K9CmvsyypMq1zVea98MPUlC9ve3moR9 lGuvGRT+9V53kMOPxsP+dHm6ZQzwM2Gf03CHEae1JrWJUAPB148GPIhrUtTvzksd0pOECLz1 whfh1bBGOxzeTgAAAAAAAA== --------------ms080202060800090301040506-- From cabo@tzi.org Wed Mar 31 00:10:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802583A69D8 for ; Wed, 31 Mar 2010 00:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.746 X-Spam-Level: X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gijrnXgZScAe for ; Wed, 31 Mar 2010 00:10:41 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1A99C3A69C6 for ; Wed, 31 Mar 2010 00:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o2V7B03w001114; Wed, 31 Mar 2010 09:11:00 +0200 (CEST) Received: from [192.168.217.101] (p5489C7A9.dip.t-dialin.net [84.137.199.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4D08BE773; Wed, 31 Mar 2010 09:11:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 31 Mar 2010 09:10:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> To: "Dave Horwitz" X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 07:10:42 -0000 On Mar 31, 2010, at 02:03, Dave Horwitz wrote: > It > was implied that if you wanted to do "some things" you might have to = do > them using TCP. It was also said that TCP cannot (or will not) be > implemented on some constrained devices. How is this reconciled? One way to do this would be to say that TCP is optional for devices that = don't deal in large resources, or (if we use my range request proposal) = that can meaningfully use range requests to operate on any large = resources (e.g., if these are just static descriptions or if there is = some caching going on). Personally, I'm indeed not sure most nodes *need* TCP. TCP likely will = be more efficient that any lock-step protocol based on range requests -- = do we need that efficiency? TCP also makes the state explicit that = would be involved in a caching scheme, but there may be other ways to do = that. Again, I have not made up my mind yet. Gruesse, Carsten From L.Wood@surrey.ac.uk Wed Mar 31 02:59:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB603A684F for ; Wed, 31 Mar 2010 02:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPq+mIV-sp+b for ; Wed, 31 Mar 2010 02:59:56 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id CCB1F3A67AE for ; Wed, 31 Mar 2010 02:59:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-10.tower-78.messagelabs.com!1270029623!654765!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 19530 invoked from network); 31 Mar 2010 10:00:23 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-10.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 31 Mar 2010 10:00:23 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Wed, 31 Mar 2010 11:00:23 +0100 From: To: , Date: Wed, 31 Mar 2010 11:00:22 +0100 Thread-Topic: [core] HTTP over UDP Thread-Index: AcrQTuHmnt45aAisT9mUA3c1wZpeCQAFZfoQABTu5gg= Message-ID: References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 09:59:57 -0000 Well, wasn't at the meeting, but I can describe some constrained devices wh= ich do not implement TCP, because it's not efficient enough for the environ= ment. So an alternative UDP-based protocol is used instead. See http://tools.ietf.org/html/draft-wood-tsvwg-saratoga http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga.html Given implementations of TCP-friendly rate control (TFRC) in various protoc= ols for when congestion control is needed, and moves to split e.g. HTTP fro= m TCP and run it over other transports, I'm having trouble seeing where use= of TCP would be a must. L. Lloyd Wood http://tinyurl.com/lloydwood-ccsr ________________________________________ From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Dave Horwi= tz [dhorwitz@echelon.com] Sent: 31 March 2010 01:03 To: core Subject: Re: [core] HTTP over UDP I've been confused about the "TCP optional" part since the meeting. It was implied that if you wanted to do "some things" you might have to do them using TCP. It was also said that TCP cannot (or will not) be implemented on some constrained devices. How is this reconciled? And can we define what "those things" are that can't/won't be done on the constrained devices? -Dave From Colin.OFlynn@atmel.com Wed Mar 31 03:15:02 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49D93A6818 for ; Wed, 31 Mar 2010 03:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlAiQnJztz5S for ; Wed, 31 Mar 2010 03:15:01 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 8E9993A67B4 for ; Wed, 31 Mar 2010 03:15:01 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o2VADQQv005631; Wed, 31 Mar 2010 03:13:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD0BB.0E2F5574" Date: Wed, 31 Mar 2010 04:12:10 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] HTTP over UDP Thread-Index: AcrQTuHmnt45aAisT9mUA3c1wZpeCQAFZfoQABTu5ggAAJrCbw== References: <4BACDDAB.9090506@gridmerge.com><1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com>, From: "Oflynn, Colin" To: , , Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 10:15:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD0BB.0E2F5574 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I could imagine TCP being used on nodes which are handling either large = frames (especially too large for UDP), or dealing with primarily = streaming traffic where TCP makes more sense. In both these cases a node which is "too constrained" to run TCP = wouldn't be able to run these more demanding application protocols = anyway.=20 Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of L.Wood@surrey.ac.uk Sent: Wed 31/03/2010 11:00 To: dhorwitz@echelon.com; core@ietf.org Subject: Re: [core] HTTP over UDP =20 Well, wasn't at the meeting, but I can describe some constrained devices = which do not implement TCP, because it's not efficient enough for the = environment. So an alternative UDP-based protocol is used instead. See http://tools.ietf.org/html/draft-wood-tsvwg-saratoga http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga.html Given implementations of TCP-friendly rate control (TFRC) in various = protocols for when congestion control is needed, and moves to split e.g. = HTTP from TCP and run it over other transports, I'm having trouble = seeing where use of TCP would be a must. L. Lloyd Wood http://tinyurl.com/lloydwood-ccsr ________________________________________ From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Dave = Horwitz [dhorwitz@echelon.com] Sent: 31 March 2010 01:03 To: core Subject: Re: [core] HTTP over UDP I've been confused about the "TCP optional" part since the meeting. It was implied that if you wanted to do "some things" you might have to do them using TCP. It was also said that TCP cannot (or will not) be implemented on some constrained devices. How is this reconciled? And can we define what "those things" are that can't/won't be done on the constrained devices? -Dave _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CAD0BB.0E2F5574 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] HTTP over UDP

Hello,

I could imagine TCP being used on nodes which are handling either large = frames (especially too large for UDP), or dealing with primarily = streaming traffic where TCP makes more sense.

In both these cases a node which is "too constrained" to run = TCP wouldn't be able to run these more demanding application protocols = anyway.

Regards,

   -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of L.Wood@surrey.ac.uk
Sent: Wed 31/03/2010 11:00
To: dhorwitz@echelon.com; core@ietf.org
Subject: Re: [core] HTTP over UDP

Well, wasn't at the meeting, but I can describe some constrained devices = which do not implement TCP, because it's not efficient enough for the = environment. So an alternative UDP-based protocol is used instead.

See
http://tool= s.ietf.org/html/draft-wood-tsvwg-saratoga
ht= tp://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga.html

Given implementations of TCP-friendly rate control (TFRC) in various = protocols for when congestion control is needed, and moves to split e.g. = HTTP from TCP and run it over other transports, I'm having trouble = seeing where use of TCP would be a must.

L.

Lloyd Wood
http://tinyurl.com/lloydwood-c= csr
________________________________________
From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Dave = Horwitz [dhorwitz@echelon.com]
Sent: 31 March 2010 01:03
To: core
Subject: Re: [core] HTTP over UDP


I've been confused about the "TCP optional" part since the = meeting. It
was implied that if you wanted to do "some things" you might = have to do
them using TCP. It was also said that TCP cannot (or will not) be
implemented on some constrained devices. How is this reconciled? And = can
we define what "those things" are that can't/won't be done on = the
constrained devices?

-Dave
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/= mailman/listinfo/core

------_=_NextPart_001_01CAD0BB.0E2F5574-- From angelo.castellani@gmail.com Wed Mar 31 08:50:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597863A6A2E for ; Wed, 31 Mar 2010 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X6hHt7BR7xk for ; Wed, 31 Mar 2010 08:50:41 -0700 (PDT) Received: from mail-yx0-f189.google.com (mail-yx0-f189.google.com [209.85.210.189]) by core3.amsl.com (Postfix) with ESMTP id B64373A6A2A for ; Wed, 31 Mar 2010 08:50:27 -0700 (PDT) Received: by yxe27 with SMTP id 27so173149yxe.17 for ; Wed, 31 Mar 2010 08:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:received:message-id:subject:from:to :content-type; bh=wU2qHd5AZZJw3Tl0+Ru04wyeJitrYdj5T05TL7IWCUo=; b=CNINgAIZOB67uz5IPb82VDNknAT4Zty2fDdkoWLjyukT9oOO1AgRpGRtDfb/5V5+2/ R9Nne64dPzHp2U+FhNvJmcuwDAgEwteYC0YJ8v+6TBuIx777h7NMUb5BCxkG0n4x8x/C Q03DGEheSAD16qzg8VHPUyW7QbLV3EuUp/JlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=ijlF316h3Tvy71p+Y+92R6o1rSUoXCufySPW/4gWDDzAhL5mPl+ZWzMGV0qqj60Uxx f4jCJbLNTlsVO8VgmOUvJbequ/gdk3UeUHozhWJ3aBgtJ7tAaQT6hMvGsZDmbp1jWF78 6UG09M4hu6MAgI3rPv+2dxyKwjMSklzkBe+Mc= MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.90.106.17 with HTTP; Wed, 31 Mar 2010 08:50:55 -0700 (PDT) Date: Wed, 31 Mar 2010 17:50:55 +0200 X-Google-Sender-Auth: a3fe38b18a6abd99 Received: by 10.91.129.4 with SMTP id g4mr273317agn.11.1270050655868; Wed, 31 Mar 2010 08:50:55 -0700 (PDT) Message-ID: From: "Angelo P. Castellani" To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Some comments on draft-shelby-core-coap-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 15:50:42 -0000 Dear all, I've some questions on CoAP, to understand why you are doing things in this way: 1) Why is a TransactionID needed, cannot be used the UDP source port of the requester to session mapping, it is the usual way to do it and we can save bytes in the header? In this way can also be exploited the 6lowpan UDP port compression, so when a lot of sessions are active, the UDP source port field size will automagically scale to a greater size. In cases where source port mapping may be changed (?? PAT?) a Transaction-ID Option can still be defined that will override the assumption that request source port maps the session. 2) Why isn't defined a SUBSCRIBE method? Isn't that one of the new "features" required? 3) The OPTIONS format is quite "big". Why don't you avoid size byte for options where the size is well-known? (from the draft: Content-type=2B, Uri-code=1B, Max-age=2B) I'm asking this because I think that actual compression with respect to a simple HTTP/1.0 request could be a lot better.. That I consider a crucial requirement because could be the main motivation for actually using CoAP and not the latter. Best regards, Angelo P. Castellani From dhorwitz@echelon.com Wed Mar 31 15:15:22 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CEC3A681B for ; Wed, 31 Mar 2010 15:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyIzlr3Es2Ev for ; Wed, 31 Mar 2010 15:15:20 -0700 (PDT) Received: from monk.echelon.com (monk.echelon.com [12.191.56.29]) by core3.amsl.com (Postfix) with ESMTP id 75A953A6807 for ; Wed, 31 Mar 2010 15:15:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Mar 2010 15:15:51 -0700 Message-ID: In-Reply-To: <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] HTTP over UDP Thread-Index: AcrQoVba2vKAuC/ASe+la1+kMtLmvAAeL92g References: <4BACDDAB.9090506@gridmerge.com> <1DC8AF8FBEC046CCB5593526878FE43D@china.huawei.com> <3B93A858-DEAC-4140-9E0E-65261937A855@tzi.org> From: "Dave Horwitz" To: "Carsten Bormann" Cc: core Subject: Re: [core] HTTP over UDP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 22:15:22 -0000 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, March 31, 2010 12:11 AM > To: Dave Horwitz > Cc: core > Subject: Re: [core] HTTP over UDP >=20 > On Mar 31, 2010, at 02:03, Dave Horwitz wrote: >=20 > > It was implied that if you wanted to do "some things"=20 > > you might have to do them using TCP. It was also said=20 > > that TCP cannot (or will not) be implemented on some=20 > > constrained devices. How is this reconciled? >=20 > One way to do this would be to say that TCP is optional=20 > for devices that don't deal in large resources,=20 This would require a definition of "large" and some way to=20 identify devices that do or do not support large resources? > or (if we use my range request proposal) that can meaningfully=20 > use range requests to operate on any large resources (e.g., if > these are just static descriptions or if there is some caching=20 > going on). This would work. I have not formed an opinion on the complexity/efficiency/practicality of this, but it would work. > Personally, I'm indeed not sure most nodes *need* TCP.=20 My view is if any nodes *need* TCP then it's not "optional" in the protocol and must be specified as required for those=20 nodes. Otherwise it's implied that some requirement is not being met? > TCP likely will be more efficient that any lock-step protocol > based on range requests - do we need that efficiency? TCP also > makes the state explicit that would be involved in a caching=20 > scheme, but there may be other ways to do that. Again, I have > not made up my mind yet. >=20 > Gruesse, Carsten -Dave