Fwd: SVG WG comments on MIFFY and MTOM

Separate mail in case the message I bounced from
Chris doesn't make it.

----- Forwarded message from Chris Lilley <chris@w3.org> -----

Date: Wed, 3 Dec 2003 00:04:32 +0100
From: Chris Lilley <chris@w3.org>
Subject: SVG WG comments on MIFFY and MTOM
To: w3c-xml-protocol-wg@w3.org
Cc: w3c-svg-wg@w3.org
Message-ID: <1542980042.20031203000432@w3.org>
Reply-To: Chris Lilley <chris@w3.org>
Resent-From: w3c-svg-wg@w3.org
Resent-Date: Tue,  2 Dec 2003 18:04:47 -0500 (EST)
Organization: W3C
X-Archived-At: http://www.w3.org/mid/1542980042.20031203000432@w3.org


Hello David,

The SVG working group has reviewed the MTOM and MIFFY documents
referenced at:
"http://www.w3.org/mid/3FC37C1E.20201@crf.canon.fr" and
"http://www.w3.org/mid/3598942A-1742-11D8-A2DC-00039396E15A@bea.com"
respectively, and discussed them at the 2 December telcon.

We have some comments for your consideration.

Executive summary:
* Referenced parts must include the 'Content-Transfer-Encoding' field
  and should include the 'Content-Length' field.
* The referencing mechanism via 'Content-Type' and 'http' URI presents
  an ambiguous referencing mechanism and may require removal.
* Addressing the 'data:' URI directly in the MIFFY specification
  is desirable.
* Packaging multipart payloads via use of the
  'multipart/multiplexed' mechanism in RFC 3391 should be considered
  as a valid MIFFY encoding mechanism.
  
  ----------------------------------------------------
  
1) Referenced parts MUST include the 'Content-Transfer-Encoding' field
   and should include the 'Content-Length' field.

    The MIFFY description as presented in the above referenced document
presents a sound approach to encoding of compound or multipart payloads.
It appears that the described encoding mechanism from SOAP data into
MIME encoded multipart will produce arbitrary binary data for the
encoded MIME sub-parts.   In particular, when control characters,
i.e. less than 32 decimal are encoded in base64, they will decode into
raw control characters in the MIME part.  The NUL (0x00) character in
particular will very probably be problematic.

    MIME sub-parts encoded in such a manner assume an 8-bit clean
transmission channel, which may not be available for general application
of such an encoding.

    In the presence of an 8-bit clean channel, there must be a workable
mechanism to allow the inclusion of arbitrary binary data.  Such
binary data may by its very nature include a valid MIME part delimiter.

   The mechanism for inclusion of arbitrary binary data inside a MIME
sub-part is addressed in RFC 2045 by use of the
'Content-Transfer-Encoding' field with a parameter specified as
'binary'. In the case of using the 'binary' encoding, the MIME header
MUST include a 'Content-Length' field indicating the number of bytes
of raw binary data present in the sub-part (as specified in RFC 2543
etc.).

    It is our suggestion that the 'Content-Transfer-Encoding' and
'Content-Length' fields be present in all MIME sub-parts encoded using
the MIFFY encapsulation.  At minimum the contained data should be
analysed for compatibility with non-binary transport gateways and the
sub-part encoded using a well specified 'Content-Transfer-Encoding',
be that base64, etc.

    For simplicity of encode/decode we would suggest that
'Content-Transfer-Encoding' and 'Content-Length' be mandatory in a
MIFFY encoded sub-part and that the encoding be 'binary'.

    Note, that the CIP4 group using JDF already use such a scheme for
transmission of multipart aggregated print jobs in pre-press production
areas.

    In the absence of an 8-bit clean transmission channel, MIFFY
should specify a preferred encoding mechanism for the sub-parts,
most probably base64.  In any case, transcoding at gateways should
be possible.

2) The referencing mechanism via 'Content-Type' and 'http' URI
   presents an ambiguous referencing mechanism and may require removal.

   The process of encoding a SOAP packet into an aggregated MIME
multipart specifies two alternate encodings for referenced content.
One uses the well-known 'cid:' URI which references the MIME sub-part
by use of 'Content-Id' in the sub-part.

    An alternate referencing mechanism by use of an 'http:' URI and
specification in the MIME sub-part by use of the 'Content-Location'
field.

    This latter mechanism seems to present a potential ambiguity in
its semantics.

    Firstly, if the process is a recoding mechanism, it is entirely
unclear why two alternate schemes are needed.  The 'cid:' referencing
mechanism is well known and functional.  An encoder can unambiguously
encode content via this mechanism.

    The second mechanism via the use of 'http:' seems to be semantically
incorrect.  The specification of an 'http:' address in the XML content
in the root part of the MIME package implies that an 'http:' request
should be made to retrieve the referenced content.  This is clearly
not the desired behaviour.  A greater concern is in malformed encodings
where a matching MIME sub-part cannot be found.  Should the decoder
attempt to fetch the resource via 'http:'?  If so, the message itself
is in error, as the resources are not present in the packaged message.
Also, should a decoder check if the referenced content is up to date,
or just use the encapsulated MIME sub-part instead?

        The use of 'http:' as a referencing mechanism seems to be
at odds with what the encoding represents.  Placing a 'Content-Location'
header field in the MIME sub-part is possibly useful as metadata,
however we would suggest that the 'cid:' referencing mechanism be
mandatory.

3) Addressing the 'data:' URI directly in the MIFFY specification
   is desirable.

   As currently defined, MIFFY may only optimise base64 data found as 
element content. In order to accommodate common practice in a number of
vocabularies, notably SVG where it is a frequent occurrence, we believe
that there would be great value in supporting data: URIs (RFC 2397) in 
MIFFY, through the addition of appropriate markup to your vocabulary.

    This would effectively allow us to use MIFFY directly, without
requiring  any backwards-incompatible change to SVG. We understand
that XMLP may wish to without this feature in the SOAP context, but
it appears to us that MTOM could profile MIFFY to eliminate it if
you are so inclined.

4) Consideration of packaging multipart payloads via use of the
   'multipart/multiplexed' mechanism in RFC 3391 should be considered
   as a valid MIFFY encoding mechanism.

   In some use cases, it is desirable to interleave the base XML
document data with its referenced content.

    A mechanism for doing so is described in RFC 3391.  It is our
opinion that the mechanism described in RFC 3391 be a valid encoding
mechanism for MIFFY encoded documents.  It presents little overhead
for decoders and has the desirable benefit of facilitating streamed
content with multiple referenced parts.

    We respectfully ask you to consider these suggestions.


-- 
 Chris Lilley                      mailto:chris@w3.org
 Chair, W3C SVG WG

----- End forwarded message -----

Received on Tuesday, 16 December 2003 17:39:39 UTC