From beepwg-admin@lists.beepcore.org Sun Sep 15 02:46:17 2002 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 CAA00024 for ; Sun, 15 Sep 2002 02:46:16 -0400 (EDT) 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 g8F6lCQ02749; Sat, 14 Sep 2002 23:47:12 -0700 (PDT) Received: from myslo.com (qmailr@adsl-66-122-64-130.dsl.snlo01.pacbell.net [66.122.64.130]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g8F6kHQ02737 for ; Sat, 14 Sep 2002 23:46:18 -0700 (PDT) Received: (qmail 28218 invoked from network); 15 Sep 2002 06:47:08 -0000 Received: from unknown (HELO localhost.localdomain) (kkress@10.0.0.12) by localhost with SMTP; 15 Sep 2002 06:47:08 -0000 From: Kevin Kress To: BEEP WG Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aUTAQCDTMX8aEHAiT7Oh" X-Mailer: Ximian Evolution 1.0.8 Message-Id: <1032072206.1280.6.camel@quark> Mime-Version: 1.0 Subject: [BEEPwg] Aborting SASL authentication from the client 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: 14 Sep 2002 23:43:26 -0700 --=-aUTAQCDTMX8aEHAiT7Oh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I was hoping the group could clarify something for me. In SASL when a client aborts a SASL transaction, sending a what would the proper response from the server be? =20 Should it respond with a RLY message of "" or perhaps a RLY with "" or should it be the "" in a ER= R message? Other suggestions? Thoughts? --Kevin Kress --=-aUTAQCDTMX8aEHAiT7Oh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9hCwOaosyXJKUkDIRAuMNAKCZgsCO0fHtIzjOJbop9B+dxjrnuACggJN0 PrZfHPFjlgCn4nQr+XgorRI= =DNou -----END PGP SIGNATURE----- --=-aUTAQCDTMX8aEHAiT7Oh-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Sun Sep 15 14:22:43 2002 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 OAA08319 for ; Sun, 15 Sep 2002 14:22:43 -0400 (EDT) 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 g8FIO4Q08027; Sun, 15 Sep 2002 11:24:04 -0700 (PDT) Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8FINlQ08010 for ; Sun, 15 Sep 2002 11:23:47 -0700 (PDT) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g8FIN0d02999; Sun, 15 Sep 2002 11:23:00 -0700 (PDT) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: kkress@myslo.net Subject: Re: [BEEPwg] Aborting SASL authentication from the client Message-Id: <20020915112300.16c700f8.mrose@dbc.mtview.ca.us> In-Reply-To: <1032072206.1280.6.camel@quark> References: <1032072206.1280.6.camel@quark> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; ) Mime-Version: 1.0 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: Sun, 15 Sep 2002 11:23:00 -0700 Content-Transfer-Encoding: 7bit the server should send which is its way of telling the client that the sasl exchange has successfully completed. (note that "a successful completion of the exchange" doesn't mean that the client got authenticated). /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 11:52:59 2002 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 LAA13784 for ; Mon, 23 Sep 2002 11:52:58 -0400 (EDT) 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 g8NFrCQ01145; Mon, 23 Sep 2002 08:53:12 -0700 (PDT) Received: from mail8.atl.registeredsite.com (nobody@mail8.atl.registeredsite.com [64.224.219.82]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8NFqlQ01133 for ; Mon, 23 Sep 2002 08:52:48 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail8.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g8NFrX9V009021 for ; Mon, 23 Sep 2002 11:53:34 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A9A68910112; Mon, 23 Sep 2002 11:56:22 -0400 From: "Eamon O'Tuathail" To: Message-ID: <000001c26319$5cfaaea0$8b3b869f@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [BEEPwg] MIME-Version Header Field 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, 23 Sep 2002 16:53:28 +0100 Content-Transfer-Encoding: 7bit Do BEEP messages require the MIME-Version header field? RFC 2045 states: "Messages composed in accordance with this document MUST include such a header field, with the following verbatim text: MIME-Version: 1.0" As BEEP carries MIME messages, one could argue that MIME-Version is a mandatory header. However, the main practical purpose of this header is to tell a RFC (2)822 user agent that the message they receive is MIME or not - as BEEP messages are always MIME, it is not needed (unless someone decides to invent a new version of MIME, which seems unlikely for the near future). Eamon _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 13:03:29 2002 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 NAA16478 for ; Mon, 23 Sep 2002 13:03:29 -0400 (EDT) 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 g8NH0DQ01674; Mon, 23 Sep 2002 10:00:14 -0700 (PDT) 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 g8NGxaQ01632 for ; Mon, 23 Sep 2002 09:59:36 -0700 (PDT) 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 00FAF13268; Mon, 23 Sep 2002 13:00:20 -0400 (EDT) To: "Eamon O'Tuathail" Cc: Subject: Re: [BEEPwg] MIME-Version Header Field References: <000001c26319$5cfaaea0$8b3b869f@central> From: Jered Floyd In-Reply-To: <000001c26319$5cfaaea0$8b3b869f@central> Message-ID: <87vg4wy72z.fsf@questionably-configured.permabit.com> Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) 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: 23 Sep 2002 13:00:20 -0400 "Eamon O'Tuathail" writes: > Do BEEP messages require the MIME-Version header field? > > RFC 2045 states: > > "Messages composed in accordance with this document MUST include such > a header field, with the following verbatim text: > > MIME-Version: 1.0" > > As BEEP carries MIME messages, one could argue that MIME-Version is a > mandatory header. (For those playing along with the home game, this is RFC 2045 Section 4, "MIME-Version Header Field".) I interpret the "Messages" in the quoted sentence to mean "RFC 822 messages", since this RFC is all w.r.t Internet message bodies. While BEEP messages are structured according to the rules of MIME, I don't consider them to be RFC 2045's "Internet message bodies" and thus are exempt from needing the MIME-Version header. All existing specifications and implementations of which I am aware do not use the MIME-Version header. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 13:35:22 2002 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 NAA17690 for ; Mon, 23 Sep 2002 13:35:19 -0400 (EDT) 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 g8NHa3Q01928; Mon, 23 Sep 2002 10:36:03 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8NHZsQ01911 for ; Mon, 23 Sep 2002 10:35:54 -0700 (PDT) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA01692; Mon, 23 Sep 2002 10:36:39 -0700 Message-Id: <5.1.1.2.2.20020923101816.024cb680@jay.songbird.com> X-Sender: dhc2@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) To: "Eamon O'Tuathail" From: Dave Crocker Subject: Re: [BEEPwg] MIME-Version Header Field Cc: In-Reply-To: <000001c26319$5cfaaea0$8b3b869f@central> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 23 Sep 2002 10:19:20 -0700 At 04:53 PM 9/23/2002 +0100, Eamon O'Tuathail wrote: >However, the main practical purpose of this header is to tell a RFC >(2)822 user agent that the message they receive is MIME or not - as BEEP >messages are always MIME, it is not needed however, leaving it out violates the specification. information redundancy does not make things stop working. violating a specification does. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 13:59:42 2002 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 NAA18699 for ; Mon, 23 Sep 2002 13:59:41 -0400 (EDT) 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 g8NI0CQ02119; Mon, 23 Sep 2002 11:00:12 -0700 (PDT) Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8NHxtQ02082 for ; Mon, 23 Sep 2002 10:59:55 -0700 (PDT) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g8NI07q06132; Mon, 23 Sep 2002 11:00:07 -0700 (PDT) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: dhc2@dcrocker.net, beepwg@lists.beepcore.org Subject: Re: [BEEPwg] MIME-Version Header Field Message-Id: <20020923110007.7edc5e26.mrose@dbc.mtview.ca.us> In-Reply-To: <5.1.1.2.2.20020923101816.024cb680@jay.songbird.com> References: <000001c26319$5cfaaea0$8b3b869f@central> <5.1.1.2.2.20020923101816.024cb680@jay.songbird.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; ) Mime-Version: 1.0 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: Mon, 23 Sep 2002 11:00:07 -0700 Content-Transfer-Encoding: 7bit > however, leaving it out violates the specification. > > information redundancy does not make things stop working. violating a > specification does. then there's the "be liberal in what you expect and conservative in what you generate" thing. conservatisms says you should always send it. liberalism says you should never care whether you receive it... /mtr ps: it's easy enough for me to add the one line to my implementation to generate it. i don't think i'm going to be modifying the mime package that i'm using to actually require it though... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 15:51:17 2002 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 PAA22459 for ; Mon, 23 Sep 2002 15:51:16 -0400 (EDT) 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 g8NJoRQ02868; Mon, 23 Sep 2002 12:50:27 -0700 (PDT) Received: from mail8.atl.registeredsite.com (nobody@mail8.atl.registeredsite.com [64.224.219.82]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8NJndQ02840 for ; Mon, 23 Sep 2002 12:49:39 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail8.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g8NJoX9V027879 for ; Mon, 23 Sep 2002 15:50:33 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A1326B930036; Mon, 23 Sep 2002 15:53:22 -0400 From: "Eamon O'Tuathail" To: Message-ID: <000301c2633a$787a5010$0a3b869f@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [BEEPwg] MIME-Version Header Field 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, 23 Sep 2002 20:50:27 +0100 Content-Transfer-Encoding: 7bit > however, leaving it out violates the specification. I would agree with that - RFC 2045 says "MUST include such a header field" (that's not a MAY or a SHOULD), so it MUST be present in the outgoing BEEP message a peer sends and MUST be verified to be present in the incoming BEEP message a peer receives. However, if a BEEP implementation did this, it would currently interoperate with no peer that is based on any existing BEEP implementation - none of them use it! I see three possible solutions: Solution 1) A BEEP implementation adds MIME-Version Header to all outgoing messages, and does not accept any incoming messages without it - a strict reading of the MIME and BEEP specs would mandate this. The first message a peer will receive will be the greeting message on channel zero, and RFC 3080 says "If a poorly-formed reply is received on channel zero, the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged." Solution 2) A BEEP implementation provides a (locally defined) configuration option that specifies whether to add MIME-Version headers on outgoing messages, and another configuration option that states whether to REQUIRE it on incoming messages. Solution 3) That the MIME-Version header be added without changing any of the implementations - the only way to do this is that in some future revision, section 2.2. of RFC 3080 be updated with one line about the MIME-Header: "2.2 Messages and Frames A message is structured according to the rules of MIME. Accordingly, each message may begin with "entity-headers" (c.f., MIME's Section 3 [1]). If none, or only some, of the "entity-headers" are present: o the default "Content-Type" is "application/octet-stream"; and, o the default "Content-Transfer-Encoding" is "binary". o the default "MIME-Version" is "1.0"." <<<---------------- new line I would favour option 3. Is that acceptable to others? ================================================= Jered Floyd wrote: > While BEEP messages are structured according to the rules of MIME, > I don't consider them to be RFC 2045's "Internet message bodies" .. BEEP is a MIME-compliant protocol, and so should certainly comply with all aspects of RFC 2045. I would certainly think that BEEP messages are "Internet message bodies". Other protocols (e.g. HTTP) state they are not MIME compliant, but reuse some of the MIME concepts (e.g. RFC 2616's section 19.4.1) but have flexibility in what aspects of MIME they permit (e.g. multiple body parts). Eamon _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 17:17:26 2002 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 RAA25392 for ; Mon, 23 Sep 2002 17:17:26 -0400 (EDT) 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 g8NLIBQ03446; Mon, 23 Sep 2002 14:18:11 -0700 (PDT) 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 g8NLHSQ03434 for ; Mon, 23 Sep 2002 14:17:28 -0700 (PDT) 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 807C313268; Mon, 23 Sep 2002 17:18:10 -0400 (EDT) To: "Eamon O'Tuathail" Cc: Subject: Re: [BEEPwg] MIME-Version Header Field References: <000301c2633a$787a5010$0a3b869f@central> From: Jered Floyd In-Reply-To: <000301c2633a$787a5010$0a3b869f@central> Message-ID: <87r8fkwgkt.fsf@questionably-configured.permabit.com> Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) 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: 23 Sep 2002 17:18:10 -0400 > Solution 3) That the MIME-Version header be added without changing any > of the implementations - the only way to do this is that in some future > revision, section 2.2. of RFC 3080 be updated with one line about the > MIME-Header: > "2.2 Messages and Frames > A message is structured according to the rules of MIME. Accordingly, > each message may begin with "entity-headers" (c.f., MIME's Section 3 > [1]). If none, or only some, of the "entity-headers" are present: > o the default "Content-Type" is "application/octet-stream"; and, > o the default "Content-Transfer-Encoding" is "binary". > o the default "MIME-Version" is "1.0"." <<<---------------- new > line > > I would favour option 3. Is that acceptable to others? This seems like a fine solution. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 17:35:35 2002 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 RAA26098 for ; Mon, 23 Sep 2002 17:35:35 -0400 (EDT) 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 g8NLa2Q03606; Mon, 23 Sep 2002 14:36:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8NLZVQ03589 for ; Mon, 23 Sep 2002 14:35:31 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KMU78PAM0000628S@mauve.mrochek.com> for beepwg@lists.beepcore.org; Mon, 23 Sep 2002 14:36:11 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: [BEEPwg] MIME-Version Header Field In-reply-to: "Your message dated Mon, 23 Sep 2002 16:53:28 +0100" <000001c26319$5cfaaea0$8b3b869f@central> To: "Eamon O'Tuathail" Cc: beepwg@lists.beepcore.org Message-id: <01KMUDQDCYVG00628S@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <000001c26319$5cfaaea0$8b3b869f@central> 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, 23 Sep 2002 14:23:20 -0700 (PDT) Content-Transfer-Encoding: 7BIT > Do BEEP messages require the MIME-Version header field? > RFC 2045 states: > "Messages composed in accordance with this document MUST include such > a header field, with the following verbatim text: > MIME-Version: 1.0" > As BEEP carries MIME messages, one could argue that MIME-Version is a > mandatory header. This is quite true, however, you've missed a crucial definition: When RFC 2045 talks about "messages" it is talking about RFC 822 messages specifically. This is clearly stated in section 2.3. I don't believe it is the case that BEEP is defined to carry RFC 822 messages, so I don't believe this requirement applies to BEEP. > However, the main practical purpose of this header is to tell a RFC > (2)822 user agent that the message they receive is MIME or not - as BEEP > messages are always MIME, it is not needed (unless someone decides to > invent a new version of MIME, which seems unlikely for the near future). It isn't the main practical purpose of the header; it is the only purpose. I should also point out that we have plenty of examples of protocols, including some that deal with "messages", which use MIME labelling and do not see a need to use a MIME-Version field. The obvious example here is HTTP. Ned _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 17:36:12 2002 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 RAA26147 for ; Mon, 23 Sep 2002 17:36:11 -0400 (EDT) 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 g8NLb2Q03630; Mon, 23 Sep 2002 14:37:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8NLaIQ03618 for ; Mon, 23 Sep 2002 14:36:18 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KMU78PAM0000628S@mauve.mrochek.com> for beepwg@lists.beepcore.org; Mon, 23 Sep 2002 14:37:12 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: [BEEPwg] MIME-Version Header Field In-reply-to: "Your message dated Mon, 23 Sep 2002 13:00:20 -0400" <87vg4wy72z.fsf@questionably-configured.permabit.com> To: Jered Floyd Cc: "Eamon O'Tuathail" , beepwg@lists.beepcore.org Message-id: <01KMUDRMT1S800628S@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <000001c26319$5cfaaea0$8b3b869f@central> <87vg4wy72z.fsf@questionably-configured.permabit.com> 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, 23 Sep 2002 14:36:34 -0700 (PDT) Content-Transfer-Encoding: 7BIT > "Eamon O'Tuathail" writes: > > Do BEEP messages require the MIME-Version header field? > > > > RFC 2045 states: > > > > "Messages composed in accordance with this document MUST include such > > a header field, with the following verbatim text: > > > > MIME-Version: 1.0" > > > > As BEEP carries MIME messages, one could argue that MIME-Version is a > > mandatory header. > (For those playing along with the home game, this is RFC 2045 > Section 4, "MIME-Version Header Field".) > I interpret the "Messages" in the quoted sentence to mean "RFC 822 > messages", since this RFC is all w.r.t Internet message bodies. > While BEEP messages are structured according to the rules of MIME, > I don't consider them to be RFC 2045's "Internet message bodies" > and thus are exempt from needing the MIME-Version header. Exactly right and even supported by a careful reading of RFC 2045. Ned _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 23 19:39:10 2002 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 TAA29362 for ; Mon, 23 Sep 2002 19:39:10 -0400 (EDT) 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 g8NNZ6Q04414; Mon, 23 Sep 2002 16:35:06 -0700 (PDT) Received: from mail9.atl.registeredsite.com (nobody@mail9.atl.registeredsite.com [64.224.219.83]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8NNYOQ04395 for ; Mon, 23 Sep 2002 16:34:25 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail9.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g8NNZINQ013214; Mon, 23 Sep 2002 19:35:18 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A5E05AF50128; Mon, 23 Sep 2002 19:38:08 -0400 From: "Eamon O'Tuathail" To: Cc: Subject: RE: [BEEPwg] MIME-Version Header Field Message-ID: <000001c26359$de0a2080$0a3a869f@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <01KMUDQDCYVG00628S@mauve.mrochek.com> Importance: Normal 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, 24 Sep 2002 00:35:11 +0100 Content-Transfer-Encoding: 7bit Ned, >> When RFC 2045 talks about "messages" it is talking about RFC 822 messages >> specifically. This is clearly stated in section 2.3. There are two aspects to RFC 822 messages - one we might call the generic structure (we see this aspect reused by MIME entities, HTTP, SIP, etc.) - it defines a generic message as divided into headers and body by a CRLF, multipart bodies are supported, the headers are of the format ": " and folding lines etc. are supported. BEEP messages follow this aspect. The other aspect to RFC 822 is the mail related collection of headers (From:, To:, Subject:, References:, etc.) and a variety of rules around email format. BEEP messages certainly do not follow this aspect. RFC 822 and the MIME RFCs do not make this distinction, but other RFCs do (e.g. HTTP - RFC2616, section 4.1). > I don't believe it is the case that BEEP is defined to carry RFC 822 > messages, so I don't believe this requirement applies to BEEP. So would it be accurate to state that BEEP carries MIME entities - BEEP does not carry MIME messages? (RFC 3080, section 2.2 only states " A message is structured according to the rules of MIME.", and then goes on to discuss entity headers.) If that is the case, then the BEEP message (the MIME entity) can only carry MIME entity headers, and I agree that MIME message headers, such as MIME-Version, are not needed. Eamon _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Sep 24 04:08:38 2002 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 EAA19626 for ; Tue, 24 Sep 2002 04:08:37 -0400 (EDT) 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 g8O894Q07792; Tue, 24 Sep 2002 01:09:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8O88YQ07780 for ; Tue, 24 Sep 2002 01:08:34 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KMUPHEXL0000628S@mauve.mrochek.com> for beepwg@lists.beepcore.org; Tue, 24 Sep 2002 01:09:29 -0700 (PDT) From: ned.freed@mrochek.com Subject: RE: [BEEPwg] MIME-Version Header Field In-reply-to: "Your message dated Tue, 24 Sep 2002 00:35:11 +0100" <000001c26359$de0a2080$0a3a869f@central> To: "Eamon O'Tuathail" Cc: ned.freed@mrochek.com, beepwg@lists.beepcore.org Message-id: <01KMUZUK4QO200628S@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KMUDQDCYVG00628S@mauve.mrochek.com> <000001c26359$de0a2080$0a3a869f@central> 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, 24 Sep 2002 00:53:58 -0700 (PDT) Content-Transfer-Encoding: 7BIT > >> When RFC 2045 talks about "messages" it is talking about RFC 822 > messages > >> specifically. This is clearly stated in section 2.3. > There are two aspects to RFC 822 messages - one we might call the > generic structure (we see this aspect reused by MIME entities, HTTP, > SIP, etc.) - it defines a generic message as divided into headers and > body by a CRLF, multipart bodies are supported, the headers are of the > format ": " and folding lines etc. are > supported. BEEP messages follow this aspect. Yes, this is referred to as an entity in the MIME RFCs. See section 2.4 of RFC 2045. > The other aspect to RFC 822 is the mail related collection of headers > (From:, To:, Subject:, References:, etc.) and a variety of rules around > email format. BEEP messages certainly do not follow this aspect. "Message" refers to a subset of possible RFC 822 messages in the MIME RFCs. > RFC 822 and the MIME RFCs do not make this distinction, but other RFCs > do (e.g. HTTP - RFC2616, section 4.1). On the contrary, this distinction is very clearly made in the MIME RFCs. Entity and message are very different things and the MIME RFCs are careful to make this distinction. The issue here seems to be that how the MIME RFCs use the term message. Unfortunately this is unavoidable given that MIME was intiially concieved entirely in the context of email, which uses the term "message" in a fairly specific way. But by the time RFC 2045-2049 came out it had become clear that MIME constructs had broader applicability. That's why the term "entity" was defined and the specifications were changed to use it when it was appropriate. We went round and round and round on all this before RFCs 2045-2049 came out. > > I don't believe it is the case that BEEP is defined to carry RFC 822 > > messages, so I don't believe this requirement applies to BEEP. > So would it be accurate to state that BEEP carries MIME entities - BEEP > does not carry MIME messages? (RFC 3080, section 2.2 only states " A > message is structured according to the rules of MIME.", and then goes on > to discuss entity headers.) That would be correct. Saying something like a "a BEEP message is a MIME entity as defined in RFC 2045 ..." or something similar would be a useful clarification > If that is the case, then the BEEP message (the MIME entity) can only > carry MIME entity headers, and I agree that MIME message headers, such > as MIME-Version, are not needed. Exactly. Ned _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Sep 24 11:40:11 2002 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 LAA02825 for ; Tue, 24 Sep 2002 11:40:10 -0400 (EDT) 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 g8OFY5Q11242; Tue, 24 Sep 2002 08:34:05 -0700 (PDT) Received: from mail7.atl.registeredsite.com (nobody@mail7.atl.registeredsite.com [64.224.219.81]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8OFXHQ11229 for ; Tue, 24 Sep 2002 08:33:17 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail7.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g8OFY85Q032031; Tue, 24 Sep 2002 11:34:09 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A67C3D140038; Tue, 24 Sep 2002 11:36:28 -0400 From: "Eamon O'Tuathail" To: Cc: Subject: RE: [BEEPwg] MIME-Version Header Field Message-ID: <000601c263df$bf89c850$693a869f@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <01KMUZUK4QO200628S@mauve.mrochek.com> Importance: Normal 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, 24 Sep 2002 16:33:33 +0100 Content-Transfer-Encoding: 7bit Ned Thanks for that - it is much clearer to me now. Eamon _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Sat Sep 28 05:55:28 2002 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 FAA01650 for ; Sat, 28 Sep 2002 05:55:24 -0400 (EDT) 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 g8S9mCQ20729; Sat, 28 Sep 2002 02:48:12 -0700 (PDT) Received: from texas.pobox.com (texas.pobox.com [64.49.223.111]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8S9lNQ20712 for ; Sat, 28 Sep 2002 02:47:23 -0700 (PDT) Received: from partisan.pobox.com (adsl-64-171-15-135.dsl.sntc01.pacbell.net [64.171.15.135]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by texas.pobox.com (Postfix) with ESMTP id 796D745364; Sat, 28 Sep 2002 05:47:49 -0400 (EDT) Message-Id: <5.1.0.14.2.20020928023757.02aec610@pobox.com> X-Sender: dnm@pobox.com@pobox.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: beepwg@lists.beepcore.org From: Dan Moniz Cc: beepcore-ruby-discuss@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [BEEPwg] Ruby BEEP core (beepcore-ruby) project now underway 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, 28 Sep 2002 02:47:43 -0700 Hi all, Despite being officially formed in Summer 2001, and after numerous false starts, the project to implement the BEEP core (RFC 3080 and RFC 3081) in the Ruby programming language ("Ruby BEEP Core", or colloquially "beepcore-ruby") is now underway. We're going after the same goal as both the Java, Tcl, and C implementations -- a full, useable core in 100% Ruby. It's still early days yet, and we're just now discussing the overall design, direction, and shape the project and the code is going to take, so now is a great time to get involved. Interested parties should check out and for more information, and to sign up on the project mailing lists. Cheers! -- Dan Moniz [http://www.pobox.com/~dnm/] _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 30 03:58:43 2002 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 DAA26114 for ; Mon, 30 Sep 2002 03:58:43 -0400 (EDT) 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 g8U7v9Q08910; Mon, 30 Sep 2002 00:57:10 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8U7uSQ08898 for ; Mon, 30 Sep 2002 00:56:29 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8U7w3OW009846 for ; Mon, 30 Sep 2002 09:58:04 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id TRZTM3V0; Mon, 30 Sep 2002 09:58:03 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 09:58:03 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA9410D3138C4@edeacnt100.eed.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sachit Jain (QED)" To: "'beepwg@lists.beepcore.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [BEEPwg] a simple question 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, 30 Sep 2002 09:58:03 +0200 hi, i was wondering if anyone could help me find any implementation of SOAP over BEEP? i couldn't find any so far on the net. Also if anyone could give me more information about if anybody's planning to implement the BEEP Core over SCTP, that would be great. best regards, sachit. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Sep 30 09:23:34 2002 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 JAA02688 for ; Mon, 30 Sep 2002 09:23:33 -0400 (EDT) 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 g8UDM8Q11533; Mon, 30 Sep 2002 06:22:13 -0700 (PDT) Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g8UDLfQ11521 for ; Mon, 30 Sep 2002 06:21:41 -0700 (PDT) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g8UDMqv04955; Mon, 30 Sep 2002 06:22:52 -0700 (PDT) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: Sachit.Jain@eed.ericsson.se Subject: Re: [BEEPwg] a simple question Message-Id: <20020930062252.27fcda58.mrose@dbc.mtview.ca.us> In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA9410D3138C4@edeacnt100.eed.ericsson.se> References: <5E5172B4DE05D311B3AB0008C75DA9410D3138C4@edeacnt100.eed.ericsson.se> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; ) Mime-Version: 1.0 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: Mon, 30 Sep 2002 06:22:52 -0700 Content-Transfer-Encoding: 7bit > hi, > > i was wondering if anyone could help me find any implementation of SOAP over BEEP? i > couldn't find any so far on the net. Also if anyone could give me more information > about if anybody's planning to implement the BEEP Core over SCTP, that would be great. go to http://beecore.org/ and research some of the implementations there listed under "Products" or "Projects". in particular, beepcore-tcl and clipcode both have soap/beep. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg