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

[Kevin K. <kk...@my...>]

Resend.... Reply-to was wrong... OOPS.

see comments below....

--Kevin
-------

On Tue, 2002-08-06 at 12:38, Marshall Rose wrote:
> > A note on tuning profiles, SASL is a tuning profile that affects the
> session
> > state, but does not issue a tuning reset.
> 
> actually, this is not true. if a security layer is negotiated as a part of
> the SASL process, then a tuning reset will occur.
> 
> 
> > 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.
> 
> in the C and Tcl implementations, each data exchange profile is responsible
> for determining whether the tuning is to its liking or not.
> 
> in the Java implementation, one could (as bill points out), have a subclass
> of Profile that does the checking for you, so that the profile itself
> doesn't have to check. seems like a fairly straight-forward abstraction to
> put together.
> 
> however, at the present time, beepcore-java doesn't have that abstraction.
> 
> /mtr
> 

All,

I just wanted to point out that I am a newcomer to beep, and I am coming
to this after reading the RFC only 2 or 3 times, so I want to admit up
front I could be completely off base, but I figured I may as well try to
explore the idea.  Also if I am just rehashing something that has
already been discussed please let me know.

Throwing the responsibility of check dependencies to the parent class of
the TuningProfile is more along the lines of what I had in mind, but let
me put up and example that is a little more along the lines of what I
had in mind. 

This not in any way a real world example, but something I have come up
with to further discussion.  

for this example there exists 5 profiles (full URI's removed for
brevity)

- TLS
- SASL/ANONYMOUS
- SASL/OTP
- SASL/OTHER (one that negotiates both authentication and a security
layer)
- Some Application profile, lets say SMTP.


Now consider the following situations all implemented in different
software processes:

case 1:
SMTP requires SASL/OTP
SASL/OTP requires TLS

case 2:
SMTP requires SASL/ANONYMOUS

case 3:
SMTP requires SASL/OTHER

case 4:
SMTP requires nothing.

In each of these cases SMTP works exactly the same once the channel is
started, ie no change in functionality.  What I am proposing is that the
core functionality be written so that it can be aware of these different
dependencies and handle them, so the application writer does not have to
worry about them at a profile level, only at the session level.

Now in the case where the profile is aware of the authentication layers
that are sitting above it, the SMTP Profile (or its parent class) has to
check to see what encryption/authentication schemes are in place and
compare those to what it knows about.  This would require the session to
call to he profile and then the profile to veto the start channel until
proper authentication is in place.  

If this were setup at the session layer, the profile would be blissfully
unaware of what is running underneath it (unless that info is
specifically requested form the session).  It would be the job of the
session to determine whether a profile has enough
authentication/encryption/etc in place.  How would it determine this? 
The ProfileRegistry could be augmented to contain a dependency scheme. 
This could allow for both tuning and application profile dependencies. 
Say for a certain application you want to combine Echo profile with SMTP
(don't ask me why just an example), but that you do not want Echo to be
able to start unless a SMTP channel is already open.  Using dependencies
you could have attempts to start Echo fail until SMTP is up.

Here is where my ignorance of the details of BEEP comes in, are these
idea valid within the bounds of the specification.  From what I
understand for case 1 TLS should be the only protocol for the initial
greeting and SALS/OTP and SMTP come after that, but is it also legal to
advertise all 3 up front and have start requests to SASL/OTP and SMTP
error out?  Also if that is that is the case then should SMTP be
returning errorcode 530's before OTP is complete?  Should OTP be
throwing out errorCodes if TLS has not been started (534? 538? 550?)

Thanks for any comments.

--Kevin Kress