RE: [lemonade] WG last call on Goals

["Stephane H. Maes" <[e-mail]>]

Please find attached comments to draft-ietf-lemonade-goals-04.txt.

Sorry if long and sometimes repetitive... I think some aspect still warrant more discussions.

Thanks

Stephane

------------

1.	Introduction - Motivation

The draft draft-ietf-lemonade-goals-04.txt is in WG last call status. The present document provides detailed comments.
2.	Mobile e-mail aspects

Based on lessons learned with mobile e-mail we believe that some additional discussion on mobile e-mail should be added. These considerations were accumulated while working on actual mobile e-mail deployments, analyzing the gamut of existing solutions from different vendors, developing, implementing and deploying P-IMAP (draft-smaes-lemonade-p-imap-05.txt) as well as participating to the OMA (Open Mobile Alliance) Mobile E-mail activity (http://member.openmobilealliance.org/ftp/Public_documents/REL/WP/Summary_WISPR_statusPage4.html).

To that effect, I would like to suggest considering adding material from the following:
-	Discussion of mobile issues and use cases were presented in the Dallas/Richardson intermediary Lemonade FTF meeting (59.5): http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-Draft_Overview_Draft.ppt (slide 2 to 5). 
-	More details on the challenges and mobile specific issues that are presented in draft-smaes-lemonade-mobile-email-01.txt. 

See also draft-smaes-lemonade-s2c-notification-reqs-00.txt.

We believe that these use cases, requirements and issues should be discussed in more details in the Lemonade goals draft.
3.	Detailed comments
This section provides more specific comments section by section.
3.1	Comments to the abstract section

>> In particular, by clients on hosts not only operating in environments 
>> with high latency/bandwidth-limited unreliable links but also 
>> constrained to limited resources. <<

While this is correct, I think that we should explicitly recognize the other challenges met in mobile environment (see for example draft-smaes-lemonade-mobile-email-01.txt). So I would like to state:

=>>... but also constrained to limited resources or limitations imposed by mobile networks properties and deployment models.<<=

>> The enhanced mail must continue to support the existing service as 
>> before. <<

This is an unclear statement. I would challenge that in some cases there is no possible (open standard) service in some cases / environment. It should be clarified to acknowledge that fact and to explain that the statement is probably more a statement in terms of interworking between new use and existing mail services etc...

>> The primary motivation for this effort is -- by making Internet mail
   protocols richer and more adaptable to varied media and environments <<

It is not clear that extending the protocol is always suitable (e.g. mobile). Instead we should rather state:

=>> The primary motivation for this effort is to make Internet mail protocols more adaptable and optimizable to varied media and environments <<=

>> ... to allow their use by handheld devices to wirelessly access
   Internet mail without intermediation.<<

I thought that Lemonade had a much broader scope than mobile only. Should the text be changed accordingly to expand the scope

I recommend changing wireless to mobile.

I strongly disagree with the limitation implied by "without intermediation". This is not something that has been justified (yet t at least in my mind) and it is in contradiction with most common current models (see draft-smaes-lemonade-mobile-email-01.txt). It could also be construed as contradicted by the voice mail solution later described. These two words should be removed from the text. 

The goal document is a pre-requirement document. It can't make such decisions in advance. I realize that we may have a problem in the sense that we are designing solution before completing appropriately use cases, requirements etc... But in any case this restriction is too preliminary.
3.1.1	Last paragraph of Abstract

This section seems outdated, at least based on the discussions and work that I have seen taking place at Lemonade in the last year. The size of the paragraph seems to imply a much bigger role that what it has. I suggest updating and reducing and adding a section on mobile e-mail; noting that mobile messaging is not mobile e-mail.

Also if voice mail and other cases are to be supported, they should be mentioned in the Abstract... They are not.

3.2	Comments on introduction

The introduction is missing a discussion on mobile e-mail:
-	Existing demand (enterprises, operators and even consumers), numerous technical solutions, growing adoption 
-	Challenges
-	Need to offer an open standard solution that based on enhanced internet mail or at least appropriately interworking with it.

While messaging clearly includes e-mail; when referring to mobile messaging and when reading the draft so far, messaging rather refers to alternate messaging methods like SMS, MMS etc instead of e-mail. So wording to clarify this should be added. But clearly, we would like to see also the text discussing the need to provide open standard ways to address the challenges of mobile e-mail (see draft-smaes-lemonade-mobile-email-01.txt) and associated use cases (see http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-Draft_Overview_Draft.ppt (slide 2 to 5)).

Similarly and to avoid confusion, instant messaging should be positioned with respect to the Lemonade goals.
3.2.1	Section on "This document [...] in other contexts"

There may be some confusions and lack of clarities with the concept of WUI, Mobile messaging Multi-modal and Mobile e-mail.

- WUI is a client on a mobile / wireless device

- WUI may differ for mobile messaging (SMS, MMS, IM, ...), and mobile e-mail

- Different agents (WUI, TUI, ...) may be involved in multi-modal messaging. It is not a subset of WUI; but WUI may be used to provide multi-modal messaging...

- The multimodal messaging should refer to the multimodal and multi-device work at OMA that explicitly address and explains how agents are combined to provide that desired multimodal effect and more. After all, this work better be consistent with the OMA specifications on this... It may also be good to refer to the W3C MMI work if multimodal messaging was t be treated as a separately authored multimodal application.

- The notion of mobile e-mail client / functionality should be explicitly listed, where mobile e-mail is defined in draft-smaes-lemonade-mobile-email-01.txt as: access to e-mail while mobile.

3.2.2	Comments on Last bullet list

Please add:

- Issues related to mobile e-mail


[And a section should be added. This could be based on the document discussed earlier (See section 2. Mobile e-mail aspects)

3.3	Comments to section 3
3.3.1	Comments to section 3.2.2

We believe that it is important to recognize and document the notions of inband versus outband notifications.

We also believe that it is important to recognize that while the internet mail in general has not identified the need for notifications. However, mobile e-mail as discussed in draft-smaes-lemonade-mobile-email-01.txt) with associated use cases (see http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-Draft_Overview_Draft.ppt (slide 2 to 5)) and in draft-smaes-lemonade-s2c-notification-reqs-00.txt. Therefore the draft should identify to reconcile this difference between "internet mail" and the need of mobile e-mail. Addressing this is a goal of Lemonade...

3.4	Comments to section 4

A problem that I think plague some of the discussion that we are having for example around mobile e-mail is at the level of what it means to:
- Define a profile of internet mail
- Extend internet mail to other environments.

Among the confusion is the difference and confusion already mentioned in these comments between:
- i) Using internet mail as is and adding capabilities
and
- ii) Extending internet mail and way it is used to allow appropriate extension of capabilities and optimize use or support use cases in the new environment.

We recommend that the work and goals of Lemonade include ii) and not just i). We believe that for example supporting server to client notifications is needed in such a context and may require accepting ii). The same holds for deployment use cases.

3.4.1	Comments to section 4.2.2

This is a repeat of the comments made in section 4.1.1. (Comments to "This document [...] in other contexts"):
- The Multi-modal client should refer and state a goal to be reconciled with the OMA multimodal and multi-device specifications and the W3C MMI WG specifications (both sets are currently consistent among each others).

3.4.2	Comments to section 4.2.3

As already discuss in section 4.1.1. (Comments to "This document [...] in other contexts"), we should account for different clients for the different functions that it must perform. It is confusing and frankly not required nor realistic considering the current state of mobile clients to expect a unified client.

We also recommend to change the name from wireless to mobile [This is a general comment across the whole draft]. 	

We would like to see a discussion of a mobile e-mail functionality that is currently missing from the draft and from the notion of WUI.

3.4.3	Additional comments on WUI / Multimodal figure

Similarly, the figure that depicts the multimodal clients is not consistent with the OMA multimodal and multi-device enabler architecture document or the W3C architecture drafts: it misses the functionality of interaction / multimodal synchronization manager consistently identified by both activities. We should re-think what we write it this section, especially as no work seems to have really completed on this at Lemonade. What would be affected?

In addition, we believe that the figure may not be suitable in general for mobile e-mail where the "logical" picture is closer to what is discussed in draft-smaes-lemonade-mobile-email-01.txt (see also the presentation given in Vancouver intermediate Lemonade FTF meeting (60.5): http://www1.ietf.org/mail-archive/web/lemonade/current/pptdErKweWZk5.ppt).  Accordingly, IETF standard protocol may be actually the mobile e-mail protocol as is RFC 822/MIME for retrieval and submission. Notifications are also missing as are notification.

An option to progress is to keep section 4.2.3 as is (taking account the comments of first 3.4.2 Comments to section 4.2.3 and first paragraph above) and adding a section on mobile e-mail client.

3.5	Comments to section 5

I am rather positive and comfortable with the principle enumerated in section 5.  However, I would like to see mobile e-mail added to the list of the topic covered by the principle.

3.5.1	Comment to section 5.1.1 and 5.1.2

[Analysis rather comment - The editor may decide if this should be further explained in the draft of draft-ietf-lemonade-goals-0x.txt] It should be however that when in section 5.1.2 we state that we will not break existing protocols, this does not imply that only new functionalities are added to existing protocols. New protocols and interworking mechanisms are also within scope if they can't be satisfied by existing protocols.

3.5.2	Comment to section 5.3

[Analysis rather comment - The editor may decide if this should be further explained in the draft of draft-ietf-lemonade-goals-0x.txt]

I agree with the principle. However, again it must be clear that this is not preventing new infrastructure when new functionality is needed. 

It should also be clear that  having all extensions backward compatible may be achieved with a protocol that supports IMAP and a different protocol provided that IMAP client can interface with the system and new devices can exploit the additional features.

Intermediaries as discussed in draft-smaes-lemonade-mobile-email-01.txt should be covered and compatible with this principle. They provide a way to support the backward compatibility and progressive support of features. [End of analysis]

>>Messages created in an enhanced messaging context MUST NOT require 
>>changes to existing mail clients.<<

I agree with this and it should also apply to mobile e-mail. But it is important to understand what it means. In the case of mobile e-mail, email generate outside the mobile context MUST be received / used by mobile e-mail client (by design) and email generated by mobile clients MUST be received / used by e-mail clients without any changes. 

The statement should be extended to email servers to state that email server MUST be able to send, receive, handle emails to and from mobile e-mail client without changes of specifications. That does not mean however that it may not involve intermediaries as discussed in draft-smaes-lemonade-mobile-email-01.txt.

>> However, there may be a degradation in functionality in certain 
>> circumstances.<<

For mobile e-mail, we believe that this is not an appropriate statement. Mobile e-mail does not call for degradation of functionality but instead for full support of the requirements / user cases / user experience expected. This statement should be rephrased so that support across different messaging context may imply degradation in functionality BUT when it come to mobile e-mail, full support of the mobile email functionalities (that differs from internet mail as it is today).

3.5.3	Additional comment

A section should be added on mobile e-mail requirements inspired from http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-Draft_Overview_Draft.ppt (slide 2 to 5), draft-smaes-lemonade-mobile-email-01.txt and draft-smaes-lemonade-s2c-notification-reqs-00.txt.

3.6	Comments on section 7

The comment requiring extension of WUI to include mobile e-mail applies.

The recommendation to rename WUI to "mobile" UI still holds

In general this should be run against http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-Draft_Overview_Draft.ppt (slide 2 to 5), draft-smaes-lemonade-mobile-email-01.txt and draft-smaes-lemonade-s2c-notification-reqs-00.txt and completed as needed.

A section in the draft should address the need of enterprise.

3.6.1	Comments to section 7.1

Please add the other considerations on transport challenges mentioned in draft-smaes-lemonade-mobile-email-01.txt section 2.2 (and may be aspect of 2.3)(e.g. loss of IP address, loss of sessions, control of exchanged data, .)
3.6.1.1	Comments to section 7.1.3

Please add the other considerations on Wireless Bandwidth and Network Utilization Considerations mentioned in draft-smaes-lemonade-mobile-email-01.txt section 2.2/2.3 (e.g. walled garden, regulation, firewalls,.)

3.6.2	Comment to sections 7.1.4.2 to 7.1.4.4
Please add the other considerations on device limitations mentioned in draft-smaes-lemonade-mobile-email-01.txt section 2.1 (e.g. closed / controlled platform, .).

Note that these sections are not about content display considerations but about devices capabilities. It would be less confusing if the title of 7.4 was changed to device capabilities.

3.6.3	Comments to section 7.2

The section should be renamed to "mobile e-mail".

It should add all requirements discussed in http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/PIMAP-Draft_Overview_Draft.ppt (slide 2 to 5), draft-smaes-lemonade-mobile-email-01.txt and draft-smaes-lemonade-s2c-notification-reqs-00.txt and explicitly identify that it must address the challenges identified in draft-smaes-lemonade-mobile-email-01.txt (by providing at least supporting technologies)

Example of missing discussion items:
- Need for notifications
- Need to support of firewalls and associated sometimes very conservative corporate policies
- Need to support mobile network limitations (e.g. no session, often disconnected, no fixed IP, non-internet features / capabilities / limitations)
- Mobile deployment models (http://www1.ietf.org/mail-archive/web/lemonade/current/pptdErKweWZk5.ppt and draft-smaes-lemonade-mobile-email-01.txt).
- ... 

3.7	Comments to section 8

Again, this should include a discussion of mobile e-mail. It should include a section that discuss a mobile e-mail protocol as in http://www1.ietf.org/mail-archive/web/lemonade/current/pptdErKweWZk5.ppt and draft-smaes-lemonade-mobile-email-01.txt.

3.7.1	Comment to section 8.2

I do not agree with having sentence "Client-to-server notification is not within the LEMONADE Charter" in the goals. 

1) We need to discuss and agree on the fact that this would not be a goal. It is a goal in my view as discussed earlier
2) It is not clear that it is not within the charter. In other words, the charter may be self contradictory if the required extensions actually require notification. 
3) Goal and charter are not necessarily the same thing. If it happens that Lemonade can not provide client to server notification based on "charter issues" that may not be resolvable, the goal of Lemonade is to provide a protocol that can be used in conjunction with such notifications that can be specified elsewhere. 

The sentence should be removed and we should state that lemonade will analyze the need for client to server notification and will either address them or interwork with them.

3.8	Comment to section 8.
3.8.1	Comments on section 8.4

Additional consideration are presented in section 2.2 of draft-smaes-lemonade-mobile-email-01.txt (e.g. DRM, Charging, .)

The need and concerns of operators with respect to mobile e-mail should be addressed somewhere in the draft. This section solely focus on other mobile messaging.

3.9	Comments to security issues. 

Add the considerations presented in in terms of:
- intermediaries / proxies and end-to-end security
- intermediate storage
- deployment models
- spam

4.	Recommendations

I recommend that these comments be considered and acted upon before the draft be considered as ready to successfully complete WG last call.


_____
Stephane H. Maes, PhD,
Director of Architecture - Mobile, Oracle Corporation.
Ph: [phone] (mobile/SMS); Fax: [phone]; Office UM: [phone].
e-mail: [e-mail]
IM: shmaes (AIM) or [e-mail] (MSN Messenger)


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Glenn Parsons
Sent: Tuesday, October 19, 2004 3:16 AM
To: '[e-mail]'
Subject: [lemonade] WG last call on Goals


Folks, 
A two week last call period is open until midnight EDT Nov 2nd on: 
   Goals for Internet Messaging to Support Diverse Service Environments    <draft-ietf-lemonade-goals-04.txt> 
Please forward any comments on this document to the WG mailing list. 
Cheers, 
Glenn.



_______________________________________________
lemonade mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/lemonade