2.1.7 Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-16

Chair(s):
Pete Resnick <presnick@qualcomm.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Mailing Lists:
General Discussion: ietf-imapext@imc.org
To Subscribe: ietf-imapext-request@imc.org
Archive: http://www.imc.org/ietf-imapext/
Description of Working Group:
The IETF IMAP extensions Working Group shall revise and publish standards-track extensions to IMAP4 for performing the following functions:

1. Sorting, threading, and viewing (to be dealt with by one or more mechanisms)

2. Access Control Lists

3. Message-level annotations

Revising the base IMAP4rev1 specification is out of the scope of this WG. However, this WG will ensure that whatever extensions it does propose do not worsen any existing problems in the base specification of IMAP, nor do they make any such problems harder to address in the future.

Goals and Milestones:
May 00  Submit an Internet-Draft enumerating known problems to avoid in the base specification
Aug 00  Submit revised Sorting/Threading/Viewing spec(s) to IESG
Nov 00  Submit annotation spec to IESG
Mar 01  Submit revised ACL spec to IESG
Internet-Drafts:
  • - draft-ietf-imapext-sort-13.txt
  • - draft-ietf-imapext-acl-09.txt
  • - draft-ietf-imapext-annotate-08.txt
  • - draft-ietf-imapext-list-extensions-04.txt
  • - draft-ietf-imapext-condstore-04.txt
  • - draft-ietf-imapext-i18n-00.txt
  • No Request For Comments

    Current Meeting Report

    eoprivIMAPEXT WG minutes
    
    document status:
    - ANNOTATE: ready for list last-call
    - ANNOTATEMORE: one issue
    - SORT/THREAD: submitted to IESG, blocked on Chris's i18n draft
      - Ted will bump status and ping Ned
    - LISTEXT: chair to ping Barry to unstick draft and get it into WG last 
    call
    - ACL2: many issues still being worked out
    - CONDSTORE: - Alexey to submit updated draft that resolves issue from AD 
    review
    - lemonade stuff:
      - COMPOSE: ain't written
      - URLAUTH: will get pushed further, probably one or two more revs
      - CHANNEL: in limbo
        - Pete thinks his mailto: text should be stripped
    - initial-response for SASL: Rob asks for review, a couple impls so far
    - i18n: Chris to update draft per discussion below
    
    
    discussion:
    - ANNOTATEMORE
      - how to handle partial failure when changing multiple mailboxes
        1) require rollback
        2) allow partial failure/success
        3) don't allow multiple mailbox changes
      - Alexey noted that ACL2 behavior in similar case is #2
      - example of an annotation to apply to a hierarchy: setting the 
    sort/thread type on all mailboxes beneath your 'list' folder
      - since creating a new mailbox doesn't result in the mailbox 
    inheriting annotations from its parent, clients already have to 
    implement search up tree
      - consensus is to disallow multiple mailbox setannotation
      - Crispin asked for more impl advice: how should a client fake 
    annotations when working with a server that doesn't support them?  (that 
    advice should help servers that use legacy mailbox formats)
    - ACL2
      - issue: how to express the acl models in use
        - query: webdav acl rfc status?
          - passed IESG, but with both security ADs abstaining(!)
          - now, in rfc-editor queue, last draft was #12
          - servers can advertise all sorts of mappings and tieing of rights 
    that vary, with result that clients just end up presenting results to the 
    user; automated clients suffer
        - main question is how a client can predict results when making a 
    change
        - Marc reiterates Cyrus's comment about GUI interface exposing just 
    simple bits
        - Klensin disagrees: in enterprises you do need fine-grained control
      - chair: specific open issues and comments?  no, so take it to the list
    - i18n
      - revised comparator draft
        - various tweaks to format and wording
        - registration template is now XML and its URL is part of standard
          - Ted Hardie: concern about putting requirements on IANA, in 
    particular guarantees of stability.  On the otherhand, DDDS and URNs *can* be 
    guaranteed; can we do those or perhaps push stability requirement onto W3C?
            - Michael Meeling's doc on XML namespaces as example, ditto 
    provreg
      - upcoming changes
        - reference to Unicode Consortium doc on tailoring
        - review by W3C and Unicode Consortium
      - open issues
        - nameprep processing for basic collation?
          - no, just use straight unicode collation, no IETF-specific 
    processing
        - way to download unicode collation 
    customizations/tailoring
          - may do if a stable spec for format et al can be found
      - IMAP i18n changes and open issues
        - add examples
        - not going to add command to fetch lookup table
        - Cyrus: capability for comparator only to be displayed after 
    entering authenticated state.  Why?
          - default can change
            - advertising default via capability (vs a separate 
    unsolicited response) seems...odd...
    - lemonade
      - COMPOSE
        - to work as an append that can take pieces from the currently 
    selected mailbox
        - looking to address simple case of composing simple forwards, not 
    grand unified document building
      - URLAUTH
        - request for feedback
        - "we [imapext] may be nuts, but some [lemonade] people really are 
    crazy"
        - contention: URLAUTH is useful outside of lemonade
          - "are [the authors] under the belief that it [the URL 
    authorization bits] apply to other schemas, because they don't"
          - why are they linking the location identifier and the 
    authorization token?
            - want to use urlauth to publicly export data too
              - "use of IMAP as general purpose object access protocol is 
    unwise"
            - conflating location and identification has costs as well as 
    benefits
            - imap-url spec is old and is poorly deployed
              - partly because you need a mostly full imap client
            - complete fine-grained access vs broad strokes?
        - result: study of use cases needs more study?  More to happen on 

    Slides

    None received.