From beepwg-admin@lists.beepcore.org Wed Mar 17 13:14:51 2004 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 NAA27386 for ; Wed, 17 Mar 2004 13:14:49 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2HI3EFV028618; Wed, 17 Mar 2004 10:03:14 -0800 (PST) Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2HHqeFV028526 for ; Wed, 17 Mar 2004 09:52:40 -0800 (PST) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i2HHqYBm095680 for ; Wed, 17 Mar 2004 09:52:34 -0800 (PST) (envelope-from lzhang@juniper.net) Received: from juniper.net (lzhang-bsd.juniper.net [172.17.20.151]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2HHqWJ97328 for ; Wed, 17 Mar 2004 09:52:34 -0800 (PST) (envelope-from lzhang@juniper.net) Message-ID: <40589060.70207@juniper.net> From: Lei Zhang User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020206 X-Accept-Language: en-us MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEEPwg] contained within Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Mar 2004 09:52:32 -0800 Content-Transfer-Encoding: 7bit Hi, A simple question that I cannot find answer from RFC 3080: should a message contain _all_ profiles the BEEP peer supports, or should it contain only those profiles that it is willing to act as listener? What's the intended use for those profile elements in a message? Thanks.. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 17 20:05:40 2004 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 UAA21097 for ; Wed, 17 Mar 2004 20:05:39 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2I0rDFV001940; Wed, 17 Mar 2004 16:53:13 -0800 (PST) Received: from drakken.dbc.mtview.ca.us (64-73-228-56.cust.telepacific.net [64.73.228.56]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2I0hsFV001878 for ; Wed, 17 Mar 2004 16:43:54 -0800 (PST) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id i2I0hncW004380; Wed, 17 Mar 2004 16:43:49 -0800 (PST) From: Marshall Rose To: Lei Zhang Cc: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] contained within Message-Id: <20040317164349.4c297902.mrose@dbc.mtview.ca.us> In-Reply-To: <40589060.70207@juniper.net> References: <40589060.70207@juniper.net> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) 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.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Mar 2004 16:43:49 -0800 Content-Transfer-Encoding: 7bit > A simple question that I cannot find answer from RFC 3080: should a > message contain _all_ profiles the BEEP peer supports, or > should it contain only those profiles that it is willing to act as > listener? What's the intended use for those profile elements in a > message? the greeting "advertises profiles that it supports". the specification does not define what "supports" means. some might say that was on purpose... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Mar 18 03:57:10 2004 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 DAA28012 for ; Thu, 18 Mar 2004 03:57:09 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2I8h4FV005284; Thu, 18 Mar 2004 00:43:05 -0800 (PST) Received: from mail.hq.adiscon.com (mail.hq.adiscon.com [217.6.190.188]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2I8YuFV005224 for ; Thu, 18 Mar 2004 00:34:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 813F99C61A; Thu, 18 Mar 2004 09:37:03 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05098-07; Thu, 18 Mar 2004 09:36:20 +0100 (CET) Received: from grfext.intern.adiscon.com (unknown [192.168.0.2]) by mail.hq.adiscon.com (Postfix) with SMTP id 449149C4C0; Thu, 18 Mar 2004 09:36:20 +0100 (CET) Received: from 172.19.0.5 by grfext.intern.adiscon.com (InterScan E-Mail VirusWall NT); Thu, 18 Mar 2004 09:33:57 +0100 Subject: RE: [BEEPwg] contained within MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <28915501A44DBA4587FE1019D675F9831AE5C0@grfint> Thread-Topic: [BEEPwg] contained within Thread-Index: AcQMhij4x0E8ITcwQqaho6ugC8NqPgAPO5+w From: "Rainer Gerhards" To: "Lei Zhang" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id i2I8YuFV005224 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Mar 2004 09:33:57 +0100 Content-Transfer-Encoding: 8bit > > A simple question that I cannot find answer from RFC 3080: should a > > message contain _all_ profiles the BEEP peer > supports, or > > should it contain only those profiles that it is willing to act as > > listener? What's the intended use for those profile elements in a > > message? > > the greeting "advertises profiles that it supports". the specification > does not define what "supports" means. some might say that was on > purpose... In my implementation, I advertise only those profiles that I am ready to accept. And if I am a client peer, I expect that I can call up any profiles that the server peer advertises. Everything else sounds illogical to me. Just theoretical: a listener - in my point of view - may also temporarily NOT advertise some profiles if it *temporarily* is unable to process them (e.g. a needed ressources for one profile is offline while the other profiles can be handled). So I think is of highly dynamic nature - and the listener should only avertise those profiles that it actually *expects* to be able to accept (of course, this assumption may turn out to be false at any time later so the listener may still need to "ERR" on a requested profile (e.g. while a necessary ressources goes just at this moment offline) - but I think this is as always in IT (and life) - expect unexpected things to happen ;) HTH Rainer _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Mar 25 03:20:56 2004 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 DAA08531 for ; Thu, 25 Mar 2004 03:20:55 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2P87AFx024568; Thu, 25 Mar 2004 00:07:11 -0800 (PST) Received: from wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2P830Fx024527 for ; Thu, 25 Mar 2004 00:03:00 -0800 (PST) Received: from [208.177.152.18] (helo=[10.0.1.7]) by wetware.com with esmtp (Exim 4.20) id 1B6Pp4-0002SJ-HQ for beepwg@lists.beepcore.org; Thu, 25 Mar 2004 00:02:42 -0800 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <28915501A44DBA4587FE1019D675F9831AE5C0@grfint> References: <28915501A44DBA4587FE1019D675F9831AE5C0@grfint> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEEPwg] contained within To: BEEP WG X-Mailer: Apple Mail (2.613) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Mar 2004 00:02:41 -0800 Content-Transfer-Encoding: 7bit On 18 Mar 2004, at 00:33, Rainer Gerhards wrote: > > In my implementation, I advertise only those profiles that I am ready > to > accept. And if I am a client peer, I expect that I can call up any > profiles that the server peer advertises. Everything else sounds > illogical to me. My implementation regards the list of profiles in the message as 'advisorial' in nature. I predict that some applications will want the ability for the listener to obscure its capability to support a profile by opting not to advertise it in the initial message. (I can envision ways this could be used to slow down hostile server probes from discovering servers with specific applications simply by making the probers do a lot more work to discover their targets.) It's also the case that a BEEP endpoint must cope if a profile advertised in a received message turns out to not be supported by the peer, i.e. attempts to start channels with that profile produce an with code 550. In other words, it's no guarantee that a remote peer does not support a given profile if it doesn't appear in the greeting, and it's also no guarantee that a remote peer does support a given profile if it *does* appear in the greeting. The only way you know if the peer supports a profile at the time you want to start a channel for it is if the peer responds to a message with a response. The only reasonable things a BEEP endpoint can do with the list of profiles in a message: 1) [in the event it has not yet sent an initial exchange entity] make its decision about whether to send its own or an ; or 2) [in any event] make its decision about which profiles to use in attempting to start which channels in what order of priority. -- j h woodyatt don't take any wooden root certs... _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Mar 25 04:28:23 2004 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 EAA10787 for ; Thu, 25 Mar 2004 04:28:23 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2P9H5Fx025173; Thu, 25 Mar 2004 01:17:05 -0800 (PST) Received: from mail.hq.adiscon.com (mail.hq.adiscon.com [217.6.190.188]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2P96SFx025092 for ; Thu, 25 Mar 2004 01:06:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id E4E0D9C699; Thu, 25 Mar 2004 10:09:18 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17554-07; Thu, 25 Mar 2004 10:08:40 +0100 (CET) Received: from grfext.intern.adiscon.com (unknown [192.168.0.2]) by mail.hq.adiscon.com (Postfix) with SMTP id 97F009C696; Thu, 25 Mar 2004 10:08:40 +0100 (CET) Received: from 172.19.0.5 by grfext.intern.adiscon.com (InterScan E-Mail VirusWall NT); Thu, 25 Mar 2004 10:05:40 +0100 Subject: RE: [BEEPwg] contained within MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <28915501A44DBA4587FE1019D675F9831AE6A3@grfint> Thread-Topic: [BEEPwg] contained within Thread-Index: AcQSROT14PmkSWY0Rqqu7ko8s8SywQAAqSJg From: "Rainer Gerhards" To: "james woodyatt" , "BEEP WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id i2P96SFx025092 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Mar 2004 10:05:40 +0100 Content-Transfer-Encoding: 8bit > In other words, it's no guarantee that a remote peer does not > support a > given profile if it doesn't appear in the greeting, mmmhhh... is this really in the spirit of BEEP? I doubt... My implementation does NOT request profiles which are NOT advertised and I think it is not a good idea to do so. > and it's also no > guarantee that a remote peer does support a given profile if > it *does* > appear in the greeting. This sounds reasonable - the profile may also simply have gone offline for some tech reason. > The only way you know if the peer supports a > profile at the time you want to start a channel for it is if the peer > responds to a message with a response. So why have the greeting at all? Honestly, if would I agree to your points, I would conclude that the greeting is a comment. So why shuffle that comment along the wire if there is no need for it? At least it should become an optional argument. I am also sceptic about this as a "security measure". Agree, it would make probing a little more time intense, but I could request the profiles anyhow. So I don't see this adds much. Wouldn't it be more appropriate to use the tuning profiles and allow only trusted connections in this case ;) Rainer _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Mar 25 13:13:05 2004 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 NAA12182 for ; Thu, 25 Mar 2004 13:13:05 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2PHv5Fx001461; Thu, 25 Mar 2004 09:57:05 -0800 (PST) Received: from wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i2PHkbFx001370 for ; Thu, 25 Mar 2004 09:46:38 -0800 (PST) Received: from [208.177.152.18] (helo=[10.0.1.7]) by wetware.com with esmtp (Exim 4.20) id 1B6Yw4-0002lL-IC for beepwg@lists.beepcore.org; Thu, 25 Mar 2004 09:46:32 -0800 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <28915501A44DBA4587FE1019D675F9831AE6A3@grfint> References: <28915501A44DBA4587FE1019D675F9831AE6A3@grfint> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5A659C76-7E84-11D8-AA55-000A958FF2FE@wetware.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEEPwg] contained within To: BEEP WG X-Mailer: Apple Mail (2.613) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Mar 2004 09:46:32 -0800 Content-Transfer-Encoding: 7bit On 25 Mar 2004, at 01:05, Rainer Gerhards wrote: > > mmmhhh... is this really in the spirit of BEEP? I doubt... My > implementation does NOT request profiles which are NOT advertised and I > think it is not a good idea to do so. I think your implementation is being more conservative in what it sends than what the specification requires. Nothing *really* wrong with that, but from what I know about the "spirit of BEEP" I'm not sure I would agree with you about whether it's a good idea. The designers of the protocol have been known to apply qualifications to the conventional wisdom that a protocol implementation should be liberal in what it accepts and conservative in what it sends. Specifically, I've seen at least one of them warn about the dangers of being too liberal and too conservative, respectively. >> The only way you know if the peer supports a >> profile at the time you want to start a channel for it is if the peer >> responds to a message with a response. > > So why have the greeting at all? Honestly, if would I agree to your > points, I would conclude that the greeting is a comment. So why shuffle > that comment along the wire if there is no need for it? At least it > should become an optional argument. Here's why: suppose you have a application protocol in which a client starts a set of channels with a specific profile after tuning the session for an authentication layer. The first greeting message from the server should contain a list of profiles for SASL mechanisms. It might be a matter of policy at the server which authentication mechanisms are required for clients, and this policy might vary from server to server. Therefore, a client needs the greeting message to know which authentication mechanisms the server claims to support. > I am also sceptic about this as a "security measure". Agree, it would > make probing a little more time intense, but I could request the > profiles anyhow. So I don't see this adds much. Wouldn't it be more > appropriate to use the tuning profiles and allow only trusted > connections in this case ;) It's not a "security" measure. It's only camouflage. And I agree, it doesn't add much security. Doesn't mean people won't want to do it. Here's another thing to keep in mind: a BEEP endpoint may start a new session by sending a message after a previous session is released by a message. It's not just after a tuning reset when an endpoint can send another . Why in the world would you want to do this? Again, probably only when you're trying to camouflage a server. What kind of lunatics wear camouflage in public? I couldn't say. They're not normal people, that's for sure. -- j h woodyatt that's my village calling... no doubt, they want their idiot back. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg