[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
imapext minutes from IETF-62 [DRAFT]
Let me know your comments, I'll send this on to minutes@xxxxxxxx probably
IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.
These minutes are based off the Jabber log, available here:
Chairs welcomed the members to the IMAPEXT variety show. The agenda was
- 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
- 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
- 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
- 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
- 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
- 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
- ANNOTATEMORE interaction: there are large blocks of shared text that
should now be updated in both places.
- 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,
- 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
- Authors asked that members who disagree with the strawman propose
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
- 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.
Rob Siemborski | PGP:0x5CE32FCC | rjs3@xxxxxxxxxxxxxx
-----BEGIN GEEK CODE BLOCK----
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----