How about stepping back and focusing on what you want.
Michael Wener writes:
Consider carefully what state-carryover would imply to a client that
is not aware of the state in any other session. The client couldn't
use any data that it got, because it could be invalidated, without
notice, by some
Stuart Nicholson writes:
However RFC 2195 makes no mention of what should be done when userid
contains whitespace. The obvious solution is to quote the userid but
is this standard practice? What's the recommended solution?
The digest cannot contain a space, so a server should look for the last
s
On Tue, 2004-09-28 at 22:00, Barry Leiba wrote:
> > Why is this a better question? I consider one of the goals of
> > specification to be reduced ambiguity. I would think that if there was
> > expected behavior then it would be better to be written down?
>
> Hm. So, let's see:
> You'd expect to b
On Tue, 2004-09-28 at 23:43, Mark Crispin wrote:
> On Tue, 28 Sep 2004, Michael Wener wrote:
> >> It's not concensus; it's the specification.
> > Where?
>
...
> This is a good rule of thumb to keep in mind when considering any
> protocol: when it seems that a protocol has senseless rules and nume
Michael Wener <[EMAIL PROTECTED]> writes:
>On Tue, 2004-09-28 at 23:43, Mark Crispin wrote:
>> On Tue, 28 Sep 2004, Michael Wener wrote:
...
>> UID 1232 tells you two things. First:
>> . if the message exists in the other session
>> *and*
>> . if the UIDVALIDITY of the mailbox is the same in b
> Note, I'm not arguing SNs should be session state. I'm convinced they
> are not.
I misspoke. I'm convinced that SNs should not be shared between
sessions.
Mike
Michael Wener <[EMAIL PROTECTED]> wrote:
> My consideration at the moment is only coordinated sessions. Sessions
> that are aware of each others logic and are behaving in concert.
The server has no way of knowing whether two sessions are coordinated
on the client side. It has to treat each sessio
On Wed, 2004-09-29 at 09:42, Philip Guenther wrote:
> Michael Wener <[EMAIL PROTECTED]> writes:
...
> Note that you still have to wait until the server tells you the
> message exists. Until then it is completely free to say "no such
> message".
>
>
> ...
> >How this is not shared state between s
Michael Wener <[EMAIL PROTECTED]> wrote:
> Is it fair to say that once a UID is visible within a session it is
> shared state?
The UID has the same meaning for all sessions that have the same
UIDVALIDITY and that have been notified about the message. The same
is *not* true for message sequence nu
On Wed, 2004-09-29 at 10:30, Paul Jarc wrote:
> Michael Wener <[EMAIL PROTECTED]> wrote:
> > My consideration at the moment is only coordinated sessions. Sessions
> > that are aware of each others logic and are behaving in concert.
>
> The server has no way of knowing whether two sessions are coor
Michael Wener writes:
Is it fair to say that once a UID is visible within a session it is
shared state?
Yes. It's shared with all other sessions that have the same uidvalidity
and mailbox, and in which that UID is visible.
My goal and intent at the moment is to understand the concept of a
sessi
Michael Wener <[EMAIL PROTECTED]> wrote:
> Does the server keep a per-session mapping between messages and
> UIDs?
No, that mapping is per-UIDVALIDITY. UIDVALIDITY typically does not
change very often, although the server is allowed to change it at any
time.
paul
On 09/29/2004 04:34:05 PM, Michael Wener wrote:
On Wed, 2004-09-29 at 09:42, Philip Guenther wrote:
> Michael Wener <[EMAIL PROTECTED]> writes:
> to do something that turns out to be a step away from the ultimate
> goal is frustrating to all involved. There's a good chance that
I'm not frustrated
Mark Crispin wrote:
It looks to me that you can not use CRAM-MD5 authentication if you
allow user names with a space.
This is addressed in draft-ietf-sasl-crammd5: when extracting digest the
server should look for the rightmost space. Everything to the left is a
username.
So, spaces are allowed
On 29 Sep 2004, Michael Wener wrote:
:
: My goal and intent at the moment is to understand the concept of a
: session within IMAP.
The best explanation I've ever heard on this list is to think of the
mailstore as a "world" or "environment" and the server is describing the
world to the client ses
I wrote:
> UIDVALIDITY typically does not change very often, although the
> server is allowed to change it at any time.
More precisely, it can't change during a session, but two different
sessions can get different UIDVALIDITY values, no matter how close
together they are.
paul
Ah, but sequence numbers ARE a session characteristic. They can only be
considered to be valid in the context of a single session.
That's why there are so many "silly" rules about when you can change the
session numbers and the consequences of that. Consider the EXISTS and
EXPUNGE responses for e
On Wed, 29 Sep 2004, Larry Osterman wrote:
UIDs are cross session, IF (and only IF) the UIDVALIDITY is unchanged.
And there ARE existing, compliant servers which will give a different
UIDVALIDITY for every session (if the underlying message store is
incapable of implementing UIDs).
However, this "c
Absolutely right, that's a subtlety I missed in my response. In
particular, just because you have two sessions with the same UIDVALIDITY
doesn't mean that you can use a UID from session 1 in session 2 - if you
haven't seen the EXISTS response for that message, it doesn't exist.
This is actually R
I’m implementing an IMAP server and I’m a bit confused
about this sentence found in rfc 3501 6.3.8 (LIST command).
page 42, 3rd paragraph from bottom, 3rd sentence
states:
If the "%" wildcard is the
last character of a mailbox name argument, matching levels of hierarchy are
als
20 matches
Mail list logo
