Skip to main content

Liaison statement
OMALS 0068 MWG-MEM SWG Response to Liaison on Mobile e-mail from the IETF LEMONADE WG

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2006-01-23
From Group IETF
From Contact Dean Willis
To Group lemonade
To Contacts eburger@brooktrout.com
gparsons@nortel.com
Cc hardie@qualcomm.com
sah@428cobrajet.net
Response Contact Dorothy.gellert@nokia.com
Technical Contact Dorothy.gellert@nokia.com
Purpose In response
Attachments Liaision Statement Original in MS Word Format
Body
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.