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

[Lyndon Nerenberg <lyndon@xxxxxxxxxxxxxxxxxxx>]

> The subject draft attempts to fufill a needed requirement for the VPIM folks.

Initially that was the case, although I certainly think this extension has
a use outside of that context.

> However, I object strongly to the "BODY[x.y.BINARY]" syntax.  Unlike other
> section specifiers, this one would stipulate a transformation of a section
> rather than identify a unique section.  It also adds complexity (the "terminal
> MIME body part" rule) as a side effect of overloading location syntax (the
> section specifier) with transformation instructions ("BINARY").

I'll agree with that. I'm not particularly happy with that syntax either.
I needed something as a starting point (and was under the gun to meet
the submission deadline, so I didn't have a chance to work out anything
better), so I went with the syntax in the original VPIM proposal.

> Furthermore, this extension does not really address the complete need, which
> is a general ability to transform/deliver message data in extended forms.  For
> example, a streaming application may wish to specify a separate host/port for
> delivery of the data.  It may be desireable to request the server to transform
> text data to UTF-8.

And this is something VPIM originally requested (general conversions). I
don't like overloading (or combining, I guess) BINARY with data conversion.
BINARY provides a single piece of functionality: undoing of content
transfer encodings. This is neutral to the actual content. If there is
a need to do actual conversion of the underlying data, that should be
handled separately. Character set conversions (such as your UTF8 example) 
are a bit fuzzy, sitting in between BINARY and general data conversions.
I'm not sure where that actually fits in, but again I think that's a
separate issue from BINARY itself.

> 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
two are really distinct issues, and should be separate extensions. I don't
think implementing channel necessarily requires the BINARY extensions
be present. The external channel may already be 8bit clean, and the
specification for that profile of the channel target mechanism could
explicitly state that the channel is 8bit clean, therefore there's
no need for the server to also implement BINARY if the implementer doesn't
feel it adds significant value. It's still very early in the game, though,
so I don't consider any of this cast in stone. I'm looking forward to
seeing a more complete specification for XFETCH.

> We should also have a syntax for literal8s that are output in the case of an
> XFETCH that would output on the IMAP channel, so the client can distinguish a
> literal8 from an ordinary literal.  Otherwise there would be an ambiguity due
> to the unsolicited data model of IMAP, and the client would have to depend
> upon a command modality that IMAP espressly forbids.

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.

--lyndon