RE: Feedback on the MSS draft - content issues

[Rik Drummond <rvd2@worldnet.att.net>]

we left it mandatory in this version until we have more discussion... so i
would not assume it will be there in phase two stuff. thanks for the input.
we will discuss this in tokyo. best regards, rik

-----Original Message-----
From: Steve Hole [mailto:steve.hole@messagingdirect.com]
Sent: Tuesday, October 17, 2000 6:10 PM
To: ebXML Transport
Subject: Feedback on the MSS draft - content issues


1. Issue: Mandatory use of the Content-Length header in all parts of the
message.

   Discussion:
       The Content-Length header has turned out to be one of the big
       mistakes in the MIME world.   There are several problems that
       have been encountered with it when people try to use it:

       * It defeats streaming data dumps.   It is often the requirement
         that messages are constructed by "streaming" generators that do
         not know how big the data is that will be included in the
         output message.   To get proper calculations, the size of the
         output body part AND of the entire message must be calculated
         by processing the entire body part before the MIME headers are
         written, then writing the final MIME data.   This is *very*
         inefficient.

       * Content-Encodings change the size of the content over the wire
         and receiving agents often use the Content-Length to
         incorrectly calculate receiving buffer sizes.   Clearly, this
         is a "weak implementation issue", but the effect is that
         software breaks badly.

       As such, Content-Length has been officially frowned upon and was
       seriously considered for removal from the standards track by the
       DRUMS working group.

       There is work to provide alternative advice headers for media
       representations like VPIM (Voice Profile of Internet Mail) that
       would advise receiving agents as to the apparent content size of
       a message.   These are expressed not in bytes, but in time
       increments.

   Proposed Solution
       Remove requirement for mandatory Content-Length header.  Make it
       nothing stronger than a MAY.

2. Issue:
       Use of "charset" parameter in toplevel multipart/related body part.

   Discussion: The "charset" parameter should never be used in a
       mulitpart/{mumble} part.  The charset parameter is legal only on
       "text/{mumble}" content types.  It would not provide useful
       information for a multipart type in any case.  In addition, the
       draft specifies that the default charset type is "iso-8859-1",
       which is not in fact true.  The default charset for MIME is
       "us-ascii".

   Proposed Solution:
       Do not include charset parameter in any part other than text/{mumble}
parts.

3. Issue:
       Specification of "version" attribute for multipart/related body part

   Discussion:
       This issue is raised based on the experience had with MIME
       itself.   The MIME-Version header is effectively useless because
       there is no semantic difference between a receiving agent being
       unable to handle a new version of a MIME representation and a
       completely different MIME representation.   All the version tag
       does is add an additional registration requirement to the
       requirement to specify the new contract.

       There are two approaches to handling new semantics in a content
       representation.

       (1) Define an entirely new representation type.
       (2) Define an extension mechanism for a base representation type.

       The selection on which is use is, in fact, quite easy.   If you
       wish to deprecated functionality (make it more restrictive) then
       use (1).   If you wish to extend functionality use (2), or if the
       extensions are very extensive, use (1).

       The important thing to remember is that, if you can't handle
       "application/ebxml version=2" then that is exactly equivalent to not
being
       able to handle "application/ebxml-on-steriods".   Relieve
       yourself of the requirement to manage the version number
       increments and just build new types.

       <my-personal-opinion>
       It is impossible to get everything right the first time -- thus
       the desire for version numbers.   My belief is that you should be
       able to arrive a situation where all you need to do to "fix"
       things in the future is add (extend) functionality.   Thus, keep
       it simple to start with and add the things you need that are
       proven to be needed in the future.   It is a very good idea to
       design for extensions, it will save you much heartache later.

       Very much the minimalist IETF approach, but proven to work well.
       </my-personal-opinion>

   Proposed Solution:
       Do not specify a version parameter in the Content-Type header.
       If a new version is required then define a new "root" MIME
       content type for the multipart/related that has the new
       semantics.  If extensions are required with no deprecations, then
       define an extension mechanism for the root content type.

4. Issue:
       Specification of "version" attribute for application/vnd.eb+xml body
part

   Discussion:
       See the discussion for issue 3.

   Proposed Solution:
       Do not specify a version parameter in the Content-Type header.
       Put version information in the XML payload itself if you must,
       but it would be preferrable to provide either a new XML type or
       an extension mechanism in XML type.



---
Steve Hole
Messaging Direct
Mailto:Steve.Hole@MessagingDirect.com
Phone: 780-424-4922