Re: Propsed new issue: variability of encoding in Miffy

On Wed, 14 Jan 2004 11:29:11 -0500
noah_mendelsohn@us.ibm.com wrote:
> Amelia Lewis writes:
> >> Also, for 7bit and 8bit (and as part of the encoding for
> >> quoted-printable and the MIME version of base64), the 
> >> line termination is specified to be CRLF, but processors 
> >> are expected to be forgiving, and lines may be padded 
> >> with extra spaces, which may also be freely removed.
> 
> If so, then my view is that 7bit and 8bit are inappropriate labels for
> binary data sent from SOAP Infosets.  The fundamental responsibility
> of any SOAP binding is to preserve the Infoset, character for
> character. Among other things, this is essential to make sure that
> digital signatures work.  I am strongly opposed to any definition of
> MTOM or Miffy that results in a "binding" that fails to preserve the
> characters in the Infoset.

I think that I may need a clarification of what purpose MTOM/MIFFY is
intended for.  Should it enable an arbitrary protocol to be bound, using
the characteristics of that protocol, and permitting text attachments as
well as binary attachments?  Or is it intended solely for binary
attachments, and only for (really) 8bit-clean protocols?

If the intention is the former, then in order to support MIME-compliant
protocols (which specifically and according to RFC 2616 *excludes*
HTTP), the full set of content-transfer-encoding values ought to be
supported.  This would presumably require translation, if an MTOM/MIFFY
packet crossed protocol boundaries between MIME-compliant and not
MIME-compliant (HTTP forbids the use of the Content-Transfer-Encoding
header, and unlike a MIME-compliant protocol, absence of this header in
HTTP does not indicate 7bit, but binary).

If, on the other hand, it is intended solely for binary attachments, and
only over binary-capable protocols, the universe of discourse becomes
much smaller, and a packet crossing protocol boundaries would generally
not need transformation.  However, a binding to internet email would be
fairly problematic (text attachments would, in email, be forced into
more verbose encodings, given that support for c-t-e: binary is still
not ubiquitous, and path of travel of email remains unpredictable).

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 14 January 2004 12:08:03 UTC