Rob Siemborski writes:
On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote:
(I'll be happy with either, though. And I wish people would mention
it on the list when they freeze a draft by releasing code widely.)
...
The problem is often times the only way to fully vet a draft is to
implement and actually us
On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote:
While it might be slightly cleaner, both UW and Cyrus both already
implement the original AUTHENTICATE syntax.
In released versions or just internally?
Released versions for UW.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from vot
> On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote:
>
>> (I'll be happy with either, though. And I wish people would mention it
>> on the list when they freeze a draft by releasing code widely.)
>
> (oh -- Squirrelmail [and I presume pine] have also deployed this on the
> client side).
>
Regarding
>
> Well, I suppose the releases effectively Last Called SASL-IR, then. In
> that case, I like Alexey's proposal better than Corby's:
>
> b authenticate (SID 1234432143) plain AGFybnQAdG5yYQ==
>
> (I'll be happy with either, though. And I wish people would mention it
> on the list when they free
Rob Siemborski wrote:
In released versions or just internally?
If in released versions, I suggest a Last Call for the SASL-IR draft
right now.
Released versions in both cases. I was hoping to wait until the new
SASL draft was last called, in order to deal with any last minute
modifications that
On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote:
(I'll be happy with either, though. And I wish people would mention it on the
list when they freeze a draft by releasing code widely.)
(oh -- Squirrelmail [and I presume pine] have also deployed this on the
client side).
The problem is often times the
Well, I suppose the releases effectively Last Called SASL-IR, then. In
that case, I like Alexey's proposal better than Corby's:
b authenticate (SID 1234432143) plain AGFybnQAdG5yYQ==
(I'll be happy with either, though. And I wish people would mention it
on the list when they freeze a draft by re
[EMAIL PROTECTED] wrote:
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?
This would be possible, however as Rob pointed out there is al
On Fri, 16 Jul 2004, Alexey Melnikov wrote:
Atleast Arnt proposed this syntax:
That was Corby, I think.
Whoops, my mistake
b authenticate login (SASLIR dGVzdDg=) (SID 1234567890), which would be
incompatible.
The client is not going to use it unless the server supports it.
Well, of course, but
On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote:
Rob Siemborski writes:
While it might be slightly cleaner, both UW and Cyrus both already
implement the original AUTHENTICATE syntax.
In released versions or just internally?
If in released versions, I suggest a Last Call for the SASL-IR draft right
no
Rob Siemborski wrote:
On Fri, 16 Jul 2004, Alexey Melnikov wrote:
The alternative proposal is to use () only to pass additional
parameters:
b authenticate (SID 1234432143) plain AGFybnQAdG5yYQ==
Atleast Arnt proposed this syntax:
That was Corby, I think.
b authenticate login (SASLIR dGVzdDg=) (
On Fri, 16 Jul 2004, Alexey Melnikov wrote:
The alternative proposal is to use () only to pass additional parameters:
b authenticate (SID 1234432143) plain AGFybnQAdG5yYQ==
Atleast Arnt proposed this syntax:
b authenticate login (SASLIR dGVzdDg=) (SID 1234567890), which would be
incompatible.
The
Rob Siemborski writes:
While it might be slightly cleaner, both UW and Cyrus both already
implement the original AUTHENTICATE syntax.
In released versions or just internally?
If in released versions, I suggest a Last Call for the SASL-IR draft right now.
Arnt
Rob Siemborski wrote:
On Thu, 15 Jul 2004, Alexey Melnikov wrote:
An alternative would be to put AUTHENTICATE options in () before the
SASL mechanism name.
While it might be slightly cleaner, both UW and Cyrus both already
implement the original AUTHENTICATE syntax.
The alternative proposal is t
On Thu, 15 Jul 2004, Alexey Melnikov wrote:
An alternative would be to put AUTHENTICATE options in () before the SASL
mechanism name.
While it might be slightly cleaner, both UW and Cyrus both already
implement the original AUTHENTICATE syntax.
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ken Murchison wrote:
Alexey Melnikov wrote:
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.
Alexey Melnikov writes:
Arnt Gulbrandsen wrote:
(in this case, no persistent session is created.)
This works as you suggest as described in the current version of the draft.
Oh, I see. I misunderstood first time I read the draft. Still think the
paren is insufficient, and anyway, what should a cli
[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:
>
>
On Thu, 15 Jul 2004, Alexey Melnikov 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 c
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
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 t
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 f
Hi,
draft-ietf-lemonade-reconnect and
draft-siemborski-imap-sasl-initial-response conflict, because they
extend AUTHENTICATE in the same way.
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 useles
23 matches
Mail list logo
