Subject: [lemonade] Remarks about NOTIFY-07 while trying to implement it in a client

From: Philip Van Hoof <[email-masked]>
Date: Tue, 13 Nov 2007 15:48:16 +0100

Hi there,

I don't know whether or not I'm the first to try, but I tried to
implement 'using NOTIFY' in my client (Tinymail, Modest, TMut). I had
some difficulties and, given that there are few servers supporting it
and I couldn't find any to use, some questions too. 

This probably means that the proposal can use some more clarification
here and there. Or maybe some more examples.

* The unsolicited LIST response must be accompanied by a STATUS. Else I
have a new folder but I don't know about its counts. For example: if the
user of another E-mail client that is connected to the same account
copies a folder A to B, I'd get a LIST response, but not guaranteed a
STATUS? I think the standard should guarantee both to take place in
order (first the LIST, then the STATUS).

* STATUS's unsolicited response does not mention the UNSEEN parameter.
Neither (however) would that be a useful one as some E-mail clients see
"unread" as the amount of items that never got read AND that never got
marked as deleted (while perhaps still being unread).

The problem here is that a lot of spam softwares mark spam as deleted
too. Some people "hide" deleted E-mails too (they want to remove unread
items, which is not uncommon in these days of spam spam and spam). They
don't want those hidden (marked as deleted) items to be counted as
unread. STATUS's UNSEEN doesn't take that into account. With ESEARCH
it's possible to merge the \Deleted and \Seen correctly to a meaningful
number.

NOTIFY doesn't seem to support that calculation, putting us back at
where we are with STATUS (for NOTIFY): at a non useful number. This
limits NOTIFY, other than the folder created/deleted/renamed events, to
the exact same functionality than what IDLE already offers (most mobile
E-mail clients don't show the total count of the folders, for screen
space reasons): only the unread count of the currently selected folder
can be known in real time.

Putting us back at IDLE :)

* Is it possible for a folder to be created with a bunch of childs
instantly? And will I get unsolicited LIST responses in order about
that? I haven't found something in the proposal that talks about the
order of LIST responses. For the client developer, it's important that
this happens in order (or a lot more complex to handle, if not).

* Unsolicited VANISHED vs. EXPUNGE: clarify exactly and very clearly
"when what" is going to be used. For the client it's highly important
that the IMAP server doesn't use both (the index number of the EXPUNGE
response would be wrong if the client already handled a VANISHED for the
removal, causing loss of data for the user).

* Unsolicited multi-line responses are not easy for my situation to
handle. At least not if they don't start with a " * ". Although this is
a problem of my software (not of the standard itself). This makes it
difficult to deal with nicer MessageNew responses (I fear I'll have to
limit what the server will offer me to just the UID, and use my current
IDLE code: to stop the IDLE mode, get the information that I need and
then restart IDLE mode, rather than letting the server instantly give me
all the info that I'll need).

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Philip Van Hoof <[email-masked]>
Date: Tue, 13 Nov 2007 17:04:51 +0100

> and I couldn't find any to use, some questions too. 

...

Another question:

What is the difference between a deleted mailbox, and a created
mailbox's unsolicited STATUS response? From the examples:

Example of a newly created mailbox:
        S: * LIST () "/" "NewMailbox"

And a deleted mailbox:
        S: * LIST (\NoSelect) "/" "INBOX.DeletedMailbox"

So ... the "\NoSelect" flag? Can't a not-removed folder have that flag 
too? The description doesn't seem to talk about this \NoSelect flag
either (just the example shows this as difference).

---

From: Dave Cridland <[email-masked]>
Date: Tue, 13 Nov 2007 16:34:46 +0000

On Tue Nov 13 16:04:51 2007, Philip Van Hoof wrote:
> So ... the "\NoSelect" flag? Can't a not-removed folder have that  
> flag too?

Kind of. But the distinction between a mailbox that exists, but has  
the \NoSelect attribute, and a mailbox that doesn't exist at all, is  
pretty minor for a client. Nevertheless, you're right that a "folder"  
- a hierarchy point which can potentially have inferior mailboxes -  
can indeed have an existence and this flag.

>  The description doesn't seem to talk about this \NoSelect flag

\NoSelect is itself defined in RFC3501.

I think in this case, we possibly want to say \NonExistent instead  
(From LIST-EXTENDED).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 14 Nov 2007 12:05:12 +0000

> I think in this case, we possibly want to say \NonExistent instead  

Indeed. This is a bug in the example that Philip quoted, as the text 
above was talking about \Nonexistent.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 14 Nov 2007 17:53:33 +0000

Hi Philip,

>this happens in order (or a lot more complex to handle, if not).
You can't expect any particular order of unsolicited LIST responses and 
your client already has to handle this for the regular LIST command.
When your client sees a response like this:
 * LIST () "/" "A/B/C"
it has to also create [UI] objects for mailboxes A and A/B, if it hasn't 
created them already.

>that the IMAP server doesn't use both
>
The server is either always sending EXPUNGE or always sending VANISHED. 
Mixing them is indeed not a good idea. But this is really a QRESYNC 
issue, if it is an issue at all.

>(the index number of the EXPUNGE
As a side note: I think a client that has the full mailbox msgno-to-uid 
map should be able to cope anyway. The server should send correct 
message numbers at all times.

>handle. At least not if they don't start with a " * ".
>
I am not sure I understand what the issue is. Can you elaborate?

>Although this is a problem of my software (not of the standard itself). This makes it

---

From: Philip Van Hoof <[email-masked]>
Date: Thu, 15 Nov 2007 00:12:35 +0100

> it has to also create [UI] objects for mailboxes A and A/B, if it hasn't 

Okay. That makes it quit a bit more difficult though.

> issue, if it is an issue at all.

Indeed

> I am not sure I understand what the issue is. Can you elaborate?

Well, it's a problem in how I'm handling things that happen while in
IDLE mode. I should fix this in my code rather than claim it's making
certain things more difficult :)