[EAI] Re: POLL: on the "what MIME type" question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EAI] Re: POLL: on the "what MIME type" question



Harald Alvestrand <harald at alvestrand.no> writes in gmane.ietf.ima:

> This is a poll to determine if there is a WG consensus on the various
> issues surrounding the MIME type for carrying UTF8SMTP messages.
> 
> To reply to the poll, send a message to the list, or to both WG
> chairs, before JUNE 29, 2007, 12:00 GMT. The chairs will tally the
> responses and report the results; names of respondents will be
> included in the tally.
> 
> This poll asks questions about the carriage of messages that make use of
> the extensions described in draft-ietf-eai-utf8hdrs, when they are
> part of another message. In the text below, we call them UTF8SMTP
> messages, without prejudice to what we end up naming them.
> 
> The questions below are not unrelated; the poll is intended to show
> strong preferences, it is not a replacement for informed debate.
> 
> QUESTION 1: Should there be a new MIME type for UTF8SMTP messages when
> carried inside messages in an UTF8SMTP environment?
> 
> A: No, message/rfc822 can be used.
> B: Yes.
> C: I have another opinion, which is....

0  -- No strong preferece, slighly A -- I think that it is used anyway

> QUESTION 2: Should the same MIME type be used to carry UTF8SMTP messages in
> a SMTP environment (without the UTF8SMTP extension, and without requiring
> the 8BITMIME extension)?
> This implies that it's possible to encode the message.
> 
> A: Yes.
> B: No, that should not be allowed.
> C: I have another opinion, which is....

C   -- Depends what is MIME type to carry UTF8SMTP messages

       If type is message/rfc822, or new type is any message/*
       then B

       - Encoding of message/* conflicts with RFC 2045
         (it is not possible to encode message)

       If UTF8SMTP message does not actually include UTF8SMTP 
       addresses, it need to be downgraded.

       
       Using of any message/* for carrying  UTF8SMTP messages 
       in 8BITMIME or SMTP environment is too dangerous.


> QUESTION 3: Should the new type be a subtype of Message/?
> 
> A: Yes
> B: No, it should be application/something
> C: I have another opinion, which is....

C -- No strong preference, can be subtype of Message/ inside of 
     UTF8SMTP environment

     Carefully selected application/* can be used, if name refers
     to email.


> QUESTION 4: What should the new MIME type be called?
> 
> A: Message/utf8smtp
> B: Message/i18n
> C: Message/international
> D: Message/global
> E: Message/rfcxxxx (to be assigned)
> F: Message/rfc822 (consistent with an "A" answer on question 1)
> G: Message/utf8
> H: Message/rfc822u
> I: Message/mail
> J: Message/i18n-email
> K: Message/eai
> L: Message/smtp
> M: Message/smtp8
> N: Message/utf8eai
> O: Message/utf8-headers
> P: Message/utf8-email
> Q: Message/ima
> R: Message/intl-email
> S: I have another opinion, which is....
> 

F, P, N

S: application/utf8-email 

S: Message/eai-email

S: application/eai-email

( somewhat in order -- not sure is utf8-email or eai-email better )


> _______________________________________________
> EAI-DT mailing list
> EAI-DT at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/eai-dt

/ Kari Hurtta



_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.