Hi, A simple question that I cannot find answer from RFC 3080: should a <greeting> 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 <greeting> message? Thanks..
> A simple question that I cannot find answer from RFC 3080: should a > <greeting> 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 > <greeting> message? the greeting "advertises profiles that it supports". the specification does not define what "supports" means. some might say that was on purpose... /mtr
> > A simple question that I cannot find answer from RFC 3080: should a > > <greeting> 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 > > <greeting> 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 <greeting> 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(Continue reading)
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 <greeting> 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 <greeting> 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 <greeting> message turns out to not be supported by the peer, i.e. attempts to start channels with that profile produce an <error> 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 <start> message with a <profile> response. The only reasonable things a BEEP endpoint can do with the list of(Continue reading)
> 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 <start> message with a <profile> 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 ;)(Continue reading)
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 <start> message with a <profile> 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(Continue reading)
RSS Feed2 | |
|---|---|
1 | |
1 | |
1 | |
3 | |
2 | |
2 | |
1 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
12 | |
1 | |
4 | |
24 | |
2 | |
1 | |
2 | |
5 | |
2 | |
1 | |
1 | |
7 | |
1 | |
1 | |
2 | |
4 | |
1 | |
1 | |
1 | |
1 | |
2 | |
2 | |
1 | |
4 | |
2 | |
3 | |
1 | |
4 | |
8 | |
4 | |
13 | |
15 | |
3 | |
1 | |
2 | |
1 | |
12 | |
2 | |
10 | |
6 | |
8 | |
3 | |
1 | |
4 | |
15 | |
6 | |
10 | |
5 | |
3 | |
2 | |
1 | |
6 | |
3 | |
16 | |
35 | |
29 | |
27 | |
2 | |
5 |
