Last Modified: 2005-02-02
| Done | Submit revised Sorting/Threading/Viewing spec(s) to IESG | |
| Done | Submit draft on conditional storage to help multiple clients use a single mailbox to IESG | |
| Aug 04 | WG last call for i18n draft | |
| Aug 04 | WG Last call for annotate draft | |
| Aug 04 | WG last call for LIST extensions draft, defining syntax allowing much better extensibility in the frequently-extended LIST command, and supporting other drafts in this WG | |
| Sep 04 | Submit to IESG, Internationalization draft | |
| Sep 04 | Submit to IESG, revised annotate draft | |
| Oct 04 | Submit to IESG, revised List Extensions draft | |
| Done | Submit I-D to *update* existing ACL RFC, explaining rights & listing rights in CAPABILITY response | |
| Oct 04 | New draft of ACL2 proposal which would *obsolete* existing ACL RFC | |
| Feb 05 | ACL2 to WG Last Call -- note that if this milestone is not met we agreed to close the WG and defer ACL2 to another WG |
|
IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.
These minutes are based off the Jabber log, available here: http://www.xmpp.org/ietf-logs/imapext@ietf.xmpp.org/2005-03-10.htm Administrivia: Chairs welcomed the members to the IMAPEXT variety show. The agenda was bashed. 2086upd [draft-ietf-imapext-2086upd-03.txt]: - Chair summarized that people have been reviewing the document, things are looking good and we're almost done. - Cyrus sent a large number of comments to the list this morning that were mostly minor nits. - Room consensus that no comments had invalidated last call, and we can move forward. ANNOTATE [draft-ietf-imapext-annotate-12.txt]: - Brief discussion about how references when replacing a document work (you don't have to reference a document you are obsoleting) - Lisa summarized Cyrus's recent changed for the room. - Use of UTF-8 for values: rough consensus for 'SHOULD' instead of 'MUST' - Discussion of open issues: - Should servers validate the syntax of the content-type value? Yes. (but should not have to validate that the actual content-type is correct). - We should reference RFC2046 for their content-type syntax. - Should entity registrations contain a default content-type value? - Other questions included: "Should entries be forced to a particular content type?" No - IANA registration will contain a recommended content-type value. - Can values contain binary data? Can we use the literal8 syntax from BINARY? - Alternate ideas included tagging to indicate that a binary response was desired. (experience from LDAP indicated this was tricky to get right) - Desire to not require BINARY extension, just the syntax. - Desire to move literal8 syntax to the common syntax document. - Rough consensus to use literal8 syntax for all ANNOTATE literals, but no modifications for regular strings. - Rough consensus to move literal8 syntax to the syntax document (out of BINARY). - How to deal with hierarchy levels named 'shared' and 'priv'? - Ambiguity on first hierarchy level. - Rough consensus to just deny them on all levels. - UTF-8 entry/attribute names - We need stringprep for comparisons if they stay UTF-8 - Recent lunch BOF proposal to restrict to US-ASCII and have another attribute for UTF-8 display name. - Additionally, clients are not required to use the display name for presentation if they choose not to. - Really, the display name attribute would only be necessary for custom entries (for standard entries, clients could know how they are used). - Point that we will need stringprep for mailbox names eventually anyway. (but this is likely a different stringprep profile). - Observation that mailbox names aren't registered, its much nicer to be able to just register US-ASCII names. - Rough consensus to restrict entry and attribute names to US-ASCII, and include a UTF-8 displayname attribute. - Interaction with CATENATE syntax (for APPEND), since the CATENATE draft is now APPEND-only. Should we just reference the syntax draft? - Rough consensus: Yes. - Side discussion about making Alexey's syntax draft an official WG item. Rough consensus to decide after seeing it (Alexey promises to be quick with updates). - ANNOTATEMORE interaction: there are large blocks of shared text that should now be updated in both places. LISTEXT [draft-ietf-imapext-list-extensions-11.txt]: - Philip summarized the changes to LISTEXT proposed at the interim and subsequent list discussion, the main problem being that LIST responses cannot rely on the context of the command that prompted them. - Solution: move lots of this into CHILDINFO. - Discussion of possible difference in behavior with current RLIST and the \Remote flag (currently a server does not need to actually declare what mailboxes are remote and which ones aren't). This could cause problems for some type of proxies that choose to refer based on if the clients send an RLIST or not. - Probably not a problem, since LIST flags can change at any time, really.. - Issue: The current ABNF is very complex, can it be simplified? - Observation: some of the syntax is performing validation that is really semantic in nature. - Cyrus offered to take a look and suggest text/new ABNF. - Chair asked authors of LISTEXT to propose strawman for open issues in the next document, continuing to have open issues will just delay the group. - Authors asked that members who disagree with the strawman propose alternates. Comparator (not a WG item) [draft-newman-i18n-comparator-03.txt]: - We have several items that depend on this. - Chris tried to find another author, and failed. He will continue to try to find someone else to work on it, but will also commit some cycles near term. - Chris is currently interrupt driven, and asks to be pinged. ACL2 & Working Group Future: - In San Diego we agreed to drop ACL2 if there had been no progress by this meeting. There hasn't been progress on ACL2, but there has been substantial other progress. Chair asks if we want to extend our deadline given this (and adjust charter dates). - Scott (AD) is ok with this. - Rough consensus to revisit ACL2 in 6 months. - Members should watch the LEMONADE group for some of their encrypted/signed message issues. IMAPEXT (or at least its members) should be involved in a deep way. i18n Document [draft-ietf-imapext-i18n-04.txt]: - Chris asks if we can simplify the use of comparators in the search program so that one comparator could be used for the entire program. - Example use case: search for case-sensitive local part and case-insensitive domain part of an address. - Point that we could accomplish most of the usefulness of this with the ability to search within results. - Rough consensus to simplify in this way, and allow for a future extension to do the recursive search. Chris will send a message to Arnt and the list. |
None received.