Minutes of the IMAPEXT meeting at London

Pete Resnick <presnick@qualcomm.com> Thu, 30 August 2001 14:14 UTC

Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UEEtF03526 for ietf-imapext-bks; Thu, 30 Aug 2001 07:14:55 -0700 (PDT)
Received: from episteme-software.com (champdsl-25.mcleodusa.net [216.43.25.66] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UEErD03522 for <ietf-imapext@imc.org>; Thu, 30 Aug 2001 07:14:54 -0700 (PDT)
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1b1); Thu, 30 Aug 2001 09:14:37 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com (Unverified)
Message-Id: <a05100306b7a18572397e@[216.43.25.67]>
X-Mailer: Eudora [Macintosh version 5.1a1-12.00]
Date: Thu, 30 Aug 2001 09:14:35 -0500
To: minutes@ietf.org
From: Pete Resnick <presnick@qualcomm.com>
Subject: Minutes of the IMAPEXT meeting at London
Cc: IMAP Extensions <ietf-imapext@imc.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>

Minutes of the IMAPEXT Working Group
51st IETF - London

Chair: Pete Resnick
Minutes taker: Lawrence Greenfield (edited by Pete Resnick)

Issues discussed:

1. Access Control List document

Chair notes that the current document editor has been unable to spend 
enough time on it and is therefore handing it off to Alexey Melnikov. 
Alexey will submit a new draft soon accounting for earlier comments 
as possible. Chair will assure that notes taken from a bar-BOF at 
Minneapolis (taken by Chris Newman, we think) will be forwarded to 
Alexey.

2. ANNOTATE document (Cyrus Daboo)

a) Should IMAP flags be mirrored in annotations?

Clearly opposed: Crispin, Nerenberg, Gahrns

- Having two ways to do things is bad with no real benefit
- Additional flags can be done in current protocol which is superior
- Will cause increased complexity (what kinds of responses, do they 
always store to old/new)

Clearly supporting: Resnick, Stebbens

- Clients would prefer to use one mechanism for all annotation-like 
data if it is available
- Easier extensibility
- Features are available that don't exist in base flags (personal v. shared)

Issue to be taken to the list

b) Should there be a suffix default capability (.priv/.shared/nothing)

- List consensus: Explicit statement necessary
- No argument in room

- If system flags are mapped on annotations (see (a)), do they get 
defaults? Room reamined depressed on the matter.

c) Unsolicited annotation responses

- Room agreeds that unsolicited responses are only cache 
invalidations, they aren't the data
- Take to list the issue of whether they should they come only after 
an annotate command has been issued

d) Should the 's' bit be used for "can store private annotations?" 
Should the 'w' bit be used for "can store shared annotations?"

- Greenfield and Daboo debate issue of more bits vs. overloading bits discussed
- Crispin and Resnick agree that since private annotations are 
private to the one storing the annotations and should be stored in 
the space of the annotator, there is no reason for the mailbox owner 
to grant permission for those annotations to exist
- Further discussion indicates that ACL is not where this belongs

3. SORT/THREAD

- IESG has given pushback that some sort of internationalized 
comparison/collation need to exist
- Some folks indicated that a global command that set up 
comaparison/collation for all other commands might not be desirable
- AD (Patrik) indicates that a reasonable default is at least need. 
Unicode technical standard #10 is a good candidate
- Crispin will take two issues to the list: a) What is the default 
comparator? b) What is the correct way of choosing comparators?

4. CONDSTORE

a) MODTIME is currently like ACAP, based off a timestamp
- move it to a 64-bit number, strictly ascending, opaque
- make sure time goes forward if it's used

b) Highest modtime for mailbox added
- Base spec doesn't allow 64-bit numbers in status, but we'll deal.

c) Do we want per message or per flag modtime?
- No opposition to per message.
- No opposition to dropping per flag.

d) Do we need to unify flags & annotations?
- No, but it creates syntax problems.

e) Should we return all items that have changed or just one?
- Alexey wants all.
- Some concerns for servers, but hey, what's a few more comparisons?

5. WINDOW

- Discussion of whether WINDOW/SORT need to move together. Chair 
indicates that extensive cross references aren't needed.

6. LIST extensions

- Greenfield wants to allow "()" at the end of a LIST response to 
allow for extensibility such as referrals or arbitrary status 
information
- Gahrns notes that referrals should be optional

7. BINARY

[Minutes taker notes something was said, but not available]

8. CHANNEL

- Issue is settling down

9. ANNOTATEMORE

So far, no objections

10. LITERAL+/MULTIAPPEND

- Crispin indicates that there are reasons for LITERAL+ that he understands
- Some discussion about whether TRANSACTIONS are necessary, or 
whether they will address some folks concerns in IESG/IAB about the 
complication of the protocol

11. LANGUAGE

Issues brought up:

- server responses
- matching (search/thread)
- collation (sort/list/thread?)
- [annotate]

Some light discussion of going from mUTF-7 to UTF-8

Meeting adjourned.

-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102