sort and i18n

 From i18n draft:

     Strings encoded using unknown character encodings should never  
match
     when using the SEARCH command, and should sort together with  
invalid
     input for the SORT and THREAD commands.

First of all, I don't see either draft explaining how "invalid input"  
is sorted. Does it mean it should be treated as an empty string?

If I have a subject:

Subject: hello =?unknown?q?pretty?= world

Should it be treated as empty string, "hello" or "hello world"? I  
think "hello world" is what the user would want.

Re: sort and i18n

On Fri Jan  5 18:19:56 2007, Timo Sirainen wrote:
> From i18n draft:
> 
>     Strings encoded using unknown character encodings should never  
> match
>     when using the SEARCH command, and should sort together with  
> invalid
>     input for the SORT and THREAD commands.
> 
> First of all, I don't see either draft explaining how "invalid 
> input"  is sorted. Does it mean it should be treated as an empty 
> string?
> 
> 
By comparator rules, at the end, independently of the ordering.

> If I have a subject:
> 
> Subject: hello =?unknown?q?pretty?= world
> 
> Should it be treated as empty string, "hello" or "hello world"? I  
> think "hello world" is what the user would want.
> 
> 
For sorting purposes, I'd expect it to be treated as invalid.

For searching purposes, strictly speaking it's invalid and doesn't 
match anything, but I wouldn't bemaon an implementation where 
substring matches for "hello" and "world" matched. It definitely 

Re: sort and i18n

On Fri, 5 Jan 2007, Dave Cridland wrote:
> I could also deal with it matching "hello =?unknown?q?pretty?= world" 
> too.

+1

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: sort and i18n

Happy new year.

Timo Sirainen writes:
>  From i18n draft:
>
>      Strings encoded using unknown character encodings should never match
>      when using the SEARCH command, and should sort together with invalid
>      input for the SORT and THREAD commands.
>
> First of all, I don't see either draft explaining how "invalid input" 
> is sorted. Does it mean it should be treated as an empty string?

It goes at the end.

> If I have a subject:
>
> Subject: hello =?unknown?q?pretty?= world
>
> Should it be treated as empty string, "hello" or "hello world"? I 
> think "hello world" is what the user would want.

That's certainly what I would want as a user, but neither RFC 1345 nor 
any of the later RFCs say that all unknown characters sets must be 
supersets of ASCII, so it's a somewhat unsafe assumption. I don't see 
justification for making that assumption that in a standards-track RFC.

I thought about adding some language to the i18n document specifying 
that some codepoints may be assumed to be equal to those in ASCII even 
if the name of the character set is not known, but it was a lot of text 

[Fwd: Advancing RFC2821 to Draft Standard -- outline of work]

This is an FYI of work that's starting up on the ietf-smtp <at> imc.org
mailing list.

	Tony Hansen
	tony <at> att.com

From: Lisa Dusseault <ldusseault <at> commerce.net>
Subject: Advancing RFC2821 to Draft Standard -- outline of work
Date: 2007-01-22 19:40:08 GMT

I've been discussing the advancement of RFC2821 along the standards  
track with a few people, and we'd like to proceed publicly.  This  
email can be considered an informal charter and plan for initial  
work, with consensus goals for the effort, which may not need a  
formal WG.  Charter-bashing should be done *early* if you disagree.  
I'd rather avoid late-cycle suggestions to change the goals. This  
list seems like a fine place to have discussions about the goals, as  
well as to do the actual work, and I'll post pointers to a couple  
other lists to direct people here who aren't already subscribed.

1.  We want to advance RFC2821/SMTP to Draft Standard.  Thus, we  
don't want to design anything "new" or "better" for SMTP as part of  
this particular effort, which would require recycling at Proposed  
Standard -- in fact, we want to be conservative in minimizing  

SEARCHM

Looks like the draft expired years ago. Are there any newer efforts to
support searching from multiple mailboxes with a single command?

Re: SEARCHM

Timo Sirainen wrote:

>Looks like the draft expired years ago. Are there any newer efforts to
>support searching from multiple mailboxes with a single command?
>  
>
I've recently revived it as 
draft-melnikov-imapext-multimailbox-search-01.txt.

Re: SEARCHM

On Wed, 2007-01-24 at 16:45 +0000, Alexey Melnikov wrote:
> Timo Sirainen wrote:
> 
> >Looks like the draft expired years ago. Are there any newer efforts to
> >support searching from multiple mailboxes with a single command?
> >  
> >
> I've recently revived it as 
> draft-melnikov-imapext-multimailbox-search-01.txt.

Weren't there some talk about using LISTEXT for selecting the mailbox
list?

At least I don't really like that multimailbox-search supports DEPTH
while LISTEXT doesn't.

Re: SEARCHM

Timo Sirainen wrote:

>On Wed, 2007-01-24 at 16:45 +0000, Alexey Melnikov wrote:
>  
>
>>Timo Sirainen wrote:
>>    
>>
>>>Looks like the draft expired years ago. Are there any newer efforts to
>>>support searching from multiple mailboxes with a single command?
>>>      
>>>
>>I've recently revived it as 
>>draft-melnikov-imapext-multimailbox-search-01.txt.
>>    
>>
>Weren't there some talk about using LISTEXT for selecting the mailbox
>list?
>  
>
I vaguely remember something.

>At least I don't really like that multimailbox-search supports DEPTH
>while LISTEXT doesn't.
>  
>
We should discuss how to fix this in both places. I think LISTEXT is 
lacking DEPTH, which is inconvenient.