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 be able
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 numerous
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 session
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 sessions I'm
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 coordinated
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
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.
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
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
(if the underlying message store is
incapable of implementing UIDs).
Larry Osterman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Michael Wener
Sent: Wednesday, September 29, 2004 5:27 AM
To: [EMAIL PROTECTED]
Subject: Re: FETCH Failure
On Tue, 2004-09-28 at 22:00
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
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Mark Crispin
Sent: Wednesday, September 29, 2004 12:34 PM
To: Larry Osterman
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: FETCH Failure
On Wed, 29 Sep 2004, Larry Osterman wrote:
UIDs are cross session
On Tue, 28 Sep 2004, Michael Wener wrote:
Session 2
Ah Ha, I see I have new mail
There's your problem. You were informed of new mail in session 1, and you
assumed that this information is valid in session 2. It isn't.
You can not carry over state from one session to another.
-- Mark --
Michael Wener wrote:
Session 1
1 IDLE
+ IDLE Accepted
Some time passes and then new mail arrives
* N EXISTS
* 1 RECENT
Session 2
Ah Ha, I see I have new mail
2 FETCH N BODYSTRUCTURE
* N EXISTS
* 1 RECENT
2 NO the specified message set is invalid
The line Ah Ha, I see I have new mail is incorrect.
On Tue, 2004-09-28 at 13:43, Timo Sirainen wrote:
On 28.9.2004, at 20:30, Michael Wener wrote:
Session 1
1 IDLE
+ IDLE Accepted
Some time passes and then new mail arrives
* N EXISTS
* 1 RECENT
Session 2
Ah Ha, I see I have new mail
2 FETCH N BODYSTRUCTURE
* N EXISTS
* 1
On Tue, 2004-09-28 at 13:48, Mark Crispin wrote:
On Tue, 28 Sep 2004, Michael Wener wrote:
Session 2
Ah Ha, I see I have new mail
There's your problem. You were informed of new mail in session 1, and you
assumed that this information is valid in session 2. It isn't.
Yes, this seems
On Tue, 28 Sep 2004, Michael Wener wrote:
The point here is that it *is* currently a valid sequence number. After
all the next FETCH confirms this.
No, it is not a valid sequence number, and it remains an invalid sequence
number until you receive an EXISTS response *in that session* that
On 28.9.2004, at 22:19, Michael Wener wrote:
This is clearly a client bug. There are no guarantees that multiple
sessions have compatible sequence numbers. Expunges especially may
make
the fetch return wrong message. At minimum the client should do UID
FETCH and do some fallback processing if it
On Tue, 2004-09-28 at 15:40, Mark Crispin wrote:
On Tue, 28 Sep 2004, Michael Wener wrote:
...
assumed that this information is valid in session 2. It isn't.
Yes, this seems to be the consensus.
It's not concensus; it's the specification.
Where?
You can not carry over state from one
On Tue, 28 Sep 2004, Michael Wener wrote:
Also incorrect. An untagged EXPUNGE can only be transmitted when a
command other than FETCH, STORE, and SEARCH is in progress. Until such a
command is in progress, the sequence remains valid even if the message was
expunged in another session.
Do you
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 be able to open two FTP sessions to the same server,
set the
On Tue, 28 Sep 2004, Barry Leiba wrote:
My consideration at the moment is only coordinated sessions. Sessions
that are aware of each others logic and are behaving in concert.
And do you know ANY Internet protocols where that happens?
This is actually a pretty good observation.
Internet protocols
On Tue, 28 Sep 2004, Michael Wener wrote:
It's not concensus; it's the specification.
Where?
The IMAP specification is filled with numerous rules having to do with
when updates (most notably, untagged EXPUNGE) can be sent (and are
required to be sent) all in the name of maintaining precise
25 matches
Mail list logo
