Subject: [imap5] Standardized error messages

From: Peter Mogensen <[email-masked]>
Date: Tue, 21 Oct 2008 16:55:49 +0200

Hi,

I'm really looking forward to IMAP5, and I think I have only one wish 
which I really care about (for now :) ):

Error reporting.

I've been doing a multi-lingual client for some time now and the stuff 
we get back from the IMAP-server is basically useless.

The way error reporting is defined in section 7.1.2-7.1.3 of RFC3501 is 
a problem in todays multi-lingual world. We can't use the human-readable 
text after NO and BAD. Not all users are english and often the 
description is non of their business, but for the sysadm.
But we can't use the string for anything programmatic because it differs 
from server to server. All you have is "NO" and "BAD", which gives you 
not much for choosing an error-message to present to the user.

Personally I would prefer a pre-condition/post-condition error-reporting 
with well defined codes for violation , - like CalDAV (rfc4791) - 
without the XML obviously.

regards,
Peter
_______________________________________________
imap5 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/imap5

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 21 Oct 2008 16:55:55 +0200

> we get back from the IMAP-server is basically useless.

Yes.

> The way error reporting is defined in section 7.1.2-7.1.3 of RFC3501 
> is a problem in todays multi-lingual world. We can't use the 
> human-readable text after NO and BAD. Not all users are english and 
> often the description is non of their business, but for the sysadm.
> But we can't use the string for anything programmatic because it 
> differs from server to server. All you have is "NO" and "BAD", which 
> gives you not much for choosing an error-message to present to the 
> user.

Please read RFC 5255 and draft-gulbrandsen-imap-response-codes, and see 
what you think.

Arnt

---

From: Peter Mogensen <[email-masked]>
Date: Tue, 21 Oct 2008 19:27:10 +0200

Arnt Gulbrandsen wrote:
> Please read RFC 5255

Oh... hadn't seen.
It's of course better wrt. i18n than RFC3501, but IMHO it also servers 
to make the matter worse wrt. server-responses not being the same across 
implementations. Now you have several languages for which the response 
could differ differently.

> and draft-gulbrandsen-imap-response-codes, and see 
> what you think.

Better... although I'm not sure it's a good idea to merge error-codes 
and status info (like UNSEEN,UIDNEXT...) into the same namespace.

/Peter

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 21 Oct 2008 20:37:56 +0300

On Oct 21, 2008, at 8:27 PM, Peter Mogensen wrote:

>> and draft-gulbrandsen-imap-response-codes, and see what you think.
>
> Better... although I'm not sure it's a good idea to merge error- 
> codes and status info (like UNSEEN,UIDNEXT...) into the same  
> namespace.

Hmm. Wonder if this causes problems. For example [EXPUNGEISSUED] can't  
be returned for a STORE UNCHANGEDSINCE that returns [CHANGEDSINCE].  
Perhaps there are other similar issues. But maybe they don't matter.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 21 Oct 2008 19:50:04 +0200

Timo Sirainen writes:
> Hmm. Wonder if this causes problems.

It does, but that problem is one we have already and it hasn't been THAT 
painful:

        REFERRAL             RFC 2221
        ALERT                RFC 3501
        BADCHARSET           RFC 3501
        PARSE                RFC 3501
        PERMANENTFLAGS       RFC 3501
        READ-ONLY            RFC 3501
        READ-WRITE           RFC 3501
        TRYCREATE            RFC 3501
        UIDNEXT              RFC 3501
        UIDVALIDITY          RFC 3501
        UNSEEN               RFC 3501
        UNKNOWN-CTE          RFC 3516
        UIDNOTSTICKY         RFC 4315
        APPENDUID            RFC 4315
        COPYUID              RFC 4315
        URLMECH              RFC 4467
        TOOBIG               RFC 4469
        BADURL               RFC 4469
        HIGHESTMODSEQ        RFC 4551
        NOMODSEQ             RFC 4551
        MODIFIED             RFC 4551
        COMPRESSIONACTIVE    RFC 4978
        CLOSED               RFC 5162
        BADCOMPARATOR        RFC 5255
        ANNOTATE TOOBIG      RFC 5257
        ANNOTATE TOOMANY     RFC 5257
        ANNOTATIONS          RFC 5257

I've run into a case where I wanted to return two things (UIDNEXT and an 
error? can't remember).

> For example [EXPUNGEISSUED] can't be returned for a STORE 
> UNCHANGEDSINCE that returns [CHANGEDSINCE].

I think they matter in principle, but generally you IMAP doesn't both 
return an error and do something at the same time.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 21 Oct 2008 11:31:20 -0700

> could differ differently.

The so-called "human-readable" responses in IMAP are not, and were never,
intended for end users.  They are intended to be recorded into telemetry logs
for the benefit of maintenance personnel.

It is completely wrong-headed to attempt l10n (not, as certain people
misstate, i18n -- the two are not the same) of the "human-readable"
responses in IMAP.  You seem to recognize that fact, which is good.  The
next step is to recognize that "human-readable" responses are the wrong
thing to tweak, and that IMAP has a suitable mechanism for this purpose.

Response codes are the right way to generate information for the end user.
The fact that this question still comes up shows that this is a very difficult
problem.

> and status info (like UNSEEN,UIDNEXT...) into the same namespace.

There is no clear dichotomy between an "error code" and "status info".
Many IMAP response codes are both.

IMAP's server response schema isn't perfect -- it's 22 years old and has
acquired warts along the way.  NMAPv3 is quite a bit cleaner in that regard.
But the mechanism exists to do as you advocate.
_________________________________________________________________
Want to read Hotmail messages in Outlook? The Wordsmiths show you how.
http://windowslive.com/connect/post/wedowindowslive.spaces.live.com-Blog-cns!20EE04FBC541789!167.entry?ocid=TXT_TAGLM_WL_hotmail_092008
_______________________________________________
imap5 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/imap5

---

From: Peter Mogensen <[email-masked]>
Date: Tue, 21 Oct 2008 20:38:09 +0200

> for the benefit of maintenance personnel.

Sure... that was my hope.
Which still leaves IMAP4 with very poor error-reporting to client programs.

> thing to tweak, and that IMAP has a suitable mechanism for this purpose.

Yes - I believe that was what I wrote in the initial mail.

> But the mechanism exists to do as you advocate.

Great... I haven't read enough about the proposals for IMAP5 yet to 
suggest any way to do it, but I just wanted to bring focus to this 
rather important (IMHO) area.

regards,
Peter