MBOX-Line: From vladimir_butenko at stalker.com  Wed Apr 12 00:16:26 2006
To: imap-protocol@u.washington.edu
From: "Vladimir A. Butenko" <vladimir_butenko@stalker.com>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] LIST Clarification
In-Reply-To: <Pine.OSX.4.64.0604112206540.2906@pangtzu.panda.com>
References: <443A7A2D.2070708@consilient.com> <web-35034698@mail.stalker.com>
	<Pine.OSX.4.64.0604101053530.2906@pangtzu.panda.com>
	<web-35035906@mail.stalker.com>
	<Pine.WNT.4.65.0604101441160.4904@Tomobiki-Cho.CAC.Washington.EDU>
	<443C0286.60200@att.com>
	<Pine.WNT.4.65.0604111228310.3332@Tomobiki-Cho.CAC.Washington.EDU>
	<syMWpRdWCviH+GmTLGxvWQ.md5@libertango.oryx.com>
	<Pine.WNT.4.65.0604111418130.3332@Tomobiki-Cho.CAC.Washington.EDU>
	<web-35044345@mail.stalker.com>
	<Pine.WNT.4.65.0604111814490.3332@Tomobiki-Cho.CAC.Washington.EDU>
	<web-35045943@mail.stalker.com>
	<Pine.OSX.4.64.0604112206540.2906@pangtzu.panda.com>
Message-ID: <web-35046695@mail.stalker.com>

On Tue, 11 Apr 2006 22:56:33 -0700 (PDT)
  Mark Crispin <mrc@CAC.Washington.EDU> wrote:

>> correctly matching the pattern the client has provided - matching 
>>according to the rules known to the server only, not the client?

[...]
>> then the client HAS ABSOLUTELY NO RIGHT to expect that all returned names 
>> will start with "ZZZ/", and thus - can be displayed as "ZZZ" "subtree".
> 
> I don't understand why.  There's no M-UTF7 here. 

Who cares? You've just said that I (being a client) cannot assume ANYTHING 
about your (server's) responses, so I cannot plan my life depending on you.

Now you are backing up and saying "sorry, I may not be reliable at coming 
home at 19:35 every evening, but if you ask me to bring home a steak, I may 
actually bring you a fish (you've asked about Inbox, I gave you INBOX), or a 
well-baked skunk (INboX, as I like that name better), but no, no, I won't 
bring any toilet paper, you can rely on me here!".

>The only thing that may 
>different is that with a case-insensitive server that it may return names 
>that start with zzz/ or Zzz/ etc.

As we saw with non-ASCII names, it's more complex than that, and the number 
of variations is endless (though it's a countable set, not a continuum :-).

There are some freeware IMAP servers using "." as the path separator. At the 
same time, "." is part of "Modified-UTF-7 BASE64" encoding. So, some name 
can look as &ADB.r985-, because it was "言語" (it's just an example, not a 
real encoding of this japanese word). So, what would

    LIST "%.%" command return?

I'd say that the client really cannot know here, and the hierarchy it will 
present to the user would be quite different from what some users expect.

>> in the LIST command, it should not expect to see any name that ends on 
>>"HJ-", 
>> right?
> 
> I agree that M-UTF7 patterns with embedded wildcards don't work.

The problem is that it means they do not work at all :-(. I.e. a client may 
expect SOMETHING if it uses wildcards only at the end of some level, i.e. 
doing "nesting loops" like "INBOX/%/%", - and making an *assumption* that 
everything returned by such a request will be really a subdirectory of the 
"INBOX" mailbox, but if the separator is ".", then such a request 
(INBOX.%.%" can suddently return INBOX.&ADB-.&r985-, which is a INBOX.言語 and 
belongs to a different level.
  
> That's only if the client expects to know what the server will do for any 
>particular LIST command if it has earlier done a LIST of *.
> 
> IMAP makes no such promises.  It's implementation dependent, as are the 
>semantics of the naming hierarchy.

And that's exactly the problem.
  
> This was a mistake.  We all acknowledge it to have been a mistake. 
>However, the discussion about naming that took place in the early 1990s 
>wasted at least 18 months of everybody's time (and probably reduced all of 
>our lifespans by a few years due to high blood pressure).  What came up was 
>a wretched compromise, but at least it let us do our work.
>
> I disagree that case-insensitive servers are ill-defined; any 
>case-insensitive server is very well defined.  The problem is that there 
>are multiple definitions, and no authority to declare one definition to be 
>correct.

You are misinterpreting me. I had absolutely zero intention to point fingers 
and say how bad some decision WAS. If anyone can take the best step, taking 
into account all future developments till his own death, the best step would 
be to hang himself. What I'm trying to do here is quite different:

a) I'm trying to point to the problem with the current design.
b) Because I'm getting a feeling that some people, including Mr.Crispin MAY 
find time to do some revision of the IMAP protocol in the nearest future, 
I'm trying to remember ALL bad things we have met with - not even the 
protocol - but with this particular part of the protocol - and dump it on 
Mr.Crispin's head, so we can contribute - at least in this way - to the 
process of improving the protocol.
  
> Had URLs existed at the time, that is what IMAP should have used.  That at 
>least is a hierarchy that people understand.

It all depends on the amount of time you have. If I were you (if I may), I'd 
drop all concerns about the "compatibility issues" - and would create a 
clean and nice IMAP5 (NOT IMAP4revX). Making all the changes you would want 
to see there. And THEN see how it can be bridged to the existing standard so 
the existing clients and servers won't stop talking to each other. While 
this approarch seems scary and unrealistic, one usually discovers that the 
"bridge" to older versions is not as long and shaky as one would think.

But - that's just my not so humble opinion, this protocol is your kid, it's 
up to you to decide if it's a time for a Revolution, or smooth evolution is 
a better thing to do.
  
>>>>> Si vis pacem, para bellum.
>>>> and when you wish for war, prepare for a long boring peace? :-)
>>> I don't know, as only fascists wish for war;
>> Mark, I just wanted to make a quite innocent joke. Looks like I've failed, 
>> and let's not turn it into a Political Science exercise. Let's continue to 
>> play within the Computer Science barrack :-)
> 
> Oh, I understood the joke.  However, it's worth remembering that 61 years 
>ago, our parents sacrificed a great deal so that we could grow up to play 
>with computers...

Yes, it's worth remembering that it was 65 years rather than 61, though the 
death of those how died at the very end of that war when the outcome was 
clear was, probably, even more misfortunate.

Nothing is my sentense, though, had any intended ref. to that Great War. 
Neither did the creaters of ParaBellum(c) know anything about that upcoming 
event... There are many wars around. And not only on "battlefields".

  
> -- 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.

Sincerely,
Vladimir

