RE: [lemonade] WG last call on Goals

[Eric Burger <[e-mail]>]

At this point, my overarching thought is, "some good stuff here, but will it
materially add value or change the goals".

Keep in mind that the IETF does protocols.  The goals document provides a
framework and sets the stage for the protocol.  However, it will have
absolutely no impact on the protocol.  We leave it to groups like OMA and
3GPP to promote mobile services, hack together conventions of IETF standards
for non-Internet usage, and address non-protocol issues such as billing or
payload DRM.  What I'm saying here is that with no disrespect to Kue, unless
there is something glaringly wrong with the document, I would much rather
focus the work group intellectual resources on the protocol documents.

The goals document will not change the world.  The protocol documents will.


On to the comments:

I fully agree with using the term "mobile" instead of "wireless".

I fully agree that if profiling an existing protocol will not meet our
requirements, we will adapt an existing protocol or create a new one.  Note
that by "new protocol", I mean one that targets the problem at hand.  I MUST
EMPHASIZE, this work group is NOT chartered to replace SMTP or IMAP, or make
next generation versions of same.  In addition, we WILL NOT adapt an
existing protocol such that the semantics of the protocol change (the "will
not break existing protocols" mantra).

I agree that we should acknowledge the existence of NAT and firewalls.  We
should state goals that say we should be able to coexist with them.
However, making accommodation for non-Internet deployments is outside the
scope of the IETF.  That means that we will NOT make an attempt to work
around Byzantine enterprise deployments.

On the comments relating to mobile messaging.  We have this thing called
Internet Mail.  Note there is no such thing as Mobile Mail in the IETF.  Our
charter is to make Internet Mail work for mobile devices.  Our charter is
NOT to make Mobile Mail.

My recollection of the discussion at the Interim in Dallas was there was
neither consensus nor disagreement on the P-IMAP goals.  We took them as the
goals of P-IMAP.  Can you be specific as to which goals are missing from the
work group document?

On the client notifications issue, we are NOT CHARTERED to address it.  That
does not mean it will not be addressed.  However, rather than the W3C
approach of boiling the ocean, which requires everything to be done at once,
we take the approach of working on digestible pieces.  Since notifications
are wholly orthogonal to the rest of our work, let's keep this off the
charter until after we get some of the more pressing work done.


Do keep the following in mind:

- Billing, charging, DRM, etc. are for the most part out of scope for the
IETF
- Eliminating SMTP is not a goal
- There is no concept of a corporate e-mail server or service provider
e-mail server.  This is the Internet, where there are e-mail servers.
Either you are part of the infrastructure or you are not.  This is part of
the "Internet Mail" discussion above.
- The IETF for the most part creates protocols that meet the end-to-end
principal.  One result of this is we try to create protocols that do not
REQUIRE intermediaries.  Of course, one is always free to insert
intermediaries if you feel like it.  However, the IETF rarely does
architectures.  A better place to build non-Internet protocols that require
intermediaries is one of the industry fora.

Four pages of comments is excellent!  Good work.

More in-line.

> -----Original Message-----
> From: Stephane H. Maes [mailto:[e-mail]]
> Sent: Monday, October 25, 2004 11:12 PM
> To: [e-mail]
> Cc: Glenn Parsons; [e-mail]
> Subject: RE: [lemonade] WG last call on Goals
> 
> 
> 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-D
raft_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.

Which ones, specifically?

> 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...

Ummm.  Isn't addressing what can't be done today the point of the work
group?


> >> 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 <<=

A bit of politics here: we will never trade-off optimization for
functionality.  Stating a preference for optimization will raise flags that
don't need to be raised.


> >> ... 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.

Yes and yes.


> 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.

See introductory comments.


> 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.

Sounds good.

> 
> 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 

OK for OMA, 3GPP, 3GPP2, but irrelevant for IETF

> -	Challenges
> -	Need to offer an open standard solution that based on 
> enhanced internet mail or at least appropriately interworking with it.

Open standard, INTERNET solution.  If it won't work on the Internet (scale,
interoperability, architecture, security assumptions), then the IETF isn't
the right place to do the work.  We believe we can achieve Internet
robustness and still address the needs of users and operators.  However, if
we violate Internet principles, we won't get very far with the protocols.


> 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-D
raft_Overview_Draft.ppt (slide 2 to 5)).
> 
> Similarly and to avoid confusion, instant messaging should be 
> positioned with respect to the Lemonade goals.

sounds OK.  which challenges in particular?


> 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-D
raft_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...

Out of scope for now.


> 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.

See discussion above.


> 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?

Sounds like a ton of work.  Would it materially impact our work?  If not,
I'd leave it out / unsaid as being way out of our scope of work and our
scope of expertise.


> 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/pptdErK
> weWZk5.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]

If an intermediary is transparent to the protocol, we have nothing to say,
positive or negative.  Let's not say anything.

If an intermediary is key to the protocol, then we need to examine the
protocol closely.
> 
> >>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.

And it will require intermediaries if the source isn't Internet mail, but
something like SMS or MMS.


> >> 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).

Keep in mind we're engineers and not marketing folks.  We all can agree that
today's mobile e-mail is *different* from Internet mail.  I also think most
of us can agree that today's mobile e-mail, because of the nature of mobile
(low bandwidth, high latency, intermittent connectivity), isn't quite the
service that Internet mail offers.

Most people would call that service degradation.  Tell your marketing folks
that we are not bashing mobile messaging.  All we're doing is explaining why
we're undertaking this task in the first place.


> 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-D
raft_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-D
raft_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-D
raft_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

out of charter scope

> - Need to support of firewalls 

acknowledge them and try to work with them

> and associated sometimes very 
> conservative corporate policies

way out of scope.  We aren't in the business of codifying anti-Internet
architectures.  We will do our best to educate the corporate world the
benefits of being part of the Internet.  However, we will not break the
Internet to satisfy the perceived needs of folks not fully implementing real
security.


> - Need to support mobile network limitations (e.g. no 
> session, often disconnected, no fixed IP, non-internet 
> features / capabilities / limitations)

Yep


> - Mobile deployment models 
> (http://www1.ietf.org/mail-archive/web/lemonade/current/pptdEr
> KweWZk5.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/pptdErK
> weWZk5.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.

Way too late for this.  The charter is the charter.  The work group chairs
are not up to that battle at this time.  We can re-address this issue once
we make significant progress on our current document set.


> 
> 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, .)

Out of scope.


> 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

Do you have text for these issues?


Thanks again for your close look at this document!

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