Subject: [lemonade] METADATA use by Lemonade Profile Bis and suggested simplifications

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 13:29:44 +0000

One of the goals of Lemonade Profile Bis is to try to satisfy majority 
of OMA MEM requirements.
Recently Zoltan and I (with some help with Dave Cridland) went through 
OMA MEM requirements trying to figure out how they can be mapped to 
Lemonade (and/or Sieve). My personal belief is that multiple 
requirements can be satisfied by IMAP METADATA extension (or ACAP, but I 
am not going to go into this discussion here). Here is an incomplete 
list of the corresponding OMA MEM requirements (some of them also need 
Sieve and Sieve Metadata extension):

ADMIN-1: It MUST be possible to provision the mobile email client, based 
on any combination of who the user is and what the device is.
ADMIN-4: Authorized principals MUST be able to configure the settings of 
the user preferences/filters/configurable settings for a particular user
ADMIN-7: It MUST be possible for a user to view, edit and reset settings 
of a mobile email client
USAB-11: The mobile email enabler MUST support:
      Different methods for notifying the client about new emails based 
on capabilities of the network
      The ability for the user to select the transport method based on 
the capabilities of the client and network (e.g. SMS, Push, MMS etc)
      The ability for the user to select if, when and how events are 
accessed by the client
USAB-16: Authorized principals MUST be able to select the ways that 
email events are sent to or accessed by the mobile email client and 
other email settings that may affect the server behaviour
USAB-28: The mobile email enabler SHOULD support activation/deactivation 
of auto-reply from the client. Automatically generated replies SHOULD 
avoid mail loops (RFC 2821 and related RFCs)

After looking at this list Dave and I agreed that there doesn't seem to 
be any requirement to use per-mailbox metadata, per-user metadata seems 
to be sufficient. So I would like to propose that the METADATA extension 
is split into 2 separate extensions: per-user METADATA and per-mailbox 
METADATA. I would also like to propose that only the former extension is 
included into Lemonade Profile Bis.

Per-user metadata extensions is relatively easy to implement: it would 
only consist of GETMETADATA command (with mailbox parameter being ""), 
GETMETADATA response and SETMETADATA command, it doesn't depend on 
LIST-EXTENDED. Support for the COMPARATOR extension can be made optional.

Opinions?

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Curtis King <[email-masked]>
Date: Wed, 19 Dec 2007 10:48:19 -0700

On 19-Dec-07, at 6:29 AM, Alexey Melnikov wrote:

> ADMIN-1: It MUST be possible to provision the mobile email client,  
> based on any combination of who the user is and what the device is.
> ADMIN-4: Authorized principals MUST be able to configure the  
> settings of the user preferences/filters/configurable settings for a  
> particular user
> ADMIN-7: It MUST be possible for a user to view, edit and reset  
> settings of a mobile email client
>     Different methods for notifying the client about new emails  
> based on capabilities of the network
> USAB-28: The mobile email enabler SHOULD support activation/ 
> deactivation of auto-reply from the client. Automatically generated  
> replies SHOULD avoid mail loops (RFC 2821 and related RFCs)

These are valid problems to solve but have nothing to-do with IMAP.  
They should be solved using an other protocol for example ACAP, LDAP  
or LACAP. Pushing everything into IMAP is wrong and needs to stop, as  
IMAP is coming complex enough just solving the core problem of pushing  
email to a mobile client.

I have no problem with expanding lemonade to include mobile  
configuration, so OMA MEM keeps one contact group within IETF.

ck

---

From: Ned Freed <[email-masked]>
Date: Wed, 19 Dec 2007 09:56:02 -0800 (PST)

> These are valid problems to solve but have nothing to-do with IMAP.

More to the point, while the group isn't constrained to only extend IMAP, these
things are pretty clearly outside the current group's charter and deliverables.

> email to a mobile client.

Agreed.

> configuration, so OMA MEM keeps one contact group within IETF.

That would either require that we recharter or else create a new group. If this
sort of thing is to done in the IETF I'd prefer having a new group do it.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Dec 2007 13:07:43 -0500

Hi Curtis,

--On December 19, 2007 10:48:19 AM -0700 Curtis King <[email-masked]> wrote:

> These are valid problems to solve but have nothing to-do with IMAP. They
> should be solved using an other protocol for example ACAP, LDAP or LACAP.
> Pushing everything into IMAP is wrong and needs to stop, as IMAP is
> coming complex enough just solving the core problem of pushing email to a
> mobile client.
>

We don't need to do much on this. A solution already exists in the form of 
XCAP which at least SIP-based mobile devices are likely to be supporting.

-- 
Cyrus Daboo

---

From: "Darryl Champagne" <[email-masked]>
Date: Wed, 19 Dec 2007 13:10:49 -0500

> -----Original Message-----
> From: Curtis King [mailto:[email-masked]]
> 
..
> > based on any combination of who the user is and what the device is.
..
> configuration, so OMA MEM keeps one contact group within IETF.

It's also worth remembering that OMA already has a provisioning/Device
Management specification/Enabler, DM, which is deployed on 95+% of the
handsets produced this year ***.

Thus an easy way for OMA-MEM to support provisioning (and various other
settings) is by specifying just the data to configure on the handset (a DM
Management object).  The DM Working Group also has guidelines on creating
management objects available.

Having yet another way to change configuration settings seems of marginal
value - especially since you will not be able to specify the address of the
email server via IMAP no matter what goes in, whereas operators will
configure handsets via DM to access their own servers, and frequently
provide Web UIs of their own to revise settings.

Dgc

*** Based on poll including manufacturers producing 700 million handsets,
summary available at
http://member.openmobilealliance.org/ftp/TP/2007london/OMAWorldPresentation2
007.zip for OMA Members, public versions to follow in a week or so on the
OMA website.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 18:24:14 +0000

> These are valid problems to solve but have nothing to-do with IMAP.

I almost agree with you. Almost, because support for virtual views is 
missing one small piece, which is storing search filters on IMAP server 
(draft-melnikov-imapext-filters-02.txt). This piece currently depends on 
per-user METADATA.

> IMAP is coming complex enough just solving the core problem of 
> pushing  email to a mobile client.

---

From: Curtis King <[email-masked]>
Date: Wed, 19 Dec 2007 11:26:20 -0700

On 19-Dec-07, at 11:24 AM, Alexey Melnikov wrote:

>
> I almost agree with you. Almost, because support for virtual views  
> is missing one small piece, which is storing search filters on IMAP  
> server (draft-melnikov-imapext-filters-02.txt). This piece currently  
> depends on per-user METADATA.

Which it shouldn't.

ck

---

From: Dan Karp <[email-masked]>
Date: Wed, 19 Dec 2007 11:06:11 -0800 (PST)

> > depends on per-user METADATA.

+1

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 19:12:16 +0000

>>>depends on per-user METADATA.
Am I correct in interpreting that as:
1). People would like to make draft-melnikov-imapext-filters independent 
of METADATA (so that it can be used with METADATA, ACAP, LDAP, XCAP, 
whatever)
2). People would like to include draft-melnikov-imapext-filters (after 
it is updated as described in 1) into Profile Bis, because they agree it 
is a missing piece?

---

From: Dan Karp <[email-masked]>
Date: Wed, 19 Dec 2007 11:18:16 -0800 (PST)

> of METADATA (so that it can be used with METADATA, ACAP, LDAP, XCAP, 

Yes.  I'd think it'd make more sense as an extension to CONTEXT=SEARCH.

> it is updated as described in 1) into Profile Bis, because they agree it 

No.  I don't see a screaming need for it in Lemonade.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 19:25:10 +0000

Dan Karp wrote:

>Yes.
Ok.

>I'd think it'd make more sense as an extension to CONTEXT=SEARCH.
>  
>
It is a syntactically independent extension and can be used in a regular 
SEARCH.

>No.  I don't see a screaming need for it in Lemonade.
As a server guy and as an author of the document I am not really allowed 
to have an opinion ;-).
I can only proxy Roger Grönberg from Momail on this. He requested this 
functionality during the Lemonade interop in Munich.
(And I've already mentioned the OMA MEM requirement)

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Dec 2007 20:16:21 +0000

> > These are valid problems to solve but have nothing to-do with  

(Agreed)

> > email to a mobile client.

(Agreed, although s/mobile/restricted/)

> > configuration, so OMA MEM keeps one contact group within IETF.

If another WG were setup to handle this, then Lemonade would be the  
logical place to put those peices into the form of a support package  
for diverse environments. It'd be effectively similar to IMAPEXT's  
development of CONDSTORE et al.

> handsets produced this year ***.

Use of DM would essentially isolate the mobile world from the  
desktop. So settings made on a desktop cleint wouldn't propogate to  
the mobile device. I've seen the effect this facility has on people  
first hand - people are impressed with the concept that they  
configure their desktop client and the mobile device client follows  
suite.

I'm also less than convinced by XCAP - it requires SIP to be by any  
reasonable definition "useful", and mandating SIP in every MUA is  
just not going to happen.

Of course, I'm biased, I've used ACAP for these purposes for years  
now, but I didn't pick that technology because it had a cool name,  
nor have I stuck with it out of some weird sense of pride.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Dec 2007 15:48:55 -0500

Hi Dave,

--On December 19, 2007 8:16:21 PM +0000 Dave Cridland <[email-masked]> 
wrote:

> reasonable definition "useful", and mandating SIP in every MUA is just
> not going to happen.
>
> Of course, I'm biased, I've used ACAP for these purposes for years now,
> but I didn't pick that technology because it had a cool name, nor have I
> stuck with it out of some weird sense of pride.

My feeling is XCAP will work just fine and there really is no absolute 
requirement on implementing SIP. XCAP would be an order of magnitude more 
easy to implement on both clients and servers, but then again it does not 
attempt to address all the bells and whistles that ACAP does. But I believe 
it would be sufficient for the key requirements we would have.

-- 
Cyrus Daboo