Lei Zhang | 17 Mar 18:52 2004
Picon

<profile> contained within <greeting>

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..
Marshall Rose | 18 Mar 01:43 2004
Picon
Picon

Re: <profile> contained within <greeting>

> 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
Rainer Gerhards | 18 Mar 09:33 2004

RE: <profile> contained within <greeting>


> > 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)

james woodyatt | 25 Mar 09:02 2004

Re: <profile> contained within <greeting>

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)

Rainer Gerhards | 25 Mar 10:05 2004

RE: <profile> contained within <greeting>

> 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)

james woodyatt | 25 Mar 18:46 2004

Re: <profile> contained within <greeting>

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)


Gmane