From zach@sensinode.com Mon Aug 2 04:52: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 CF6193A6BD4 for ; Mon, 2 Aug 2010 04:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_50=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 7BXhesWvp+KX for ; Mon, 2 Aug 2010 04:52:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 676D03A6BAA for ; Mon, 2 Aug 2010 04:52:56 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o72Bqk9w030074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Aug 2010 14:53:15 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 2 Aug 2010 14:26:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <82675C78-0167-4E11-9F77-EAEC0DB071E2@sensinode.com> References: To: "Simpson, Robby (GE Energy Services)" X-Mailer: Apple Mail (2.1081) Cc: brian@skyfoundry.com, core@ietf.org Subject: Re: [core] POST vs PUT in I-D coap-01 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, 02 Aug 2010 11:52:57 -0000 On Jul 30, 2010, at 7:09 PM, Simpson, Robby (GE Energy Services) wrote: > I would strongly recommend using the same semantics as 2616, but only = the bits applicable to a RESTful interface (for instance, I think we = could leave out the POST functionality for forms).=20 Agreed. >=20 > In short, PUT for modifying a resource or creating at a specific URI = and POST for creating a subordinate resource for a given URI or adding = to a "list" at a given URI.=20 This is exactly what the current coap-01 text should do. If Owen or = anyone else feels the text for the POST or PUT subsections needs some = tweaking then suggestions are welcome for coap-02.=20 Thanks, Zach=20 >=20 > - Robby >=20 >=20 > ------------ > Sent from my BlackBerry - thus the tpyos and brvty >=20 > ----- Original Message ----- > From: core-bounces@ietf.org > To: core@ietf.org > Cc: brian@skyfoundry.com > Sent: Fri Jul 30 08:55:46 2010 > Subject: [core] POST vs PUT in I-D coap-01 >=20 > Hi, >=20 > During the plugfest on Wednesday, I found that the text on the methods > POST and PUT in sections 2.3.2 and 2.3.3 is somewhat ambiguous (at = least > to me). I read this as POST is the method to create new resources = that > are identified by the given request URI while PUT is used specifically > for modifying existing resources (as the creation of new resources is = a > MAY in section 2.3.3). >=20 > I suppose the intention of POST and PUT is the very same as in = sections > 9.5 and 9.6 of RFC 2616? >=20 > Thanks, > Olaf > _______________________________________________ > 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 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From fluffy@cisco.com Tue Aug 3 10:26: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 233303A6AC2 for ; Tue, 3 Aug 2010 10:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.397 X-Spam-Level: X-Spam-Status: No, score=-109.397 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_20=-0.74, HTML_MESSAGE=0.001, 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 yxZ6qRysLdVU for ; Tue, 3 Aug 2010 10:26:04 -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 1EF453A6A99 for ; Tue, 3 Aug 2010 10:26:04 -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: AlEFAIDuV0yrR7Ht/2dsb2JhbACBRJ5NcYgboHGbV4J6EAaCKQSEF4R3iWo X-IronPort-AV: E=Sophos;i="4.55,311,1278288000"; d="scan'208,217";a="166886198" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 03 Aug 2010 17:26:32 +0000 Received: from dhcp-171-68-21-71.cisco.com (dhcp-171-68-21-71.cisco.com [171.68.21.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73HQW1Z026315; Tue, 3 Aug 2010 17:26:32 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1--246000769 From: Cullen Jennings X-Priority: 3 Date: Tue, 3 Aug 2010 10:26:33 -0700 Message-Id: References: <0EA51384-5EAF-4FA8-90CC-D7C003483AC0@amsl.com> To: core X-Mailer: Apple Mail (2.1081) Subject: [core] Webex info for CORE phone call on Wed Aug 25 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, 03 Aug 2010 17:26:06 -0000 --Apple-Mail-1--246000769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>=20 >> -------------------------------------------------------=20 >> Meeting information=20 >> -------------------------------------------------------=20 >> Topic: CORE=20 >> Date: Wednesday, August 25, 2010=20 >> Time: 3:00 pm, (Reykjavik, GMT)=20 >> Meeting Number: 966 638 223=20 >> Meeting Password: (This meeting does not require a password.)=20 >>=20 >> -------------------------------------------------------=20 >> To start or join the online meeting=20 >> -------------------------------------------------------=20 >> Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D135667597&UID=3D483233937= &RT=3DMiMyMA%3D%3D=20 >>=20 >> -------------------------------------------------------=20 >> Audio conference information=20 >> -------------------------------------------------------=20 >> To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 >> Call-in toll number (US/Canada): 1-408-792-6300=20 >> Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED= =3D135667597&tollFree=3D0=20 >>=20 >> Access code:966 638 223=20 >>=20 >> -------------------------------------------------------=20 >> For assistance=20 >> -------------------------------------------------------=20 >> 1. Go to https://workgreen.webex.com/workgreen/mc=20 >> 2. On the left navigation bar, click "Support".=20 >> To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 >> = https://workgreen.webex.com/workgreen/j.php?ED=3D135667597&UID=3D483233937= &ICS=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA2=3D6e5oUaV5lRDBWS40m9TFH9Ra1A3NhSF5xRZ9= 1lYEHz0=3D=20 >>=20 >> To check whether you have the appropriate players installed for UCF = (Universal Communications Format) rich media files, go to = https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 >>=20 >> http://www.webex.com=20 >>=20 >>=20 >>=20 >> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. You should inform all meeting attendees = prior to recording if you intend to record the meeting. Please note that = any such recordings may be subject to discovery in the event of = litigation.=20 >=20 > - --Apple-Mail-1--246000769 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

= -------------------------------------------------------
Meeting = information
------------------------------------------------------- =
Topic: CORE
Date: Wednesday, August 25, 2010
Time: 3:00 = pm, (Reykjavik, GMT)
Meeting Number: 966 638 223
Meeting = Password: (This meeting does not require a password.)

= -------------------------------------------------------
To start or = join the online meeting
= -------------------------------------------------------
Go to https://workgreen.webex.com/workgreen/j.php?ED=3D1356675= 97&UID=3D483233937&RT=3DMiMyMA%3D%3D

= -------------------------------------------------------
Audio = conference information
= -------------------------------------------------------
To receive = a call back, provide your phone number when you join the meeting, or = call the number below and enter the access code.
Call-in toll = number (US/Canada): 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?s= erviceType=3DMC&ED=3D135667597&tollFree=3D0

Access = code:966 638 223

= -------------------------------------------------------
For = assistance
------------------------------------------------------- =
1. Go to https://workgreen.webex.com/workgreen/mc
2. = On the left navigation bar, click "Support".
To add this meeting to = your calendar program (for example Microsoft Outlook), click this link: =
https://workgreen.webex.com/workgreen/j.php?ED=3D1356675= 97&UID=3D483233937&ICS=3DMS&LD=3D1&RD=3D2&ST=3D1&S= HA2=3D6e5oUaV5lRDBWS40m9TFH9Ra1A3NhSF5xRZ91lYEHz0=3D

To = check whether you have the appropriate players installed for UCF = (Universal Communications Format) rich media files, go to https://workgreen.webex.com/workgreen/systemdiagnosis.ph= p

http://www.webex.com



IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the session to = be recorded. You should inform all meeting attendees prior to recording = if you intend to record the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation.
=

-
= --Apple-Mail-1--246000769-- From wwwrun@core3.amsl.com Tue Aug 3 11:49:17 2010 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 766A83A6AD9; Tue, 3 Aug 2010 11:49:17 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100803184917.766A83A6AD9@core3.amsl.com> Date: Tue, 3 Aug 2010 11:49:17 -0700 (PDT) Cc: core@ietf.org Subject: [core] Announcement of CORE WG Conference Call, August 25, 2010 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, 03 Aug 2010 18:49:17 -0000 The CORE WG will have a conference call via webex on August 25 at 15:00 UTC for 2 hours. Agenda and details will be posted on the core@ietf.org mailing list. Note this is 8:00 PDT and 17:00 CEST. From bimschas@itm.uni-luebeck.de Wed Aug 11 00:42: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 811393A6A28 for ; Wed, 11 Aug 2010 00:42:40 -0700 (PDT) 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 Yh7x4g1DUuNJ for ; Wed, 11 Aug 2010 00:42:38 -0700 (PDT) Received: from itm01.itm.uni-luebeck.de (itm01.itm.uni-luebeck.de [141.83.68.100]) by core3.amsl.com (Postfix) with ESMTP id 84F973A6804 for ; Wed, 11 Aug 2010 00:42:37 -0700 (PDT) Received: from opium.itm.uni-luebeck.de (opium.itm.uni-luebeck.de [141.83.68.179]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by itm01.itm.uni-luebeck.de (Postfix) with ESMTPSA id 5290283F8E3 for ; Wed, 11 Aug 2010 09:43:12 +0200 (CEST) From: Daniel Bimschas Content-Type: multipart/signed; boundary=Apple-Mail-7-410197862; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 11 Aug 2010 09:43:12 +0200 Message-Id: <8E5856C3-59FD-4633-803E-3426B35E123F@itm.uni-luebeck.de> To: core@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Sensor node implementations 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: Wed, 11 Aug 2010 07:42:40 -0000 --Apple-Mail-7-410197862 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi list, I just have a short question. Are there already any early (open-source) = implementations of CoAP for wireless sensor nodes available? If yes, = what OS and/or hardware is supported? Is it open for other developers to = commit/contribute? The background of my question is, that we're currently thinking about = implementing and evaluating CoAP for our wireless sensor nodes and were = wondering if that's worth the effort ;-) Kind regards, Daniel= --Apple-Mail-7-410197862 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFNzCCBB+gAwIBAgIEChiHZjANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDMxNTA4NTQ0 N1oXDTE5MDMxNDAwMDAwMFowgasxCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQg enUgTHVlYmVjazEuMCwGA1UECxMlSW5zdGl0dXQgZnVlciBNZWRpemluaXNjaGUgSW5mb3JtYXRp azEnMCUGA1UEAxMeQ0EgZGVyIFVuaXZlcnNpdGFldCB6dSBMdWViZWNrMSEwHwYJKoZIhvcNAQkB FhJwa2lAdW5pLWx1ZWJlY2suZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWZS7m r7XjjwizbKXx3HQYxk369Bw40r31jGlnN0lJl2e+VCzKa2KOSGndQ2dfPEFfGTS16BEhpf8SPPYD PEsMz8WR/FnZdFGK4qpV0b7+pzN7L4xgnKoG2LXWaJR2hygCb6fG2EiPWT7eovN4PK/sNXj/5ekP fXdyKrD9fbMPhll+mTTR9DsCypH5oDGOFAsNAn3h0iE4dYPTl67T3LGhYl7Wd7Z9zSZRfD6a+lOm J86jguBL1rfq5wvefwIvsGZYYwOTf+uZyMosFYZlGMJCY0m9JO/ZNoRGdDGdv1iFVSxeL0im28gZ zoREaPbc7qFaTKw0w2kCoROEYhXmrqFDAgMBAAGjggGxMIIBrTAPBgNVHRMBAf8EBTADAQH/MAsG A1UdDwQEAwIBBjAdBgNVHQ4EFgQUtytvwMcYEDE2F1IQdaHQQMM5NB8wHwYDVR0jBBgwFoAUSbfG z+g9H3/qRHsTKffxCnA+3mQwHQYDVR0RBBYwFIEScGtpQHVuaS1sdWViZWNrLmRlMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3Js L2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAopseiKAnns0Q+mVXqJfb7JdQkuFnNNfMUPnU DA2upi+bxj5ZJFLBckRlrqq4X1QNLUfFzJTMn+2eGhwX+o/WdUKhXxPceLEDFzlmLBjvV+hDEktE MBMeUIsPtBhl0HjiZQXN6OTBjmHeSqUf5hhr7BuGLg85tV8XqO4ZEssPibF+2W8Qrbja+0RNaQ3M z454MW4blXziGaz0ySFRL1kVXtYF+FM4bldtgIApXJvZmDYVCzQ6Lif0jphvBUG7R8UEF/h1ZFdm KNwe0juUX0jmf+8OYZans8ObDGENRyyWSUe/KClmRO5phFK95LACNSpl7ueJeWwqo6jK1Rb8PN0d tzCCBUAwggQooAMCAQICBA8jnP0wDQYJKoZIhvcNAQEFBQAwgasxCzAJBgNVBAYTAkRFMSAwHgYD VQQKExdVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEuMCwGA1UECxMlSW5zdGl0dXQgZnVlciBNZWRp emluaXNjaGUgSW5mb3JtYXRpazEnMCUGA1UEAxMeQ0EgZGVyIFVuaXZlcnNpdGFldCB6dSBMdWVi ZWNrMSEwHwYJKoZIhvcNAQkBFhJwa2lAdW5pLWx1ZWJlY2suZGUwHhcNMDkxMTE4MTYyMzA5WhcN MTIxMTE3MTYyMzA5WjBXMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1 ZWJlY2sxDDAKBgNVBAsTA0lUTTEYMBYGA1UEAxMPRGFuaWVsIEJpbXNjaGFzMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoyuuPmJVmcAgGqD88Buo28xWB9M2K4xRSDFyxAq6my795dac 24WNuheq6MTDzl8VlQt51euYjBLGTXVWvsVMEDbC3EPqd8BME2Dxl9YLXstTUoAP95IHkZ5QraiN 2bEeSmdGz+XvHjST0xCuCZKpn2+fShyVU6SqlRQx5eLVTS1OvD/Wox++OdNAvaVxxVmvmM3W596f aUfd2l5a4dvMwR5fog6dWYQ27TlWK7oawb7afAFNsYqy51Y9zniErXUo48dvWDvlyy8HZyVqrD4C DLqBdMt8oQ2yZrDQDeZ9Ea+Pd3/x0pGNfTOmBc5B2uYYZl3VLX9giYEGrZ/dFl+aiQIDAQABo4IB vTCCAbkwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUF BwMEBgorBgEEAYI3FAICMB0GA1UdDgQWBBTSsiROJNYBKUR2iL6pBxt8ICDbWjAfBgNVHSMEGDAW gBS3K2/AxxgQMTYXUhB1odBAwzk0HzAmBgNVHREEHzAdgRtiaW1zY2hhc0BpdG0udW5pLWx1ZWJl Y2suZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS91emwtY2EvcHVi L2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvdXpsLWNhL3B1Yi9j cmwvY2FjcmwuY3JsMIGSBggrBgEFBQcBAQSBhTCBgjA/BggrBgEFBQcwAoYzaHR0cDovL2NkcDEu cGNhLmRmbi5kZS91emwtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3V6bC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBAG6RWU3TV0viAr5G142hIWIq68nll/Vq7eZFi8BPLkn+AZJ7I2uUPWAQVWXo05hY GwoJn11jUHzX7WdsEQHsjFqzYaf/0kTvOqgabUJa7WDyCpaArRh2+EINtDdqo+8KbcHC79h5Xw/I uCII3uo2mLV7m1SwU1Ps22skpGKMxnoBEnOuW4p2tiOQxwT5rsYrgjllp+u6T+Vyr2P2vcIDY2sg 9L+J/76oQJkRgj6Ey6yJ2bt8AMMJBrkN42PXXAzFTinyCptyOUcDWe5f2uVAElj90U0zvQkz0612 +Z4ZmptsRPkH5uluKddzd0a1CAa+2s4TVSMAoAX+vQOq4JY1nyMxggPPMIIDywIBATCBtDCBqzEL MAkGA1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMS4wLAYDVQQLEyVJ bnN0aXR1dCBmdWVyIE1lZGl6aW5pc2NoZSBJbmZvcm1hdGlrMScwJQYDVQQDEx5DQSBkZXIgVW5p dmVyc2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0BCQEWEnBraUB1bmktbHVlYmVjay5kZQIE DyOc/TAJBgUrDgMCGgUAoIIB7zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMDA4MTEwNzQzMTJaMCMGCSqGSIb3DQEJBDEWBBQGG9UMtKtzgrKRN/B43HcKi17xrzCB xQYJKwYBBAGCNxAEMYG3MIG0MIGrMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0 IHp1IEx1ZWJlY2sxLjAsBgNVBAsTJUluc3RpdHV0IGZ1ZXIgTWVkaXppbmlzY2hlIEluZm9ybWF0 aWsxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJ ARYScGtpQHVuaS1sdWViZWNrLmRlAgQPI5z9MIHHBgsqhkiG9w0BCRACCzGBt6CBtDCBqzELMAkG A1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMS4wLAYDVQQLEyVJbnN0 aXR1dCBmdWVyIE1lZGl6aW5pc2NoZSBJbmZvcm1hdGlrMScwJQYDVQQDEx5DQSBkZXIgVW5pdmVy c2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0BCQEWEnBraUB1bmktbHVlYmVjay5kZQIEDyOc /TANBgkqhkiG9w0BAQEFAASCAQBBlvBoyS371sHSAmLHlxej1yYvOoO0F/D8sjkqjSU5b0lK2Rbv Td3DS4cpRC2gMSu7H1Hqai5hABWL0s1eJTe+oJbl4PGQFAIZTbjaLyRz5tTDdVj7iFKxoD6G4DYY HubMJBwD69eEoqCwRpUTh7kMG7Z5XIe+47AJ28GGdtlFQF5y15ipnusmK7SISfvK0tQcnL3fqREt Mo1HwYC9sePWpe+d8CkihER7PgWORIfzIeTQ9asYY4tranHVPvKpGQpnsYWzO2E8KvhvZtw178yp CQb7zkjFCbrN4hJ8iW63Gs+ZlZhc276ocu5t52yvStbE8X/YlWJTAh5ZCGrlMtp+AAAAAAAA --Apple-Mail-7-410197862-- From hariharasudhan.tce@gmail.com Wed Aug 18 00:08: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 28B7B3A6A09 for ; Wed, 18 Aug 2010 00:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 87lvNfVKrKbK for ; Wed, 18 Aug 2010 00:08:42 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8E2473A67B7 for ; Wed, 18 Aug 2010 00:08:41 -0700 (PDT) Received: by ewy22 with SMTP id 22so127742ewy.31 for ; Wed, 18 Aug 2010 00:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=U7DeVMIYL+jymRzFeXolNSiejUaX6OoCWj/FN5J7KuI=; b=uiCo2pMAnKLxjQ/Zj8IjpOWkMfXThei9QRpzY6Q4HzS1sSEU27IcykonCDEg5bA9So ejxqeARYsGM1quIee0bQoMLoqt2Jo4fGOE8knyMj+CGoQnvg+8EDAagboMpkhq+8fQAw 4dMfiuklvLdR+Mvgk/Hu9+PXOPBO4jLKbMSGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YErPxTID4mHX9I6JmvFWCiM9qVIgDk71flDyW2FjSRJFxRJeV3bz/UCPgJBmdCLIE7 N8SiDqGDk0zw1S5aKWxDtiWnWEWP8NwQRIZJXLhA26mA71NNZ6AJtJMtLxf0u0aPBHfP 3AKhNHRatqPRxhZEXvAFIR/eT1DIigDbtkR18= MIME-Version: 1.0 Received: by 10.213.15.82 with SMTP id j18mr1682339eba.78.1282115355989; Wed, 18 Aug 2010 00:09:15 -0700 (PDT) Received: by 10.213.23.19 with HTTP; Wed, 18 Aug 2010 00:09:15 -0700 (PDT) Date: Wed, 18 Aug 2010 12:39:15 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Response Code in ACK in case of asynchronous response 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, 18 Aug 2010 07:08:47 -0000 Hi all, In case of asynchronous response when the server sends a response what is the response code it should use? Thanks and Regards, Hari Hara Sudhan R From ydoi@isl.rdc.toshiba.co.jp Wed Aug 18 00:26: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 BA63F3A67A7 for ; Wed, 18 Aug 2010 00:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, 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 ZRWYeLCu7YI1 for ; Wed, 18 Aug 2010 00:26:44 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 7D7363A68C0 for ; Wed, 18 Aug 2010 00:26:44 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id o7I7RJPG007521 for ; Wed, 18 Aug 2010 16:27:19 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id o7I7RJ6t028676 for core@ietf.org; Wed, 18 Aug 2010 16:27:19 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id SAA28675; Wed, 18 Aug 2010 16:27:19 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id o7I7RIYG018179 for ; Wed, 18 Aug 2010 16:27:18 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id o7I7RIFQ013385; Wed, 18 Aug 2010 16:27:18 +0900 (JST) Received: from [133.196.16.126] (ncg-dhcp126.isl.rdc.toshiba.co.jp [133.196.16.126]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id 9275797CC4; Wed, 18 Aug 2010 16:27:18 +0900 (JST) Message-ID: <4C6B8B55.3030408@isl.rdc.toshiba.co.jp> Date: Wed, 18 Aug 2010 16:27:17 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: hariharasudhan.tce@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Response Code in ACK in case of asynchronous response 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, 18 Aug 2010 07:26:45 -0000 Hi all, Let me ask a related question. - How long should a client wait for asynchronous response, after receiving acknowledge? Personally I think there should be some refresh mechanism (for example, periodic ack with same tid) to let client know the server is working on the request. Otherwise, the server may lost the state and the client have to keeps waiting. Regards, // Yusuke DOI , TOSHIBA Corp., R&D Center (2010/08/18 16:09), Hari Hara Sudhan R wrote: > Hi all, > > In case of asynchronous response when the server sends a response what > is the response code it should use? > > Thanks and Regards, > Hari Hara Sudhan R > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From hariharasudhan.tce@gmail.com Wed Aug 18 01:36:52 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 723833A68AE for ; Wed, 18 Aug 2010 01:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 62bN9TC-7eXO for ; Wed, 18 Aug 2010 01:36:42 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B54033A6A09 for ; Wed, 18 Aug 2010 01:31:38 -0700 (PDT) Received: by ewy22 with SMTP id 22so155418ewy.31 for ; Wed, 18 Aug 2010 01:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=mPpCaWYRinwEZ4f4jbGSXxh9SsPW+ENDnvEi2MH14ek=; b=p4Jmm0cqmurSITkuIF2yDnUEY4XXu9jrCUDzrzz8FXNxSt3Kco35zIGQYNRguRaeuY ywriL/tUqvH+Ae9HEgvWw46XKFZr6DAhS8KV7yPAgJeWWso0USVC0nefGoM3GdjkAYwP dJHZn7WOR1t8uagZVQ6CuLxwpFid3TeCK6Oa4= 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 :content-type; b=GYVNNj5hzj+hKwPLnyeRlGgon9RziliFJanMQ9p1n3v49DnlxzqQ2D89TKCq0oXgOH Xk3hIdfdPEjrJkxSnV083PiM8b/V7iB7ye36HfBHHpCXidIEtl53au994gdVJXvdERlF AW2lvZWA7JpmTlDHnylpNLFH/WAnrtspRdxjw= MIME-Version: 1.0 Received: by 10.213.113.194 with SMTP id b2mr1754882ebq.89.1282120312566; Wed, 18 Aug 2010 01:31:52 -0700 (PDT) Received: by 10.213.23.19 with HTTP; Wed, 18 Aug 2010 01:31:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 14:01:52 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Response Code in ACK in case of asynchronous response 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, 18 Aug 2010 08:36:52 -0000 Hi all, Let me be more clear. In case of asynchronous response when the server sends a acknowledgement what is the response code it should use? Thanks and Regards, Hari Hara Sudhan R On Wed, Aug 18, 2010 at 12:39 PM, Hari Hara Sudhan R wrote: > Hi all, > > In case of asynchronous response when the server sends a response what > is the response code it should use? > > Thanks and Regards, > Hari Hara Sudhan R > From bergmann@tzi.org Wed Aug 18 03:11: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 969E73A69A3 for ; Wed, 18 Aug 2010 03:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 kEl4u4QFm7iO for ; Wed, 18 Aug 2010 03:11:08 -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 5FA263A6914 for ; Wed, 18 Aug 2010 03:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from aung.localdomain.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o7IABMJo023494; Wed, 18 Aug 2010 12:11:33 +0200 (CEST) From: Olaf Bergmann To: Hari Hara Sudhan R References: Date: Wed, 18 Aug 2010 12:11:22 +0200 In-Reply-To: (Hari Hara Sudhan R.'s message of "Wed, 18 Aug 2010 14:01:52 +0530") Message-ID: <877hjo1b91.fsf@aung.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: core@ietf.org Subject: Re: [core] Response Code in ACK in case of asynchronous response 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, 18 Aug 2010 10:11:10 -0000 Hari Hara Sudhan R writes: > In case of asynchronous response when the server sends a acknowledgement what > is the response code it should use? Does anything except 200 (in HTTP-speak) make sense? Gruesse, Olaf From hariharasudhan.tce@gmail.com Wed Aug 18 03:23: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 207D53A6A72 for ; Wed, 18 Aug 2010 03:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 RZ7TTMsPp21R for ; Wed, 18 Aug 2010 03:23:08 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 077A33A6A6C for ; Wed, 18 Aug 2010 03:23:06 -0700 (PDT) Received: by eyd10 with SMTP id 10so187338eyd.31 for ; Wed, 18 Aug 2010 03:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=632mS8oFW7oIELeNlxZafu27oeGTYYfub1hnCXcaBHA=; b=VysxRPBMTnuDwtb/FCPL2GsucD5siyh8n1qrGfSOY6qWWrACaGdFk3IED0d+TSk3aR il661AaCICJ05eyVIT3bbLUiaedXdOeIUkVEiaZe/+pT2M2drhkSe3GEVLhC81c8YHbr TsFXrtCphTFUtEIrh8rsxtRRmPfhVJbseEzfE= 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; b=HpjC5nKZRNns40x7wYDRPHYm1QNpiph5cEEzhK6u4YmFAoaBiPAWZEyfDBrebGqteK ONUdSmGU0VzR/f5XeEGf8+du52xUKAXnxwDjyXsuUZp4PpKAEs+UmTfgUdYXeur1NdXd RbqTesitUmzhQAGxlTfJtTlAwjjcoan4Plrcw= MIME-Version: 1.0 Received: by 10.213.29.18 with SMTP id o18mr1930149ebc.35.1282127021462; Wed, 18 Aug 2010 03:23:41 -0700 (PDT) Received: by 10.213.23.19 with HTTP; Wed, 18 Aug 2010 03:23:41 -0700 (PDT) In-Reply-To: <877hjo1b91.fsf@aung.localdomain> References: <877hjo1b91.fsf@aung.localdomain> Date: Wed, 18 Aug 2010 15:53:41 +0530 Message-ID: From: Hari Hara Sudhan R To: Olaf Bergmann Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] Response Code in ACK in case of asynchronous response 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, 18 Aug 2010 10:23:11 -0000 > Does anything except 200 (in HTTP-speak) make sense? 200 makes sense.But then how does the client know whether that is just an acknowledgement or a synchronous response. May be Im missing something. Thanks and Regards, Hari hara Sudhan R On Wed, Aug 18, 2010 at 3:41 PM, Olaf Bergmann wrote: > Hari Hara Sudhan R writes: > >> In case of asynchronous response when the server sends a acknowledgement what >> is the response code it should use? > > > Gruesse, > Olaf > From cabo@tzi.org Wed Aug 18 03:31: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 394763A6914 for ; Wed, 18 Aug 2010 03:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.172 X-Spam-Level: X-Spam-Status: No, score=-106.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 vQxC-Dfl-EQB for ; Wed, 18 Aug 2010 03:31:48 -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 2F2403A69A3 for ; Wed, 18 Aug 2010 03:31:38 -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 o7IAW1tC029903; Wed, 18 Aug 2010 12:32:06 +0200 (CEST) Received: from [192.168.217.101] (p5489EAC9.dip.t-dialin.net [84.137.234.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 16E676A02; Wed, 18 Aug 2010 12:32:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <877hjo1b91.fsf@aung.localdomain> Date: Wed, 18 Aug 2010 12:31:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <877hjo1b91.fsf@aung.localdomain> To: Olaf Bergmann X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] Response Code in ACK in case of asynchronous response 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, 18 Aug 2010 10:31:51 -0000 On Aug 18, 2010, at 12:11, Olaf Bergmann wrote: > Hari Hara Sudhan R writes: >=20 >> In case of asynchronous response when the server sends a = acknowledgement what >> is the response code it should use? I'm not sure I understand the question. You mean the second message in = the four-message exchange? > Does anything except 200 (in HTTP-speak) make sense? Well, 200 would mean "here is the (OK) answer now". Figure 3 from 2.1.2 may be a bit brief: Client Server | | | CON tid=3D48 | | GET http://n.. | +---------------->| | | | ACK tid=3D48 | |<----------------+ | | ... Time Passes ... | | | CON tid=3D783 | | 200 http://n.. | | "| | | The two messages marked ACK do not carry a code at all, i.e. use code 0. Gruesse, Carsten From hariharasudhan.tce@gmail.com Wed Aug 18 04:18: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 CC64B3A6A7D for ; Wed, 18 Aug 2010 04:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 oiyfsK865brf for ; Wed, 18 Aug 2010 04:18:43 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 9E9513A6A79 for ; Wed, 18 Aug 2010 04:18:43 -0700 (PDT) Received: by ewy22 with SMTP id 22so244130ewy.31 for ; Wed, 18 Aug 2010 04:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W7XFpEf9lLemAtMsZLVT5MD2d0ZbEyodULU9UcQnO7E=; b=CJr47mcNG1KEyD5Gkxhkvlp7D/T1z/ZaBofTg5kkID4OPEXpRLRMJrLvuj3bLMWayz hDp6yH//eEETC4CiqbZcK4/HikMX/izA2dPks82+9VOwR+zzWJNseu5oFpfuMp1fOi2n ZXjHyplUW0n8rBABJd9sQPMISWqchTm1LBuHk= 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=eDjsT/kvj90tlnYdmph4YLlQLUZcz1ZT1QB4xokeepbUacv00FZ56fnJ3dHA/agQv+ o2hMc5Y5s7jK11AWFBF5Kv5NptWUEKwwsAIZJ/K4+PLdyeZ8FdqbB1p4Pz56Eu3aLM9b h38Nwup+nOZ7uIUPjQqrCMln8XC0ufZV9G4rU= MIME-Version: 1.0 Received: by 10.213.33.72 with SMTP id g8mr190207ebd.10.1282130357961; Wed, 18 Aug 2010 04:19:17 -0700 (PDT) Received: by 10.213.23.19 with HTTP; Wed, 18 Aug 2010 04:19:17 -0700 (PDT) In-Reply-To: References: <877hjo1b91.fsf@aung.localdomain> Date: Wed, 18 Aug 2010 16:49:17 +0530 Message-ID: From: Hari Hara Sudhan R To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Response Code in ACK in case of asynchronous response 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, 18 Aug 2010 11:18:45 -0000 Thanks a lot. That was my question. Now it is clear. Thanks and Regards, Hari Hara Sudhan R On Wed, Aug 18, 2010 at 4:01 PM, Carsten Bormann wrote: > > On Aug 18, 2010, at 12:11, Olaf Bergmann wrote: > >> Hari Hara Sudhan R writes: >> >>> In case of asynchronous response when the server sends a acknowledgemen= t what >>> is the response code it should use? > > I'm not sure I understand the question. =A0You mean the second message in= the four-message exchange? > >> Does anything except 200 (in HTTP-speak) make sense? > > Well, 200 would mean "here is the (OK) answer now". > > Figure 3 from 2.1.2 may be a bit brief: > > > =A0 Client =A0 =A0 =A0 =A0 =A0 =A0 Server > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 CON tid=3D48 =A0 =A0| > =A0 =A0 =A0| =A0GET http://n.. | > =A0 =A0 =A0+---------------->| > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 ACK tid=3D48 =A0 =A0| > =A0 =A0 =A0|<----------------+ > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0... Time Passes ... > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 CON tid=3D783 =A0 | > =A0 =A0 =A0| =A0200 http://n.. | > =A0 =A0 =A0| =A0 =A0 " =A0 =A0 =A0|<----------------+ > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 ACK tid=3D783 =A0 | > =A0 =A0 =A0+---------------->| > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > The two messages marked ACK do not carry a code at all, i.e. use code 0. > > Gruesse, Carsten > > From matthieu.vial@fr.non.schneider-electric.com Fri Aug 20 03:17: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 7AFB73A694C for ; Fri, 20 Aug 2010 03:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HfrcEKmjUDH6 for ; Fri, 20 Aug 2010 03:17:27 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 641473A68E6 for ; Fri, 20 Aug 2010 03:17:27 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010082012073035-40431 ; Fri, 20 Aug 2010 12:07:30 +0200 To: core X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Fri, 20 Aug 2010 12:17:54 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 20/08/2010 12:18:00, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 20/08/2010 12:07:30, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 20/08/2010 12:07:32, Serialize complete at 20/08/2010 12:07:32 Content-type: multipart/alternative; Boundary="0__=4EBBFD16DFB957F48f9e8a93df938690918c4EBBFD16DFB957F4" Content-Disposition: inline Subject: [core] Asynchronous exchange 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, 20 Aug 2010 10:17:29 -0000 --0__=4EBBFD16DFB957F48f9e8a93df938690918c4EBBFD16DFB957F4 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Hi all, Are you planning to improve the way to relate an asynchrounous response= to a request for CoAP clients ? In a 4-message exchange the TID changes so currently the only invariant= is the tuple (address, uri) if I'm right. Decoding this tuple seems quite complex for a constrained node just to = find a response to a request. And we still have problems with - multicast addresses - proxied requests - a sequence of requests PUT, GET to the same (address, uri) because th= e method is not preserved. The token option in coap-misc could be a solution. But the presence of = this option would be a client-side decision whereas the synchronous/asynchro= nous mode is currently a server-side decision. So there would be different ways of associating an asynchronous respons= e to a request depending on the presence of the option. Multiplicity is not = a good thing for constrained devices. Could be the asynchronous mode always a client-side decision ? The server could return an error code if it knows the request will take= too much time without the asynchronous mode. That way we could also have implementations supporting only the synchronous mode. What are the current rules to decide to activate the asynchronous mode = or to stay in synchronous mode for servers ? I presume it should be the processing time of the request compared to RESPONSE_TIMEOUT to avoid retransmissions. But RESPONSE_TIMEOUT includes the transfer time which = is fluctuating and not necessarily negligible on a mesh 802.15.4 network. This kind of rules can only be determined by the server and seems incompatible with a client-side asynchronous mode. Regards, Matthieu= --0__=4EBBFD16DFB957F48f9e8a93df938690918c4EBBFD16DFB957F4 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi all,

Are you planning to improve the way to relate an asynchrounous response= to a request for CoAP clients ?
In a 4-message exchange the TID changes so currently the only invariant= is the tuple (address, uri) if I'm right.
Decoding this tuple seems quite complex for a constrained node just to = find a response to a request.
And we still have problems with
- multicast addresses
- proxied requests
- a sequence of requests PUT, GET to the same (address, uri) because th= e method is not preserved.

The token option in coap-misc could be a solution. But the presence of = this option would be a client-side decision whereas the synchronous/asy= nchronous mode is currently a server-side decision.
So there would be different ways of associating an asynchronous respons= e to a request depending on the presence of the option. Multiplicity is= not a good thing for constrained devices.
Could be the asynchronous mode always a client-side decision ?
The server could return an error code if it knows the request will take= too much time without the asynchronous mode. That way we could also ha= ve implementations supporting only the synchronous mode.

What are the current rules to decide to activate the asynchronous mode = or to stay in synchronous mode for servers ? I presume it should be the= processing time of the request compared to RESPONSE_TIMEOUT to avoid r= etransmissions. But RESPONSE_TIMEOUT includes the transfer time which i= s fluctuating and not necessarily negligible on a mesh 802.15.4 network= .
This kind of rules can only be determined by the server and seems incom= patible with a client-side asynchronous mode.

Regards,
Matthieu= --0__=4EBBFD16DFB957F48f9e8a93df938690918c4EBBFD16DFB957F4-- From trac@tools.ietf.org Fri Aug 20 05:22: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 7F75B3A68AE for ; Fri, 20 Aug 2010 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 CQullnDMvAXg for ; Fri, 20 Aug 2010 05:22:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9EC933A6892 for ; Fri, 20 Aug 2010 05:22:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OmQcc-0005Vh-Iz; Fri, 20 Aug 2010 05:22:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 20 Aug 2010 12:22:58 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/18 Message-ID: <057.72fc0681b884c100f9ed31e99d5f745b@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #18: Error on critical option clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 12:22:25 -0000 #18: Error on critical option clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Section 2.5.1 is not clear enough with regard to how to send an error in reponse to a critical option that is not supported. In addition to a 400 Bad Request code, a copy of the critical option number should be included in the payload. Change "including a copy of the critical option number" to "including a copy of the critical option number in the payload of the response" -- Ticket URL: core From trac@tools.ietf.org Fri Aug 20 05:54:31 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 E56EA3A699A for ; Fri, 20 Aug 2010 05:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 p03YmHEt6KVR for ; Fri, 20 Aug 2010 05:54:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3543A3A6877 for ; Fri, 20 Aug 2010 05:54:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OmR7h-0004n1-IQ; Fri, 20 Aug 2010 05:55:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 20 Aug 2010 12:55:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/19 Message-ID: <057.ca541c1c2b0a8779f8dcf23985b22808@tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #19: Clarification about PUT X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 12:54:32 -0000 #19: Clarification about PUT --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- A thread on the list discussed that the basic semantics of POST and PUT in CoAP should be the same as in RFC2616 as applicable to RESTful interfaces. After a review of Sections 2.3.2/2.3.3 in coap-01 and Sections 9.5/9.6 of RFC2616 I propose that just an editorial change is needed: Section 2.3.3 PUT Change "be updated with the enclosed body" to "be updated or created with the enclosed body" The current coap-01 might have given the wrong impression from the first sentence that PUT is only for updating an existing resource. -- Ticket URL: core From trac@tools.ietf.org Fri Aug 20 06:04:23 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 150FB3A6892 for ; Fri, 20 Aug 2010 06:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Ryu9OHZ95qzZ for ; Fri, 20 Aug 2010 06:04:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5D0013A6A17 for ; Fri, 20 Aug 2010 06:04:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OmRHB-0005EY-Mq; Fri, 20 Aug 2010 06:04:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 20 Aug 2010 13:04:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/20 Message-ID: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #20: Proxying clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:04:23 -0000 #20: Proxying clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The following changes with regard to Section 5.3. Proxying are proposed: - A new list item is required for the steps upon receiving a Uri-Authority header. In the case that this option is received by an end-point which does not support proxying, then an error is returned as specified in Section 2.5.1 since the option is critical. - The behaviour when a proxy receives a request with a Uri-Authority of the proxy itself should be clarified. It is proposed that the proxy returns a 400 Bad Request in this case. - The Uri-Scheme Option is not actually required in the current CoAP design, and this proposes that the option be removed for simplicity. A CoAP-CoAP proxy simply assumes that the scheme is coap:// and a CoAP-HTTP proxy assumes that the scheme is http://. This obviously means that a proxy on the same port can't support both CoAP-CoAP and CoAP-HTTP functionality (something people can surely live with) as it wouldn't know which to perform. -- Ticket URL: core From trac@tools.ietf.org Fri Aug 20 06:38: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 35E2A3A6903 for ; Fri, 20 Aug 2010 06:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ll+-HvYD6vuD for ; Fri, 20 Aug 2010 06:38:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5B41D3A6A92 for ; Fri, 20 Aug 2010 06:38:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OmRoW-0006k1-KR; Fri, 20 Aug 2010 06:39:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 20 Aug 2010 13:39:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/21 Message-ID: <057.83b661287e9e4b9d6725189a7f45adbe@tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #21: Resource discovery changes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:38:47 -0000 #21: Resource discovery changes --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: critical | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The comments received in the Maastricht meeting, and lots of hallway discussions made it clear that we need to take a different approach to the resource discovery section in CoRE. This ticket tries to summarize the changes needed: 1. Make hosting a resource discovery end-point optional. Thus also removing the text "MUST be supported by a server for resource discovery" from Section 4.4. To make discovery work, if a host does enable resource discovery, it MUST/SHOULD? be on the defailt port. 2. Do not mention DNS-SD, trying to explain how these interact just seems to be confusing to people. 3. Do not mention multicast. 4. Discussions with many people in Maastricht suggested that the Link Format definition, MIME request and well-known URI definitions should be defined in a separate "CoRE Link Format" draft. Thus the text needed for Section 6 of coap-02 would be just a short paragraph pointing to the other I-D. This new I-D would do the following: - Define the re-use of the nottingham-http-link-header format as a payload. Instead of re-defining the ABNF, just CoRE-specific link- extensions would be defined. - Use of the rel= to be considered, and CoRE specific values to be registered. - /.well-known/core to be proposed as the URI, as /.well-known/r was considered too short to be registered. - Request a MIME type for the format. - Remove the HTTP and Naming sections. - No references to DNS-SD nor multicast. - Remove multiple ct= values for now as we have no Accept feature at this time. - Clarify if the leading / is included (it is). -- Ticket URL: core From trac@tools.ietf.org Fri Aug 20 06:46: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 B14113A687A for ; Fri, 20 Aug 2010 06:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 kDakh2pc+QnX for ; Fri, 20 Aug 2010 06:46:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DC99F3A6803 for ; Fri, 20 Aug 2010 06:46:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OmRw2-00059J-Ca; Fri, 20 Aug 2010 06:47:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 20 Aug 2010 13:47:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/22 Message-ID: <057.434f2ed34b028a8dfa52e661bea01d8f@tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #22: Security Section X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:46:32 -0000 #22: Security Section --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The security section needs to be written. Volunteers needed to help with this. * Definition of using CoAP with DTLS * Threat analysis and protocol limitations, e.g.: ** URIs risks ** Proxying and caching ** Possible attacks using TID, multicast, asyncronous responses etc. * Access control considerations? -- Ticket URL: core From trac@tools.ietf.org Fri Aug 20 06:48: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 597CF3A69AC for ; Fri, 20 Aug 2010 06:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 znvPd2ph4Dih for ; Fri, 20 Aug 2010 06:48:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 92DB93A6803 for ; Fri, 20 Aug 2010 06:48:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OmRxb-0007b9-Ft; Fri, 20 Aug 2010 06:48:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 20 Aug 2010 13:48:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/2#comment:3 Message-ID: <066.9bf722d9b29d3d756dedd1f2b0891818@tools.ietf.org> References: <057.f066386920aa68369202bab242483a0f@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <057.f066386920aa68369202bab242483a0f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #2: New Sub/Not design X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:48:14 -0000 #2: New Sub/Not design --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: enhancement | Status: closed Priority: critical | Milestone: coap-02 Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Ticket closed as WG consensus in Maastricht seemed to be that the subscription option should stay as a separate draft from the base coap spec as it is optional. -- Ticket URL: core From zach@sensinode.com Fri Aug 20 07:46:03 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 88E983A6808 for ; Fri, 20 Aug 2010 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 DUiLNPJksekW for ; Fri, 20 Aug 2010 07:46:02 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0921F3A68BC for ; Fri, 20 Aug 2010 07:46:01 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7KEkWN2025414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Aug 2010 17:46:33 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-46--934283262; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 20 Aug 2010 17:46:34 +0300 Message-Id: <622DD5C1-ADFD-4E0A-8B1D-1985A871E0DF@sensinode.com> To: core Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] CoAP tickets from Maastricht 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, 20 Aug 2010 14:46:03 -0000 --Apple-Mail-46--934283262 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I summarized the feedback from around Maastricht (Interop, CoRE WG, list = etc.) now as tickets. If I missed any issues that should be tickets = please let us know on the list. In addition to the tickets I have some = sets of general comments from people on coap-01, a few more reviews = would be helpful when putting together coap-02. In particular, feedback on Ticket #21 (Resource discovery split) and = help with Ticket #22 (Security section) are needed. The others one are = pretty straightforward, although note that #20 suggest removing the = Uri-Scheme option. I don't see any reason why coap-02 couldn't be submitted already towards = the end of next week, or worst case the week after.=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-46--934283262 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyMDE0NDYz NVowIwYJKoZIhvcNAQkEMRYEFEtPNM2ZowAHzQBjn4D/7HrhyTzfMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAD+yC2l0Ef91xTp7jpkpDL2N02mVtZXEP3wCg8ZHAUh9UqnhJVsop0+k XtiDn0h6A9fnetiTyWjzdrmO4M4Wls1J0gzEAlTIPnE7teCmMV2wqpCsE+95pSbPvtUVBETJP7M1 oi9vNH4bMj2vdx/UC6Nxlzqat8iZeVAVfv3etL6dxUAXL4VOhVEKhmXcEDjelJllpmbKfqmTtghM lz2IiC5zusTGJU16UVCiA00HghmTSxCclRd3zMExgGTzi9cKtoW+C8aFa6QtkO27sfT70Qk3SUFi 4zxChvX8azgZMpA+M8uC2wZTqIyUX8ULoTL8UImbRL06fT2FSimexfmbA6UAAAAAAAA= --Apple-Mail-46--934283262-- From edward.hill@ember.com Fri Aug 20 08:42: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 2E77B3A68C5 for ; Fri, 20 Aug 2010 08:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 64GU36z09XdB for ; Fri, 20 Aug 2010 08:42:33 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 3A8C73A67E6 for ; Fri, 20 Aug 2010 08:42:33 -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, 20 Aug 2010 11:43:05 -0400 Message-ID: In-Reply-To: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #20: Proxying clarification Thread-Index: ActAaFHmTlZGxQWDTt2UOYdFWlLOYAAFJ7cg References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> From: "Edward Hill" To: Subject: Re: [core] #20: Proxying clarification 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, 20 Aug 2010 15:42:34 -0000 > - The behaviour when a proxy receives a request with a Uri-Authority of > the proxy itself should be clarified. It is proposed that the proxy > returns a 400 Bad Request in this case. Coap-01 says "If the authority (host and port) is the same as the proxy end-point, then the request MUST be treated as a local request". Why change this to return 400 Bad Request? - Ed From hariharasudhan.tce@gmail.com Mon Aug 23 02:15: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 1738E3A682A for ; Mon, 23 Aug 2010 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 kGlaszfP8AW9 for ; Mon, 23 Aug 2010 02:15:26 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 026773A67E5 for ; Mon, 23 Aug 2010 02:15:25 -0700 (PDT) Received: by ewy22 with SMTP id 22so3345316ewy.31 for ; Mon, 23 Aug 2010 02:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=zLOUvAd8kfK5xN7w9IG2Un4siPz5qN30i+8PmnL2V0E=; b=ZNWqS3bM86vARb5MOgBJ01kp+9gvyOSUR/dPRqGP6s5uEB583cwJcTOFzDfdOoTQ2z jxyErb/plqJs1itN5/VnQodZx8hw98iZdvBs+3V/WMaEfEUpzFDVG1oJBdN8RbFaNbHP UktiIJifvXZ5BG2gAS9p4rZM3Qrng0oyrHo+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LCaSVQFX5R4Twix8RByBKhM6+11V/X5gS08XvOqx8OkdLvQa0Ts2g5+J2LoC2S/TPa Wttf183+pC+MV7T14DZj7dYfrYLCEwENjh9ZSLMldteuUeMtBr7F+FwnmYUVo2RzdnM+ /26aeI6mRZd9ewUhhMkyoMEO+sdrCoAA6f32U= MIME-Version: 1.0 Received: by 10.213.6.208 with SMTP id a16mr4333319eba.62.1282554958896; Mon, 23 Aug 2010 02:15:58 -0700 (PDT) Received: by 10.213.23.19 with HTTP; Mon, 23 Aug 2010 02:15:58 -0700 (PDT) Date: Mon, 23 Aug 2010 14:45:58 +0530 Message-ID: From: Hari Hara Sudhan R To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] information on option delta 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, 23 Aug 2010 09:15:27 -0000 Hi all, I'm not clear on how to handle negative values for option delta. If the header contains options in following order CoAP will compute option delta it in the following way. 1. uri_Path - type 9 (option delta is 9 since this is first option) 2. uri_Scheme - type 3 (option delta here is 3 - 9 = -6. In 2's complement form it would be 10) Is my understanding correct? While decoding the options. 1. first option delta is 9 so the option is calculated as 0+9 = 9 which is uri_Path 2. For second option delta is 10 so the option is 10+9 = 19. Now Im confused on how to use this value 19 to get the option uri_Scheme (type 3). The spec mentions about fencepost. How can i use that value for this situation? Thanks and Regards, Hari Hara Sudhan R From szymon.sasin@sensinode.com Mon Aug 23 02:26:52 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 D5E873A69A0 for ; Mon, 23 Aug 2010 02:26:52 -0700 (PDT) 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 LLbkYkvqMF1q for ; Mon, 23 Aug 2010 02:26:51 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6A94F3A68FA for ; Mon, 23 Aug 2010 02:26:51 -0700 (PDT) Received: from [192.168.0.86] (82-128-196-163-Torikatu-TR1.suomi.net [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7N9RJVG009064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 12:27:21 +0300 Message-ID: <4C723EF9.3080802@sensinode.com> Date: Mon, 23 Aug 2010 12:27:21 +0300 From: Szymon User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Hari Hara Sudhan R , core@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] information on option delta 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, 23 Aug 2010 09:26:53 -0000 Hi, You have to place options in ascending order before encoding, so there is no need for negative delta. Szymon > Hi all, > > > I'm not clear on how to handle negative values for option delta. > If the header contains options in following order CoAP will compute option delta > it in the following way. > > 1. uri_Path - type 9 (option delta is 9 since this is first option) > 2. uri_Scheme - type 3 (option delta here is 3 - 9 = -6. In 2's > complement form it would be 10) > > Is my understanding correct? > > While decoding the options. > > 1. first option delta is 9 so the option is calculated as 0+9 = 9 > which is uri_Path > 2. For second option delta is 10 so the option is 10+9 = 19. Now Im > confused on how to use this value > 19 to get the option uri_Scheme (type 3). > > The spec mentions about fencepost. How can i use that value for this situation? > > Thanks and Regards, > Hari Hara Sudhan R > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From mab@comnets.uni-bremen.de Mon Aug 23 02:27:23 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 417053A699A for ; Mon, 23 Aug 2010 02:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 KauV-+rb5RmY for ; Mon, 23 Aug 2010 02:27:22 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 0340C3A6835 for ; Mon, 23 Aug 2010 02:27:22 -0700 (PDT) Received: from shelbyville.comnets.uni-bremen.de (unknown [134.102.155.175]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id 2D1F424EE3B for ; Mon, 23 Aug 2010 11:27:55 +0200 (CEST) From: Markus Becker Organization: Comnets, University Bremen To: core@ietf.org Date: Mon, 23 Aug 2010 11:27:53 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201008231127.53958.mab@comnets.uni-bremen.de> Subject: Re: [core] information on option delta 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, 23 Aug 2010 09:27:23 -0000 > Hi all, > > > I'm not clear on how to handle negative values for option delta. > If the header contains options in following order CoAP will compute option > delta it in the following way. > > 1. uri_Path - type 9 (option delta is 9 since this is first option) > 2. uri_Scheme - type 3 (option delta here is 3 - 9 = -6. In 2's > complement form it would be 10) As far as I understand the option delta computation: Your options need to be ordered in increasing order, so that you do not have negative values. -> first uri_scheme (3), then uri_path (9) -> delta 6 > Is my understanding correct? > > While decoding the options. > > 1. first option delta is 9 so the option is calculated as 0+9 = 9 > which is uri_Path > 2. For second option delta is 10 so the option is 10+9 = 19. Now Im > confused on how to use this value > 19 to get the option uri_Scheme (type 3). > > The spec mentions about fencepost. How can i use that value for this > situation? I think the fencepost is for jumping to higher values, if you do not have intermediate values. > Thanks and Regards, > Hari Hara Sudhan R > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | Mobile Research Center | TZI - Center for Computing Technologies | University Bremen | Germany ------------------------------------------------ | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: mab@comnets.uni-bremen.de ------------------------------------------------ From zach@sensinode.com Mon Aug 23 03:21: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 EB4753A68FA for ; Mon, 23 Aug 2010 03:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_05=-1.11, 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 ZyB4zehHxdvq for ; Mon, 23 Aug 2010 03:21:26 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0EB7F3A68B9 for ; Mon, 23 Aug 2010 03:21:25 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7NALpQ6020437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Aug 2010 13:21:51 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-110--690964799; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 23 Aug 2010 13:21:53 +0300 Message-Id: References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> To: Edward Hill X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] #20: Proxying clarification 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, 23 Aug 2010 10:21:29 -0000 --Apple-Mail-110--690964799 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ed, On Aug 20, 2010, at 6:43 PM, Edward Hill wrote: >> - The behaviour when a proxy receives a request with a Uri-Authority > of >> the proxy itself should be clarified. It is proposed that the proxy >> returns a 400 Bad Request in this case. >=20 > Coap-01 says "If the authority (host and port) is the same as the = proxy > end-point, then the request MUST be treated as a local request". Why > change this to return 400 Bad Request? Right, this was the assumption so far. However, at interop it was = pointed out (by Klaus if I remember right) that this behavior doesn't = make much sense. A proxy is usually realized as a dedicated end-point, = so treating this as a local request would really just mean it returns a = 404. In this case though the Uri-Authority option was probably included = by mistake in the request, so returning a 400 would be a clearer error. Does anyone else see the need for changing that to a 400? If not, then I = am happy to leave the behavior as it is in coap-01. Zach >=20 > - Ed > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-110--690964799 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyMzEwMjE1 M1owIwYJKoZIhvcNAQkEMRYEFF1dLj2uICr/DSrS1mUEIsiK61IWMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADbm+kp+f4uLFJF2YqvSRzOkX9KYZt7FU0kGQTuUaoxRMd/TyZBhhF8k yv5LV6de7l244ZWE3OFMXEsrJKm9crNy3JMsWOxgJux/v2xT1BWVYaQZL8KBFClrWet26aTOI1vE q6jOdRmSkiJ0hKwNDwoyPSnoA+m1+UITK6fB+GZKxmOHE+cuibfiWlDzX7m5VauvEThbeOAX3ej7 7pqVxK3R16eKh3MCo5yylILCkcEIFn/GRMD+fvoVly7ZPCWsQeDLXkvyWVTkHl5pFvC+bZC/ApwG hUuMDiOLtx3dDd9tiLW/ZfJ2hpw6/qsOwIxxe3OO85r5tvrvZhwZboAGE8wAAAAAAAA= --Apple-Mail-110--690964799-- From cabo@tzi.org Mon Aug 23 03:31:43 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 35CFF3A69CC for ; Mon, 23 Aug 2010 03:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 TeDquRgTVGyb for ; Mon, 23 Aug 2010 03:31:42 -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 E55643A6809 for ; Mon, 23 Aug 2010 03:31:41 -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 o7NAVwgR001752; Mon, 23 Aug 2010 12:32:03 +0200 (CEST) Received: from [192.168.217.101] (p5489CF70.dip.t-dialin.net [84.137.207.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7C66F68E1; Mon, 23 Aug 2010 12:31:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 23 Aug 2010 12:31:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] #20: Proxying clarification 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, 23 Aug 2010 10:31:43 -0000 On Aug 23, 2010, at 12:21, Zach Shelby wrote: > Does anyone else see the need for changing that I think we need to be clear whether a request to a server should include = the authority or not. Not all servers (if very constrained) may be able to find out whether an = authority given is actually themselves or not. Instead of getting = simple hosts into the habit of accepting any authority, I think it would = be better to leave the onus to connect to the right place to the client. (The underlying question is how important the virtual server concept is. = If we expect virtual servers to be an important feature, we'll need to = have the authority in there always, just as HTTP always has a Host: = header. If we ask clients to leave out the authority, we can't have = virtual servers. We can't have the client make a decision whether the = server will be using virtual servers. The above paragraph assumes not = sending the authority is more important than having the virtual server = capability.) Gruesse, Carsten From hariharasudhan.tce@gmail.com Mon Aug 23 03:36: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 ADE9D3A69D3 for ; Mon, 23 Aug 2010 03:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 FvFzG3BzfsrL for ; Mon, 23 Aug 2010 03:36:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4C8263A68FA for ; Mon, 23 Aug 2010 03:36:12 -0700 (PDT) Received: by bwz9 with SMTP id 9so5386606bwz.31 for ; Mon, 23 Aug 2010 03:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2+Dm+liJHpstdRmDoPa/pcYrpYmlaZ/iz0BqakOHxLs=; b=UzAQ9ckKuJYlCT0E+ueizOLkFj/OXpuw19XcZAIfzoKZPmrd9YYiyPAgKfn4flNSWI Su88JrTzspe8Hn9pw1HpfgrGLbIs1GZ18mQO1jxMH41ap9uwwKG2fu6veaK2jcCX9CQq BPAU1R2f/KtjLr5rWkEJ0bBZrsDijiE81NkvY= 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; b=rHvARxEdhxO+DmnQcO0PTKS01eLkjT4phCgqgr1ztUEQRn31W2DMvAOHk8EiTUkQ06 peoWBVYfa3YEPYKkJIItMNj77ITrdOxPUocSp+x3S2ho1wAPA4sGWhkhIRnWTbw+bZ9F ekUXWK2dxRAjKNHB/GrNPDGLoNEM/z2Baanxg= MIME-Version: 1.0 Received: by 10.213.29.144 with SMTP id q16mr3119154ebc.75.1282559805286; Mon, 23 Aug 2010 03:36:45 -0700 (PDT) Received: by 10.213.23.19 with HTTP; Mon, 23 Aug 2010 03:36:45 -0700 (PDT) In-Reply-To: <201008231127.53958.mab@comnets.uni-bremen.de> References: <201008231127.53958.mab@comnets.uni-bremen.de> Date: Mon, 23 Aug 2010 16:06:45 +0530 Message-ID: From: Hari Hara Sudhan R To: Markus Becker Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] information on option delta 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, 23 Aug 2010 10:36:14 -0000 Hi Marcus, >I think the fencepost is for jumping to higher values, if you do not have >intermediate values. Thanks for your answer. What is meant by an intermediate value here?. I could not find any reference in specs. If it was encoded in a sorted way how can "prev_option + delta" go beyond 9?. Thanks and Regards Hari Hara Sudhan R On Mon, Aug 23, 2010 at 2:57 PM, Markus Becker wrote: >> Hi all, >> >> >> I'm not clear on how to handle negative values for option delta. >> If the header contains options in following order CoAP will compute option >> delta it in the following way. >> >> 1. uri_Path - type 9 (option delta is 9 since this is first option) >> 2. uri_Scheme - type 3 (option delta here is 3 - 9 = -6. In 2's >> complement form it would be 10) > > As far as I understand the option delta computation: > > Your options need to be ordered in increasing order, so that you do not have > negative values. > > -> first uri_scheme (3), then uri_path (9) -> delta 6 > >> Is my understanding correct? >> >> While decoding the options. >> >> 1. first option delta is 9 so the option is calculated as 0+9 = 9 >> which is uri_Path >> 2. For second option delta is 10 so the option is 10+9 = 19. Now Im >> confused on how to use this value >> 19 to get the option uri_Scheme (type 3). >> >> The spec mentions about fencepost. How can i use that value for this >> situation? > > I think the fencepost is for jumping to higher values, if you do not have > intermediate values. > >> Thanks and Regards, >> Hari Hara Sudhan R >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > ------------------------------------------------ > | Dipl.-Ing. Markus Becker > | Communication Networks > | Mobile Research Center > | TZI - Center for Computing Technologies > | University Bremen > | Germany > ------------------------------------------------ > | web: http://www.comnets.uni-bremen.de/~mab/ > | mailto: mab@comnets.uni-bremen.de > ------------------------------------------------ > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From cabo@tzi.org Mon Aug 23 03:49: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 79E783A69D5 for ; Mon, 23 Aug 2010 03:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.142 X-Spam-Level: X-Spam-Status: No, score=-106.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 5JsH2Rl+SUor for ; Mon, 23 Aug 2010 03:49:36 -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 132623A67DB for ; Mon, 23 Aug 2010 03:49: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 o7NAntnJ008987; Mon, 23 Aug 2010 12:50:00 +0200 (CEST) Received: from [192.168.217.101] (p5489CF70.dip.t-dialin.net [84.137.207.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C80B56908; Mon, 23 Aug 2010 12:49:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 23 Aug 2010 12:49:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201008231127.53958.mab@comnets.uni-bremen.de> To: Hari Hara Sudhan R X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] information on option delta 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, 23 Aug 2010 10:49:37 -0000 >> I think the fencepost is for jumping to higher values, if you do not = have >> intermediate values. >=20 > Thanks for your answer. >=20 > What is meant by an intermediate value here?. I could not find any > reference in specs. > If it was encoded in a sorted way how can "prev_option + delta" go = beyond 9?. The assumption here seems to be that we will allocate more and more = options, with higher and higher option numbers, and at some point = someone may want to send just option 0 and option 27. In this case, the = delta would be 27 and cannot be expressed in 4 bits. So you need to add = a NOP option, in this case option 14. The deltas are then 0, 14 and 13. If the sender had wanted to send option 0, 12, and 27, no such = "fencepost option" would be needed (the deltas would be 0, 12, 15). Note that this only becomes relevant for a sender that indeed wants to = send option combinations with such a large gap in the option numbers. = As you note, with the options we have defined so far, that cannot happen = yet, but it is good to know what to do when option 16 or higher finally = does get allocated. (Also note that any properly implemented receiver already has the code = to ignore an option 14.) Gruesse, Carsten From pab@peoplepowerco.com Mon Aug 23 06:55: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 849663A6A56 for ; Mon, 23 Aug 2010 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, 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 TV8pJYdEBZPA for ; Mon, 23 Aug 2010 06:55:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 930F93A6A4C for ; Mon, 23 Aug 2010 06:55:35 -0700 (PDT) Received: by vws10 with SMTP id 10so5663672vws.31 for ; Mon, 23 Aug 2010 06:56:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.60.15 with SMTP id n15mr3203027vch.158.1282571768890; Mon, 23 Aug 2010 06:56:08 -0700 (PDT) Received: by 10.220.67.86 with HTTP; Mon, 23 Aug 2010 06:56:08 -0700 (PDT) In-Reply-To: References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> Date: Mon, 23 Aug 2010 08:56:08 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] #20: Proxying clarification 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, 23 Aug 2010 13:55:36 -0000 How does a client determine whether it must include the authority in a request to a server (i.e., server is a proxy), or must not include it (i.e., server is the origin server)? Peter On Mon, Aug 23, 2010 at 5:31 AM, Carsten Bormann wrote: > On Aug 23, 2010, at 12:21, Zach Shelby wrote: > >> Does anyone else see the need for changing that > > I think we need to be clear whether a request to a server should include = the authority or not. > Not all servers (if very constrained) may be able to find out whether an = authority given is actually themselves or not. =A0Instead of getting simple= hosts into the habit of accepting any authority, I think it would be bette= r to leave the onus to connect to the right place to the client. > > (The underlying question is how important the virtual server concept is. = =A0If we expect virtual servers to be an important feature, we'll need to h= ave the authority in there always, just as HTTP always has a Host: header. = =A0If we ask clients to leave out the authority, we can't have virtual serv= ers. =A0We can't have the client make a decision whether the server will be= using virtual servers. =A0The above paragraph assumes not sending the auth= ority is more important than having the virtual server capability.) > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From cabo@tzi.org Mon Aug 23 07:33: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 0424D3A69DD for ; Mon, 23 Aug 2010 07:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.11 X-Spam-Level: X-Spam-Status: No, score=-106.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 CWZzu1C9g0FR for ; Mon, 23 Aug 2010 07:33:48 -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 9D8943A69F8 for ; Mon, 23 Aug 2010 07:33:46 -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 o7NEY6qG023578; Mon, 23 Aug 2010 16:34:11 +0200 (CEST) Received: from [192.168.217.101] (p5489CF70.dip.t-dialin.net [84.137.207.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2C6D36AEA; Mon, 23 Aug 2010 16:34:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 23 Aug 2010 16:34:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CF13564-09BE-4EAA-AC7D-049178AEFCBF@tzi.org> References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] #20: Proxying clarification 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, 23 Aug 2010 14:33:51 -0000 On Aug 23, 2010, at 15:56, Peter Bigot wrote: > How does a client determine whether it must include the authority in a > request to a server (i.e., server is a proxy), or must not include it > (i.e., server is the origin server)? If the client is configured to use a server as a proxy, it sends a = request with an option giving the authority of the origin server to the = proxy. If the client is not so configured, it sends a request without the = authority option to the server. (In other words, as with HTTP, the decision to use a proxy is orthogonal = to the URI.) (All this is assuming that we stick with the model I was proposing, = which does not allow virtual servers. I think we need to decide this at = some point.) Gruesse, Carsten From pab@peoplepowerco.com Mon Aug 23 08:18:23 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 7F6533A68E0 for ; Mon, 23 Aug 2010 08:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, 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 i77xP1d7Pa-w for ; Mon, 23 Aug 2010 08:18:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4EF0C3A68B8 for ; Mon, 23 Aug 2010 08:18:22 -0700 (PDT) Received: by gyg8 with SMTP id 8so2527884gyg.31 for ; Mon, 23 Aug 2010 08:18:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.15.6 with SMTP id i6mr3486996eba.72.1282576734781; Mon, 23 Aug 2010 08:18:54 -0700 (PDT) Received: by 10.220.67.86 with HTTP; Mon, 23 Aug 2010 08:18:54 -0700 (PDT) In-Reply-To: <0CF13564-09BE-4EAA-AC7D-049178AEFCBF@tzi.org> References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> <0CF13564-09BE-4EAA-AC7D-049178AEFCBF@tzi.org> Date: Mon, 23 Aug 2010 10:18:54 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] #20: Proxying clarification 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, 23 Aug 2010 15:18:23 -0000 OK. I wasn't thinking of proxy as a client-configuration choice as in the browser sense, but in a more transparent caching sense where some servers can't always be directly reached by the client so pass through an intermediary that deals with things like sleeping nodes. For example, I'd planned to run a CoAP server on my gateway, which would serve as a proxy to allow wired clients to connect to nodes in the wireless network. I guess that does require a virtual-server model. Absence of the URI authority in requests to the gateway will be inconvenient, since I'll have to map the actual destination host somewhere in the URI path, strip it out when the request is forwarded, and put it back when sending the response to the client. So the same resource is accessed by different URIs depending on whether it's a direct connect or has to pass through an intermediary, and I can't hide that at the service interface level by doing DNS tricks. This might make an HTTP bridge more complicated. Peter On Mon, Aug 23, 2010 at 9:34 AM, Carsten Bormann wrote: > On Aug 23, 2010, at 15:56, Peter Bigot wrote: > >> How does a client determine whether it must include the authority in a >> request to a server (i.e., server is a proxy), or must not include it >> (i.e., server is the origin server)? > > If the client is configured to use a server as a proxy, it sends a reques= t with an option giving the authority of the origin server to the proxy. > If the client is not so configured, it sends a request without the author= ity option to the server. > > (In other words, as with HTTP, the decision to use a proxy is orthogonal = to the URI.) > > (All this is assuming that we stick with the model I was proposing, which= does not allow virtual servers. =A0I think we need to decide this at some = point.) > > Gruesse, Carsten > > From zach@sensinode.com Tue Aug 24 05:03: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 272023A6936 for ; Tue, 24 Aug 2010 05:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 23OajjRH0VAv for ; Tue, 24 Aug 2010 05:03:12 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5545D3A6824 for ; Tue, 24 Aug 2010 05:03:11 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7OC3fSx029680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Aug 2010 15:03:41 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-230--598454873; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <0CF13564-09BE-4EAA-AC7D-049178AEFCBF@tzi.org> Date: Tue, 24 Aug 2010 15:03:42 +0300 Message-Id: <4A767E45-4B0D-4056-A08E-19049E22C7E4@sensinode.com> References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> <0CF13564-09BE-4EAA-AC7D-049178AEFCBF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Cc: core@ietf.org Subject: Re: [core] #20: Proxying clarification 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, 24 Aug 2010 12:03:14 -0000 --Apple-Mail-230--598454873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 23, 2010, at 5:34 PM, Carsten Bormann wrote: > On Aug 23, 2010, at 15:56, Peter Bigot wrote: >=20 >> How does a client determine whether it must include the authority in = a >> request to a server (i.e., server is a proxy), or must not include it >> (i.e., server is the origin server)? >=20 > If the client is configured to use a server as a proxy, it sends a = request with an option giving the authority of the origin server to the = proxy. > If the client is not so configured, it sends a request without the = authority option to the server. >=20 > (In other words, as with HTTP, the decision to use a proxy is = orthogonal to the URI.) This is how I have assumed this works. We have also this model = implemented and tested, no problems so far. Note that Brian Franck has also given some thought to transparent = proxying, which is what Peter had in mind. For now we decided not to = discuss that in the draft. In practice though, transparent proxying = should not require any special consideration in the protocol, nor does = it need the Uri-Authority, as it is done using packet capture = techniques. Do we need to mention this in the draft? > (All this is assuming that we stick with the model I was proposing, = which does not allow virtual servers. I think we need to decide this at = some point.) I would prefer not to support virtual servers.=20 Zach >=20 > Gruesse, Carsten >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-230--598454873 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNDEyMDM0 M1owIwYJKoZIhvcNAQkEMRYEFNfrKhx+ZxxR7YlMGVg8JvxWfaRqMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADxMQ0Uv2WgOWOEauk/xu3C6UaJklG/YSKQ2csV7ODYjC1N5KN8PQtgf w8gn3X7rF0S7ReyjjIm5Sg9+12WWKx79KvVgCdnfgGod8iRUmRBzhkkbuuosoRNBZFtnvbETARyo aAIz428TmdlzgEXzUrNtWWbIka6MlMR8lRyzQUkmzOmvuOycXvj8UWG472PkKrx5yPvB4AKfgdHw s2HjJ2WxTQLy3rdxLO4U0LysBPT/jYj3jXtm3QSqSarWzPPxi2KifhgdU9pBxA9hPezUnLeYsNFJ 4Niy1ejM8D4q8TX63spwsm1qS0gkQVokqk06UPnoDfG5x8lOj1cuHvo3G4QAAAAAAAA= --Apple-Mail-230--598454873-- From pab@peoplepowerco.com Tue Aug 24 07:17:08 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 5B5203A6A47 for ; Tue, 24 Aug 2010 07:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, 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 0a5aIt8oLTBe for ; Tue, 24 Aug 2010 07:17:07 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 7561A3A6A04 for ; Tue, 24 Aug 2010 07:17:07 -0700 (PDT) Received: by vws10 with SMTP id 10so558864vws.31 for ; Tue, 24 Aug 2010 07:17:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.140 with SMTP id t12mr4216256vch.54.1282659460212; Tue, 24 Aug 2010 07:17:40 -0700 (PDT) Received: by 10.220.172.65 with HTTP; Tue, 24 Aug 2010 07:17:40 -0700 (PDT) In-Reply-To: <4A767E45-4B0D-4056-A08E-19049E22C7E4@sensinode.com> References: <057.a66ba7c3b9381ba45cb0037c8effd015@tools.ietf.org> <0CF13564-09BE-4EAA-AC7D-049178AEFCBF@tzi.org> <4A767E45-4B0D-4056-A08E-19049E22C7E4@sensinode.com> Date: Tue, 24 Aug 2010 09:17:40 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] #20: Proxying clarification 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, 24 Aug 2010 14:17:08 -0000 Could we have a ticket to discuss this separately? Peter >> (All this is assuming that we stick with the model I was proposing, whic= h does not allow virtual servers. =A0I think we need to decide this at some= point.) > > I would prefer not to support virtual servers. > > Zach > From trac@tools.ietf.org Tue Aug 24 08:06: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 D57C03A6B57 for ; Tue, 24 Aug 2010 08:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 rWaCJ5IfKG-X for ; Tue, 24 Aug 2010 08:06:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EDD5A3A6B56 for ; Tue, 24 Aug 2010 08:06:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Onv62-000831-Ca; Tue, 24 Aug 2010 08:07:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 24 Aug 2010 15:07:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/23 Message-ID: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #23: Virtual server capability? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 15:06:59 -0000 #23: Virtual server capability? --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: minor | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Carsten pointed out that we need to decide whether to support the Uri- Authority option in non-proxy requests (and thus the virtual server concept). From the original mail: I think we need to be clear whether a request to a server should include the authority or not. Not all servers (if very constrained) may be able to find out whether an authority given is actually themselves or not. Instead of getting simple hosts into the habit of accepting any authority, I think it would be better to leave the onus to connect to the right place to the client. (The underlying question is how important the virtual server concept is. If we expect virtual servers to be an important feature, we'll need to have the authority in there always, just as HTTP always has a Host: header. If we ask clients to leave out the authority, we can't have virtual servers. We can't have the client make a decision whether the server will be using virtual servers. The above paragraph assumes not sending the authority is more important than having the virtual server capability.) -- Ticket URL: core From trac@tools.ietf.org Tue Aug 24 08:13:31 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 21A103A6A61 for ; Tue, 24 Aug 2010 08:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Cg+yplo2THq8 for ; Tue, 24 Aug 2010 08:13:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E31763A69F2 for ; Tue, 24 Aug 2010 08:13:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OnvCL-0000ye-5B; Tue, 24 Aug 2010 08:14:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 24 Aug 2010 15:14:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/24 Message-ID: <057.dc61e7b30438c8091fedd8b14607cd68@tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #24: Clarification about repeated options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 15:13:31 -0000 #24: Clarification about repeated options --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: minor | Milestone: coap-02 Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- coap-01 did not specify whether an option can appear multiple times in a CoAP header. It was pointed out in Maastricht that coap-02 should clearly either allow or forbid repeated options. This ticket is to decide whether we should allow (and have any real use for) repeated options in coap-02. -- Ticket URL: core From pab@peoplepowerco.com Tue Aug 24 10:09: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 1E57D3A6B7B for ; Tue, 24 Aug 2010 10:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, 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 U58JQtCw563e for ; Tue, 24 Aug 2010 10:09:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id C8BB23A6A5C for ; Tue, 24 Aug 2010 10:08:54 -0700 (PDT) Received: by vws10 with SMTP id 10so705410vws.31 for ; Tue, 24 Aug 2010 10:09:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.59.5 with SMTP id j5mr4454102vch.90.1282669762962; Tue, 24 Aug 2010 10:09:22 -0700 (PDT) Received: by 10.220.172.65 with HTTP; Tue, 24 Aug 2010 10:09:21 -0700 (PDT) In-Reply-To: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> Date: Tue, 24 Aug 2010 12:09:21 -0500 Message-ID: From: Peter Bigot To: core issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] #23: Virtual server capability? 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, 24 Aug 2010 17:09:02 -0000 Having a UriAuthority in a request can be a problem if the receiving server has limited functionality and can't, for example, do a DNS lookup to verify a host name refers to it. I think this can be worked around by simply comparing the authority against a fixed set of authorities known by the server to be acceptable. Providing that list is a configuration issue outside the scope of the protocol; at a minimum it can be expected that the server can always recognize its own IP address as a legal authority. Eliminating the UriAuthority from the REST request sent to a server would repeat the same mistake made in HTTP/1.0. That mistake had to be fixed in HTTP/1.1 to allow HTTP to participate in full REST transactions where arbitrary intermediate nodes unknown to the client could provide value-added services without affecting how the client accessed the resource. I'd intended to use CoAP as an end-to-end protocol for a common case of a full-function client collecting data from multiple reduced-function servers, possibly in different administrative domains with different intermediaries. I disagree with the statement in the discussion of #20 that the UriAuthority is unnecessary to support transparent proxying. The backbone of the success of REST on the web is the ability to use virtual servers and DNS tricks to maintain a persistent URI for a resource while evolving the infrastructure that provides that resource. The uniform interface between components which is the central feature of REST requires that the complete URI be present at each step. If CoAP can't be used end-to-end, then full-function clients like an energy services platform will have to use HTTP to access the devices, to enable use of these unknown intermediate services, such as gateways to clouds of wireless devices. CoAP becomes useful only as the last hop between a full-function gateway and the reduced-function devices. Adequate for simple situations, but seriously limited in its potential when compared to REST. Peter On Tue, Aug 24, 2010 at 10:07 AM, core issue tracker wrote: > #23: Virtual server capability? > --------------------------------+----------------------------------------= --- > =A0Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Owner: = =A0zach@=85 > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0coa= p-02 > Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: > =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keywords: > --------------------------------+----------------------------------------= --- > =A0Carsten pointed out that we need to decide whether to support the Uri- > =A0Authority option in non-proxy requests (and thus the virtual server > =A0concept). From the original mail: > > =A0I think we need to be clear whether a request to a server should inclu= de > =A0the authority or not. > =A0Not all servers (if very constrained) may be able to find out whether = an > =A0authority given is actually themselves or not. =A0Instead of getting s= imple > =A0hosts into the habit of accepting any authority, I think it would be > =A0better to leave the onus to connect to the right place to the client. > > =A0(The underlying question is how important the virtual server concept i= s. > =A0If we expect virtual servers to be an important feature, we'll need to > =A0have the authority in there always, just as HTTP always has a Host: > =A0header. =A0If we ask clients to leave out the authority, we can't have > =A0virtual servers. =A0We can't have the client make a decision whether t= he > =A0server will be using virtual servers. =A0The above paragraph assumes n= ot > =A0sending the authority is more important than having the virtual server > =A0capability.) > > -- > Ticket URL: > core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From klaus.hartke@googlemail.com Tue Aug 24 12:02: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 0346C3A69E6 for ; Tue, 24 Aug 2010 12:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 En5IR6llvELV for ; Tue, 24 Aug 2010 12:02:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 537DB3A6924 for ; Tue, 24 Aug 2010 12:02:13 -0700 (PDT) Received: by bwz9 with SMTP id 9so7035976bwz.31 for ; Tue, 24 Aug 2010 12:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=512qyv+VYaAtGJqXjtt0C7H++EyZMgVPonlgjm65vSw=; b=O16hGduueGGk++4K1q8wvtTPw9BdM40pdlKxjbnluJcV35MQMyIBLj0ZqmQ6JBU6Hd YQ1RIyunitiTkmHhXY2/00Ax/jNnh4S9XpOxiSW8tnwXJK1GktwKrijbWNplOcAxCjUo /NBAdXA7YNpVRTmbLiN8Mz2ZnTENcQ+5wa4a8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=R4Wl5NINT7cmFydFl3MkYrlhZJtaWAH/OyMk+QKdEFVpXCyyadHdM5l6n2gIx1TrhS C2O2OhXyGxnBeET7ZyrOLXsaFbKQ51Fr8NFswdDYNl4WLlbGGussJp5ZRjRfS7eDPF/T 6hY7UuJyhYDsv0JweCgWcy5YvGy1tnjjOEKMU= MIME-Version: 1.0 Received: by 10.204.127.65 with SMTP id f1mr5148537bks.55.1282676565639; Tue, 24 Aug 2010 12:02:45 -0700 (PDT) Sender: klaus.hartke@googlemail.com Received: by 10.204.126.77 with HTTP; Tue, 24 Aug 2010 12:02:45 -0700 (PDT) In-Reply-To: <057.dc61e7b30438c8091fedd8b14607cd68@tools.ietf.org> References: <057.dc61e7b30438c8091fedd8b14607cd68@tools.ietf.org> Date: Tue, 24 Aug 2010 21:02:45 +0200 X-Google-Sender-Auth: 83rU_e1gQv4EUM9__Lw-q5fmK_Q Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] #24: Clarification about repeated options 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, 24 Aug 2010 19:02:17 -0000 On 24 August 2010 17:14, core issue tracker wrote: > =A0coap-01 did not specify whether an option can appear multiple times in= a > =A0CoAP header. It was pointed out in Maastricht that coap-02 should clea= rly > =A0either allow or forbid repeated options. This ticket is to decide whet= her > =A0we should allow (and have any real use for) repeated options in coap-0= 2. The only real use for repeated options so far is the inclusion of multiple Etags in a GET request. IMO that's a good thing to have. If we forbid repeated options, we need a format to store multiple byte sequences in a single option, such as 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-...-+-+-+ | x | y | ...x bytes... | ...y bytes... | ... etc. ... +-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-...-+-+-+ Klaus From cabo@tzi.org Tue Aug 24 13:56: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 8D0353A695E for ; Tue, 24 Aug 2010 13:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 nC3Zznr-D0kK for ; Tue, 24 Aug 2010 13:56: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 02BD03A690F for ; Tue, 24 Aug 2010 13:56:04 -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 o7OKuKrF026427 for ; Tue, 24 Aug 2010 22:56:30 +0200 (CEST) Received: from [192.168.217.101] (p5489EE6A.dip.t-dialin.net [84.137.238.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CD9F4612B; Tue, 24 Aug 2010 22:56:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 24 Aug 2010 22:56:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <512774B1-1ABD-4585-BAD8-40C5D75D78CE@tzi.org> References: <057.dc61e7b30438c8091fedd8b14607cd68@tools.ietf.org> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] #24: Clarification about repeated options 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, 24 Aug 2010 20:56:06 -0000 We currently have just one example where allowing repeatable options is = beneficial as it removes the need to define an array representation for = the multivalued option value. Even if we didn't, array-valued options are likely to come up later. = Saying they don't, appears to be a form of proof by lack of imagination. As a general observation, nodes that do not implement such a repeatable = option can ignore all option instances and thus do not need to implement = the concept of repeatable options at all. Nodes that do implement the repeatable option benefit from the = simplified encoding. The cognitive dissonance mainly seems to come from attempts at providing = general option handling code that processes options independent of their = semantics. My take is therefore: Do not explicitly disallow repeatable options, as there is no benefit in = doing so. Use them where and when they do provide a benefit. Unless a specific option is specifically identified as repeatable (and = the semantics of the resulting array of option values is defined), an = option defined for CoAP is not repeatable, and repeating such an option = in a request should lead to a 400 error. Gruesse, Carsten From cabo@tzi.org Tue Aug 24 16: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 B4F4A3A6A72 for ; Tue, 24 Aug 2010 16:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.128 X-Spam-Level: X-Spam-Status: No, score=-106.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 HCqeJRRExekc for ; Tue, 24 Aug 2010 16: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 312273A6A2E for ; Tue, 24 Aug 2010 16:31:04 -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 o7ONVKOM005540 for ; Wed, 25 Aug 2010 01:31:30 +0200 (CEST) Received: from [192.168.217.101] (p5489EE6A.dip.t-dialin.net [84.137.238.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3EF3A6149; Wed, 25 Aug 2010 01:31:20 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Aug 2010 01:31:18 +0200 To: core Message-Id: <6E88BE0F-E4E1-43F2-B702-F26D5365C6A3@tzi.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [core] Two updated and one extracted satellite draft on CoAP 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, 24 Aug 2010 23:31:06 -0000 Klaus and I have been busy preparing tomorrow's (Wednesday's) Interim. Please find: http://tools.ietf.org/html/draft-bormann-coap-misc-06 http://tools.ietf.org/html/draft-hartke-coap-observe-02 http://tools.ietf.org/html/draft-bormann-core-coap-block-00 The block option is mainly extracted from coap-misc, with some = additional explanations. The subscription-lifetime option (coap-observe) also has some additional = explanations, and much less background information that may actually not = be necessary in this document. coap-misc is slightly updated, minus block, plus user-defined, and with = reference to coap-01. For convenient diffing: http://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-coap-misc-06.txt http://tools.ietf.org/rfcdiff?url2=3Ddraft-hartke-coap-observe-02.txt Gruesse, Carsten From zach@sensinode.com Wed Aug 25 03:36: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 04B823A6ACA for ; Wed, 25 Aug 2010 03:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 ZYfxzfdz22j3 for ; Wed, 25 Aug 2010 03:36:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 60DAE3A6AC9 for ; Wed, 25 Aug 2010 03:36:25 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7PAasPv025494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Aug 2010 13:36:54 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-312--517261181; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <512774B1-1ABD-4585-BAD8-40C5D75D78CE@tzi.org> Date: Wed, 25 Aug 2010 13:36:56 +0300 Message-Id: References: <057.dc61e7b30438c8091fedd8b14607cd68@tools.ietf.org> <512774B1-1ABD-4585-BAD8-40C5D75D78CE@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] #24: Clarification about repeated options 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, 25 Aug 2010 10:36:33 -0000 --Apple-Mail-312--517261181 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 24, 2010, at 11:56 PM, Carsten Bormann wrote: > My take is therefore: > Do not explicitly disallow repeatable options, as there is no benefit = in doing so. > Use them where and when they do provide a benefit. > Unless a specific option is specifically identified as repeatable (and = the semantics of the resulting array of option values is defined), an = option defined for CoAP is not repeatable, and repeating such an option = in a request should lead to a 400 error. Works for me - would have no problem including text like this in = coap-02.=20 Zach >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-312--517261181 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNTEwMzY1 N1owIwYJKoZIhvcNAQkEMRYEFKqkrp1Y3mtIVO6zhZ14ZQfz9is6MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAClr9sYrLmELuxsAsjwYBvaMVsznUcRUh378p90ytLYibI6A0zIQn2C1 92pL1pUIQCvLVeVFzje8GxCiaGgvOiGEmlMBW1ZiU99ZPlBebIRe82vhriqh9ealtlUsa5P4da21 incB80r0s1XXoRpCQ0c4Zf73G5Lc2BjfSChu0gnVmvpBvNptAucS8krpOaiGi679man1jSev2cAI HK06Kt3a4CikTloLC2yhRtadQb9D2ZMEtvA5GPWWUYg8cxMt0LZPpZXBdJnTXTdD0U6JOUxvhO5M RYJ0Z0qSpMddO8av2lTKgBKANV2HC2l/NW1QhNt5xznfPKCryMpD/GznsMsAAAAAAAA= --Apple-Mail-312--517261181-- From zach@sensinode.com Wed Aug 25 04:59:18 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 D40263A682F for ; Wed, 25 Aug 2010 04:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 Ei1yUlcau9Ek for ; Wed, 25 Aug 2010 04:59:17 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E524D3A67DB for ; Wed, 25 Aug 2010 04:59:16 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7PBxjE7019571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Aug 2010 14:59:45 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-315--512290172; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> Date: Wed, 25 Aug 2010 14:59:47 +0300 Message-Id: <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> To: core X-Mailer: Apple Mail (2.1081) Cc: core issue tracker Subject: Re: [core] #23: Virtual server capability? 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, 25 Aug 2010 11:59:18 -0000 --Apple-Mail-315--512290172 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 24, 2010, at 6:07 PM, core issue tracker wrote: > #23: Virtual server capability? > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: zach@=85 =20= > Type: defect | Status: new =20 > Priority: minor | Milestone: coap-02 =20 > Component: coap | Version: =20 > Severity: - | Keywords: =20 > = --------------------------------+-----------------------------------------= -- > Carsten pointed out that we need to decide whether to support the Uri- > Authority option in non-proxy requests (and thus the virtual server > concept). =46rom the original mail: >=20 > I think we need to be clear whether a request to a server should = include > the authority or not. > Not all servers (if very constrained) may be able to find out whether = an > authority given is actually themselves or not. Instead of getting = simple > hosts into the habit of accepting any authority, I think it would be > better to leave the onus to connect to the right place to the client. >=20 > (The underlying question is how important the virtual server concept = is. > If we expect virtual servers to be an important feature, we'll need to > have the authority in there always, just as HTTP always has a Host: > header. If we ask clients to leave out the authority, we can't have > virtual servers. We can't have the client make a decision whether the > server will be using virtual servers. The above paragraph assumes not > sending the authority is more important than having the virtual server > capability.) When I earlier said I prefer not to support virtual servers, I should = have been more specific. My concern was: 1. On requiring virtual server capability for all end-points. I don't = see constrained servers being able to verify host names using DNS. As = Peter also pointed out, this can be achieved by attempting to match a = pre-configured list of host names. There is a significant chance of = misconfiguration here though. Hard to ensure that the host name will = actually match (required pre-configuration on both sides), and what are = the possible security risks?=20 2. Requiring Uri-Authority to be included even when it is repeated = overhead. Most requests made by constrained clients will only know the = IP address of the host. If we require the Uri-Authority even when it is = the same as the destination IP address it is a lot of wasteful overhead.=20= I don't find the virtual server concept very useful on constrained = servers themselves, nor for constrained clients making direct requests = from them. However, I do understand that intermediate or backend = infrastructure might make use of preserving the full URI of a request. = How can we allow that, without requiring a Uri-Authority in each and = every request?=20 One solution would be to elide the Uri-Authority when it is the same as = the IP destination address. In requests where the Uri-Authority is a = host name then the Uri-Authority option would be included by the = client. When a request URI is re-written by an intermediate, then the = Uri-Authority could be added if it doesn't already exist. Zach =20 >=20 > --=20 > Ticket URL: > core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-315--512290172 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNTExNTk0 OFowIwYJKoZIhvcNAQkEMRYEFL76vc+J4nhnQdaAVKJJu37aN4l+MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAA1NJDEX5WZxtvRfZWBLi1aNpVGQWbTA5ABoMoEvsgux9NkwfU0/td+7 B/j9OIsYz6Igkd3fAKDB0S4uZ6D3iZgprr+AYD7QppEmovVz8HHehHW6v1lufpGTvEwGIM9b02CH /gKe4umlEVX/sG/sJ4/zcY4rOJhU+ktv8CeYnkrou6shB8QsloJhn/3TN+WyFBC7eRQuHvmmO/Zn 0LjIeRzOuADsCljDG+AFUZEPUrcydMKJqT5Is4oB0E9OIRXyGZcr/x1ETuULCY6xYiZmzKrW0CDK IuupVBUGgf925RyI6ke7hABD9leaEqVnQfBuTG8iSY6Y0kcUBaehfpJfHhwAAAAAAAA= --Apple-Mail-315--512290172-- From zach@sensinode.com Wed Aug 25 05:16: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 5F8ED3A6AE3 for ; Wed, 25 Aug 2010 05:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 vG9m0xM-8pqU for ; Wed, 25 Aug 2010 05:16:55 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EB8383A6AB2 for ; Wed, 25 Aug 2010 05:16:53 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7PCHMb2021800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Aug 2010 15:17:22 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-316--511233036; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 25 Aug 2010 15:17:24 +0300 Message-Id: References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core@ietf.org Subject: Re: [core] #23: Virtual server capability? 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, 25 Aug 2010 12:16:57 -0000 --Apple-Mail-316--511233036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Peter, Great that you have a concrete scenario in mind. I also agree that CoAP = must be useful end-to-end for many M2M applications (e.g. AMI), a valid = design requirement. Could you elaborate with some example request = exchanges using intermediates? I would like to understand in your case = where and how Uri-Authority is being used. Also it seems to me that the = virtual server in the constrained server is not really needed, but = preserving the URI in the intermediate infrastructure is enough? Thanks, Zach=20 On Aug 24, 2010, at 8:09 PM, Peter Bigot wrote: > Having a UriAuthority in a request can be a problem if the receiving > server has limited functionality and can't, for example, do a DNS > lookup to verify a host name refers to it. I think this can be worked > around by simply comparing the authority against a fixed set of > authorities known by the server to be acceptable. Providing that list > is a configuration issue outside the scope of the protocol; at a > minimum it can be expected that the server can always recognize its > own IP address as a legal authority. >=20 > Eliminating the UriAuthority from the REST request sent to a server > would repeat the same mistake made in HTTP/1.0. That mistake had to > be fixed in HTTP/1.1 to allow HTTP to participate in full REST > transactions where arbitrary intermediate nodes unknown to the client > could provide value-added services without affecting how the client > accessed the resource. >=20 > I'd intended to use CoAP as an end-to-end protocol for a common case > of a full-function client collecting data from multiple > reduced-function servers, possibly in different administrative domains > with different intermediaries. I disagree with the statement in the > discussion of #20 that the UriAuthority is unnecessary to support > transparent proxying. The backbone of the success of REST on the web > is the ability to use virtual servers and DNS tricks to maintain a > persistent URI for a resource while evolving the infrastructure that > provides that resource. The uniform interface between components > which is the central feature of REST requires that the complete URI be > present at each step. >=20 > If CoAP can't be used end-to-end, then full-function clients like an > energy services platform will have to use HTTP to access the devices, > to enable use of these unknown intermediate services, such as gateways > to clouds of wireless devices. CoAP becomes useful only as the last > hop between a full-function gateway and the reduced-function devices. > Adequate for simple situations, but seriously limited in its potential > when compared to REST. >=20 > Peter >=20 > On Tue, Aug 24, 2010 at 10:07 AM, core issue tracker > wrote: >> #23: Virtual server capability? >> = --------------------------------+-----------------------------------------= -- >> Reporter: zach@=85 | Owner: zach@=85 >> Type: defect | Status: new >> Priority: minor | Milestone: coap-02 >> Component: coap | Version: >> Severity: - | Keywords: >> = --------------------------------+-----------------------------------------= -- >> Carsten pointed out that we need to decide whether to support the = Uri- >> Authority option in non-proxy requests (and thus the virtual server >> concept). =46rom the original mail: >>=20 >> I think we need to be clear whether a request to a server should = include >> the authority or not. >> Not all servers (if very constrained) may be able to find out = whether an >> authority given is actually themselves or not. Instead of getting = simple >> hosts into the habit of accepting any authority, I think it would be >> better to leave the onus to connect to the right place to the = client. >>=20 >> (The underlying question is how important the virtual server concept = is. >> If we expect virtual servers to be an important feature, we'll need = to >> have the authority in there always, just as HTTP always has a Host: >> header. If we ask clients to leave out the authority, we can't have >> virtual servers. We can't have the client make a decision whether = the >> server will be using virtual servers. The above paragraph assumes = not >> sending the authority is more important than having the virtual = server >> capability.) >>=20 >> -- >> Ticket URL: >> core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-316--511233036 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNTEyMTcy NVowIwYJKoZIhvcNAQkEMRYEFAvC6YHlWtIbh6lvwvvDmy6JrAKnMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAASPjKmRyX78/U90+ZQqxqQleq4XqDcYqmySeE+0L2VRo+CmhsAdFFiG iq+lWKC0FdbtRTqdhkw1Xb/lDUceigXQ/z4NfFDfbKQIyDv2xUDJQWoEXUUD6Jb3HfMf4XhtHXA9 wv9h9BUy462uCq0QD6jHNL06+HY3b1DUxe+2Ab7DdWc3ldb9p2EnGXrKlLfS00tbcZA6BTB6KTAx oeyvEgdCKcucnpkjhMFUEOIfYjNEnwkB2aigc+ZK036cA5u2qPtoujA/nnbpndalVCwvXOElU2lq GtRV6EGjw7HFNTDJn6gLDZJp5w3suJkTb03AwzYqmgIKU4PXJha0vo7D6z0AAAAAAAA= --Apple-Mail-316--511233036-- From cabo@tzi.org Wed Aug 25 06:12: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 38D3B3A687B for ; Wed, 25 Aug 2010 06:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.119 X-Spam-Level: X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 TGJebX66j979 for ; Wed, 25 Aug 2010 06:12:56 -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 8ACB53A69A4 for ; Wed, 25 Aug 2010 06:12:55 -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 o7PDDDGj014598 for ; Wed, 25 Aug 2010 15:13:18 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9B50E63DD; Wed, 25 Aug 2010 15:13:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann X-Priority: 3 In-Reply-To: Date: Wed, 25 Aug 2010 15:13:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <546491D2-18B6-46EC-B6A6-7C1BB5B53743@tzi.org> References: <0EA51384-5EAF-4FA8-90CC-D7C003483AC0@amsl.com> To: core X-Mailer: Apple Mail (2.1081) Subject: [core] REMINDER: info for CORE phone call on Wed Aug 25 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, 25 Aug 2010 13:12:58 -0000 So you don't have to hunt them down, below are the Webex details for the = conference call today. Note that 1500 UTC is 0800 PDT, 1100 EDT, 1700 CEST, 1800 EEST, 2400 = JST/KST, i.e., soon. Please download the consolidated slides ahead of time, which are at: http://www.ietf.org/proceedings/78/slides/core-1.pdf (I know this isn't the right place, but I don't know a righter place.) This slide set also contains the proposed agenda. (If you have any more slide updates, please send them to me quickly.) Please note that we do intend to record this meeting (Cullen, I hope you = know how to do this...). Gruesse, Carsten On Aug 3, 2010, at 19:26, Cullen Jennings wrote: > -------------------------------------------------------=20 > Meeting information=20 > -------------------------------------------------------=20 > Topic: CORE=20 > Date: Wednesday, August 25, 2010=20 > Time: 3:00 pm, (Reykjavik, GMT)=20 > Meeting Number: 966 638 223=20 > Meeting Password: (This meeting does not require a password.)=20 >=20 > -------------------------------------------------------=20 > To start or join the online meeting=20 > -------------------------------------------------------=20 > Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D135667597&UID=3D483233937= &RT=3DMiMyMA%3D%3D=20 >=20 > -------------------------------------------------------=20 > Audio conference information=20 > -------------------------------------------------------=20 > To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 > Call-in toll number (US/Canada): 1-408-792-6300=20 > Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED= =3D135667597&tollFree=3D0=20 >=20 > Access code:966 638 223=20 >=20 > -------------------------------------------------------=20 > For assistance=20 > -------------------------------------------------------=20 > 1. Go to https://workgreen.webex.com/workgreen/mc=20 > 2. On the left navigation bar, click "Support".=20 > To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 > = https://workgreen.webex.com/workgreen/j.php?ED=3D135667597&UID=3D483233937= &ICS=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA2=3D6e5oUaV5lRDBWS40m9TFH9Ra1A3NhSF5xRZ9= 1lYEHz0=3D=20 >=20 > To check whether you have the appropriate players installed for UCF = (Universal Communications Format) rich media files, go to = https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 >=20 > http://www.webex.com=20 >=20 >=20 >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. You should inform all meeting attendees = prior to recording if you intend to record the meeting. Please note that = any such recordings may be subject to discovery in the event of = litigation.=20 From cabo@tzi.org Wed Aug 25 08:00: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 F31FA3A6B2F for ; Wed, 25 Aug 2010 08:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 zbOsbvw72sOc for ; Wed, 25 Aug 2010 08:00:19 -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 E90573A6B2C for ; Wed, 25 Aug 2010 08:00:17 -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 o7PF0cfF027284 for ; Wed, 25 Aug 2010 17:00:43 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF4A964A3; Wed, 25 Aug 2010 17:00:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann X-Priority: 3 In-Reply-To: <546491D2-18B6-46EC-B6A6-7C1BB5B53743@tzi.org> Date: Wed, 25 Aug 2010 17:00:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9503FC29-BEFA-4A17-8BEA-C75AAC6A4211@tzi.org> References: <0EA51384-5EAF-4FA8-90CC-D7C003483AC0@amsl.com> <546491D2-18B6-46EC-B6A6-7C1BB5B53743@tzi.org> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] REMINDER: info for CORE phone call on Wed Aug 25 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, 25 Aug 2010 15:00:21 -0000 On Aug 25, 2010, at 15:13, Carsten Bormann wrote: > Note that 1500 UTC is 0800 PDT, 1100 EDT, 1700 CEST, 1800 EEST, 2400 = JST/KST, i.e., soon. In case you are wondering why the meeting does not start: We are, too. In the meantime, you can join core@jabber.ietf.org for some realtime = updates. Gruesse, Carsten From cabo@tzi.org Wed Aug 25 08:06: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 F0FC83A6B14 for ; Wed, 25 Aug 2010 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 uCWhjdNWoTfG for ; Wed, 25 Aug 2010 08:06:21 -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 C90C93A6B12 for ; Wed, 25 Aug 2010 08:06:15 -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 o7PF6aiA029758 for ; Wed, 25 Aug 2010 17:06:41 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9104E64AD; Wed, 25 Aug 2010 17:06:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann X-Priority: 3 In-Reply-To: <9503FC29-BEFA-4A17-8BEA-C75AAC6A4211@tzi.org> Date: Wed, 25 Aug 2010 17:06:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0EA51384-5EAF-4FA8-90CC-D7C003483AC0@amsl.com> <546491D2-18B6-46EC-B6A6-7C1BB5B53743@tzi.org> <9503FC29-BEFA-4A17-8BEA-C75AAC6A4211@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] REMINDER: info for CORE phone call on Wed Aug 25 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, 25 Aug 2010 15:06:22 -0000 On Aug 25, 2010, at 17:00, Carsten Bormann wrote: > In case you are wondering why the meeting does not start: We are, too. >=20 > In the meantime, you can join core@jabber.ietf.org for some realtime = updates. Cullen will try to set up a new Webex session, as the = secretariat-provided one does not start. Gruesse, Carsten From cabo@tzi.org Wed Aug 25 08:27:38 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 1E57F3A6A4C for ; Wed, 25 Aug 2010 08:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 zXS6OoyDd0jk for ; Wed, 25 Aug 2010 08:27:37 -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 9AE023A6885 for ; Wed, 25 Aug 2010 08:27:36 -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 o7PFRuMt006103; Wed, 25 Aug 2010 17:28:01 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B3C3364CF; Wed, 25 Aug 2010 17:27:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Carsten Bormann Date: Wed, 25 Aug 2010 17:27:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C27114A-8287-46DA-9FDF-C59A5E0385B2@tzi.org> To: core X-Mailer: Apple Mail (2.1081) Subject: [core] New Webex 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, 25 Aug 2010 15:27:38 -0000 h= ttps://ciscosales.webex.com/ciscosales/e.php?AT=3DWMI&EventID=3D147114532&= PW=3D1f1763412b5e5e4056&RT=3DMiM0= From fluffy@cisco.com Wed Aug 25 09:33:30 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 3AD103A6B35 for ; Wed, 25 Aug 2010 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 zznHh3HhHBs6 for ; Wed, 25 Aug 2010 09:33:16 -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 6BF373A6A43 for ; Wed, 25 Aug 2010 09:33:14 -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: AvsEAGHidEyrR7Ht/2dsb2JhbACgPXGhPpwYhTcEhDqFSQ X-IronPort-AV: E=Sophos;i="4.56,269,1280707200"; d="scan'208";a="176769433" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 25 Aug 2010 16:33:47 +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 o7PGXkPP020895 for ; Wed, 25 Aug 2010 16:33:46 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings X-Priority: 3 In-Reply-To: Date: Wed, 25 Aug 2010 10:33:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0EA51384-5EAF-4FA8-90CC-D7C003483AC0@amsl.com> <546491D2-18B6-46EC-B6A6-7C1BB5B53743@tzi.org> <9503FC29-BEFA-4A17-8BEA-C75AAC6A4211@tzi.org> To: core X-Mailer: Apple Mail (2.1081) Subject: Re: [core] REMINDER: info for CORE phone call on Wed Aug 25 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, 25 Aug 2010 16:33:30 -0000 I think we have tracked down what went wrong with the original webex = call and hopefully it won't happen again.=20 Cullen On Aug 25, 2010, at 9:06 AM, Carsten Bormann wrote: > On Aug 25, 2010, at 17:00, Carsten Bormann wrote: >=20 >> In case you are wondering why the meeting does not start: We are, = too. >>=20 >> In the meantime, you can join core@jabber.ietf.org for some realtime = updates. >=20 > Cullen will try to set up a new Webex session, as the = secretariat-provided one does not start. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pab@peoplepowerco.com Wed Aug 25 14:04: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 AE10B3A68A7 for ; Wed, 25 Aug 2010 14:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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 3SM9PJfMOu9E for ; Wed, 25 Aug 2010 14:04:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 48FF73A6829 for ; Wed, 25 Aug 2010 14:04:07 -0700 (PDT) Received: by iwn3 with SMTP id 3so969117iwn.31 for ; Wed, 25 Aug 2010 14:04:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.192.67 with SMTP id dp3mr10708565ibb.180.1282770279584; Wed, 25 Aug 2010 14:04:39 -0700 (PDT) Received: by 10.231.33.73 with HTTP; Wed, 25 Aug 2010 14:04:38 -0700 (PDT) In-Reply-To: <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> Date: Wed, 25 Aug 2010 16:04:38 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=0016363b8d5ed7d6a1048eac3a6a Cc: core issue tracker , core Subject: Re: [core] #23: Virtual server capability? 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, 25 Aug 2010 21:04:09 -0000 --0016363b8d5ed7d6a1048eac3a6a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Can we clarify what's meant by "requiring virtual server capability for all end-points"? "Virtual server" in the sense of assigning multiple hostnames to the same IP address and allowing the receiver to sort them out is one technique that's enabled by providing the authority part of the URI within the REST message. But it's not the only time the authority part is needed. I think most of us agree that anything that requires a constrained server t= o do DNS lookups is unacceptable. I hope we all agree that validation of authority could be done in much more simple ways, which can be left out of scope for CoAP. A quick search failed to find anything in RFC2616 that specified how the server must interpret the naming authority that's passed in the Host field, which is really what the UriAuthority option is. RFC261= 6 simply specifies that it must be made available, because its absence prevented useful things from being done. Consequent to this discovery, I don't think we even need to specify that an origin server is required to even look at the authority option. It could just assume that the resource is the one it's responsible for. What I understand you and Carsten to be concerned with is that including th= e authority can take a lot of message space, and therefore if it can be reconstructed from external information there's no need to include it in th= e REST message. So the real question is "how can CoAP support omission of UriAuthority in requests without impacting its application to REST architectures that use constrained devices?" Do we all agree that, regardless of how or whether a constrained server validates the authority part of the URI, the protocol must ensure it is available (explicitly or implicitly) in any case where its value is require= d for the server to correctly identify the resource? It's already understood that this is true when the server is a configured proxy, or when virtual servers hosted on a transparent proxy are used. But it can also occur when the server is an origin server. See below for some examples. If so, I can go on to claim that the precondition of "if it can be reconstructed from external information" is a server property that cannot b= e determined a-priori by a client. Consequently, there is no way for the client to guarantee availability of the authority part of the resource URI at the server unless the client always sends it along with the rest of the URI within the REST message. Here's the argument: I assume it's reasonable to expect that CoAP could be implemented using a standard network API like POSIX sockets. Recall that a POSIX socket bound to the wildcard address will generally receive packets addressed to the hos= t through any IP address bound to any NIC on the host. The POSIX API does no= t provide access to the destination address in the original IP packet. - Even if an origin server has only one NIC with one unicast IP address, it might have to handle requests for several resources for which the URI= s have the same path and are distinguished only by distinct multicast or anycast addresses, all received over the same socket. - An origin server can legitimately be multi-homed: In our systems, we have a very constrained node that will need to run CoAP but still has tw= o NICs: a serial connection running IPv6/PPP and an 802.15.4 radio. If I = ask for a resource with pathname /nic/stats and the authority was the IP add= ress of either the PPP link or the radio link, I need to know which so I send= the right NIC statistics back. - Though virtual servers are normally implemented by multiple hostnames to the same IP address, nothing prevents me from assigning multiple IP addresses to the outward facing NIC of a gateway device and accomplishin= g the same thing. All these cases hold even if the authority is an IP-literal address. Also consider the issue of asynchronous responses: unless the token proposa= l eliminates the use of the URI to correlate the response with a request, the server must be able to reconstruct enough of the original URI so that the *client* can identify the resource. Some of the cases suggested above are ones where an absent authority would be difficult to reconstruct for the response message; and leaving it out could put the client to a lot of effor= t to identify which resource was meant. So much easier if it's just provided in the original request and can be copied into the response unchanged. In summary, there are too many cases where dropping the URI authority from the REST message creates problems for perfectly reasonable applications of CoAP. I think the fundamental protocol has to ensure that it's always possible for the authority to be provided in the REST request. Now, we could specify a rule that would enable a client to omit the UriAuthority in a request, like: - if the UriAuthority option is absent and the remainder of the URI uniquely identifies a resource the server MAY proceed to execute the request. If the server requires the authority to identify the resource= it MUST reject the request with "400 Bad Request". With this, you could even try omitting the authority when it's a hostname, which is when it'll really save space. However, the client would still would have to accept that a "400 Bad Request" may indicate it needs to retransmit the request with the missing information before being sure the request was really invalid. I also think it would cause hard-to-diagnose problems with, for example, DNS misconfigurations. But if shorter messages are that important, a system designer might choose to take the risk: it becomes a quality-of-implementation issue, not a protocol-capability issue. Unless there're problems I don't see, that'd work for me. Would it be acceptable to you? (Regarding those unseen problems: there's still the open question of what's to be done if the server has to reconstruct the authority for an asynchronous response. It's probably necessary to understand what a distributed resource addressed by a group name means in REST before we coul= d figure out what to do then. For now, a reasonable technique would be to "400 Bad Request" anything that doesn't have a UriAuthority but requires an asynchronous response.) Peter On Wed, Aug 25, 2010 at 6:59 AM, Zach Shelby wrote: > > On Aug 24, 2010, at 6:07 PM, core issue tracker wrote: > >> #23: Virtual server capability? >> --------------------------------+------------------------------------------= - >> Reporter: zach@=85 | Owner: zach@=85 >> Type: defect | Status: new >> Priority: minor | Milestone: coap-02 >> Component: coap | Version: >> Severity: - | Keywords: >> --------------------------------+------------------------------------------= - >> Carsten pointed out that we need to decide whether to support the Uri- >> Authority option in non-proxy requests (and thus the virtual server >> concept). From the original mail: >> >> I think we need to be clear whether a request to a server should include >> the authority or not. >> Not all servers (if very constrained) may be able to find out whether an >> authority given is actually themselves or not. Instead of getting simpl= e >> hosts into the habit of accepting any authority, I think it would be >> better to leave the onus to connect to the right place to the client. >> >> (The underlying question is how important the virtual server concept is. >> If we expect virtual servers to be an important feature, we'll need to >> have the authority in there always, just as HTTP always has a Host: >> header. If we ask clients to leave out the authority, we can't have >> virtual servers. We can't have the client make a decision whether the >> server will be using virtual servers. The above paragraph assumes not >> sending the authority is more important than having the virtual server >> capability.) > > When I earlier said I prefer not to support virtual servers, I should hav= e been more specific. My concern was: > > 1. On requiring virtual server capability for all end-points. I don't see constrained servers being able to verify host names using DNS. As Peter als= o pointed out, this can be achieved by attempting to match a pre-configured list of host names. There is a significant chance of misconfiguration here though. Hard to ensure that the host name will actually match (required pre-configuration on both sides), and what are the possible security risks? > > 2. Requiring Uri-Authority to be included even when it is repeated overhead. Most requests made by constrained clients will only know the IP address of the host. If we require the Uri-Authority even when it is the same as the destination IP address it is a lot of wasteful overhead. > > I don't find the virtual server concept very useful on constrained server= s themselves, nor for constrained clients making direct requests from them. However, I do understand that intermediate or backend infrastructure might make use of preserving the full URI of a request. How can we allow that, without requiring a Uri-Authority in each and every request? > > One solution would be to elide the Uri-Authority when it is the same as the IP destination address. In requests where the Uri-Authority is a host name then the Uri-Authority option would be included by the client. When a request URI is re-written by an intermediate, then the Uri-Authority could be added if it doesn't already exist. > > Zach > >> >> -- >> Ticket URL: >> core >> > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --0016363b8d5ed7d6a1048eac3a6a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Can we clarify what's meant by "requiring virtual server capabilit= y for all end-points"? =A0"Virtual server" in the sense of a= ssigning multiple hostnames to the same IP address and allowing the receive= r to sort them out is one technique that's enabled by providing the aut= hority part of the URI within the REST message. =A0But it's not the onl= y time the authority part is needed.

I think most of us agree that anything that requires a constrained serv= er to do DNS lookups is unacceptable. =A0I hope we all agree that validatio= n of authority could be done in much more simple ways, which can be left ou= t of scope for CoAP.=A0=A0 A quick search failed to find anything in RFC261= 6 that specified how the server must interpret the naming authority that= 9;s passed in the Host field, which is really what the UriAuthority option = is.=A0 RFC2616 simply specifies that it must be made available, because its= absence prevented useful things from being done.=A0 Consequent to this dis= covery, I don't think we even need to specify that an origin server is = required to even look at the authority option.=A0 It could just assume that= the resource is the one it's responsible for.

What I understand you and Carsten to be concerned with is that includin= g the authority can take a lot of message space, and therefore if it can be= reconstructed from external information there's no need to include it = in the REST message. =A0So the real question is "how can CoAP support = omission of UriAuthority in requests without impacting its application to R= EST architectures that use constrained devices?"

Do we all agree that, regardless of how or whether a constrained server= validates the authority part of the URI, the protocol must ensure it is av= ailable (explicitly or implicitly) in any case where its value is required = for the server to correctly identify the resource?=A0 It's already unde= rstood that this is true when the server is a configured proxy, or when vir= tual servers hosted on a transparent proxy are used.=A0 But it can also occ= ur when the server is an origin server.=A0 See below for some examples.

If so, I can go on to claim that the precondition of "if it can be= reconstructed from external information" is a server property that ca= nnot be determined a-priori by a client. =A0Consequently, there is no way f= or the client to guarantee availability of the authority part of the resour= ce URI at the server unless the client always sends it along with the rest = of the URI within the REST message.

Here's the argument:

I assume it's reasonable to expect = that CoAP could be implemented using a standard network API like POSIX sock= ets. =A0Recall that a POSIX socket bound to the wildcard address will gener= ally receive packets addressed to the host through any IP address bound to = any NIC on the host. =A0The POSIX API does not provide access to the destin= ation address in the original IP packet.

  • Even if an origin server has only one NIC with one unicast IP addre= ss, it might have to handle requests for several resources for which the UR= Is have the same path and are distinguished only by distinct multicast or a= nycast addresses, all received over the same socket.
  • An origin server can legitimately be multi-homed: In our systems, we ha= ve a very constrained node that will need to run CoAP but still has two NIC= s: a serial connection running IPv6/PPP and an 802.15.4 radio. =A0If I ask = for a resource with pathname /nic/stats and the authority was the IP addres= s of either the PPP link or the radio link, I need to know which so I send = the right NIC statistics back.
  • Though virtual servers are normally implemented by multiple hostnames t= o the same IP address, nothing prevents me from assigning multiple IP addre= sses to the outward facing NIC of a gateway device and accomplishing the sa= me thing.
All these cases hold even if the authority is an IP-literal addre= ss.

Also consider the issue of asynchronous responses: unless the to= ken proposal eliminates the use of the URI to correlate the response with a= request, the server must be able to reconstruct enough of the original URI= so that the *client* can identify the resource. =A0Some of the cases sugge= sted above are ones where an absent authority would be difficult to reconst= ruct for the response message; and leaving it out could put the client to a= lot of effort to identify which resource was meant. =A0So much easier if i= t's just provided in the original request and can be copied into the re= sponse unchanged.

In summary, there are too many cases where dropping the URI authority f= rom the REST message creates problems for perfectly reasonable applications= of CoAP. =A0I think the fundamental protocol has to ensure that it's a= lways possible for the authority to be provided in the REST request.

Now, we could specify a rule that would enable a client to omit the Uri= Authority in a request, like:
  • if the UriAuthority option is abse= nt and the remainder of the URI uniquely identifies a resource the server M= AY proceed to execute the request.=A0=A0 If the server requires the authori= ty to identify the resource it MUST reject the request with "400 Bad R= equest".
With this, you could even try omitting the authority when it'= s a hostname, which is when it'll really save space.=A0 However, the cl= ient would still would have to accept that a "400 Bad Request" ma= y indicate it needs to retransmit the request with the missing information = before being sure the request was really invalid.=A0 I also think it would = cause hard-to-diagnose problems with, for example, DNS misconfigurations.= =A0 But if shorter messages are that important, a system designer might cho= ose to take the risk: it becomes a quality-of-implementation issue, not a p= rotocol-capability issue.=A0 Unless there're problems I don't see, = that'd work for me.=A0 Would it be acceptable to you?

(Regarding those unseen problems: there's still the open question o= f what's to be done if the server has to reconstruct the authority for = an asynchronous response. =A0It's probably necessary to understand what= a distributed resource addressed by a group name means in REST before we c= ould figure out what to do then.=A0 For now, a reasonable technique would b= e to "400 Bad Request" anything that doesn't have a UriAuthor= ity but requires an asynchronous response.)

Peter

On Wed, Aug 25, 2010 at 6:59 AM, Zach Shelby <zach@sensinode.com> wrote:
>> On Aug 24, 2010, at 6:07 PM, core issue tracker wrote:
>
>= ;> #23: Virtual server capability?
>> --------------------------------+---------------------------------= ----------
>> Reporter: =A0zach@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 Owner: =A0zach@=85
>> =A0 =A0 Type: =A0defect =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
>> Priority: =A0min= or =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0coap-02
>> Component: =A0coap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Versio= n:
>> Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0= Keywords:
>> --------------------------------+--------------------= -----------------------
>> Carsten pointed out that we need to dec= ide whether to support the Uri-
>> Authority option in non-proxy requests (and thus the virtual serve= r
>> concept). From the original mail:
>>
>> I t= hink we need to be clear whether a request to a server should include
>> the authority or not.
>> Not all servers (if very constra= ined) may be able to find out whether an
>> authority given is act= ually themselves or not. =A0Instead of getting simple
>> hosts int= o the habit of accepting any authority, I think it would be
>> better to leave the onus to connect to the right place to the clie= nt.
>>
>> (The underlying question is how important the v= irtual server concept is.
>> If we expect virtual servers to be an= important feature, we'll need to
>> have the authority in there always, just as HTTP always has a Host= :
>> header. =A0If we ask clients to leave out the authority, we c= an't have
>> virtual servers. =A0We can't have the client = make a decision whether the
>> server will be using virtual servers. =A0The above paragraph assum= es not
>> sending the authority is more important than having the = virtual server
>> capability.)
>
> When I earlier said= I prefer not to support virtual servers, I should have been more specific.= My concern was:
>
> 1. On requiring virtual server capability for all end-points. = I don't see constrained servers being able to verify host names using D= NS. As Peter also pointed out, this can be achieved by attempting to match = a pre-configured list of host names. There is a significant chance of misco= nfiguration here though. Hard to ensure that the host name will actually ma= tch (required pre-configuration on both sides), and what are the possible s= ecurity risks?
>
> 2. Requiring Uri-Authority to be included even when it is repe= ated overhead. Most requests made by constrained clients will only know the= IP address of the host. If we require the Uri-Authority even when it is th= e same as the destination IP address it is a lot of wasteful overhead.
>
> I don't find the virtual server concept very useful on con= strained servers themselves, nor for constrained clients making direct requ= ests from them. However, I do understand that intermediate or backend infra= structure might make use of preserving the full URI of a request. How can w= e allow that, without requiring a Uri-Authority in each and every request?<= br> >
> One solution would be to elide the Uri-Authority when it is th= e same as the IP destination address. In requests where the Uri-Authority i= s a host name =A0then the Uri-Authority option would be included by the cli= ent. When a request URI is re-written by an intermediate, then the Uri-Auth= ority could be added if it doesn't already exist.
>
> Zach
>
>>
>> --
>> Ticket URL= : <http://= trac.tools.ietf.org/wg/core/trac/ticket/23>
>> core <http://tools.ietf.org/core/> >>
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.=
> http://zachshelby.org =A0- M= y blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embed= ded Internet"
> Mobile: +358 40 7796297
>
>
> ______________________= _________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>

--0016363b8d5ed7d6a1048eac3a6a-- From cabo@tzi.org Wed Aug 25 15:03: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 6B5723A6837 for ; Wed, 25 Aug 2010 15:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 dhci9VRPV6G8 for ; Wed, 25 Aug 2010 15:03:44 -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 CE4413A63C9 for ; Wed, 25 Aug 2010 15:03: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 o7PM41at008835; Thu, 26 Aug 2010 00:04:07 +0200 (CEST) Received: from [192.168.217.101] (p5489CA4E.dip.t-dialin.net [84.137.202.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 71814658B; Thu, 26 Aug 2010 00:04:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 26 Aug 2010 00:04:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core Subject: Re: [core] #23: Virtual server capability? 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, 25 Aug 2010 22:03:45 -0000 On Aug 25, 2010, at 23:04, Peter Bigot wrote: > Recall that a POSIX socket bound to the wildcard address will = generally receive packets addressed to the host through any IP address = bound to any NIC on the host. The POSIX API does not provide access to = the destination address in the original IP packet. Peter, interesting analyis! Let me just answer on this one point for now, because it comes up = repeatedly: If you really need to program to POSIX interfaces, then don't do that. Bind one socket per address. With Java or .NET, you may be stuck with this (I don't know). For the rest of us on general-purpose OSes, there is = IP_RECVDSTADDR/IP_PKTINFO/IPV6_RECVPKTINFO/... With luck, as defined in RFC 3542. Not pretty, but workable. This is less of an issue for a constrained OS, but, as you say, that is = where we probably don't care. Gruesse, Carsten From pab@peoplepowerco.com Thu Aug 26 04:18: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 04ABF3A6AAC for ; Thu, 26 Aug 2010 04:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 77T9x+tpHZqY for ; Thu, 26 Aug 2010 04:18:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B16943A6AA4 for ; Thu, 26 Aug 2010 04:18:00 -0700 (PDT) Received: by vws10 with SMTP id 10so1746747vws.31 for ; Thu, 26 Aug 2010 04:18:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.88.22 with SMTP id y22mr6102663vcl.12.1282821512798; Thu, 26 Aug 2010 04:18:32 -0700 (PDT) Received: by 10.220.172.65 with HTTP; Thu, 26 Aug 2010 04:18:32 -0700 (PDT) In-Reply-To: References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> Date: Thu, 26 Aug 2010 06:18:32 -0500 Message-ID: From: Peter Bigot To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e647185e94a281048eb828ac Cc: core issue tracker , core Subject: Re: [core] #23: Virtual server capability? 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, 26 Aug 2010 11:18:02 -0000 --0016e647185e94a281048eb828ac Content-Type: text/plain; charset=ISO-8859-1 First, my constrained devices use a POSIX API, because I want to lower the barrier to entry for people who need to develop on them by supporting a familiar and standard interface. One socket per address is not an acceptable solution. Second, do not assume that the vast majority of CoAP implementation work will be done on constrained devices. There will be many devices, and there will be a strong need to enhance them with highly capable intermediate services that allow simple clients (some of them constrained) to communicate with sleeping nodes and across multiple link layers, provide value-added composition and abstraction services, translate between vendor resource representations and URI syntax, etc. It is support for these unknown intermediaries that makes REST such a powerful style, and unless CoAP is to be relegated to a last-hop role these services must be implementable for CoAP rather than prior to some as-yet-undefined HTTP/CoAP translation. In terms of complexity of application and time spent in development, CoAP may well be used more in these environments, for which Python, Java, dot NET, and other high-level languages and APIs would normally be very suitable. Protocol decisions that require use of special tricks and low-level vendor-specific APIs will ensure a short and unhappy life for CoAP before it's replaced by something more usable. Peter On Wed, Aug 25, 2010 at 5:04 PM, Carsten Bormann wrote: > On Aug 25, 2010, at 23:04, Peter Bigot wrote: > > > Recall that a POSIX socket bound to the wildcard address will generally > receive packets addressed to the host through any IP address bound to any > NIC on the host. The POSIX API does not provide access to the destination > address in the original IP packet. > > Peter, > > interesting analyis! > > Let me just answer on this one point for now, because it comes up > repeatedly: > > If you really need to program to POSIX interfaces, then don't do that. > Bind one socket per address. > With Java or .NET, you may be stuck with this (I don't know). > > For the rest of us on general-purpose OSes, there is > IP_RECVDSTADDR/IP_PKTINFO/IPV6_RECVPKTINFO/... > With luck, as defined in RFC 3542. Not pretty, but workable. > > This is less of an issue for a constrained OS, but, as you say, that is > where we probably don't care. > > Gruesse, Carsten > > --0016e647185e94a281048eb828ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First, my constrained devices use a POSIX API, because I want to lower the = barrier to entry for people who need to develop on them by supporting a fam= iliar and standard interface.=A0 One socket per address is not an acceptabl= e solution.

Second, do not assume that the vast majority of CoAP implementation wor= k will be done on constrained devices.=A0 There will be many devices, and t= here will be a strong need to enhance them with highly capable intermediate= services that allow simple clients (some of them constrained) to communica= te with sleeping nodes and across multiple link layers, provide value-added= composition and abstraction services, translate between vendor resource re= presentations and URI syntax, etc.=A0 It is support for these unknown inter= mediaries that makes REST such a powerful style, and unless CoAP is to be r= elegated to a last-hop role these services must be implementable for CoAP r= ather than prior to some as-yet-undefined HTTP/CoAP translation.

In terms of complexity of application and time spent in development, Co= AP may well be used more in these environments, for which Python, Java, dot= NET, and other high-level languages and APIs would normally be very suitab= le.=A0 Protocol decisions that require use of special tricks and low-level = vendor-specific APIs will ensure a short and unhappy life for CoAP before i= t's replaced by something more usable.

Peter

On Wed, Aug 25, 2010 at 5:04 PM= , Carsten Bormann <cabo@tzi.org> wrote:
On Aug 25, 2010, at 23:04, Peter Bigot wrote:

> Recall that a POSIX socket bound to the wildcard address will generall= y receive packets addressed to the host through any IP address bound to any= NIC on the host. =A0The POSIX API does not provide access to the destinati= on address in the original IP packet.

Peter,

interesting analyis!

Let me just answer on this one point for now, because it comes up repeatedl= y:

If you really need to program to POSIX interfaces, then don't do that.<= br> Bind one socket per address.
With Java or .NET, you may be stuck with this (I don't know).

For the rest of us on general-purpose OSes, there is IP_RECVDSTADDR/IP_PKTI= NFO/IPV6_RECVPKTINFO/...
With luck, as defined in RFC 3542. =A0Not pretty, but workable.

This is less of an issue for a constrained OS, but, as you say, that is whe= re we probably don't care.

Gruesse, Carsten


--0016e647185e94a281048eb828ac-- From pab@peoplepowerco.com Thu Aug 26 04:22: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 F224F3A691B for ; Thu, 26 Aug 2010 04:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 fL0Zckn6IDYi for ; Thu, 26 Aug 2010 04:22:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id EDC5C3A6AB5 for ; Thu, 26 Aug 2010 04:22:34 -0700 (PDT) Received: by vws10 with SMTP id 10so1750497vws.31 for ; Thu, 26 Aug 2010 04:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.198 with SMTP id l6mr479221vcs.219.1282821785604; Thu, 26 Aug 2010 04:23:05 -0700 (PDT) Received: by 10.220.172.65 with HTTP; Thu, 26 Aug 2010 04:23:05 -0700 (PDT) Date: Thu, 26 Aug 2010 06:23:05 -0500 Message-ID: From: Peter Bigot To: core Content-Type: multipart/alternative; boundary=e0cb4e887e71d752db048eb83875 Subject: [core] duration type comments 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, 26 Aug 2010 11:22:36 -0000 --e0cb4e887e71d752db048eb83875 Content-Type: text/plain; charset=ISO-8859-1 Rather than spend a lot of time on this one: 1. It is suggested that many options require a duration. I could find only two: subscription-lifetime and max-age. Before determining the encoding, the characteristics of these durations should be reviewed. I suspect virtually every use of subscription-lifetime will be either "forever" or "stop". What range of durations are reasonably expected for Max-Age for resources that reflect measurements of real-world data? 2. While we could select an encoding that supports only those durations we're thinking about now, I would prefer one that could handle other natural uses of duration, like "how long until a scheduled event". For that use, a set of representable values that is not closed under subtraction is unsuitable. 3. A detailed description of the subscription-lifetime option encoding in variable-length-integer format takes one third of a page in draft-hartke-coap-observe-02. The pseudo-FP approach takes three pages to motivate and describe, plus five pages to list its values. It's a nice solution, but any claim that this decreases complexity relative to variable-length-integer is indefensible. 4. I'm not going to bother to implement this right now to see how much space it takes, but if we continue to create novel encodings that require, for example, three times as much ROM as a comparable straightforward encoding, CoAP will be unimplementable on the very devices where it's most needed. Peter --e0cb4e887e71d752db048eb83875 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rather than spend a lot of time on this one:

1. It is suggested that= many options require a duration.=A0 I could find only two: subscription-li= fetime and max-age.=A0 Before determining the encoding, the characteristics= of these durations should be reviewed.=A0 I suspect virtually every use of= subscription-lifetime will be either "forever" or "stop&quo= t;.=A0 What range of durations are reasonably expected for Max-Age for reso= urces that reflect measurements of real-world data?

2. While we could select an encoding that supports only those durations= we're thinking about now, I would prefer one that could handle other n= atural uses of duration, like "how long until a scheduled event".= =A0 For that use, a set of representable values that is not closed under su= btraction is unsuitable.

3. A detailed description of the subscription-lifetime option encoding = in variable-length-integer format takes one third of a page in draft-hartke= -coap-observe-02.=A0 The pseudo-FP approach takes three pages to motivate a= nd describe, plus five pages to list its values.=A0 It's a nice solutio= n, but any claim that this decreases complexity relative to variable-length= -integer is indefensible.

4. I'm not going to bother to implement this right now to see how m= uch space it takes, but if we continue to create novel encodings that requi= re, for example, three times as much ROM as a comparable straightforward en= coding, CoAP will be unimplementable on the very devices where it's mos= t needed.

Peter
--e0cb4e887e71d752db048eb83875-- From cabo@tzi.org Thu Aug 26 06:09: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 C24243A6982 for ; Thu, 26 Aug 2010 06:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.05 X-Spam-Level: X-Spam-Status: No, score=-106.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 GZLjlQcNnRkO for ; Thu, 26 Aug 2010 06:09:39 -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 2939D3A683A for ; Thu, 26 Aug 2010 06:09:38 -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 o7QD9xZw011091; Thu, 26 Aug 2010 15:10:04 +0200 (CEST) Received: from [192.168.217.101] (p5489F9F2.dip.t-dialin.net [84.137.249.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF606680E; Thu, 26 Aug 2010 15:09:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 26 Aug 2010 15:09:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4103345C-420F-49CE-9E1A-E0F6272ABD60@tzi.org> References: To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] duration type comments 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, 26 Aug 2010 13:09:40 -0000 On Aug 26, 2010, at 13:23, Peter Bigot wrote: > Rather than spend a lot of time on this one: >=20 > 1. It is suggested that many options require a duration. I could find = only two: subscription-lifetime and max-age. Before determining the = encoding, the characteristics of these durations should be reviewed. I = suspect virtually every use of subscription-lifetime will be either = "forever" or "stop". What range of durations are reasonably expected = for Max-Age for resources that reflect measurements of real-world data? I don't have a scientifically grounded answer for that, but various = discussions I have had so far indicate that 1 second to a couple of = months is about the right range. > 2. While we could select an encoding that supports only those = durations we're thinking about now, I would prefer one that could handle = other natural uses of duration, like "how long until a scheduled event". = For that use, a set of representable values that is not closed under = subtraction is unsuitable. It is always hard to design for unknown future requirements. The duration type was indeed meant for soft-state/lifetime-like = durations, not for anything approaching precise timing (there is no = consideration of clock skew or leap seconds, for instance). > 3. A detailed description of the subscription-lifetime option encoding = in variable-length-integer format takes one third of a page in = draft-hartke-coap-observe-02. The pseudo-FP approach takes three pages = to motivate and describe, plus five pages to list its values. It's a = nice solution, but any claim that this decreases complexity relative to = variable-length-integer is indefensible. This is a deliberately unfair statement. I wrote expansive text, erring on the side of redundancy, when I noticed = not every implementer has the CS background about number representations = I would have expected. A description of binary numbers at this level of detail would be about = as long. The actual description is five lines of C, four of which are constant = definitions. The reduced complexity comes from the reduced variability in length, not = from a shorter description. But maybe I'm the only one who sees that advantage. > 4. I'm not going to bother to implement this right now to see how much = space it takes, but if we continue to create novel encodings that = require, for example, three times as much ROM as a comparable = straightforward encoding, CoAP will be unimplementable on the very = devices where it's most needed. The implementation is in the draft. I think the meta-observation here is that the technical advantages or = disadvantages are mostly irrelevant where people are significantly more = familiar with one way of doing things than with another way. I do think = that is an important consideration in protocol design. I just wasn't = prepared for such a reaction in this case. (This is not about you, = others had the same reaction.) I'm willing to learn. Gruesse, Carsten From zach@sensinode.com Thu Aug 26 07:00: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 08AB83A6993 for ; Thu, 26 Aug 2010 07:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 cHZqzJNLdDLN for ; Thu, 26 Aug 2010 07:00:54 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2E14E3A6995 for ; Thu, 26 Aug 2010 07:00:53 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7QE1M81016438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Aug 2010 17:01:22 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-446--418593571; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4103345C-420F-49CE-9E1A-E0F6272ABD60@tzi.org> Date: Thu, 26 Aug 2010 17:01:24 +0300 Message-Id: References: <4103345C-420F-49CE-9E1A-E0F6272ABD60@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Cc: core Subject: Re: [core] duration type comments 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, 26 Aug 2010 14:00:56 -0000 --Apple-Mail-446--418593571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 26, 2010, at 4:09 PM, Carsten Bormann wrote: > I think the meta-observation here is that the technical advantages or = disadvantages are mostly irrelevant where people are significantly more = familiar with one way of doing things than with another way. I do think = that is an important consideration in protocol design. I just wasn't = prepared for such a reaction in this case. (This is not about you, = others had the same reaction.) I'm willing to learn. It is true that this has more to do with the humans than machines, = although the format does have limitations if used where it wasn't meant = to be. I'm pretty neutral on this, but to concentrate energy on things = we really need to work on like security - I suggest we stick with the = variable length integer format for coap-observe and other durations. =20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-446--418593571 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNjE0MDEy NFowIwYJKoZIhvcNAQkEMRYEFIWfOi0C4r049/tdToyvQCLjI88bMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADZ1dgd8zocoVrvNcn6eGj1mAKfsTA7GYpMSvnLuYPjNt4md0AY600cc LgJ26zLOECddqH74pbr/c4vErvwh+U81LKNR/o/SzILZEICcAkp+Sb3h9jM5Jtlg+j2oovi9uavv tTfrCr3xWrCoQ7Kx+BipQ0+j4ffX2BVLlXiD82nfMpEl1r1Pk/BSX+86Q9vpyVLkNrOhCHqz72Dk 6aC5Zmk6JfNMaR4HWyguoU01JNgadHxJF5QTy67fKB17SrMZ3FMWnqvSduRWg3eX230rDOsLXH3i iK5tHASu7ZhsWtz1Rz76QCV8/fz4ikRWjpaJbqKUyIjCKMQQUXlRZ95HAeYAAAAAAAA= --Apple-Mail-446--418593571-- From zach@sensinode.com Thu Aug 26 07:07: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 E3F993A69A6 for ; Thu, 26 Aug 2010 07:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 vsbG7yWLRyfz for ; Thu, 26 Aug 2010 07:07:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 250873A699E for ; Thu, 26 Aug 2010 07:07:17 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7QE7ldv018447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Aug 2010 17:07:47 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-449--418208772; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Thu, 26 Aug 2010 17:07:49 +0300 Message-Id: <5F9025D2-3F02-4CB0-AF58-08938F533490@sensinode.com> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core Subject: Re: [core] #23: Virtual server capability? 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, 26 Aug 2010 14:07:20 -0000 --Apple-Mail-449--418208772 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 26, 2010, at 12:04 AM, Peter Bigot wrote: > In summary, there are too many cases where dropping the URI authority = from the REST message creates problems for perfectly reasonable = applications of CoAP. I think the fundamental protocol has to ensure = that it's always possible for the authority to be provided in the REST = request. >=20 > Now, we could specify a rule that would enable a client to omit the = UriAuthority in a request, like: > =95 if the UriAuthority option is absent and the remainder of = the URI uniquely identifies a resource the server MAY proceed to execute = the request. If the server requires the authority to identify the = resource it MUST reject the request with "400 Bad Request". Works for me. Anyone have problems with text like this? If not I will = use this as the solution for Ticket #23. Clearly we need some more text on how to interpret the RequestURI in = coap-02, and of course to consider the other implications of URIs with = CoAP (e.g. multicast, asynchronous responses etc.).=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-449--418208772 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNjE0MDc0 OVowIwYJKoZIhvcNAQkEMRYEFPNu1eieVbRP1Dd2Iyck9WDSM5M/MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADMbGyACiicg3XocusERBuXUikEtR5+SzVL7C0SEytEthylyIlFC5hvK En71+jeZuYWDf7jT5kZpF4q8f02cZmUmgQ/e+TlG6pWBBTOQ96hekZqRW7bakzwPDUD7ZxSaL6WU SXFF8D33dbUSC/IIxRRjalhb75dVUQszSJcscZzOUSaQ+Kp9mo1DzAugIoRYkXE5UalNbOu8U1bi DQCCuRSLtwYyTVRelVAp9GZfTw3zCQiYO3VlrM1fGhLOCn+fUXo0SwQbrq6h490sOEmAm06c2BYM c3XHI0mlYEXihYXg2dMRrGYdYMRfgqQEq9wm2AJ1Um+/mmbdicd7jk43F0QAAAAAAAA= --Apple-Mail-449--418208772-- From cabo@tzi.org Thu Aug 26 07:12: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 45D2B3A69C3 for ; Thu, 26 Aug 2010 07:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.055 X-Spam-Level: X-Spam-Status: No, score=-106.055 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 kOy-IMv1kTCj for ; Thu, 26 Aug 2010 07:12:52 -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 6D1503A681A for ; Thu, 26 Aug 2010 07:12:51 -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 o7QEDBpo003825; Thu, 26 Aug 2010 16:13:16 +0200 (CEST) Received: from [192.168.217.101] (p5489F9F2.dip.t-dialin.net [84.137.249.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D7B456858; Thu, 26 Aug 2010 16:13:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 26 Aug 2010 16:13:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E137B96-505D-4FE4-9ADE-00E0BB4E2E10@tzi.org> References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> To: Peter Bigot X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core Subject: Re: [core] #23: Virtual server capability? 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, 26 Aug 2010 14:12:57 -0000 On Aug 26, 2010, at 13:18, Peter Bigot wrote: > First, my constrained devices use a POSIX API, because I want to lower = the barrier to entry for people who need to develop on them by = supporting a familiar and standard interface. One socket per address is = not an acceptable solution. Well, that is not borne out by the facts. The Internet has a small number UDP-based protocols in heavy use, such = as DNS, NTP, DHCP. I haven't done extensive statistics, but one socket per address indeed = appears to be the prevailing implementation strategy. (The main reason is not that RFC 3542 is not widely available, but that = multiple sockets are needed to actually bind each of them to a specific = address instead of blindly receiving everything on every interface.) > Second, do not assume that the vast majority of CoAP implementation = work will be done on constrained devices. =20 I don't know how to count work, but I completely agree that the = availability of CoAP middleware will be a make-or-break influence in the = protocol deployment. So let's, for a moment, work from the assumption that the dominant DNS, = NTP and DHCP implementations have it wrong, and we need to make = destination address detection work on catch-all sockets. A quick non-scientific survey indicates potential issues with = IP_PKTINFO.../RFC 3542 support in: vxworks (no idea) Windows 2000/NT4/9x (fixed in XP, i.e. WinSock 2) Cygwin (could fix it in 1.7, but didn't yet) Solaris (?) Python (fixed with eunuchs library) Java (need to do JNI calls, unaware of a packaged library for that) I was unable to make my way through the .NET documentation thicket, but = I think WSARecvMsg should be available in .NET; it just isn't clear = whether that works right. Java (and possibly .NET) may indeed be the dealkiller here. How quaint. Gruesse, Carsten From cabo@tzi.org Thu Aug 26 07:41: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 57C303A697D for ; Thu, 26 Aug 2010 07:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.06 X-Spam-Level: X-Spam-Status: No, score=-106.06 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 CwaHTqOsUOxW for ; Thu, 26 Aug 2010 07:41:31 -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 143EF3A67ED for ; Thu, 26 Aug 2010 07:41:30 -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 o7QEfnnR012889; Thu, 26 Aug 2010 16:41:54 +0200 (CEST) Received: from [192.168.217.101] (p5489F9F2.dip.t-dialin.net [84.137.249.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 25D626871; Thu, 26 Aug 2010 16:41:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <5F9025D2-3F02-4CB0-AF58-08938F533490@sensinode.com> Date: Thu, 26 Aug 2010 16:41:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.5447f06c446cb40161a608a9b48422f5@tools.ietf.org> <072FFF58-FEE0-49F6-85CC-680BD1F55752@sensinode.com> <5F9025D2-3F02-4CB0-AF58-08938F533490@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: core issue tracker , core Subject: Re: [core] #23: Virtual server capability? 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, 26 Aug 2010 14:41:33 -0000 On Aug 26, 2010, at 16:07, Zach Shelby wrote: >> Now, we could specify a rule that would enable a client to omit the = UriAuthority in a request, like: >> =95 if the UriAuthority option is absent and the remainder of = the URI uniquely identifies a resource the server MAY proceed to execute = the request. If the server requires the authority to identify the = resource it MUST reject the request with "400 Bad Request". >=20 > Works for me. Anyone have problems with text like this? If not I will = use this as the solution for Ticket #23. The only real problem I'm seeing right now is that we are starting to = build a Kernighan's car here*). We *need* to come up with more ways to identify errors than mapping = everything to 400. Otherwise debugging will be a nightmare, and debuggability is an = important element of deployability. Maybe having a convention about the payload of such error responses = would be good enough. But it becomes much worse if we expect client implementations to act = automatically on this error -- then we need something like the 401 = response in HTTP that is a very specific request to send credentials. Once we start to invent status codes HTTP does not have, we need to = decide where to put them in the number space. Officially, of course, we = are free to do as we please, but we want to stay culturally compatible. We could start at 439 and go down, for instance**). (So, the rule for what my client code should do, is: don't send = Uri-Authority, unless a cached previous 4xx from this address indicates = this server wants one? Might work. Not beautiful, but neither is 401.) Note that all this may not suffice to obviate the need for = Uri-Authority-Binary. > Clearly we need some more text on how to interpret the RequestURI in = coap-02, and of course to consider the other implications of URIs with = CoAP (e.g. multicast, asynchronous responses etc.).=20 Yes, please. Gruesse, Carsten *) Brian Kernighan's car: its only instrument is a big question mark on = the dashboard, which lights when something goes wrong. "The experienced driver," Dr Kernighan is quoted as saying, "will know what's wrong." (Common UNIX koan inspired by the fact that early versions of the ed = editor had just one error message, the question mark, which was = justified in just that way.) **) (Because of our single-byte number encoding, only the digits 0 to = 3 are valid in the second position. HTTP goes up to 417, currently; = various standard extensions use 42x; Microsoft appears to use 449/450 = for parental control and such. Hmm, 4xx is crowded. Maybe we should = start 6xx, or give up the nice quadrodecimal number system.)