The IETF LEMONADE WG responded to the liaison initiated by OMA MEM
SWG. This response is available as document OMA-MEM-2005-0079-
This liaison is in response to OMA-MEM-2005-0079-ILS-Mobile-email-
The IETF LEMONADE liaison response, OMA-MEM-2005-0079-ILS-
Mobile-email-AD-RD was presented to the OMA MWG-MEM at the Athens
OMA meeting on December 12th, 2005. The following comments and
discussion points were agreed by the OMA MEM SWG regarding the IETF
There was some confusion raised by the IETF working group draft
provided in the IETF liaison response. In particular:
-The draft-ietf-lemonade-oma-mem-realization-00.txt re-states
sections of the AD. The OMA MEM WG suggests referencing the OMA
MEM AD to describe the OMA MEM architecture, rather than
summarizing the architecture specification.
- Draft-ietf-lemonade-oma-mem-realization-00.txt. raises
questions as to the division of work between the OMA and IETF.
The OMA MEM WG wants to avoid duplication of technical
specifications to avoid confusion. Since this draft is now a WG
item, it is unclear to some that the OMA has ownership of an OMA
Technical Specification of an IETF LEMONADE based solution for
the OMA MEM enabler.
The following are responses to the specific questions raised by the
IETF LEMONADE WG in the liaison:
1. Is a protocol really needed to cope with lost notifications:
2. â€œCache deleteâ€? is more precise than â€?local deleteâ€?.
Within OMA MEM, â€œcacheâ€? is considered to be temporary storage, and
this terminology is not appropriate since there may still be a copy of
the message on the client. Since the AD clearly defines the meaning of
the term â€œlocal deleteâ€?, OMA MEM would prefer to retain the term
3. Are signed notifications required?
Yes, the signature is required in the protocol. We have discussed the
option of turning this on and off, but the functionality is required
to meet the RD.
Responses to Section 7 of IETF draft (17 mechanisms):
1. No comment
2. This should be referred back to the earlier question on â€œcoping
with lost notificationsâ€? as the statement â€œThis is supported by
ensuring that the LEMONADE protocol does not require that the
notification have been received by the MUA.â€? Goes back to the solution
to be worked out for that question. However, they should include some
kind of indication to Sieve not to generate notification in-band (only
out-band.) Using LFilter to allow the user to update the filters from
the MEM client could be a remote Sieve update, XDM, etc.
3. There are items that are labelled as â€œ--â€œ with a note that the item
is not in the scope of IETF. However, we believe that these should be
changed to â€œ++â€?indicating MEM responsibility.
4. Local & Attachment should be changed to â€œ++â€? out of scope of
Lemonade and â€œRemoteâ€? is believed to be handled by IMAP in two steps,
deleting with marked deleted (from clientâ€™s view) and sponging it
later (when & how?).
5. Itâ€™s understood that CONVERT references OMA STI. Client decides the
conversion and server performs conversion (or does not with raising a
6. No comment.
7. For â€œClient to server: e.g. rules filters vacation notices,
notification channel, ...,â€?, there are other methods, e.g., XDMS.
8. Can you provide feedback to the â€œminimizing delaysâ€? aspects?
9. Why â€œto reduce the notifications to the exchange of information
that may not have to be encryptedâ€? if the notifications carry
information worth protecting? We (OMA MEM) are of the opinion that
there might be cases where the notifications include data worth
10. No comment.
11. No comment.
12. No comment.
13. No comment
14. LEMONADE should be aware that there may be limitations on the
mobile devices for mutual authentication as opposed to a full-featured
fixed internet terminal device. May be the object level encryption can
be used and the key can be re-used.
15. The intent here is to have the recall feature extend beyond the
submit server domain. It is an end-to-end recall requirement,
recalling the message.
16. No comment.
17. No comment.
OMA MWG-MEM intends to provide detailed updates of the Mobile e-mail
enabler related activities, including disposition of the comments
received from LEMONADE.
3 Requested Action(s)
We request the IETF LEMONADE Working Group to consider and accept these
OMA MWG-MEM SWG wishes to thank the IETF LEMONADE WG for its response
to OMA MWG-MEMâ€™s previous liaison and for the analysis and feedback
they provided regarding the draft OMA Mobile Email RD and AD. OMA
MWG-MEM looks forward to continued collaboration on these matters with
the IETF LEMONADE WG. Finally, OMA MWG-MEM wishes to thank the IETF
LEMONADE WG for its kind consideration of this liaison.