OMALS 0068 MWG-MEM SWG Response to Liaison on Mobile e-mail from the IETF LEMONADE WG
|From Contact||Dean Willis|
|Attachments||Liaision Statement Original in MS Word Format|
1 Overview The IETF LEMONADE WG responded to the liaison initiated by OMA MEM SWG. This response is available as document OMA-MEM-2005-0079- ILS-Mobile-email-AD-RD. This liaison is in response to OMA-MEM-2005-0079-ILS-Mobile-email- AD-RD. 2 Proposal 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 liaison. 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 â€œLocal deleteâ€?. 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 flag.) 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 protecting. 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 comments. 4 Conclusion 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.