Subject: [EAI] #1485 "is intended to be transportable as part of an ordinary [RFC2822] message" (Re: #1485: Choices)

From: Kari Hurtta <[email-masked]>
Date: Tue, 22 May 2007 06:33:37 +0300 (EEST)

>>> Harald Alvestrand
> Kari Hurtta wrote:
> > Harald Tveit Alvestrand <[email-masked]> writes:
> >
> >
> >   
> >> ------------ Forwarded Message ------------
> >> Subject: [psg.com #1485]: UTF8HDR 4.6/DSN: Choice of body part for
> >> transport of UTF8SMTP messages
> >>
> >> The choice of the body part to transport UTF8SMTP messages in a message
> >> has proved controversial.
> >> Suggestions include:
> >>
> >> - message/utf8 (inconsistent with certain statements in the MIME RFCs)
> >> - application/utf8smtp (stylistically questionable)
> >> - message/rfc822 (incompatible with existing definition)
> >>
> >> A decision needs to be made.
> >>     
> >
> > In another message you said:
> >
> >     Downgrading to message/rfc822 is not completely beyond the realm of the
> >     reasonable (imho).
> >
> >
> > However seems that you did not listed that alternative
> >
> >    - message/utf8 on UTF8SMTP compliant environment,
> >        downgraded it to message/rfc822 outside of UTF8SMTP environment 
> >
> >
> > To me it looks that on this alternative there is no problems
> > mentioned inside of ( ) on list.
> >
> >
> > Or what I have missed?
> >   
> This is not an alternative for carrying an UTF8SMTP message.
> It is an alternative for what to do with an UTF8SMTP message that is 
> carried as part of another message when it hits a UTF8SMTP-to-2821 
> gateway, which is a separable issue.
> 
> I believe that to be an issue that needs to be addressed in the 
> downgrading document, not the utf8hdr document.

There is sentence on utf8hdr document which is affected:

|  the object defined in [EAI-dsn] is intended to be transportable as
|   part of an ordinary [RFC2822] message.

That sentence imply that if message/utf8  is selected, it is not 
downgraded.   So it is part of that issue. That is on chapter 4.6
on draft-ietf-eai-utf8headers-05.txt.

/ Kari Hurtta

> > ( This do not imply that I prefer that alternative. I just noted that
> >   downgrading alternative was not listed. )
> >
> >
> > / Kari Hurtta
> >
> > PS.  That was Picture 4 on my message "Ascii user X sends mail"
> >      (and alternative 1 on my message "UTF8SMTP / 8BITMIME / ASCII -universe 
> >       amd message/utf8smtp").

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

---

From: Yuri Inglikov <[email-masked]>
Date: Wed, 23 May 2007 00:21:43 -0700

+1 for message/rfc822.

I think that even if it leaks outside UTF8SMTP environment without downgrading (which /normally/ should not happen), it is better if older applications can at least partially interpret it / show most of the content than let them deal with unknown subtype of a message/ (which they certainly unable to) or deal with unstructured blob attachment (application/utf8smtp or anything like that). I don't quite understand the hesitation to extend the meaning of message/rfc822 to allow UTF8 content in UTF8SMTP environment. Isn't it very similar to allowing any other incompatible thing in such environment, like address headers with UTF8 local parts? Any such extensions likely will cause same problems if leaked outside UTF8SMTP environment. On the other hand, most applications are robust enough to deal with unexpected / malformed MIME content and could be able to reasonably recover in most cases if faced with UTF8 embedded message.

Yuri Inglikov