Re: draft-nerenberg-imap-binary-00.txt

From:           	Lyndon Nerenberg <[email protected]>
> > I believe therefore that this functionality belongs in a new command, e.g.
> > something like
> > 	tag XFETCH (BINARY) 1 BODY[x.y]
> > 	tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
> > 	tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
> > etc.  These examples are to demonstrate the concept; the exact syntax to be
> > determined.
> 
> I hadn't realized that you and Steve had been discussing this, otherwise
> I would have held off with BINARY for a bit. I like the XFETCH architecture,
> however I'm not convinced (yet) that a server should have to implement
> external channel support just to get BINARY. At this point I think the

i would like to go on the record as one imap client implementor that 
would be very much interested in a BINARY FETCH. we have no 
use for CHANNEL at the moment... so i think these 2 concepts 
definitely should be separated.

i'd also like to enumerate some of the problems i see with 
CHANNEL as sketched out in the example above.

transport protocol
it isn't too clear from the example whether udp or tcp transport is 
envisioned. i think that the original impetus for this proposal within 
vpim was to enable the voice data to be delivered via voip (that is, 
rtp over udp.) in that context, tcp transport doesn't gain anything.

if udp is used for delivery, you then have to consider what happens 
when a packet gets dropped. voip uses fancy error-tolerant codecs 
to handle this case. the codec currently on the table for ivm (gsm) 
has no such abilities, so when a packet gets dropped, the rest of 
the file will be corrupted. 

of course, you could have the server translate the voice data into a 
fancy error-tolerant codec on the fly. probably a good use for the 
data-conversion feature of XFETCH?

nat
embedding ip addresses and port numbers within tcp payload is a 
sure way to break network address translators. it also makes imap 
dependant on ipv4, complicating the transition to ipv6. these are 
two reasons to avoid it altogether.

if ip addresses and ports must be embedded, you should at least 
try to avoid the minor disaster that ftp creates for nat by always 0-
padding the ip address octets and the port so that they always 
come out to exactly the same length. for example, instead of:

tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]

you'd have:

tag XFETCH (BINARY CHANNEL=[001.002.003.004]:00432) 1 
BODY[x.y]

(sorry about the line wrap.)
this will still break nat, of course, but at least it will be easier to 
write a custom nat protocol handler for imap.

"The battle 
 for mental territory 
            is glory. 
            End of story."
                           --KRS-ONE