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

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 18 Mar 2004 09:33:57 +0100

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

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

---

From: james woodyatt <[email-masked]>
Date: Thu, 25 Mar 2004 00:02:41 -0800

> profiles that the server peer advertises. Everything else sounds

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-masked]>
don't take any wooden root certs...