[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MORG] MORG notes from IETF 74
Title: MORG notes from IETF 74
Here are my own notes from the MORG session.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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