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 
profiles in a <greeting> message: 1) [in the event it has not yet sent 
an initial exchange entity] make its decision about whether to send its 
own <greeting> or an <error>; or 2) [in any event] make its decision 
about which profiles to use in attempting to start which channels in 
what order of priority.


-- 
j h woodyatt <[email protected]>
don't take any wooden root certs...