From beepwg-admin@lists.beepcore.org  Sat Jun  1 20:57:14 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29108
	for <beep-archive@odin.ietf.org>; Sat, 1 Jun 2002 20:57:13 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g520c4H04054;
	Sat, 1 Jun 2002 17:38:04 -0700 (PDT)
Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g520bbH04042
	for <beepwg@lists.beepcore.org>; Sat, 1 Jun 2002 17:37:37 -0700 (PDT)
Received: from dhcp2 (dhcpd253.dbc.mtview.ca.us [64.168.10.253])
	by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g520Wtd18624;
	Sat, 1 Jun 2002 17:32:55 -0700 (PDT)
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: beepwg@lists.beepcore.org
Cc: jhw@wetware.com
Subject: Re: [BEEPwg] transformative content-transfer-encoding in core profiles
Message-Id: <20020601175452.5ce64e26.mrose@dbc.mtview.ca.us>
In-Reply-To: <A445EE6C-74EC-11D6-917A-000502DB38F5@wetware.com>
References: <A445EE6C-74EC-11D6-917A-000502DB38F5@wetware.com>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Sat, 1 Jun 2002 17:54:52 -0700
Content-Transfer-Encoding: 7bit

> everyone--
> 
> What should a BEEP peer do when it receives an initial greeting message 
> in a transformative content transfer encoding?
> 
> For example:
> 
> 	RPY 0 0 . 0 nnn
> 	Content-Type: application/beep+xml; charset="iso-8859-1"
> 	Content-Transfer-Encoding: quoted-printable
> 
> 	<greeting/>
> 	END
> 
> RFC 3080 seems to be silent on the subject.
> 
> If the IETF ever revises the BEEP core specification, is it possible we 
> might see an outright ban on the use of the Content-Transfer-Encoding 
> entity header in all of the core profiles?  At least a strong 
> recommendation against?

hmmm... i don't think that seeing a CTE on channel zero is any different than seeing a CTE on any other channel. it's just wrong. each channel is supposed to be 8-bit clean. can anyone come up with a reason as to why a CTE is needed?

if not, then i think this falls under the category of "being liberal in what you accept"...if an implementation treated it as a fatal error, i wouldn't complain about that...

/mtr
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Wed Jun  5 21:49:45 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05614
	for <beep-archive@odin.ietf.org>; Wed, 5 Jun 2002 21:49:44 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g561T9H08065;
	Wed, 5 Jun 2002 18:29:09 -0700 (PDT)
Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g561SDH08053
	for <beepwg@lists.beepcore.org>; Wed, 5 Jun 2002 18:28:13 -0700 (PDT)
Received: from (local broken client) localhost(dh03.wetware.com[199.108.16.43]) (2121 bytes) by wetware.wetware.com
	via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <jhw@wetware.com>) 
	id <m17FmLe-002zeUC@wetware.wetware.com>
	for <beepwg@lists.beepcore.org>; Wed, 5 Jun 2002 18:45:58 -0700 (PDT)
	(Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4)
Mime-Version: 1.0 (Apple Message framework v482)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: james woodyatt <jhw@wetware.com>
To: BEEP WG <beepwg@lists.beepcore.org>
Content-Transfer-Encoding: 7bit
Message-Id: <0D7FB89E-78EF-11D6-B805-000502DB38F5@wetware.com>
X-Mailer: Apple Mail (2.482)
Subject: [BEEPwg] SEQ frames and MIME entity headers
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Wed, 5 Jun 2002 18:45:17 -0700
Content-Transfer-Encoding: 7bit

everyone--

Another minor thing that might be helpful to carry around until the IETF 
decides to revise RFC 3080 and/or RFC 3081:

I think BEEP peers should not send SEQ frames to acknowledge processing 
of incomplete MIME entity headers.  It would be better, to my mind, if 
BEEP peers were required to buffer the entire MIME entity header of a 
message before sending a SEQ frame to acknowledge it.

As I read RFC 3080 and 3081, BEEP peers are *permitted* to do this, but 
I can't think of a good reason why an application should expect that its 
BEEP core framework be able to present it with an incomplete entity 
header.  If your application *really* wants to receive a 
Content-Description field that can potentially be larger than the RFC 
3081 window for your channel, then it seems to me it can enlarge the 
window.

One of the reasons I bring this up: if I *do* send SEQ frames 
acknowledging incomplete MIME entity headers, then I have a problem when 
a malicious peer sends an initial greeting message with a 
Content-Description field of infinite length.  Plus, it complicates the 
programming interface for application profiles to have to support 
pathologically long MIME entity headers, and I'd rather just place the 
onus on the application to make sure all its headers fit through the 
transport mapping channel window.

Anyway, this seems like another one of those interoperability "corner 
case" issues that we should be tracking at this stage of the game.  
Would anyone care to add a comment to this?


--
j h woodyatt <jhw@wetware.com>

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Thu Jun  6 08:58:01 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11172
	for <beep-archive@odin.ietf.org>; Thu, 6 Jun 2002 08:58:01 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g56Ce3H12863;
	Thu, 6 Jun 2002 05:40:03 -0700 (PDT)
Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g56CdxH12845
	for <beepwg@lists.beepcore.org>; Thu, 6 Jun 2002 05:39:59 -0700 (PDT)
Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92])
	by act-of-god.permabit.com (Postfix) with ESMTP
	id 6893613F07; Thu,  6 Jun 2002 08:57:56 -0400 (EDT)
To: james woodyatt <jhw@wetware.com>
Cc: BEEP WG <beepwg@lists.beepcore.org>
Subject: Re: [BEEPwg] SEQ frames and MIME entity headers
References: <0D7FB89E-78EF-11D6-B805-000502DB38F5@wetware.com>
From: Jered Floyd <jered@permabit.com>
In-Reply-To: <0D7FB89E-78EF-11D6-B805-000502DB38F5@wetware.com>
Message-ID: <873cw0womj.fsf@questionably-configured.permabit.com>
Lines: 39
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: 06 Jun 2002 08:57:56 -0400

james woodyatt <jhw@wetware.com> writes:
> 
> I think BEEP peers should not send SEQ frames to acknowledge
> processing of incomplete MIME entity headers.  It would be better, to
> my mind, if BEEP peers were required to buffer the entire MIME entity
> header of a message before sending a SEQ frame to acknowledge it.

[...]

> Anyway, this seems like another one of those interoperability "corner
> case" issues that we should be tracking at this stage of the game.
> Would anyone care to add a comment to this?

I think this is a poor idea.  As far as I'm concerned, the data format
of a BEEP message should be beyond the abstraction barrier of the
things that the transport code need have knowledge of.  

I also agree that the scenario you describe, in which there are more
headers than the channel window buffer can hold, is a mess, and adds
unnecessary complexity.  You suggest that the sending peer could 
increase the channel window size if it wishes to send a long set
of headers, but BEEP does not currently define a mechanism by which
a sending peer can request an increase in the channel window size.

> One of the reasons I bring this up: if I *do* send SEQ frames
> acknowledging incomplete MIME entity headers, then I have a problem
> when a malicious peer sends an initial greeting message with a
> Content-Description field of infinite length.

How is this worse than an XML body of infinite length, say filled
with whitespace or comments?  

> Plus, it complicates the programming interface for application
> profiles to have to support pathologically long MIME entity headers,

You applications will often have to support pathologically long
entities, be they MIME headers or not.

--Jered

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Thu Jun  6 19:12:01 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10155
	for <beep-archive@odin.ietf.org>; Thu, 6 Jun 2002 19:12:01 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g56I66H14624;
	Thu, 6 Jun 2002 11:06:06 -0700 (PDT)
Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g56I5YH14608
	for <beepwg@lists.beepcore.org>; Thu, 6 Jun 2002 11:05:35 -0700 (PDT)
Received: from (local broken client) localhost(dh02.wetware.com[199.108.16.42]) (3807 bytes) by wetware.wetware.com
	via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <jhw@wetware.com>) 
	id <m17G1v2-002zeTC@wetware.wetware.com>
	for <beepwg@lists.beepcore.org>; Thu, 6 Jun 2002 11:23:32 -0700 (PDT)
	(Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4)
Subject: Re: [BEEPwg] SEQ frames and MIME entity headers
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: BEEP WG <beepwg@lists.beepcore.org>
To: Jered Floyd <jered@permabit.com>
From: james woodyatt <jhw@wetware.com>
In-Reply-To: <873cw0womj.fsf@questionably-configured.permabit.com>
Message-Id: <84ED0F70-797A-11D6-8356-000502DB38F5@wetware.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Thu, 6 Jun 2002 11:23:37 -0700
Content-Transfer-Encoding: 7bit

On Thursday, June 6, 2002, at 05:57 AM, Jered Floyd wrote:
> james woodyatt <jhw@wetware.com> writes:
>>
>> I think BEEP peers should not send SEQ frames to acknowledge
>> processing of incomplete MIME entity headers.  It would be better, to
>> my mind, if BEEP peers were required to buffer the entire MIME entity
>> header of a message before sending a SEQ frame to acknowledge it.
>
> I also agree that the scenario you describe, in which there are more
> headers than the channel window buffer can hold, is a mess, and adds
> unnecessary complexity.  You suggest that the sending peer could
> increase the channel window size if it wishes to send a long set
> of headers, but BEEP does not currently define a mechanism by which
> a sending peer can request an increase in the channel window size.

That's true, but it doesn't have to.  Applications that depend on that 
feature can define mechanisms in their profiles for doing that.  The 
core profiles don't have any such mechanism, but then-- they don't need 
to send pathologically long entity headers, do they?

>> One of the reasons I bring this up: if I *do* send SEQ frames
>> acknowledging incomplete MIME entity headers, then I have a problem
>> when a malicious peer sends an initial greeting message with a
>> Content-Description field of infinite length.
>
> How is this worse than an XML body of infinite length, say filled
> with whitespace or comments?

All BEEP messages have entity headers.  If an application wants to 
process entity bodies incrementally and still prevent peers from being 
able to send content of unbounded length, its profile can require the 
presence of Content-Length header fields in its message entities.

When an application receives a MSG entity without a required 
Content-Length field, it can immediately produce an ERR entity in 
response.  When receiving any other kind of entity without a required 
Content-Length field, the application can instruct the framework to 
discard the body.

The harder problem is letting applications process entity *headers* 
incrementally, because that forces the application programming interface 
for profiles to support applications having to deal with headers of 
potentially unbounded length.

I think that unnecessarily complicates an already very complicated 
programming interface, and I can't think of any good reasons why 
applications would need to process entity headers incrementally.  Can 
anyone?

>> Plus, it complicates the programming interface for application
>> profiles to have to support pathologically long MIME entity headers,
>
> You applications will often have to support pathologically long
> entities, be they MIME headers or not.

As I said, applications get some control over the size of messages with 
the Content-Length entity header field.  The core profiles can all be 
written in such a way that their messages are completely buffered in the 
channel window and processed atomically.  I'm pretty sure that's one of 
the reasons why RFC 3081 says the initial window size of a channel is 
4096 octets.


--
j h woodyatt <jhw@wetware.com>

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Mon Jun 17 13:02:00 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11596
	for <beep-archive@odin.ietf.org>; Mon, 17 Jun 2002 13:01:56 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5HGgAo07696;
	Mon, 17 Jun 2002 09:42:10 -0700 (PDT)
Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5HGf8o07680
	for <beepwg@lists.beepcore.org>; Mon, 17 Jun 2002 09:41:09 -0700 (PDT)
Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92])
	by act-of-god.permabit.com (Postfix) with ESMTP
	id C89EF13E43; Mon, 17 Jun 2002 13:00:12 -0400 (EDT)
To: james woodyatt <jhw@wetware.com>
Cc: BEEP WG <beepwg@lists.beepcore.org>
Subject: Re: [BEEPwg] SEQ frames and MIME entity headers
References: <84ED0F70-797A-11D6-8356-000502DB38F5@wetware.com>
From: Jered Floyd <jered@permabit.com>
In-Reply-To: <84ED0F70-797A-11D6-8356-000502DB38F5@wetware.com>
Message-ID: <87k7oxvo0z.fsf@questionably-configured.permabit.com>
Lines: 15
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: 17 Jun 2002 13:00:12 -0400


> That's true, but it doesn't have to.  Applications that depend on that
> feature can define mechanisms in their profiles for doing that.  The
> core profiles don't have any such mechanism, but then-- they don't
> need to send pathologically long entity headers, do they?

Applications can only define mechanisms in their profiles only if 
their profiles are tied to only operate over a TCP transport.  This
seems poor.  The core profiles don't need to send 'pathologically'
long entity headers, but they *could*, and changing the standard
in such a way where the 'proper' behaviour can only be defined as
'deadlock' is inappropriate.  It's reasonable to disallow certain
operations, but only if failure can be indicated meaningfully.

--Jered

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Mon Jun 24 18:58:57 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06285
	for <beep-archive@odin.ietf.org>; Mon, 24 Jun 2002 18:58:54 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5OMu7M26803;
	Mon, 24 Jun 2002 15:56:07 -0700 (PDT)
Received: from mail.omsoft.com (velocipede.dcn.davis.ca.us [168.150.193.10])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5OMsbM26621
	for <beepwg@lists.beepcore.org>; Mon, 24 Jun 2002 15:54:37 -0700 (PDT)
Received: from isis.dvs.silicondefense.com (dcn238-233.dcn.davis.ca.us [168.150.238.233])
	by mail.omsoft.com (8.11.4/8.11.4/Omsoft) with ESMTP id g5OMsrG25942
	for <beepwg@lists.beepcore.org>; Mon, 24 Jun 2002 15:54:54 -0700 (PDT)
Received: from silicondefense.com (sebek.dvs.silicondefense.com [10.0.1.9])
	by isis.dvs.silicondefense.com (Postfix) with ESMTP id 9DE1889A7F
	for <beepwg@lists.beepcore.org>; Mon, 24 Jun 2002 15:54:49 -0700 (PDT)
Message-ID: <3D17A45E.3060100@silicondefense.com>
From: Ryan Ripken <ryan@silicondefense.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: beepwg@lists.beepcore.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [BEEPwg] caching and compression profiles?
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Mon, 24 Jun 2002 15:59:42 -0700
Content-Transfer-Encoding: 7bit


Has anyone thought about writing a zlib profile to do gzip compression? 
 What about a profile to do caching?  Is there any reason profiles like 
this couldn't be created?

It seems like a compression profile would be straightforward and useful 
enough that someone may have already done this.

In my case I would like to send a large amount of xml messages (IDMEF) 
from a client to a server.  Using gzip I can usually get around 30x 
compression.  I'd imagine that XMill or some other approach could do 
better.  For security reasons I'd like to use the tls profile (actually 
the idxp profile with tls).  Besides network bandwidth there are 
performance and security reasons why compression is attractive.

  I could turn on compression in openssl in both the client and the 
server machines but that is implementation specific and not general 
 purpose.  I could also compress/decompress the messages in the 
applications - but this ties clients to servers and kinda defeats the 
purpose of using an open format like IDMEF.  I think a compression 
profile would be the best solution and allow peers to negotiate a 
compression profile when it is available on the client and the server.

I did a quick search and found a refernce to a suggestion for a 
compression profile in the mailing list archive, whatever happened to 
that idea?
If a compression profile could be written it wouldn't work very well 
with small messages, that is where a caching profile might be useful - 
cache messages and compress a bunch of them at once.

What do you people think?

Ryan

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Wed Jun 26 02:14:43 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20661
	for <beep-archive@odin.ietf.org>; Wed, 26 Jun 2002 02:14:42 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5Q6E5M09047;
	Tue, 25 Jun 2002 23:14:05 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5Q6DJM09034
	for <beepwg@lists.beepcore.org>; Tue, 25 Jun 2002 23:13:19 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5Q6Cvr02712;
	Tue, 25 Jun 2002 23:12:57 -0700 (PDT)
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: beepwg@lists.beepcore.org, ekr@rtfm.com
Cc: ryan@silicondefense.com
Subject: Re: [BEEPwg] caching and compression profiles?
Message-Id: <20020625231257.650f94c7.mrose@dbc.mtview.ca.us>
In-Reply-To: <3D17A45E.3060100@silicondefense.com>
References: <3D17A45E.3060100@silicondefense.com>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Tue, 25 Jun 2002 23:12:57 -0700
Content-Transfer-Encoding: 7bit

[ eric rescolra added to thread... ]

eric - what's the story on TLS use of compression? is it automatic, if available? or is there some other "magic" involved.

ryan - i think that caching and compression are probably two different things.

caching is probably profile-specific in the sense that whatever does the caching has to understand the semantics of the profile in use on the channel.

compression is more general. i suppose you could do it either as a tuning profile (for the whole session) or on a per-channel basis. i can see advantages to each, but i'd prefer that the result look like this:

1. if you tune for privacy, then session-wide compression should just happen automatically, as a part of the security layer.

2. if you don't tune for privacy, then you may decide to tune for compression. it should be fairly easy to define a family of profiles to do this, e.g., http://.../zlib, http://.../my-whacky-compression, etc.

if someone feels strongly that compression ought to be done on a per-channel basis, then we'll finally get a chance to use BEEP's feature negotiation mechanism, because there'll have to be a way of letting the two sides negotiate the use of compression before they start adding a "Content-..." header to the messages they exchange over BEEP...

/mtr

> Has anyone thought about writing a zlib profile to do gzip compression? 
>  What about a profile to do caching?  Is there any reason profiles like 
> this couldn't be created?
> 
> It seems like a compression profile would be straightforward and useful 
> enough that someone may have already done this.
> 
> In my case I would like to send a large amount of xml messages (IDMEF) 
> from a client to a server.  Using gzip I can usually get around 30x 
> compression.  I'd imagine that XMill or some other approach could do 
> better.  For security reasons I'd like to use the tls profile (actually 
> the idxp profile with tls).  Besides network bandwidth there are 
> performance and security reasons why compression is attractive.
> 
>   I could turn on compression in openssl in both the client and the 
> server machines but that is implementation specific and not general 
>  purpose.  I could also compress/decompress the messages in the 
> applications - but this ties clients to servers and kinda defeats the 
> purpose of using an open format like IDMEF.  I think a compression 
> profile would be the best solution and allow peers to negotiate a 
> compression profile when it is available on the client and the server.
> 
> I did a quick search and found a refernce to a suggestion for a 
> compression profile in the mailing list archive, whatever happened to 
> that idea?
> If a compression profile could be written it wouldn't work very well 
> with small messages, that is where a caching profile might be useful - 
> cache messages and compress a bunch of them at once.
> 
> What do you people think?
> 
> Ryan
> 
> _______________________________________________
> BEEPwg mailing list
> BEEPwg@lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Wed Jun 26 11:12:56 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22455
	for <beep-archive@odin.ietf.org>; Wed, 26 Jun 2002 11:12:56 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5QF99Y00291;
	Wed, 26 Jun 2002 08:09:09 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5QF8ZY00278
	for <beepwg@lists.beepcore.org>; Wed, 26 Jun 2002 08:08:35 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5QF7xr03783;
	Wed, 26 Jun 2002 08:07:59 -0700 (PDT)
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: "Eric Rescorla" <ekr@rtfm.com>
Cc: beepwg@lists.beepcore.org, ryan@silicondefense.com
Subject: Re: [BEEPwg] caching and compression profiles?
Message-Id: <20020626080758.50e23baf.mrose@dbc.mtview.ca.us>
In-Reply-To: <200206261337.g5QDb8W38974@romeo.rtfm.com>
References: <20020625231257.650f94c7.mrose@dbc.mtview.ca.us>
	<200206261337.g5QDb8W38974@romeo.rtfm.com>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Wed, 26 Jun 2002 08:07:58 -0700
Content-Transfer-Encoding: 7bit

> > eric - what's the story on TLS use of compression? is it automatic,
> > if available? or is there some other "magic" involved.
> Not good.
> 
> TLS has "support" for compression and automatic algorithm
> negotiation. However, no magic numbers are defined so it doesn't
> actually exist. Essentially what happened was that there were IPR
> concerns about all the algorithms so there was a reluctance to
> standardize.
> 
> A couple of people have implemented compression on an experimental
> scale but there's nothing standard. IIRC, OpenSSL has (disconnected)
> support for RLE and zlib.

eric - thanks, that's very good data. what that indicates to me is that if there's interest in a tuning profile for beep that does compression, then it should be used regardless of whether or not the session has already been tuned for privacy... (but, obviously, tuning for compression should occur after tuning for privacy!)

thanks!

/mtr
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Wed Jun 26 13:30:32 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01205
	for <beep-archive@odin.ietf.org>; Wed, 26 Jun 2002 13:30:31 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5QHU4Y01123;
	Wed, 26 Jun 2002 10:30:04 -0700 (PDT)
Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5QHTNY01101
	for <beepwg@lists.beepcore.org>; Wed, 26 Jun 2002 10:29:24 -0700 (PDT)
Received: from (local broken client) localhost(dh08.wetware.com[199.108.16.48]) (3242 bytes) by wetware.wetware.com
	via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <jhw@wetware.com>) 
	id <m17NGc0-002zeTC@wetware.wetware.com>
	for <beepwg@lists.beepcore.org>; Wed, 26 Jun 2002 10:29:48 -0700 (PDT)
	(Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4)
Subject: Re: [BEEPwg] SEQ frames and MIME entity headers
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: BEEP WG <beepwg@lists.beepcore.org>
To: Jered Floyd <jered@permabit.com>
From: james woodyatt <jhw@wetware.com>
In-Reply-To: <87k7oxvo0z.fsf@questionably-configured.permabit.com>
Message-Id: <A18DBCC8-892A-11D6-95F8-000502DB38F5@wetware.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Wed, 26 Jun 2002 10:32:04 -0700
Content-Transfer-Encoding: 7bit

[apologies for waiting so long to get back to this.  we were having a 
friendly discussion stemming from my deeply paranoid fear that 
unauthenticated peers might attack a beep listener by sending 
pathologically long entity headers in an attempt to deplete the space 
resources used by its MIME parser.]

On Monday, June 17, 2002, at 10:00 AM, Jered Floyd wrote:
> [I wrote:]
>> That's true, but it doesn't have to.  Applications that depend on that
>> feature can define mechanisms in their profiles for doing that.  The
>> core profiles don't have any such mechanism, but then-- they don't
>> need to send pathologically long entity headers, do they?
>
> Applications can only define mechanisms in their profiles only if
> their profiles are tied to only operate over a TCP transport. [...]

[if we recall, the mechanisms we are talking about would allow a 
mechanism to request an increase in the size of its channel window.]

I disagree.  Every BEEP connection is a point-to-point full-duplex flow 
over a network with finite resources.  Managing the share of that flow 
consumed by each channel is the job of the transport mapping.  While the 
TCP mapping uses SEQ frames for this purpose, since the transport 
provider itself doesn't provide a mechanism, *every* transport mapping 
will have some mechanism for this.

Applications need not be "tied" to the TCP transport mapping if they 
want to implement mechanisms for requesting a larger share of the flow.

> [...] The core profiles don't need to send 'pathologically'
> long entity headers, but they *could*, and changing the standard
> in such a way where the 'proper' behaviour can only be defined as
> 'deadlock' is inappropriate.  It's reasonable to disallow certain
> operations, but only if failure can be indicated meaningfully.

It's true.  The proposed standard is silent about what a BEEP listener 
may do in the face of an attack on its MIME parser space resource by an 
unauthenticated peer.

I should rephrase my original proposition: I think RFC 3081 should be 
amended (someday, over the rainbow) to say: "A peer MAY process the 
entity header fields in a message atomically; therefore, to avoid 
deadlock, a peer SHOULD NOT send a frame containing any part of the 
entity header of a message until the channel window is large enough to 
send the complete entity header (including its terminating CRLF)."

I'll worry about other transport mappings when they emerge from whatever 
dungeon in which they are currently withering.


--
j h woodyatt <jhw@wetware.com>

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Wed Jun 26 15:33:29 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07412
	for <beep-archive@odin.ietf.org>; Wed, 26 Jun 2002 15:33:28 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5QJX3Y01833;
	Wed, 26 Jun 2002 12:33:03 -0700 (PDT)
Received: from mail2.atl.registeredsite.com (nobody@mail2.atl.registeredsite.com [64.224.219.76])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5QJWGY01821
	for <beepwg@lists.beepcore.org>; Wed, 26 Jun 2002 12:32:16 -0700 (PDT)
Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241])
	by mail2.atl.registeredsite.com (8.12.2/8.12.2) with ESMTP id g5QJWkZg014708
	for <beepwg@lists.beepcore.org>; Wed, 26 Jun 2002 15:32:46 -0400
Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP
  (SMTPD32-6.06) id A6FE7D8000F8; Wed, 26 Jun 2002 15:33:18 -0400
From: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
To: <beepwg@lists.beepcore.org>
Subject: Re: [BEEPwg] caching and compression profiles?
Message-ID: <000201c21d48$3d681f80$0100a8c0@central>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Wed, 26 Jun 2002 20:32:40 +0100
Content-Transfer-Encoding: 7bit


One way a BEEP compression feature could be done is outlined in:

http://www.clipcode.org/peer/common-beep-features/index.htm

Eamon O'Tuathail
Clipcode.com

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Thu Jun 27 11:32:06 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24482
	for <beep-archive@odin.ietf.org>; Thu, 27 Jun 2002 11:32:06 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5RFV5Y09408;
	Thu, 27 Jun 2002 08:31:05 -0700 (PDT)
Received: from monsoon.us.ny.firstrain.com ([208.198.42.246])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5RFUeY09396
	for <beepwg@lists.beepcore.org>; Thu, 27 Jun 2002 08:30:40 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C21DF0.1F746AF8"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <C1C4A3C0FEE62A45A35BE7890264FF2788F27D@monsoon.us.ny.firstrain.com>
Thread-Topic: Benchmarks? Performance, conformance...
Thread-Index: AcId8B8WeggUQyttTjCyhI8MhyAXyg==
From: "Bob Wyman" <bobwyman@firstrain.com>
To: <beepwg@lists.beepcore.org>
Subject: [BEEPwg] Benchmarks? Performance, conformance...
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Thu, 27 Jun 2002 11:34:27 -0400

This is a multi-part message in MIME format.

------_=_NextPart_001_01C21DF0.1F746AF8
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Has anyone developed, or is anyone developing, any useful BEEP
performance and/or conformance benchmarks or testing suites that might
be useful in compariing the performance and/or conformance to
specification of various implementations of BEEP?
=20
Whether or not your are developing such things, I would appreciate
pointers to benchmark or validation suites developed for similar
protocols or your comments on how such testing should be most properly
done.
=20
        bob wyman
=20

------_=_NextPart_001_01C21DF0.1F746AF8
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D770143015-27062002><FONT face=3DArial size=3D2>Has =
anyone=20
developed, or is anyone developing, any useful BEEP performance and/or=20
conformance benchmarks or testing suites that might be useful in =
compariing the=20
performance and/or conformance to specification of various =
implementations of=20
BEEP?</FONT></SPAN></DIV>
<DIV><SPAN class=3D770143015-27062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D770143015-27062002><FONT face=3DArial =
size=3D2>Whether or not your=20
are developing such things, I would appreciate pointers to benchmark or=20
validation suites developed for similar protocols or your comments on =
how such=20
testing should be most properly done.</FONT></SPAN></DIV>
<DIV><SPAN class=3D770143015-27062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN =
class=3D770143015-27062002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial size=3D2>bob wyman</FONT></SPAN></DIV>
<DIV><SPAN class=3D770143015-27062002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C21DF0.1F746AF8--
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 02:54:49 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12237
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 02:54:48 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5S6s5Y14645;
	Thu, 27 Jun 2002 23:54:05 -0700 (PDT)
Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5S6rFY14629
	for <beepwg@lists.beepcore.org>; Thu, 27 Jun 2002 23:53:16 -0700 (PDT)
Received: (qmail 19664 invoked by uid 417); 28 Jun 2002 06:53:46 -0000
Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12)
  by shunt-smtp-out-0 with SMTP; 28 Jun 2002 06:53:46 -0000
Received: from testing ([203.196.132.237])
  (AUTH: LOGIN chakpak@softhome.net)
  by softhome.net with esmtp; Fri, 28 Jun 2002 00:53:42 -0600
Reply-To: chakpak@softhome.net
From: "Rohit Karlupia" <chakpak@softhome.net>
To: beepwg@lists.beepcore.org
Message-ID: <FEEBJIPBIIGHNPOELBJPMEFPCDAA.chakpak@softhome.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <C1C4A3C0FEE62A45A35BE7890264FF2788F27D@monsoon.us.ny.firstrain.com>
Subject: [BEEPwg] Soap Over Beep Question
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 12:30:46 +0530
Content-Transfer-Encoding: 7bit


Hi ALL!

I have a question regarding the SOAP Message Patterns.
In the section 4.1 under SOAP Message Patterns, the RFC 3288 says 
that in case of One-way Message exchange...

"....in which the client sends a "MSG" message containing 
an envelope, and the server immediately sends back a "NUL" 
message, before processing the contents of the envelope."

My question is: How does the server knows that the given MSG 
message containing the SOAP envelope is to be replied using 
the NUL message before processing the message? 

Since there is nothing in the syntax of SOAP Over Beep messages
which suggests how the message is to be replied with (i.e. if
this is a one way, 2 way or multi answer response)..the server 
will only know about the type of message pattern being used only 
from processing the SOAP message. 

Please enlighten me on this. I may be completely missing something.

Thanks,
Rohit Karlupia




_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 11:46:29 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01995
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 11:46:28 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SFijY18190;
	Fri, 28 Jun 2002 08:44:45 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SFhlY18172
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 08:43:47 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5SFgbe03304;
	Fri, 28 Jun 2002 08:42:37 -0700 (PDT)
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: beepwg@lists.beepcore.org
Cc: chakpak@softhome.net
Subject: Re: [BEEPwg] Soap Over Beep Question
Message-Id: <20020628084236.70f1e431.mrose@dbc.mtview.ca.us>
In-Reply-To: <FEEBJIPBIIGHNPOELBJPMEFPCDAA.chakpak@softhome.net>
References: <C1C4A3C0FEE62A45A35BE7890264FF2788F27D@monsoon.us.ny.firstrain.com>
	<FEEBJIPBIIGHNPOELBJPMEFPCDAA.chakpak@softhome.net>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 08:42:36 -0700
Content-Transfer-Encoding: 7bit

> Since there is nothing in the syntax of SOAP Over Beep messages
> which suggests how the message is to be replied with (i.e. if
> this is a one way, 2 way or multi answer response)..the server 
> will only know about the type of message pattern being used only 
> from processing the SOAP message. 

this is really a soap-specific issue, not a beep- or soap-over-beep issue.

the answer is the "server" can either have some kind of pre-knowledge over the kind of messages it gets (i.e., the service it offers only dones one-way exchanges), or, the first thing the "server" does is parse the envelope and thereby know what's what.

there, are, of course, some interesting failure modes with either approach.

/mtr
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 13:00:23 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06920
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 13:00:22 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SGx4Y18618;
	Fri, 28 Jun 2002 09:59:04 -0700 (PDT)
Received: from xomi.pair.com (xomi.pair.com [209.68.2.14])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5SGwQY18606
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 09:58:27 -0700 (PDT)
Received: (qmail 24680 invoked by uid 3039); 28 Jun 2002 16:59:04 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 28 Jun 2002 16:59:04 -0000
From: Gabe Wachob <gwachob@wachob.com>
X-Sender:  <gwachob@xomi.pair.com>
To: Marshall Rose <mrose@dbc.mtview.ca.us>
cc: <beepwg@lists.beepcore.org>, <chakpak@softhome.net>
Subject: Re: [BEEPwg] Soap Over Beep Question
In-Reply-To: <20020628084236.70f1e431.mrose@dbc.mtview.ca.us>
Message-ID: <Pine.BSF.4.30.0206280951090.8947-100000@xomi.pair.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 09:59:04 -0700 (PDT)

I think this is a legitimate issue for the SOAP/BEEP RFC.

Message exchange patterns is a hot discussion topic over at the XMLP WG,
and its not clear (at least to me) how the message pattern for a
particular message will be expressed. But no matter what, I would expect
that message patterns for each message type, even on a single BEEP
channel, could be different.

THUS, for a recipient peer to know which message pattern is intended,
there either a) has to be a way to express the desired message pattern at
the "transport" level (e.g. within a BEEP message/channel) or b) within
the message.

Thus, the SOAP/BEEP profile will either have to provide a facility for
communicating the intended message exchange pattern (a per-message
header?) or the recipient node will have to at least partially process the
incoming message to decide which messaging pattern is appropriate (and
whether a NUL or RPY response is appropriate).

Either way, it seems that the SOAP/BEEP RFC is inadequate here because it
assumes the recipient has knowledge of the messaging pattern for a
particular message without giving the recipient any chance to figure it
out.

	-Gabe

On Fri, 28 Jun 2002, Marshall Rose wrote:

> > Since there is nothing in the syntax of SOAP Over Beep messages
> > which suggests how the message is to be replied with (i.e. if
> > this is a one way, 2 way or multi answer response)..the server
> > will only know about the type of message pattern being used only
> > from processing the SOAP message.
>
> this is really a soap-specific issue, not a beep- or soap-over-beep issue.
>
> the answer is the "server" can either have some kind of pre-knowledge over the kind of messages it gets (i.e., the service it offers only dones one-way exchanges), or, the first thing the "server" does is parse the envelope and thereby know what's what.
>
> there, are, of course, some interesting failure modes with either approach.
>
> /mtr
> _______________________________________________
> BEEPwg mailing list
> BEEPwg@lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
>

-- 
Gabe Wachob                       gwachob@wachob.com
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 14:43:56 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13686
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 14:43:54 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SIg4Y19178;
	Fri, 28 Jun 2002 11:42:04 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SIf7Y19162
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 11:41:07 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5SIeme03415;
	Fri, 28 Jun 2002 11:40:48 -0700 (PDT)
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: "Gabe Wachob" <gwachob@wachob.com>
Cc: beepwg@lists.beepcore.org, chakpak@softhome.net
Subject: Re: [BEEPwg] Soap Over Beep Question
Message-Id: <20020628114048.3ece91de.mrose@dbc.mtview.ca.us>
In-Reply-To: <Pine.BSF.4.30.0206280951090.8947-100000@xomi.pair.com>
References: <20020628084236.70f1e431.mrose@dbc.mtview.ca.us>
	<Pine.BSF.4.30.0206280951090.8947-100000@xomi.pair.com>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 11:40:48 -0700
Content-Transfer-Encoding: 7bit

> Either way, it seems that the SOAP/BEEP RFC is inadequate here because it
> assumes the recipient has knowledge of the messaging pattern for a
> particular message without giving the recipient any chance to figure it
> out.

uh, no. it's up to the soap folks to decide how to deal with this. beep, and soap-over-beep, just doesn't care.

i could just as easily s/beep/http/g in the original note and the same issue exists. ditto for s/beep/smtp/g

/mtr
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 14:57:40 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14583
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 14:57:39 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SIv2Y19511;
	Fri, 28 Jun 2002 11:57:02 -0700 (PDT)
Received: from xomi.pair.com (xomi.pair.com [209.68.2.14])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5SIueY19498
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 11:56:40 -0700 (PDT)
Received: (qmail 36051 invoked by uid 3039); 28 Jun 2002 18:57:22 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 28 Jun 2002 18:57:22 -0000
From: Gabe Wachob <gwachob@wachob.com>
X-Sender:  <gwachob@xomi.pair.com>
To: Marshall Rose <mrose@dbc.mtview.ca.us>
cc: <beepwg@lists.beepcore.org>, <chakpak@softhome.net>
Subject: Re: [BEEPwg] Soap Over Beep Question
In-Reply-To: <20020628114048.3ece91de.mrose@dbc.mtview.ca.us>
Message-ID: <Pine.BSF.4.30.0206281144400.26506-100000@xomi.pair.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 11:57:22 -0700 (PDT)

On Fri, 28 Jun 2002, Marshall Rose wrote:

> > Either way, it seems that the SOAP/BEEP RFC is inadequate here because it
> > assumes the recipient has knowledge of the messaging pattern for a
> > particular message without giving the recipient any chance to figure it
> > out.
>
> uh, no. it's up to the soap folks to decide how to deal with this.
> beep, and soap-over-beep, just doesn't care.
>
> i could just as easily s/beep/http/g in the original note and the same
> issue exists. ditto for s/beep/smtp/g

Uh, no.

The beep/http binding does NOT specify that the recipient must send back a
HTTP 200 response "before processing the contents of the envelope."

Thats the problem. In fact, the HTTP bindings don't speak about one-way
messaging at all (which is too bad). I'm saying that the phrase under
consideration requires the recipient to know the message pattern before it
has any way of knowing it. Its a logical problem. At the very least I
think the language in this RFC is premature as it eliminates the
possibility of SOAP using a header to express the messaging pattern. The
only way I see out of this is using a BEEP header (ie along the lines of a
MIME header) which expresses the messaging pattern. That assumes the SOAP
people go with expressing the MEP at the transport level.

	-Gabe

-- 
Gabe Wachob                       gwachob@wachob.com
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 15:24:34 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16237
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 15:24:33 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SJO6Y19785;
	Fri, 28 Jun 2002 12:24:06 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SJNFY19766
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 12:23:15 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5SJMge03507;
	Fri, 28 Jun 2002 12:22:42 -0700 (PDT)
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: beepwg@lists.beepcore.org
Cc: mbeck@cs.utk.edu
Message-Id: <20020628122241.3ca70498.mrose@dbc.mtview.ca.us>
In-Reply-To: <012201c21ed7$57fe9820$333924a0@laptop60>
References: <012201c21ed7$57fe9820$333924a0@laptop60>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: [BEEPwg] Re: unsubscribing
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 12:22:41 -0700
Content-Transfer-Encoding: 7bit

> I would like to unsubscribe from the BEEP mailing list but I do not have my password. 
> Can you help me please? Micah Beck

	http://lists.beepcore.org/mailman/listinfo/beepwg

/mtr
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 16:11:41 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19181
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 16:11:40 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SKB7Y20509;
	Fri, 28 Jun 2002 13:11:07 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SKAjY20497
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 13:10:45 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5SK9qe03591;
	Fri, 28 Jun 2002 13:09:52 -0700 (PDT)
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: "Gabe Wachob" <gwachob@wachob.com>
Cc: beepwg@lists.beepcore.org, chakpak@softhome.net
Subject: Re: [BEEPwg] Soap Over Beep Question
Message-Id: <20020628130951.736cc0af.mrose@dbc.mtview.ca.us>
In-Reply-To: <Pine.BSF.4.30.0206281144400.26506-100000@xomi.pair.com>
References: <20020628114048.3ece91de.mrose@dbc.mtview.ca.us>
	<Pine.BSF.4.30.0206281144400.26506-100000@xomi.pair.com>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 13:09:51 -0700
Content-Transfer-Encoding: 7bit

> The beep/http binding does NOT specify that the recipient must send back a
> HTTP 200 response "before processing the contents of the envelope."
> 
> Thats the problem. In fact, the HTTP bindings don't speak about one-way
> messaging at all (which is too bad). I'm saying that the phrase under
> consideration requires the recipient to know the message pattern before it
> has any way of knowing it. Its a logical problem. At the very least I
> think the language in this RFC is premature as it eliminates the
> possibility of SOAP using a header to express the messaging pattern. The
> only way I see out of this is using a BEEP header (ie along the lines of a
> MIME header) which expresses the messaging pattern. That assumes the SOAP
> people go with expressing the MEP at the transport level.

perhaps, but perhaps not.

the fact that similar language doesn't appear in the http binding doesn't mean the problem isn't the same...

m/tr
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 17:03:39 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21843
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 17:03:38 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SL34Y20854;
	Fri, 28 Jun 2002 14:03:04 -0700 (PDT)
Received: from mail3.atl.registeredsite.com (nobody@mail3.atl.registeredsite.com [64.224.219.77])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SL2BY20838
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 14:02:11 -0700 (PDT)
Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241])
	by mail3.atl.registeredsite.com (8.12.2/8.12.2) with ESMTP id g5SL2lW0008183;
	Fri, 28 Jun 2002 17:02:48 -0400
Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP
  (SMTPD32-6.06) id AF135F0800A8; Fri, 28 Jun 2002 17:03:15 -0400
From: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
To: <beepwg@lists.beepcore.org>
Cc: <gwachob@wachob.com>, <chakpak@softhome.net>, <mrose@dbc.mtview.ca.us>
Subject: [BEEPwg] Soap Over Beep Question
Message-ID: <000001c21ee7$2307fd40$0100a8c0@central>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <200206281901.g5SJ12Y19588@qawoor.dbc.mtview.ca.us>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 22:02:34 +0100
Content-Transfer-Encoding: 7bit

Hi,

One has two options with one-way messages:

Either the peer acting as the server knows that it has to respond with a
NUL, or it peeks inside the envelope, and they replies with NUL, before
doing any substantive processing of the envelope contents. The former
scenario is for servers that typically will only accept one-way messages
(e.g. notification-style messages) and the latter would typically be for
servers that accept a mixture of message patterns. 

Eamon


_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 17:31:33 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23485
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 17:31:33 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SLT3Y21022;
	Fri, 28 Jun 2002 14:29:03 -0700 (PDT)
Received: from xomi.pair.com (xomi.pair.com [209.68.2.14])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5SLSwY21010
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 14:28:58 -0700 (PDT)
Received: (qmail 52668 invoked by uid 3039); 28 Jun 2002 21:29:37 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 28 Jun 2002 21:29:37 -0000
From: Gabe Wachob <gwachob@wachob.com>
X-Sender:  <gwachob@xomi.pair.com>
To: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
cc: <beepwg@lists.beepcore.org>, <chakpak@softhome.net>,
        <mrose@dbc.mtview.ca.us>
Subject: Re: [BEEPwg] Soap Over Beep Question
In-Reply-To: <000001c21ee7$2307fd40$0100a8c0@central>
Message-ID: <Pine.BSF.4.30.0206281426530.39803-100000@xomi.pair.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Fri, 28 Jun 2002 14:29:37 -0700 (PDT)

IN the case of mixture of patterns (which I think will be the modal case),
the wording *could* be interpreted to allow what you describe below
("peeks inside the envelope").

The way I read "immediately sends back a "NUL" message, before processing
the contents of the envelope" says that you *can't* do what you propose.
The trick is what you mean by the "contents of the envelope". I read this
as "you can't open up the SOAP envelope at all". I think you are
suggesting something else?

	-Gabe

On Fri, 28 Jun 2002, Eamon O'Tuathail wrote:

> Hi,
>
> One has two options with one-way messages:
>
> Either the peer acting as the server knows that it has to respond with a
> NUL, or it peeks inside the envelope, and they replies with NUL, before
> doing any substantive processing of the envelope contents. The former
> scenario is for servers that typically will only accept one-way messages
> (e.g. notification-style messages) and the latter would typically be for
> servers that accept a mixture of message patterns.
>
> Eamon
>
>
> _______________________________________________
> BEEPwg mailing list
> BEEPwg@lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
>

-- 
Gabe Wachob                       gwachob@wachob.com
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Fri Jun 28 18:14:14 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25546
	for <beep-archive@odin.ietf.org>; Fri, 28 Jun 2002 18:14:13 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5SMD3Y21296;
	Fri, 28 Jun 2002 15:13:03 -0700 (PDT)
Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5SMCDY21284
	for <beepwg@lists.beepcore.org>; Fri, 28 Jun 2002 15:12:13 -0700 (PDT)
Received: (qmail 27802 invoked by uid 417); 28 Jun 2002 22:12:57 -0000
Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12)
  by shunt-smtp-out-0 with SMTP; 28 Jun 2002 22:12:57 -0000
Received: from testing ([203.122.21.130])
  (AUTH: LOGIN chakpak@softhome.net)
  by softhome.net with esmtp; Fri, 28 Jun 2002 16:12:51 -0600
Reply-To: chakpak@softhome.net
From: "Rohit Karlupia" <chakpak@softhome.net>
To: "Gabe Wachob" <gwachob@wachob.com>,
        "Marshall Rose" <mrose@dbc.mtview.ca.us>
Cc: beepwg@lists.beepcore.org
Subject: RE: [BEEPwg] Soap Over Beep Question
Message-ID: <FEEBJIPBIIGHNPOELBJPEEGICDAA.chakpak@softhome.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <Pine.BSF.4.30.0206280951090.8947-100000@xomi.pair.com>
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Sat, 29 Jun 2002 03:49:55 +0530
Content-Transfer-Encoding: 7bit


I stand by your views Gabe.
I was thinking, as you suggested that message exchange pattern
could be either channel specific, in which case it could
be the property of the "resource" or "feature" negotiated during
the channel initialization; there must be some additional
tag(header) with the message that suggests the message pattern being
used.

I think it would be restrictive to make message patterns
channel specific. And thus would not support it as a solution.

I personally believe that it would be good to have the
message pattern information "outside" the SOAP message. This
would not only help the servers in deciding which BEEP message
type to use for responding to messages, but also help the client
to know beforehand what BEEP message to expect, and thus be
ready for it. Moreover, it would also allow the SOAP Application
developers to think in terms of which message patterns to use,
than to have the code taking care of any possible type of exchange.

I think it would be an important issue in a scenario when one doesn't own
both the
server and the client. All the applications will be using one
of the three possible message patterns, and these message patterns will
have to be "specified"/"known" by both the communicating applications
(server and client)before they can communicate. Thus, it makes sense to
resolve this ambiguity at the protocol level and thereby create a unifying
standard to increase interoperability.

regards,
Rohit Karlupia






-----Original Message-----
From: beepwg-admin@lists.beepcore.org
[mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Gabe Wachob
Sent: Friday, June 28, 2002 10:29 PM
To: Marshall Rose
Cc: beepwg@lists.beepcore.org; chakpak@softhome.net
Subject: Re: [BEEPwg] Soap Over Beep Question


I think this is a legitimate issue for the SOAP/BEEP RFC.

Message exchange patterns is a hot discussion topic over at the XMLP WG,
and its not clear (at least to me) how the message pattern for a
particular message will be expressed. But no matter what, I would expect
that message patterns for each message type, even on a single BEEP
channel, could be different.

THUS, for a recipient peer to know which message pattern is intended,
there either a) has to be a way to express the desired message pattern at
the "transport" level (e.g. within a BEEP message/channel) or b) within
the message.

Thus, the SOAP/BEEP profile will either have to provide a facility for
communicating the intended message exchange pattern (a per-message
header?) or the recipient node will have to at least partially process the
incoming message to decide which messaging pattern is appropriate (and
whether a NUL or RPY response is appropriate).

Either way, it seems that the SOAP/BEEP RFC is inadequate here because it
assumes the recipient has knowledge of the messaging pattern for a
particular message without giving the recipient any chance to figure it
out.

	-Gabe

On Fri, 28 Jun 2002, Marshall Rose wrote:

> > Since there is nothing in the syntax of SOAP Over Beep messages
> > which suggests how the message is to be replied with (i.e. if
> > this is a one way, 2 way or multi answer response)..the server
> > will only know about the type of message pattern being used only
> > from processing the SOAP message.
>
> this is really a soap-specific issue, not a beep- or soap-over-beep issue.
>
> the answer is the "server" can either have some kind of pre-knowledge over
the kind of messages it gets (i.e., the service it offers only dones one-way
exchanges), or, the first thing the "server" does is parse the envelope and
thereby know what's what.
>
> there, are, of course, some interesting failure modes with either
approach.
>
> /mtr
> _______________________________________________
> BEEPwg mailing list
> BEEPwg@lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
>

--
Gabe Wachob                       gwachob@wachob.com
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Sat Jun 29 09:37:15 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24966
	for <beep-archive@odin.ietf.org>; Sat, 29 Jun 2002 09:37:14 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5TDaDY26919;
	Sat, 29 Jun 2002 06:36:13 -0700 (PDT)
Received: from mail4.atl.registeredsite.com (nobody@mail4.atl.registeredsite.com [64.224.219.78])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5TDZaY26901
	for <beepwg@lists.beepcore.org>; Sat, 29 Jun 2002 06:35:36 -0700 (PDT)
Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241])
	by mail4.atl.registeredsite.com (8.12.2/8.12.2) with ESMTP id g5TDaFTN026404;
	Sat, 29 Jun 2002 09:36:17 -0400
Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP
  (SMTPD32-6.06) id A7EB84A4014C; Sat, 29 Jun 2002 09:36:43 -0400
From: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
To: "'Gabe Wachob'" <gwachob@wachob.com>
Cc: <beepwg@lists.beepcore.org>, <chakpak@softhome.net>,
        <mrose@dbc.mtview.ca.us>
Subject: RE: [BEEPwg] Soap Over Beep Question
Message-ID: <001501c21f71$ec62d220$0100a8c0@central>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <Pine.BSF.4.30.0206281426530.39803-100000@xomi.pair.com>
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Sat, 29 Jun 2002 14:36:03 +0100
Content-Transfer-Encoding: 7bit

Gabe,

If you have no other way of identifying that it is a one-way message,
then you can examine the message, and when you have decided that it
one-way, then respond with the NUL, and after that you can "process" the
message. By "process" I mean the substantive work that you will do as a
result of receiving the message (e.g. write to a database, interact with
the file system, start a new process, etc.). 

Eamon

-----Original Message-----
From: Gabe Wachob [mailto:gwachob@wachob.com] 
Sent: 28 June 2002 22:30
To: Eamon O'Tuathail
Cc: beepwg@lists.beepcore.org; chakpak@softhome.net;
mrose@dbc.mtview.ca.us
Subject: Re: [BEEPwg] Soap Over Beep Question

IN the case of mixture of patterns (which I think will be the modal
case),
the wording *could* be interpreted to allow what you describe below
("peeks inside the envelope").

The way I read "immediately sends back a "NUL" message, before
processing
the contents of the envelope" says that you *can't* do what you propose.
The trick is what you mean by the "contents of the envelope". I read
this
as "you can't open up the SOAP envelope at all". I think you are
suggesting something else?

	-Gabe

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Sat Jun 29 17:12:46 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05416
	for <beep-archive@odin.ietf.org>; Sat, 29 Jun 2002 17:12:45 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5TL95Y29568;
	Sat, 29 Jun 2002 14:09:05 -0700 (PDT)
Received: from xomi.pair.com (xomi.pair.com [209.68.2.14])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5TL85Y29556
	for <beepwg@lists.beepcore.org>; Sat, 29 Jun 2002 14:08:05 -0700 (PDT)
Received: (qmail 97876 invoked by uid 3039); 29 Jun 2002 21:08:54 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 29 Jun 2002 21:08:54 -0000
From: Gabe Wachob <gwachob@wachob.com>
X-Sender:  <gwachob@xomi.pair.com>
To: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
cc: <beepwg@lists.beepcore.org>, <chakpak@softhome.net>,
        <mrose@dbc.mtview.ca.us>
Subject: RE: [BEEPwg] Soap Over Beep Question
In-Reply-To: <001501c21f71$ec62d220$0100a8c0@central>
Message-ID: <Pine.BSF.4.30.0206291407490.97650-100000@xomi.pair.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Sat, 29 Jun 2002 14:08:54 -0700 (PDT)

Thanks for the clarification.

I think we were reading that one sentence too literally.

These back and forth discussions serve a useful purpose because even
though the RFC is finalized, these archives will hopefully prevent repeat
questions. I just hope the archives stay up relatively permanently.

	-Gabe

On Sat, 29 Jun 2002, Eamon O'Tuathail wrote:

> Gabe,
>
> If you have no other way of identifying that it is a one-way message,
> then you can examine the message, and when you have decided that it
> one-way, then respond with the NUL, and after that you can "process" the
> message. By "process" I mean the substantive work that you will do as a
> result of receiving the message (e.g. write to a database, interact with
> the file system, start a new process, etc.).
>
> Eamon
>
> -----Original Message-----
> From: Gabe Wachob [mailto:gwachob@wachob.com]
> Sent: 28 June 2002 22:30
> To: Eamon O'Tuathail
> Cc: beepwg@lists.beepcore.org; chakpak@softhome.net;
> mrose@dbc.mtview.ca.us
> Subject: Re: [BEEPwg] Soap Over Beep Question
>
> IN the case of mixture of patterns (which I think will be the modal
> case),
> the wording *could* be interpreted to allow what you describe below
> ("peeks inside the envelope").
>
> The way I read "immediately sends back a "NUL" message, before
> processing
> the contents of the envelope" says that you *can't* do what you propose.
> The trick is what you mean by the "contents of the envelope". I read
> this
> as "you can't open up the SOAP envelope at all". I think you are
> suggesting something else?
>
> 	-Gabe
>
> _______________________________________________
> BEEPwg mailing list
> BEEPwg@lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
>

-- 
Gabe Wachob                       gwachob@wachob.com
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Sun Jun 30 03:03:03 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24254
	for <beep-archive@odin.ietf.org>; Sun, 30 Jun 2002 03:03:03 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5U72FY02936;
	Sun, 30 Jun 2002 00:02:15 -0700 (PDT)
Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5U717Y02922
	for <beepwg@lists.beepcore.org>; Sun, 30 Jun 2002 00:01:08 -0700 (PDT)
Received: (qmail 21140 invoked by uid 417); 30 Jun 2002 07:02:00 -0000
Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12)
  by shunt-smtp-out-0 with SMTP; 30 Jun 2002 07:02:00 -0000
Received: from testing ([203.122.21.130])
  (AUTH: LOGIN chakpak@softhome.net)
  by softhome.net with esmtp; Sun, 30 Jun 2002 01:01:56 -0600
Reply-To: chakpak@softhome.net
From: "Rohit Karlupia" <chakpak@softhome.net>
To: "Gabe Wachob" <gwachob@wachob.com>,
        "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>,
        beepwg@lists.beepcore.org
Cc: mrose@dbc.mtview.ca.us
Subject: RE: [BEEPwg] Soap Over Beep Question
Message-ID: <FEEBJIPBIIGHNPOELBJPMEHFCDAA.chakpak@softhome.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <Pine.BSF.4.30.0206291407490.97650-100000@xomi.pair.com>
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Sun, 30 Jun 2002 12:39:01 +0530
Content-Transfer-Encoding: 7bit

Hi!

Thank you all for your inputs on the question. 
Eamon has very clearly stated the intent/meaning of 
that line and I am clear about it now.

There is one request I have. Would you guys care to reply 
to my second email. Starting from the first day I read
SOAP Over BEEP, I had this question in mind that why there
are no tags for message patterns, since in my openion they
would have made life alots easier for people using SOAP Over
BEEP. I would feel complete about the discussion if you guys
could give me some hints on why this was not done.

Thanks One Again! And looking forward to some more insights
on SOAP Over BEEP.

regards,
Rohit Karlupia 




-----Original Message-----
From: beepwg-admin@lists.beepcore.org
[mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Gabe Wachob
Sent: Sunday, June 30, 2002 2:39 AM
To: Eamon O'Tuathail
Cc: beepwg@lists.beepcore.org; chakpak@softhome.net;
mrose@dbc.mtview.ca.us
Subject: RE: [BEEPwg] Soap Over Beep Question


Thanks for the clarification.

I think we were reading that one sentence too literally.

These back and forth discussions serve a useful purpose because even
though the RFC is finalized, these archives will hopefully prevent repeat
questions. I just hope the archives stay up relatively permanently.

	-Gabe

On Sat, 29 Jun 2002, Eamon O'Tuathail wrote:

http://lists.beepcore.org/mailman/listinfo/beepwg
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Sun Jun 30 12:58:10 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06203
	for <beep-archive@odin.ietf.org>; Sun, 30 Jun 2002 12:58:10 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5UGv8Y06894;
	Sun, 30 Jun 2002 09:57:08 -0700 (PDT)
Received: from mail1.atl.registeredsite.com (nobody@mail1.atl.registeredsite.com [64.224.219.75])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5UGuYY06882
	for <beepwg@lists.beepcore.org>; Sun, 30 Jun 2002 09:56:34 -0700 (PDT)
Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241])
	by mail1.atl.registeredsite.com (8.12.3/8.12.2) with ESMTP id g5UGvIhJ031990;
	Sun, 30 Jun 2002 12:57:19 -0400
Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP
  (SMTPD32-6.06) id A88D3E190128; Sun, 30 Jun 2002 12:57:49 -0400
From: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
To: <chakpak@softhome.net>, "'Gabe Wachob'" <gwachob@wachob.com>,
        <beepwg@lists.beepcore.org>
Cc: <mrose@dbc.mtview.ca.us>
Subject: RE: [BEEPwg] Soap Over Beep Question
Message-ID: <000001c22057$2ef50b90$0100a8c0@central>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <FEEBJIPBIIGHNPOELBJPMEHFCDAA.chakpak@softhome.net>
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Sun, 30 Jun 2002 17:57:10 +0100
Content-Transfer-Encoding: 7bit

Rohit,

We did look at where to put information that is exchanged between the
BEEP peers, and concluded it was best to put it all inside the SOAP
envelope, and not to have any additional information flows (external to
the envelope). 

Note that RFC 3288 focuses on how SOAP travels over BEEP, not on the
internals of the SOAP envelope - the latter is the job of the W3C
XMLP/SOAP WG. 

I can appreciate why people might like an explicit description of the
message pattern to use, but you have to ask yourself would such a
description be useful only to BEEP, or might it also interest non-BEEP
SOAP users too (e.g. those who use SOAP-over-HTTP or SOAP-over-SMTP). I
think you will answer "yes" to this, and therefore the message pattern
description should rightly be placed inside the SOAP envelope (as a SOAP
message header), so it can be used by all. 

At the moment there is no (IANA-like) registry of possible message
pattern descriptions, but I could see it envolving in future. For now,
peers that accept multiple message patterns must determine from the
message how to respond.  
 
Eamon

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


From beepwg-admin@lists.beepcore.org  Sun Jun 30 15:04:14 2002
Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09189
	for <beep-archive@odin.ietf.org>; Sun, 30 Jun 2002 15:04:13 -0400 (EDT)
Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g5UJ3DH00387;
	Sun, 30 Jun 2002 12:03:13 -0700 (PDT)
Received: from xomi.pair.com (xomi.pair.com [209.68.2.14])
	by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g5UJ29H00362
	for <beepwg@lists.beepcore.org>; Sun, 30 Jun 2002 12:02:10 -0700 (PDT)
Received: (qmail 24013 invoked by uid 3039); 30 Jun 2002 19:02:59 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 30 Jun 2002 19:02:59 -0000
From: Gabe Wachob <gwachob@wachob.com>
X-Sender:  <gwachob@xomi.pair.com>
To: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com>
cc: <chakpak@softhome.net>, <beepwg@lists.beepcore.org>,
        <mrose@dbc.mtview.ca.us>
Subject: RE: [BEEPwg] Soap Over Beep Question
In-Reply-To: <000001c22057$2ef50b90$0100a8c0@central>
Message-ID: <Pine.BSF.4.30.0206301159540.21921-100000@xomi.pair.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: beepwg-admin@lists.beepcore.org
Errors-To: beepwg-admin@lists.beepcore.org
X-BeenThere: beepwg@lists.beepcore.org
X-Mailman-Version: 2.0.6
Precedence: bulk
List-Help: <mailto:beepwg-request@lists.beepcore.org?subject=help>
List-Post: <mailto:beepwg@lists.beepcore.org>
List-Subscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=subscribe>
List-Id: Mailing list for the IETF's BEEP working group <beepwg.lists.beepcore.org>
List-Unsubscribe: <http://lists.beepcore.org/mailman/listinfo/beepwg>,
	<mailto:beepwg-request@lists.beepcore.org?subject=unsubscribe>
List-Archive: <http://lists.beepcore.org/pipermail/beepwg/>
Date: Sun, 30 Jun 2002 12:02:59 -0700 (PDT)

This discussion of where to put message exchange pattern information is a
live topic over at the XMLP, from what I can tell.

Some there appear to take the position that the MEP should be expressed
*by the transport binding* - that is, it would be expressed within the
BEEP profile (perhaps as a custom message header?). They apparently
believe that *they* are going to specify or have great influence over the
SOAP bindings.

So, your conclusion about where to put that information *may* end up being
in direct contradiction to what the XMLP group says.

Its not clear to me at this point, however, where the prevailing winds are
blowing, and I'm not sure this issue is soon to be closed (or if it has
very recently been closed at all).

	-Gabe

On Sun, 30 Jun 2002, Eamon O'Tuathail wrote:

> Rohit,
>
> We did look at where to put information that is exchanged between the
> BEEP peers, and concluded it was best to put it all inside the SOAP
> envelope, and not to have any additional information flows (external to
> the envelope).
>
> Note that RFC 3288 focuses on how SOAP travels over BEEP, not on the
> internals of the SOAP envelope - the latter is the job of the W3C
> XMLP/SOAP WG.
>
> I can appreciate why people might like an explicit description of the
> message pattern to use, but you have to ask yourself would such a
> description be useful only to BEEP, or might it also interest non-BEEP
> SOAP users too (e.g. those who use SOAP-over-HTTP or SOAP-over-SMTP). I
> think you will answer "yes" to this, and therefore the message pattern
> description should rightly be placed inside the SOAP envelope (as a SOAP
> message header), so it can be used by all.
>
> At the moment there is no (IANA-like) registry of possible message
> pattern descriptions, but I could see it envolving in future. For now,
> peers that accept multiple message patterns must determine from the
> message how to respond.
>
> Eamon
>
> _______________________________________________
> BEEPwg mailing list
> BEEPwg@lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
>

-- 
Gabe Wachob                       gwachob@wachob.com
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg