re: GMail

If I had to rate Gmail's IMAP server by the standards of
"ready for prime 
time" my rating would be quite damning; it is
non-compliant with the IMAP 
specification and has demonstrable bugs in operation.

Rather than do so, I prefer to consider Gmail's IMAP server
to be a first 
development test, and NOT something that is presented as
being "ready for 
prime time".

I hope that Google feels the same way, and that Google will
soon present 
a server that is "ready for prime time".

-- Mark --

http://staff.washingt
on.edu/mrc
Science does not emerge from voting, party politics, or
public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On 10/25/07, Mark Crispin <MRCcac.washington.edu>
wrote:
> If I had to rate Gmail's IMAP server by the standards
of "ready for prime
> time" my rating would be quite damning; it is
non-compliant with the IMAP
> specification and has demonstrable bugs in operation.
>
> Rather than do so, I prefer to consider Gmail's IMAP
server to be a first
> development test, and NOT something that is presented
as being "ready for
> prime time".
>
> I hope that Google feels the same way, and that Google
will soon present
> a server that is "ready for prime time".

an other silly bug:

http://www.colino.net/wordpress-1.5/archives/
2007/10/25/dear-gmail/

-- 
DINH Viêt Hoà
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Sat, 27 Oct 2007, DINH Viêt Hoà wrote:
> another silly bug:
> http://www.colino.net/wordpress-1.5/archives/
2007/10/25/dear-gmail/

We definitely need to encourage them to Google these bugs. 
Microsoft too; 
unfortunately it seems that Exchange server has regressed
with protocol 
syntax bugs (take a look at BODYSTRUCTURE, especially of
nested messages).

I exchanged a handful of messages with Google about their
use of mailboxes 
(instead of keywords) to represent GMail labels and the
problems that 
occur as a result of this.  They have two problems; first
that labels can 
be UTF-8 and second that they worry about limited client
support.

IMHO, we should give a hum of concensus for a commuity
statement that 
keywords can be in modified UTF-7.  I don't see any syntax
reason why this 
can not be done, although doubtless we'd all have to update
our clients to 
handle MUTF7 in keywords.  That should not be a big deal for
most of us.

MUTF7 sucks.  We all know that.  We should move forward on
IMAP UTF-8 
ASAP.  I think that we should have a sweet, short, RFC in
which a server 
advertises a UTF8 capability which the client has to switch
on.  When on, 
the server accepts and outputs UTF-8 instead of MUTF7.  It
is up to server 
how the strings are stored internally, but if it stored in
UTF-8 then it 
must convert to/from MUTF7 when not in UTF-8 mode.

We do need better client support for keywords.  IMHO, we
should do that 
and drag Outlook along, screaming and kicking.  That's
better than the 
current situation where Outlook is dragging us back.

-- Mark --

http://staff.washingt
on.edu/mrc
Science does not emerge from voting, party politics, or
public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Sat Oct 27 17:36:06 2007, Mark Crispin wrote:
> I exchanged a handful of messages with Google about
their use of  
> mailboxes (instead of keywords) to represent GMail
labels and the  
> problems that occur as a result of this.  They have two
problems;  
> first that labels can be UTF-8 and second that they
worry about  
> limited client support.
> 
> IMHO, we should give a hum of concensus for a commuity
statement  
> that keywords can be in modified UTF-7.  I don't see
any syntax  
> reason why this can not be done, although doubtless
we'd all have  
> to update our clients to handle MUTF7 in keywords. 
That should not  
> be a big deal for most of us.
> 
> MUTF7 sucks.  We all know that.  We should move forward
on IMAP  
> UTF-8 ASAP.  I think that we should have a sweet,
short, RFC in  
> which a server advertises a UTF8 capability which the
client has to  
> switch on.  When on, the server accepts and outputs
UTF-8 instead  
> of MUTF7.  It is up to server how the strings are
stored  
> internally, but if it stored in UTF-8 then it must
convert to/from  
> MUTF7 when not in UTF-8 mode.

+1 - I was just having this conversation with - apparently -
the same  
person you were.

But I'd like to turn off all the legacy encoding at the same
time.  
Mailboxes, keywords, headers, bodies - the lot.

Dave.
-- 
Dave Cridland - mailto:davecridland.net - xmpp:dwdjabber.org
  -
acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Sat, 2007-10-27 at 23:21 +0100, Dave Cridland wrote:
> > MUTF7 sucks.  We all know that.  We should move
forward on IMAP  
> > UTF-8 ASAP.  I think that we should have a sweet,
short, RFC in  
> > which a server advertises a UTF8 capability which
the client has to  
> > switch on.  When on, the server accepts and
outputs UTF-8 instead  
> > of MUTF7.  It is up to server how the strings are
stored  
> > internally, but if it stored in UTF-8 then it must
convert to/from  
> > MUTF7 when not in UTF-8 mode.
> 
> +1 - I was just having this conversation with -
apparently - the same  
> person you were.
> 
> But I'd like to turn off all the legacy encoding at the
same time.  
> Mailboxes, keywords, headers, bodies - the lot.

What do you mean by header/body legacy encoding?


_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Sat, 27 Oct 2007, Dave Cridland wrote:
> But I'd like to turn off all the legacy encoding at the
same time. Mailboxes, 
> keywords, headers, bodies - the lot.

You mean that you want the server to translate charsets to
UTF-8?  I would 
support doing that with an alternative form of FETCH, e.g.,
UTF8.FETCH. 
But then there would have to be an error on a charset
conversion failure, 
and it begs the question as to why the CONVERT extension in
Lemonade 
doesn't do that.

IIRC, the only IMAP specific things that are 7-bit are
keywords and 
mailbox names.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for
lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Sat, 2007-10-27 at 17:10 -0700, Mark Crispin wrote:
> On Sat, 27 Oct 2007, Dave Cridland wrote:
> > But I'd like to turn off all the legacy encoding
at the same time. Mailboxes, 
> > keywords, headers, bodies - the lot.
> 
> You mean that you want the server to translate charsets
to UTF-8?  I would 
> support doing that with an alternative form of FETCH,
e.g., UTF8.FETCH. 
> But then there would have to be an error on a charset
conversion failure, 
> and it begs the question as to why the CONVERT
extension in Lemonade 
> doesn't do that.

Converting message bodies would break cryptographic
signatures.
Converting headers automatically might also do bad things. I
guess
ENVELOPE, BODY and BODYSTRUCTURE could be returned
converted, but I
don't know if that helps much.


_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Sun, 28 Oct 2007, Timo Sirainen wrote:
> Converting message bodies would break cryptographic
signatures.
> Converting headers automatically might also do bad
things. I guess
> ENVELOPE, BODY and BODYSTRUCTURE could be returned
converted, but I
> don't know if that helps much.

Right, which is why FETCH should remain unchanged.

-- Mark --

http://staff.washingt
on.edu/mrc
Science does not emerge from voting, party politics, or
public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

Mark Crispin writes:
> On Sun, 28 Oct 2007, Timo Sirainen wrote:
>> Converting message bodies would break cryptographic
signatures. 
>> Converting headers automatically might also do bad
things. I guess 
>> ENVELOPE, BODY and BODYSTRUCTURE could be returned
converted, but I 
>> don't know if that helps much.
>
> Right, which is why FETCH should remain unchanged.

I haven't looked at CONVERT recently, but from what I
remember, it can 
handle charset conversion. That leaves ENVELOPE, BODY,
BODYSTRUCTURE, 
mailbox names and flags. So a new extension to say
"give me those in 
UTF-8" makes sense to me.

But an extension to say only "use UTF-8 for mailboxes
and flags (instead 
of mUTF-7)" makes even more sense. UTF-8 flags have
real value. But I 
assume most clients need 8859-1 and 2047 support for other
reason, 
andso changing the way ENVELOPE, BODY and BODYSTRUCTURE
works doesn't 
really make life simpler for them.

Arnt
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Sun, 28 Oct 2007, Arnt Gulbrandsen wrote:
> I haven't looked at CONVERT recently, but from what I
remember, it can handle 
> charset conversion. That leaves ENVELOPE, BODY,
BODYSTRUCTURE, mailbox names 
> and flags. So a new extension to say "give me
those in UTF-8" makes sense to 
> me.

IMHO, since CONVERT isn't done yet, it should be extended to
do ENVELOPE, 
BODY[STRUCTURE] for those people who want that
functionality.  The main 
benefit that I see is that it allows clients to have less
knowledge of 
random charsets.  Otherwise, clients need to know how to
generate MIME 
encoded words, and probably want to generate them in the
same charset in 
replies that the original message used.

> But an extension to say only "use UTF-8 for
mailboxes and flags (instead of 
> mUTF-7)" makes even more sense. UTF-8 flags have
real value.

Well, there's several possible ways to go about doing all
this.  Consider 
all of these to be strawmen.

1) An "ENABLE UTF-8" command that throws a big
switch.  Rather unIMAPish.

2) UTF8 FETCH, UTF8 LIST, UTF8 LSUB commands.  IMAPish, but
somewhat 
pessimistic about the future of certain extensions.

3) Make CONVERT do ENVELOPE/BODY[STRUCTURE] for those who
want it, and add 
a UTF8 option to LISTEXT.  Somewhat optimistic about these
extensions.

Personally, I vote for 2, simply because this is easy to
apply upon the 
base specification.  Exchange's server, which is rapidly
taking over while 
we're talking about ever-more esoteric extensions, only
supports IDLE, 
NAMESPACE, and LITERAL+.  I don't see much future for a
framework that 
requires complex extensions such as CONVERT and LISTEXT.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for
lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol