Tag Configuration object draft

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Fri Jun 20 11:35:02 CEST 2014


On 2014-06-17 14:18, Aleksander Machniak wrote:
> 2.2. Email messages need to be specified as IMAP URIs with additional
> data to use as a fallback search when message specified by folder/UID
> does not exist. So, we have RFC5092 to consider. However, our use-case
> here is different. I propose:
> 
> imap:///<path>/<uid>#<message-id>;<date>
> 
> where <path> is "user/<username>[/folder]" or "shared[/folder]", <uid>
> is message IMAP UID, <message-id> and <date> are values of these 
> headers.
> 
> Note that we use "imap:///" prefix because we don't need host/auth info
> here.
> 
> Considerations/Feedback needed:
> 
> - I decided to not use UIDVALIDITY in URI, what do you think?
> - Still, I'm not sure if we should use message date header as is or 
> e.g.
> converted to unix timestamp.
> - maybe what we do after # we should change to a search string, e.g.
> "imap:///<path>/<uid>?<search>", where <search> is e.g.
> HEADER%20MESSAGE-ID...%20HEADER%20DATE...?
> 

Specifically for IMAP URIs to email messages, it can reasonably be 
argued that such a URI is a one-shot attempt (to quickly refer to the 
message should it still live in that place).

I suppose that to circumvent the dead links when the target message is 
moved/deleted, folder renamed/deleted, or any such intermediate event 
takes place, we could add additional parameters -- perhaps in the XML, 
perhaps in the IMAP URI.

As to using or not using UIDVALIDITY, I suppose ultimately this might 
have to do with performance.

Suppose I link to a message Foo/1., and I find Foo/ is still the exact 
same folder, but 1. is not in there -- I should start searching 
(probably all folders but Foo/). If Foo/ however is a different folder 
(the old Foo/ was renamed/deleted, a new Foo/ was created?) -- I should 
start searching (probably all folders including Foo/) -- could I start 
searching for whatever Foo/ may have been renamed to in a ditch attempt 
to be a little more efficient?

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08


More information about the format mailing list