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

[Mark Crispin <MRC@xxxxxxxxxxxxxxxxxx>]

On Tue, 21 Nov 2000 15:08:50 -0700, Lyndon Nerenberg wrote:
> > However, I object strongly to the "BODY[x.y.BINARY]" syntax.
> I'll agree with that. I'm not particularly happy with that syntax either.
> I needed something as a starting point

OK, good.  I'm happy with a stipulation that we're going to fix that.  I don't
want to stand in the way of the functionality, but that particular syntax has
got to go.

> And this is something VPIM originally requested (general conversions). I
> don't like overloading (or combining, I guess) BINARY with data conversion.

Isn't converting QP and BASE64 to BINARY a form of data conversion?

> I hadn't realized that you and Steve had been discussing this, otherwise
> I would have held off with BINARY for a bit.

That's why I was a bit surprised to see your document!  :-)

> 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
> two are really distinct issues, and should be separate extensions.

OK with me.

My guiding principle (consider XLIST) is that if it's trivial to bundle two
things together and less work than having them separate, then bundle them; but
if there's a reason why someone may want one and not the other, then keep them
separate.

If you feel that BINARY vs. external channel support is the latter, I won't
squawk.  [I'd appreciate the return favor when we talk about XLIST vs.
subscriptions........]

> > XFETCH that would output on the IMAP channel, so the client can
> > distinguish a literal8 from an ordinary literal.
> This shouldn't be necessary. The server will only send a literal8 at
> the specific request of the client, and they will never show up in
> an unsolicited response. It's not a big deal, though. If concensus is
> for a unique syntax for literal8 that's an easy change to make.

Mr. IMAP Architecture says that it's presumptious to say that "they will never
show up in an unsolicited responses."

The presumption may be valid for literal8 (and certainly right now it is), but
it isn't for literal; and that's what creates the ambiguity.  We don't want
the situation where a client gets a literal and thinks that it's a literal8.

I suggest some added little token in literal8, perhaps {###}~ instead of {###}
to indicate its special nature.