Subject: Re: SEARCHM
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: [email-masked]
Date: Wed, 24 Jan 2007 17:56:29 +0000
List-Id: <ietf-imapext.imc.org>

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.

Subject: Re: SEARCHM
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Wed, 24 Jan 2007 19:01:45 +0200
Sender: [email-masked]

--=-xey1jLHTdC0gtmb/L1HH
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2007-01-24 at 16:45 +0000, Alexey Melnikov wrote:
> Timo Sirainen wrote:
>=20
> >Looks like the draft expired years ago. Are there any newer efforts to
> >support searching from multiple mailboxes with a single command?
> > =20
> >
> I've recently revived it as=20
> 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.

--=-xey1jLHTdC0gtmb/L1HH
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-xey1jLHTdC0gtmb/L1HH--

Date: Wed, 24 Jan 2007 16:45:59 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: [email-masked]
Subject: Re: SEARCHM
Sender: [email-masked]

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.

Subject: SEARCHM
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: Wed, 24 Jan 2007 18:30:08 +0200
Sender: [email-masked]

--=-Bc5EvcGPAURw9HITagy8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

--=-Bc5EvcGPAURw9HITagy8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-Bc5EvcGPAURw9HITagy8--

Date: Mon, 22 Jan 2007 15:31:51 -0500
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>, [email-masked], imapext <[email-masked]>
CC: [email-masked]
Subject: [Fwd: Advancing RFC2821 to Draft Standard -- outline of work]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060704040600040307050804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This is an FYI of work that's starting up on the [email-masked]
mailing list.

	Tony Hansen
	[email-masked]

--------------060704040600040307050804
Content-Type: message/rfc822;
 name="Advancing RFC2821 to Draft Standard -- outline of work"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="Advancing RFC2821 to Draft Standard -- outline of work"

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Advancing RFC2821 to Draft Standard -- outline of work
Date: Mon, 22 Jan 2007 11:40:08 -0800
Sender: [email-masked]

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  
changes.   As with any movement from DS to PS, changes should be  
limited to, if possible: clarifications of the spec where there are  
discrepancies, and removal of unused features. The fixing of "bugs"  
should be limited to those that have a *very strong* consensus.

Tony Hansen volunteered to keep a chair-like eye on the activity,  
progress and consensus where needed, which will be particularly  
helpful as I'll be on leave in Feb and March.

2.  We do think there are some bugs in the document that are worth  
fixing.  We don't think that those fixes are likely to cause  
significant change to the behavior of conforming implementations.   
Tony Hansen put RFC2821 into XML2RFC format, and John Klensin has a  
revision with fixes which he'll post here.

Volunteers to review, please?

3.  Some interop reporting is likely needed.  We don't think this  
requires a huge effort.  Here's one way to proceed: one step is for  
somebody to write an outline that lists the major interop areas or  
features to consider.  The next step is for a couple implementors to  
fill in that outline their experience with their code-bases and  
talking to other implementations.  Another way to try to proceed is  
to have implementors report what they *don't* implement or find  
doesn't work.  We don't believe we have to document every MUST/MAY/ 
SHOULD but can look at least one level higher (less granular).   
Either way, it shouldn't require new testing, and we definitely want  
to try to keep this lightweight so that there's hope it actually gets  
done.

Ned Freed and Alexey Melnikov have volunteered to do some work here  
-- Alexey has already begun -- and Dave Crocker outlined a "interop  
questionnaire" that would be lightweight.

Ned, Alexey and Dave can you post your proposals or status to this list?

Lisa

--------------060704040600040307050804--

Date: Mon, 8 Jan 2007 12:43:23 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sort and i18n
Cc: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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 
for an odd case and I wasn't sure what codepoints that should be.  (The 
common subset of US-ASCII and ISO-646-*?)

As if today, your subject should be treated the same way as

Subject: hello =?us-ascii?q?=88?= world

and I think this is the same, too:

Subject: hello =?iso-8859-8?q?=ff?= world

Arnt

Date: Fri, 5 Jan 2007 12:32:15 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: sort and i18n
Sender: [email-masked]

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.

Date: Fri, 05 Jan 2007 19:39:54 +0000
Subject: Re: sort and i18n
From: Dave Cridland <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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 
doesn't match "hello world", since there are no [known] spaces. I 
could also deal with it matching "hello =?unknown?q?pretty?= world" 
too.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

To: [email-masked]
From: Timo Sirainen <[email-masked]>
Subject: sort and i18n
Date: Fri, 5 Jan 2007 20:19:56 +0200
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-7-735435426
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

 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.

--Apple-Mail-7-735435426
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-7-735435426--

Date: Wed, 24 Jan 2007 17:56:29 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: [email-masked]
Subject: Re: SEARCHM
Sender: [email-masked]

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.

Subject: Re: SEARCHM
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Wed, 24 Jan 2007 19:01:45 +0200
Sender: [email-masked]

--=-xey1jLHTdC0gtmb/L1HH
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2007-01-24 at 16:45 +0000, Alexey Melnikov wrote:
> Timo Sirainen wrote:
>=20
> >Looks like the draft expired years ago. Are there any newer efforts to
> >support searching from multiple mailboxes with a single command?
> > =20
> >
> I've recently revived it as=20
> 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.

--=-xey1jLHTdC0gtmb/L1HH
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-xey1jLHTdC0gtmb/L1HH--

Date: Wed, 24 Jan 2007 16:45:59 +0000
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: [email-masked]
Subject: Re: SEARCHM
Sender: [email-masked]

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.

Subject: SEARCHM
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: Wed, 24 Jan 2007 18:30:08 +0200
Sender: [email-masked]

--=-Bc5EvcGPAURw9HITagy8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

--=-Bc5EvcGPAURw9HITagy8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-Bc5EvcGPAURw9HITagy8--

Date: Mon, 22 Jan 2007 15:31:51 -0500
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>, [email-masked], imapext <[email-masked]>
CC: [email-masked]
Subject: [Fwd: Advancing RFC2821 to Draft Standard -- outline of work]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060704040600040307050804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This is an FYI of work that's starting up on the [email-masked]
mailing list.

	Tony Hansen
	[email-masked]

--------------060704040600040307050804
Content-Type: message/rfc822;
 name="Advancing RFC2821 to Draft Standard -- outline of work"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="Advancing RFC2821 to Draft Standard -- outline of work"

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Advancing RFC2821 to Draft Standard -- outline of work
Date: Mon, 22 Jan 2007 11:40:08 -0800
Sender: [email-masked]

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  
changes.   As with any movement from DS to PS, changes should be  
limited to, if possible: clarifications of the spec where there are  
discrepancies, and removal of unused features. The fixing of "bugs"  
should be limited to those that have a *very strong* consensus.

Tony Hansen volunteered to keep a chair-like eye on the activity,  
progress and consensus where needed, which will be particularly  
helpful as I'll be on leave in Feb and March.

2.  We do think there are some bugs in the document that are worth  
fixing.  We don't think that those fixes are likely to cause  
significant change to the behavior of conforming implementations.   
Tony Hansen put RFC2821 into XML2RFC format, and John Klensin has a  
revision with fixes which he'll post here.

Volunteers to review, please?

3.  Some interop reporting is likely needed.  We don't think this  
requires a huge effort.  Here's one way to proceed: one step is for  
somebody to write an outline that lists the major interop areas or  
features to consider.  The next step is for a couple implementors to  
fill in that outline their experience with their code-bases and  
talking to other implementations.  Another way to try to proceed is  
to have implementors report what they *don't* implement or find  
doesn't work.  We don't believe we have to document every MUST/MAY/ 
SHOULD but can look at least one level higher (less granular).   
Either way, it shouldn't require new testing, and we definitely want  
to try to keep this lightweight so that there's hope it actually gets  
done.

Ned Freed and Alexey Melnikov have volunteered to do some work here  
-- Alexey has already begun -- and Dave Crocker outlined a "interop  
questionnaire" that would be lightweight.

Ned, Alexey and Dave can you post your proposals or status to this list?

Lisa

--------------060704040600040307050804--

Date: Mon, 8 Jan 2007 12:43:23 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: sort and i18n
Cc: Timo Sirainen <[email-masked]>
Sender: [email-masked]

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 
for an odd case and I wasn't sure what codepoints that should be.  (The 
common subset of US-ASCII and ISO-646-*?)

As if today, your subject should be treated the same way as

Subject: hello =?us-ascii?q?=88?= world

and I think this is the same, too:

Subject: hello =?iso-8859-8?q?=ff?= world

Arnt

Date: Fri, 5 Jan 2007 12:32:15 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked]
Subject: Re: sort and i18n
Sender: [email-masked]

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.

Date: Fri, 05 Jan 2007 19:39:54 +0000
Subject: Re: sort and i18n
From: Dave Cridland <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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 
doesn't match "hello world", since there are no [known] spaces. I 
could also deal with it matching "hello =?unknown?q?pretty?= world" 
too.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

To: [email-masked]
From: Timo Sirainen <[email-masked]>
Subject: sort and i18n
Date: Fri, 5 Jan 2007 20:19:56 +0200
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-7-735435426
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

 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.

--Apple-Mail-7-735435426
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-7-735435426--