From beepwg-admin@lists.beepcore.org Tue Nov 6 04:26:37 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04559 for ; Tue, 6 Nov 2001 04:26:36 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA69O7D07873; Tue, 6 Nov 2001 01:24:08 -0800 (PST) Received: from fep5.online.sh.cn ([202.96.209.78]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA69N9D07855 for ; Tue, 6 Nov 2001 01:23:38 -0800 (PST) Received: from cnshans1.acersoftech.com.cn ([202.96.233.98]) by fep5.online.sh.cn (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20011106091914.YZXS26621.fep5.online.sh.cn@cnshans1.acersoftech.com.cn> for ; Tue, 6 Nov 2001 17:19:14 +0800 Received: by cnshans1.acersoftech.com.cn(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 48256AFC.0033E387 ; Tue, 6 Nov 2001 17:26:45 +0800 X-Lotus-FromDomain: ACER From: johnny_xia@wistron.com.cn To: beepwg@lists.beepcore.org Message-ID: <48256AFC.0033E2BD.00@cnshans1.acersoftech.com.cn> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [BEEPwg] The status of beepcore-c library. Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 6 Nov 2001 17:26:22 +0800 Hi All, I have just downloaded a copy of beepcore-c library. And I want to use it in our product. What is the status of this library? Is it reliable enough? Where can I get more information about the library? Where can I attend the discussion of the library? Thanks in advance. Regards, Johnny Xia. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 6 11:35:45 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20437 for ; Tue, 6 Nov 2001 11:35:44 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA6GY3D21055; Tue, 6 Nov 2001 08:34:03 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA6GXGD21043 for ; Tue, 6 Nov 2001 08:33:16 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fA6GW0f03900; Tue, 6 Nov 2001 08:32:01 -0800 (PST) Message-ID: <062001c166e0$8c2b4d00$fe0aa840@FATORA> From: "Marshall T. Rose" To: , Cc: "Marshall Rose" References: <48256AFC.0033E2BD.00@cnshans1.acersoftech.com.cn> Subject: Re: [BEEPwg] The status of beepcore-c library. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 6 Nov 2001 08:31:54 -0800 Content-Transfer-Encoding: 7bit > I have just downloaded a copy of beepcore-c library. And I want to use it in our > product. What is the status of this library? Is it reliable enough? Where can I > get more information about the library? i suppose the simple answer is to look at the index page for the project that includes things like "Status:" however, if you'd like a more detailed answer: the API has undergone a major revision and is in the process of being tested. so, i'd wait three weeks. > Wh ere can I attend the discussion of the library? try https://lists.sourceforge.net/lists/listinfo/beepcore-c-users /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 6 11:58:29 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21398 for ; Tue, 6 Nov 2001 11:58:28 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA6Gw2D23721; Tue, 6 Nov 2001 08:58:02 -0800 (PST) Received: from mail.franklin.ro (cpe-66-1-176-103.ut.sprintbbd.net [66.1.176.103]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id fA6GvDD23709 for ; Tue, 6 Nov 2001 08:57:13 -0800 (PST) Received: (qmail 7560 invoked from network); 6 Nov 2001 16:57:04 -0000 Received: from clyde.franklin.ro (HELO clyde) (trilluser@10.0.0.1) by local-bob.franklin.ro with SMTP; 6 Nov 2001 16:57:04 -0000 Message-ID: <010501c166e4$08144f90$0d00000a@clyde> From: "Huston" To: , References: <48256AFC.0033E2BD.00@cnshans1.acersoftech.com.cn> Subject: Re: [BEEPwg] The status of beepcore-c library. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 6 Nov 2001 09:56:51 -0700 Content-Transfer-Encoding: 7bit > I have just downloaded a copy of beepcore-c library. And I want to use it in our > product. What is the status of this library? Is it reliable enough? Where can I > get more information about the library? Where can I attend the discussion of the > library? The code in cvs is approaching beta quality. The beta release should be out in 3-4 weeks. Discussions about the library are typically held on the sourceforge mailing list (beepcore-c-users). --Huston _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 6 13:29:37 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25918 for ; Tue, 6 Nov 2001 13:29:36 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA6IT2D03009; Tue, 6 Nov 2001 10:29:03 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id fA6ISYD02997 for ; Tue, 6 Nov 2001 10:28:35 -0800 (PST) Received: (qmail 47596 invoked by uid 3039); 6 Nov 2001 18:28:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Nov 2001 18:28:44 -0000 From: Gabe Wachob X-Sender: To: Huston cc: , Subject: Re: [BEEPwg] The status of beepcore-c library. In-Reply-To: <010501c166e4$08144f90$0d00000a@clyde> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 6 Nov 2001 10:28:44 -0800 (PST) Also, if you prefer live chat, some beepniks can be found on #beepnik on irc.openprojects.net -Gabe _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Nov 7 19:32:00 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27122 for ; Wed, 7 Nov 2001 19:32:00 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA80SjD00715; Wed, 7 Nov 2001 16:28:45 -0800 (PST) Received: from mail2.registeredsite.com (mail2.registeredsite.com [64.224.9.11]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA80OFD00675 for ; Wed, 7 Nov 2001 16:24:15 -0800 (PST) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail2.registeredsite.com (8.11.6/8.11.4) with ESMTP id fA7NUSa01582 for ; Wed, 7 Nov 2001 18:30:28 -0500 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A0C64264002C; Wed, 07 Nov 2001 19:24:38 -0500 From: "Eamon O'Tuathail" To: Message-ID: <000101c167eb$c0ef7aa0$56c8fea9@central> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000 Subject: [BEEPwg] ANN: BEEP for .NET/C# - beta testing Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 8 Nov 2001 00:24:37 -0000 Content-Transfer-Encoding: 7bit Hi all, Clipcode is pleased to announce the beta of its new peer networking product, Clipcode.Peer, which provides an implementation of BEEP for Microsoft .NET/C#. See http://www.clipcode.com/peer/ for details. Those of you with Visual Studio.NET (beta 2) who would like to take Clipcode.Peer for a spin, please register for the beta program at: http://www.clipcode.com/beta_registration.htm Thanks, Eamon O'Tuathail Clipcode.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Nov 7 19:32:33 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27155 for ; Wed, 7 Nov 2001 19:32:33 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA80P5D00690; Wed, 7 Nov 2001 16:25:05 -0800 (PST) Received: from mail2.registeredsite.com (mail2.registeredsite.com [64.224.9.11]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fA80O5D00670 for ; Wed, 7 Nov 2001 16:24:11 -0800 (PST) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail2.registeredsite.com (8.11.6/8.11.4) with ESMTP id fA7NUGa01429 for ; Wed, 7 Nov 2001 18:30:17 -0500 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A0B04261002C; Wed, 07 Nov 2001 19:24:16 -0500 From: "Eamon O'Tuathail" To: Message-ID: <000001c167eb$b3e80f70$56c8fea9@central> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000 Subject: [BEEPwg] Article available providing a high level introduction to BEEP Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 8 Nov 2001 00:24:15 -0000 Content-Transfer-Encoding: 7bit There is an article at: http://www.clipcode.com/peer/beep_technical_whitepaper.htm that provides an overview of BEEP. It might be of interest to those new to BEEP seeking a high-level introduction to the spec. Enjoy, Eamon O'Tuathail Clipcode.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Nov 19 15:45:23 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24014 for ; Mon, 19 Nov 2001 15:45:22 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAJKg5x11562; Mon, 19 Nov 2001 12:42:05 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAJKfVx11550 for ; Mon, 19 Nov 2001 12:41:32 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id BA65613A48; Mon, 19 Nov 2001 15:43:03 -0500 (EST) To: Cc: protocol@permabit.com From: Jered Floyd Message-ID: <874rnqpk4o.fsf@questionably-configured.permabit.com> Lines: 78 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BEEPwg] Trouble with TLS and transport mappings Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 19 Nov 2001 15:43:03 -0500 Greetings, I have encountered another (somewhat obscure) case in RFC 3080 where I am unsure what the proper behaviour is for a BEEP library; or rather, I am sure what the proper behaviour is, and also sure that it would lead to deadlock. RFC 3080, Section 3.1.3.1 states: When a BEEP peer sends the "ready" element, it MUST NOT send any further traffic on the underlying transport service until a corresponding reply ("proceed" or "error") is received; ... [emphasis mine] This clearly includes SEQ frames, and must do so to ensure the connection streams are in a consistent state when the underlying negotiation process begins. If the peer that sends the "ready" element cannot send SEQ frames for the channel upon which it expects a reply (zero in the case of a piggybacked request, some other channel in the case of a started channel) it is not always possible for the remote peer to send its response. If the response to be sent exceeds the channel window size, the peer that sent the "ready" element has no way to indicate to the responding peer that more space is available after it partially processes the response, as it is unable to send SEQ frames. This cannot be fixed by allowing SEQ frames until the last frame of the response is received; the peer has know way of knowing if the last frame is already 'on the wire' when it sends a SEQ, and thus could send a SEQ after the remote peer believes that the next bytes to be received should correspond to the underlying negotiation process. An example of a TLS negotation attempt that must result in deadlock under the current guidelines: C: MSG 0 1 . 52 158 C: Content-Type: application/beep+xml C: C: C: C: ]]> C: C: C: END S: RPY 0 1 * 110 4096 S: Content-Type: application/beep+xml S: S: S: This is a very long error response S: that is still within the 4K limit for an initialization S: message embedded in a "start" transaction, but brings S: the channel zero message size to above the size of S: the channel zero TCP mapping window [more data here S: to reach 4K within this frame...] S: END (A successful negotation request for TLS that results in deadlock would be extremely contrived, but this may not be the case for other profiles that implement transport level security.) It is insufficient to limit the full channel zero response to a tuning request to less than 4K, as there's no reason in RFC 3081 for the peer to necessarily have advertised that it has a completely empty window (thus at least 4K). The only solution I have come up with is to declare at the transport level that channels implementing a tuning profile disregard the window mechanism; the sending peer may send data at any time and the recipient must be prepared to accept it. I don't find this solution particularly pleasing. Does anyone have a better counter-proposal? --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Nov 19 21:13:06 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06819 for ; Mon, 19 Nov 2001 21:13:06 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAJNO2x12394; Mon, 19 Nov 2001 15:24:02 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAJNNXx12377 for ; Mon, 19 Nov 2001 15:23:33 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fAJNNWf29052; Mon, 19 Nov 2001 15:23:32 -0800 (PST) Message-ID: <086401c17151$5d2107e0$fe0aa840@FATORA> From: "Marshall T. Rose" To: , "Jered Floyd" Cc: , "Marshall Rose" References: <874rnqpk4o.fsf@questionably-configured.permabit.com> Subject: Re: [BEEPwg] Trouble with TLS and transport mappings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Mon, 19 Nov 2001 15:24:40 -0800 Content-Transfer-Encoding: 7bit > The only solution I have come up with is to declare at the transport > level that channels implementing a tuning profile disregard the window > mechanism; the sending peer may send data at any time and the > recipient must be prepared to accept it. I don't find this solution > particularly pleasing. doesn't this fall under the category that people doing stupid things deserve what they get? > Does anyone have a better counter-proposal? it seems to me that it's worthwhile to note in the discussion on processing the "" element, that the window isn't going to get updated and that when a reply is generated it must fit within the window advertised... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 20 16:25:49 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06705 for ; Tue, 20 Nov 2001 16:25:49 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKLN5x15264; Tue, 20 Nov 2001 13:23:05 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKLMMx15252 for ; Tue, 20 Nov 2001 13:22:23 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 3EA4A142CF; Tue, 20 Nov 2001 16:24:07 -0500 (EST) To: "Marshall T. Rose" Cc: , , "Marshall Rose" Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> From: Jered Floyd In-Reply-To: <086401c17151$5d2107e0$fe0aa840@FATORA> Message-ID: <87r8qtnnk8.fsf@questionably-configured.permabit.com> Lines: 60 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 20 Nov 2001 16:24:07 -0500 "Marshall T. Rose" writes: > doesn't this fall under the category that people doing stupid things > deserve what they get? I'm not sure I follow. I agree that the example I gave was rather contrived, but only because I was trying to demonstrate the issue with minimal setup. > it seems to me that it's worthwhile to note in the discussion on processing > the "" element, that the window isn't going to get updated and that > when a reply is generated it must fit within the window advertised... Because a peer must process any pending replies before a element may be returned, and some of these replies may be on the same channel that the is to be returned upon, the window size could be arbitrarily small; in fact, the advertised window could be full even before the response to the is generated. In the case of a connection that is significantly active before tls negotiation occurs, I believe that in some cases there is nothing that the peer can do to avoid deadlock. Anyway, while that sits I have some slightly less pedantic tls-related questions: 1) Once transport layer security of any kind has been negotiated, may a different tls negotiation occur? Section 4.1 makes it clear that this is *not* allowed with SASL profiles ("Once transport security is successfully negotiated for a BEEP session, then a SASL security layer must not be negotiated; similarly, once any SASL negotiation is successful, a transport security profile must not begin its underlying negotiation process"), but RFC 3080 isn't clear on tls in general. 2) Re: TLS, Section 3.1.3.1 says: When a BEEP peer sends the "ready" element, it must not send any further traffic on the underlying transport service until a corresponding reply ("proceed" or "error") is received; similarly, the receiving BEEP peer must wait until any pending replies have been generated and sent before it processes a "ready" element. Consider the case in which several frames (but on the final frame) of a request have been sent on channel 1, and the same peer wishes to request TLS in a piggybacked message on channel 0. Should this be interpreted to mean: a) A BEEP peer must not sent a "ready" element until there are no partially-sent messages on any channel, or b) A BEEP peer should not consider partially-received messages to be pending replies? I greatly prefer the former interpretation, but I'm not sure this is correct. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 20 16:56:03 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07911 for ; Tue, 20 Nov 2001 16:56:02 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKLs1x15428; Tue, 20 Nov 2001 13:54:01 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKLrTx15416 for ; Tue, 20 Nov 2001 13:53:29 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 827FE142EA; Tue, 20 Nov 2001 16:55:17 -0500 (EST) To: "Marshall T. Rose" Cc: , , "Marshall Rose" Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> From: Jered Floyd In-Reply-To: <87r8qtnnk8.fsf@questionably-configured.permabit.com> Message-ID: <87n11hnm4a.fsf@questionably-configured.permabit.com> Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 20 Nov 2001 16:55:17 -0500 > Consider the case in which several frames (but on the final frame) > of a request have been sent on channel 1, and the same peer wishes > to request TLS in a piggybacked message on channel 0. Should this > be interpreted to mean: > > a) A BEEP peer must not sent a "ready" element until there are > no partially-sent messages on any channel, or > > b) A BEEP peer should not consider partially-received messages > to be pending replies? > > I greatly prefer the former interpretation, but I'm not sure this > is correct. Err; strike that; I greatly prefer the latter interpretation because the former is quite obnoxious to implement, but I can't find strong support for either interpretation. --jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 20 17:53:00 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09871 for ; Tue, 20 Nov 2001 17:53:00 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKMp3x15736; Tue, 20 Nov 2001 14:51:03 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKMoOx15724 for ; Tue, 20 Nov 2001 14:50:24 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fAKMoMf03385; Tue, 20 Nov 2001 14:50:22 -0800 (PST) Message-ID: <0bfc01c17215$e828c430$fe0aa840@FATORA> From: "Marshall T. Rose" To: "Jered Floyd" Cc: , , "Marshall Rose" References: <874rnqpk4o.fsf@questionably-configured.permabit.com><086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> Subject: Re: [BEEPwg] Trouble with TLS and transport mappings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 20 Nov 2001 14:51:34 -0800 Content-Transfer-Encoding: 7bit maybe i'm missing the big picture here, but i don't understand why this small problem requires a big solution. anyone who sends a 4K+ "error" or "proceed" element has big problems. so, i return to my suggestion that we add a sentence to the paragraph that talks about the processing of the "ready" element that reminds implementors that folks who try to use the "error" element as some kind of covert bulk transfer facility are going to lose big... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 20 17:55:55 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09927 for ; Tue, 20 Nov 2001 17:55:54 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKMs2x15766; Tue, 20 Nov 2001 14:54:02 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAKMrux15754 for ; Tue, 20 Nov 2001 14:53:56 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fAKMrtf03403; Tue, 20 Nov 2001 14:53:55 -0800 (PST) Message-ID: <0c1201c17216$6701e930$fe0aa840@FATORA> From: "Marshall T. Rose" To: "Jered Floyd" Cc: , , "Marshall Rose" References: <874rnqpk4o.fsf@questionably-configured.permabit.com><086401c17151$5d2107e0$fe0aa840@FATORA><87r8qtnnk8.fsf@questionably-configured.permabit.com> <87n11hnm4a.fsf@questionably-configured.permabit.com> Subject: Re: [BEEPwg] Trouble with TLS and transport mappings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 20 Nov 2001 14:55:08 -0800 Content-Transfer-Encoding: 7bit i don't think beep has enough in it to solve the byzantine generals' problem. so, i think it wise that implementations try to avoid the problem altogether. for example, you shouldn't start the TLS profile if you have something outstanding. this applies both to the peer who sends the start and the peer who receives the start. similarly, once a TLS channel is started, each peer shouldn't allow other channels to be started or to send traffic. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Nov 21 15:27:39 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04279 for ; Wed, 21 Nov 2001 15:27:39 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fALKP5x22822; Wed, 21 Nov 2001 12:25:05 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fALKO7x22807 for ; Wed, 21 Nov 2001 12:24:07 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 7D8D813A41; Wed, 21 Nov 2001 15:26:00 -0500 (EST) To: "Marshall T. Rose" Cc: , , "Marshall Rose" Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> <87n11hnm4a.fsf@questionably-configured.permabit.com> <0c1201c17216$6701e930$fe0aa840@FATORA> From: Jered Floyd In-Reply-To: <0c1201c17216$6701e930$fe0aa840@FATORA> Message-ID: <87y9kzvpk7.fsf@questionably-configured.permabit.com> Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 21 Nov 2001 15:26:00 -0500 > i don't think beep has enough in it to solve the byzantine generals' > problem. I agree entirely. But I believe that it is our responsibility in defining a standard to avoid issues that are open to interpretation, or that allow applications to get into untenable states. Either the definition of BEEP should be expanded to address issues that could affect implementation interoperability, or (much preferably) BEEP should be restricted so that the situation cannot occur. I believe that my most recent concern is addressed by the following change in Section 3.1.3.1: [...]; similarly, the receiving BEEP peer must wait until any pending replies have been generated and sent before it processes a "ready" element. changes to: [...]; similarly, the receiving BEEP peer may wait until any pending replies to messages that have been fully received have been generated and sent before it processes a "ready" element. In any case, the specification should document recommendations to implementors on how to be good network citizens. This is also why I previously brought up the lack of recommendation to avoid sending many small frames (as appears in TCP). Yes, I am being obtuse. Yes, I am being pedantic. But BEEP is a standards track RFC, and I'd like to see it become a standard. I'll be out of contact for the remainer of the week and early next. To the US participants of this list, happy thanksgiving! --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Nov 21 18:35:38 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13430 for ; Wed, 21 Nov 2001 18:35:37 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fALNX7x23767; Wed, 21 Nov 2001 15:33:07 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fALNWBx23755 for ; Wed, 21 Nov 2001 15:32:11 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fALNWAf07703; Wed, 21 Nov 2001 15:32:10 -0800 (PST) Message-ID: <013901c172e4$f171edd0$fe0aa840@FATORA> From: "Marshall T. Rose" To: "Jered Floyd" Cc: , , "Marshall Rose" References: <874rnqpk4o.fsf@questionably-configured.permabit.com><086401c17151$5d2107e0$fe0aa840@FATORA><87r8qtnnk8.fsf@questionably-configured.permabit.com><87n11hnm4a.fsf@questionably-configured.permabit.com><0c1201c17216$6701e930$fe0aa840@FATORA> <87y9kzvpk7.fsf@questionably-configured.permabit.com> Subject: Re: [BEEPwg] Trouble with TLS and transport mappings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Wed, 21 Nov 2001 15:33:36 -0800 Content-Transfer-Encoding: 7bit > I believe that my most recent concern is addressed by the > following change in Section 3.1.3.1: > > [...]; similarly, the receiving BEEP peer must wait until any > pending replies have been generated and sent before it processes > a "ready" element. > > changes to: > > [...]; similarly, the receiving BEEP peer may wait until any > pending replies to messages that have been fully received > have been generated and sent before it processes a "ready" > element. this would work, although you probably meant to say "must" instead of "may". thanks, /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 27 11:34:41 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08029 for ; Tue, 27 Nov 2001 11:34:39 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fARGV8x06924; Tue, 27 Nov 2001 08:31:08 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fARGUHx06912 for ; Tue, 27 Nov 2001 08:30:18 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 1DD6E13DEF; Tue, 27 Nov 2001 11:32:39 -0500 (EST) To: "Marshall T. Rose" Cc: , , "Marshall Rose" Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> <87n11hnm4a.fsf@questionably-configured.permabit.com> <0c1201c17216$6701e930$fe0aa840@FATORA> <87y9kzvpk7.fsf@questionably-configured.permabit.com> <013901c172e4$f171edd0$fe0aa840@FATORA> From: Jered Floyd In-Reply-To: <013901c172e4$f171edd0$fe0aa840@FATORA> Message-ID: <87n118p42g.fsf@questionably-configured.permabit.com> Lines: 66 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 27 Nov 2001 11:32:39 -0500 > this would work, although you probably meant to say "must" instead > of "may". Great; works for me. What's the next step? Do we just note this and remember it for when a specification revision occurs? Something I mentioned 2 messages ago but didn't see an opinion on: Once transport layer security of any kind has been negotiated, may a different tls negotiation occur? Section 4.1 makes it clear that the BEEP SASL profile (as opposed to the SASL BEEP profiles, argh) explicitly does not permit multiple successful SASL negotiations. Other (non-SASL) tls negotations are outside the scope of this, though. It would be consistent with the choice made in Section 4.1 to add after the fist paragraph of section 3 the following: "Only one successful transport security negotiation may occur in a protocol session." Would you be amenable to this? The other option would be to explicitly allow multiple tls negotations. To be consistent with RFC 2222 (SASL) Section 5.3, only one security layer may be in effect; if a subsequent negotiation selects a second security layer, then the second security layer replaces the first. If this is preferred, then Section 4.1 of RFC 3080 should be changed to explicitly allow multiple SASL negotiations. I can think of no reason to support this beyond paranoia; i.e. wishing to obscure a high-security tls negotiation within a weakly-secured connection. Finally, while we're squashing issues, I'll bring up two options for resolving my previous concern regarding the character set of base64 encoded initialization messages. 1) If backwards-compatibility is not a concern: Errata against RFC 3080: the 'encoding' attribute is depricated. Initialization messages as described in Section 2.3.1.2 are precisely BEEP Messages, as defined in Section 2.2. A "Content-Transfer-Encoding" may be specified to protect content. Additionally, the default "Content-Type" could be "application/beep+xml", which would maintain compatibility with existing beep+xml profiles (such as TLS and SASL profiles). (This would only add an additional newline to the head of the initialization message.) 2) If backwards compatibility is a concern: The 'base64' value for the 'encoding' attribute should not be used. The 'encoding' attribute may take the value 'msg', in which case the content is interpreted as a BEEP Message, as described in option 1 above. Support for this is indicated via a feature in the greeting. Which is the better solution? --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Nov 27 13:43:03 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16715 for ; Tue, 27 Nov 2001 13:43:03 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fARIe3x07549; Tue, 27 Nov 2001 10:40:03 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fARIdix07531 for ; Tue, 27 Nov 2001 10:39:44 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fARIdZf02787; Tue, 27 Nov 2001 10:39:35 -0800 (PST) Message-ID: <00a001c17773$20fb5090$fe0aa840@FATORA> From: "Marshall T. Rose" To: "Jered Floyd" Cc: , , "Marshall Rose" References: <874rnqpk4o.fsf@questionably-configured.permabit.com><086401c17151$5d2107e0$fe0aa840@FATORA><87r8qtnnk8.fsf@questionably-configured.permabit.com><87n11hnm4a.fsf@questionably-configured.permabit.com><0c1201c17216$6701e930$fe0aa840@FATORA><87y9kzvpk7.fsf@questionably-configured.permabit.com><013901c172e4$f171edd0$fe0aa840@FATORA> <87n118p42g.fsf@questionably-configured.permabit.com> Subject: Re: [BEEPwg] Trouble with TLS and transport mappings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Nov 2001 10:41:29 -0800 Content-Transfer-Encoding: 7bit > Great; works for me. What's the next step? Do we just note this and > remember it for when a specification revision occurs? presumably, at some time in the future, the wg will reactivate and look at what changes and errata need to be me made. > It would be consistent with the choice made in Section 4.1 to add > after the fist paragraph of section 3 the following: > > "Only one successful transport security negotiation may occur > in a protocol session." that sounds fine. > Finally, while we're squashing issues, I'll bring up two options for > resolving my previous concern regarding the character set of base64 > encoded initialization messages. i think i'd rather think on this for a while, since there's no particular rush to resolve it until the wg reactivates. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Nov 28 13:37:56 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28612 for ; Wed, 28 Nov 2001 13:37:55 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fASIW4x04902; Wed, 28 Nov 2001 10:32:04 -0800 (PST) Received: from smtp1.san.rr.com (smtp1.san.rr.com [24.25.195.37]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fASIVbx04890 for ; Wed, 28 Nov 2001 10:31:37 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp1.san.rr.com (8.11.4/8.11.4) with ESMTP id fASIYEB22593 for ; Wed, 28 Nov 2001 10:34:14 -0800 (PST) Message-ID: <3C052E2E.9C42ECD6@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Wed, 28 Nov 2001 10:34:22 -0800 Content-Transfer-Encoding: 7bit Jered Floyd wrote: > > "Marshall T. Rose" writes: > > > doesn't this fall under the category that people doing stupid things > > deserve what they get? > > I'm not sure I follow. I agree that the example I gave was rather > contrived, but only because I was trying to demonstrate the issue > with minimal setup. We call this a "Doctor Doctor!" error. "Doctor, Doctor, it hurts when I do this!" > > it seems to me that it's worthwhile to note in the discussion on processing > > the "" element, that the window isn't going to get updated and that > > when a reply is generated it must fit within the window advertised... > > Because a peer must process any pending replies before a > element may be returned, and some of these replies may be on the same > channel that the is to be returned upon, the window size > could be arbitrarily small; in fact, the advertised window could be > full even before the response to the is generated. In the > case of a connection that is significantly active before tls > negotiation occurs, I believe that in some cases there is nothing that > the peer can do to avoid deadlock. Well, what the sender of the has to do is to avoid that situation. Hence, in our implementations (or at least the one's I've looked at closely), the profile implementations are told that a tuning reset is about to start, they all stop processing outgoing messages (just as if channel 0 was closing), and then finally the SEQ for the channel carrying the is sent to fully open the window, then the is sent. Only the channel on which the is sent is processed until either the error or the comes back. Yes, it's kind of a pain in the butt. If you start a tuning reset while the other side is half way thru sending a MSG, you're going to lose something, but both sides will know what happened. > 2) Re: TLS, Section 3.1.3.1 says: > When a BEEP peer sends the "ready" element, it must not send any > further traffic on the underlying transport service until a > corresponding reply ("proceed" or "error") is received; > similarly, the receiving BEEP peer must wait until any pending > replies have been generated and sent before it processes a > "ready" element. > > Consider the case in which several frames (but on the final frame) > of a request have been sent on channel 1, and the same peer wishes > to request TLS in a piggybacked message on channel 0. Should this > be interpreted to mean: > > a) A BEEP peer must not sent a "ready" element until there are > no partially-sent messages on any channel, or > > b) A BEEP peer should not consider partially-received messages > to be pending replies? > > I greatly prefer the former interpretation, but I'm not sure this > is correct. I've been interpreting it as (a). That is, the doesn't get sent until all the channels with outgoing frames have had them sent and responses to all of those have been received. If the remote side has MSGs to send and it receives a , it has the choice of either telling the profiles that their MSGs have been lost due to a tuning reset, or rejecting the with an . In summary, this is the way the beepcore-C team worked out what must happen: Without loss of generality, assume it's the initiator that wants to tuning-reset. The initiator's TLS profile informs all open initiator-side profiles that a tuning reset is starting, and gets permission. It then waits until all outgoing MSGs have been sent and answered. Initiator-side profiles have to stop sending MSGs just as if channel 0 was being closed (which it is, basically). Then the SEQ for the channel being tuned (0 if piggybacked) is sent, and then the is sent. No other channels are processed until the response to the is returned. Since they're not being processed, they don't send SEQs. The listener side gets the , asks all the listener-side profiles whether they're happy to be tuning-reset, and if so, sends the , then tosses any buffered data and generally "does" the reset. If a listener-side profile says it doesn't want to reset, then an is sent back. On the initiator side, an rolls back the tuning reset request and everyone's free to process again, while a starts the tuning process. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. You will soon read a generic fortune cookie. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 02:47:46 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27365 for ; Fri, 30 Nov 2001 02:47:45 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAU7iCx24435; Thu, 29 Nov 2001 23:44:12 -0800 (PST) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAU7hrx24423 for ; Thu, 29 Nov 2001 23:43:57 -0800 (PST) Received: from firstrain.com ([203.196.132.235]) by monsoon.us.ny.firstrain.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 30 Nov 2001 02:47:09 -0500 Message-ID: <3C07E21F.59CF23D2@firstrain.com> From: Alok Gupta X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: multipart/alternative; boundary="------------384A59D97C2016730601606A" X-OriginalArrivalTime: 30 Nov 2001 07:47:10.0140 (UTC) FILETIME=[37706FC0:01C17973] Subject: [BEEPwg] Query related with message ordering on a channel. Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Sat, 01 Dec 2001 01:16:39 +0530 --------------384A59D97C2016730601606A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a query related with the ordering of the replies on a channel in a BEEP session. The RFC 3080 says that on a channel, the messages MUST be processed in the same order as they were received and then the replies to those messages MUST be generated in the same order. My question is that the processing time for all the message will not be same so why hold the replies for the messages which have been processed before the reply is ready for the previously received messages. Please refer to the RFC 3080 in the following sections: Section 2.6.1 "...........A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received. As a consequence, the BEEP peer must generate replies in the same order as the corresponding "MSG" messages are received on a given channel......... " Section 2.6.1 "............A BEEP peer acting in the server role may process "MSG" messages received on different channels in any order it chooses. As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding "MSG" messages are received, there is no ordering constraint for replies on different channels..........." Either I have not followed the point properly or this is an unnecessary requirement from the BEEP protocol. Could anybody explain this? Thanks, Alok Gupta. --------------384A59D97C2016730601606A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I have a query related with the ordering of the replies on a channel in a BEEP session.

The RFC 3080 says that on a channel, the messages MUST be processed in the same order as they were received and then the replies to those messages MUST be generated in the same order. My question is that the processing time for all the  message will not be same so why hold the replies for the messages which have been processed before the reply is ready for the previously received messages.

Please refer to the  RFC 3080 in the following sections:
Section 2.6.1

"...........A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received.  As a consequence, the BEEP peer must generate replies in the same order as the corresponding "MSG" messages are received on a given channel......... "
Section 2.6.1
"............A BEEP peer acting in the server role may process "MSG" messages received on different channels in any order it chooses.  As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding "MSG" messages are received, there is no ordering constraint for replies on different channels..........."


Either I have not followed the point properly or this is an unnecessary requirement from the BEEP protocol.

Could anybody explain this?

Thanks,
Alok Gupta.
 
  --------------384A59D97C2016730601606A-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 10:06:04 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14583 for ; Fri, 30 Nov 2001 10:06:03 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUF23x27178; Fri, 30 Nov 2001 07:02:03 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUF18x27166 for ; Fri, 30 Nov 2001 07:01:08 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA10080; Fri, 30 Nov 2001 10:03:11 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26114; Fri, 30 Nov 2001 10:02:55 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA01075; Fri, 30 Nov 2001 10:02:51 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id KAA01403; Fri, 30 Nov 2001 10:02:50 -0500 Subject: Re: [BEEPwg] Query related with message ordering on a channel. From: Greg Hudson To: Alok Gupta Cc: beepwg@lists.beepcore.org In-Reply-To: <3C07E21F.59CF23D2@firstrain.com> References: <3C07E21F.59CF23D2@firstrain.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Message-Id: <1007132570.1286.0.camel@error-messages.mit.edu> Mime-Version: 1.0 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Nov 2001 10:02:50 -0500 Content-Transfer-Encoding: 7bit On Fri, 2001-11-30 at 14:46, Alok Gupta wrote: > The RFC 3080 says that on a channel, the messages MUST be processed in > the same order as they were received and then the replies to those > messages MUST be generated in the same order. My question is that the > processing time for all the message will not be same so why hold the > replies for the messages which have been processed before the reply is > ready for the previously received messages. It simplifies the implementation of some application protocols if you can assume that replies will be received in the order that requests are sent. That is why BEEP requires that replies be synchronous within a channel. If you have some unrelated requests and want to be able to receive replies for them in any order, send them on different channels. (And yes, this means BEEP isn't necessarily a good fit for a protocol where all requests are independent of each other and where it's important not to let one slow request hold up feedback on any other request. For such a protocol, you'd have to manage a pool of channels and create a new one each time you have a request to send and no free channel in the pool; that's a lot of bookkeeping.) _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 10:49:59 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16852 for ; Fri, 30 Nov 2001 10:49:59 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUFl2x27407; Fri, 30 Nov 2001 07:47:02 -0800 (PST) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUFk3x27395 for ; Fri, 30 Nov 2001 07:46:03 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id fAUFmqw22337 for ; Fri, 30 Nov 2001 07:48:52 -0800 (PST) Message-ID: <3C07AA6D.B81ADCC1@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Query related with message ordering on a channel. References: <3C07E21F.59CF23D2@firstrain.com> <1007132570.1286.0.camel@error-messages.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 30 Nov 2001 07:49:01 -0800 Content-Transfer-Encoding: 7bit Greg Hudson wrote: > It simplifies the implementation of some application protocols if you > can assume that replies will be received in the order that requests are > sent. Also, the profile should behave as if each request is processed in full before the next one is examined. I.e., a request to search a database followed by one to delete records in that database should not delete anything before the search is complete. Of course, if you have independent operations, it's possible to implement such things in a more efficient way, but that's the intent. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. You will soon read a generic fortune cookie. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 13:39:13 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26931 for ; Fri, 30 Nov 2001 13:39:13 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUIa3x28299; Fri, 30 Nov 2001 10:36:03 -0800 (PST) Received: from mail.franklin.ro (cpe-66-1-176-103.ut.sprintbbd.net [66.1.176.103]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id fAUH70x27826 for ; Fri, 30 Nov 2001 09:07:01 -0800 (PST) Received: (qmail 31194 invoked from network); 30 Nov 2001 17:09:29 -0000 Received: from clyde.franklin.ro (HELO clyde) (trilluser@10.0.0.1) by local-bob.franklin.ro with SMTP; 30 Nov 2001 17:09:29 -0000 Message-ID: <08b801c179c1$964703d0$0100000a@clyde> From: "Huston" To: "Greg Hudson" , "Alok Gupta" Cc: References: <3C07E21F.59CF23D2@firstrain.com> <1007132570.1286.0.camel@error-messages.mit.edu> Subject: Re: [BEEPwg] Query related with message ordering on a channel. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 30 Nov 2001 10:08:09 -0700 Content-Transfer-Encoding: 7bit > (And yes, this means BEEP isn't necessarily a good fit for a protocol > where all requests are independent of each other and where it's > important not to let one slow request hold up feedback on any other > request. For such a protocol, you'd have to manage a pool of channels > and create a new one each time you have a request to send and no free > channel in the pool; that's a lot of bookkeeping.) Greg is right but it can be made to work without too much pain. beepcore-java has a facility (ChannelPool and SharedChannel) to do channel pooling for you, they were designed for just such a purpose. If you are not using beepcore-java it can at least serve as an example. --Huston _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 13:41:06 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27055 for ; Fri, 30 Nov 2001 13:41:05 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUIc9x28328; Fri, 30 Nov 2001 10:38:09 -0800 (PST) Received: from mail.franklin.ro (cpe-66-1-176-103.ut.sprintbbd.net [66.1.176.103]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id fAUHDtx27878 for ; Fri, 30 Nov 2001 09:13:55 -0800 (PST) Received: (qmail 31235 invoked from network); 30 Nov 2001 17:16:40 -0000 Received: from clyde.franklin.ro (HELO clyde) (trilluser@10.0.0.1) by local-bob.franklin.ro with SMTP; 30 Nov 2001 17:16:40 -0000 Message-ID: <08c001c179c2$96edaea0$0100000a@clyde> From: "Huston" To: "Jered Floyd" Cc: References: <874rnqpk4o.fsf@questionably-configured.permabit.com><086401c17151$5d2107e0$fe0aa840@FATORA><87r8qtnnk8.fsf@questionably-configured.permabit.com><87n11hnm4a.fsf@questionably-configured.permabit.com><0c1201c17216$6701e930$fe0aa840@FATORA><87y9kzvpk7.fsf@questionably-configured.permabit.com><013901c172e4$f171edd0$fe0aa840@FATORA> <87n118p42g.fsf@questionably-configured.permabit.com> Subject: Re: [BEEPwg] Trouble with TLS and transport mappings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 30 Nov 2001 10:15:20 -0700 Content-Transfer-Encoding: 7bit > 1) If backwards-compatibility is not a concern: > > Errata against RFC 3080: the 'encoding' attribute is depricated. > Initialization messages as described in Section 2.3.1.2 are precisely > BEEP Messages, as defined in Section 2.2. A > "Content-Transfer-Encoding" may be specified to protect content. > > Additionally, the default "Content-Type" could be > "application/beep+xml", which would maintain compatibility with > existing beep+xml profiles (such as TLS and SASL profiles). (This > would only add an additional newline to the head of the initialization > message.) If backwards-compatibility is not a concern, my vote is to make it consistent with all other messages including the default "Content-Type". This way beep libraries don't have to do anything special with the piggyback'd data and to profiles the piggyback'd data will look just the same as if it had been sent in the first MSG. --Huston _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 14:09:04 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28897 for ; Fri, 30 Nov 2001 14:09:01 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUJ63x28497; Fri, 30 Nov 2001 11:06:03 -0800 (PST) Received: from smtp1.san.rr.com (smtp1.san.rr.com [24.25.195.37]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUJ5Hx28485 for ; Fri, 30 Nov 2001 11:05:17 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp1.san.rr.com (8.11.4/8.11.4) with ESMTP id fAUJ87B04068 for ; Fri, 30 Nov 2001 11:08:07 -0800 (PST) Message-ID: <3C07D920.81070A14@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com><086401c17151$5d2107e0$fe0aa840@FATORA><87r8qtnnk8.fsf@questionably-configured.permabit.com><87n11hnm4a.fsf@questionably-configured.permabit.com><0c1201c17216$6701e930$fe0aa840@FATORA><87y9kzvpk7.fsf@questionably-configured.permabit.com><013901c172e4$f171edd0$fe0aa840@FATORA> <87n118p42g.fsf@questionably-configured.permabit.com> <08c001c179c2$96edaea0$0100000a@clyde> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 30 Nov 2001 11:08:16 -0800 Content-Transfer-Encoding: 7bit > If backwards-compatibility is not a concern, my vote is to make it > consistent with all other messages including the default "Content-Type". > This way beep libraries don't have to do anything special with the > piggyback'd data and to profiles the piggyback'd data will look just the > same as if it had been sent in the first MSG. If backwards compatibility (with profile specifications) is a concern, one could add an encoding value that means it's MIME-encoded all the way. I.e., <... encoding="mime"> could indicate that the piggyback data has content-type and perhaps content-transfer-encoding headers. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. You will soon read a generic fortune cookie. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 15:23:16 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04254 for ; Fri, 30 Nov 2001 15:23:15 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUKK4x28982; Fri, 30 Nov 2001 12:20:04 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUKJgx28960 for ; Fri, 30 Nov 2001 12:19:42 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id A800513DEF; Fri, 30 Nov 2001 15:22:28 -0500 (EST) To: "Huston" Cc: Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> <87n11hnm4a.fsf@questionably-configured.permabit.com> <0c1201c17216$6701e930$fe0aa840@FATORA> <87y9kzvpk7.fsf@questionably-configured.permabit.com> <013901c172e4$f171edd0$fe0aa840@FATORA> <87n118p42g.fsf@questionably-configured.permabit.com> <08c001c179c2$96edaea0$0100000a@clyde> From: Jered Floyd In-Reply-To: <08c001c179c2$96edaea0$0100000a@clyde> Message-ID: <87g06wnh4r.fsf@questionably-configured.permabit.com> Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Nov 2001 15:22:28 -0500 One more thought on this before I let it rest; Embedding a BEEP message proper within the content of a 'profile' element presents some concerns that can be worked around, but are layering violations. For example, if the outer message body has (for some reason) a content-transfer encoding of 7bit, but 8bit data is present in the initialization message, one or the other needs to know to use a transformative encoding instead. OK, that was obscure; how about: if ']]>' appears in the initialization message, a transformative encoding must be used (so that it may be embedded in an XML CDATA.) This imposes additional restrictions upon a MIME composer used to form initialization messages. Something I would find a better (cleaner) solution: 'start' messages may be of MIME type multipart/mixed, where the first part is the application/beep+xml message part, and all subsequent parts are initialization messages for the identified profiles in the 'start' message. This allows the MIME body to be delivered as an initialization message to be precisely a BEEP message body. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 15:57:00 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06175 for ; Fri, 30 Nov 2001 15:57:00 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUKs2x29158; Fri, 30 Nov 2001 12:54:02 -0800 (PST) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUKr6x29146 for ; Fri, 30 Nov 2001 12:53:06 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id fAUKtvw16225 for ; Fri, 30 Nov 2001 12:55:57 -0800 (PST) Message-ID: <3C07F266.4C6BAE4A@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Trouble with TLS and transport mappings References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> <87n11hnm4a.fsf@questionably-configured.permabit.com> <0c1201c17216$6701e930$fe0aa840@FATORA> <87y9kzvpk7.fsf@questionably-configured.permabit.com> <013901c172e4$f171edd0$fe0aa840@FATORA> <87n118p42g.fsf@questionably-configured.permabit.com> <08c001c179c2$96edaea0$0100000a@clyde> <87g06wnh4r.fsf@questionably-configured.permabit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 30 Nov 2001 12:56:06 -0800 Content-Transfer-Encoding: 7bit Jered Floyd wrote: > Something I would find a better (cleaner) solution: Actually, I think the better cleaner solution would be the original BXXP solution, which was that a piggyback message is an XML fragment, and if that wasn't good enough, don't piggyback the first message. ;-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. You will soon read a generic fortune cookie. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Nov 30 16:09:00 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07049 for ; Fri, 30 Nov 2001 16:08:59 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUL63x29271; Fri, 30 Nov 2001 13:06:03 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id fAUL55x29259 for ; Fri, 30 Nov 2001 13:05:05 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fAUL53f20076; Fri, 30 Nov 2001 13:05:03 -0800 (PST) Message-ID: <058201c179e3$141c4a60$fe0aa840@FATORA> From: "Marshall T. Rose" To: "Darren New" Cc: , "Marshall Rose" References: <874rnqpk4o.fsf@questionably-configured.permabit.com> <086401c17151$5d2107e0$fe0aa840@FATORA> <87r8qtnnk8.fsf@questionably-configured.permabit.com> <87n11hnm4a.fsf@questionably-configured.permabit.com> <0c1201c17216$6701e930$fe0aa840@FATORA> <87y9kzvpk7.fsf@questionably-configured.permabit.com> <013901c172e4$f171edd0$fe0aa840@FATORA> <87n118p42g.fsf@questionably-configured.permabit.com> <08c001c179c2$96edaea0$0100000a@clyde> <87g06wnh4r.fsf@questionably-configured.permabit.com> <3C07F266.4C6BAE4A@san.rr.com> Subject: Re: [BEEPwg] Trouble with TLS and transport mappings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 30 Nov 2001 13:07:53 -0800 Content-Transfer-Encoding: 7bit > Actually, I think the better cleaner solution would be the original BXXP > solution, which was that a piggyback message is an XML fragment, and if > that wasn't good enough, don't piggyback the first message. ;-) darren - where's the fun in that? everytime someone adds to this thread, the solution becomes more complex. i am deeply shocked that you would buck this trend... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg