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 
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 <greeting> message after a previous session is 
released by a <close> message.  It's not just after a tuning reset when 
an endpoint can send another <greeting>.

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 <[email protected]>
that's my village calling... no doubt, they want their idiot back.