Alexey Melnikov wrote:
Arnt Gulbrandsen wrote:
Hi,
draft-ietf-lemonade-reconnect and draft-siemborski-imap-sasl-initial-response conflict, because they extend AUTHENTICATE in the same way.
We've already marked this as an open issue in the reconnect draft.
I've suspected, but I didn't have time to check. This will be fix in the next revision.
My preferred way of resolving this would be to make sessions more explicit in the RECONNECT draft, which would also avoid loading the server with useless persistent sessions. That is, a RECONNECT-supporting client would send SESSION NEW to get a new session or SESSION <id> to resume a session.
Without sessions in client and server:
a capability b login arnt trna c select inbox
(in this case, no persistent session is created.)
This works as you suggest as described in the current version of the draft.
With sessions in the client and server:
a capability b login arnt tnra c session 1234432143
(in this case, a persistent session is used, of if that number isn't valid, created.)
For the latter case the current syntax is b login arnt tnra (SID 1234432143)
which will do exactly what you are asking for. Extending LOGIN also saves a round trip.
This *could* still work with SASL-IR because AFAIR '(' isn't a valid base64 character. The parser could just check the first character of third argument to see if its '(' and proceed accordingly. We already have to do this for LISTEXT to detemine if we're using LISTEXT syntax or LIST syntax. So check handling both
b authenticate plain (SID 1234432143)
and
b authenticate plain AGFybnQAdG5yYQ== (SID 1234432143)
shouldn't be too difficult.
-- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
