You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2005/10/14 05:38:41 UTC

[mina] TLS protocol closure and MINA versioning strategy.

Hi,

Now we are able to implement StartTLS, but what about TLS closure (reverting
back to non-encrypted mode)?

I've found that MINA filters cannot filter session close requests so that
SSLFilter send close_notify. We also don't have any way to notify the
removal of SSLFilter from session-scope filter chain to SSLFilter itself so
that it can send close_notify to revert back to non-encrypted mode without
closing the connection in MINA 0.7. Fortunately we've got filterAdded and
filterRemoved in trunk (0.9 stream).

I think porting back these features and adding filterClose() to filters in
0.7 stream just increases my maintenance overhead. I'd like to change
current linux-like versioning scheme of MINA to just plain one; to release
current branch as 0.7.5 and trunk as 0.8 soon with full StartTLS and TLS
closure support. I don't see any good reason to retain current versioning
scheme in current situation.

WDYT?

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: [mina] TLS protocol closure and MINA versioning strategy.

Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:

> 2005/10/15, Alex Karasulu <aok123@bellsouth.net 
> <ma...@bellsouth.net>>:
>
>     -1 this was decided a while back ... maintain consistency for now.
>
>
> Yes, we've talked over IM after I had sent this message.  I realized I 
> don't need to change our versioning scheme at all while talking with 
> you.  We'll release 0.8 and 0.9 this month. 

Ooops sorry about that T: it's my bad!

> ApacheDS 0.9.5 will include StartTLS support based on MINA 0.8.  But 
> we won't be able to implement TLS closure (reverting back to 
> non-encrypted connection without disconnection) with MINA 0.8.  We'll 
> have to migrate to MINA 0.9 after we release MINA 0.9 which will 
> support TLS closure.

Yah that sounds like a good idea let's just make ApacheDS 0.9.5 depend 
on MINA 0.9 then.  Perhaps we should focus on a MINA 1.0 to do the 
ApacheDS 1.0 release or does this matter?

Alex

Re: [mina] TLS protocol closure and MINA versioning strategy.

Posted by Trustin Lee <tr...@gmail.com>.
2005/10/15, Alex Karasulu <ao...@bellsouth.net>:
>
> -1 this was decided a while back ... maintain consistency for now.


Yes, we've talked over IM after I had sent this message. I realized I don't
need to change our versioning scheme at all while talking with you. We'll
release 0.8 and 0.9 this month. ApacheDS 0.9.5 will include StartTLS support
based on MINA 0.8. But we won't be able to implement TLS closure (reverting
back to non-encrypted connection without disconnection) with MINA 0.8. We'll
have to migrate to MINA 0.9 after we release MINA 0.9 which will support TLS
closure.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: [mina] TLS protocol closure and MINA versioning strategy.

Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:

> Hi,
>
> Now we are able to implement StartTLS, but what about TLS closure 
> (reverting back to non-encrypted mode)?
>
> I've found that MINA filters cannot filter session close requests so 
> that SSLFilter send close_notify.  We also don't have any way to 
> notify the removal of SSLFilter from session-scope filter chain to 
> SSLFilter itself so that it can send close_notify to revert back to 
> non-encrypted mode without closing the connection in MINA 0.7.  
> Fortunately we've got filterAdded and filterRemoved in trunk (0.9 stream).
>
> I think porting back these features and adding filterClose() to 
> filters in 0.7 stream just increases my maintenance overhead.  I'd 
> like to change current linux-like versioning scheme of MINA to just 
> plain one; to release current branch as 0.7.5 and trunk as 0.8 soon 
> with full StartTLS and TLS closure support.  I don't see any good 
> reason to retain current versioning scheme in current situation.
>
> WDYT?

-1 this was decided a while back ... maintain consistency for now.

Alex