Method MailNotification.RequestComposeURL should return an URL (an associated POST data) that lead to webmail composition window. This method should be designed in a way that it could handle similar feature to mailto:... URI.

The function was removed from MailNotification draft because the implementation had flaws and was not based on any good use case. Here is the relevant part of the discussion:

<stormer> smcv: the Request_Compose_URL, might be missing arguments, if we think of a typical mailto you can set the field To, Subject and Body (body is plain text only iirc)

<smcv> but do webmail services have those as URL arguments or whatever, in practice?
<smcv> if they don't, then we don't care

<stormer> I need to give a closer look, but I think they do

<smcv> have an a{sv} or a{ss} where the keys are the query-string arguments of a mailto: URI?
<smcv> oh, the query-string arguments are actually just RFC822 headers, except 'body' which is special :-)

... more discussion ...

<stormer> smcv: well that's the second issue, different CM may support different set of headers
<stormer> smcv: would it be fine for CMs just to skip silently the one they don't support ?

<smcv> stormer: that was what I had in mind, yeah
<smcv> stormer: although I suppose they should have an 'as' property listing the ones they support...
<smcv> stormer: otherwise UIs would provide text boxes for things that will never actually work, which would be loss
<smcv> stormer: tbh, do we actually need this?
<smcv> stormer: (as in, is there any UI demand for it?)
<smcv> stormer: if not, I'd be inclined to remove RequestComposeURL entirely, and consider it to be a separate feature later

<stormer> smcv: honestly, I think I should remove it, maybe somebody later could come back with better use case

<smcv> stormer: sounds good. drop it from the spec, clone the bug as "add MailNotification.RequestComposeURL", paste in this conversation?
<stormer> ok