mailing list archives

I find that the Apple Mail tool (version 3.3) is sending my UpLib IMAP
server counted literals with an odd count.  The "number" part of the
count ends with a "+", as in "{548+}".  I don't know what that means,
or what IMAP extension defines that syntax...

My server advertises LITERAL+, NAMESPACE, UIDPLUS, IDLE.  RFC 4466
(Collected Extensions to IMAP4 ABNF) says,

   literal8        = "~{" number ["+"] "}" CRLF *OCTET
                      ;; A string that might contain NULs.
                      ;; <number> represents the number of OCTETs
                      ;; in the response string.
                      ;; The "+" is only allowed when both LITERAL+ and
                      ;; BINARY extensions are supported by the server.

It says that the "literal8" syntax was taken from RFC 3516, but
neither the character "+" nor the string "plus" occurs in RFC 3516, so
I don't trust either the spec or the attribution in RFC 4466.  My server
in any case doesn't advertise BINARY, and there's no "~" in the count
being sent by Apple Mail.

Any ideas?

Bill

The RFC 2088 Non-Synchronized Literals extension has what you're looking 
for, which is where the grammar that includes that plus is defined.

UpLib apparently wants to send a literal to the server in a single 
request/response, without having to handshake a continuation first, 
which doubles the # of round-trips for a given unit of work.

David



Bill Janssen wrote:
> I find that the Apple Mail tool (version 3.3) is sending my UpLib IMAP
> server counted literals with an odd count.  The "number" part of the
> count ends with a "+", as in "{548+}".  I don't know what that means,
> or what IMAP extension defines that syntax...
>
> My server advertises LITERAL+, NAMESPACE, UIDPLUS, IDLE.  RFC 4466
> (Collected Extensions to IMAP4 ABNF) says,
>
>    literal8        = "~{" number ["+"] "}" CRLF *OCTET
>                       ;; A string that might contain NULs.
>                       ;; <number> represents the number of OCTETs
>                       ;; in the response string.
>                       ;; The "+" is only allowed when both LITERAL+ and
>                       ;; BINARY extensions are supported by the server.
>
> It says that the "literal8" syntax was taken from RFC 3516, but
> neither the character "+" nor the string "plus" occurs in RFC 3516, so
> I don't trust either the spec or the attribution in RFC 4466.  My server
> in any case doesn't advertise BINARY, and there's no "~" in the count
> being sent by Apple Mail.
>
> Any ideas?
>
> Bill
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol
>

> I find that the Apple Mail tool (version 3.3) is sending my UpLib
> IMAP server counted literals with an odd count.  The "number" part
> of the count ends with a "+", as in "{548+}".  I don't know what
> that means, or what IMAP extension defines that syntax...
> 
> My server advertises LITERAL+, NAMESPACE, UIDPLUS, IDLE.

By advertising "LITERAL+", you claim you handle this syntax and that
clients are free to use it.  Check out RFC 2088 for details on non-
blocking literals.

> The RFC 2088 Non-Synchronized Literals extension has what you're looking 
> for, which is where the grammar that includes that plus is defined.
> 
> UpLib apparently wants to send a literal to the server in a single 
> request/response, without having to handshake a continuation first, 
> which doubles the # of round-trips for a given unit of work.

UpLib is the server, but you're otherwise exactly right -- this is a
bug in my code, not Apple's.  Thanks.  I should know this; this is
standard LITERAL+.

Bill