Subject: [lemonade] URLAUTH authorization mechanisms

From: Timo Sirainen <[email-masked]>
Date: Thu, 2 May 2013 18:42:20 +0300

Only INTERNAL mechanism was specified by RFC 4467, but it made it possible to add more in future. But it doesn't look like there's any easy way for a client to find out which mechanisms are supported? Perhaps there should be an errata saying that URLMECH reply MUST be returned by SELECT/EXAMINE if there are any other mechanisms besides INTERNAL?

---

From: Eric Burger <[email-masked]>
Date: Thu, 2 May 2013 11:50:48 -0400

Before we go too deep, I wold like to solve two problems with one email. The overarching problem: does anyone care about lemonade? I have not heard boo since 2009 about implementations. So, to find out who cares, it would be interesting to find out who does. Can people let me know if their information is correct, updated, or you are new to implementing lemonade. See http://www.standardstrack.com/ietf/lemonade/Lemonade-Plans.html for what I know about now.

On May 2, 2013, at 11:42 AM, Timo Sirainen <[email-masked]> wrote:

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

---

From: Jan Kundrát <[email-masked]>
Date: Thu, 02 May 2013 18:06:58 +0200

On Thursday, 2 May 2013 17:50:48 CEST, Eric Burger wrote:
> See 
> http://www.standardstrack.com/ietf/lemonade/Lemonade-Plans.html 
> for what I know about now.

Hi Eric, that page refers to "phase 1", but RFC5550 doesn't use that terminology anywhere. What is "phase 1"? There are some traces of that in a presentation from 2005 [1] which refers to the POSTADDRESS extension which is completely dead AFAIK. I don't suppose it makes much sense to use these terms anymore.

Anyway, it looks like Trojitá ("vendor": KDE) supports all extensions I could find in that "phase 1" presentation except POSTADDRESS and DSN.

I've tested CATENATE against Cyrus, a development version of Dovecot and against Isode. The full-blown "Lemonade trio" with URLAUTH and BURL was verified with Isode.

With kind regards,
Jan

[1] http://www.ietf.org/proceedings/64/slides/lemonade-3/lemonade-3.ppt

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 2 May 2013 19:12:03 +0300

Dovecot v2.2 supports all of the required IMAP extensions in RFC 5550, except for CONTEXT=SORT and CONVERT. CONTEXT=SORT is actually half implemented, and probably will be fully at some point. I'm not sure about CONVERT, although it probably isn't that much trouble to implement. Dovecot v2.3 will also implement a new SMTP submission server, which is planned to support all of the Lemonade SMTP extensions.

For some other IMAP servers see http://imapwiki.org/Specs

I know only one IMAP client that supports much of Lemonade: http://trojita.flaska.net/ but maybe it slowly gets more popular when more servers implement it.

BTW. Dovecot's vendor in your web page isn't IKI (and has never been). Nowadays it has a company, so it could be updated also to Dovecot, or to its logo: http://dovecot.org/logo/

---

From: Eric Burger <[email-masked]>
Date: Thu, 2 May 2013 12:17:07 -0400

Rather than duplicating effort, I think I'll point to imapwiki. Here is the Does Anyone Care question rephrased: Gmail and Exchange use none of the lemonade extensions. Any idea if the Android client, iPhone Mail, or RIM (BlackBerry) clients use lemonade? If the answer is No, then I fear X.400 has more market share than lemonade.

---

From: Jan Kundrát <[email-masked]>
Date: Thu, 02 May 2013 18:39:59 +0200

On Thursday, 2 May 2013 18:17:07 CEST, Eric Burger wrote:
> Android client

Nope. As of android-4.1.1_r3-35-g01c55fd (mid-2012, roughly), they only supported NAMESPACE, UIDPLUS and STARTTLS, nothing else -- not even LITERAL+ or ESEARCH.

> iPhone Mail

CONDSTORE, ESEARCH, COMPRESS and BURL are supported. As far as I know, as of mid-2012, QRESYNC or IDLE were not supported.

With kind regards,
Jan

---

From: Dave Cridland <[email-masked]>
Date: Thu, 2 May 2013 18:39:16 +0100

Inky - http://inky.com - by Arcode will be implementing everything except
convert, roughly. I think convert has been overtaken by events, really,
whereas many of the others are still relevant and useful.

I've not yet done a formal roadmap, though, so this remains off the top of
my head, and subject to change.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 May 2013 20:23:06 +0100

On 02/05/2013 17:06, Jan Kundrát wrote:
>> See http://www.standardstrack.com/ietf/lemonade/Lemonade-Plans.html 
> Hi Eric, that page refers to "phase 1", but RFC5550 doesn't use that 
> terminology anywhere. What is "phase 1"? There are some traces of that 
> in a presentation from 2005 [1] which refers to the POSTADDRESS 
> extension which is completely dead AFAIK. I don't suppose it makes 
> much sense to use these terms anymore.
"Phase 1" refers to RFC 4550. POSTADDRESS was removed from it before 
publication.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 May 2013 20:26:39 +0100

> Before we go too deep, I wold like to solve two problems with one email. The overarching problem: does anyone care about lemonade? I have not heard boo since 2009 about implementations. So, to find…
I think people do care about some subset of Profile Bis, they don't care 
much about the label.

As far as updating your web page is concerned, Isode supports Profile 
Bis, minus the following:
NOTIFY, CONVERT, CONTEXT=SORT, I18NLEVEL=1.

 From the list Isode doesn't support, we might look at NOTIFY, but no 
urgency until somebody asks for it.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 May 2013 15:29:05 -0400

> Only INTERNAL mechanism was specified by RFC 4467, but it made it possible
> to add more in future. But it doesn't look like there's any easy way for a client to
> find out which mechanisms are supported? Perhaps there should be an errata
> saying that URLMECH reply MUST be returned by SELECT/EXAMINE if there
> are any other mechanisms besides INTERNAL?

There's no need to do this with an errata report, and I would only
Reject such a report anyway, because this isn't an erratum.

Nothing at all needs to happen until there's a new mechanism, and then
the specification for that mechanism can say what needs to be said,
and it can "update" 4467.

Barry