mailing list archives

Hello,

Quoting RFC 3501:
>       A special situation occurs when using LSUB with the % wildcard.
>       Consider what happens if "foo/bar" (with a hierarchy delimiter of
>       "/") is subscribed but "foo" is not.  A "%" wildcard to LSUB must
>       return foo, not foo/bar, in the LSUB response, and it MUST be
>       flagged with the \Noselect attribute.

Could someone please explain why this exception is needed?



E.g. if I'm subscribed to "User/somedropbox", why would I need to 
discover that I'm also subscribed to "Users" if I'm not? Assuming that 
'LSUB *' will return only User/somedropbox - any client can get confused.

If some client uses a sequence of 'LSUB %', then 'LSUB found/%', etc for 
reading the tree of subscriptions - this is a problem of the client, and 
it should not be transferred to all servers and clients.

If I have lookup right on 'one/two' mailbox but no lookup right on 'one' 
- does it mean that the same "special situation" should occur for LIST 
command which on 'LIST "~someuser" "%"' should show me 'one' (despite of 
the fact that I don't have lookup right for it) if a 'one/two' mailbox 
exist which for I do have lookup right?

-- 
Roman

On Fri, 7 Mar 2008, Roman Prokhorov wrote:
> E.g. if I'm subscribed to "User/somedropbox", why would I need to discover 
> that I'm also subscribed to "User" if I'm not? Assuming that 'LSUB *' will 
> return only User/somedropbox - any client can get confused.

Consider the situation in which User/somedropbox is subscribed, but User 
is not.  The client issues
 	tag LSUB "" %

The server can not return "User/somedropbox" because that does not match 
the pattern.  "User" isn't subscribed.  So how does the hierarchical 
browsing client find out that there's a "User/somedropbox" that is 
subscribed?

The answer is that it returns "User" to LSUB with the \NoSelect flag, to 
indicate that "User" is not subscribed, but it has at least one descendent 
(child, grandchild, great-grandchild, whatever) which is subscribed.

> If some client uses a sequence of 'LSUB %', then 'LSUB found/%', etc for 
> reading the tree of subscriptions - this is a problem of the client, and it 
> should not be transferred to all servers and clients.

You just described the way that ALL well-behaved clients prowl the 
hierarchy with LIST.  Only poorly-written clients use a * wildcard with 
LIST.

It is not unreasonable that a hierarchical browsing client would do the 
same for LSUB.

> If I have lookup right on 'one/two' mailbox but no lookup right on 'one' - 
> does it mean that the same "special situation" should occur for LIST command 
> which on 'LIST "~someuser" "%"' should show me 'one' (despite of the fact 
> that I don't have lookup right for it) if a 'one/two' mailbox exist which for 
> I do have lookup right?

This is something that an implementation would have to decide for itself. 
However, if LIST won't show "one" but will show "one/two", then there is 
no way for a hierarchical browser can discover "one/two".  Your users may 
complain.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On Fri, 7 Mar 2008, Roman Prokhorov wrote:
> Quoting RFC 3501:
>>       A special situation occurs when using LSUB with the % wildcard.
>>       Consider what happens if "foo/bar" (with a hierarchy delimiter of
>>       "/") is subscribed but "foo" is not.  A "%" wildcard to LSUB must
>>       return foo, not foo/bar, in the LSUB response, and it MUST be
>>       flagged with the \Noselect attribute.
>
> Could someone please explain why this exception is needed?
>
> E.g. if I'm subscribed to "User/somedropbox", why would I need to discover 
> that I'm also subscribed to "Users" if I'm not? Assuming that 'LSUB *' will 
> return only User/somedropbox - any client can get confused.

"User" will be returned by LSUB with the \noselect attribute, so the 
client knows that the mailbox isn't really subscribed.  No reason to get 
confused.


> If some client uses a sequence of 'LSUB %', then 'LSUB found/%', etc for 
> reading the tree of subscriptions - this is a problem of the client, and 
> it should not be transferred to all servers and clients.

Okay, imagine this special handling didn't exist.  Please explain how a 
client is to discover that you're subscribed to "Users/somedropbox" 
without doing an 'LSUB "" *' and without iterating over the output of a 
normal LIST.  I.e., how is it supposed to discover that there's a 
subscribed mailbox under "Users" at all?


> If I have lookup right on 'one/two' mailbox but no lookup right on 'one' 
> - does it mean that the same "special situation" should occur for LIST 
> command which on 'LIST "~someuser" "%"' should show me 'one' (despite of 
> the fact that I don't have lookup right for it) if a 'one/two' mailbox 
> exist which for I do have lookup right?

You should probably be sending 'LIST "~someuser/" "%"'.  Note the trailing 
hierarchy delimiter on the reference argument.

With that caveat, you are correct: you should get back
 	* LIST (\Noselect) "/" ~someuser/one

(The \noselect attribute *really* means "no lookup right, doesn't exist, 
or doesn't match the selection criterion")


Philip Guenther