[MORG] draft scribe notes from meeting

[Chris Newman <Chris.Newman at Sun.COM>]

MORG WG -- IETF 74 -- San Francisco -- 2009-03-27

Scribe: Chris Newman
Jabber Scribe: Cyrus Daboo

Status-in-List Slides

open issue slide 1:

Barry: Who in room is doing servers?  Will you all implement this?
* Multiple server implementers in room, all interested in implementing this.

Barry: Who in the room is doing clients?
* Only one in room, but intends to implement it.  One other client guy
 (not in room interested) interested.

Arnt: "Roundqueue" implementation that sends _lots_ of STATUS (see jabber 
room).

Barry: NO is not right answer.  Prefer #2 bullet from slide.
Alexey: +1 (as contributor)
Chris: +1

** Rough consensus for option 2.

Sort display open issue slide 2 (DISPLAYTO):

Alexey: think we need DISPLAYTO.

Barry: thought "use first address" was resolved on list.

** Rough consensus for both points.

slide 3 (INTHREAD):

Open issue: should we do it?

Barry: who is likely to implement it?
2 of 4 server implementers
0 client implementers

Cyrus & Barry discuss THREAD=REFS vs. THREAD=REFERENCES

Discussion of impact that c-client likely won't implement this.

** Chair (Randy): This appears to be a lower priority draft due to lack of 
implementer interest.

Open issue: how to encode Message-ID?

Alexey: needs to be quoted.  Having angle brackets ugly but not a big deal.
Barry: prefers treating msgid as blob
Timo: heard from Arnt via email that it should be treated as blob.

** Rough consensus for last option.

Address search

Discussion.
Cyrus: suggest we be very explicit here (1a), allow fuzzy search to go 
further

** Rough consensus for Cyrus proposal

Alexey: If somebody says SEARCH DOMAIN or SEARCH ADDRESS and list header 
not mentioned in RFC 5322.  Is this an error or should this succeed?

Timo & Alexey prefer it succeeds.

Address search and non-toplevel messages?

Base spec states next to nothing on topic.
Long discussion.
Cyrus: for now leave it top-level only.  We can always do extension later 
to traverse structure.

**Rough consensus for option a.

Address search and fallbacks or not?

**Leave to editor's discretion.

Fuzzy search non-string criteria

Servers can do what they want, but interpret it in a useful way.

** Rough consensus

Fuzzy search relevancy scores

Discussion result: Have server normalize 0-100 primarily for result 
sorting.  Informative note servers may weight or normalize in arbitrary 
ways but should be cognizant of UI impact.

Fuzzy search: relevancy & fuzzy linked

Keep them together.

ascii-signed-numeric

No objections, but seems low priority / limited support

ascii-punc-ignore-numeric

Needs new name, need to ignore parens, currency symbols?
Cyrus: should ", " be separator between numbers, while "," is ignored.
Chris: would like to look at use cases and build collators that fit them.

Other comparators

* Space ignoring comparator (e.g., for Japanese text)
 strong support
 either Ned or Chris will own this work item.
* Case sensitive version of i;unicode-casemap?
 might want to focus on i;basic instead
 limited support

Need to discuss interaction of fuzzy search and collators on list.

Multi-mailbox search

Chris: relevancy: what order to present results.  Could use with fuzzy.

List wildcards or notify-style subtree?

Several supporters for subtree.  No objections to using subtrees.

Several supporters to make depth a must.

Barry: issue with implementations that have loops in hierarchy.
Chris: Infinity means search each mailbox in subtree once.

Lots of design discussion: exceptions for trash, shared folders, etc.

Big open issue about how to limit and order returned results.

meeting concluded.