Re: BINARYMIME clarification

> In RFC 3030, the Binary Service Extension framework specifies one
> extension that is required (CHUNKING) but does not have any other
> dependencies explicitly listed.  However, it claims to extend the MAIL
> BODY parameter defined in the 8BITMIME service extension, nothing that
> the revised syntax allows for 7bit, 8bit, and binary options.

> Does this mean that all servers that advertise BINARYMIME must accept
> "8BITMIME" as a MAIL BODY parameter value?

No, not unless the 8bitMIME extension is offered.

> Is it permissible to advertise the BINARYMIME keyword without
> advertising the 8BITMIME keyword?

It's permissible but given that 8bitMIME is a proper subset of BINARYMIME, not
very useful.

> Second, the framework definition includes "can only be used with the
> 'CHUNKING' service extension".  I am trying to figure out how to
> handle the situation where a server advertises BINARYMIME but not
> CHUNKING (and not 8BITMIME).

This, OTOH, is a standards violation. You have to offer CHUNKING
in order to offer BINARYMIME.

> Can the client set the MAIL BODY parameter, but must set it to "7BIT"?

As long as the message is actually 7bit. BUt if it is, since 7bit is
the default, why even bother with the BODY parameter?

> Or does the client have to ignore the BINARYMIME keyword, as CHUNKING
> is a dependency?

Again, a server that offers BINARYMIME without also offering CHUNKING isn't
valid. Our standards generally do not indicate what needs to be done in such
cases, but a client would probably be well advisded to ignore BINARYMIME when
CHUNKING isn't present.

				Ned