Subject: [lemonade] Solicitation for Another Profile Document

From: Eric Burger <[email-masked]>
Date: Fri, 15 Feb 2008 12:32:24 -0500

Question:
In addition to publishing the Lemonade Profile for OMA MEM (Profile-bis),
should the work group publish another document that comprises the entire
lemonade suite, including the bits that are not part of the OMA MEM profile?

[ ] Yes
[ ] No
[ ] Yes, but it is of such low priority that it can wait for the current
work of the work group to complete before we start work on such a document.
As such, we should not add it to our work plan at this time.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: "Stephane H. Maes" <[email-masked]>
Date: Fri, 15 Feb 2008 14:11:50 -0800

_____
Stephane H. Maes, PhD, 
Chief Architect & CTO, Mobility, Voice, and Communications, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Friday, February 15, 2008 9:32 AM
To: [email-masked]
Subject: [lemonade] Solicitation for Another Profile Document

Question:
In addition to publishing the Lemonade Profile for OMA MEM (Profile-bis), should the work group publish another document that comprises the entire lemonade suite, including the bits that are not part of the OMA MEM profile?

[X] Yes
[ ] No
[ ] Yes, but it is of such low priority that it can wait for the current work of the work group to complete before we start work on such a document.
As such, we should not add it to our work plan at this time.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Feb 2008 16:39:48 +0000

>As such, we should not add it to our work plan at this time.
Unless we can identify another set of requirements that we want to 
satisfy with this new document, my answer to this question is No.
However I would like to work on some extra (most likely Intormational) 
documents that describe how these other pieces can be used by clients. 
But I think it takes lower priority at the moment.

---

From: <[email-masked]>
Date: Mon, 18 Feb 2008 13:30:11 +0200

Hi Eric,
I think that a pre-condition is not met: "publishing the Lemonade Profile for OMA MEM"
So, I cannot vote on this.

However, I got the impression that Lemonade will not be able to fulfil all OMA MEM requirements (which is ok). So, the next obvious question to ask is: what are additional "bits that are not part of the OMA MEM profile"? Or, since such document does not exist: what bits and pieces in Your opinion could be part of such future document?

Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Eric Burger
>Sent: 15 February, 2008 19:32
>To: [email-masked]
>In addition to publishing the Lemonade Profile for OMA MEM 
>(Profile-bis), should the work group publish another document 
>that comprises the entire lemonade suite, including the bits 
>that are not part of the OMA MEM profile?
>
>[ ] Yes
>[ ] No
>[ ] Yes, but it is of such low priority that it can wait for 
>the current work of the work group to complete before we start 
>work on such a document.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Feb 2008 12:46:36 +0100

I'm not Eric, but I want to say something, so I do.

[email-masked] writes:
> However, I got the impression that Lemonade will not be able to fulfil 
> all OMA MEM requirements (which is ok). So, the next obvious question 
> to ask is: what are additional "bits that are not part of the OMA MEM 
> profile"?

That's the question, isn't it?

> Or, since such document does not exist: what bits and pieces in Your 
> opinion could be part of such future document?

I know of three things.

1. Locating the IMAP and SMTP/submission servers. (I like and now use 
SRV records. [email-masked] -> _imap._tcp.doma.in and 
_submission._tcp.doma.in.)

2. Mandatory conversion set. I've stated my opinion before.

3. Better error reporting in IMAP. Philip wanted more, it makes sense to 
many of us, and Peter and I have written drafts (independently, solving 
different problems).

Arnt

---

From: <[email-masked]>
Date: Mon, 18 Feb 2008 14:16:04 +0200

Hi Arnt,
there is no problem - this is why I sent it to the mailing list as well.

I have a few comments/questions below.

>From: ext Arnt Gulbrandsen [mailto:[email-masked]] 
>Sent: 18 February, 2008 13:47
>To: [email-masked]
>Cc: [email-masked]; Ordogh Zoltan (Nokia-D-MSW/Tampere)
>Subject: Re: [lemonade] Solicitation for Another Profile Document
>

Indeed. I thought that the OMA MEM requirements were so comprehensive and high level enough that it would be hard to find something that it not covered. Hence my curiosity. There is one thing I learned about OMA: if a said requirement is not provided, someone will complain, but if there is some extra that was not required in the first place, usually a "Is that mandatory? No." kind of conversation takes care of it.

>1. Locating the IMAP and SMTP/submission servers. (I like and 
>now use SRV records. [email-masked] -> _imap._tcp.doma.in and

What does "locating" mean? Could You clarify, please? Set the address of your own servers? Figure out the closest SMTP server?

>2. Mandatory conversion set. I've stated my opinion before.

This could be easily considered as part of the OMA MEM requirements (though it is not explicitly spelled out).

>3. Better error reporting in IMAP. Philip wanted more, it 
>makes sense to many of us, and Peter and I have written drafts 
>(independently, solving different problems).

This could be considered as part of the OMA MEM requirements - reducing traffic and roundtrips (?)
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Feb 2008 12:42:34 +0000

>2. Mandatory conversion set. I've stated my opinion before.
This is likely to be needed for OMA MEM, btw.
But there are good arguments why this should be a separate document.

>many of us, and Peter and I have written drafts (independently, solving 
4. Improved retrieval of basic information about mailboxes (a.k.a. 
STATUS in LIST)

There are also various other bits that may still end up being in the 
Profile Bis:

Stored searches
IMAP URL extension for CONVERTed messages (it was removed from the 
CONVERT draft)
...

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Feb 2008 14:21:48 +0100

[email-masked] writes, answering me:
> I thought that the OMA MEM requirements were so comprehensive and high 
> level enough that it would be hard to find something that it not 
> covered.

Consider CONVERT. I think that lemonadish devices really need 
conversions to only two formats (one small image format and one small 
sound format). Other people on this list have different opinions. None 
of us can point to the MEM and say "OMA agrees with me".

>>>  Or, since such document does not exist: what bits and pieces in 
>>>  Your opinion could be part of such future document?
>>
>> I know of three things.
>>
> What does "locating" mean? Could You clarify, please? Set the address 
> of your own servers? Figure out the closest SMTP server?

Here's a scenario: User NN purchases a new mobile phone which comes with 
a lemonade-capable mail client, a web browser, etc, etc, and btw. Six 
months later, NN purchases a small and expensive new Sony Vaio laptop 
and wants to read mail with it too. So downloads a lemonade-compliant 
mail client to use there.

The question is: How does the new program on the laptop find the IMAP 
and SMTP/submission servers it is supposed to use?

There are various answers to this. I've heard 5-10 different ones from 
people on this list. The extremes are "no can do - only 
vendor-supplied/approved clients are permitted" to "ask the user for 
the email address and use SRV lookups based on the domain part".

> This could be easily considered as part of the OMA MEM requirements 
> (though it is not explicitly spelled out).

Could you spell it out for me, please?

>> 3. Better error reporting in IMAP. Philip wanted more, it makes sense 
>> to many of us, and Peter and I have written drafts (independently, 
>> solving different problems).
>

No, this is mostly about client UI quality, not traffic/rountrips. 
Currently some server errors tend to have very generic client messages 
like "could not delete mailbox". It would be better to support "could 
not delete mailbox because someone is using it at the moment" or "... 
because someone else already deleted it".

Arnt

---

From: <[email-masked]>
Date: Mon, 18 Feb 2008 16:04:23 +0200

>conversions to only two formats (one small image format and 
>one small sound format). Other people on this list have 
>different opinions. None of us can point to the MEM and say 
>"OMA agrees with me".

Well, I think that the problem is the interpretation of the requirement,
not the existence of requirements.
Participating the OMA MEM meetings, it seems obvious that image and
sound conversion only is not enough.

>Here's a scenario: User NN purchases a new mobile phone which 
>comes with a lemonade-capable mail client, a web browser, etc, 
>etc, and btw. Six months later, NN purchases a small and 
>expensive new Sony Vaio laptop and wants to read mail with it 
>too. So downloads a lemonade-compliant mail client to use there.
>
>The question is: How does the new program on the laptop find 
>the IMAP and SMTP/submission servers it is supposed to use?
>
>There are various answers to this. I've heard 5-10 different 
>ones from people on this list. The extremes are "no can do - 
>only vendor-supplied/approved clients are permitted" to "ask 
>the user for the email address and use SRV lookups based on 
>the domain part".

There is a requirement is in OMA MEM, but it's called provisioning
(settings will be there before you use the service) so I think that this
is a good candidate.

>Could you spell it out for me, please?

You mean the relevant OMA MEM requirements?
I quote here the requirements that I think are relevant:
IOP-11	The email enabler MUST support server-side adaptation of
attachment to the device user by user
IOP-12	The server-side adaptation MUST be capable of being controlled
by the client (e.g. with smart or intermediate clients)
IOP-14	Server-side adaptation MUST preserve the ability of accessing
email via other channels (e.g. via other email clients)
IOP-15	Server-side adaptation MUST preserve the original emails and
attachment stored in the email server

Or, you mean how it can be covered?
For minimum interoperability. Two reasons: OMA needs this, otherwise
there is no interoperability test. Market needs this, otherwise nobody
can start a service that would work with the others.

>makes sense 
>Currently some server errors tend to have very generic client 
>messages like "could not delete mailbox". It would be better 
>to support "could not delete mailbox because someone is using 
>it at the moment" or "... 

Ok, this might be a good candidate then. I think that everyone in OMA
assumed that these are implementation issues so there are no
requirements on this (normally protocols can signal error conditions
adequately). Though I think this is something that would serve
everyone's benefit, so I am pretty sure that OMA MEM would not complain
having enhancements in this area - without having requirements for it.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Feb 2008 15:48:06 +0100

[email-masked] writes:
> (settings will be there before you use the service) so I think that 
> this is a good candidate.

Provisioning applies only to the mobile phone NN gets from the service 
provider, not to the Vaio.

(And IMO it's not realistic to tell customers "you cannot read your mail 
with your new Toshiba laptop, only with the device we sold you". RIM 
has succeeded in that, but it's not possible to do it with 
IMAP+SMTP+TLS.)

> You mean the relevant OMA MEM requirements?

That's what I mean. Alexey and I disagree about what's needed, and the 
OMA's document is so general that it covers both of our positions.

Arnt

---

From: <[email-masked]>
Date: Tue, 19 Feb 2008 11:47:19 +0200

Hi Arnt,
please see my responses below.

>Sent: 18 February, 2008 16:48
>To: [email-masked]
>Provisioning applies only to the mobile phone NN gets from the 
>service provider, not to the Vaio.
>
>(And IMO it's not realistic to tell customers "you cannot read 
>your mail with your new Toshiba laptop, only with the device 
>we sold you". RIM has succeeded in that, but it's not possible 
>to do it with 
>IMAP+SMTP+TLS.)

I totally agree with You on these. It is a valid requirement, too, so please communicate it to the OMA DM group.

>That's what I mean. Alexey and I disagree about what's needed, 
>and the OMA's document is so general that it covers both of 
>our positions.

I see. I feel that since Alexey did participate OMA MEM meetings in the past, He has some sort of an advange here.
I suggest that we pick this up as a discussion topic for the upcoming joined meeting - I hope that You can make it there personally and express/discuss Your views and concerns about this topic.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade