
MIME Conformance ?
==================

README.ME+ states:

        > But anyway, Elm will never be MIME Conformant

But lets look what RFC 2049 (Multipurpose Internet Mail Extensions
(MIME) Part Five: Conformance Criteria and Examples) says. Text
from RFC 2049 is quoted with ###. 

ELM ME+ refers to Elm 2.4ME+ PL109 (25).

###   A mail user agent that is MIME-conformant MUST:

###    (1)   Always generate a "MIME-Version: 1.0" header field in
###          any message it creates.

      ELM ME+ do not add MIME-Version: 1.0 
      on following situation:

      1) If Elm ME+ is mailing of form

	    Content-Type: mailform

	 That is not MIME message, but some obsolete format
	 (it is unclear can be that format invoked)

###    (2)   Recognize the Content-Transfer-Encoding header field
###          and decode all received data encoded by either quoted-
###          printable or base64 implementations.  The identity
###          transformations 7bit, 8bit, and binary must also be
###          recognized.

      ELM ME+ do not recognize these content-transfer-encodings
      if message have not MIME-Version header and elmrc option
      "require-mime-version-for-body-encoding" have value ON 
      (default ON).

###          Any non-7bit data that is sent without encoding must be
###          properly labelled with a content-transfer-encoding of
###          8bit or binary, as appropriate.  If the underlying
###          transport does not support 8bit or binary (as SMTP
###          [RFC-821] does not), the sender is required to both
###          encode and label data using an appropriate Content-
###          Transfer-Encoding such as quoted-printable or base64.

      ELM ME+ do not encode non-7bit text data, 
      on following situation:

      1) If elmrc option "noencoding" have value "pass-8bit" 
         or "pass-binary".

         Default value is "pass-7bit".

      Also ELM ME+ do not encode, if to it is told that underlying
      transport supports 8bit or binary.

###    (3)   Must treat any unrecognized Content-Transfer-Encoding
###          as if it had a Content-Type of "application/octet-
###          stream", regardless of whether or not the actual
###          Content-Type is recognized.

      ELM ME+ provides way to save part on message encoded form if 
      content-transfer-encoding is unrecognized.

      ELM ME+ provides way to save application/octet-stream on
      decoded form if  content-transfer-encoding is recognized and
      supported.

      However if metamail is available and elmrc option "metamail"
      is not value "none", mail with unknown content-transfer-encoding
      is passed to metamail. So behaviour depends of metamail.

###    (4)   Recognize and interpret the Content-Type header field,
###          and avoid showing users raw data with a Content-Type
###          field other than text.

      ELM ME+ do not recognize these content-type header
      if message have not MIME-Version header and elmrc option
      "require-mime-version-for-body-encoding" have value ON 
      (default ON).


      If metamail is available and elmrc option "metamail"
      is not value "none", mail with unknown content-type
      is passed to metamail. So behaviour depends of metamail.

      1) Metamail may display raw data

      If metamail is not used, Elm ME+ provides way to save
      part with unknown content-type on (content-transfer-encoding) 
      decoded form. Raw data is not shown if external programs
      are not used for interpretation of data.

      Elm ME+ provides limited internal mailcap parser. If mailcap
      specifies program for content-type and Elm ME+ is able to
      support line on mailcap, Elm ME+ provides possibility to pass
      data on (content-transfer-encoding) decoded form to that 
      external program. So on that case it depends on external program.

###                                  Implementations  must be able
###          to send at least text/plain messages, with the
###          character set specified with the charset parameter if
###          it is not US-ASCII.

      Elm ME+ provides is able to send text/plain messages and
      provides charset -parameter if it is not US-ASCII.

###    (5)   Ignore any content type parameters whose names they do
###          not recognize.

      Elm ME+ ignores unknown content type parameters.

      If metamail is called, behaviour depends of metamail.

###    (6)   Explicitly handle the following media type values, to
###          at least the following extents:

###          Text:

###            -- Recognize and display "text" mail with the
###            character set "US-ASCII."

      Elm ME+ displays text/plain mail with the character set 
      "US-ASCII." (at least if underlining system supports US-ASCII
      -- on other hand ELM ME+ do not support environments
      where that is not true -- systems with some ISO 646 set other
      than US-ASCII are perhaps exception.)

      It is possible define or redefine charset names of configuration
      file. With sufficient broken redefinition of charset US-ASCII,
      it is possible that Elm ME+ is do not have able to display
      text/plain mail with the character set  "US-ASCII."

      If system supports some other ISO 646 set than US-ASCII, Elm ME+
      is not able to print all US-ASCII characters.

      User have possibility with 'O' (Override charset) command
      change charset of charset. That may change behaviour. In that
      case also charset parameter of mail is ignored.

###            -- Recognize other character sets at least to the
###            extent of being able to inform the user about what
###            character set the message uses.

      Elm ME+ prints character set's name or value of charset
      parameter if it is unknown or unsupported.

###            -- Recognize the "ISO-8859-*" character sets to the
###            extent of being able to display those characters that
###            are common to ISO-8859-* and US-ASCII, namely all
###            characters represented by octet values 1-127.

      Elm ME+ should be able to work environment, where display and 
      system supports only some ISO 646 sets. On these systems
      all US-ASCII characters are not printable. 

      If ELM ME+ do no able to display US-ASCII, it probably
      also do not have able to display ASCII parts of these
      charsets.

      If elmrc page-known-charsets is OFF (default ON) and metamail is 
      available and elmrc option "metamail" is not value "none", mail 
      with other than system or display charset is passed to metamail.
      So behaviour depends of metamail on that case.

      1) Metamail usually pages text directly to terminal without
         taking account of charset.

      If metamail is not used:

      Assuming that underlining system supports US-ASCII, ELM ME+
      usually recognize "ISO-8859-*" character sets and display
      ASCII part of them.

      There is definition for existing "ISO-8859-*" character sets
      so that these treated as superset of US-ASCII. It is possible 
      define or redefine charset names of configuration file. With
      sufficient broken definition or redefinition of some ISO-8859-*
      set that this is not true.

      If "ISO-8859-*" character sets is not defined and elmrc
      option "auto-iso-8859" is ON (default ON), given charset is
      automatically defined to be superset of OS-ASCII.

      If charset is not defined or is defined to unknown, metamail is 
      available and elmrc option "metamail" is not value "none", mail
      is passed to metamail. So behaviour depends of metamail on that 
      case.

      User have possibility with 'O' (Override charset) command
      change charset of mail. That may change behaviour. In that
      case also charset parameter of mail is ignored.

###            -- For unrecognized subtypes in a known character
###            set, show or offer to show the user the "raw" version
###            of the data after conversion of the content from
###            canonical form to local form.

      Elm ME+ provides limited internal mailcap parser. If mailcap
      specifies program for content-type and Elm ME+ is able to
      support line on mailcap, Elm ME+ provides possibility to pass
      data to external program. But that case perhaps is not
      unrecognized subtype (if wildcars is not used on mailcap.)

      If metamail is available and elmrc option "metamail" is not value 
      "none", mail with unrecognized subtypes of text is passed to
      metamail. So behaviour depends of metamail on that 
      case.

      Otherwise Elm ME+ handles unrecognized subtypes of text 
      as "text/plain".

###             -- Treat material in an unknown character set as if
###            it were "application/octet-stream".

       If metamail is available and elmrc option "metamail" is not value 
      "none", mail with unknown charset is passed to metamail. So behaviour 
       depends of metamail on that case.

      1) Metamail usually pages text directly to terminal without
         taking account of charset.

      If metamail is not used:
      
      ELM ME+ provides way to save text on decoded form. Text is not 
      displayed.

      User have possibility with 'O' (Override charset) command
      change charset of mail. That may change behaviour. In that
      case also charset parameter of mail is ignored.

###         Image, audio, and video:

###           -- At a minumum provide facilities to treat any
###          unrecognized subtypes as if they were
###          "application/octet-stream".

      ELM ME+ provides way to save  both unrecognized subtypes
      of Image, audio, and video and application/octet-stream on
      decoded form if  content-transfer-encoding is recognized and
      supported.

###          Application:

###            -- Offer the ability to remove either of the quoted-
###            printable or base64 encodings defined in this
###            document if they were used and put the resulting
###            information in a user file.

      Elm ME+ provides way to save  subtypes on decoded form if  
      content-transfer-encoding is recognized and supported.

###          Multipart:

###            -- Recognize the mixed subtype.  Display all relevant
###            information on the message level and the body part
###            header level and then display or offer to display
###            each of the body parts individually.

      Elm ME+ recognizes multipart/mixed. Handling of message depends 
      are all subparts supported or not.

      If subparts are unrecognized and elmrc option "pagemultipart"
      is OFF (default OFF),  metamail is available and elmrc option 
      "metamail" is not value "none", mail on that case is passed to
      metamail. So behaviour depends of metamail on that case.

      On some conditions subparts is passed to external program using 
      ELM ME+'s internal mailcap parser.


###            -- Recognize the "alternative" subtype, and avoid
###            showing the user redundant parts of
###            multipart/alternative mail.

      Elm ME+ recognizes multipart/alternative. Handling of message 
      depends are all or some subparts supported or not. Elm ME+
      may either itself show multipart/alternative message or pass
      it to metamail (and perhaps on some conditions to external
      program via using it's internal mailcap parser.)

      When Elm ME+ handles itself multipart/alternative, it shows
      only one subpart from it.

      Also if metamail is called, it shows only one subpart from
      multipart/alternative.

###            -- Recognize the "multipart/digest" subtype,
###            specifically using "message/rfc822" rather than
###            "text/plain" as the default media type for body parts
###            inside "multipart/digest" entities.

      Elm ME+ recognizes multipart/mixed. Handling of message depends 
      are all subparts supported or not.

      Elm ME+ treats "message/rfc822" as default media type for
      subtypes instead of "text/plain". Otherwise "multipart/digest"
      is basically handled same way than "multipart/mixed".

###            -- Treat any unrecognized subtypes as if they were
###            "mixed".

      If elmrc option "pagemultipart" is OFF (default OFF),  metamail 
      is available and elmrc option  "metamail" is not value "none", 
      mail on that case is passed to metamail. 

      On some conditions mail is passed to external program via using 
      it's internal mailcap parser.

      Otherwise mail is treated as "multipart/mixed."

###          Message:

###            -- Recognize and display at least the RFC822 message
###            encapsulation (message/rfc822) in such a way as to
###            preserve any recursive structure, that is, displaying
###            or offering to display the encapsulated data in
###            accordance with its media type.

     Elm ME+ recognizes message/rfc822. Handling of message depends 
     are all subparts of recursive structure supported or not.

###            -- Treat any unrecognized subtypes as if they were
###            "application/octet-stream".

      Elm ME+ recognizes multipart/mixed. Handling of message depends 
      are all subparts supported or not.

      If subparts are unrecognized and elmrc option "pagemultipart"
      is OFF (default OFF),  metamail is available and elmrc option 
      "metamail" is not value "none", mail on that case is passed to
      metamail. So behaviour depends of metamail on that case.

      On some conditions subparts is passed to external program using 
      ELM ME+'s internal mailcap parser.

###    (7)   Upon encountering any unrecognized Content-Type field,
###          an implementation must treat it as if it had a media
###          type of "application/octet-stream" with no parameter
###          sub-arguments.  How such data are handled is up to an
###          implementation, but likely options for handling such
###          unrecognized data include offering the user to write it
###          into a file (decoded from its mail transport format) or
###          offering the user to name a program to which the
###          decoded data should be passed as input.

      ELM ME+ provides way to save unrecognized subtypes on decoded form 
      if  content-transfer-encoding is recognized and supported.

      If content-type is unrecognized and elmrc option "pagemultipart"
      is OFF (default OFF),  metamail is available and elmrc option 
      "metamail" is not value "none", mail on that case is passed to
      metamail. So behaviour depends of metamail on that case.

      On some conditions part is passed to external program using 
      ELM ME+'s internal mailcap parser.

      Elm ME+ do not offer the user to name a program to which the
      decoded data should be passed as input. Except via mailcap
      mechanism.

###    (8)   Conformant user agents are required, if they provide
###          non-standard support for non-MIME messages employing
###          character sets other than US-ASCII, to do so on
###          received messages only. Conforming user agents must not
###          send non-MIME messages containing anything other than
###          US-ASCII text.

###          In particular, the use of non-US-ASCII text in mail
###          messages without a MIME-Version field is strongly
###          discouraged as it impedes interoperability when sending
###          messages between regions with different localization
###          conventions. Conforming user agents MUST include proper
###          MIME labelling when sending anything other than plain
###          text in the US-ASCII character set.

      1) If Elm ME+ is mailing of form

	    Content-Type: mailform

	  it may include other than US-ASCII text and it is 
          non-MIME message (it is unclear can be that format 
          invoked.)

###          In addition, non-MIME user agents should be upgraded if
###          at all possible to include appropriate MIME header
###          information in the messages they send even if nothing
###          else in MIME is supported.  This upgrade will have
###          little, if any, effect on non-MIME recipients and will
###          aid MIME in correctly displaying such messages.  It
###          also provides a smooth transition path to eventual
###          adoption of other MIME capabilities.

       (Seems irrelevant.)

###    (9)   Conforming user agents must ensure that any string of
###          non-white-space printable US-ASCII characters within a
###          "*text" or "*ctext" that begins with "=?" and ends with
###          "?=" be a valid encoded-word.  ("begins" means: At the
###          start of the field-body or immediately following
###          linear-white-space; "ends" means: At the end of the
###          field-body or immediately preceding linear-white-
###          space.) In addition, any "word" within a "phrase" that
###          begins with "=?" and ends with "?=" must be a valid
###          encoded-word.

        1) This is not done if Elm ME+ is mailing of form

	    Content-Type: mailform

            (it is unclear can be that format invoked.)

        2) This is not done, if elmrc option "nohdrencoding"
           have value ON (default OFF.)

        Otherwise it is believed, that this is ensured. 

###    (10)  Conforming user agents must be able to distinguish
###          encoded-words from "text", "ctext", or "word"s,
###          according to the rules in section 4, anytime they
###          appear in appropriate places in message headers.  It
###          must support both the "B" and "Q" encodings for any
###          character set which it supports.  

        1) This is not done if X-ELM-OSV: -header includes parameter
           no-hdr-encoding=1. That parameter and header is added by
           Elm ME+ on mailing, if elmrc option "nohdrencoding"
           have value ON (default OFF.)

           ( Actually header reads as
	     X-ELM-OSV: (Our standard violations)
           )

        2) That is not done if message have not MIME-Version header
	   and elmrc option "require-mime-version-for-hdr-encoding"
           have value ON (default OFF.)

	Otherwise it is believed that this is done. However that
        requires quite complete parser for mail headers so that
        "*text" and "*ctext" are recognized correctly and that
	decoding is not tried on other places.

###                                           The program must be
###          able to display the unencoded text if the character set
###          is "US-ASCII".

        It is possible define or redefine charset names of configuration
        file. With sufficient broken redefinition of charset US-ASCII,
        this is not done.

        Otherwise this is done.
      
###                          For the ISO-8859-* character sets, the
###          mail reading program must at least be able to display
###          the characters which are also in the US-ASCII set.

      There is definition for existing "ISO-8859-*" character sets
      so that these treated as superset of US-ASCII. It is possible 
      define or redefine charset names of configuration file. With
      sufficient broken definition or redefinition of some ISO-8859-*
      set that this is not true.

      If "ISO-8859-*" character sets is not defined and elmrc
      option "auto-iso-8859" is ON (default ON), given charset is
      automatically defined to be superset of OS-ASCII.

