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 session to another.
> > Where in the RFCs is this stated or implied?
> 
> The better question is: where in the RFCs does it state or imply that you 
> can carry over state from one session to another?
> 

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?

> 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 
> other client.

My consideration at the moment is only coordinated sessions. Sessions
that are aware of each others logic and are behaving in concert.

> 
> IMAP goes to great efforts to guarantee each session precise state, and to 
> synchronize state changes precisely.  This can not happen if there is 
> carryover between sessions.

I'm still not sure what session state we are talking about. Obviously
sequence numbers. Is there anything else in this category?

> 
> > Also, obviously some state is carried over as stated in 2.3.1.1.
> 
> Actually, that is not the case.
> 
> Note in the second paragraph in 2.3.1.1 about the UIDVALIDITY.  A 
> compliant server could issue different UIDVALIDITY values in different 
> sessions and have nothing in common between the two.
> 
> The only thing that UIDs do is allow you to refer to the same message 
> between sessions.  They do not, in any way, guarantee that that message 
> actually exists.

If they allow you to refer to the same message between sessions how is
this not state being carried over from one session to another? I realize
that the server has the option to invalidate the state between sessions,
but by your own statement this is intended to be the exception.

> 
> Once again, why do you have multiple simultaneous sessions to the same 
> mailbox from the same client?  I think that you may have a more 

This is a good question, but before we diverge the discussion I would
like to fully understand the base behavior.


> fundamental misunderstanding about IMAP, and I'd like to clear that up.

Thank You. I may.

Mike


Reply via email to