Agreed. However, is it possible to encase all attributes to the authenticate/login commands as per XML?
Ex: b authenticate plain (SASLIR AGFybnQAdG5yYQ==) (SID 1234432143) This way it is permanently extensible? Corby > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of ext Ken Murchison > Sent: Thursday, July 15, 2004 1:46 PM > To: Alexey Melnikov > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Arnt Gulbrandsen > Subject: Re: [lemonade] Re: RECONNECT and SASL-IR aren't friends > > 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 > > _______________________________________________ > lemonade mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/lemonade
