mailing list archives

Hello

I'm suffering using the little bogus python imaplib, that don't handle well
literals.
I would like to update the code, but need enlightened advices.

In the following questions I'm not to much interested by AUTH, LOGIN, FETCH
or APPEND but more about LIST, SEARCH, SETACL ...

I would like to better understand the literal usage :

When does a _server_  OR  a _client_ use a literals ?
When their is no other way (when does quoted string are not enough) ?
What are the usual cases ? (I looked cyrus and found constraint about
size>1024 or use of special char like "%" )

What is the correct usage when mixing literal and string,
does I need to insert a space between the end of a literal ?

For example for a setacl mailbox username lrswipcda, where I mix strings
ands literals

(Here .. means CRLF)

C: 000001 SETACL "mailbox" {8}
S: wait for server "continuation response"
C: username..<DO I NEED TO INSERT A SPACE HERE>lrswipcda..

Best regards.


--
Alain Spineux
aspineux gmail com
May the sources be with you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20070320/099eadfc/attachment.html>

> Hello
> I'm suffering using the little bogus python imaplib, that don't 
> handle well
> literals.
> I would like to update the code, but need enlightened advices.
You could take a look at my Python library, at 
http://trac.dave.cridland.net/
It might well save you a lot of work.
> In the following questions I'm not to much interested by AUTH, 
> LOGIN, FETCH
> or APPEND but more about LIST, SEARCH, SETACL ...
> I would like to better understand the literal usage :
> When does a _server_  OR  a _client_ use a literals ?
> When their is no other way (when does quoted string are not enough) 
> ?
> What are the usual cases ? (I looked cyrus and found constraint 
> about
> size>1024 or use of special char like "%" )
Either when they have to, or can. Quoted strings must be used in a 
couple of places, such as Append commands for the date.
> What is the correct usage when mixing literal and string,
> does I need to insert a space between the end of a literal ?
There's usually a space, yes.
> For example for a setacl mailbox username lrswipcda, where I mix 
> strings
> ands literals
> (Here .. means CRLF)
> C: 000001 SETACL "mailbox" {8}
> S: wait for server "continuation response"
> C: username..<DO I NEED TO INSERT A SPACE HERE>lrswipcda..
No cr lf should be there. Just a space.
Dave.

On Tue, 20 Mar 2007, Alain Spineux wrote:
> When does a _server_  OR  a _client_ use a literals ?

An implementation will use literals if it must; that is, the string can 
not be represented as atom or quoted.

An implementation is likely to do so when it is uncomfortable with the 
contents; for example, \ was an ordinary character quoted strings in IMAP2 
and thus implementations that seek to be IMAP2 compatible will avoid using 
quoted strings that have \ quoting.  Another reason for discomfort is if 
the string is long; parsing for the trailing quote is more work than 
handling the literal.

Or, it can use literals just because it wants to.

> What is the correct usage when mixing literal and string,
> does I need to insert a space between the end of a literal ?

This is defined by the formal syntax.  It is incorrect to ask your 
question, because that assumes a single answer.  The formal syntax defines 
what delimiter appears after the literal.

As a general rule, one (and only one) space separates tokens in IMAP. 
However, that is not associated with the token, but rather the syntax.  If 
the token is the last item of a list, there would be a close parenthesis 
instead of a space after it.

> For example for a setacl mailbox username lrswipcda, where I mix strings
> ands literals
>
> (Here .. means CRLF)
>
> C: 000001 SETACL "mailbox" {8}
> S: wait for server "continuation response"
> C: username..<DO I NEED TO INSERT A SPACE HERE>lrswipcda..

That is defined by the syntax of SETACL.  In that case, yes there is a 
SPACE and not a CRLF.

Again, please use the formal syntax and not code rules into your handling 
of literals.  After a literal is either a delimiter or end of string; that 
is all that the literal handler should know.  A higher level rule that 
handles the syntax of the command will deal with what the delimiter is.

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

Alain Spineux wrote:
> I'm suffering using the little bogus python imaplib, that don't handle
> well literals.

You might find my library [1] useful.

[1] http://svn.flaska.net/viewcvs/trojita/trunk/ymaplib/

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20070331/bb9a6468/attachment.sig>

> As a general rule, one (and only one) space separates tokens in IMAP. 

In my server implementation, I tried to follow the old rule of "be
liberal in what you accept, and strict in what you provide."  So
though arguments to IMAP commands are strictly speaking separated by
exactly one space, I accept any run of whitespace in place of that
single space.  I'm speaking only of top-level arguments to a command,
of course.

Bill

On 3/20/07, Mark Crispin <mrc@cac.washington.edu> wrote:
> On Tue, 20 Mar 2007, Alain Spineux wrote:
>
> An implementation is likely to do so when it is uncomfortable with the
> contents; for example, \ was an ordinary character quoted strings in IMAP2
> and thus implementations that seek to be IMAP2 compatible will avoid using
> quoted strings that have \ quoting.  Another reason for discomfort is if
> the string is long; parsing for the trailing quote is more work than
> handling the literal.

This is a usefull answere :-)

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


-- 
--
Alain Spineux
aspineux gmail com
May the sources be with you

> In my server implementation, I tried to follow the old rule of "be
> liberal in what you accept, and strict in what you provide."

That "rule" meant: when presented with garbage input, the receiver should 
not crash, explode, or otherwise take down the rest of the network.  It 
does not, and it never did, mean "violate the published protocol 
specification at your whim."

All you are doing is contributing to non-interoperability between IMAP 
clients and servers.  Please don't do that.

> I accept any run of whitespace in place of that
> single space.

Strictly speaking, what you have is not an IMAP server.

--lyndon

On Tue, 20 Mar 2007, Bill Janssen wrote:
>> As a general rule, one (and only one) space separates tokens in IMAP.
> In my server implementation, I tried to follow the old rule of "be
> liberal in what you accept, and strict in what you provide."  So
> though arguments to IMAP commands are strictly speaking separated by
> exactly one space, I accept any run of whitespace in place of that
> single space.  I'm speaking only of top-level arguments to a command,
> of course.

Although the practice you describe is relatively common, there are cases 
(SASL comes to mind) in which spaces are highly significant.

I generally agree with what Lyndon said; however to avoid a "pot, kettle, 
black" (or is it, "do what I say, not what I do"?) I assert that there is 
a difference, in cases where one and only one space is called for, 
between:
  . accepting a run of spaces because it was easier to code that way (e.g.,
    something quick & dirty like strtok()).
  . going to extra effort to accept a run of spaces.
In the former case, you aren't actively enforcing every possible aspect of 
syntax; in the latter case, you're deliberately allowing a violation.

-- Mark --

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

> > I accept any run of whitespace in place of that
> > single space.
> 
> Strictly speaking, what you have is not an IMAP server.

It's even worse than that :-).  I haven't figured out how to implement
STARTTLS yet.

Bill