Re: Feedback on the MSS draft - content issues

[Christopher Ferris <chris.ferris@east.sun.com>]

Steve,

Thanks for the great feedbcak/comments. My thoughts below avec <cbf>.

Cheers,

Chris

Steve Hole wrote:
> 
> 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.

<cbf>
As Rik points out, we are planning on addressing this in our next
phase. Your points are well taken.
</cbf>

> 
> 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.

<cbf>
In the current version (v0.21d) it is omitted. It was intended to be removed
earlier, but somehow we missed the edit even after we agreed to remove it.
</cbf>
> 
> 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.

<cbf>
Good point. The version attribute is intended to reflect the version
of the "packaging" which is MIME multipart/related with a specific
overall organization (single header container and single payload
container which may itself be of type MIME miltipart/*. Given that
distinction and your eloquent discussion, it is likely that your option (1)
would be appropriate for our use rather than to use a version attribute.
We will likely discuss this at our next face2face.
</cbf>

> 
> 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

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903