Re: [Beepcore-java-users] Requireing a profile

[William J. M. <wm...@ol...>]

Well, one of the major issues here is that once you start saying profile-X 
depends on SASL which shade of SASL?  All of them?  The "simple dependency
scheme" does not really end up simple I think.  

Also consider that you may not want to advertise all profiles before authentication
or encryption has been completed.

A note on tuning profiles, SASL is a tuning profile that affects the session
state, but does not issue a tuning reset.

The design decision we made was to leave this kind of thing out, because it can
be implemented in the profiles, there did not appear to be a general solution,
and perhaps the greatest consideration was that it adds a lot of complexity to the
wrapper.

Not to say that another wrapper could not be implemented with this kind of thing
added.  That's one of the reasons that we broke the code up the way we did.  Core
and utilities are separate.  The transport stuff can be utilized easily by another 
wrapper.

For the 3 profiles you talk about, only advertise TLS initially, after the tuning 
reset, advertise SASL and ECHO.  The only profile that need be custom is ECHO.
ECHO is not the greatest example here, but it will serve fine as a straw man.

-bill

On Mon, Aug 05, 2002 at 09:05:34PM -0700, Kevin Kress wrote:
> This seems like a bit overkill to me.  If you think about tuing profiles
> as a layer below the application profiles then a profile should have no
> knowledge of the tuing profile that is operating under it.
> 
> Shouldn't it be the responsibilty of the core API to establish a chain
> of dependancies that can be setup when the server session listener (in
> this can TCPSessionCreator) is created?
> 
> If a simple dependancy scheme is implemented that would mean that all
> supported profiles could be advertised upon the first greeting and
> return error codes when start requests are attempted without proper
> authentication or security in place.
> 
> 
> For example:
> 
> 3 profiles exist in parallel, Echo, TLS and SASL/OTP
> 
> Echo profile requires that SASL/OTP be in place.
> 
> SASL/OTP requires TLS
> 
> in this case you would need custom protocols for each profile to
> properly handle this situation.  
> 
> thoughts?
> 
> --Kevin Kress
> 
> On Sun, 2002-08-04 at 19:44, William J. Mills wrote:
> > I think this is a case where the profiles need to do the right thing, rather than
> > the core functionality.  I may be wrong.  
> > 
> > SASL sets a state in the session, but to some extent it is the profiles which
> > must honor this.  Tuning profiles which casue a new greeting to be exchanged
> > give the opportunity to register new profiles, and advertise them at that time,
> > which would do what you want, but SASL/ANONYMOUS does not cause a tuning reset 
> > in this way (as far as I know).
> > 
> > So for the ECHO example, you'd need a custom version that checks authentication 
> > in it's start message handler.
> > 
> > Someone please correct me if I am mistaken.
> > 
> > -bill
> > 
> > On Sun, Aug 04, 2002 at 05:20:46PM -0700, Kevin Kress wrote:
> > > In the SASL profile (or possibly a TLS) what is the mechanism used to
> > > send out "530" errors if the server wants to require authentication. 
> > > 
> > > For example, when a server starts up, it registers both, SASL/ANONYMOUS
> > > and ECHO... the desired result being that until the SASL/ANONYMOUS has
> > > set credentials in the Session, all other startChannel messages (in this
> > > case ECHO) will return with a <error code='530'> . 
> > > 
> > > If this is not done yet, where might it fit best?  A function of Session
> > > for the error sending?  Possibly ProfileRegistry for initial setup or
> > > TCPSessionCreator to setup the required auth?
> > > 
> > > thoughts? 
> > > 
> > > --Kevin Kress 
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Beepcore-java-users mailing list
> > > Bee...@li...
> > > https://lists.sourceforge.net/lists/listinfo/beepcore-java-users
> > 
> -- 
> Kevin Kress
> kk...@my...
> 
> GnuPG Key ID: 92949032
> Fingerprint : B7F9 2B08 6FC8 35CA 5B64  BD34 6A8B 325C 9294 9032
> 
> See Keyserver: http://www.keyserver.net/en/findkey.html
> (search for "Kevin Kress" or "0x92949032")
> 
> Get GnuPG or PGP at http://www.pgpi.org