Re: LISTEXT to IESG?

[Alexey Melnikov <alexey.melnikov@xxxxxxxxx>]

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.