Subject: RE: [BEEPwg] <profile> contained within <greeting>

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 25 Mar 2004 10:05:40 +0100

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

Rainer

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: james woodyatt <[email-masked]>
Date: Thu, 25 Mar 2004 09:46:32 -0800

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

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

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