RE: [lemonade] METADATA use by Lemonade Profile Bis and suggestedsimplifications

<Zoltan.Ordogh@nokia.com> Mon, 21 January 2008 12:37 UTC

Return-path: <lemonade-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvu7-0005wA-Fs; Mon, 21 Jan 2008 07:37:31 -0500
Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGvu6-0005vz-EJ for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 07:37:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvu6-0005vr-4d for lemonade@ietf.org; Mon, 21 Jan 2008 07:37:30 -0500
Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGvu4-0003iK-Im for lemonade@ietf.org; Mon, 21 Jan 2008 07:37:30 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0LCbJWH005401; Mon, 21 Jan 2008 14:37:26 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:37:25 +0200
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:37:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] METADATA use by Lemonade Profile Bis and suggestedsimplifications
Date: Mon, 21 Jan 2008 14:37:32 +0200
Message-ID: <D11B1A8C0C8D64419879CA3C931F95E5A787A2@esebe199.NOE.Nokia.com>
In-Reply-To: <47691CC8.7020903@isode.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: [lemonade] METADATA use by Lemonade Profile Bis and suggestedsimplifications
Thread-Index: AchCQ0dzpa7WMkBAQcaat/vLMIFhbQZ4LJ+Q
References: <47691CC8.7020903@isode.com>
From: Zoltan.Ordogh@nokia.com
To: alexey.melnikov@isode.com, lemonade@ietf.org
X-OriginalArrivalTime: 21 Jan 2008 12:37:26.0077 (UTC) FILETIME=[60B2C6D0:01C85C2A]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc:
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Hi all,
please excuse my late reply on this thread - I was on vacation and I have a long backlog to process.
I have read all replies to this thread to date.

First, I would like to respond to Alexey: You mention per-user and per-mailbox METADATA. I am missing one thing from the list: per-client METADATA. For that matter, I guess we still need to identify clients somehow.

Second, for the METADATA doubters:
What is your actual concern? METADATA itself, or having one more IMAP extension?

If the concern is METADATA, please express all your concerns so that they can be addressed in the draft. METADATA might not be right, but it is in our power to make it right - or, if it's that bad, create something else that does the job.

If the concern is having yet another IMAP extension: IMAP was created to be extensible - I do not see any restrictions in the IMAP specifications. We can't dismiss new features because "there are so many IMAP extensions already" - this is not a basis for argument.
Also, I would like to point out that we do have requirements in OMA to optimize network usage. In a mobile environment it is not very efficient to open up (and keep open) a separate connection with every single IMAP connection just to manage settings (and to notify/get the updates when some other client or the administrator changes them). I do not think that yet another extension is such a big deal when it is compared to saving resources - if it is, we could make it part of Profile bis specification instead, so that it is not necessary to have yet another extension.

Any thoughts?

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

 

>-----Original Message-----
>From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com] 
>Sent: 19 December, 2007 15:30
>To: Lemonade WG
>Subject: [lemonade] METADATA use by Lemonade Profile Bis and 
>suggestedsimplifications
>
>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
>lemonade@ietf.org
>https://www1.ietf.org/mailman/listinfo/lemonade
>Supplemental Web Site:
>http://www.standardstrack.com/ietf/lemonade
>


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade