Subject: [EAI] Request for review of EAI MIME types

From: Harald Alvestrand <[email-masked]>
Date: Mon, 21 Jan 2008 11:35:32 +0100

This is the formal request for review for the following media types that 
have been defined in the Email Address Internationalization WG, and 
published in the drafts

draft-ietf-eai-utf8headers-08
draft-ietf-eai-dsn-05

The extracted templates are given below. For full context, read the drafts.

If possible, keep the EAI WG copied on any substantive comments.

                Harald Alvestrand, EAI WG chair

=== message/global, from draft-ietf-eai-utf8headers-08 =====

   Type name:  message

   Subtype name:  global

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  Any content-transfer-encoding is permitted.
      The 8-bit or binary content-transfer-encodings are recommended
      where permitted.

   Security considerations:  See Section 6

   Interoperability considerations:  The media type provides
      functionality similar to the message/rfc822 content type for email
      messages with international email headers.  When there is a need
      to embed or return such content in another message, there is
      generally an option to use this media type and leave the content
      unchanged or downconvert the content to message/rfc822.  Both of
      these choices will interoperate with the installed base, but with
      different properties.  Systems unaware of international headers
      will typically treat a message/global body part as an unknown
      attachment, while they will understand the structure of a message/
      rfc822.  However, systems which understand message/global will
      provide functionality superior to the result of a down-conversion
      to message/rfc822.  The most interoperable choice depends on the
      deployed software.

   Published specification:  RFC XXXX

   Applications that use this media type:  SMTP servers and email
      clients that support multipart/report generation or parsing.
      Email clients which forward messages with international headers as
      attachments.

   Additional information:

   Magic number(s):  none

   File extension(s):  The extension ".u8msg" is suggested.

   Macintosh file type code(s):  A uniform type identifier (UTI) of
      "public.utf8-email-message" is suggested.  This conforms to
      "public.message" and "public.composite-content" but does not
      necessarily conform to "public.utf8-plain-text".

   Person & email address to contact for further information:  See the
      Author's address section of this document.

   Intended usage:  COMMON

   Restrictions on usage:  This is a structured media type which embeds
      other MIME media types.  The 8-bit or binary content-transfer-
      encoding MUST be used unless this media type is sent over a 7-bit
      only transport.

   Author:  See Author's Address section of this document.

   Change controller:  IETF Standards Process

=== Message/global-headers, from draft-ietf-eai-dsn-05 ===

   Type name:  message

   Subtype name:  global-headers

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  This media type contains Internationalized
      Email Headers [I-D.ietf-eai-utf8headers] with no message body.
      Whenever possible, the 8-bit content transfer encoding SHOULD be
      used.  When this media type passes through a 7-bit-only SMTP
      infrastructure it MAY be encoded with the base64 or quoted-
      printable content transfer encoding.

   Security considerations:  See Section 7

   Interoperability considerations:  It is important this media type is
      not converted to a charset other than UTF-8.  As a result,
      implementations MUST NOT include a charset parameter with this
      media type.  Although it might be possible to downconvert this
      media type to the text/rfc822-header media type, such conversion
      is discouraged as it loses information.

   Published specification:  RFC XXXX

   Applications that use this media type:  UTF8SMTP servers and email
      clients that support multipart/report generation or parsing.
   Additional information:

   Magic number(s):  none

   File extension(s):  In the event this is saved to a file, the
      extension ".u8hdr" is suggested.

   Macintosh file type code(s):  The 'TEXT' type code is suggested as
      files of this type are typically used for diagnostic purposes and
      suitable for analysis in a UTF-8 aware text editor.  A uniform
      type identifier (UTI) of "public.utf8-email-message-header" is
      suggested.  This type conforms to "public.utf8-plain-text" and
      "public.plain-text".

   Person & email address to contact for further information:  See the
      Author's address section of this document.

   Intended usage:  COMMON

   Restrictions on usage:  This media type contains textual data in the
      UTF-8 charset.  It typically contains octets with the 8th bit set.
      As a result a transfer encoding is required when a 7-bit transport
      is used.

   Author:  See Author's Address section of this document.

   Change controller:  IETF Standards Process

=== Message/global-delivery-status, from draft-ietf-eai-dsn-05 ===

   Type name:  message

   Subtype name:  global-delivery-status

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  This media type contains delivery status
      notification attributes in the UTF-8 charset.  The 8-bit content
      transfer encoding MUST be used with this content-type, unless it
      is sent over a 7-bit transport environment in which case quoted-
      printable or base64 may be necessary.

   Security considerations:  See Section 7

   Interoperability considerations:  This media type provides
      functionality similar to the message/delivery-status content type
      for email message return information.  Clients of the previous
      format will need to be upgraded to interpret the new format,
      however the new media type makes it simple to identify the
      difference.

   Published specification:  RFC XXXX

   Applications that use this media type:  SMTP servers and email
      clients that support delivery status notification generation or
      parsing.

   Additional information:

   Magic number(s):  none

   File extension(s):  The extension ".u8dsn" is suggested.

   Macintosh file type code(s):  A uniform type identifier (UTI) of
      "public.utf8-email-message-delivery-status" is suggested.  This
      type conforms to "public.utf8-plain-text".

   Person & email address to contact for further information:  See the
      Author's address section of this document.

   Intended usage:  COMMON

   Restrictions on usage:  This is expected to be the second part of a
      multipart/report.

   Author:  See Author's Address section of this document.

   Change controller:  IETF Standards Process

=== Message/global-disposition-notification, from draft-ietf-eai-dsn-05 ===

   Type name:  message

   Subtype name:  global-disposition-notification

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  This media type contains disposition
      notification attributes in the UTF-8 charset.  The 8-bit content
      transfer encoding MUST be used with this content-type, unless it
      is sent over a 7-bit transport environment in which case quoted-
      printable or base64 may be necessary.

   Security considerations:  See Section 7

   Interoperability considerations:  This media type provides
      functionality similar to the message/disposition-notification
      content type for email message disposition information.  Clients
      of the previous format will need to be upgraded to interpret the
      new format, however the new media type makes it simple to identify
      the difference.

   Published specification:  RFC XXXX

   Applications that use this media type:  Email clients or servers that
      support message disposition notification generation or parsing.

   Additional information:

   Magic number(s):  none

   File extension(s):  The extension ".u8mdn" is suggested.

   Macintosh file type code(s):  A uniform type identifier (UTI) of
      "public.utf8-email-message-disposition-notification" is suggested.
      This type conforms to "public.utf8-plain-text".

   Person & email address to contact for further information:  See the
      Author's address section of this document.

   Intended usage:  COMMON

   Restrictions on usage:  This is expected to be the second part of a
      multipart/report.

   Author:  See Author's Address section of this document.

   Change controller:  IETF Standards Process

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 21 Jan 2008 12:16:33 +0100

> Subtype name:  global
[...]
>    Email clients which forward messages with international
>    headers as attachments.

Those are important cases where a Content-Type: message/global
is *explicitly* used.  For an ordinary 2822upd Internet message
the message doesn't explicitly say that it is a message/rfc822,
because that's understood for SMTP MAIL/SAML/SOML DATA (I'm not
sure about SEND, forget it, that's anyway obsolete).

Likewise it's understood that an NNTP message is a message/news
until USEFOR confirms that this is the same as a message/rfc822,
as noted in RFC 2045 IIRC.  (Or whoever deprecates message/news,
it doesn't need to be USEFOR, but likely it has to be a RFC)

Therefore a message with an UTF-8 header transmitted by UTF8SMTP
is *implicitly* a message/global, and the applications that use
this media type include anything supporting EAI - not only the
explicit cases mentioned in the registration template.

 Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 21 Jan 2008 23:53:12 +0100

Thanks Frank - this was obviously not fixed after the move of the MIME type 
definition from the dsn to the utf8hdr spec.

                   Harald

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 24 Jan 2008 14:19:10 -0500

I'm no subject matter expert in this space, but everything looks in
order from a registration process POV.  The security considerations
sections weren't included in your message, but are found in the
drafts, and they appear fine.

Mark.