Re: LISTEXT to IESG?
Alexey Melnikov <alexey.melnikov@isode.com> Tue, 31 January 2006 11:00 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VB0AUl046488; Tue, 31 Jan 2006 03:00:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VB0Ao3046487; Tue, 31 Jan 2006 03:00:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VB08MD046479 for <ietf-imapext@imc.org>; Tue, 31 Jan 2006 03:00:09 -0800 (PST) (envelope-from alexey.melnikov@isode.com)
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 31 Jan 2006 11:00:05 +0000
Message-ID: <43DF4335.70807@isode.com>
Date: Tue, 31 Jan 2006 11:00:05 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
CC: ietf-imapext@imc.org
Subject: Re: LISTEXT to IESG?
References: <D476564DADC8812608B62197@saturn.watson.ibm.com> <BBED56CE-151E-4594-8103-06488FD671A4@osafoundation.org> <17230.1138224420.107191@peirce.dave.cridland.net> <43D8C8D1.8040509@andrew.cmu.edu> <VIDIexonrQr5W047oeQkaw.md5@libertango.oryx.com>
In-Reply-To: <VIDIexonrQr5W047oeQkaw.md5@libertango.oryx.com>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>
Arnt Gulbrandsen wrote: > The thing that gets me the extended data item syntax. That syntax > seems to be flexibility waiting for a task, hoping to be flexible > enough for whatever the task may turn out to be. In other words, a > solution looking for a problem. Well, I had a similar discussion with Philip and Mark regarding generic syntax defined in draft-melnikov-imap-ext-abnf-08.txt and Marks position is that documents should provide guidance for future extensions. The generic syntax for extensions defined in LIST-EXTENDED is the same as in draft-melnikov-imap-ext-abnf-08.txt. This helps to insure consistency between extensions to different commands and thus can minimize the number of different parsers people have to write. > I'd rather let each future extension define its own syntax, Each future extension should define own syntax which ideally should conform to the generic syntax specified in LIST-EXTENDED ("ideally should conform" because it might turn out that the generic syntax is not flexible enough. However I don't think this is very likely.) > and forbid the server from adding extended data items unsolicited (ie. > striking the third sentence on page 8 of draft -15 Ok, let me talk about this for a bit. The sentence you are referring to reads: The server MAY return data in the extended fields that was not solicited by the client. This sentence might need some clarification. Firstly, there are 2 types of "solicited" fields: fields explicitly requested in the extended LIST command and fields implicitly requested by enabling some feature on the server (I can't think of such LIST field at the moment, but CONDSTORE defines a similar behavior when FETCH MODSEQ items are enabled on SELECT or other condstore-enabling command). Secondly, IMAP has philosophy that any data can send by an IMAP server at any time and an IMAP client MUST be able to cope with that. This "MAY return" refers to this part. In general the server has no reason to return such data, unless it is explicitly or implicitly asked for it. > ). The general syntax could be: > > ... [ SP 1*(extended-data-item-name SP extended-data-item) ] > > The -name would be an nstring, the -item's syntax specified by the > IANA registration of the -name. If a client knows the name, it can > parse the item. If not, it can't. Full stop. > > I know I've muttered about this before. Sorry for sounding like a > broken record.
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: LISTEXT to IESG? Alexey Melnikov
- Re: LISTEXT to IESG? Arnt Gulbrandsen
- Re: LISTEXT to IESG? Arnt Gulbrandsen
- Re: LISTEXT to IESG? Ken Murchison
- Re: LISTEXT to IESG? Arnaud Taddei
- Re: Review of draft-ietf-imapext-list-extensions-… Alexey Melnikov
- Re: LISTEXT to IESG? Dave Cridland
- Re: LISTEXT to IESG? Mark Crispin
- Re: LISTEXT to IESG? Dave Cridland
- LISTEXT to IESG? Lisa Dusseault
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Dave Cridland
- Re: Review of draft-ietf-imapext-list-extensions-… Barry Leiba