[MORG] MORG notes from IETF 74

[Randall Gellens <[e-mail]>]

MORG notes from IETF 74

Here are my own notes from the MORG session.

• STATUS in LIST

• Barry asks if there is real demand for this, specifically, who will implement it?  Four server people in the room say they will, some client people (one via Jabber) say they will.
• Discussion regarding failure case (server can't return status for some requested mailboxes).
• Barry, Chris, and Alexey prefer choice #2.

• Sort display

• Open issue: Should there be a DISPLAYTO sort-key and how should it work?
• Alexey wants it, e.g., in a "sent items" folder where everything is from the user so sorting by "From" is meaningless, but sorting by "To" is useful.

• INTHREAD

• Open issue: How to encode Message-ID?
• Discussion if this needs to be a WG item; usability of extension.
• Barry says this is clearly usable, but questions as to who will implement.  Only two of the server vendors present say they will or have implemented, no client people say so.
• Discussion on THREAD=REFS compared to rest.  Barry questions need for in-thread SEARCH.
• Cyrus notes that this is most useful for webmail clients, most of which use c-client as base, so if c-client won't implement, then this won't be used.
• Chris notes that he has a webmail implementation that doesn't use c-client.
• Status: open question as to real need for this; Randy suggests leaving draft as low-priority until there's demonstrated need for it.
• Alexey notes that first part of this extension adds new basic IMAP syntax, which breaks many generic IMAP parsers (which tokenize into strings, atoms, etc.); Alexey suggests using STRING.
• Barry agrees and says that Message-ID should be treated as a blob and not parsed.
• Consensus in room to go with last option on slide

• Address Search

• ANY field (list of many headers to search) -- should server be allowed to search additional headers?
• Alexey suggests MUST search listed fields, MAY search others.
• Discussion as to possible user confusion if server says there is a match but matching header isn't clear
• Barry and Arnt prefer option 1A (just RFC5322).
• I suggest that there isn't an interoperability harm to server searching extra headers.
• Discussion of headers such as List-Unsubscribe: nonsense if this is searched.
• Barry suggests 5322 only or 5322+server choice.
• Cyrus suggests we be very explicit here, and do the fuzzy search in fuzzy search extension.
• Consensus for this.
• Discussion on searching arbitrary headers.  Some support for this.
• Question on searching address headers in nested body parts.
• Some agreement that this is useful (e.g., forwarded messages, multipart/digest) .
• Discussion on server MAY or MUST, and on client option.
• Tony likes having a client option.
• I suggest that a client option is the most complex choice, since the server MUST then implement everything, and with conditional code paths, and further the client needs to choose, but without any clear basis for doing so.
• Cyrus wonders what the user interface would look like to control this.
• Cyrus suggests making this extension search top-level only, and doing a new extension for nested body parts.
• Consensus call to go with this choice.
• Open issue: fallback or not.
• Suggestion to leave it up to editor.  No one cares much.

• Fuzzy Search

• A few people had read the draft (posted a few days ago).
• Question on handling of non-string matching data.
• Barry says fuzzy search means it is up to the server, so this choice is left up to the server.
• Alexey asks about fuzzy date searching. (Looking for "recent" message, time zone boundaries, etc.)
• Consensus that fuzzy means server chooses.
• Alexey suggests draft include examples of this to make it more clear.
• Randy suggests that if we do fuzzy, it means searcher choice, and if we want to specify everything then it isn't fuzzy.
• Consensus to move forward  with fuzzy search.
• Chris reiterates need for lots of examples and informative text regarding what's helpful and what's not.
• Question on returning relevancy scores.  Is this useful?
• Barry suggests standardizing the range (0-100).
• Chris says we have some experience that scores in the 0-100 range are useful; displayed as percentage; users seem to handle it.  Google, e.g., shows scores.
• Consensus that servers return relevancy scores (probably 0-100) and the document needs text to say that scores from different servers can't be correlated.
• Barry and Cryus note that server can choose how to normalize internal values.
• Question on returning relevancy without fuzzy search.  No one does.

• Collations/Comparators

• Ned proposed space-ignore
• proposal for non-case-mapping unicode comparitor
• Alexey added two numeric comparators: signed numeric and ignore leading white space.
• Barry asks about one that ignores separators, and one that recognizes decimals (including national differences).
• I note that even if the user knows what he uses, he doesn't know what the author of an email may have used, so will need to search all possibilities (US, European, etc.)
• Chris asks which server implementers want to do this.  Three raise their hands.  Chris asks for client people.  No one raises their hands.
• Zoltan says most useful search is phone numbers, and this doesn't do that.
• Discussion that this is more useful in Sieve (which doesn't currently permit signed numbers).
• No enthusiasm for i-ascii-signed-numeric but Alexey suggests leaving it for now and we can discuss on list and abandon later.
• i-ascii-punc-ignore-numeric
• Cyrus asks if digits on either side of comma followed by whitespace should be treated as one number or two.
• Chris says we should look at use cases first, and only if we have a clear use case that needs a comparator do we create one; this is creating comparators first.
• Ned's proposed space ignoring comparator (e.g., Japanese texts).
• Case-sensitive version of i;unicode-casemap -- Barry and Pete suggest we don't know what this means.
• Consensus that only space-ignore is clearly needed.  Chris or Ned will take on editorship.

• Multi-Mailbox SEARCH

• Can't pipeline SEARCH since untagged search responses are indistinguishable.
• Proposed extension tags search results, runs in authenticated, non-selected state, always returns UIDs.
• Options for wildcards and depth limit; allows for future extension for result option; one ESEARCH response per mailbox with hits.
• Discussion on new CAPABILITY for server to report that it executes pipelined commands in parallel.
• Discussion on wildcards.  Use LIST syntax or NOTIFY syntax?  NOTIFY uses subtree.  Several people voice support for this, no one argues against it.
• Discussion on depth limit.  What should be used by default?  Should default be specified or left to server?  Support for saying client MUST specify depth.
• Barry notes that some IMAP implementations can have loops in hierarchy, and that some implementations loop infinitely on SEARCH.  Chris suggests making depth 0, 1, or infinitely, and adding text that infinity means that the server searches each mailbox once.
• Discussion on security considerations.  Barry notes ACL.  Chris suggests shared mailboxes could be used for force spam into search results by owner of shared mailbox.  Chris wonders about a parameter that says search only user's own mailboxes (no shared).  Cyrus says you can use metadata to tag mailboxes you don't want to search, and use search criteria to exclude them.
• Suggestions to add EXCLUDE clause (with a nested search criteria).
• Suggestions to use metadata tags to mark those mailboxes that you want to search (to not

• VIEW vs Multi-Mailbox Search

• Timo asks if anyone besides him is interested in VIEW.
• Barry says VIEW was attractive but a big rat-hole.
• Much debate regarding how to return or limit large results.

-- 

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The whole problem with the world is that fools and fanatics are always
so certain of themselves, but wiser people so full of doubts.
                                                   --Bertrand Russell