re: FETCH command behavior

[Larry Osterman <[e-mail]>]

That would certainly make me (and Mark Pustilnik who owns the canonicalization 
logic) very happy, because it means that we don't have to change what we're 
doing :)

Feelings on the part of the other interested parties?  If we have concensus, 
then Mark, can you take it as an editorial point to relax the wording (or 
explicitly put in wording to allow this) in the next revision of 2060?  I'd 
hate to decide that this was an ok thing too do and then have some client 
implementor decide that they CAN depend on this behavior....




On Tue, 26 Aug 1997 16:06:14 -0700 (PDT) Mark Crispin <[e-mail]> 
wrote:

> On Tue, 26 Aug 1997 15:57:38 -0700, Larry Osterman (Exchange) wrote:
> > The corollary of this statement is that a unique identifier OUTSIDE a
> > message set range SHOULD generate a message.  Thus the first example
> > will fail if any of the messages specified doesn't exist, while after
> > our canonicalization logic, the example would fail only if all of the
> > messages specified don't exist.
> 
> I consider that to be a rather extreme position.  I think that unknown UIDs
> should be just ignored, and if a UID sequence doesn't match any messages the
> command would then be a no-op.
> 
> I could imagine clients taking advantage of that characteristic.
> 
> > Do we need to change our canonicalization logic to not collapse
> > individual sequence values (not a big deal, but we need to know).
> > And are there clients that will choke if we DO canonicalize the output?
> 
> Code which collapses 1:5,3,7,8 to 1:8 is fine as-is.

----------------------
Larry Osterman
Sent from Simeon 4.1.1, from Microsoft Exchange "Osmium" IMAP server.
Since not all of these are released products, please notify the sender of any problems.

[e-mail]