From daemon@optimus.ietf.org Mon Feb 4 10:21:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25380 for ; Mon, 4 Feb 2002 10:21:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08769 for midcom-archive@odin.ietf.org; Mon, 4 Feb 2002 10:21:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08407; Mon, 4 Feb 2002 10:15:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08379 for ; Mon, 4 Feb 2002 10:15:44 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25153 for ; Mon, 4 Feb 2002 10:15:41 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g14FFxj88438; Mon, 4 Feb 2002 16:15:59 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 7094FC05C; Mon, 4 Feb 2002 16:15:12 +0100 (CET) Date: Mon, 04 Feb 2002 16:32:05 +0100 From: Martin Stiemerling To: midcom@ietf.org Cc: quittek@ccrle.nec.de Message-ID: <13670000.1012836725@elgar> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========1728306916==========" Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-simco-00.txt (fwd) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --==========1728306916========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, Juergen and I have submitted a new internet draft regarding NAT and firewall configuration. The draft defines a Simple Middlebox Configuration (SIMCO) protocol which: - is compliant with the MIDCOM requirements (draft-ietf-midcom-requirements-05.txt) - is designed to follow the "Keep It Simple,Stupid" principle - and the protocol state machines are completely defined. We further plan to have a first implementation up to the IETF #53. Regards Martin ---------- Forwarded Message ---------- Date: Montag, Februar 04, 2002 07:21:08 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-stiemerling-midcom-simco-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 1.0 Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-simco-00.txt Pages : 28 Date : 01-Feb-02 This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-simco-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-simco-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- End Forwarded Message ---------- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Martin.Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de --==========1728306916========== Content-Type: message/rfc822; name="I-D ACTION:draft-stiemerling-midcom-simco-00.txt" X-Sieve: cmu-sieve 2.0 Return-Path: Received: from tokyo.ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 0527BC05B; Mon, 4 Feb 2002 15:45:33 +0100 (CET) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g14EjV827159; Mon, 4 Feb 2002 15:45:32 +0100 (CET) (envelope-from ietf-123-owner@loki.ietf.org) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA22163 for ietf-123-outbound.06@ietf.org; Mon, 4 Feb 2002 09:25:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA21207 for ; Mon, 4 Feb 2002 07:21:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19813 for ; Mon, 4 Feb 2002 07:21:08 -0500 (EST) Message-Id: <200202041221.HAA19813@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stiemerling-midcom-simco-00.txt Date: Mon, 04 Feb 2002 07:21:08 -0500 Sender: nsyracus@cnri.reston.va.us MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========1971417796==========" --==========1971417796========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 1.0 Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-simco-00.txt Pages : 28 Date : 01-Feb-02 This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-simco-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-simco-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --==========1971417796========== Content-Type: multipart/alternative; boundary="==========437908339==========" --==========437908339========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020201164347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-simco-00.txt --==========437908339========== Content-Type: message/external-body; name="draft-stiemerling-midcom-simco-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020201164347.I-D@ietf.org> --==========437908339==========-- --==========1971417796==========-- --==========1728306916==========-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Feb 4 11:52:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28713 for ; Mon, 4 Feb 2002 11:52:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14568 for midcom-archive@odin.ietf.org; Mon, 4 Feb 2002 11:52:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13635; Mon, 4 Feb 2002 11:39:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13606 for ; Mon, 4 Feb 2002 11:39:33 -0500 (EST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28202 for ; Mon, 4 Feb 2002 11:39:29 -0500 (EST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id LAA22336 for midcom@ietf.org; Mon, 4 Feb 2002 11:41:49 -0500 Message-Id: <200202041641.LAA22336@markbaker.ca> To: midcom@ietf.org Date: Mon, 4 Feb 2002 11:41:49 -0500 (EST) From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] HTTP as the Midcom protocol Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I've had a read through the requirements, and I'd suggest that HTTP makes a pretty good candidate for a MIDCOM protocol. The only requirement that it currently has trouble meeting, and so would require a small extension to meet, is 2.1.6 (assuming that status report is to be asynchronous with respect to the agent). WEBI is considering a similar extension that they would use for cache invalidation, but it can easily be used for other problems such as this one. Many of the requirements in 2.2 would also not be directly satisfied by HTTP, but would instead be satisfied by a data format (MidcomML?) that would be transferred with HTTP. Granted, HTTP 1.1 also does a lot more than what MIDCOM needs, but its value is that it's already deployed and that there are a lot of well tested, optimized, and secured third party implementations available. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Feb 4 13:36:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02412 for ; Mon, 4 Feb 2002 13:36:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22951 for midcom-archive@odin.ietf.org; Mon, 4 Feb 2002 13:36:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22845; Mon, 4 Feb 2002 13:34:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22817 for ; Mon, 4 Feb 2002 13:34:21 -0500 (EST) Received: from mailil.kagoor.com ([212.199.132.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02344 for ; Mon, 4 Feb 2002 13:34:18 -0500 (EST) Received: (qmail 18135 invoked from network); 4 Feb 2002 18:19:52 -0000 Received: from unknown (HELO gby) (212.199.132.194) by 212.199.132.210 with SMTP; 4 Feb 2002 18:19:52 -0000 From: "Gilad Ben-Yossef" To: Subject: RE: [midcom] HTTP as the Midcom protocol Date: Mon, 4 Feb 2002 21:48:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200202041641.LAA22336@markbaker.ca> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA22818 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Hi all, As this is my first post I believe I ought to introduce myself: my name is Gilad Ben-Yossef, and I'm the a software team leader with Kagoor Networks R&D arm. > I've had a read through the requirements, and I'd suggest that HTTP > makes a pretty good candidate for a MIDCOM protocol. The only > requirement that it currently has trouble meeting, and so would require > a small extension to meet, is 2.1.6 (assuming that status report is to > be asynchronous with respect to the agent). WEBI is considering a > similar extension that they would use for cache invalidation, but it can > easily be used for other problems such as this one. Since the subject of adopting already existing protocols has already surfaced, I'd like to suggest something that I kept thinking to myself while reading the workgroup RFCs: use SOCKS (and possible extensions) as the MIDCOM protocol. Like HTTP it is already deployed, used and debugged. Unlike HTTP, it already implements more then just the transport layer and actually is being used in a context very similar to the group objectives. Even more important: many clients and some MIDCOM equipment already implements and support SOCKS5 today. An an added bonus SOCK5 is an IETF standart. Before the advent of NAT that deals with "generic" protocols, SOCKS was one of the leading ways to deal with the same problems we are facing now of private address spaces. There's no reason not to use it now to solve the remaining problem of protocols which simple NAT does not cover. Of course, several extensions would be needed, for example to deal with odd/even port numbers issue but the basic infrastructure is already there. More on SOCKS5 ca be found here: http://www.socks.nec.com/socksprot.html Remarks are very much welcome. Gilad. -- Gilad Ben-Yossef Tel: +972(9)9717330 | Fax: +972(9)9717334 | Cel: +972(54)756701 Kagoor Networks ltd | http://www.kagoor.com | _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Feb 4 13:51:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02829 for ; Mon, 4 Feb 2002 13:51:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23919 for midcom-archive@odin.ietf.org; Mon, 4 Feb 2002 13:51:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23759; Mon, 4 Feb 2002 13:48:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23733 for ; Mon, 4 Feb 2002 13:48:28 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02700 for ; Mon, 4 Feb 2002 13:48:24 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g14IltG02855; Mon, 4 Feb 2002 10:47:55 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACS76303; Mon, 4 Feb 2002 10:45:51 -0800 (PST) Message-Id: <5.1.0.14.0.20020204134540.00a54b90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 13:50:47 -0500 To: "Gilad Ben-Yossef" , From: Melinda Shore Subject: RE: [midcom] HTTP as the Midcom protocol In-Reply-To: References: <200202041641.LAA22336@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 09:48 PM 2/4/02 +0200, Gilad Ben-Yossef wrote: >Since the subject of adopting already existing protocols has already surfaced, I'd like to suggest something that I kept thinking to myself while reading the workgroup RFCs: use SOCKS (and possible extensions) as the MIDCOM protocol. It's obviously an attractive candidate, but it would have to be extended quite a bit - more than many others. Also, I spent quite some time talking with the SOCKS folks before starting work on midcom, and they weren't at all receptive to the prospect of addressing NAT issues. I think the working group is on the cusp of closing down. This is by way of background. If you feel that SOCKS is a superior protocol for this application, you should feel free to 1) advocate its use by preparing some text describing its applicability, and 2) start working being able to describe the necessary protocol extensions (UDP support, NAT, etc.). Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Feb 4 13:54:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02889 for ; Mon, 4 Feb 2002 13:54:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24096 for midcom-archive@odin.ietf.org; Mon, 4 Feb 2002 13:54:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23879; Mon, 4 Feb 2002 13:50:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23851 for ; Mon, 4 Feb 2002 13:50:12 -0500 (EST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02809 for ; Mon, 4 Feb 2002 13:50:09 -0500 (EST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id NAA25011; Mon, 4 Feb 2002 13:52:30 -0500 Message-Id: <200202041852.NAA25011@markbaker.ca> Subject: Re: [midcom] HTTP as the Midcom protocol To: gby@kagoor.com (Gilad Ben-Yossef) Date: Mon, 4 Feb 2002 13:52:30 -0500 (EST) Cc: midcom@ietf.org In-Reply-To: from "Gilad Ben-Yossef" at Feb 04, 2002 09:48:25 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > Since the subject of adopting already existing protocols has already surfaced, I'd like to suggest something that I kept thinking to myself while reading the workgroup RFCs: use SOCKS (and possible extensions) as the MIDCOM protocol. I'm very glad to hear more support for using existing protocols. > Like HTTP it is already deployed, used and debugged. Unlike HTTP, it already implements more then just the transport layer I don't have much of an opinion about the use of SOCKS, but I would like to point out that HTTP is an application protocol, not a transport protocol. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Feb 4 17:41:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07391 for ; Mon, 4 Feb 2002 17:41:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04902 for midcom-archive@odin.ietf.org; Mon, 4 Feb 2002 17:41:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04617; Mon, 4 Feb 2002 17:31:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04582 for ; Mon, 4 Feb 2002 17:31:44 -0500 (EST) Received: from ffm163.dekundenserver.de ([62.26.119.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07260 for ; Mon, 4 Feb 2002 17:31:37 -0500 (EST) Received: (qmail 9398 invoked by uid 30); 4 Feb 2002 21:54:39 -0000 Date: 4 Feb 2002 21:54:39 -0000 Message-ID: <20020204215439.9397.qmail@ffm163.dekundenserver.de> To: midcom@alltel.net, midcom@earthlink.net, midcom@excite.com, midcom@ietf.org, midcom@iloft.com From: Christina1@adultland.com () Subject: [midcom] i thought you would wanna see this Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Folgende Angaben wurden im Web-Formular gemacht. Die Anfrage erfolgte durch: (Christina1@adultland.com) am Montag, 4. Februar, 2002 at 22:54:39 --------------------------------------------------------------------------- : Click here to get free access to the worlds largest selection of home webcams, adult fetishes and teen Exposure on the net.. NO CREDIT CARD NEEDED AT ALL 100% FREE --------------------------------------------------------------------------- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Feb 5 20:57:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27559 for ; Tue, 5 Feb 2002 20:57:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA16371 for midcom-archive@odin.ietf.org; Tue, 5 Feb 2002 20:57:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15684; Tue, 5 Feb 2002 20:38:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15649 for ; Tue, 5 Feb 2002 20:38:35 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27234 for ; Tue, 5 Feb 2002 20:38:31 -0500 (EST) Received: from jku.iptel.org (ds63-113-46-158.dynamicsoft.com [63.113.46.158]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g161bpH14196; Wed, 6 Feb 2002 02:37:51 +0100 Message-Id: <5.1.0.14.0.20020206022543.0167c188@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Feb 2002 02:37:54 +0100 To: midcom@ietf.org From: Jiri Kuthan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Yet Another Midcom Protocol Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Whoever is interested in running code may want to have a look at http://www.iptel.org/fcp/ -- there is a link to two very-beta server implementations of a midcom-like protocol called FCP. It runs on Linux, opens and closes pinholes, allocates and releases NAT translations. MPLS support is missing, which is a feature. The protocol is described there too, though not really extensivelly. Backers of protocol recycling may wonder why we haven't used COPS/SOAP/HTTP/BEEP/SNMP/Diameter/GSMP or of course H.248. Well, we wanted to stay very simple, were lazy and did not want to implement anything else than needed. -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Feb 5 21:57:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29865 for ; Tue, 5 Feb 2002 21:57:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA20017 for midcom-archive@odin.ietf.org; Tue, 5 Feb 2002 21:57:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18606; Tue, 5 Feb 2002 21:40:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18577 for ; Tue, 5 Feb 2002 21:40:22 -0500 (EST) Received: from ps.pxserver.com ([202.164.189.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29381 for ; Tue, 5 Feb 2002 21:40:14 -0500 (EST) Received: from localhost ([202.164.189.225]) by ps.pxserver.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 10:43:49 +0800 X-Sender: johnx3001@yahoo.com From: John M To: midcom@ietf.org Date: Wed, 06 Feb 2002 10:43:49 +0800 Reply-To: johnx3002@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 06 Feb 2002 02:43:49.0386 (UTC) FILETIME=[1B08C6A0:01C1AEB8] Content-Transfer-Encoding: 7bit Subject: [midcom] JOIN FOR FREE! ... Learn and Earn Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hello Fellow Networker, My name is John Miranda. I am now focusing on one online opportunity. I have tried several of these online opportunities full of hype promising us thousands of dollars every month. It is a sad fact that many people who are in need to earn additional income is being victimized by this fly by night scam artists. Every time I tried one opportunity after the other, I ended more broke than ever. As a result of trying all these opportunities, I have decided to select on my portfolio the company which is true to their words. Not the one full of hype. The only one that has consistently sent me the monthly check. Even without the hype they have given me the best compensation plan with their high % commission. They are providing real service not the one that simply transfer wealth from the new signups to the people at the top of the pyramid. They are not a form of a pyramid scam. Also when you join, you will have a team of upline sponsors who will help you succeed every step of the way. Instead of being left alone, you will be guided step by step by real people, not those autoresponders. Do not believe in do nothing, no recruiting, no selling schemes. They are scams. You might want to try it to prove my words. Only you can make your own success together with the help of your sponsors. If you have 2 to 3 hours a day, you will be able to earn a full income in a few months. And there is absolutely no limit as how much you can earn. It is designed to gain momentum after some time. But I prefer to avoid such statements as "You will get rich". I read it everywhere and I do not want to sound like them. To get your FREE membership ID send email to johnx300@yahoo.com and put "REGISTER ME FOR FREE" in the subject and your fullname in the body of your email. Regards, John Miranda johnx300@yahoo.com Note: You don't need to request for removal. This is a one time email. Your email address will be automatically de-activated in our list if you don't reply in this mail. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Feb 6 01:37:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04597 for ; Wed, 6 Feb 2002 01:37:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA09838 for midcom-archive@odin.ietf.org; Wed, 6 Feb 2002 01:37:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09589; Wed, 6 Feb 2002 01:32:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09560 for ; Wed, 6 Feb 2002 01:32:39 -0500 (EST) Received: from localhost ([211.110.178.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04524 for ; Wed, 6 Feb 2002 01:32:35 -0500 (EST) Message-Id: <200202060632.BAA04524@ietf.org> Reply-To: irej44@hanmail.net From: irej44 To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 6 Feb 2002 15:31:40 +0900 Subject: [midcom] 애인이나 친구가 필요하신분만,,(성인-광고) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 



외로움을 달래줄 애인이 필요할때 
24시간 기다리고 있어요
               


1.  전화기를 들고
   060-700-7747   를 누르세요.
   
   (전국시내요금) 


가입비 없슴

2. 외로움을 달래줄 대화상대가 필요하신분.

3. 지금 전화를 들고 060-700-7747를 눌러주세요

4. 그대가 원하는것을 해결할수 있습니다

5. 가입후 공개게시판에 자신의 개인프로필을 강력하게 어필해보세요
 

 그다음에 무슨일이 일어날지 책임못져


** 이케하면 오빠야 품으로 열나섹쒸 쭉쭉빵빵 언냐들이 호박넝쿨처럼 우루룩!! **




본 메일은 정보통신망 이용촉진법 규정에 따라 광고메일임을 표시하였으며 수신거부장치를 마련하고 있습니다. 
본 메일주소는 인터넷상에서 수집한것이며 메일주소외 어떠한 개인정보도 갖고 있지 않습니다
원치 않은 정보였다면 정중히 사과 드리며, 수신거부를 해 주시면 다음부터는 메일이 발송되지 않을 것입니다
수신거부


  


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 05:44:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24441
	for ; Thu, 7 Feb 2002 05:44:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA13613
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 05:44:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13294;
	Thu, 7 Feb 2002 05:35:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13263
	for ; Thu, 7 Feb 2002 05:35:41 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24338
	for ; Thu, 7 Feb 2002 05:35:37 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g17AZPj07909;
	Thu, 7 Feb 2002 11:35:25 +0100 (CET)
Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 9A569C05B; Thu,  7 Feb 2002 11:34:36 +0100 (CET)
Date: Thu, 07 Feb 2002 11:34:35 +0100
From: Martin Stiemerling 
To: Mark Baker , midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
Message-ID: <41010000.1013078075@elgar>
In-Reply-To: <200202041641.LAA22336@markbaker.ca>
References:  <200202041641.LAA22336@markbaker.ca>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

comments are inline.

Cheers
Martin

--On Montag, Februar 04, 2002 11:41:49 -0500 Mark Baker  
wrote:

> I've had a read through the requirements, and I'd suggest that HTTP
> makes a pretty good candidate for a MIDCOM protocol.  The only
> requirement that it currently has trouble meeting, and so would require
> a small extension to meet, is 2.1.6 (assuming that status report is to
> be asynchronous with respect to the agent).  WEBI is considering a
> similar extension that they would use for cache invalidation, but it can
> easily be used for other problems such as this one.
>
> Many of the requirements in 2.2 would also not be directly satisfied by
> HTTP, but would instead be satisfied by a data format (MidcomML?) that

But in this case you have to define the MidcomML as well with states, 
messages and so on. Furthermore you have a huge protocol overhead due to 
the use of HTTP. This is not a really small protocol anymore.

> would be transferred with HTTP.
>
> Granted, HTTP 1.1 also does a lot more than what MIDCOM needs, but its
> value is that it's already deployed and that there are a lot of well
> tested, optimized, and secured third party implementations available.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>



Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories      Martin.Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de             IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 05:51:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24539
	for ; Thu, 7 Feb 2002 05:51:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA13919
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 05:51:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13837;
	Thu, 7 Feb 2002 05:50:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13803
	for ; Thu, 7 Feb 2002 05:49:58 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24519
	for ; Thu, 7 Feb 2002 05:49:54 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g17AoFj07958
	for ; Thu, 7 Feb 2002 11:50:15 +0100 (CET)
Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id C2552C05B
	for ; Thu,  7 Feb 2002 11:49:26 +0100 (CET)
Date: Thu, 07 Feb 2002 11:49:25 +0100
From: Martin Stiemerling 
To: midcom@ietf.org
Message-ID: <43780000.1013078965@elgar>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Subject: [midcom] SOCKS as MIDCOM protocol
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

there has been the discussion whether SOCKS could be used as a MIDCOM 
protocol or not. In my opinion this is not straight forward. SOCKS may be 
widely deployed, but the SOCKS protocol is intended  to have a 
communication between the SOCKS server/client or between two SOCKS server.
In the MIDCOM case the SOCKS server is the firewall/NAT and the client is 
located at the MIDCOM agent. After establishing a pinhole/binding in the 
NAT by the MIDCOM agent, the data flow from the client, e.g. a SIP phone 
with UPD traffic, has to take the follwing way:
SIP-Phone -> MIDCOM agent/SOCKS client -> SOCKS/Server.
That's the way SOCKS works. A lot of changes to SOCKS have to be made, to 
make  SOCKS compliant with the MIDCOM architecture.

Cheers
Martin




Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories      Martin.Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de             IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 10:54:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00419
	for ; Thu, 7 Feb 2002 10:54:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA27224
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 10:54:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27186;
	Thu, 7 Feb 2002 10:53:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27155
	for ; Thu, 7 Feb 2002 10:53:01 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00356
	for ; Thu, 7 Feb 2002 10:52:58 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id KAA11094;
	Thu, 7 Feb 2002 10:55:20 -0500
Message-Id: <200202071555.KAA11094@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: Martin.Stiemerling@ccrle.nec.de (Martin Stiemerling)
Date: Thu, 7 Feb 2002 10:55:19 -0500 (EST)
Cc: midcom@ietf.org
In-Reply-To: <41010000.1013078075@elgar> from "Martin Stiemerling" at Feb 07, 2002 11:34:35 AM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> > Many of the requirements in 2.2 would also not be directly satisfied by
> > HTTP, but would instead be satisfied by a data format (MidcomML?) that
> 
> But in this case you have to define the MidcomML as well with states, 
> messages and so on.

This work would have to be done anyway, whether it's an ML or a MIB
or whatever.  Right?

> Furthermore you have a huge protocol overhead due to 
> the use of HTTP. This is not a really small protocol anymore.

Just to be clear, by "huge protocol overhead", do you mean bloat in
the protocol at runtime, or bloat in the specification (or something
else?)?

If the former, there is some degree of truth to this since it's a text
based protocol and sometimes transfers header information that isn't
used.  But I've used it extensively, even in wireless environments
(~1200bps), and I've never regretted the decision to use it.

If the latter, that's also true, RFC 2616 is a large specification.
But it's already published, reviewed, and been validated by dozens of
commercial and open source implementations available today.  I don't
care how small a new protocol might be, it will take it years to reach
the maturity of HTTP.

If it's a given that you have to implement the chosen protocol from
scratch, then I'd agree that this is a consideration.  But if middlebox
vendors are concerned about time-to-market, and about ensuring the
most secure environment possible, I think they would all want to have
the opportunity to reuse somebody else's battle-hardened implementation
of an existing protocol.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 11:12:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01112
	for ; Thu, 7 Feb 2002 11:12:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA28641
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 11:12:50 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28581;
	Thu, 7 Feb 2002 11:11:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28555
	for ; Thu, 7 Feb 2002 11:11:22 -0500 (EST)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01060
	for ; Thu, 7 Feb 2002 11:11:20 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.76])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g17GB26Y016551;
	Thu, 7 Feb 2002 11:11:02 -0500 (EST)
Message-ID: <3C62A6EA.30D931AC@dynamicsoft.com>
Date: Thu, 07 Feb 2002 11:10:18 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Baker 
CC: Martin.Stiemerling@ccrle.nec.de, midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
References: <200202071555.KAA11094@markbaker.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

If the only requirement for midcom were the ability to move data from
the agent to the middlebox, and possibly send data from the middebox
back to the agent, then HTTP might be a good fit (although asynchronous
push has never been part of its operation). However, based on these
requirements, I think  you might find that any protocol that exists
today will work. Most that I know of can move data from A to B and back.
How about SIP! Its arguably better than HTTP since it better handles
asynchonous messages in reverse. Of course, we shouldn't forget SOAP,
the catch-all for all protocols. How about BEEP? It would work too. FTP
might work. Hey, we could even have the agent telnet to the middlebox,
and exhcnage commands over telnet! Telnet is nice and thin. 

I'm amazed at how much time people worry about the underlying framework
protocol, which in the case of HTTP would do like 2% of the real work,
instead of worrying about the real protocol mechanisms. How do we
represent pinholes? Nat bindings? How do we group resources and allow
for them to be removed as a whole? How do resource timeouts work? What
kind of resource identifiers do we need? These are the real challenges
and the important work. Arguing whether to carry all of that on HTTP as
opposed to DIAMETER as opposed to MEGACO seems like a big waste of time.
It will also be a discussion which will likely take forever, since such
debates are usually based on anecdotes like "its more mature" which are
useless in making sound technical decisions. 

Why don't we worry about specifying the detailed semantics (NOT SYNTAX)
of the protocol, without assuming an underlying framework, and once the
entire protocol is specified, behaviorially, it will be a trivial
process to see exactly how each of those behaviors would map onto an
existing framework or protocol. I suspect most frameworks will provide a
small fraction of what is needed.

But, people seem to want to worry about the least important stuff first.
So be it. Wake me up when you are done so I can participate in the
important work.

-Jonathan R.
 

Mark Baker wrote:
> 
> > > Many of the requirements in 2.2 would also not be directly satisfied
> by
> > > HTTP, but would instead be satisfied by a data format (MidcomML?)
> that
> >
> > But in this case you have to define the MidcomML as well with states,
> > messages and so on.
> 
> This work would have to be done anyway, whether it's an ML or a MIB
> or whatever.  Right?
> 
> > Furthermore you have a huge protocol overhead due to
> > the use of HTTP. This is not a really small protocol anymore.
> 
> Just to be clear, by "huge protocol overhead", do you mean bloat in
> the protocol at runtime, or bloat in the specification (or something
> else?)?
> 
> If the former, there is some degree of truth to this since it's a text
> based protocol and sometimes transfers header information that isn't
> used.  But I've used it extensively, even in wireless environments
> (~1200bps), and I've never regretted the decision to use it.
> 
> If the latter, that's also true, RFC 2616 is a large specification.
> But it's already published, reviewed, and been validated by dozens of
> commercial and open source implementations available today.  I don't
> care how small a new protocol might be, it will take it years to reach
> the maturity of HTTP.
> 
> If it's a given that you have to implement the chosen protocol from
> scratch, then I'd agree that this is a consideration.  But if middlebox
> vendors are concerned about time-to-market, and about ensuring the
> most secure environment possible, I think they would all want to have
> the opportunity to reuse somebody else's battle-hardened implementation
> of an existing protocol.
> 
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 11:28:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01369
	for ; Thu, 7 Feb 2002 11:28:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA29386
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 11:28:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29300;
	Thu, 7 Feb 2002 11:25:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29261
	for ; Thu, 7 Feb 2002 11:25:45 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01305
	for ; Thu, 7 Feb 2002 11:25:41 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g17GPUj09995;
	Thu, 7 Feb 2002 17:25:30 +0100 (CET)
Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 40BF3C05B; Thu,  7 Feb 2002 17:24:37 +0100 (CET)
Date: Thu, 07 Feb 2002 17:41:50 +0100
From: Martin Stiemerling 
To: Mark Baker 
Cc: midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
Message-ID: <16240000.1013100110@elgar>
In-Reply-To: <200202071555.KAA11094@markbaker.ca>
References:  <200202071555.KAA11094@markbaker.ca>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Hi Mark,

--On Donnerstag, Februar 07, 2002 10:55:19 -0500 Mark Baker 
 wrote:

>> But in this case you have to define the MidcomML as well with states,
>> messages and so on.
>
> This work would have to be done anyway, whether it's an ML or a MIB
> or whatever.  Right?

Yes, you are right. The point is that, when you start designing a 
ML/MIB/whatever you start from the beginning and thus you use http only as 
a "transporter". The real work is not the "transporter", the real work is 
how pinholes/bindings are managed and so on.

>
>> Furthermore you have a huge protocol overhead due to
>> the use of HTTP. This is not a really small protocol anymore.
>
> Just to be clear, by "huge protocol overhead", do you mean bloat in
> the protocol at runtime, or bloat in the specification (or something
> else?)?

Sorry, I haven't been precisly enough, of course I mean both runtime 
overhead and specification.


>
> If the former, there is some degree of truth to this since it's a text
> based protocol and sometimes transfers header information that isn't
> used.  But I've used it extensively, even in wireless environments
> (~1200bps), and I've never regretted the decision to use it.
>
> If the latter, that's also true, RFC 2616 is a large specification.
> But it's already published, reviewed, and been validated by dozens of
> commercial and open source implementations available today.  I don't
> care how small a new protocol might be, it will take it years to reach
> the maturity of HTTP.

Yeah, but there is a trade-off between maturity and protocl thickness and 
in oppinion we have to make a lot of trade-offs anyway for the midcom 
protocol in the future.
Another point is, that http is stateles abd as far as I know we need a 
stateful protocol.


Martin


>
> If it's a given that you have to implement the chosen protocol from
> scratch, then I'd agree that this is a consideration.  But if middlebox
> vendors are concerned about time-to-market, and about ensuring the
> most secure environment possible, I think they would all want to have
> the opportunity to reuse somebody else's battle-hardened implementation
> of an existing protocol.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
>



Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories      Martin.Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de             IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 11:33:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01516
	for ; Thu, 7 Feb 2002 11:33:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA00152
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 11:33:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29807;
	Thu, 7 Feb 2002 11:30:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29776
	for ; Thu, 7 Feb 2002 11:30:36 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01424
	for ; Thu, 7 Feb 2002 11:30:33 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g17GUGj10144;
	Thu, 7 Feb 2002 17:30:16 +0100 (CET)
Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 4D1B9C05B; Thu,  7 Feb 2002 17:29:27 +0100 (CET)
Date: Thu, 07 Feb 2002 17:46:40 +0100
From: Martin Stiemerling 
To: Jonathan Rosenberg , Mark Baker 
Cc: midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
Message-ID: <16870000.1013100400@elgar>
In-Reply-To: <3C62A6EA.30D931AC@dynamicsoft.com>
References: <200202071555.KAA11094@markbaker.ca>
 <3C62A6EA.30D931AC@dynamicsoft.com>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

Comments are in the text.

Martin

--On Donnerstag, Februar 07, 2002 11:10:18 -0500 Jonathan Rosenberg 
 wrote:
[...]
> If the only requirement for midcom were the ability to move data from
> I'm amazed at how much time people worry about the underlying framework
> protocol, which in the case of HTTP would do like 2% of the real work,
> instead of worrying about the real protocol mechanisms. How do we

I agree with this point, but there should be always some room for 
discussions.

> represent pinholes? Nat bindings? How do we group resources and allow
> for them to be removed as a whole? How do resource timeouts work? What
> kind of resource identifiers do we need? These are the real challenges

There are some proposal that show some solutions for handling pinholes or 
bindings. So let start the technical discussions! ;-)



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 11:36:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01591
	for ; Thu, 7 Feb 2002 11:36:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA00402
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 11:36:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00284;
	Thu, 7 Feb 2002 11:35:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00249
	for ; Thu, 7 Feb 2002 11:35:09 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01545
	for ; Thu, 7 Feb 2002 11:35:06 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id LAA12111;
	Thu, 7 Feb 2002 11:37:37 -0500
Message-Id: <200202071637.LAA12111@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: Martin.Stiemerling@ccrle.nec.de (Martin Stiemerling)
Date: Thu, 7 Feb 2002 11:37:37 -0500 (EST)
Cc: midcom@ietf.org
In-Reply-To: <16240000.1013100110@elgar> from "Martin Stiemerling" at Feb 07, 2002 05:41:50 PM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> Another point is, that http is stateles abd as far as I know we need a 
> stateful protocol.

Ah, that's interesting.  I didn't get this from the requirements.
Could you direct me to the requirement that says, or suggests that?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb  7 11:47:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01990
	for ; Thu, 7 Feb 2002 11:47:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA01021
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 11:47:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00766;
	Thu, 7 Feb 2002 11:45:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00740
	for ; Thu, 7 Feb 2002 11:45:12 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01735
	for ; Thu, 7 Feb 2002 11:45:09 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id LAA12299;
	Thu, 7 Feb 2002 11:47:39 -0500
Message-Id: <200202071647.LAA12299@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: jdrosen@dynamicsoft.com (Jonathan Rosenberg)
Date: Thu, 7 Feb 2002 11:47:39 -0500 (EST)
Cc: Martin.Stiemerling@ccrle.nec.de, midcom@ietf.org
In-Reply-To: <3C62A6EA.30D931AC@dynamicsoft.com> from "Jonathan Rosenberg" at Feb 07, 2002 11:10:18 AM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> If the only requirement for midcom were the ability to move data from
> the agent to the middlebox, and possibly send data from the middebox
> back to the agent, then HTTP might be a good fit (although asynchronous
> push has never been part of its operation).

I'm sorry, but this completely misrepresents what HTTP is.  What you
describe there is a transport protocol, not an application protocol.
To people who think it's a transport protocol, I like to point out that
HTTP has two ways of transferring data; PUT and POST.  Each means
something different.  PUT means "replace", and POST means "append".

> How about SIP! Its arguably better than HTTP since it better handles
> asynchonous messages in reverse.

SIP would also be a good protocol to consider.

Neither SOAP nor BEEP provide any application semantics by themselves,
whereas SIP and HTTP do.  So you'd have to reinvent lots of stuff.

> I'm amazed at how much time people worry about the underlying framework
> protocol, which in the case of HTTP would do like 2% of the real work,
> instead of worrying about the real protocol mechanisms. How do we
> represent pinholes? Nat bindings? How do we group resources and allow
> for them to be removed as a whole? How do resource timeouts work? What
> kind of resource identifiers do we need?

MidcomML would help you represent these things.  URIs would provide
identity to them (each pinhole gets a URI, for example, so it can be
DELETEd or its characteristics changed with PUT or POST).  The HTTP
methods would help you manipulate those resources.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 14:15:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06290
	for ; Thu, 7 Feb 2002 14:15:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA11511
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 14:15:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10872;
	Thu, 7 Feb 2002 14:09:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10847
	for ; Thu, 7 Feb 2002 14:09:12 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06096
	for ; Thu, 7 Feb 2002 14:09:10 -0500 (EST)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g17J8w918305;
        Thu, 7 Feb 2002 14:09:01 -0500 (EST)
Message-Id: <200202071909.g17J8w918305@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore 
To: Jonathan Rosenberg 
cc: Mark Baker , Martin.Stiemerling@ccrle.nec.de,
        midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol 
In-reply-to: (Your message of "Thu, 07 Feb 2002 11:10:18 EST.") 
             <3C62A6EA.30D931AC@dynamicsoft.com> 
Date: Thu, 07 Feb 2002 14:08:58 -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

> But, people seem to want to worry about the least important stuff first.
> So be it. Wake me up when you are done so I can participate in the
> important work.

oh, didn't you realize that all problems are solved by HTTP and XML?
(which is just another way of saying that all problems are solved 
by adding another layer of indirection.)

I find it ironic that the main reason people want to run things over HTTP
is to get around NATs and firewalls, and now HTTP is being proposed as the
protocol to control NATs and firewalls.  In other words, HTTP has become 
its own justification.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 14:29:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06772
	for ; Thu, 7 Feb 2002 14:29:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA11998
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 14:29:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11945;
	Thu, 7 Feb 2002 14:27:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11914
	for ; Thu, 7 Feb 2002 14:27:54 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06729
	for ; Thu, 7 Feb 2002 14:27:51 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id OAA15161;
	Thu, 7 Feb 2002 14:30:22 -0500
Message-Id: <200202071930.OAA15161@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: moore@cs.utk.edu (Keith Moore)
Date: Thu, 7 Feb 2002 14:30:22 -0500 (EST)
Cc: midcom@ietf.org
In-Reply-To: <200202071909.g17J8w918305@astro.cs.utk.edu> from "Keith Moore" at Feb 07, 2002 02:08:58 PM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> oh, didn't you realize that all problems are solved by HTTP and XML?

(don't forget URIs)

Sarcasm aside, do you believe HTTP is inappropriate for *this* problem,
and if so, which requirement do you think it doesn't meet?

> (which is just another way of saying that all problems are solved 
> by adding another layer of indirection.)

Well, no, it isn't.  It's a way of saying that if you create a general
enough coordination language, then a whole lot of problems can be solved
*within* the constraints of that language, not as a layer on top (what's
on top of the application layer anyhow?).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 14:35:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07084
	for ; Thu, 7 Feb 2002 14:35:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA12711
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 14:35:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12617;
	Thu, 7 Feb 2002 14:34:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12586
	for ; Thu, 7 Feb 2002 14:34:35 -0500 (EST)
Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07031
	for ; Thu, 7 Feb 2002 14:34:28 -0500 (EST)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by corb.mc.mpls.visi.com (Postfix) with ESMTP
	id 688A08162; Thu,  7 Feb 2002 13:34:29 -0600 (CST)
Received: by isis.visi.com (Postfix, from userid 2286)
	id A9E5D76C27; Thu,  7 Feb 2002 13:34:28 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
	by isis.visi.com (Postfix) with ESMTP
	id 9D22A76C26; Thu,  7 Feb 2002 13:34:28 -0600 (CST)
Date: Thu, 7 Feb 2002 13:34:28 -0600 (CST)
From: Andrew Molitor 
To: Mark Baker 
Cc: Keith Moore , midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
In-Reply-To: <200202071930.OAA15161@markbaker.ca>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org



On Thu, 7 Feb 2002, Mark Baker wrote:

> > oh, didn't you realize that all problems are solved by HTTP and XML?
> 
> (don't forget URIs)
> 
> Sarcasm aside, do you believe HTTP is inappropriate for *this* problem,
> and if so, which requirement do you think it doesn't meet?

	Yes. Performance.

	When I am attempting to process 1,000 transactions per
second on the embedded processor controlling my middlebox, the
last thing I need to do is laboriously decode 4K of garp
shooting out of a TCP socket, per transaction.

	HTTP is, after a fashion, universal. It's universal in the
same way as a Turing machine built from great oaken gears and
levers is universal.



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 14:41:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07290
	for ; Thu, 7 Feb 2002 14:41:53 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA12921
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 14:41:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12694;
	Thu, 7 Feb 2002 14:35:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12661
	for ; Thu, 7 Feb 2002 14:35:35 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07054
	for ; Thu, 7 Feb 2002 14:35:33 -0500 (EST)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g17JZX918641;
        Thu, 7 Feb 2002 14:35:33 -0500 (EST)
Message-Id: <200202071935.g17JZX918641@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore 
To: Mark Baker 
cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol 
In-reply-to: (Your message of "Thu, 07 Feb 2002 14:30:22 EST.") 
             <200202071930.OAA15161@markbaker.ca> 
Date: Thu, 07 Feb 2002 14:35:33 -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

> > oh, didn't you realize that all problems are solved by HTTP and XML?
> 
> (don't forget URIs)
> 
> Sarcasm aside, do you believe HTTP is inappropriate for *this* problem,
> and if so, which requirement do you think it doesn't meet?

HTTP contributes nothing (other than overhead and confusion) to solving 
the problem.

> > (which is just another way of saying that all problems are solved
> > by adding another layer of indirection.)
> 
> Well, no, it isn't.  It's a way of saying that if you create a general
> enough coordination language, then a whole lot of problems can be solved
> *within* the constraints of that language, not as a layer on top (what's
> on top of the application layer anyhow?).

As Jonathan pointed out, the hard part is getting the semantics right, 
and HTTP doesn't help there in the least.  (nor does XML)

I'd also claim that the last thing midcom needs is a connection setup/
teardown, plus SSL negotiation, every time some process needs to establish 
a pinhole through a NAT.  And no, persistent connections aren't a general 
solution to the problem.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 15:12:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08250
	for ; Thu, 7 Feb 2002 15:12:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA14430
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 15:12:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14273;
	Thu, 7 Feb 2002 15:08:41 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14246
	for ; Thu, 7 Feb 2002 15:08:37 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08125
	for ; Thu, 7 Feb 2002 15:08:34 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id PAA15943;
	Thu, 7 Feb 2002 15:11:06 -0500
Message-Id: <200202072011.PAA15943@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: moore@cs.utk.edu (Keith Moore)
Date: Thu, 7 Feb 2002 15:11:06 -0500 (EST)
Cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
In-Reply-To: <200202071935.g17JZX918641@astro.cs.utk.edu> from "Keith Moore" at Feb 07, 2002 02:35:33 PM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> As Jonathan pointed out, the hard part is getting the semantics right, 
> and HTTP doesn't help there in the least.  (nor does XML)

It's a matter of modelling the problem domain as a set of resources
identified by URIs.  If you do that, the only application semantics you
need are GET, PUT, POST, and DELETE.

Off the top of my head, you'd need resources such as;

http://mymiddlebox.org/pinholes

A GET would return a list of current pinholes, with each pinhole being
its own resource.  Invoking GET on each pinhole would describe that
pinhole (PinholeML?), which could be changed locally, then PUT back to
commit the change.  Invoking DELETE would remove the pinhole.

> I'd also claim that the last thing midcom needs is a connection setup/
> teardown, plus SSL negotiation, every time some process needs to establish 
> a pinhole through a NAT.

How often is that done?  The requirements don't say.  I'd be surprised
(and concerned) if pinholes were being established with a periodicity
anywhere near the time it takes to negotiate a HTTPS connection.

>  And no, persistent connections aren't a general 
> solution to the problem.

That's possible.  But I didn't see anything in the requirements that
suggested that a stateless, connection based protocol couldn't be used.
Do the requirements need updating?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 15:20:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08494
	for ; Thu, 7 Feb 2002 15:20:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA14947
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 15:20:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14761;
	Thu, 7 Feb 2002 15:18:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14732
	for ; Thu, 7 Feb 2002 15:18:30 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08427
	for ; Thu, 7 Feb 2002 15:18:26 -0500 (EST)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g17KIR918798;
        Thu, 7 Feb 2002 15:18:27 -0500 (EST)
Message-Id: <200202072018.g17KIR918798@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore 
To: Mark Baker 
cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol 
In-reply-to: (Your message of "Thu, 07 Feb 2002 15:11:06 EST.") 
             <200202072011.PAA15943@markbaker.ca> 
Date: Thu, 07 Feb 2002 15:18:27 -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

> > As Jonathan pointed out, the hard part is getting the semantics right,
> > and HTTP doesn't help there in the least.  (nor does XML)
> 
> It's a matter of modelling the problem domain as a set of resources
> identified by URIs.  If you do that, the only application semantics you
> need are GET, PUT, POST, and DELETE.

I disagree with all of the above -

- modeling the problem domain as a set of resources doesn't make
  sense when those resources interact in arbitrary ways

- identifying the resources with URIs just adds cruft

- trying to coerce the semantics of midcom's requirements to fit
  onto existing HTTP methods is probably not a good idea . 

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 16:54:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10956
	for ; Thu, 7 Feb 2002 16:54:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA19278
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 16:54:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19119;
	Thu, 7 Feb 2002 16:49:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19093
	for ; Thu, 7 Feb 2002 16:49:44 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10838
	for ; Thu, 7 Feb 2002 16:49:42 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id QAA17110;
	Thu, 7 Feb 2002 16:52:15 -0500
Message-Id: <200202072152.QAA17110@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: moore@cs.utk.edu (Keith Moore)
Date: Thu, 7 Feb 2002 16:52:15 -0500 (EST)
Cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
In-Reply-To: <200202072018.g17KIR918798@astro.cs.utk.edu> from "Keith Moore" at Feb 07, 2002 03:18:27 PM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> I disagree with all of the above -
> 
> - modeling the problem domain as a set of resources doesn't make
>   sense when those resources interact in arbitrary ways

Show me in RFC 2616 where it says that resource state changes can't
affect changes in the state of other resources.

> - identifying the resources with URIs just adds cruft
> 
> - trying to coerce the semantics of midcom's requirements to fit
>   onto existing HTTP methods is probably not a good idea . 

Coerce?  What, my /pinhole example looked kludgy?  Note that I forgot to
add that if you wanted to create a new pinhole, you could just POST a
description of a pinhole to /pinhole, and get a 201 (Created) response
back with the Location header providing the URI of the new pinhole.

I challenge you to name a midcom application semantic that cannot be
modelled and implemented in this manner.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 17:03:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11123
	for ; Thu, 7 Feb 2002 17:03:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA20236
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 17:03:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20116;
	Thu, 7 Feb 2002 17:01:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20088
	for ; Thu, 7 Feb 2002 17:01:42 -0500 (EST)
Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11109
	for ; Thu, 7 Feb 2002 17:01:40 -0500 (EST)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by conn.mc.mpls.visi.com (Postfix) with ESMTP id 64DB9813F
	for ; Thu,  7 Feb 2002 16:01:43 -0600 (CST)
Received: by isis.visi.com (Postfix, from userid 2286)
	id 3409776C27; Thu,  7 Feb 2002 16:01:43 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
	by isis.visi.com (Postfix) with ESMTP id 31E6876C26
	for ; Thu,  7 Feb 2002 16:01:43 -0600 (CST)
Date: Thu, 7 Feb 2002 16:01:43 -0600 (CST)
From: Andrew Molitor 
To: midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
In-Reply-To: <200202072152.QAA17110@markbaker.ca>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org



> I challenge you to name a midcom application semantic that cannot be
> modelled and implemented in this manner.

	You're missing the point.

	Of course you can drive any nail you like with a bulldozer.
Nobody has claimed that HTTP wouldn't work. It's pretty obvious to
everyone that it could be made to work. The various points being made
are that:

	- bulldozers don't make very good hammers
	- hey, wouldn't it be good to figure out what nails we want to
	  drive where before we start buying bulldozers to drive them?



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 17:03:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11143
	for ; Thu, 7 Feb 2002 17:03:45 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA20264
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 17:03:46 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20186;
	Thu, 7 Feb 2002 17:02:41 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20155
	for ; Thu, 7 Feb 2002 17:02:38 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11115
	for ; Thu, 7 Feb 2002 17:02:36 -0500 (EST)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g17M2b919577;
        Thu, 7 Feb 2002 17:02:37 -0500 (EST)
Message-Id: <200202072202.g17M2b919577@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore 
To: Mark Baker 
cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol 
In-reply-to: (Your message of "Thu, 07 Feb 2002 16:52:15 EST.") 
             <200202072152.QAA17110@markbaker.ca> 
Date: Thu, 07 Feb 2002 17:02:37 -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

> > I disagree with all of the above -
> > 
> > - modeling the problem domain as a set of resources doesn't make
> >   sense when those resources interact in arbitrary ways
> 
> Show me in RFC 2616 where it says that resource state changes can't
> affect changes in the state of other resources.

For some reason, I've never accepted RFC 2616 as an example of good 
protocol design. 

> > - identifying the resources with URIs just adds cruft
> > 
> > - trying to coerce the semantics of midcom's requirements to fit
> >   onto existing HTTP methods is probably not a good idea .
> 
> Coerce?  

Yes, coerce.  It seems better to figure out what the semantics should
be than to figure out how to get the semantics to fit into a bed that
was designed for a completely different person...er, purpose.

> I challenge you to name a midcom application semantic that cannot be
> modelled and implemented in this manner.

"Cannot" doesn't seem like a useful criterion.  I can make you fit 
into my bed with appropriate application of chains and/or axe.  
But that doesn't mean you'll like it.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 17:56:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12083
	for ; Thu, 7 Feb 2002 17:56:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA22362
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 17:56:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22148;
	Thu, 7 Feb 2002 17:48:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22117
	for ; Thu, 7 Feb 2002 17:48:23 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11922
	for ; Thu, 7 Feb 2002 17:48:20 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id RAA18211;
	Thu, 7 Feb 2002 17:50:54 -0500
Message-Id: <200202072250.RAA18211@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: moore@cs.utk.edu (Keith Moore)
Date: Thu, 7 Feb 2002 17:50:53 -0500 (EST)
Cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
In-Reply-To: <200202072202.g17M2b919577@astro.cs.utk.edu> from "Keith Moore" at Feb 07, 2002 05:02:37 PM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> > Show me in RFC 2616 where it says that resource state changes can't
> > affect changes in the state of other resources.
> 
> For some reason, I've never accepted RFC 2616 as an example of good 
> protocol design. 

Fine.  But I want to address your concern here that I can't use HTTP and
resource modelling because a state change to one can't affect another.
Please show me where any version of HTTP says that.  Or, if you think
it's so poorly designed that it forget to say that, please tell me why
you think that.

> > I challenge you to name a midcom application semantic that cannot be
> > modelled and implemented in this manner.
> 
> "Cannot" doesn't seem like a useful criterion.  I can make you fit 
> into my bed with appropriate application of chains and/or axe.  
> But that doesn't mean you'll like it.

Well, let's see shall we.  I already covered off pinhole creation,
deletion, and modification without much bloodshed.  Pick another one.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 18:15:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12490
	for ; Thu, 7 Feb 2002 18:15:15 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA23348
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 18:15:18 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23272;
	Thu, 7 Feb 2002 18:13:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23244
	for ; Thu, 7 Feb 2002 18:13:51 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12428
	for ; Thu, 7 Feb 2002 18:13:46 -0500 (EST)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g17NDl920001;
        Thu, 7 Feb 2002 18:13:47 -0500 (EST)
Message-Id: <200202072313.g17NDl920001@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore 
To: Mark Baker 
cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol 
In-reply-to: (Your message of "Thu, 07 Feb 2002 17:50:53 EST.") 
             <200202072250.RAA18211@markbaker.ca> 
Date: Thu, 07 Feb 2002 18:13:47 -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

> > > Show me in RFC 2616 where it says that resource state changes can't
> > > affect changes in the state of other resources.
> > 
> > For some reason, I've never accepted RFC 2616 as an example of good
> > protocol design.
> 
> Fine.  But I want to address your concern here that I can't use HTTP and
> resource modelling because a state change to one can't affect another.

Since that's not what I said, I won't bother responding.  
 
> > > I challenge you to name a midcom application semantic that cannot be
> > > modelled and implemented in this manner.
> > 
> > "Cannot" doesn't seem like a useful criterion.  I can make you fit
> > into my bed with appropriate application of chains and/or axe.
> > But that doesn't mean you'll like it.
> 
> Well, let's see shall we.  I already covered off pinhole creation,
> deletion, and modification without much bloodshed.  Pick another one.

Let me try one more time:

Just because you carry your forehead with you everywhere you go
does not mean it's a good tool to use for hammering nails.
(even if you do manage to hammer a few nails with it) 

The challenge that this group faces is to make a good protocol for 
allowing applications to work with NATs, not to figure out a new 
way to use HTTP.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 18:21:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12633
	for ; Thu, 7 Feb 2002 18:21:06 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA23713
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 18:21:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23434;
	Thu, 7 Feb 2002 18:19:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23400
	for ; Thu, 7 Feb 2002 18:19:50 -0500 (EST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12565
	for ; Thu, 7 Feb 2002 18:19:42 -0500 (EST)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617);
	 Thu, 7 Feb 2002 15:18:58 -0800
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Feb 2002 15:19:11 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 7 Feb 2002 15:18:57 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 7 Feb 2002 15:18:57 -0800
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Thu, 7 Feb 2002 15:16:45 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [midcom] HTTP as the Midcom protocol 
Date: Thu, 7 Feb 2002 15:16:45 -0800
Message-ID: 
Thread-Topic: [midcom] HTTP as the Midcom protocol 
Thread-Index: AcGwLQWE/F6QePiHRhSKiu7NUvr+RgAAIjbw
From: "Christian Huitema" 
To: "Keith Moore" , "Mark Baker" 
Cc: 
X-OriginalArrivalTime: 07 Feb 2002 23:16:45.0757 (UTC) FILETIME=[82CCEED0:01C1B02D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA23401
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit

> The challenge that this group faces is to make a good protocol for
> allowing applications to work with NATs, not to figure out a new
> way to use HTTP.

Yep. In fact, HTTP is a particularly bad idea, because you end up being
bothered by a lot of paraphernalia, e.g. what to do with cookies,
whether there is a relation between the http proxy and the NAT, etc. Not
to mention boxes that will detect you are doing HTTP and "transparently"
reroute your query...

-- Christian Huitema

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb  7 21:28:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16174
	for ; Thu, 7 Feb 2002 21:28:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA00909
	for midcom-archive@odin.ietf.org; Thu, 7 Feb 2002 21:28:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00713;
	Thu, 7 Feb 2002 21:21:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00687
	for ; Thu, 7 Feb 2002 21:21:38 -0500 (EST)
Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16072
	for ; Thu, 7 Feb 2002 21:21:35 -0500 (EST)
Received: (from mbaker@localhost)
	by markbaker.ca (8.9.3/8.8.7) id VAA20608;
	Thu, 7 Feb 2002 21:24:07 -0500
Message-Id: <200202080224.VAA20608@markbaker.ca>
Subject: Re: [midcom] HTTP as the Midcom protocol
To: moore@cs.utk.edu (Keith Moore)
Date: Thu, 7 Feb 2002 21:24:06 -0500 (EST)
Cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
In-Reply-To: <200202072313.g17NDl920001@astro.cs.utk.edu> from "Keith Moore" at Feb 07, 2002 06:13:47 PM
From: Mark Baker 
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

> The challenge that this group faces is to make a good protocol for 
> allowing applications to work with NATs, not to figure out a new 
> way to use HTTP.

It would *NOT* (!!!) be a new way to use HTTP.  It would be using HTTP
the way hundreds of millions of people use it each day, and the way it
was designed to be used.  Just instead of URIs for books, weblogs, news,
and porn, there'd be URIs for middleboxes, rulesets, and pinholes.  HTTP
doesn't care; they're just resources to be manipulated with the same
generic set of methods.

The Web is not your typical application, and its domain of applicability
is only "limited" to things with identity.  Witness the recent example
of somebody putting a web server in a lego brick.

Another view on this might also be helpful;

http://www.xml.com/pub/a/2002/02/06/rest.html

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Fri Feb  8 00:09:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20330
	for ; Fri, 8 Feb 2002 00:09:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA06482
	for midcom-archive@odin.ietf.org; Fri, 8 Feb 2002 00:09:47 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06352;
	Fri, 8 Feb 2002 00:07:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06323
	for ; Fri, 8 Feb 2002 00:07:29 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20281
	for ; Fri, 8 Feb 2002 00:07:29 -0500 (EST)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g1857S921272;
        Fri, 8 Feb 2002 00:07:28 -0500 (EST)
Message-Id: <200202080507.g1857S921272@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore 
To: Mark Baker 
cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol 
In-reply-to: (Your message of "Thu, 07 Feb 2002 21:24:06 EST.") 
             <200202080224.VAA20608@markbaker.ca> 
Date: Fri, 08 Feb 2002 00:07:28 -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

> The Web is not your typical application, and its domain of applicability
> is only "limited" to things with identity. 

Whatever gave you the idea that midcom had anything to do with "the Web"?
Or, for that matter, that "the Web" requires use of HTTP?

As attractive as it might sound, I don't think it works to try to coerce
the ideas of lots of different people into a single paradigm or protocol.

But this has nothing to do with midcom, so I'll stop here.

Keith

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb  8 05:05:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02318
	for ; Fri, 8 Feb 2002 05:05:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA27930
	for midcom-archive@odin.ietf.org; Fri, 8 Feb 2002 05:05:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27418;
	Fri, 8 Feb 2002 04:59:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27387
	for ; Fri, 8 Feb 2002 04:59:23 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02281
	for ; Fri, 8 Feb 2002 04:59:20 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g189xBj13375;
	Fri, 8 Feb 2002 10:59:11 +0100 (CET)
Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id E246AC05B; Fri,  8 Feb 2002 10:58:20 +0100 (CET)
Date: Fri, 08 Feb 2002 10:58:19 +0100
From: Martin Stiemerling 
To: Mark Baker 
Cc: midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
Message-ID: <7450000.1013162299@elgar>
In-Reply-To: <200202071637.LAA12111@markbaker.ca>
References:  <200202071637.LAA12111@markbaker.ca>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

--On Donnerstag, Februar 07, 2002 11:37:37 -0500 Mark Baker 
 wrote:

>> Another point is, that http is stateles abd as far as I know we need a
>> stateful protocol.
>
> Ah, that's interesting.  I didn't get this from the requirements.
> Could you direct me to the requirement that says, or suggests that?

As far as I see, this is not explicitly mentioned in the requirements, but 
midcom has to maintain pinholes and bindings in a middle box and therefore 
the midcom protocol should remember what it is doing with the middle box, 
i.e. states are needed.

Martin


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb  8 08:50:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06459
	for ; Fri, 8 Feb 2002 08:50:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA08095
	for midcom-archive@odin.ietf.org; Fri, 8 Feb 2002 08:50:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07943;
	Fri, 8 Feb 2002 08:49:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07918
	for ; Fri, 8 Feb 2002 08:49:14 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06387
	for ; Fri, 8 Feb 2002 08:49:11 -0500 (EST)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g18Dmge14747
	for ; Fri, 8 Feb 2002 05:48:42 -0800 (PST)
Received: from SBRIM-W2K (sjc-vpn2-442.cisco.com [10.21.113.186])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAN02197;
	Fri, 8 Feb 2002 05:48:44 -0800 (PST)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 8 Feb 2002 08:48:34 -0500
Date: Fri, 8 Feb 2002 08:48:34 -0500
From: Scott Brim 
To: midcom@ietf.org
Subject: Re: [midcom] HTTP as the Midcom protocol
Message-ID: <20020208084834.A1820@SBRIM-W2K>
Mail-Followup-To: Scott Brim , midcom@ietf.org
References: <200202071637.LAA12111@markbaker.ca> <7450000.1013162299@elgar>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <7450000.1013162299@elgar>; from Martin.Stiemerling@ccrle.nec.de on Fri, Feb 08, 2002 at 10:58:19AM +0100
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

On Fri, Feb 08, 2002 10:58:19AM +0100, Martin Stiemerling wrote:
> --On Donnerstag, Februar 07, 2002 11:37:37 -0500 Mark Baker 
>  wrote:
> 
> >> Another point is, that http is stateles abd as far as I know we need a
> >> stateful protocol.
> >
> > Ah, that's interesting.  I didn't get this from the requirements.
> > Could you direct me to the requirement that says, or suggests that?
> 
> As far as I see, this is not explicitly mentioned in the requirements, but 
> midcom has to maintain pinholes and bindings in a middle box and therefore 
> the midcom protocol should remember what it is doing with the middle box, 
> i.e. states are needed.

No.  The requirements are that the interaction between agent and
middlebox be deterministic and that agent and middlebox must be able to
establish a known and stable state.  We say nothing about where state
information related to a particular rule is even held, except that each
side must maintain at least basic state related to its own functioning.
We certainly say nothing about *how* the protocol accomplishes this.  

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb  8 13:49:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19162
	for ; Fri, 8 Feb 2002 13:49:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA28467
	for midcom-archive@odin.ietf.org; Fri, 8 Feb 2002 13:49:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28204;
	Fri, 8 Feb 2002 13:44:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28176
	for ; Fri, 8 Feb 2002 13:44:33 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19001
	for ; Fri, 8 Feb 2002 13:44:30 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g18Ihst26375;
	Fri, 8 Feb 2002 10:43:54 -0800 (PST)
Received: from fluffyw2k (dhcp-128-107-142-47.cisco.com [128.107.142.47])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ABZ65276;
	Fri, 8 Feb 2002 10:44:05 -0800 (PST)
From: "Cullen Jennings" 
To: , "Rohan Mahy" ,
        "Jonathan Rosenberg" ,
        , 
Date: Fri, 8 Feb 2002 10:42:49 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Subject: [midcom] Which port to put in the Changed-Address attribute?
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


All comments referring to draft-rosenberg-midcom-stun-00.txt

Imagine the case where a STUN server is running on two interfaces, A and B.
This could be on one computer or as a second server on another computer. Now
lets say I am using ports 5000 and 5001 and interface A and 6000 and 6001 on
interface B. When A gets a request, if no flags are set it will return a
response from 5000. If the change ip flag is set it will get a response from
port 6000 on IP B. If both flags are set, it will get a response from 6001
on IP B.

Now the 3rd paragraph on page 7 says "The server must add a CHANGE-ADDRESS
attribute ... that contains the source IP address and port that would be
used ...". It clear I put the address of B in but what port do I put in
5001, 6000, or 6001?

I can see two responses too this:

1) you can't do that - if you use port 5000 and 5001 on A you MUST use 5000
and 5001 on B.

2) we need to add a bit to deal with this case

I'm in favor or option 1 but wanted to make sure this is what the authors
had intended.

Thanks, Cullen




_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb  8 13:49:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19178
	for ; Fri, 8 Feb 2002 13:49:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA28486
	for midcom-archive@odin.ietf.org; Fri, 8 Feb 2002 13:49:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28162;
	Fri, 8 Feb 2002 13:44:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28131
	for ; Fri, 8 Feb 2002 13:44:00 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18990
	for ; Fri, 8 Feb 2002 13:43:57 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g18IhIh19339;
	Fri, 8 Feb 2002 10:43:18 -0800 (PST)
Received: from fluffyw2k (dhcp-128-107-142-47.cisco.com [128.107.142.47])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ABZ65254;
	Fri, 8 Feb 2002 10:43:28 -0800 (PST)
From: "Cullen Jennings" 
To: , "Rohan Mahy" ,
        "Jonathan Rosenberg" ,
        , 
Date: Fri, 8 Feb 2002 10:42:12 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Subject: [midcom] tag value for CHANGED-ADDRESS
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


All comments referring to draft-rosenberg-midcom-stun-00.txt

Section 10.2.3 defines a CHANGED-ADDRESS attribute yet the list of constants
in section 10.2 does not defined a constant to indicate this attribute.

I suggest adding to the table in section 10.2 a line like the following

0x0005: CHANGED-ADDRESS

Thanks, Cullen



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb  8 22:20:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01151
	for ; Fri, 8 Feb 2002 22:20:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA20470
	for midcom-archive@odin.ietf.org; Fri, 8 Feb 2002 22:20:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20128;
	Fri, 8 Feb 2002 22:05:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20089
	for ; Fri, 8 Feb 2002 22:05:56 -0500 (EST)
Received: from localhost ([211.107.101.159])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01005
	for ; Fri, 8 Feb 2002 22:05:51 -0500 (EST)
Message-Id: <200202090305.WAA01005@ietf.org>
Reply-To: pricelist@hutmail.com
From: 컴정보
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Sat, 9 Feb 2002 12:05:52 +0900
Subject: [midcom] {광 고} 컴퓨터가격정보 메일링 회원이 되세요..
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org



컴퓨터 가격정보 메일링 신청 받습니다.



먼저 허락없이 글을 올린것에 대해 진심으로 사과말씀 드립니다.
귀하의 이메일 주소는
인터넷 게시판을 통하여 취합하였습니다


컴퓨터 가격정보를 
매일 매일 회원님의 이메일로 발송해 드리는
서비스입니다.
항상 최신의 가격정보가 회원님의 이메일속에 담겨져 있게 해드리겠습니다.

현재 일간(화,목,토요일 발행) 및
주간(목요일 발행) 형태로 발행중입니다.
일요일 및 공휴일은 발행을 하지 않습니다.

물론 본 서비스는 무료입니다.


구독신청은 메일주소만 써주시면 끝입니다.. 간단하죠..^^




 





컴퓨터 가격정보 [일간] 

































 





컴퓨터 가격정보 [주간] 
































 



한메일 사용자용 [일간]
















 

컴퓨터가격정보



 



한메일 사용자용 [주간]
















 

컴퓨터가격정보


지난메일링보기 ★


본 메일로 기분 상하셨다면 깊이사과 드립니다.!
수신거부 해주시면 반복발송하지 않도록 하겠습니다.
본메일은 1회성 메일입니다.


수신거부 <== 수신거부는 꼭 요기를 눌러주세요.. 감사합니다.




_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Sun Feb 10 03:24:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03867
	for ; Sun, 10 Feb 2002 03:24:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA00701
	for midcom-archive@odin.ietf.org; Sun, 10 Feb 2002 03:24:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00465;
	Sun, 10 Feb 2002 03:11:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00438
	for ; Sun, 10 Feb 2002 03:11:35 -0500 (EST)
Received: from relay6.kornet.net ([211.48.62.166])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03774
	for ; Sun, 10 Feb 2002 03:11:31 -0500 (EST)
Received: from vivi-41a7ime526 (218.148.231.34) by relay6.kornet.net; 10 Feb 2002 17:10:57 +0900
Message-ID: <3c662b113c731480@relay6.kornet.net> (added by relay6.kornet.net)
From: =?ks_c_5601-1987?B?VklWSSBLT1JFQQ==?= 
To: midcom@ietf.org
Date: Sun, 10 Feb 2002 17:10:50 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0177_01C0F10A.93A50C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [midcom] =?ks_c_5601-1987?B?W7GksO1dIG1pZGNvbbTUILChsbiw+MDlv6G8rSDGr7qwx9LAzrCht84gsO2x3rv9yLCwobG4uKYgurizu7XluLO0z7TZLg==?=
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0177_01C0F10A.93A50C00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

vsiz58fPvLy/5C4NCg0KsKGxuMD8ua6+98O8ILrxuvHE2riuvsYgwNS0z7TZLg0KDQqw7bHe
ILv9yLCwobG4uKYgvsbB1iDA+rfFx9EgsKGw3cC4t84gxvfDtSCwobG4sPi03L+hvK0gwffB
oiDGx7jFx9W0z7TZLg0KDQrA5bfVLCC87sbELCDEp7Trte4gMjAwMrPiILq9wMcgw9a9xbjw
tai3ziC18MDawM7AzLOqIMDnwfq46b+hvK0NCr/svPbH0SDBpsewwLsgvLHBpMfPv6kgxse4
xcfPsO0gwNa9wLTPtNkuDQoNCrHiwbggsKGxuMGhwMcgNDAlfjYwJcGktbUgwPq3xcfPsNQg
xse4xcfPsO0gwNa+xr/AtM8NCrLAIMfRufggyKjG5MDMwfa4piC6uL3DseIgudm2+LTPtNku
DQoNCrChsbiwoSDHyr/kx8+9w7jpILChsbjA/LmusKHAziDA+sjxv80gwMez7cfYIMHWvcq9
w7/AIA0KQS9TILimILrxt9THz7+pILy6vcfH0SDA2ry8t84gw9a8scC7ILTZIMfPsNq9wLTP
tNkuDQoNCmh0dHA6Ly93d3cudml2aS5jby5rci8NCg0KtOe757TCILHNu+cox88pv6EgsPzH
z7+pIL7Guau3sSDBpLq4tbUgsK6w7SDA1sH2vsq9wLTPtNkuDQq02bi4IMDMuN7AzyDA2rW/
w9/D4rHit84gwMy43sDPuLggwKW758DMxq6/obytIMPfw+LHz7+0vcC0z7TZDQq89r3FsMW6
ziDHz73HutDAuiC/qbHiIGh0dHA6Ly93d3cuY3J1c2FkZS5jby5rci9yZWplY3QvcmVqZWN0
LnBocD9pZD0yMjQxJmF1dGg9YjZlMzIzMjBmYTZiYzVhNTg4YjkwMTgzYjk1ZGMwMjgmbWFp
bD1taWRjb21AaWV0Zi5vcmcmbW9kZT13cml0ZSC4piDFrLivx9ggwda9yr3Dv8AuDQoNCg==

------=_NextPart_000_0177_01C0F10A.93A50C00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

vsiz58fPvLy/5C4NCg0KsKGxuMD8ua6+98O8ILrxuvHE2riuvsYgwNS0z7TZLg0KDQqw7bHe
ILv9yLCwobG4uKYgvsbB1iDA+rfFx9EgsKGw3cC4t84gxvfDtSCwobG4sPi03L+hvK0gwffB
oiDGx7jFx9W0z7TZLg0KDQrA5bfVLCC87sbELCDEp7Trte4gMjAwMrPiILq9wMcgw9a9xbjw
tai3ziC18MDawM7AzLOqIMDnwfq46b+hvK0NCr/svPbH0SDBpsewwLsgvLHBpMfPv6kgxse4
xcfPsO0gwNa9wLTPtNkuDQoNCrHiwbggsKGxuMGhwMcgNDAlfjYwJcGktbUgwPq3xcfPsNQg
xse4xcfPsO0gwNa+xr/AtM8NCrLAIMfRufggyKjG5MDMwfa4piC6uL3DseIgudm2+LTPtNku
DQoNCrChsbiwoSDHyr/kx8+9w7jpILChsbjA/LmusKHAziDA+sjxv80gwMez7cfYIMHWvcq9
w7/AIA0KQS9TILimILrxt9THz7+pILy6vcfH0SDA2ry8t84gw9a8scC7ILTZIMfPsNq9wLTP
tNkuDQoNCmh0dHA6Ly93d3cudml2aS5jby5rci8NCg0KtOe757TCILHNu+cox88pv6EgsPzH
z7+pIL7Guau3sSDBpLq4tbUgsK6w7SDA1sH2vsq9wLTPtNkuDQq02bi4IMDMuN7AzyDA2rW/
w9/D4rHit84gwMy43sDPuLggwKW758DMxq6/obytIMPfw+LHz7+0vcC0z7TZDQq89r3FsMW6
ziDHz73HutDAuiC/qbHiIGh0dHA6Ly93d3cuY3J1c2FkZS5jby5rci9yZWplY3QvcmVqZWN0
LnBocD9pZD0yMjQxJmF1dGg9YjZlMzIzMjBmYTZiYzVhNTg4YjkwMTgzYjk1ZGMwMjgmbWFp
bD1taWRjb21AaWV0Zi5vcmcmbW9kZT13cml0ZSC4piDFrLivx9ggwda9yr3Dv8AuDQoNCg==

------=_NextPart_000_0177_01C0F10A.93A50C00--


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Mon Feb 11 00:07:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17390
	for ; Mon, 11 Feb 2002 00:07:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA08292
	for midcom-archive@odin.ietf.org; Mon, 11 Feb 2002 00:07:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07518;
	Sun, 10 Feb 2002 23:59:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07487
	for ; Sun, 10 Feb 2002 23:59:45 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17317
	for ; Sun, 10 Feb 2002 23:59:41 -0500 (EST)
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1B4x8M22611
	for ; Sun, 10 Feb 2002 22:59:09 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <1MAFWPP8>; Sun, 10 Feb 2002 20:59:03 -0800
Message-ID: <4F973E944951D311B6660008C7917CF00898226F@zsc4c008.us.nortel.com>
From: "Reinaldo Penno"
To: midcom@ietf.org
Date: Sun, 10 Feb 2002 20:59:04 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1B2B8.D41FB960"
Subject: [midcom] Minutes of the January 11, 2001 IESG meeting. - Midcom
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1B2B8.D41FB960
Content-Type: text/plain;
	charset="iso-8859-1"

<..snip>

3. The IESG approved creation of the Middlebox Communication (midcom) 
    Working Group. Steve to make sure the latest description is 
    available prior to sending out an announcement.

http://www.ietf.org/iesg/iesg.2001-01-11

What exactly this means?

thanks,

Reinaldo

------_=_NextPart_001_01C1B2B8.D41FB960
Content-Type: text/html;
	charset="iso-8859-1"






Minutes of the January 11, 2001 IESG meeting. - Midcom




<snip...><..snip>




3. The IESG approved creation of the Middlebox Communication (midcom) 

    Working Group. Steve to make sure the latest description is 

    available prior to sending out an announcement.




http://www.ietf.org/iesg/iesg.2001-01-11




What exactly this means?




thanks,




Reinaldo





------_=_NextPart_001_01C1B2B8.D41FB960--

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Mon Feb 11 00:08:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17438
	for ; Mon, 11 Feb 2002 00:08:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA08364
	for midcom-archive@odin.ietf.org; Mon, 11 Feb 2002 00:08:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08070;
	Mon, 11 Feb 2002 00:04:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08039
	for ; Mon, 11 Feb 2002 00:04:54 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17371
	for ; Mon, 11 Feb 2002 00:04:55 -0500 (EST)
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1B54NM22767
	for ; Sun, 10 Feb 2002 23:04:24 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <1MAFWPQN>; Sun, 10 Feb 2002 21:04:18 -0800
Message-ID: <4F973E944951D311B6660008C7917CF008982270@zsc4c008.us.nortel.com>
From: "Reinaldo Penno"
To: midcom@ietf.org
Subject: RE: [midcom] Minutes of the January 11, 2001 IESG meeting. - Midc
	om
Date: Sun, 10 Feb 2002 21:04:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1B2B9.8F26E7B0"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1B2B9.8F26E7B0
Content-Type: text/plain;
	charset="iso-8859-1"

soorry about this message. I tought it was 2002..

-----Original Message-----
From: Penno, Reinaldo [SC9:T327:EXCH] 
Sent: Sunday, February 10, 2002 8:59 PM
To: midcom@ietf.org
Subject: [midcom] Minutes of the January 11, 2001 IESG meeting. - Midcom



<..snip> 

3. The IESG approved creation of the Middlebox Communication (midcom) 
    Working Group. Steve to make sure the latest description is 
    available prior to sending out an announcement. 

http://www.ietf.org/iesg/iesg.2001-01-11
  

What exactly this means? 

thanks, 

Reinaldo 


------_=_NextPart_001_01C1B2B9.8F26E7B0
Content-Type: text/html;
	charset="iso-8859-1"




Minutes of the January 11, 2001 IESG meeting. - Midcom




soorry 
about this message. I tought it was 2002..



  
-----Original Message-----
From: Penno, Reinaldo 
  [SC9:T327:EXCH] 
Sent: Sunday, February 10, 2002 8:59 
  PM
To: midcom@ietf.org
Subject: [midcom] Minutes of the 
  January 11, 2001 IESG meeting. - Midcom


  
<snip...><..snip> 

  
3. The IESG approved creation of the Middlebox Communication 
  (midcom) 
    Working Group. Steve to 
  make sure the latest description is 
    
  available prior to sending out an announcement. 

  
http://www.ietf.org/iesg/iesg.2001-01-11 

  
What exactly this means? 

  
thanks, 

  
Reinaldo 


------_=_NextPart_001_01C1B2B9.8F26E7B0--

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Mon Feb 11 10:19:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05207
	for ; Mon, 11 Feb 2002 10:19:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA13388
	for midcom-archive@odin.ietf.org; Mon, 11 Feb 2002 10:19:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13007;
	Mon, 11 Feb 2002 10:12:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12967
	for ; Mon, 11 Feb 2002 10:12:05 -0500 (EST)
Received: from moonship ([218.11.36.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04946
	for ; Mon, 11 Feb 2002 10:12:01 -0500 (EST)
Message-Id: <200202111512.KAA04946@ietf.org>
From: "Liu Qi" 
To: "midcom" 
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Date: Mon, 11 Feb 2002 23:17:58
Subject: [midcom] Sell Chinese Forklifts
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

Dear Sir and Madam,

We sell Chinese Forklift from 4 tons, 5 tons, 6 tons, and 7 tons
lifting capacity.

Chinese Forklifts are good quality with the most competitive
price. If you are interested, please contact us at:

moonship2000@etang.com
moonship@heinfo.net

All request will be replyed with photos, specifications
and price list.

Best Regards.
Liu Qi.
president of Moonship International Trade Corporation
http://www.moonship.esmartbiz.com
moonship2000@etang.com
moonship@heinfo.net
liuqi@excite.com
Tel&Fax:+86-315-2737253


賈痰섐槿錟숭횐랙，轟伎繫법錟숭륩蛟포，殮댐뚤렘錟芎，醵똑없뚤寧직！
苟潼貢囹：http://love2net.51.net/，뫘뜩출롤돨낚욉흡숭된콱윱苟∼∼

----------------------------------------------------
INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.
----------------------------------------------------

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Wed Feb 13 21:23:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25918
	for ; Wed, 13 Feb 2002 21:23:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA15918
	for midcom-archive@odin.ietf.org; Wed, 13 Feb 2002 21:23:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15355;
	Wed, 13 Feb 2002 21:07:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15288
	for ; Wed, 13 Feb 2002 21:07:50 -0500 (EST)
Received: from moonship ([218.11.34.237])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25677
	for ; Wed, 13 Feb 2002 21:07:38 -0500 (EST)
Message-Id: <200202140207.VAA25677@ietf.org>
From: "Liu Qi" 
To: "midcom" 
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Date: Thu, 14 Feb 2002 10:13:49
Subject: [midcom] Sell Chinese Forklifts
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

Dear Sir and Madam,

We sell Chinese Forklift from 
1.5 tons, 2 tons, 3 tons 4 tons, 5 tons, 6 tons, and 7 tons
lifting capacity.

Chinese Forklifts are good quality with the most competitive
price. If you are interested, please contact us at:

moonship2000@etang.com
moonship@heinfo.net

All request will be replyed with photos, specifications
and price list.

Best Regards.
Liu Qi.
president of Moonship International Trade Corporation
http://www.moonship.esmartbiz.com
moonship2000@etang.com
moonship@heinfo.net
liuqi@excite.com
Tel&Fax:+86-315-2737253


賈痰섐槿錟숭횐랙，轟伎繫법錟숭륩蛟포，殮댐뚤렘錟芎，醵똑없뚤寧직！
苟潼貢囹：http://love2net.51.net/，뫘뜩출롤돨낚욉흡숭된콱윱苟∼∼

----------------------------------------------------
INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.
----------------------------------------------------

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Wed Feb 13 23:14:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01840
	for ; Wed, 13 Feb 2002 23:14:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA26323
	for midcom-archive@odin.ietf.org; Wed, 13 Feb 2002 23:14:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24450;
	Wed, 13 Feb 2002 23:10:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24421
	for ; Wed, 13 Feb 2002 23:10:48 -0500 (EST)
Received: from localhost ([211.222.117.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01529
	for ; Wed, 13 Feb 2002 23:10:38 -0500 (EST)
Message-Id: <200202140410.XAA01529@ietf.org>
Reply-To: gtech@gtech21.com
From: (주)지텍
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Thu, 14 Feb 2002 13:09:28 +0900
Subject: [midcom] 획기적인 휴대폰용 이어폰!!!!!  [광고]
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org




mail02-1















⊙ 허락없이 메일을 보내서 죄송합니다.

⊙ 본메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.

⊙ e-mail 주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다.

⊙ 수신을 원치 않으시면 '수신거부'를 눌러주세요.
[수신거부]


















 















 














 















 






































































           












 




























 






























 




















(주)지텍 인천광역시 계양구 작전동 852-73 Tel:(032)552-7222

E-mail : gtech@gtech21.com    Homepage : http://www.gtech21.com





































 









_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb 14 07:10:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16082
	for ; Thu, 14 Feb 2002 07:10:06 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA24898
	for midcom-archive@odin.ietf.org; Thu, 14 Feb 2002 07:10:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24563;
	Thu, 14 Feb 2002 07:03:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24536
	for ; Thu, 14 Feb 2002 07:03:29 -0500 (EST)
Received: from mail.njbs.com.cn ([61.155.107.205])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15637
	for ; Thu, 14 Feb 2002 07:03:26 -0500 (EST)
Message-Id: <200202141203.HAA15637@ietf.org>
Received: from smtp0301.mail.yahoo.com (mail.steelplan.com.au [203.47.13.2]) by mail.njbs.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 13Q7NCLD; Thu, 14 Feb 2002 19:55:58 +0800
Reply-To: servinginthenameofgod99@yahoo.com
From: servinginthenameofgod99210000@yahoo.com
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 14 Feb 2002 06:22:38 -0500
Subject: [midcom] Where Others Deny You, We Will Not
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

STREET BISHOPS, a U.S. based international ministry, has the authority to ORDAIN you tomorrow. More than 100 have joined us since the new year!  We feel so blessed.  

STREET BISHOPS believes that ordination should be given to all who ask. One of the benefits of being a LEGAL member of the clergy is that you will be authorized to perform the rites and ceremonies of the church. They include:

WEDDINGS - You can earn part-time income officiating marriages on weekends. Couples are searching for a wedding officiates. Most states require that you register your certificate (THAT WE SEND YOU) prior to conducting the ceremony. Some pastors work full-time as a wedding officiate, so can you! And we'll put you in our database of officates which receives thousands of requests for ordained ministers!

FUNERALS - The simple fact is that people die every day, providing a never-ending need for funeral officiates. 

BAPTISMS - What a special way to welcome a child of God. As millions return to church and desire these official ceremonies, you are there to assist them! This adds to your part or full time income as a minister!

PRISON MINISTRIES - Since you will be a Certified Minister, you can visit others in need. Assist those who are ready to CHANGE their lives - You can play a major part in that decision!

HOSPITOL MINISTRIES - A an ordained clergy, you can be listed with most hospitals and conduct a successful hospital ministry. 

WANT TO START YOUR OWN CHURCH? After your ordination, you may start your own congregation! We can offer much assistance as you begin your new place of worship.

WHAT ARE PEOPLE SAYING? "You are truly an answer to prayer for myself and for hundrededs, if not thousands, of men who have been frustrated with constitution, laws, and by-laws of most denominations who have denied bretheren who have answered the call of God." - Colorado Springs, Colorado., "We've been wanting to take communion during the weeks we are without a Priest, and now we are able to do that." - Greenwith, Australia 

IS THIS A SCAM? No way. Our ministry is thriving, peoples lives are being touched, and you can be a part of this awesome movement to make a difference in the world!  We are a real ministry, doing real ministry work, and enabling you to join us in this exciting profession.

WHAT IS REQUIRED? That you intend to become ordained to honestly bring love, understanding, peace, comfort, compassion, and forgiveness to the world. No degrees needed, no hoops to jump through, no restrictions on gender or any other rediculous hurdle. Promise to honor God and that is all that's required.

YOU RECEIVE a professionally printed 8-inch by 10-inch color certificate and Letter of Ordination/Proof of Minister Certification in your name. We pay the U.S. shipping. For Shipping OUTSIDE the U.S. please add $15.00.

NEWSLETTER. You will also begin receiving our helpful newsletter with advice and answers as you begin your new ministry. This is what makes us very different from the others, we provide support along with the credentials.

THE STREET BISHOP gaol is to make this life changing step easy and affordable so average folks like you can benefit from the advantages of being ordained, and you can be enabled to serve others. The administrative costs for processing the ordination is only $29.00.

FAX: To place your order by fax, complete the following form and fax to 1-413-487-7457, or use postal mail..  

MAIL: For Cash, Check, or Money Order, complete the form below, make your check payable to "TSG" and mail to

Ordination Committee
3206 South Hopkins Ave, #89
Titusville, Florida 32780 U.S.A.

The committee meets every other day, all applications processed within 3 days of receiving them. 

Check all that apply:

__________ $29.00 for your Ordination Certificate/Credentials
__________ $15.00 for International Shipping (if outside the US, $6 if in Canada)
__________ Optional: $19 for personalized, laminated Identification Badge with lapel clip
__________ Optional: $15 for "Birch Liturgies" - a collection of more than 35 ceremonies to guide you through your new profession. (CD ROM)

(Please print very clearly in dark ink)

---------------- Ordination Information ------------------------X371-380-02142002

Name of Applicant:

Academic Degree (if any):

Address:

City, State, Zip Code:

Phone Number:

Email Address:

Religion:

Denomination (if any):

Preferred Title: (example Rev., Pastor, Fr., Priest, etc):

Ministry Area of Interest (Congregational, Hospital, Prison, Marriage Officiating, etc):

Website (if any):

Although not required, by sending us a one page writing of why you are seeking Ordination, you will guide us in supporting you in your ministry.

------------ If Paying By Credit Card Use This Form  ----------------------------

Name on Credit Card: 

Address:

City/State/ZIP:

Your email address: 

Type of Card, circle one:             Visa          MasterCard         Discover
(Sorry, no American Express.)

Credit Card Number: 

Date Credit Card Expires: 

Phone Number: 

Fax Number: 

------------------------------------------------------
To be removed from our mailing list, fax address to 1-313-557-2776. Our understanding at the time of this mailing is that this is a legal form of marketing, similar to postal mail. Evidence otherwise is encouraged and requested via fax. We are doing our best to exclude those individuals who do not desire to receive materials of this type. Thank you for your consideration.

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb 15 10:52:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08823
	for ; Fri, 15 Feb 2002 10:52:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA27028
	for midcom-archive@odin.ietf.org; Fri, 15 Feb 2002 10:52:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26749;
	Fri, 15 Feb 2002 10:49:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26721
	for ; Fri, 15 Feb 2002 10:49:38 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08705
	for ; Fri, 15 Feb 2002 10:49:35 -0500 (EST)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1FFn7E29785
	for ; Fri, 15 Feb 2002 07:49:07 -0800 (PST)
Received: from spandex.cisco.com (ssh-sj1.cisco.com [171.68.225.134])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACV94647;
	Fri, 15 Feb 2002 07:47:18 -0800 (PST)
Message-Id: <5.1.0.14.0.20020215104801.0385fec0@localhost>
X-Sender: mshore@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Feb 2002 10:52:40 -0500
To: midcom@ietf.org
From: Melinda Shore 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Current status
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

Just to let you know where we are:

1) Both the framework and requirements documents are in IESG
   review.  We haven't gotten any feedback yet.
2) A proposed revised charter is being reviewed by the ADs and
   by, I think, the IESG.  Likewise, we haven't gotten any 
   feedback yet.
3) The pre-midcom design team is finishing up the STUN document
   and is starting on the other piece of work.  We're (ADs)
   near agreement on the updated charter text covering the pre-
   midcom work.

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb 15 10:53:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08862
	for ; Fri, 15 Feb 2002 10:53:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA27082
	for midcom-archive@odin.ietf.org; Fri, 15 Feb 2002 10:53:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26490;
	Fri, 15 Feb 2002 10:44:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26465
	for ; Fri, 15 Feb 2002 10:44:56 -0500 (EST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08459
	for ; Fri, 15 Feb 2002 10:44:48 -0500 (EST)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1FFi9Z06831
	for ; Fri, 15 Feb 2002 07:44:10 -0800 (PST)
Received: from spandex.cisco.com (ssh-sj1.cisco.com [171.68.225.134])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACV94541;
	Fri, 15 Feb 2002 07:42:29 -0800 (PST)
Message-Id: <5.1.0.14.0.20020215104508.038550b0@localhost>
X-Sender: mshore@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Feb 2002 10:47:51 -0500
To: midcom@ietf.org
From: Melinda Shore 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Minneapolis
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

We are tentatively scheduled to meet on Thursday, from 3:30pm
to 5:30pm.  Also scheduled during that time are:

APP	calsch	 Calendaring and Scheduling WG
APP     vpim     Voice Profile for Internet Mail WG
OPS     siked    Secure Internet Key Distribution BOF
SEC	idwg	 Intrusion Detection Exchange Format WG
TSV     ips      IP Storage WG

The primary items on the agenda are the pre-midcom work
and rechartering status.  Please let me know if there's
anything else you feel needs to be discussed during the
meeting.

Thanks,

Melinda


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb 15 11:31:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10243
	for ; Fri, 15 Feb 2002 11:31:52 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA00207
	for midcom-archive@odin.ietf.org; Fri, 15 Feb 2002 11:31:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29430;
	Fri, 15 Feb 2002 11:29:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29399
	for ; Fri, 15 Feb 2002 11:29:30 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10180
	for ; Fri, 15 Feb 2002 11:29:27 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1FGTjj52638;
	Fri, 15 Feb 2002 17:29:45 +0100 (CET)
Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 674D3C040; Fri, 15 Feb 2002 17:28:50 +0100 (CET)
Date: Fri, 15 Feb 2002 17:28:47 +0100
From: Martin Stiemerling 
To: Melinda Shore , midcom@ietf.org
Subject: Re: [midcom] Minneapolis
Message-ID: <1810000.1013790527@elgar>
In-Reply-To: <5.1.0.14.0.20020215104508.038550b0@localhost>
References:  <5.1.0.14.0.20020215104508.038550b0@localhost>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit




> The primary items on the agenda are the pre-midcom work
> and rechartering status.  Please let me know if there's

It would be interesting to talk about the current midcom protocol 
proposals, like simco, and thus start/continue the discussions about the 
midcom protocol.

> anything else you feel needs to be discussed during the
> meeting.
>
> Thanks,
>
> Melinda
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>



Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories      Martin.Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de             IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb 15 22:24:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26772
	for ; Fri, 15 Feb 2002 22:24:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA03017
	for midcom-archive@odin.ietf.org; Fri, 15 Feb 2002 22:24:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02834;
	Fri, 15 Feb 2002 22:13:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02809
	for ; Fri, 15 Feb 2002 22:13:47 -0500 (EST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26639
	for ; Fri, 15 Feb 2002 22:13:43 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1G3D1Z16757
	for ; Fri, 15 Feb 2002 19:13:02 -0800 (PST)
Received: from fluffyw2k (dhcp-128-107-142-47.cisco.com [128.107.142.47])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACB19911;
	Fri, 15 Feb 2002 19:13:21 -0800 (PST)
From: "Cullen Jennings" 
To: 
Date: Fri, 15 Feb 2002 19:12:02 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Subject: [midcom] note to design team on STUN
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


Would be nice if any 32 bit values like address in the message were aligned
on word boundaries.


Thanks, Cullen



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Fri Feb 15 22:38:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27921
	for ; Fri, 15 Feb 2002 22:38:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA03971
	for midcom-archive@odin.ietf.org; Fri, 15 Feb 2002 22:38:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03768;
	Fri, 15 Feb 2002 22:37:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03738
	for ; Fri, 15 Feb 2002 22:37:20 -0500 (EST)
Received: from lycos.com ([211.220.51.242])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27885
	for ; Fri, 15 Feb 2002 22:36:58 -0500 (EST)
Message-Id: <200202160336.WAA27885@ietf.org>
Reply-To: kjoi_dj33@lycos.com
From: 마케터 
To: 
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Sat, 16 Feb 2002 12:36:56 +0900
X-User: 2.63-figjdliv-lilkhn-Ddigq
Subject: [midcom] [광고]새로운 사업이나 부업을 찾으십니까?
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org







▶ 허락없이 홍보메일을 보내게 된 점 사과드립니다. 
▶ 정보통신망이용촉진법규정을 준수하여 광고메일임을 표시하였읍니다. 
▶ 
전자우편주소는 인터넷상에서 취득하였으며, 전자우편주소외 어떠한 개인 정보도 가지고 있지 않습니다


 !!!! 
지금 이순간 님께서 저희 다이너스티를 만나신 것은 대단한 행운이라 확신합니다. !!!!            

 


반갑습니다. 
저는 부산에서 직장을 다니면서 부업으로 이 사업을 진행하고 있는 장강민이란 사람입니다. 
적극적이고 열정적으로 
살면서 자기 발전을 위해 끊임없이 노력하고 있습니다. 


사업은 물론 만나서 대화를 나누어야 가장 좋겠지만, 우선 서면으로 대략을 알려드리니 살 펴보시고 계속 관심이 있으시면 연락주시기 
바랍니다.... 


 


사업의 개념이 이해하기쉽고, 네트웤을 형성하는 방법이 on-line, off-line 으로 다양하고, 듣는 사람도 너무나 쉽게 납득할 수 
있기 때문에 누구나 하실 수가 있습니다. 


특히 기존에 어떤 형식이든 네트웤 마케팅을 하고 계시는 분들이면 더욱 잘 하실 수 
있습니다. 


 


이 사업은 통신 사업 중 가장먼저 시작된 새로운 사업으로서 다이너스티 라는 회사로 별정통신1호와 2호의 회사입니다.


자본 없이도 자기사업을 하는것과 같으며 시간이 흐름에 따라 점차 그 규모가 커져 1년 후 회원 수와 매출액면에서 비교가 안 될 정도로 
확장되는 굉장히 비젼이 있는 사업입니다. 


 


아마도 주변에서 아는분들이 다단계 사업을 하시면서 같이 사업해 보지 않겠냐는 제안 한 두 번쯤 안 들어보신 분들 거의없으리라 
생각됩니다.


그렇지만 다단계가 뭡니까. 기존 시장의 유통구조를 바꾸어 즉 중간유통단계(총판, 대리점) 또는 광고없이 구전에 의한판매로 중간단계에서 
발생되는 지출을 줄여 그수익을 소비자에게 환원시켜주는 선진형 판매방식입니다.


네트웍 사업은 회원들의 재구매가 빠른 제품으로 구성되어야 한다는것은 잘아시겠죠? 


우리가 하루도 전화를 걸지 않고는 살아갈 수 없다는 것을 님께서도 인정하십니까? 
바로 이 전화요금을 현재 기간통신에 후불로 
납부하는것을 선불로 카드에 충전해서 쓰는것이 사업입니다. 


 


2000년도 국내 소비시장중 통신시장규모는 자그만치 약24조원이었으며 2001년도는 아직 통계가 나오지 않아 잘모르지만 훨씬 늘어났으며 
참고로 말씀드린다면 쌀소비시장은 약 1조원, 자동차시장-약6조, 유류(석유)시장-약6조원이었습니다. 
통신시장 규모가 얼마나 큰시장인지 
짐작이 가시겠죠? 


이 거대통신시장이 이대로 개방된다면우리나라 신경인 통신은 그대로 외국유수업체에 잠식 당할 수 밖에 없습니다.


그래서 정부에서 별정통신을 허용하여 개인전화국(1호사업자)으로 하여금 개방이전에 국제경쟁력을 갖추기 위한 국책사업입니다. 


통합선불카드 하나로 시내.외,공중전화 통화는 물론 휴대폰 기종,번호변경없이 011부터 019까지 축기능으로 많은 버튼을 누르지 않고 
온가족이 함께 간편하게 사용하실수 있습니다.



물론 상기내용은 아주 기본적인 내용이구요.
자기밑으로 2명만 둘수 있는 바이너리 구조입니다


이외에도 부가산업도 뿐만아니라  수익구조,전자상거래등등 하고싶은 이야기는 많으나 이정도로 설명을 해드리구요 더궁굼하신것들은 직접 
상담을 하시거나 회사의 홈페이지를 둘러보시면 되겠읍니다. 


 


http://www.dynastytel.co.kr(별정통신) 

http://www.clubaqua.co.kr(여행사)
http://www.visiondynasty.com(전자상거래)
http://www.e-dynasty.co.kr(홈페이지)
연락처 : 
codejang@intizen.com
H.P    
: 019-596-9808
수신거부 : e-dynasty@simmani.com 또는 아래의 수신거부 버튼을 
눌러주세요


 


 



원치않으시면  수신거부 를 눌러주시고 제목에 수신거부라고 적어주시기 바랍니다.
불편을 드렸다면 죄송합니다.

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Sun Feb 17 13:53:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09800
	for ; Sun, 17 Feb 2002 13:53:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA22027
	for midcom-archive@odin.ietf.org; Sun, 17 Feb 2002 13:53:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21957;
	Sun, 17 Feb 2002 13:50:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21927
	for ; Sun, 17 Feb 2002 13:50:42 -0500 (EST)
Received: from yourwebsite.com (adsl-66-136-202-106.dsl.austtx.swbell.net [66.136.202.106])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09776
	for ; Sun, 17 Feb 2002 13:50:38 -0500 (EST)
From: RCPMailing@hotmail.com
Message-Id: <200202171850.NAA09776@ietf.org>
Reply-To: RCPMailing@hotmail.com
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sun, 17 Feb 2002 12:50:59 -0600
Subject: [midcom] Receive $2 for every envelope you stuff for our company!
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

Receive $2 for every envelope you stuff for our company! No experience required! Visit http://www.rcplanet.tv for more information!

Regards,
RCPM Staff


















This is a one time e-mail and you will not recieve any more e-mails from us.

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Mon Feb 18 06:07:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00104
	for ; Mon, 18 Feb 2002 06:07:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA13952
	for midcom-archive@odin.ietf.org; Mon, 18 Feb 2002 06:07:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13817;
	Mon, 18 Feb 2002 06:03:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13786
	for ; Mon, 18 Feb 2002 06:03:32 -0500 (EST)
Received: from netra.bnu.edu.cn (netra.bnu.edu.cn [202.112.80.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00061
	for ; Mon, 18 Feb 2002 06:03:26 -0500 (EST)
Received: from smtp0105.mail.yahoo.com ([64.112.134.74])
	by netra.bnu.edu.cn (8.9.1a/8.9.1) with SMTP id TAA21742;
	Mon, 18 Feb 2002 19:04:02 +0800 (CST)
Message-Id: <200202181104.TAA21742@netra.bnu.edu.cn>
From: saveonlife2713@excite.com
To: midcom1@gte.net
CC: midcom@ietf.org, midcowboy@yahoo.com, midda@sover.net, middaugh@juno.com,
        middcoke@kih.net, middcon@midplains.net, midder@westerncom.net,
        middle-east@silverplatter.com
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Mon, 18 Feb 2002 06:04:34 -0500
Subject: [midcom] Life Insurance Price Wars
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

















TOP Life Companies Continue to Slash Rates 


Save up to 70% on your LIFE INSURANCE today! 


Term Insurance Comparisons 


Permanent (Whole/Universal) Life 


Burial/Final Expense 


CLICK HERE 


Get a  free quote for 


the coverage that 


Bests suits YOUR needs. 


Quotes from over 300 top rated companies 


 


 
 Please
note that by requesting your quote you have not opted-in to any mailing list. We
have a stringent privacy policy and we warrant that we will NEVER use the
data provided to us by you for any purpose except to provide you the quotes you
request.
This email ad is being sent in full compliance with U.S. Senate Bill 1618, Title #3, section 301. We honor all removal requests. 
To be removed from our mailing list click here


. 




_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Mon Feb 18 15:09:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16339
	for ; Mon, 18 Feb 2002 15:09:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA09103
	for midcom-archive@odin.ietf.org; Mon, 18 Feb 2002 15:09:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09039;
	Mon, 18 Feb 2002 15:07:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09010
	for ; Mon, 18 Feb 2002 15:07:11 -0500 (EST)
Received: from yahoo.com (IDENT:nobody@[210.178.180.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16228
	for ; Mon, 18 Feb 2002 15:06:59 -0500 (EST)
From: youcherry@yahoo.com
Message-Id: <200202182006.PAA16228@ietf.org>
Reply-To: youcherry@yahoo.com
To: midcom@ietf.org
Date: 18 Feb 2002 20:39:21 GMT
MIME-Version: 1.0
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [midcom] Take me.
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit



  

    
      


        Can you break my cherry?

      
Click
        Here and give it a try...

        

        

         

      		
  




Little sluts are waiting for your big dick!

  What are you waiting for?


  HERE






























Note: this is not a spam email. This email
was sent to you because your email was entered in on a website requesting to be
a registered subscriber. If you did not request this email, please just answer on this mail.





_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Tue Feb 19 09:22:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20276
	for ; Tue, 19 Feb 2002 09:22:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA07678
	for midcom-archive@odin.ietf.org; Tue, 19 Feb 2002 09:22:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07487;
	Tue, 19 Feb 2002 09:20:32 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07428
	for ; Tue, 19 Feb 2002 09:20:28 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20152
	for ; Tue, 19 Feb 2002 09:20:25 -0500 (EST)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1JEJut15401
	for ; Tue, 19 Feb 2002 06:19:56 -0800 (PST)
Received: from spandex.cisco.com (ssh-sj1.cisco.com [171.68.225.134])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with ESMTP id ACW52779;
	Tue, 19 Feb 2002 06:18:08 -0800 (PST)
Message-Id: <5.1.0.14.0.20020219091910.0133f150@localhost>
X-Sender: mshore@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Feb 2002 09:23:34 -0500
To: midcom@ietf.org
From: Melinda Shore 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Fwd: concern over the use of terms in the midcom framework
 document
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

By way of an update:

1) I've heard informally that the requirements document has been
   approved by the IESG
2) I've appended IESG feedback on the framework document - there
   are some concerns about terminology.  As you'll recall we originally
   had some difficulty coming to agreement on items 2, 3, and 4, but I 
   don't think that the recommended changes are out of keeping with the 
   spirit of the decisions we finally arrived at.

Melinda


>I reviewed the MIDCOM document and have the following concerns:
>(Luckily the draft uses the terms consistently - perhaps wholesale
>find/replace operations can be performed.)
>
>1.  Policy Server - Mentioned at the end of the Intro (Section 1), defined
>in Section 2.9 and further discussed throughout the document.  The MIDCOM
>draft defines a Policy Server as "a management entity that acts in advisory
>capacity and interfaces with a middlebox to communicate policies concerning
>authorization of MIDCOM agents gaining access to middlebox resources. ...
>the middlebox will consult the Policy Server and obtain the agent profile to
>validate session setup and authorization of the agent ..."
>
>The policy terminology RFC defines a Policy Server as "a marketing term
>whose definition is imprecise.  Originally, [R2753] referenced a "policy
>server."  As the RFC evolved, this term became more precise and known as the
>Policy Decision Point (PDP).  Today, the term is used in marketing and other
>literature to refer specifically to a PDP, or for any entity that
>uses/services policy."
>
>I would recommend changing the MIDCOM terminology - a MIDCOM "policy server"
>is primarily a Policy Decision Point and also acts as a policy repository,
>holding MIDCOM related policy information/profiles/etc in order to make the
>authorization decisions.  Specifically from the terminology RFC, a PDP is
>defined as "a logical entity that makes policy decisions for itself or for
>other network elements that request such decisions"; and a policy repository
>is "a specific data store that holds policy rules, their conditions and
>actions, and related policy data".
>
>
>2. Filter spec - Defined in Section 2.13 and used in subsequent sections of
>the document.  The MIDCOM draft defines a Filter Spec as "Packet matching
>information that identifies a set of packets to be treated a certain way by
>a middlebox."  (BTW, there is a typo in the definition in that it says
>"filter spec is a Packet matching information ..." - the "a" should not be
>there.)
>
>The policy terminology RFC defines this simply as a "filter" ("A set of
>terms and/or criteria used for the purpose of separating or categorizing.
>This is accomplished via single- or multi-field matching of traffic header
>and/or payload data.").
>
>I would recommend using the simpler term, "filter", and not defining another
>variant of it.
>
>
>3. Action spec - Defined in Section 2.14 and used in subsequent
>sections/text.  The MIDCOM draft defines an Action Spec as "a description of
>the middlebox treatment/service to be applied to a set of packets."  This is
>consistent with the definition of a "policy action" in the terminology RFC
>("Definition of what is to be done to enforce a policy rule, when the
>conditions of the rule are met.  Policy actions may result in the execution
>of one or more operations to affect and/or configure network traffic and
>network resources.").
>
>I would recommend using the term, "action" or "policy action", and not
>defining another variant of it.
>
>
>4. Ruleset - Defined in Section 2.15 and used in subsequent sections/text.
>The MIDCOM draft defines a Ruleset as "The combination of one or more filter
>Specs and one or more action Specs. Packets matching the filter Spec(s) are
>to be treated as specified by the associated action Spec(s)."  This is the
>essence of a "policy rule" in the terminology RFC and PCIM - "the binding of
>a set of actions to a set of conditions - where the conditions are evaluated
>to determine whether the actions are performed."
>
>I would recommend changing the MIDCOM terminology - a MIDCOM "ruleset" is a
>"policy rule" where the "filters" are the conditions and the "actions" are
>as defined above. 


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Tue Feb 19 11:24:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26211
	for ; Tue, 19 Feb 2002 11:24:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA16101
	for midcom-archive@odin.ietf.org; Tue, 19 Feb 2002 11:24:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16034;
	Tue, 19 Feb 2002 11:22:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16004
	for ; Tue, 19 Feb 2002 11:22:47 -0500 (EST)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26121
	for ; Tue, 19 Feb 2002 11:22:44 -0500 (EST)
Received: from jku2.iptel.org (dhcp165.fokus.gmd.de [195.37.78.165])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g1JGMDH27145;
	Tue, 19 Feb 2002 17:22:13 +0100
Message-Id: <5.1.0.14.0.20020219171837.01dc80c0@mailhost.fokus.gmd.de>
X-Sender: jiri@iptel.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Feb 2002 17:22:05 +0100
To: midcom@ietf.org
From: Jiri Kuthan 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [midcom] Fwd: I-D ACTION:draft-iab-arch-changes-00.txt
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

FYI

>To: IETF-Announce: ;
>From: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-iab-arch-changes-00.txt
>Date: Tue, 19 Feb 2002 07:09:54 -0500
>Sender: nsyracus@cnri.reston.va.us
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Internet Architecture Board Working Group of the IETF.
>
>        Title           : Recent Changes in the Architectural Principles of the 
>                          Internet
>        Author(s)       : B. Carpenter, R. Austein
>        Filename        : draft-iab-arch-changes-00.txt
>        Pages           : 9
>        Date            : 18-Feb-02


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Tue Feb 19 11:42:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26724
	for ; Tue, 19 Feb 2002 11:42:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA17594
	for midcom-archive@odin.ietf.org; Tue, 19 Feb 2002 11:42:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17395;
	Tue, 19 Feb 2002 11:39:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17367
	for ; Tue, 19 Feb 2002 11:39:42 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26611
	for ; Tue, 19 Feb 2002 11:39:39 -0500 (EST)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1JGdBt01582;
	Tue, 19 Feb 2002 08:39:11 -0800 (PST)
Received: from SBRIM-W2K (sjc-vpn3-159.cisco.com [10.21.64.159])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAO00528;
	Tue, 19 Feb 2002 08:39:13 -0800 (PST)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 19 Feb 2002 11:39:10 -0500
Date: Tue, 19 Feb 2002 11:39:10 -0500
From: Scott Brim 
To: Melinda Shore 
Cc: midcom@ietf.org
Subject: Re: [midcom] Fwd: concern over the use of terms in the midcom framework document
Message-ID: <20020219113909.H1520@SBRIM-W2K>
Mail-Followup-To: Scott Brim ,
	Melinda Shore , midcom@ietf.org
References: <5.1.0.14.0.20020219091910.0133f150@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.1.0.14.0.20020219091910.0133f150@localhost>; from mshore@cisco.com on Tue, Feb 19, 2002 at 09:23:34AM -0500
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

On Tue, Feb 19, 2002 09:23:34AM -0500, Melinda Shore wrote:
>    As you'll recall we originally
>    had some difficulty coming to agreement on items 2, 3, and 4, but I 
>    don't think that the recommended changes are out of keeping with the 
>    spirit of the decisions we finally arrived at.

I think there's a fine difference.

Policy Server -> PDP is okay with me.

The rest, though ... 

First, we were referring to what is communicated, in the protocol.  That
is, the specification of the {filter, action, rule}, not its meaning.
The appended "spec" was significant, and is not incompatible with the
use of "filter" suggested in that message.

Second, a ruleset was exactly that.  A set of one *or more* rules, not
just a single rule as in the offered definition.  The rules might be
independent, not just a single set of actions bound to a single set of
conditions.

..Scott

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Tue Feb 19 12:11:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27903
	for ; Tue, 19 Feb 2002 12:11:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA21010
	for midcom-archive@odin.ietf.org; Tue, 19 Feb 2002 12:11:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20916;
	Tue, 19 Feb 2002 12:10:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20886
	for ; Tue, 19 Feb 2002 12:10:06 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27845
	for ; Tue, 19 Feb 2002 12:10:03 -0500 (EST)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1JH9Zt19240;
	Tue, 19 Feb 2002 09:09:35 -0800 (PST)
Received: from SBRIM-W2K.cisco.com (sjc-vpn3-159.cisco.com [10.21.64.159])
	by airborne.cisco.com (Mirapoint)
	with ESMTP id AAO00891;
	Tue, 19 Feb 2002 09:09:37 -0800 (PST)
X-Mailer: emacs 21.1.1 (via feedmail 11-beta-1 I);
	VM 7.01 under Emacs 21.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15474.34508.467000.835523@gargle.gargle.HOWL>
Date: Tue, 19 Feb 2002 12:09:32 -0500
From: Scott Brim 
To: Melinda Shore , midcom@ietf.org
Subject: Re: [midcom] Fwd: concern over the use of terms in the midcom framework document
In-Reply-To: <20020219113909.H1520@SBRIM-W2K>
References: <5.1.0.14.0.20020219091910.0133f150@localhost>
	<20020219113909.H1520@SBRIM-W2K>
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

On 19 Feb 2002 at 11:39 -0500, Scott Brim allegedly wrote:
> Second, a ruleset was exactly that.  A set of one *or more* rules, not
> just a single rule as in the offered definition.  The rules might be
> independent, not just a single set of actions bound to a single set of
> conditions.

OK, having done a bit more investigation ... it wouldn't hurt to have
another definition, "rule", which was in accord with the policy
terminology rfc, but I like keeping "ruleset" around.  We had to work to
get that flexibility.


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Tue Feb 19 20:34:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09974
	for ; Tue, 19 Feb 2002 20:34:41 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA14331
	for midcom-archive@odin.ietf.org; Tue, 19 Feb 2002 20:34:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13765;
	Tue, 19 Feb 2002 20:29:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13739
	for ; Tue, 19 Feb 2002 20:29:11 -0500 (EST)
Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09873
	for ; Tue, 19 Feb 2002 20:29:09 -0500 (EST)
Received: from tnpfrancis ([10.10.3.137]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 19 Feb 2002 17:28:40 -0800
Message-ID: <008201c1b9ad$ed6d0430$89030a0a@tahoenetworks.com>
Reply-To: "Paul Francis" 
From: "Paul Francis" 
To: , "Jiri Kuthan" 
References: <5.1.0.14.0.20020206022543.0167c188@iptel.org>
Subject: Re: [midcom] Yet Another Midcom Protocol
Date: Tue, 19 Feb 2002 17:28:39 -0800
Organization: TAHOE Networks
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
X-OriginalArrivalTime: 20 Feb 2002 01:28:40.0551 (UTC) FILETIME=[ED57A770:01C1B9AD]
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit

I see that you have some expired drafts on this protocol, so I wonder if you
guys plan to propose this in midcom, or just pursue it independently?

PD

ps.  Also, the iptel.org URL is not working for me at the moment.  Is it
just a temporary glitch?


----- Original Message -----
From: "Jiri Kuthan" 
To: 
Sent: Tuesday, February 05, 2002 5:37 PM
Subject: [midcom] Yet Another Midcom Protocol


> Whoever is interested in running code may want to have a look
> at http://www.iptel.org/fcp/ -- there is a link to two
> very-beta server implementations of a midcom-like protocol called FCP.
> It runs on Linux, opens and closes pinholes, allocates and releases
> NAT translations. MPLS support is missing, which is a feature. The
> protocol is described there too, though not really extensivelly.
>
> Backers of protocol recycling may wonder why we haven't used
> COPS/SOAP/HTTP/BEEP/SNMP/Diameter/GSMP or of course H.248.
> Well, we wanted to stay very simple, were lazy and did not
> want to implement anything else than needed.
>
> -Jiri
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Wed Feb 20 13:58:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16004
	for ; Wed, 20 Feb 2002 13:58:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA14043
	for midcom-archive@odin.ietf.org; Wed, 20 Feb 2002 13:58:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13740;
	Wed, 20 Feb 2002 13:52:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13711
	for ; Wed, 20 Feb 2002 13:52:07 -0500 (EST)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15765
	for ; Wed, 20 Feb 2002 13:52:04 -0500 (EST)
Received: from jku2.iptel.org (dhcp165.fokus.gmd.de [195.37.78.165])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g1KIpTH06354;
	Wed, 20 Feb 2002 19:51:36 +0100
Message-Id: <5.1.0.14.0.20020220035701.00b3a6b8@iptel.org>
X-Sender: jiri@iptel.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 20 Feb 2002 11:35:23 +0100
To: "Paul Francis" , 
From: Jiri Kuthan 
Subject: Re: [midcom] Yet Another Midcom Protocol
In-Reply-To: <008201c1b9ad$ed6d0430$89030a0a@tahoenetworks.com>
References: <5.1.0.14.0.20020206022543.0167c188@iptel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

At 02:28 AM 2/20/2002, Paul Francis wrote:
>I see that you have some expired drafts on this protocol, so I wonder if you
>guys plan to propose this in midcom, or just pursue it independently?

That depends much more on WG's willingnes and ability to move ahead.
I don't insist on my pet if noone else likes it. I haven't seen
excessive interest, not at least on the mailing list.

My

>PD
>
>ps.  Also, the iptel.org URL is not working for me at the moment.  Is it
>just a temporary glitch?

It worx now.

-Jiri


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb 21 05:10:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12511
	for ; Thu, 21 Feb 2002 05:10:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA10545
	for midcom-archive@odin.ietf.org; Thu, 21 Feb 2002 05:10:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09569;
	Thu, 21 Feb 2002 04:59:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09544
	for ; Thu, 21 Feb 2002 04:59:43 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12352
	for ; Thu, 21 Feb 2002 04:59:39 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1LA1ag06254
	for ; Thu, 21 Feb 2002 11:01:36 +0100 (CET)
	(envelope-from Martin.Stiemerling@ccrle.nec.de)
Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA13887
	for ; Thu, 21 Feb 2002 10:59:08 +0100
Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180])
	by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A50B7D5B5
	for ; Thu, 21 Feb 2002 10:59:07 +0100 (CET)
Date: Thu, 21 Feb 2002 10:59:08 +0100
From: Martin Stiemerling 
To: midcom@ietf.org
Subject: Re: [midcom] Yet Another Midcom Protocol
Message-ID: <11320000.1014285548@elgar>
In-Reply-To: <5.1.0.14.0.20020220035701.00b3a6b8@iptel.org>
References: <5.1.0.14.0.20020206022543.0167c188@iptel.org>
 <5.1.0.14.0.20020220035701.00b3a6b8@iptel.org>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 7bit


>> I see that you have some expired drafts on this protocol, so I wonder if
>> you guys plan to propose this in midcom, or just pursue it independently?
>
> That depends much more on WG's willingnes and ability to move ahead.

Yeah, that's a good point. There are some drafts (expired and non-expired) 
proposing a protocol for midcom, but no discussions about the protocol 
itself. Especially I would be interested in some comments regarding 
SIMCO... ;-)

Martin

> I don't insist on my pet if noone else likes it. I haven't seen
> excessive interest, not at least on the mailing list.
>
> My
>
>> PD
>>
>> ps.  Also, the iptel.org URL is not working for me at the moment.  Is it
>> just a temporary glitch?
>
> It worx now.
>
> -Jiri
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom



Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories      Martin.Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de             IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@ns.ietf.org  Thu Feb 21 22:40:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12207
	for ; Thu, 21 Feb 2002 22:40:08 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA13854
	for midcom-archive@odin.ietf.org; Thu, 21 Feb 2002 22:40:12 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13536;
	Thu, 21 Feb 2002 22:35:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13493
	for ; Thu, 21 Feb 2002 22:35:00 -0500 (EST)
Received: from localhost ([211.204.132.105])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12103
	for ; Thu, 21 Feb 2002 22:34:50 -0500 (EST)
Message-Id: <200202220334.WAA12103@ietf.org>
Reply-To: bplike@hanmail.net
From: 성공자
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Sun, 12 Dec 1999 00:28:39 +0900
Subject: [midcom] 창업소개-뉴트리션포라이프에서 찬스를 잡으세요-[정보]
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

본메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 
의거한 [광고] 메일입니다.

전자우편 주소 외 어떠한 개인 정보도 가지고 있지 않으므로 안심하시기 
바랍니다.

이메일 수신을 원치 않으시면 아래주소로[수신거부] 를하여 주십시오.
저희는귀하의 의사를 존중합니다.

수신거부된 메일은 절대로 메일을 재발송하지 
않겠습니다.



안녕하세요?

정보전략연구 소장인 윤은기 박사는 

"21세기는 신인재가 이끌어가는 사회가 될 것이고, 창업의시대"라고 
도 했습니다.

점포가 필요없는 시대가 도래할 것입니다. 



학력을 내세우던 시대는 이제 지났습니다.

신사고를 하는 신지식인의 시대가 온 것입니다. 

학력보다는 idea가, 분석력보다는 실천력이 요구되는시대입니다.

학력불문, 나이불문, 성별불문, 전공불문.누구나 할 수 있는 사업입니다. 



현 직장인이라면, 남는 시간에 부업으로하시면 됩니다. 

소박한 꿈마저도 없는 분이라면 사양합니다. 

2년 전의 생활과 지금의 생활을 비교했을 때, 아주만족하십니까? 

그럼, 2년 후는 어떻게 될까요? 


같은 문을 열면 같은 결과밖에 나오지 않습니다. 

이제 다른 문을 열어볼 때가 되었습니다. 

신지식인이 되고자 하시는 분은 주저마시고 연락주십시요. 

기회는 평등합니다. 
하지만 보상은 차등 됩니다. 

노력하시는 분이 성공합니다. 

2년 후엔 엄청난 결과가 있을 것입니다. 


새로운 님의 미래를 에서 시작하십시요..

NFLI 의비젼은 세계인이 증명하였습니다.

세계20여개국에서 한번의 실패도 없이 85% 재구매율이라는
경이적인 
실적으로 성장하고 있습니다.

580여가지의 다양한 상품군과 70%의 자체생산으로 가격이나

품질경쟁력에서 타회사의 우위를 고수할수있는원인이라 
할수있습니다.


(제품 : 생활용품, 세재류, 건강식품, 화장품, 주방용품, 허벌제품, 
개인용품

다이어트식품, 커피와 차류,스낵류, 미네랄 케어, 바이오워트 기타)



그런데 회사가 아무리 좋다고 님이 성공을 하는것은 아니겠지요...

4명의 메트릭스방식으로 구성되는 래그에서 님은 어떤 라인에서 사업을

하느냐도 중요한 문제이니 신중하게 결정을 해야겠지요.

우리 클럽은 가상회원이라는 제도를 구축하여 가입회원의 모든 
네트웍회사의

비젼을 확인하고 가입을 하게끔 시도하여 엄청난 호응을 불러일으키고 
있습니다.


하루 200명 이상의 회원이 새로운 사업을 저희클럽에서 시도하고 
있습니다.

님이 동참의사가 있으시다면 첫걸음부터 안내하겠습니다.

님은 최소한의 의지만 있으면 됩니다.
모든 PLAN은 저희가 이미 
준비하였습니다.

님은 합류만하면 됩니다.


온라인 무료등록하시고 다운라인 형성되는것 직접

다운라인 조회에서 확인하세요...

당신과 당신이 홍보하여 형성되는 파트너까지

모두 홈페이지를 실시간으로 지원합니다.


http://ebiz7.net/myteam/index.php?id= 
본인아이디


본인의 아이디는 아래에서 가상멤버 등록의 아이디를 말합니다.


본 클럽에서는 절대 님의 의사를 존중합니다.

본 클럽을 성공의 발판으로 삼으시길 바랍니다.

아래의 홈페이지를 클릭하여 가입하신후 연락을 주십시요.


모든 성공 사업에는 아이템과 타이밍이 가장 중요합니다.

아무리 훌륭한 사업도 타이밍이 지난 뒤에는 성공의 기회 역시 
사라집니다.

그리고 오프라인으로만 진행을 할 경우,많은 분들이 두려움을느낍니다. 



"나는 아는 사람이 별로 없는데." 

"다른 사람에게 말할 자신이 없는데." 

"시간이 없어서 못해요." 
"
열심히 해도 수입이 안돼요." 


네트워크 마케팅을 오프라인보다는 인터넷홍보에 중점적으로 뛰는 팀으로 
누구나 쉽게 사업을 
진행하실 수 있습니다.
요즘 경기가 안 좋아 수입이 적은 분들,부업을 
원하는 분들,가정 주부 등등 누구나 하실 수 있습니다.(재택근무) 


富를 창출하는 가장 좋은 방법은 새로운 기회를 발견하고 
만들어내는 것 입니다.
인터넷 경제에서는 새로운 기회를 누가 얼마나 
빨리 포착하느냐가 성공의 관건이 되고 있습니다.
인터넷 세상에서 1년은 
예전의 10년과 같습니다. 님의 빠른 행동만이 정보의 가치를 살릴 
수 있습니다.
그러나 시장선점을 할 수 있는 사업적 타이밍은 백만장자의 
가능성을 현실화 할 수 있는 최고의 조건인 것 
입니다.

진심으로 권하고 싶습니다. 우리가 평생을 살아가면서 
이처럼 좋은 사업 기회는 쉽게오지 않을 것 입니다.
마지막으로 이 
글이 여러분에게 불편을 끼쳤드렸다면 다시한번 
사과드립니다.

즐거운 하루되십시오.

10년 안에는 쉽게 오지 않을 세계적인 
e-비지니스의 기회를 결코 놓치지 마십시오.
그럼 더자세한 알고싶으시면 
아래주소를 클릭하십시요.

홈페이지바로가기 

e-mail 
:kisroom@yahoo.co.kr 

손폰 : 
016-9757-2535 






_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Sun Feb 24 03:22:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08911
	for ; Sun, 24 Feb 2002 03:22:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA00880
	for midcom-archive@odin.ietf.org; Sun, 24 Feb 2002 03:21:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00756;
	Sun, 24 Feb 2002 03:17:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00718
	for ; Sun, 24 Feb 2002 03:17:10 -0500 (EST)
Received: from localhost ([211.200.167.230])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08881
	for ; Sun, 24 Feb 2002 03:17:04 -0500 (EST)
Message-Id: <200202240817.DAA08881@ietf.org>
Reply-To: kisroom@yahoo.co.kr
From: 찬스를파는자
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Tue, 14 Dec 1999 05:10:38 +0900
Subject: [midcom] [정보]엄첨난 찬스가 왔습니다/찬스를 잡으세요.(아직오픈전)
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

본메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 
의거한 [광고] 메일입니다.

전자우편 주소 외 어떠한 개인 정보도 가지고 있지 않으므로 안심하시기 
바랍니다.

이메일 수신을 원치 않으시면 아래주소로[수신거부] 를하여 주십시오.
저희는귀하의 의사를 존중합니다.

수신거부된 메일은 절대로 메일을 재발송하지 
않겠습니다.



안녕하세요?

정보전략연구 소장인 윤은기 박사는 

"21세기는 신인재가 이끌어가는 사회가 될 것이고, 창업의시대"라고 
도 했습니다.

점포가 필요없는 시대가 도래할 것입니다. 



학력을 내세우던 시대는 이제 지났습니다.

신사고를 하는 신지식인의 시대가 온 것입니다. 

학력보다는 idea가, 분석력보다는 실천력이 요구되는시대입니다.

학력불문, 나이불문, 성별불문, 전공불문.누구나 할 수 있는 사업입니다. 



현 직장인이라면, 남는 시간에 부업으로하시면 됩니다. 

소박한 꿈마저도 없는 분이라면 사양합니다. 

2년 전의 생활과 지금의 생활을 비교했을 때, 아주만족하십니까? 

그럼, 2년 후는 어떻게 될까요? 


같은 문을 열면 같은 결과밖에 나오지 않습니다. 

이제 다른 문을 열어볼 때가 되었습니다. 

신지식인이 되고자 하시는 분은 주저마시고 연락주십시요. 

기회는 평등합니다. 
하지만 보상은 차등 됩니다. 

노력하시는 분이 성공합니다. 

2년 후엔 엄청난 결과가 있을 것입니다. 


새로운 님의 미래를 에서 시작하십시요..

NFLI 의비젼은 세계인이 증명하였습니다.

세계20여개국에서 한번의 실패도 없이 85% 재구매율이라는
경이적인 
실적으로 성장하고 있습니다.

580여가지의 다양한 상품군과 70%의 자체생산으로 가격이나

품질경쟁력에서 타회사의 우위를 고수할수있는원인이라 
할수있습니다.


(제품 : 생활용품, 세재류, 건강식품, 화장품, 주방용품, 허벌제품, 
개인용품

다이어트식품, 커피와 차류,스낵류, 미네랄 케어, 바이오워트 기타)



그런데 회사가 아무리 좋다고 님이 성공을 하는것은 아니겠지요...

4명의 메트릭스방식으로 구성되는 래그에서 님은 어떤 라인에서 사업을

하느냐도 중요한 문제이니 신중하게 결정을 해야겠지요.

우리 클럽은 가상회원이라는 제도를 구축하여 가입회원의 모든 
네트웍회사의

비젼을 확인하고 가입을 하게끔 시도하여 엄청난 호응을 불러일으키고 
있습니다.


하루 200명 이상의 회원이 새로운 사업을 저희클럽에서 시도하고 
있습니다.

님이 동참의사가 있으시다면 첫걸음부터 안내하겠습니다.

님은 최소한의 의지만 있으면 됩니다.
모든 PLAN은 저희가 이미 
준비하였습니다.

님은 합류만하면 됩니다.


온라인 무료등록하시고 다운라인 형성되는것 직접

다운라인 조회에서 확인하세요...

당신과 당신이 홍보하여 형성되는 파트너까지

모두 홈페이지를 실시간으로 지원합니다.


http://ebiz7.net/myteam/index.php?id= 
본인아이디


본인의 아이디는 아래에서 가상멤버 등록의 아이디를 말합니다.


본 클럽에서는 절대 님의 의사를 존중합니다.

본 클럽을 성공의 발판으로 삼으시길 바랍니다.

아래의 홈페이지를 클릭하여 가입하신후 연락을 주십시요.


모든 성공 사업에는 아이템과 타이밍이 가장 중요합니다.

아무리 훌륭한 사업도 타이밍이 지난 뒤에는 성공의 기회 역시 
사라집니다.

그리고 오프라인으로만 진행을 할 경우,많은 분들이 두려움을느낍니다. 



"나는 아는 사람이 별로 없는데." 

"다른 사람에게 말할 자신이 없는데." 

"시간이 없어서 못해요." 
"
열심히 해도 수입이 안돼요." 


네트워크 마케팅을 오프라인보다는 인터넷홍보에 중점적으로 뛰는 팀으로 
누구나 쉽게 사업을 
진행하실 수 있습니다.
요즘 경기가 안 좋아 수입이 적은 분들,부업을 
원하는 분들,가정 주부 등등 누구나 하실 수 있습니다.(재택근무) 


富를 창출하는 가장 좋은 방법은 새로운 기회를 발견하고 
만들어내는 것 입니다.
인터넷 경제에서는 새로운 기회를 누가 얼마나 
빨리 포착하느냐가 성공의 관건이 되고 있습니다.
인터넷 세상에서 1년은 
예전의 10년과 같습니다. 님의 빠른 행동만이 정보의 가치를 살릴 
수 있습니다.
그러나 시장선점을 할 수 있는 사업적 타이밍은 백만장자의 
가능성을 현실화 할 수 있는 최고의 조건인 것 
입니다.

진심으로 권하고 싶습니다. 우리가 평생을 살아가면서 
이처럼 좋은 사업 기회는 쉽게오지 않을 것 입니다.
마지막으로 이 
글이 여러분에게 불편을 끼쳤드렸다면 다시한번 
사과드립니다.

즐거운 하루되십시오.

10년 안에는 쉽게 오지 않을 세계적인 
e-비지니스의 기회를 결코 놓치지 마십시오.
그럼 더자세한 알고싶으시면 
아래주소를 클릭하십시요.

홈페이지바로가기 

e-mail 
:kisroom@yahoo.co.kr 

손폰 : 
016-9757-2535 






_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Mon Feb 25 10:00:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12746
	for ; Mon, 25 Feb 2002 10:00:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA24817
	for midcom-archive@odin.ietf.org; Mon, 25 Feb 2002 10:00:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24361;
	Mon, 25 Feb 2002 09:57:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24336
	for ; Mon, 25 Feb 2002 09:57:08 -0500 (EST)
Received: from localhost ([211.199.43.141])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12644
	for ; Mon, 25 Feb 2002 09:57:02 -0500 (EST)
Message-Id: <200202251457.JAA12644@ietf.org>
Reply-To: godfs3233@empal.com
From: 프렌차이즈
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Mon, 25 Feb 2002 23:56:11 +0900
Subject: [midcom] 도움이 되는 메일이었으면 합니다[광  고]
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org









백만장자클럽










백만장자클럽에서는 백만장자가 되기 위한 다양한 컨텐츠들이 있으며, 실제로 사업을 할 수 있도록 지원해 드리고 있습니다.
오셔서 유익한 정보를 얻으시고, 궁금한 것이 있으면 질문해 주시기 바랍니다.
















          























본 메일은 정보통신분 권고사항에 의거하여[광고]로 표시된 홍보메일이며 귀하의 이메일
 주소 이외에 다른정보는 일체 가지고 있지 않습니다. 광고 메일을
받고 싶지 않으신 분은 
아래의 [수신거부]버튼을 눌러 주세요. 간혹 메일중복이 발생하여 본의 아니게 보내게 되는
 점 용서해 주셨으면 고맙겠습니다
허락없이 본 메일을 발송함에 대해 다시 한 번 양해를 구합니다.

E-Mail 주소는 게시판을 통해서 알게되었습니다. 원치 않는 메일이라면 수신거부를 하시면
 다시 보내 드리지 않겠습니다.


수신거부합니다





_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Mon Feb 25 18:26:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03903
	for ; Mon, 25 Feb 2002 18:26:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA24606
	for midcom-archive@odin.ietf.org; Mon, 25 Feb 2002 18:26:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24458;
	Mon, 25 Feb 2002 18:20:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24429
	for ; Mon, 25 Feb 2002 18:20:11 -0500 (EST)
Received: from www51.tt.co.kr ([211.47.65.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03680
	for ; Mon, 25 Feb 2002 18:20:06 -0500 (EST)
Received: (from okonomi@localhost)
	by www51.tt.co.kr (8.10.1/8.10.1) id g1PN8Zu12980;
	Tue, 26 Feb 2002 08:08:35 +0900
Date: Tue, 26 Feb 2002 08:08:35 +0900
Message-Id: <200202252308.g1PN8Zu12980@www51.tt.co.kr>
MIME-Version: 1.0
Content-Type: text/html; charset=euc-kr
To: himem
From: himem
Subject: [midcom] 제목없음
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org


 



_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Wed Feb 27 01:27:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04051
	for ; Wed, 27 Feb 2002 01:27:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA26704
	for midcom-archive@odin.ietf.org; Wed, 27 Feb 2002 01:27:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26006;
	Wed, 27 Feb 2002 01:16:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25960
	for ; Wed, 27 Feb 2002 01:16:18 -0500 (EST)
Received: from hyperion.site5.com (64-21-152-2.site5.com [64.21.152.2] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03907
	for ; Wed, 27 Feb 2002 01:16:16 -0500 (EST)
Received: from aqii15uwy24ra.ab.hsia.telus.net ([142.173.173.244] helo=aura)
	by hyperion.site5.com with smtp (Exim 3.34 #1)
	id 16fxO0-00012s-00
	for midcom@ietf.org; Wed, 27 Feb 2002 01:16:20 -0500
From: "Alan Hawrylyshen" 
To: 
Date: Tue, 26 Feb 2002 23:16:42 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_01C1BF1B.A6957740"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hyperion.site5.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - polyphase.ca
Subject: [midcom] Subscribe midcom
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C1BF1B.A6957740
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



------=_NextPart_000_0012_01C1BF1B.A6957740
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







 


------=_NextPart_000_0012_01C1BF1B.A6957740--


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Wed Feb 27 02:27:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12791
	for ; Wed, 27 Feb 2002 02:27:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA29131
	for midcom-archive@odin.ietf.org; Wed, 27 Feb 2002 02:27:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28889;
	Wed, 27 Feb 2002 02:16:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28860
	for ; Wed, 27 Feb 2002 02:16:26 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10053
	for ; Wed, 27 Feb 2002 02:16:24 -0500 (EST)
Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1R7Fuh14933;
	Tue, 26 Feb 2002 23:15:56 -0800 (PST)
Date: Tue, 26 Feb 2002 23:15:56 -0800 (PST)
From: Rohan Mahy 
To: 
cc: , 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [midcom] Open Source STUN Client and Server available
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org

Hello,

Alan Hawrylyshen has written a STUN server and client and kindly released
it with a very liberal open source license.  Both the client and server
run on Windows, Linux, and Solaris.  It is available at the following
location:

http://www.polyphase.ca/software/stun/overview.html

As this is his personal server, please do not thrash it.  Please direct
questions on this software to mailto:stun-list@polyphase.ca

thanks,
-rohan

Rohan Mahy
STUN co-author


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Wed Feb 27 09:40:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24715
	for ; Wed, 27 Feb 2002 09:40:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA23534
	for midcom-archive@odin.ietf.org; Wed, 27 Feb 2002 09:40:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23267;
	Wed, 27 Feb 2002 09:34:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23230
	for ; Wed, 27 Feb 2002 09:34:22 -0500 (EST)
Received: from localhost ([211.217.173.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24341
	for ; Wed, 27 Feb 2002 09:34:16 -0500 (EST)
Message-Id: <200202271434.JAA24341@ietf.org>
Reply-To: gotours@dreamwiz.com
From: 여행가자
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Wed, 27 Feb 2002 23:29:32 +0900
Subject: [midcom] [이벤트광고]무료 회원가입 하시면 해외 무료 여행권을 드립니다.
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org




여행가자 오픈 기념으로 회원 가입시 [태국,필리핀,사이판] 무료 해외 여행권을 드립니다.


















































[이벤트1] = 여행가자 홈페이지 오픈 기념으로 회원 가입시 [태국,필리핀,사이판] 
무료
해외 여행권을 드립니다.   [항공권 별도
]
기간 : 2002년 2월18일 ~ 4월 30일 까지 대상 : 여행가자 신규회원 가입자
전원증정

[이벤트2] =
주위의 결혼하시는 분들에게 저희 여행가자를 소개시켜 주셔서 신혼여행이 
계약되면 계약과 동시에 계좌로 일금 50,000원을 입금해 드립니다.
(단 제주도 신혼여행은 20,000원) 
 여행가자
홈페이지 바로가기
 






 
 귀하의 승락없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다.
정보통신망이용촉진법 규정을 준수하여 광고메일임을 표시하였으며, 수신거부 장치를 마련하고 있습니다.
귀하의 전자 우편 주소는 인터넷 상의
공개된 장소에서 습득하였으며, 저희는 귀하의 전자우편 주소 외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다. 수신을 원치 않으시면 
를 클릭해 주십시요.  








 












_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom



From daemon@optimus.ietf.org  Thu Feb 28 20:21:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28387
	for ; Thu, 28 Feb 2002 20:21:53 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA14608
	for midcom-archive@odin.ietf.org; Thu, 28 Feb 2002 20:21:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14232;
	Thu, 28 Feb 2002 20:05:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14189
	for ; Thu, 28 Feb 2002 20:05:47 -0500 (EST)
Received: from cjstls3 ([61.38.87.71])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28012
	for ; Thu, 28 Feb 2002 20:05:41 -0500 (EST)
Message-Id: <200203010105.UAA28012@ietf.org>
Reply-To: cjstls3@hotmail.com
From: 운산
To: midcom@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="ks_c_5601-1987"
Date: Fri, 1 Mar 2002 10:07:48 +0900
Subject: [midcom] [광고]여러분의 잃어버린 행복의 복까지 찾아드립니다.
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  
X-BeenThere: midcom@ietf.org






운산운세정보










본 메일은 정보통신부 권고사항에 의거,제목에 [광고]란이 표시된 메일입니다.

허락없이 광고메일을 보내드려 죄송하며,정중히 양해 바랍니다.

메일주소는 게시판,동호회등의 공개 메일주소를 수집하여, 다른 개인정보는 없음을 알려드립니다.










































운산운세정보에서는 다른 실시간상담업체와 달리 많은
상담선생님을 초빙하지 않고, 회사의 엄격한 기준에 부합된 상담선생님들만 모셔서 24시간 1:1 상담이
될 수 있도록 하였습니다. (홈페이지로 이동,무료상담실 운영)



직업운, 시험운, 진학운, 애정운, 사랑운, 건강운, 사업운, 꿈해몽,
토정비결, 속궁합 겉궁합, 승진운, 작명, 택일, 사주팔자, 풍수지리...


























 
 
 




 

 




 





1.



지역번호 없이(휴대폰 포함) 060-700-8865번으로 전화를 겁니다(전국단일요금)




2.







1번을 누르시면 대기중인 상담선생님과 자동연결되고, 2번을 누르시고 원하는 상담선생님 고유번호를 누르시면 선택한
역술상담선생님과 통화할 수 있습니다. 이용중 문의 사항이나 불편사항은
이메일로 연락주시기 바랍니다.






 




 
 
 




 

 




 
상담하실 내용을 미리 마음속으로 정리를 하거나 메모를 해 보세요.

그리고 상담선생님과 연결이 되면 상담하실 내용을 차근차근 설명을 하시면 보다 편리하게 상담을 하실 수 있을 겁니다.
상담내용은 일체 비밀이므로, 편안한 마음과 자세로 상담 해보세요.		
 




 
 
 




 

 




 
서비스 이용요금은
사용 후, 익월에 사용한 내역이 정보이용료
사용하신 전화요금에 함께 청구되도록 되어 있어 결재시 불편함이 없습니다. 
 




 
 

          
"역학은 통계에 의한 과학적인 학문입니다"

                  
Copyright (c) 2002 운산운세정보 All rights reserved

 














(사)한국전화정보통신협회 심의필번호 200112-223 
        불건전 정보신고 ☎080-700-3700











이 메일의 수신을 원하지 않으시면
수신거부
 를 눌러 주세요.




















_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom