gmane.ietf.lemonade

Re: BINARY & CATENATE

Timo Sirainen — 2013-06-15T07:43:16


Hmh. Maybe this should be done the other way around. Save C-T-E=binary mails as is, and do the necessary translation at FETCH time instead so any digital signatures wouldn't break either. But it would be nice if clients could get C-T-E=binary BODYSTRUCTURE replies and such. Perhaps a new BINARY extension that supports "ENABLE BINARY" for clients that allows sending them literal8 for FETCH replies?

Although how common is C-T-E=binary support anyway? Is it required by something? Is it becoming more common in future? Is there any point in spending time on this?..

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: BINARY & CATENATE

Dave Cridland — 2013-06-14T09:50:04


So looking at that, I note that literal8 is actually literalNUL - <literal>
is defined as being made up of <CHAR8>, which is any octet except NUL. So
you can have messages you need to rewrite even if they don't use literal8
syntax in the upload.

I would, in general, scan and if needs be reformat the message on any
APPEND. You're allowed to do this by RFC 3501, which specifically allows it
in the case where your underlying message store is only 7-bit capable.

Dave
_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: BINARY & CATENATE

Timo Sirainen — 2013-06-13T15:04:25


Old message :) How was this eventually implemented to Cyrus? Or how do people think it should work? I was also wondering about this a year ago: http://mailman2.u.washington.edu/pipermail/imap-protocol/2012-June/001787.html

I'm now again wondering if I should change how it works.

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: URLAUTH authorization mechanisms

Barry Leiba — 2013-05-02T19:29:05

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
_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: URLAUTH authorization mechanisms

Alexey Melnikov — 2013-05-02T19:26:39

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.

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: URLAUTH authorization mechanisms

Alexey Melnikov — 2013-05-02T19:23:06

"Phase 1" refers to RFC 4550. POSTADDRESS was removed from it before 
publication.

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: URLAUTH authorization mechanisms

Dave Cridland — 2013-05-02T17:39:16

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.
_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: URLAUTH authorization mechanisms

Jan Kundrát — 2013-05-02T16:39:59

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.


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

Re: URLAUTH authorization mechanisms

Eric Burger — 2013-05-02T16:17:07

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.

On May 2, 2013, at 12:12 PM, Timo Sirainen <tss< at >iki.fi> wrote:


_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: URLAUTH authorization mechanisms

Timo Sirainen — 2013-05-02T16:12:03

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/

On 2.5.2013, at 18.50, Eric Burger <eburger< at >standardstrack.com> wrote:


_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemen

Re: URLAUTH authorization mechanisms

Jan Kundrát — 2013-05-02T16:06:58

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

Re: URLAUTH authorization mechanisms

Eric Burger — 2013-05-02T15:50:48

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 <tss< at >iki.fi> wrote:


_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

URLAUTH authorization mechanisms

Timo Sirainen — 2013-05-02T15:42:20

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?

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: [Technical Errata Reported] RFC5162 (3323)

Alexey Melnikov — 2012-12-18T15:19:40

Sorry for the delay, finally got in touch with Jan to discuss what to do 
here.
Either reject explaining in the rejection note that the issue is valid, 
but the fix is not (and pointing to the new draft). Or "Hold for 
Document Update".



_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: [Technical Errata Reported] RFC5162 (3323)

Pete Resnick — 2012-12-10T17:21:54

(Housekeeping)

Should we be marking this as "Hold for Document Update" at this point, 
or reject it outright?

pr

On 8/17/12 10:12 AM, Alexey Melnikov wrote:
_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

CATENATE with 0 message size

Timo Sirainen — 2012-08-29T20:00:12

a APPEND INBOX CATENATE (TEXT {0}
)

This isn't explicitly prevented by the RFC. So I guess it means that the TEXT {0} parts can be simply skipped.

Regardless of the above, it's possible to also create empty URL streams (e.g. a partial starting from offset 100000000). Should it be allowed to save empty messages?.. I'm thinking I'll just return NO to such APPENDs, although with MULTIAPPEND that's a bit bad behavior to abort the whole APPEND.

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: NOTIFY + CONTEXT

Alexey Melnikov — 2012-08-20T14:11:45

Correct. I think it says that explicitly earlier in the same section.

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: [Technical Errata Reported] RFC5162 (3323)

Jan Kundrát — 2012-08-18T13:16:06

I've therefore submitted my earlier draft, it lives on [1].

Please feel free to do anything you deem appropriate with the original 
errata.

With kind regards
Jan

[1] http://datatracker.ietf.org/doc/draft-kundrat-qresync-arrived/

NOTIFY + CONTEXT

Timo Sirainen — 2012-08-13T05:01:20

Just wondering if I understood this feature correctly..:

RFC says:


This basically means that only new messages get FETCH responses, right?
It also means that doing this wouldn't be very useful:

a SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER])) FLAGGED

because the only time it would return the header is when a message was
saved/copied to the mailbox with the \Flagged flag already set.

I guess the only use case would be when you want to get pushed FETCH
replies for new messages that match a search query.

So a client can add a NOTIFY and multiple SEARCH UPDATEs, each one
pushing FETCH updates about new mails.


_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: URLAUTH RESETKEY

Alexey Melnikov — 2012-05-24T15:22:22

Hi Timo,

On 22/05/2012 12:52, Timo Sirainen wrote:
I think the purpose is to notify the client that previously issued 
URLAUTH keys are no longer valid. The client might want to regenerate 
some URLs upon seeing that.
Not necessarily. This might also be caused by some administrative 
interface that doesn't necessarily use IMAP.
On SELECT/EXAMINE this response code is used to advertise supported 
URLAUTH mechanisms.
Well, if your session is in IDLE, you should receive it immediately. 
Otherwise sending it on the next command would be fine, unless the next 
command is GENURLAUTH...


_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

URLAUTH RESETKEY

Timo Sirainen — 2012-05-22T11:52:47

..

This is a bit confusing. First of all, what is the purpose of sending the URLMECH response to other clients? Can they assume that if it's received then a RESETKEY command has been issued? Doesn't seem very IMAPy to assume that, since it is also sent during SELECT/EXAMINE. Is it simply to handle the cases when non-INTERNAL mechanisms are used and they might have changed the mech-specific data? Is there really even a need to send this if server only supports INTERNAL?

And when would the message be sent? Does "will receive" mean immediately? Before the next command? After the next command? Maybe sometimes later?

_______________________________________________
lemonade mailing list
lemonade< at >ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade