StevenJ <sjohn...@sakuraindustries.com> added the comment:
Hi Julien,
>> I also don't understand why START_TLS and AUTHINFO need to change
>> how the module is interfaced to (separating log in/authentication, etc)
> Because once you have used AUTHINFO, STARTTLS is no longer a valid
> command in a session.
I understand this, but doesn't this mean the init function needs to change to
something like:
init:
if capability STARTTLS is advertised
STARTLS stuff
reget capabilities because STARTTLS changed them probably
Now handle AUTHINFO Stuff
Is there a case where a server advertises STARTTLS and one would not use it?
If so then couldn't that just be handled with an option to the class inhibiting
it?
This is one of the reasons why I proposed dividing the job across two features.
1. Simple NNTPS which seems to be the most common secured NNTP in use at the
moment and is easy to implement, and verify (either as an improvement to the
NNTP class or as a new NNTP_SSL class).
2. SASL AUTHINFO/STARTTLS Extension handling implementation and improvements.
There are also other bugs with properly handling capabilities at start related
to this, are there not? http://bugs.python.org/issue10287
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
