Re: <profile> contained within <greeting>
james woodyatt <jhw <at> wetware.com>
2004-03-25 17:46:32 GMT
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