From ima-bounces@ietf.org Fri Jun 01 04:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu26x-0003nL-F1; Fri, 01 Jun 2007 04:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu26w-0003n8-9t for ima@ietf.org; Fri, 01 Jun 2007 04:03:50 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu26u-0007gJ-MZ for ima@ietf.org; Fri, 01 Jun 2007 04:03:50 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5183m4p029918 for ; Fri, 1 Jun 2007 08:03:48 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIY00D0155WJB00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 01 Jun 2007 02:03:48 -0600 (MDT) Received: from [192.168.2.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIY00GW96E83350@mail-amer.sun.com>; Fri, 01 Jun 2007 02:03:47 -0600 (MDT) Date: Thu, 31 May 2007 19:41:18 -0700 From: Chris Newman Subject: Re: [EAI] #1485: Choice of body part for transport of UTF8SMTP messages In-reply-to: <5dfy5ib7dp.fsf@Hurtta06k.keh.iki.fi> To: Kari Hurtta , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> <5dfy5ib7dp.fsf@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org NOTE: This is my opinion as a technical contributor, not as area director. When an SMTP server advertises "UTF8SMTP", it is saying "I accept either RFC 822 and UTF8SMTP messages". So the DATA command (or BDAT/BURL command) is not a type label, it's merely a mechanism to carry one of the supported types. Indeed SMTP was originally designed as a generic transfer protocol and the fact RFC 822 / MIME is the only format presently used is an accident of history. What concerns me with UTF8SMTP content in a message/rfc822 body part is the use of an explicit type label in a way that is known to be incompatible with the current defined meaning for that type. Perhaps we could get away with it if we could guarantee it would never ever leak to a non-UTF8SMTP system. But this is a redefinition of the meaning of a standards track type label as opposed to an isolated extension to existing protocols. I'm a lot more comfortable with message/utf8smtp as today's MIME compliant systems are expected to treat unknown message subtypes as equivalent to application/octet-stream, much as systems unfamiliar with application/zip treat it as an opaque object. With message/utf8smtp, existing message/rfc822 systems can be vetted to make sure they're UTF-8 clean, address the UTF-8 security considerations and then add "message/utf8smtp" to the list of compound types they descend. - Chris Kari Hurtta wrote on 5/27/07 6:42 PM +0300: > Harald Tveit Alvestrand writes in gmane.ietf.ima: > >> 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. > > I prefer > UTF8SMTP messages labeled as message/rfc822 on UTF8SMTP environment > and then downgraded to RFC 2822 messages when then leave UTF8SMTP > environment. > > > On downgrading there is two different cases > A) bounce/reject is available > B) bounce/reject is not available > > Case A is when downgrading is done by UTF8SMTP gateway on smtp when envelope > sender is not <>. > > Case B is when downgrading is done after delivery (for example on IMAP or > POP server) or when downgrading is done by UTF8SMTP gateway on smtp when > envelope sender is <>. > > In case A if downgrading of attached message (with type message/rfc822) > fails, enclosed message is rejected or bounced (NDN generated). > > In case B is it is just better leave out data what is not downgradeable > (for example if there is no alternative address for some address on header) > or on extreme case left out whole message/rfc822 body part. > > > ( In case B also some other options exists, but they are better discussed > when downgrading document is on subject. Also if embedded message is not > downgradeable, one option is do some sort encapsulation on both > cases A and B ) > > > For why I prefer message/rfc822 I have mentioned these reasons already: > > When working group was decided that there is no need labeling > for UTF8SMTP messages, that quite clearly follow that UTF8SMTP > messages does not need new label (ie. message/utf8 type) when > they are attached to another message. > > When whole message is not need labeling on UTF8SMTP case (ie no ESMTP > paramater), there is no need also different kind labeling if > message is attached to another message. > > That makes "message/rfc822" just mean "mail message". And consistent > that "message/rfc822" is just that type what occurs inside of DATA > on smtp. > > Actually "message/rfc822" is not mean to be only mail message, > but superset of it (rfc 2046): > > It should be noted that, despite the use of the numbers "822", a > "message/rfc822" entity isn't restricted to material in strict > conformance to RFC822, nor are the semantics of "message/rfc822" > objects restricted to the semantics defined in RFC822. More > specifically, a "message/rfc822" message could well be a News article > or a MIME message. > > > If there is reason why "message/rfc822" can not be used to > mean any mail message on UTF8SMTP universe, same problems are > also on top level. > > For example if there is some problems for IMAP on UTF8SMTP universe, > when UTF8SMTP message is attaches as "message/rfc822", same problems > also aply to top level message. > > > This issue have subject UTF8HDR 4.6. That chapter do not mention > MIME type of UTF8SMTP message at all. Instead that chapter says: > > the object defined in [EAI-dsn] is intended to be transportable as > part of an ordinary [RFC2822] message. > > That implies that UTF8SMTP messages transported inside of messages are not > downgraded. I prefer that they are downgraded. That is important when > this MIME type is just used for forwarding. > > On situation where UTF8SMTP messages start appear is when MUA and MSA supports > UTF8SMTP, and just non-ascii subject is used. If embedded messages are > downgraded when message is forwarded outside of UTF8SMTP environment, that > does not cause surprises. If downgrading is not done (and encapsulation is > done instead), recipient get different situation depending was just UTF8SMTP > MSA+MUA used. > > That is: End result outside of UTF8SMTP environment should be same on > following cases when non ascii subject is typed: > 1) MUA sends ordinary MIME message (non UTF8SMTP message) > 2) MUA sends UTF8SMTP message > On both cases end result outside of UTF8SMTP environment should be ordinary > MIME message with MIME encoded words on subject. And that should happend > even when this message leaves UTF8SMTP environment inside of another message. > > Perhaps that can be say also on following way: "Fully downgradeable UTF8SMTP > messages should be downgraded (and not encapsulated) when they leave UTF8SMTP > environment. And that does not depend is message stand alone or is it embedded > inside of another message." > > > > MIME type of UTF8SMTP message is mentioned on chapter 4.2 instead: > > In all those header fields, Observe that such Content-Type and other > header fields may be found both amongst the top-level fields of a > message and also within multiparts; and also that a complete message > conforming to this document may now appear as a message/rfc822 (in > both cases, subject to downgrade when that is necessary) > > > > application/utf8smtp have some values on situations where message is > not downgradeable. In that case that type can be used for encapsulation, > but I do not recommended it for general use. > > > message/utf8 is bad if UTF8SMTP content is not downgraded (and retyped > as message/rfc822) when message leaves UTF8SMTP environment. Some reasons > I have discussed on my messages with subjects > - Ascii user X sends mail > - UTF8SMTP / 8BITMIME / ASCII -universe amd message/utf8smtp > > > / Kari Hurtta > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 01 11:13:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8p0-0000Dm-PI; Fri, 01 Jun 2007 11:13:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8oz-0000Dh-7r for ima@ietf.org; Fri, 01 Jun 2007 11:13:45 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu8ox-0008TK-KW for ima@ietf.org; Fri, 01 Jun 2007 11:13:45 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hu8ow-000762-K3; Fri, 01 Jun 2007 11:13:43 -0400 Date: Fri, 01 Jun 2007 11:13:41 -0400 From: John C Klensin To: Chris Newman Subject: Re: [EAI] #1485: Choice of body part for transport of UTF8SMTP messages Message-ID: <70DA0946804490BEE5269C9E@p3.JCK.COM> In-Reply-To: References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> <5dfy5ib7dp.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi. I am personally gone back and forth on this one, but, at this point, find myself largely in agreement with Chris. See below. --On Thursday, 31 May, 2007 19:41 -0700 Chris Newman wrote: > NOTE: This is my opinion as a technical contributor, not as > area director. > > When an SMTP server advertises "UTF8SMTP", it is saying "I > accept either RFC 822 and UTF8SMTP messages". So the DATA > command (or BDAT/BURL command) is not a type label, it's > merely a mechanism to carry one of the supported types. Indeed > SMTP was originally designed as a generic transfer protocol > and the fact RFC 822 / MIME is the only format presently used > is an accident of history. As a historical note on that accident, some of us tried to preserve that "generic transfer" idea for many years. The notion of being able to accept an envelope-only message (i.e., construct headers on delivery if at all) was actually critical to the successful working of a number of gateways, just as the ability of accept header-only (RFC822, more or less) messages and construct an envelope in flight was essential for others. The issue was especially important before DRUMS deprecated the SMTP SEND command: many of us believed that the message data for SEND should be sent header-free since display of the headers on the user terminal would make the IM character of SEND essentially useless. Others believed that the headers should be sent but perhaps stripped by the receiver-SMTP, with only body content displayed. Of course, if one sent things without headers, and whatever passed for a mail store on the delivery system required them, SAML and SOML became tricky... but SMTP was designed for a "deliver to mailbox", rather than "deliver to mail store" model, and that, too, changes things. However, and particularly relevant to this work, the end of SMTP-as-generic-transport came, I think, with the extension mechanism. If one is going to have extensions that make assumptions about message content or that might result in transforming it, then there really needs to be a well-understood header format. So sending or accepting EHLO are now effectively an assertion of MIME-compliance. And that leads me to... > What concerns me with UTF8SMTP content in a message/rfc822 > body part is the use of an explicit type label in a way that > is known to be incompatible with the current defined meaning > for that type. Perhaps we could get away with it if we could > guarantee it would never ever leak to a non-UTF8SMTP system. > But this is a redefinition of the meaning of a standards track > type label as opposed to an isolated extension to existing > protocols. More important, I think all of our experience is that an assertion that one can guarantee that anything that appears in message content will never leak should be met with pained laughter. I don't see a big problem with modifying the presumed rule against having any message/ subtype whose content is non-ASCII, but I think there is a sufficient expectation that the headers of message/rfc822 is ASCII-only and non-extended that trying to change it is bad news -- the alternate use is just not sufficiently protected by an UTF8SMTP envelope environment. > I'm a lot more comfortable with message/utf8smtp > as today's MIME compliant systems are expected to treat > unknown message subtypes as equivalent to > application/octet-stream, much as systems unfamiliar with > application/zip treat it as an opaque object. > > With message/utf8smtp, existing message/rfc822 systems can be > vetted to make sure they're UTF-8 clean, address the UTF-8 > security considerations and then add "message/utf8smtp" to the > list of compound types they descend. Yes. In retrospect, the strong position I've taken against making this a subtree of application/ has to do with the opacity of that type. But treating it as a message/ subtype that might fall over to application/octet-stream works for me and seems to be a reasonable long-term, as well as short-term, mechanism. One request/suggestion: since users will see this subtype (just as they see, and sometimes even talk about, other subtype names), I hope that people who are better at picking names than I am can come up with something other than message/utf8smtp. First, this ought to have to do with the message, rather than how it is transported. And, second, this has more to do with i18n than with UTF-8 itself: I fear that message/utf8smtp will encourage someone to start thinking about message/is8859-1smtp or some such nonsense. I'd hope for something that is more along the lines of message/intl-email, but I'm not good at actual names. (I'm not ignoring Kari's comments about downgrading these things.. I just want to think more about that before commenting. If we are going to downgrade these things, they will need special handling in the downgrading document, but maybe we can isolate the issue there.) john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 03 16:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hux3g-0005tl-ET; Sun, 03 Jun 2007 16:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hux3f-0005tb-Bj for ima@ietf.org; Sun, 03 Jun 2007 16:52:15 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hux3e-00076i-2b for ima@ietf.org; Sun, 03 Jun 2007 16:52:15 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5D4D2596EE for ; Sun, 3 Jun 2007 22:52:08 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21882-03 for ; Sun, 3 Jun 2007 22:52:03 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67CA32596EA for ; Sun, 3 Jun 2007 22:52:03 +0200 (CEST) Message-ID: <466329F1.7050802@alvestrand.no> Date: Sun, 03 Jun 2007 22:52:01 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [EAI] Note on the design team X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org My AD reminded me that it is wise to keep the WG informed and updated on the existence of a design team, per standard IETF guidelines. So here goes: This WG has a design team consisting of the chairs and the document editors. The purpose of the team is to provide an opportunity to get quick feedback on documents and help suggest solutions to problems raised in the WG. The design team's role is not to make decisions (that is the prerogative of the WG), but to suggest proposals. The team meets occasionally by Jabber. The current members are: Abel Yang Alexey Melnikov Chris Newman Edmon Chung Kazunori Fujiwara Harald Alvestrand YAO Jiankang John Klensin Xiaodong Lee Yangwoo Ko Randall Gellens Pete Resnick Nai-Wen Hsu Yao Jiankang Yoshiro Yoneya Yangwoo Ko The team can be contacted at eai-dt@alvestrand.no. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 03 18:48:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huys6-0005HE-Tn; Sun, 03 Jun 2007 18:48:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huys5-0005H9-Hg for ima@ietf.org; Sun, 03 Jun 2007 18:48:25 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huys4-00046j-6P for ima@ietf.org; Sun, 03 Jun 2007 18:48:25 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A18992596EA; Mon, 4 Jun 2007 00:48:23 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24311-04; Mon, 4 Jun 2007 00:48:18 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 948E92596BF; Mon, 4 Jun 2007 00:48:18 +0200 (CEST) Message-ID: <46634530.8040901@alvestrand.no> Date: Mon, 04 Jun 2007 00:48:16 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Yuri Inglikov Subject: Re: [EAI] Re: #1485: Choices References: <4651FECF.2080908@alvestrand.no> <200705220333.l4M3Xbi4005542@siilo.fmi.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yuri Inglikov wrote: > +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. And using message/rfc822 would offer an easy and convenient means of leakage. Note that in the case of signed messages, you CANNOT downgrade on the border; in the case of encrypted messages, you can't even detect the MIME type of the inner part. > 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 > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 04 07:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvARn-0004q1-4S; Mon, 04 Jun 2007 07:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvARm-0004pg-2L for ima@ietf.org; Mon, 04 Jun 2007 07:10:02 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvARh-0006Z4-31 for ima@ietf.org; Mon, 04 Jun 2007 07:09:59 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3*clerew&man^ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4663f303.f316.490 for ima@ietf.org; Mon, 4 Jun 2007 12:09:55 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l54B9s7I022601 for ; Mon, 4 Jun 2007 12:09:54 +0100 (BST) Subject: Re: [EAI] #1485: Choice of body part for transport of UTF8SMTP messages References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> <5dfy5ib7dp.fsf@Hurtta06k.keh.iki.fi> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 04 Jun 2007 12:09:53 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 01 Jun 2007 03:41:18 +0100, Chris Newman wrote: > What concerns me with UTF8SMTP content in a message/rfc822 body part is > the use of an explicit type label in a way that is known to be > incompatible with the current defined meaning for that type. Perhaps we > could get away with it if we could guarantee it would never ever leak to > a non-UTF8SMTP system. Yes, that is an essential feature of any proposal to allow UTF8SMTP content in a message/rfc822. > But this is a redefinition of the meaning of a standards track type > label as opposed to an isolated extension to existing protocols. That might well be a valid argument were it not for the fact that we have already changed what is allowed within multipart/* types (when within the UTF8SMTP universe, of course). That is now solidly written into into both the utf8headers and downgrade drafts, and noone has raised any ISSUE against it. It leads, of course, straight to a requirement to scan the full body of each message looking for UTF-8 in suspicious places before you can declare that it is not a UTF8SMTP message, but we agreed on all that at the timne when we abolished the Header-Type header field. Now, since a message/rfc822 is rather similar in its structure to a multipart with only one part, it follows that whatever mechanisms an implementor has to deploy to deal with our extended multipart/* types is readily adaptable to deal with an extended message/rfc822, and whatever risks arise from UTF-8 leaking into the non-UTF8SMTP world are identical in the two cases. > I'm a lot more comfortable with message/utf8smtp as today's MIME > compliant systems are expected to treat unknown message subtypes as > equivalent to application/octet-stream, much as systems unfamiliar with > application/zip treat it as an opaque object. It is not clear to me that that requirement applies to unknown message/* types, since adhering to it produces objects that violate that "EXPRESSLY FORBIDDEN" provision in RFC 2045. But, first of all, we are proposing a new message/utf8smtp type without being given any clear indication of the properties it is supposed to possess. Everyone who advocate it seems to be working to a different model of what it actually does. So please can we have answers to some basic questions: 1. Is a message/utf8smtp supposed to be transportable without serious loss of information over the existing network? If not, then it would need to be downgraded somehow when leaving the UTF8SMTP world. 2. But if so, then what happens when it needs to be offered to a system that does not support BITMIME? Is it: a) rejected (5xx response or bounce) and is that rejection silent? b) converted to Q-P or Base64, as if it were application/octer-stream? c) passed onwards with the 8bit stuff still present? d) have the 8bit stuff truncated to 7bit? 3. IMO, only (a) is fully standards compliant, though you appear to argue that (b) is compliant too. 4. But, more to the point, what is the actual behaviour of currently deployed software, since that forms the environment with which EAI will need to interoperate when it is first deployed? So far, there have been reported 3 systems which exhibit behaviour (c), which between them account for a significant portion of the installed base. There have been rumours of ancient systems that supported (d). I have seen NO reports of systems which implement either (a) or (b) (though I have asked for such reports). It is really up to the people who advocate message/utf8smtp to provide answers to these questions because, unless a significant part of the installed base currently supports (a) or (b), or unless the answer to Question 1 is "No", then message/utf8smtp is simply not going to work. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 04 10:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDAr-0004tY-J1; Mon, 04 Jun 2007 10:04:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDAq-0004tT-Ox for ima@ietf.org; Mon, 04 Jun 2007 10:04:44 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvDAq-0001Ro-6Y for ima@ietf.org; Mon, 04 Jun 2007 10:04:44 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew^man$ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46641bfa.e8e9.286 for ima@ietf.org; Mon, 4 Jun 2007 15:04:42 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l54E4cag003344 for ; Mon, 4 Jun 2007 15:04:39 +0100 (BST) To: IMA Subject: Re: [EAI] Re: #1485: Choices References: <4651FECF.2080908@alvestrand.no> <200705220333.l4M3Xbi4005542@siilo.fmi.fi> <46634530.8040901@alvestrand.no> Message-ID: Date: Mon, 04 Jun 2007 15:04:37 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46634530.8040901@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 03 Jun 2007 23:48:16 +0100, Harald Alvestrand wrote: > Yuri Inglikov wrote: >> +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. > And using message/rfc822 would offer an easy and convenient means of > leakage. No more than using multipart/whatever with UTF-8 in Content-Description fields within its parts. Whilst all sorts of weird and wonderful departures from standards undoubtedly exist in the present network, if we cannot assume that implementors of a newly deployed feature such as UTF8SMTP will not follow our requirements, then there is not much hope for EAI. All that is required to prevent leakage is for MTAs that do downgrading to inspect all contained message/rfc822s to see if their headers contain 8bit (and so, recursively, for inner objects within the message/rfc822). > > Note that in the case of signed messages, you CANNOT downgrade on the > border; in the case of encrypted messages, you can't even detect the > MIME type of the inner part. Apart from DKIM signatures, which are a separate can of worms, I don't think other existing signature schemes are supposed to hide or alter the MIME structure of a message. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 04 12:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFqi-000189-RY; Mon, 04 Jun 2007 12:56:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFqh-000184-Vr for ima@ietf.org; Mon, 04 Jun 2007 12:56:07 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFqg-0002JP-EF for ima@ietf.org; Mon, 04 Jun 2007 12:56:07 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1HvFqf-0002pI-6h; Mon, 04 Jun 2007 12:56:05 -0400 Date: Mon, 04 Jun 2007 12:56:03 -0400 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Re: #1485: Choices Message-ID: <056DCC978B42A4C9F260B6FA@[192.168.1.110]> In-Reply-To: References: <4651FECF.2080908@alvestrand.no> <200705220333.l4M3Xbi4005542@siilo.fmi.fi> <46634530.8040901@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, June 04, 2007 3:04 PM +0100 Charles Lindsey wrote: >... >>> with UTF8 local parts? Any such extensions likely will >>> cause same problems if leaked outside UTF8SMTP environment. >> And using message/rfc822 would offer an easy and convenient >> means of leakage. > > No more than using multipart/whatever with UTF-8 in > Content-Description fields within its parts. Whilst all sorts > of weird and wonderful departures from standards undoubtedly > exist in the present network, if we cannot assume that > implementors of a newly deployed feature such as UTF8SMTP will > not follow our requirements, then there is not much hope for > EAI. All that is required to prevent leakage is for MTAs that > do downgrading to inspect all contained message/rfc822s to see > if their headers contain 8bit (and so, recursively, for inner > objects within the message/rfc822). Charles, having started out in favor of message/rfc822 and gradually changed my mind, I think the concern is that there are ways that things leak even in what is generally a conforming environment. We've had experience with that over and over again, to the point that it is hard to pretend that leaks cannot (or will not) happen. I fear that examples abound and that, while any one of them can be dismissed with an understanding of what can be done to prevent it, their number is such that we are very constrained if we want to be safe about these things in practice. If one were willing to adopt an "ok, in that situation, just-send-8" position and some of its corollaries, then this would get a little easier. I'm not, but that is just a personal opinion/ conviction/ preference. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 04 15:52:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIbC-00062v-AC; Mon, 04 Jun 2007 15:52:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIZV-0003fD-Df; Mon, 04 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvIZV-0002fc-0J; Mon, 04 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C5C7B175FC; Mon, 4 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HvIZ0-0002iD-Hu; Mon, 04 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 04 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-06.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-06.txt Pages : 20 Date : 2007-6-4 This document specifies the use of SMTP extension for internationalized email address delivery. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-4142557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-4142557.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Tue Jun 05 07:15:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvX0Y-0000Qm-6l; Tue, 05 Jun 2007 07:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvX0W-0000Mu-FQ for ima@ietf.org; Tue, 05 Jun 2007 07:15:24 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvX0T-0008UA-R3 for ima@ietf.org; Tue, 05 Jun 2007 07:15:24 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew^man*ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 466545c7.e1b8.117 for ima@ietf.org; Tue, 5 Jun 2007 12:15:19 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l55BFIiQ019391 for ; Tue, 5 Jun 2007 12:15:19 +0100 (BST) Date: Tue, 05 Jun 2007 12:15:18 +0100 To: IMA Subject: Re: [EAI] Re: #1485: Choices References: <4651FECF.2080908@alvestrand.no> <200705220333.l4M3Xbi4005542@siilo.fmi.fi> <46634530.8040901@alvestrand.no> <056DCC978B42A4C9F260B6FA@[192.168.1.110]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <056DCC978B42A4C9F260B6FA@[192.168.1.110]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 04 Jun 2007 17:56:03 +0100, John C Klensin wrote: > Charles, having started out in favor of message/rfc822 and gradually > changed my mind, I think the concern is that there are ways that things > leak even in what is generally a conforming environment. We've had > experience with that over and over again, to the point that it is hard > to pretend that leaks cannot (or will not) happen. I fear that examples > abound and that, while any one of them can be dismissed with an > understanding of what can be done to prevent it, their number is such > that we are very constrained if we want to be safe about these things in > practice. I suspect that leaks of UTF8SMTP messages into message/rfc822 objects visible in the non-utf-8 environment will mostly arise from current MUAs that manage to acquire a UTF8SMTP message somehow (not supposed to happen, but it will) and then try to forward it as a message/rfc822 attachment (clearly, such MUAs will not be aware that the attachment should have been message/utf8smtp or application/utff8smtp). So there is absolutely nothing we can do to stop this from happening; the best thing we can hope to do it to arrange that any UTF8SMTP-capable MTA that detects such a beast can at least downgrade it to something legal (unless the onward path is UT8SMTP-capable, of course). I doubt that such leaks are going to arise from MTAs that are truly UTF8SMTP-capable, which means that they are unlikely to arise in the course of DSNs that are simply returning the whole of the original UTF8SMTP message, since if they are smart enough to generate a DSN according to our documents, then they are probably smart enough to downgrade the returned message to something that is safe on the existing network (in cases where the return path is not UTF8SMTP). > > If one were willing to adopt an "ok, in that situation, just-send-8" > position and some of its corollaries, then this would get a little > easier. I'm not, but that is just a personal opinion/ conviction/ > preference. The real problem with message/utf8smtp (as opposed to some application/utff8smtp) is that we know that some existing agents will just "send it as 8bit", and we do not know of ANY existing agent (and I keep asking for counter examples) that will attempt to encode it in Q-P or Base64, as the people in Prague seemed to envisage. Basically, the message type in MIME was very badly designed. But there is not much that we can do about that except not to invent new message types. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 05 15:17:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveWb-0005yG-Pl; Tue, 05 Jun 2007 15:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveWa-0005yB-VO for ima@ietf.org; Tue, 05 Jun 2007 15:17:00 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HveWa-0001VT-Hv for ima@ietf.org; Tue, 05 Jun 2007 15:17:00 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1HveWZ-000MpZ-S8 for ima@ietf.org; Tue, 05 Jun 2007 15:17:00 -0400 Date: Tue, 05 Jun 2007 15:16:57 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [EAI] ISSUE: Trivial downgrading X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi. Kari and I have been having an offlist discussion that has inspired a thought. Suppose one has a message that has UTF-8 headers, but there are no non-ASCII addresses in the headers (either forward or backward-pointing). This may actually turn out to be a common case for people who stick with ASCII-addresses (either for interoperability or because, e.g., their names don't happen to require non-ASCII characters even if their languages are written using extended "Latin" scripts and do). But, if they are using UTF8SMTP-aware MUAs and Submission servers (MSAs), they are likely to be producing non-ASCII subject lines (as is the case today), but sending them as UTF-8 rather than as encoded words. There are some other cases, but this is the important one. At present, our rules appear to sent such messages through the entire downgrade process, generating Downgrade headers, etc. I wonder if, to make that class of cases efficient and maximize its utility, we ought to have a different downgrade path that simply: * Converts the known header fields containing UTF-8 data into the same fields with encoded words. * Documents the conversion only in trace information (i.e., no "Downgraded:" headers). * If any body parts or information require downgrading, treat them strictly according to the 8BITMIME rules, which would obviously apply. This would, of course, apply only if no non-ASCII addresses were present and all of the header fields that contained UTF-8 data were known (see below). The present downgrade procedure, and the conditions associated with it, would continue to apply to all other cases. The reason for a "known header" restriction is fear of information loss if we start tampering with headers that are not recognized, i.e., those for which explicit rules about encoding of non-ASCII information does not exist already. But the net effect of this approach would be to downgrade by recreating _exactly_ the types of messages that can be sent today (without the EAI extension), with no new headers or other material, from messages that are just the UTF-8 rendering of their encoded words ... almost exactly symmetric with the intent of the 8BITMIME transformations. Having two downgrade styles does add complexity, but because this one is simple enough and has no expectation about anything UTF8-aware on the far side of the downgrade (even aware enough to pass Downgraded header fields), maybe it would be more widely implemented and perceived as worth the trouble. Thoughts? I think that, if there is interest, Kari and I could write it up fairly quickly (for the record, he doesn't know that I'm volunteering him). john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 05 23:23:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvm7A-0001PF-PS; Tue, 05 Jun 2007 23:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvm78-0001PA-Pl for ima@ietf.org; Tue, 05 Jun 2007 23:23:14 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvm76-0007Tb-0O for ima@ietf.org; Tue, 05 Jun 2007 23:23:14 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l563N8Aj018368 for ; Wed, 6 Jun 2007 12:23:08 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 47af_3f1fa816_13dd_11dc_95c9_0014221fa3c9; Wed, 06 Jun 2007 12:23:07 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53634) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 6 Jun 2007 12:21:23 +0900 Message-Id: <6.0.0.20.2.20070606115057.07841e80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 06 Jun 2007 11:51:46 +0900 To: John C Klensin , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] ISSUE: Trivial downgrading In-Reply-To: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I haven't thought through every single detail of this, but I very much agree that it should be looked into further. Regards, Martin.s At 04:16 07/06/06, John C Klensin wrote: >Hi. > >Kari and I have been having an offlist discussion that has inspired a thought. > >Suppose one has a message that has UTF-8 headers, but there are no non-ASCII addresses in the headers (either forward or backward-pointing). This may actually turn out to be a common case for people who stick with ASCII-addresses (either for interoperability or because, e.g., their names don't happen to require non-ASCII characters even if their languages are written using extended "Latin" scripts and do). But, if they are using UTF8SMTP-aware MUAs and Submission servers (MSAs), they are likely to be producing non-ASCII subject lines (as is the case today), but sending them as UTF-8 rather than as encoded words. There are some other cases, but this is the important one. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 06 00:36:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvnFo-0000Jw-8h; Wed, 06 Jun 2007 00:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvnFm-0000Jf-Js for ima@ietf.org; Wed, 06 Jun 2007 00:36:14 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvnFl-0004Oh-1N for ima@ietf.org; Wed, 06 Jun 2007 00:36:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HvnFd-00072o-Qu for ima@ietf.org; Wed, 06 Jun 2007 06:36:05 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jun 2007 06:36:05 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jun 2007 06:36:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 06 Jun 2007 07:35:44 +0300 Lines: 91 Message-ID: <5dhcplog2n.fsf@Hurtta06k.keh.iki.fi> References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Kari Hurtta Subject: [EAI] Re: ISSUE: Trivial downgrading X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > Hi. > > Kari and I have been having an offlist discussion that has inspired a > thought. > > Suppose one has a message that has UTF-8 headers, but there are no > non-ASCII addresses in the headers (either forward or > backward-pointing). This may actually turn out to be a common case > for people who stick with ASCII-addresses (either for interoperability > or because, e.g., their names don't happen to require non-ASCII > characters even if their languages are written using extended "Latin" > scripts and do). But, if they are using UTF8SMTP-aware MUAs and > Submission servers (MSAs), they are likely to be producing non-ASCII > subject lines (as is the case today), but sending them as UTF-8 rather > than as encoded words. There are some other cases, but this is the > important one. Yes. Some background (some of these I have mentioned ealier, but not all). I have noted: I think that case, where message is turned originally (when sent) to UTF8SMTP only because subject was UTF-8, should be transparent. This means that, when message is later forwarded as mime attachment (with type message/rfc822 or message/utf8smtp), this mime attachment need to be downgraded to regular RFC2822 message/rfc822 on border of UTF8SMTP universe. That non-ASCII Subject often occur on Finnish mail (grep from one folder -- most of mails (but not all) are Finnish: hurtta$ formail -c < List/grp | fgrep Subject: | fgrep '=?' | wc -l 1308 hurtta$ formail -c < List/grp | fgrep Subject: | wc -l 3815 hurtta$ ) Non-ASCII letters, which occurs on Finnish, are ä and ö (mostly ä). These (ä and ö) are are not very often used on names. It is is hard to estimate. It is more common on surname. Most common first names (given names) on Finland: https://192.49.222.187/Nimipalvelu/nimipalvelu_etunimitop.asp?L=3 on 10 most common there is no ä or ö Most common surnames (family names) on Finland: https://192.49.222.187/Nimipalvelu/nimipalvelu_sukunimitop.asp?L=3 on 10 most there names there is 4 with ä So it is likely that UTF8SMTP mail addresses are never very common. This combination makes likely that great part of UTF8SMTP messages because of UTF-8 Subject and not UTF8SMTP address. ( And it is likely that mail server is changed according on what network you are connected. So MSA can suddenly come to UTF8SMTP aware :-) Port 25 is closed by order of Finnish Communications Regulatory Authority (FICORA) on consumer subscription line. (That order of course do not prevent sending mail via home server with port 587 or 465 (non standard)). ) Using of UTF8SMTP on MUA may be configuration switch or automatic. I noted earlier on one message: MUA which is used to send message is UTF8SMTP capable. Because UTF8SMTP is negotiated proprerty, there is no "use UTF8SMTP" switch on MUA. That just confuses users. This perhaps gives some perpective, how I look situation :-) > Thoughts? I think that, if there is interest, Kari and I could write > it up fairly quickly (for the record, he doesn't know that I'm > volunteering him). > > john Hmm. Now I know... That "Trivial Downgrading" did not occured on discussion :-) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 02:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwBU9-0001fR-Fq; Thu, 07 Jun 2007 02:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwBU7-0001fF-KS for ima@ietf.org; Thu, 07 Jun 2007 02:28:39 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwBU7-0000fK-4A for ima@ietf.org; Thu, 07 Jun 2007 02:28:39 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jun 2007 07:28:37 +0100 Message-ID: <4667A545.9090107@isode.com> Date: Thu, 07 Jun 2007 07:27:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin Subject: Re: [EAI] ISSUE: Trivial downgrading References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> In-Reply-To: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Hi. > > Kari and I have been having an offlist discussion that has inspired a > thought. > > Suppose one has a message that has UTF-8 headers, but there are no > non-ASCII addresses in the headers (either forward or > backward-pointing). This may actually turn out to be a common case > for people who stick with ASCII-addresses (either for interoperability > or because, e.g., their names don't happen to require non-ASCII > characters even if their languages are written using extended "Latin" > scripts and do). But, if they are using UTF8SMTP-aware MUAs and > Submission servers (MSAs), they are likely to be producing non-ASCII > subject lines (as is the case today), but sending them as UTF-8 rather > than as encoded words. There are some other cases, but this is the > important one. > > At present, our rules appear to sent such messages through the entire > downgrade process, generating Downgrade headers, etc. > > I wonder if, to make that class of cases efficient and maximize its > utility, we ought to have a different downgrade path that simply: > > * Converts the known header fields containing UTF-8 data > into the same fields with encoded words. > > * Documents the conversion only in trace information (i.e., > no "Downgraded:" headers). > > * If any body parts or information require downgrading, > treat them strictly according to the 8BITMIME rules, which > would obviously apply. > > This would, of course, apply only if no non-ASCII addresses were > present and all of the header fields that contained UTF-8 data were > known (see below). The present downgrade procedure, and the > conditions associated with it, would continue to apply to all other > cases. This seems sensible. The only tricky bit is properly describing the two types of messages. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 05:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDqt-0008P3-KV; Thu, 07 Jun 2007 05:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDqs-0008Os-3t for ima@ietf.org; Thu, 07 Jun 2007 05:00:18 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwDqq-0002dC-O9 for ima@ietf.org; Thu, 07 Jun 2007 05:00:18 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HwDqq-000NlA-3U for ima@ietf.org; Thu, 07 Jun 2007 05:00:16 -0400 Date: Thu, 07 Jun 2007 05:00:15 -0400 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [EAI] Name of new mesage/ subtype X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi. There is an hypothesis that we should be using a new content subtype for message/ to identify body parts whose headers may contain UTF-8 material, if only to provide a specific message/ subtype that can be used (by extension of the MIME spec) with a content-transfer-encoding. At least some of us have concluded that modifying MIME to permit a C-T-E on _any_ message/ subtype, or even any message/subtype defined in RFC 2045/2046 is a bad idea, especially in an experimental protocol. For those who still believe that message/rfc822 is appropriate or that an application/ subtype should be used, please either ignore this message or suspend disbelief long enough to get through it and determine if you want to respond. If you are then going to comment other than to address the question, please change the subject line. The question of a rigorous definition for the body part that conforms to the requirements of RFC 4288/4289 is also a separate topic. The WG has been informally using the terms message/utf8 or message/utf8smtp to refer to this body part. Neither is satisfactory (at least IMO). UTF-8 is a charset and having a charset as a subtype seems likely to be confusing and unwise. And, since this is a body part subtype, it really has nothing to do with SMTP. Proposals made in a brief design team brainstorming session included: message/i18n /international /intl and /global plus "wait for an RFC number and parallel message/rfc822". This last one appears to be impractical for several reasons, including experimental implementations before an RFC is published and a number assigned, issues that would arise if changes arose between experimental and standards-track publication, and the general undesirability of having a long-surviving reference to an Experimental document (RFC 822 was considered to be an Internet Standard before MIME came along). Other suggestions welcome: the WG needs to decide and the name should be one that will come to mean something to users (since they will inevitably hear about and refer to it) and not cause confusion with other names and concepts. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 09:06:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHhB-0008GE-E3; Thu, 07 Jun 2007 09:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHhA-0008Cg-NJ for ima@ietf.org; Thu, 07 Jun 2007 09:06:32 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwHh9-0005z7-2h for ima@ietf.org; Thu, 07 Jun 2007 09:06:32 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3*clerew&man^ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 466802d5.14a37.63 for ima@ietf.org; Thu, 7 Jun 2007 14:06:29 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l57D6Sos014117 for ; Thu, 7 Jun 2007 14:06:29 +0100 (BST) Subject: Re: [EAI] ISSUE: Trivial downgrading References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> Message-ID: To: IMA Date: Thu, 07 Jun 2007 14:06:28 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 05 Jun 2007 20:16:57 +0100, John C Klensin wrote: > Hi. > > Kari and I have been having an offlist discussion that has inspired a > thought. > > Suppose one has a message that has UTF-8 headers, but there are no > non-ASCII addresses in the headers (either forward or > backward-pointing). This may actually turn out to be a common case for > people who stick with ASCII-addresses (either for interoperability or > because, e.g., their names don't happen to require non-ASCII characters > even if their languages are written using extended "Latin" scripts and > do). But, if they are using UTF8SMTP-aware MUAs and Submission servers > (MSAs), they are likely to be producing non-ASCII subject lines (as is > the case today), but sending them as UTF-8 rather than as encoded words. > There are some other cases, but this is the important one. > > At present, our rules appear to sent such messages through the entire > downgrade process, generating Downgrade headers, etc. No they don't. > > I wonder if, to make that class of cases efficient and maximize its > utility, we ought to have a different downgrade path that simply: > > * Converts the known header fields containing UTF-8 data > into the same fields with encoded words. > > * Documents the conversion only in trace information (i.e., > no "Downgraded:" headers). And that is EXACTLY what the current downgrading draft says, so what are you proposing that is new? And it is also what happens with s in ANY header (assuming there is no other UTF-8 in that header). > > * If any body parts or information require downgrading, > treat them strictly according to the 8BITMIME rules, which > would obviously apply. But that bit is not so clear to me. Suppose some body part has a Content-Description header, or a Content-Disposition with a UTF-8 filename. The 8BITMIME rules cannot change that, but our downgrade document covers that case (you use RFC 2047 or RFC 2231, with NO Downgraded header). Granted that the code you will find in well-written MTAs that does 8BITMIME downgrading can easily be adapted to do this extra job. Again, no evidence is left in the final message to indicate that downgrading has taken place, but who cares? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 09:36:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwI9o-00083K-VL; Thu, 07 Jun 2007 09:36:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwI9i-0007yQ-Pj for ima@ietf.org; Thu, 07 Jun 2007 09:36:02 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwI8E-0003lf-Ih for ima@ietf.org; Thu, 07 Jun 2007 09:34:32 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew&man#ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46680964.bbfc.5c for ima@ietf.org; Thu, 7 Jun 2007 14:34:28 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l57DYRv5015796 for ; Thu, 7 Jun 2007 14:34:28 +0100 (BST) Date: Thu, 07 Jun 2007 14:34:27 +0100 To: IMA Subject: Re: [EAI] Name of new mesage/ subtype References: From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 07 Jun 2007 10:00:15 +0100, John C Klensin wrote: > There is an hypothesis that we should be using a new content > subtype for message/ to identify body parts whose headers may > contain UTF-8 material, if only to provide a specific message/ > subtype that can be used (by extension of the MIME spec) with a > content-transfer-encoding. At least some of us have concluded > that modifying MIME to permit a C-T-E on _any_ message/ subtype, > or even any message/subtype defined in RFC 2045/2046 is a bad > idea, especially in an experimental protocol. Does "some of us" includes you? It is certainly the main reason why I am still arguing for message/rfc822. > The question of a rigorous definition for the body part that > conforms to the requirements of RFC 4288/4289 is also a separate > topic. I find it hard to discuss this new message subtype in the absence of any clear description of its properties - particularly as to whether, how and when it gets downgraded (first to 8BITMIME and then to 7bit). A rigorous definition would be fine, but even an informal definition would help. In comparison with that, the name by which it is to be called seems like a minor issue. > > The WG has been informally using the terms message/utf8 or > message/utf8smtp to refer to this body part. Which, as a working name, is fine for now. Agreed something better is needed before it get deployed. > Proposals made in a brief design team brainstorming session > included: > message/i18n > /international > /intl > and > /global Of those, i18n is the best, but it still lacks any suggestion that this is for all objects in an email-like format. Maybe 'i18n-mail'. > plus "wait for an RFC number and parallel message/rfc822". Please not. RFCs regularly get changed as standards get upgraded. Message.rfc822 already made that mistake. Do not repeat it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 11:09:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJc2-0002pQ-DC; Thu, 07 Jun 2007 11:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJc1-0002oc-5e for ima@ietf.org; Thu, 07 Jun 2007 11:09:21 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJbU-00010M-W5 for ima@ietf.org; Thu, 07 Jun 2007 11:08:50 -0400 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1HwJbU-0002vE-LA for ima@ietf.org; Thu, 07 Jun 2007 11:08:48 -0400 Received: by mac-andrew.int.libertyrms.com (Postfix, from userid 1019) id DA7E231C296; Thu, 7 Jun 2007 11:08:53 -0400 (EDT) Date: Thu, 7 Jun 2007 11:08:53 -0400 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Name of new mesage/ subtype Message-ID: <20070607150853.GD26244@afilias.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Jun 07, 2007 at 05:00:15AM -0400, John C Klensin wrote: > message/i18n > /international > /intl > and > /global I like this idea, but I don't like the names (especially i18n, which is perhaps not confusing to those already familiar with the shorthand, but will undoubtedly be completely mysterious to non-geeklish-speakers). I haven't come up with a better idea that doesn't suggest character sets in some way (/notascii, for example), though, so I decalre support for /international. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 11:37:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3Q-0008Bz-6A; Thu, 07 Jun 2007 11:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK3L-0007yX-8i for ima@ietf.org; Thu, 07 Jun 2007 11:37:35 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwK3K-0002WX-Qf for ima@ietf.org; Thu, 07 Jun 2007 11:37:35 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 7 Jun 2007 08:37:34 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi; Thu, 7 Jun 2007 08:37:33 -0700 From: Yuri Inglikov To: Andrew Sullivan , "ima@ietf.org" Date: Thu, 7 Jun 2007 08:37:21 -0700 Subject: RE: [EAI] Name of new mesage/ subtype Thread-Topic: [EAI] Name of new mesage/ subtype Thread-Index: AcepFdf2wY3l2TFkQzqDV/kpTJkqsgAAvMxg Message-ID: References: <20070607150853.GD26244@afilias.info> In-Reply-To: <20070607150853.GD26244@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I18n is no more misterious than rfc822. In fact, there is a benefit in bein= g "mysterious", as people avoid associating meaning and making assumptions = which can be incorrect. OTOH, what about message/mail, or message/email? In= ternationalization is a momentary term, which will not be interesting ten y= ears from now - it is just one of a "properties" of new e-mail format. Or, = alternatively, what about message/rfc822u ? > -----Original Message----- > From: Andrew Sullivan [mailto:andrew@ca.afilias.info] > Sent: Thursday, June 07, 2007 8:09 AM > To: ima@ietf.org > Subject: Re: [EAI] Name of new mesage/ subtype > > On Thu, Jun 07, 2007 at 05:00:15AM -0400, John C Klensin wrote: > > > message/i18n > > /international > > /intl > > and > > /global > > I like this idea, but I don't like the names (especially i18n, which > is perhaps not confusing to those already familiar with the shorthand, > but will undoubtedly be completely mysterious to > non-geeklish-speakers). I haven't come up with a better idea that > doesn't suggest character sets in some way (/notascii, for example), > though, so I decalre support for /international. > > A > > > -- > Andrew Sullivan 204-4141 Yonge Street > Afilias Canada Toronto, Ontario Canada > M2P 2A8 > jabber: ajsaf@jabber.org +1 416 646 3304 x4110 > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 12:33:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKvR-0003jl-P3; Thu, 07 Jun 2007 12:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKvP-0003jY-5D for ima@ietf.org; Thu, 07 Jun 2007 12:33:27 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKvN-000150-UT for ima@ietf.org; Thu, 07 Jun 2007 12:33:27 -0400 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1HwKvN-00069L-K9 for ima@ietf.org; Thu, 07 Jun 2007 12:33:25 -0400 Received: by mac-andrew.int.libertyrms.com (Postfix, from userid 1019) id AFE5031C3A6; Thu, 7 Jun 2007 12:33:29 -0400 (EDT) Date: Thu, 7 Jun 2007 12:33:29 -0400 From: Andrew Sullivan To: ima@ietf.org Subject: Re: [EAI] Name of new mesage/ subtype Message-ID: <20070607163329.GG26244@afilias.info> References: <20070607150853.GD26244@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Jun 07, 2007 at 08:37:21AM -0700, Yuri Inglikov wrote: > I18n is no more misterious than rfc822. This is true, but I'm not sure that an argument from the obscurity of one name is a reason to prefer another obscure name. > In fact, there is a benefit > in being "mysterious", as people avoid associating meaning and > making assumptions which can be incorrect. On that basis, perhas we should prefer /xyzzy :) A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 12:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLKU-0007xn-FH; Thu, 07 Jun 2007 12:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLKT-0007t8-57 for ima@ietf.org; Thu, 07 Jun 2007 12:59:21 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLKR-0005tE-Uw for ima@ietf.org; Thu, 07 Jun 2007 12:59:21 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 0ED972F0; Thu, 7 Jun 2007 12:59:41 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 340BB55C35; Thu, 7 Jun 2007 12:59:39 -0400 (EDT) Date: Thu, 7 Jun 2007 09:59:11 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <962223181.20070607095911@pobox.com> To: IMA Discussion Subject: Re: [EAI] Name of new mesage/ subtype In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 2007-06-07, Charles Lindsey wrote: > On Thu, 07 Jun 2007 10:00:15 +0100, John C Klensin wrote: >> Proposals made in a brief design team brainstorming session >> included: >> message/i18n >> /international >> /intl >> and >> /global > Of those, i18n is the best, but it still lacks any suggestion that this is > for all objects in an email-like format. Maybe 'i18n-mail'. Doesn't "message/" imply email-like? Also, I like "/global" since it seems more inclusive and it would feel natural for all messages even if they had nothing but ascii in the header and body. I don't like anything with "mail" in it since I would hope that this format would not be restricted to e-mail. -- Bill McQuillan _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 13:02:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLN4-000195-OU; Thu, 07 Jun 2007 13:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLN3-00018v-5G for ima@ietf.org; Thu, 07 Jun 2007 13:02:01 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLN1-0006nT-RE for ima@ietf.org; Thu, 07 Jun 2007 13:02:01 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HwLN0-0003Sj-8Z; Thu, 07 Jun 2007 13:01:58 -0400 Date: Thu, 07 Jun 2007 13:01:56 -0400 From: John C Klensin To: Yuri Inglikov , Andrew Sullivan , ima@ietf.org Subject: RE: [EAI] Name of new mesage/ subtype Message-ID: <369178548B3309D72AEFEA8E@p3.JCK.COM> In-Reply-To: References: <20070607150853.GD26244@afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 07 June, 2007 08:37 -0700 Yuri Inglikov wrote: > I18n is no more misterious than rfc822. Yes, but, as Andrew points out, it is sort of a geek abbreviation. And if pronounced message/internationalization, rather than message/i18n, it is grammatically strange. I could, however, live with it. > In fact, there is a > benefit in being "mysterious", as people avoid associating > meaning and making assumptions which can be incorrect. That implies a completely made-up word (string), which no one has proposed one of yet. > OTOH, > what about message/mail, or message/email? To me, odd but possible. > Internationalization is a momentary term, which will not be > interesting ten years from now - it is just one of a > "properties" of new e-mail format. Or, alternatively, what > about message/rfc822u ? I think that the term/concept "rfc" is sufficiently well-known, at least in the specialist community, that anything starting with "rfc" followed by one or more digits, had better be one, regardless of what follows the digits. Otherwise, people are, e.g., going to go off to RFC822 looking for the "u" option. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 07 13:06:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLRS-0001nj-42; Thu, 07 Jun 2007 13:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLRQ-0001nd-6X for ima@ietf.org; Thu, 07 Jun 2007 13:06:32 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLRP-00081W-Qv for ima@ietf.org; Thu, 07 Jun 2007 13:06:32 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HwLRO-0003V7-Pj; Thu, 07 Jun 2007 13:06:30 -0400 Date: Thu, 07 Jun 2007 13:06:29 -0400 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Name of new mesage/ subtype Message-ID: <36142CAC28EC7DAF983693C5@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 07 June, 2007 14:34 +0100 Charles Lindsey wrote: > On Thu, 07 Jun 2007 10:00:15 +0100, John C Klensin > wrote: > >> There is an hypothesis that we should be using a new content >> subtype for message/ to identify body parts whose headers may >> contain UTF-8 material, if only to provide a specific message/ >> subtype that can be used (by extension of the MIME spec) with >> a content-transfer-encoding. At least some of us have >> concluded that modifying MIME to permit a C-T-E on _any_ >> message/ subtype, or even any message/subtype defined in RFC >> 2045/2046 is a bad idea, especially in an experimental >> protocol. > > Does "some of us" includes you? It is certainly the main > reason why I am still arguing for message/rfc822. Yes, it includes me. But, having changed my mind at least once about this, I don't consider my opinion to be particularly important. And I was trying to present, rather than persuade. >... >> The WG has been informally using the terms message/utf8 or >> message/utf8smtp to refer to this body part. > > Which, as a working name, is fine for now. Agreed something > better is needed before it get deployed. The longer these things persist as "temporary" usage, the more likely they are to become permanent just because the people working on or discussing the specs have gotten use to them. >> Proposals made in a brief design team brainstorming session >> included: >> message/i18n >> /international >> /intl >> and >> /global > > Of those, i18n is the best, but it still lacks any suggestion > that this is for all objects in an email-like format. Maybe > 'i18n-mail'. Yes, that one, one i18n-email (with or without the hyphen) should have been on the list -- I was just too fuzzy when I wrote the note to remember (I plead 2AM Jabber chats as an excuse). >> plus "wait for an RFC number and parallel message/rfc822". > > Please not. RFCs regularly get changed as standards get > upgraded. Message.rfc822 already made that mistake. Do not > repeat it. Speaking personally, I agree. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 08 02:48:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYH5-0001wt-Jj; Fri, 08 Jun 2007 02:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYH3-0001wc-Sh for ima@ietf.org; Fri, 08 Jun 2007 02:48:41 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYH2-0000bg-Ha for ima@ietf.org; Fri, 08 Jun 2007 02:48:41 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A06AD2596E0; Fri, 8 Jun 2007 08:48:39 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29116-05; Fri, 8 Jun 2007 08:48:34 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D677E2596BD; Fri, 8 Jun 2007 08:48:34 +0200 (CEST) Message-ID: <4668FBC2.3040708@alvestrand.no> Date: Fri, 08 Jun 2007 08:48:34 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Name of new mesage/ subtype References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Proposals made in a brief design team brainstorming session > included: > message/i18n > /international > /intl > and > /global > of these, message/global is the one I dislike the least. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 08 02:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYRz-0004Co-7J; Fri, 08 Jun 2007 02:59:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYRx-0004Cc-8v for ima@ietf.org; Fri, 08 Jun 2007 02:59:57 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYRu-0007tq-GM for ima@ietf.org; Fri, 08 Jun 2007 02:59:57 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l586xoJ2013497 for ; Fri, 8 Jun 2007 15:59:50 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 399f_d9d6e8ae_158d_11dc_99b1_0014221fa3c9; Fri, 08 Jun 2007 15:59:49 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60660) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 8 Jun 2007 15:58:02 +0900 Message-Id: <6.0.0.20.2.20070608151125.09f66e30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 08 Jun 2007 15:43:03 +0900 To: John C Klensin , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] Name of new mesage/ subtype In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 18:00 07/06/07, John C Klensin wrote: > message/i18n > /international > /intl >and > /global What about message/eai ? I'm sceptical about the above proposals because even with message/rfc822, I can send any kind of message, international or global or not. The two main new things, as far as I understand them, are i18n addresses and raw use of UTF-8, and it would be better in my view if the naming took that into account. As a consequence, I wouldn't exclude message/utf8, either. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 08 03:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYgy-0000fL-H4; Fri, 08 Jun 2007 03:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYgx-0000f6-4W for ima@ietf.org; Fri, 08 Jun 2007 03:15:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwYgt-000182-Ja for ima@ietf.org; Fri, 08 Jun 2007 03:15:27 -0400 Received: (qmail invoked by alias); 08 Jun 2007 07:08:41 -0000 Received: from dslb-084-056-235-150.pools.arcor-ip.net (EHLO hive) [84.56.235.150] by mail.gmx.net (mp055) with SMTP; 08 Jun 2007 09:08:41 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+vIgd3bFmvRrEkQskqHfdPvsWtnjj2IkA2byteZp EuAHyn6GnRkBw1 From: Bjoern Hoehrmann To: John C Klensin Subject: Re: [EAI] Name of new mesage/ subtype Date: Fri, 08 Jun 2007 09:08:41 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org * John C Klensin wrote: >Proposals made in a brief design team brainstorming session >included: > message/i18n > /international > /intl >and > /global I am not fond of the idea to make such entities something "special", be that "international", "global", or anything else. message/mail, /e-mail, /smtp, /smtp8, /eai, or something else less suggestive would be better. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 08 03:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZ6v-00049w-9F; Fri, 08 Jun 2007 03:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZ2P-0007RO-M4 for ima@ietf.org; Fri, 08 Jun 2007 03:37:37 -0400 Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZ2N-0003jd-44 for ima@ietf.org; Fri, 08 Jun 2007 03:37:37 -0400 Received: from [10.201.0.49] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l587e7hW031795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2007 00:40:12 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l587e7hW031795 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1181288417; bh=EEGf6SuO/X4a4Wro0H6BKnMiAf8=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=syK5xkf8lAfQqvu7 RAyk8nTPxVvMsez4z4dPH4KyZOsCx+BgqBysdNlWeorPD4/XEyyyVoHLkzCwVNjGyYc uG4B3621IQtQ+UfkNtRvjfV/8K7QGcjONQoftmmzdDr51SIK5oomKwmEwNrKZBQnI9h eoCPmLH9IphiC1K0mYnSo= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l587e7hW031795 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=L5RhhDPtYYY5o9zGwTQHI6EDS/vu+dr8S27BLn2chApMHly2ln+KavyZYWNQOS6LS ua9qKWWd6K0O927DqDX75Iqp0dJn0TSlh3v/7wq7ilJpP5BsIYlhDcAJmDVKlUTsBtO lvbE0tbOJ034wrFHJBmxh17yErtmVnp+lokPAio= Date: Fri, 8 Jun 2007 01:37:13 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Martin Duerst Subject: Re: [EAI] Name of new mesage/ subtype In-Reply-To: <6.0.0.20.2.20070608151125.09f66e30@localhost> Message-ID: References: <6.0.0.20.2.20070608151125.09f66e30@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 08 Jun 2007 03:42:16 -0400 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 8 Jun 2007, Martin Duerst wrote: > At 18:00 07/06/07, John C Klensin wrote: > >> message/i18n >> /international >> /intl >> and >> /global > > What about message/eai ? I'm sceptical about the above proposals because > even with message/rfc822, I can send any kind of message, international > or global or not. The two main new things, as far as I understand them, > are i18n addresses and raw use of UTF-8, and it would be better in my > view if the naming took that into account. As a consequence, I wouldn't > exclude message/utf8, either. I agree. The other existing message subtypes seem to describe what they contain, but the suggestions John lists seem to be more about intended applicability. What is the point of the new subtype: to contain messages which may have non-ascii UTF-8 addresses. "message/eai" is the only suggestion I've seen so far that mentions--albeit indirectly--addresses at all. While "message/utf8" raises the spector of other charsets getting in on the act, it does at least have a correct basis: the header *is* in UTF-8. Philip Guenther _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 08 03:48:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZCg-00083X-Jm; Fri, 08 Jun 2007 03:48:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZCf-00083S-Vz for ima@ietf.org; Fri, 08 Jun 2007 03:48:13 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwZCd-0007CP-Tp for ima@ietf.org; Fri, 08 Jun 2007 03:48:13 -0400 Received: (eyou send program); Fri, 08 Jun 2007 15:48:07 +0800 Message-ID: <381288887.00409@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Fri, 08 Jun 2007 15:48:07 +0800 Message-ID: <071201c7a9a1$583add30$0201a8c0@yaojk> From: "YAO Jiankang" To: "Philip Guenther" , "Martin Duerst" References: <6.0.0.20.2.20070608151125.09f66e30@localhost> <381288541.00409@cnnic.cn> Subject: Re: [EAI] Name of new mesage/ subtype Date: Fri, 8 Jun 2007 15:48:03 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.0 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0930507398==" Errors-To: ima-bounces@ietf.org --===============0930507398== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBoaWxpcCBHdWVudGhlciIg PGd1ZW50aGVyQHNlbmRtYWlsLmNvbT4NClRvOiAiTWFydGluIER1ZXJzdCIgPGR1ZXJzdEBpdC5h b3lhbWEuYWMuanA+DQpDYzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgSnVuZSAwOCwg MjAwNyAzOjM3IFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gTmFtZSBvZiBuZXcgbWVzYWdlLyBzdWJ0 eXBlDQoNCg0KPiBPbiBGcmksIDggSnVuIDIwMDcsIE1hcnRpbiBEdWVyc3Qgd3JvdGU6DQo+PiBB dCAxODowMCAwNy8wNi8wNywgSm9obiBDIEtsZW5zaW4gd3JvdGU6DQo+Pg0KPj4+ICAgbWVzc2Fn ZS9pMThuDQo+Pj4gICAgICAgICAgL2ludGVybmF0aW9uYWwNCj4+PiAgICAgICAgICAvaW50bA0K Pj4+IGFuZA0KPj4+ICAgICAgICAgIC9nbG9iYWwNCj4+DQo+PiBXaGF0IGFib3V0IG1lc3NhZ2Uv ZWFpID8gSSdtIHNjZXB0aWNhbCBhYm91dCB0aGUgYWJvdmUgcHJvcG9zYWxzIGJlY2F1c2UgDQo+ PiBldmVuIHdpdGggbWVzc2FnZS9yZmM4MjIsIEkgY2FuIHNlbmQgYW55IGtpbmQgb2YgbWVzc2Fn ZSwgaW50ZXJuYXRpb25hbCANCj4+IG9yIGdsb2JhbCBvciBub3QuIFRoZSB0d28gbWFpbiBuZXcg dGhpbmdzLCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZW0sIA0KPj4gYXJlIGkxOG4gYWRkcmVz c2VzIGFuZCByYXcgdXNlIG9mIFVURi04LCBhbmQgaXQgd291bGQgYmUgYmV0dGVyIGluIG15IA0K Pj4gdmlldyBpZiB0aGUgbmFtaW5nIHRvb2sgdGhhdCBpbnRvIGFjY291bnQuIEFzIGEgY29uc2Vx dWVuY2UsIEkgd291bGRuJ3QgDQo+PiBleGNsdWRlIG1lc3NhZ2UvdXRmOCwgZWl0aGVyLg0KPiAN Cj4gSSBhZ3JlZS4gIFRoZSBvdGhlciBleGlzdGluZyBtZXNzYWdlIHN1YnR5cGVzIHNlZW0gdG8g ZGVzY3JpYmUgd2hhdCB0aGV5IA0KPiBjb250YWluLCBidXQgdGhlIHN1Z2dlc3Rpb25zIEpvaG4g bGlzdHMgc2VlbSB0byBiZSBtb3JlIGFib3V0IGludGVuZGVkIA0KPiBhcHBsaWNhYmlsaXR5LiAg V2hhdCBpcyB0aGUgcG9pbnQgb2YgdGhlIG5ldyBzdWJ0eXBlOiB0byBjb250YWluIG1lc3NhZ2Vz IA0KPiB3aGljaCBtYXkgaGF2ZSBub24tYXNjaWkgVVRGLTggYWRkcmVzc2VzLiAgIm1lc3NhZ2Uv ZWFpIiBpcyB0aGUgb25seSANCg0KaG93IGFib3V0IG1lc3NhZ2UvdXRmOGVhaT8NCg0KWUFPIEpp YW5rYW5nDQpDTk5JQw0KDQo+IHN1Z2dlc3Rpb24gSSd2ZSBzZWVuIHNvIGZhciB0aGF0IG1lbnRp b25zLS1hbGJlaXQgaW5kaXJlY3RseS0tYWRkcmVzc2VzIGF0IA0KPiBhbGwuICBXaGlsZSAibWVz c2FnZS91dGY4IiByYWlzZXMgdGhlIHNwZWN0b3Igb2Ygb3RoZXIgY2hhcnNldHMgZ2V0dGluZyBp biANCj4gb24gdGhlIGFjdCwgaXQgZG9lcyBhdCBsZWFzdCBoYXZlIGEgY29ycmVjdCBiYXNpczog dGhlIGhlYWRlciAqaXMqIGluIA0KPiBVVEYtOC4NCj4gDQo+IA0KPiBQaGlsaXAgR3VlbnRoZXIN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPg== --===============0930507398== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============0930507398==-- From ima-bounces@ietf.org Fri Jun 08 05:40:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwax8-00018F-T2; Fri, 08 Jun 2007 05:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwax7-000186-NO for ima@ietf.org; Fri, 08 Jun 2007 05:40:17 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwax6-0000Lu-66 for ima@ietf.org; Fri, 08 Jun 2007 05:40:17 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3*clerew*man^ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 466923fe.c1a8.2aa for ima@ietf.org; Fri, 8 Jun 2007 10:40:14 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l589eB1H023321 for ; Fri, 8 Jun 2007 10:40:12 +0100 (BST) Date: Fri, 08 Jun 2007 10:40:11 +0100 From: "Charles Lindsey" To: IMA Subject: Fwd: Re: [EAI] Name of new mesage/ subtype References: <962223181.20070607095911@pobox.com> Message-ID: In-Reply-To: <962223181.20070607095911@pobox.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ------- Forwarded message ------- From: "Bill McQuillan" To: "IMA Discussion" Subject: Re: [EAI] Name of new mesage/ subtype Date: Thu, 07 Jun 2007 17:59:11 +0100 On Thu, 2007-06-07, Charles Lindsey wrote: > On Thu, 07 Jun 2007 10:00:15 +0100, John C Klensin > wrote: > Of those, i18n is the best, but it still lacks any suggestion that this > is > for all objects in an email-like format. Maybe 'i18n-mail'. Doesn't "message/" imply email-like? Are all the currently registered message types email-like? Message/CPIM for example? Or message/http? I will accept that most people believe that news is email-like. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 11 06:35:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhFN-0005Yj-Nr; Mon, 11 Jun 2007 06:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhFM-0005Ye-G6 for ima@ietf.org; Mon, 11 Jun 2007 06:35:40 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxhFL-00019L-4W for ima@ietf.org; Mon, 11 Jun 2007 06:35:40 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 11 Jun 2007 11:35:36 +0100 Message-ID: <466D2527.9010903@isode.com> Date: Mon, 11 Jun 2007 11:34:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org Subject: Re: [EAI] Name of new mesage/ subtype References: <6.0.0.20.2.20070608151125.09f66e30@localhost> In-Reply-To: <6.0.0.20.2.20070608151125.09f66e30@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: >At 18:00 07/06/07, John C Klensin wrote: > > >> message/i18n >> /international >> /intl >>and >> /global >> >> >What about message/eai ? I'm sceptical about the above proposals >because even with message/rfc822, I can send any kind of message, >international or global or not. The two main new things, as far >as I understand them, are i18n addresses and raw use of UTF-8, >and it would be better in my view if the naming took that into >account. As a consequence, I wouldn't exclude message/utf8, either. > > I don't like message/global, as it sounds ambiguous. I am Ok with message/i18n, message/international, message/eai or message/utf-8. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 11 07:13:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhpW-0002FJ-7f; Mon, 11 Jun 2007 07:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxhpU-0002ES-Mq for ima@ietf.org; Mon, 11 Jun 2007 07:13:00 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxhnY-00043E-EF for ima@ietf.org; Mon, 11 Jun 2007 07:11:03 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew&man$ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 466d2dc2.14e95.1f8 for ima@ietf.org; Mon, 11 Jun 2007 12:10:58 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5BBAvoC005958 for ; Mon, 11 Jun 2007 12:10:58 +0100 (BST) To: IMA Subject: Re: [EAI] Name of new mesage/ subtype References: <6.0.0.20.2.20070608151125.09f66e30@localhost> Message-ID: Date: Mon, 11 Jun 2007 12:10:57 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <6.0.0.20.2.20070608151125.09f66e30@localhost> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 08 Jun 2007 07:43:03 +0100, Martin Duerst wrote: > What about message/eai ? I'm sceptical about the above proposals > because even with message/rfc822, I can send any kind of message, > international or global or not. The two main new things, as far > as I understand them, are i18n addresses and raw use of UTF-8, > and it would be better in my view if the naming took that into > account. As a consequence, I wouldn't exclude message/utf8, either. But in that case you want something more explicit, such as message/utf8-headers or message/utf8-email. Though the first might be confused with a DSN returning headers only :-( . -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 11 20:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxuVJ-0000eq-Vs; Mon, 11 Jun 2007 20:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxuVI-0000eV-LP for ima@ietf.org; Mon, 11 Jun 2007 20:45:00 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxuVG-0000i6-QM for ima@ietf.org; Mon, 11 Jun 2007 20:45:00 -0400 Received: (snipe 12230 invoked by uid 0); 12 Jun 2007 09:45:30 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.415648 secs); Received: from unknown (HELO ?210.107.250.81?) (Z@210.107.250.81) by unknown with SMTP; 12 Jun 2007 09:45:30 +0900 X-SNIPER-SENDERIP: 210.107.250.81 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: ima@ietf.org, yangwooko@gmail.com Message-ID: <466DEC83.2050407@icu.ac.kr> Date: Tue, 12 Jun 2007 09:44:51 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Name of new mesage/ subtype References: <6.0.0.20.2.20070608151125.09f66e30@localhost> <466D2527.9010903@isode.com> In-Reply-To: <466D2527.9010903@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I am in favor of message/eai because this message type is a result of eai WG effort. I have mixed feelings with message/utf8. It means to me that, unlike i18n or global, we do not prevent any other internationalization of email from being explored, which can be good and bad news. Alexey Melnikov wrote: > > Martin Duerst wrote: > >> At 18:00 07/06/07, John C Klensin wrote: >> >> >>> message/i18n >>> /international >>> /intl >>> and >>> /global >>> >> What about message/eai ? I'm sceptical about the above proposals >> because even with message/rfc822, I can send any kind of message, >> international or global or not. The two main new things, as far >> as I understand them, are i18n addresses and raw use of UTF-8, >> and it would be better in my view if the naming took that into >> account. As a consequence, I wouldn't exclude message/utf8, either. >> >> > I don't like message/global, as it sounds ambiguous. > I am Ok with message/i18n, message/international, message/eai or > message/utf-8. > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 11 20:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxuaY-00043B-Eb; Mon, 11 Jun 2007 20:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxuaX-000434-QI for ima@ietf.org; Mon, 11 Jun 2007 20:50:25 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxuaW-00034f-Gx for ima@ietf.org; Mon, 11 Jun 2007 20:50:25 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1HxuaV-000Jl1-NZ; Mon, 11 Jun 2007 20:50:24 -0400 Date: Mon, 11 Jun 2007 20:50:22 -0400 From: John C Klensin To: Yangwoo Ko , ima@ietf.org Subject: Re: [EAI] Name of new mesage/ subtype Message-ID: <565ADE710A8D0ACBBADC38F4@[192.168.0.3]> In-Reply-To: <466DEC83.2050407@icu.ac.kr> References: <6.0.0.20.2.20070608151125.09f66e30@localhost> <466D2527.9010903@isode.com> <466DEC83.2050407@icu.ac.kr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, June 12, 2007 09:44 +0900 Yangwoo Ko wrote: > I am in favor of message/eai because this message type is a > result of eai WG effort. Remember that "EAI" was chosen for the WG name/ abbreviation only because "IMA" had been used for something else. It is not a particularly good name, although I could certainly live with it. > I have mixed feelings with message/utf8. It means to me that, > unlike i18n or global, we do not prevent any other > internationalization of email from being explored, which can > be good and bad news. In particular, I fear that it would encourage (non-standard and possibly non-registered) use of message/utf-32 message/Latin-1 message/Klingon-666 And so on. It is not the character set that is the issue here. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 11 21:03:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxunf-0007mc-Ls; Mon, 11 Jun 2007 21:03:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxune-0007gP-K3 for ima@ietf.org; Mon, 11 Jun 2007 21:03:58 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxund-0007EA-0b for ima@ietf.org; Mon, 11 Jun 2007 21:03:58 -0400 Received: (snipe 18192 invoked by uid 0); 12 Jun 2007 10:04:27 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.622383 secs); Received: from unknown (HELO ?210.107.250.81?) (Z@210.107.250.81) by unknown with SMTP; 12 Jun 2007 10:04:27 +0900 X-SNIPER-SENDERIP: 210.107.250.81 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: klensin@jck.com, ima@ietf.org, yangwooko@gmail.com Message-ID: <466DF0F4.4010804@icu.ac.kr> Date: Tue, 12 Jun 2007 10:03:48 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Name of new mesage/ subtype References: <6.0.0.20.2.20070608151125.09f66e30@localhost> <466D2527.9010903@isode.com> <466DEC83.2050407@icu.ac.kr> <565ADE710A8D0ACBBADC38F4@[192.168.0.3]> In-Reply-To: <565ADE710A8D0ACBBADC38F4@[192.168.0.3]> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > > > > --On Tuesday, June 12, 2007 09:44 +0900 Yangwoo Ko > wrote: > >> I am in favor of message/eai because this message type is a >> result of eai WG effort. > > Remember that "EAI" was chosen for the WG name/ abbreviation only > because "IMA" had been used for something else. It is not a > particularly good name, although I could certainly live with it. > >> I have mixed feelings with message/utf8. It means to me that, >> unlike i18n or global, we do not prevent any other >> internationalization of email from being explored, which can >> be good and bad news. > > In particular, I fear that it would encourage (non-standard and > possibly non-registered) use of > message/utf-32 > message/Latin-1 > message/Klingon-666 > > And so on. It is not the character set that is the issue here. I also share this fear. > > john > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 12 00:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxyJc-0005uv-3e; Tue, 12 Jun 2007 00:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxyJa-0005ui-PV for ima@ietf.org; Tue, 12 Jun 2007 00:49:10 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxyJX-0001iq-Vc for ima@ietf.org; Tue, 12 Jun 2007 00:49:10 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5C4n10g023631 for ; Tue, 12 Jun 2007 13:49:01 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1f7e_3d30fca4_18a0_11dc_8856_0014221fa3c9; Tue, 12 Jun 2007 13:49:01 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52729) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 12 Jun 2007 13:47:11 +0900 Message-Id: <6.0.0.20.2.20070612110104.0a249010@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 12 Jun 2007 11:03:25 +0900 To: John C Klensin , Yangwoo Ko , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] Name of new mesage/ subtype In-Reply-To: <565ADE710A8D0ACBBADC38F4@[192.168.0.3]> References: <6.0.0.20.2.20070608151125.09f66e30@localhost> <466D2527.9010903@isode.com> <466DEC83.2050407@icu.ac.kr> <565ADE710A8D0ACBBADC38F4@[192.168.0.3]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 09:50 07/06/12, John C Klensin wrote: > > >--On Tuesday, June 12, 2007 09:44 +0900 Yangwoo Ko wrote: > >> I am in favor of message/eai because this message type is a >> result of eai WG effort. > >Remember that "EAI" was chosen for the WG name/ abbreviation only because "IMA" had been used for something else. It is not a particularly good name, although I could certainly live with it. We definitiely could also make it message/ima. >> I have mixed feelings with message/utf8. It means to me that, >> unlike i18n or global, we do not prevent any other >> internationalization of email from being explored, which can >> be good and bad news. > >In particular, I fear that it would encourage (non-standard and possibly non-registered) use of > message/utf-32 > message/Latin-1 > message/Klingon-666 > >And so on. It is not the character set that is the issue here. Well, the two issues are raw utf-8 in headers and non-ASCII characters in email addresses. The former is clearly the means that was choosen for achieving the later. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 12 08:53:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5sR-0003DX-Uy; Tue, 12 Jun 2007 08:53:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5sR-0003DD-Ce for ima@ietf.org; Tue, 12 Jun 2007 08:53:39 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hy5sJ-0005Zy-2V for ima@ietf.org; Tue, 12 Jun 2007 08:53:38 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew&man^ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 466e9748.af9d.6d for ima@ietf.org; Tue, 12 Jun 2007 13:53:28 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5CCq5QF013855 for ; Tue, 12 Jun 2007 13:52:06 +0100 (BST) Date: Tue, 12 Jun 2007 13:52:04 +0100 To: IMA References: <46692595.1080300@cs.tcd.ie> <9EBAE550-57EC-4239-95DE-8090C5340C01@mail-abuse.org> <8AD160571F8A052FD9F8E6EB@rieux.neophilic.com> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [EAI] Re: [ietf-dkim] Jim's issues - one more try X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 12 Jun 2007 01:28:05 +0100, Douglas Otis wrote: > So when wildcard records are not used, > after receiving a message considered not signed: > > - When neither an MX (or A) record are found, refuse the message. > - When an MX (or A) record are found, query for a policy record. > - When no policy is found, there is no policy. (Searching not > required.) > - When policy requires DKIM signatures, refuse the message. That works for the domain that "never sends mail" "never receives mail" But what about the domain that receives, but never sends? In that case you will publish several MX records (with assorted preferences) as usual. But then you also publish an extra MX record with a ridiculously low preference (99 say) which points to something unresolvable (e.g. nomail,invalid). By convention, that means "sends no mail". So if you are a receiving site considering whether some message can be discarded, you just ask to see the MX records for the domain, and see if they include one pointing to nomail.invalid. I reckone there would be no need then to depracate A records where |MX was absent, or anything like that. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 12 09:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy610-00017T-Ru; Tue, 12 Jun 2007 09:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy610-00017O-5G for ima@ietf.org; Tue, 12 Jun 2007 09:02:30 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy60y-0002no-P6 for ima@ietf.org; Tue, 12 Jun 2007 09:02:30 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A63314AC30; Tue, 12 Jun 2007 15:02:27 +0200 (CEST) Message-Id: Date: Tue, 12 Jun 2007 15:02:27 +0200 From: Arnt Gulbrandsen To: Charles Lindsey Subject: Re: [EAI] Re: [ietf-dkim] Jim's issues - one more try References: <46692595.1080300@cs.tcd.ie> <9EBAE550-57EC-4239-95DE-8090C5340C01@mail-abuse.org> <8AD160571F8A052FD9F8E6EB@rieux.neophilic.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey writes: > By convention, that means "sends no mail". So could you please write an internet-draft summing up these conventions and get it published as RFC? You can hardly expect average IMA document readers to know about them. If they should have any influence on IMA documents, you'd better write them up as an RFC. Arnt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 12 13:13:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9vb-0005Vh-AZ; Tue, 12 Jun 2007 13:13:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9va-0005VY-2n for ima@ietf.org; Tue, 12 Jun 2007 13:13:10 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9vX-0002fm-Mp for ima@ietf.org; Tue, 12 Jun 2007 13:13:10 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Hy9vW-0005lp-G1; Tue, 12 Jun 2007 13:13:06 -0400 Date: Tue, 12 Jun 2007 13:13:05 -0400 From: John C Klensin To: Charles Lindsey Subject: Re: [EAI] Re: [ietf-dkim] Jim's issues - one more try Message-ID: <347A01E36194744C1493ACC8@[192.168.0.3]> In-Reply-To: References: <46692595.1080300@cs.tcd.ie> <9EBAE550-57EC-4239-95DE-8090C5340C01@mail-abuse.org> <8AD160571F8A052FD9F8E6EB@rieux.neophilic.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles, These comments seem appropriate as part of a discussion of DKIM, either on that WG list, or on Last Call of the DKIM overview document, or as a separate discussion, written up in an I-D in enough coherent detail that people can understand it. There is nothing about them that seems unique to EAI -- other than that that DKIM doesn't address internationalization issues. Please take it somewhere else. john --On Tuesday, June 12, 2007 13:52 +0100 Charles Lindsey wrote: > On Tue, 12 Jun 2007 01:28:05 +0100, Douglas Otis > wrote: > > >> So when wildcard records are not used, >> after receiving a message considered not signed: >> >> - When neither an MX (or A) record are found, refuse the >> message. - When an MX (or A) record are found, query for a >> policy record. - When no policy is found, there is no >> policy. (Searching not required.) >> - When policy requires DKIM signatures, refuse the message. > > That works for the domain that "never sends mail" > "never receives mail" > > But what about the domain that receives, but never sends? > > In that case you will publish several MX records (with > assorted preferences) as usual. But then you also publish an > extra MX record with a ridiculously low preference (99 say) > which points to something unresolvable (e.g. nomail,invalid). > > By convention, that means "sends no mail". So if you are a > receiving site considering whether some message can be > discarded, you just ask to see the MX records for the domain, > and see if they include one pointing to nomail.invalid. > > I reckone there would be no need then to depracate A records > where |MX was absent, or anything like that. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 13 01:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyLeO-0004e8-O3; Wed, 13 Jun 2007 01:44:12 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1HyLeN-0004e0-5X for ima-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 01:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyLeM-0004ds-Nk for ima@ietf.org; Wed, 13 Jun 2007 01:44:10 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyLeL-00069E-DL for ima@ietf.org; Wed, 13 Jun 2007 01:44:10 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.1/8.14.1) with ESMTP id l5D5guP2017887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2007 22:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1181713391; x=1181799791; bh=zwcwLoYKPLTNyg6YzORGvOllLCSrqKCbwyZ6 1qoitCI=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=INE jAvD8rTwUzePpTWdGQc0uM2HWdhqWOOfgIIZCf/m9+vZNpwaMSQwjVoH9SHoa/PspUx lIZuaOfq6AqEpzVf9Bb7qf0ucLk5sZfDAB63uriFx6Uu13wQEkOwGO3xaSF1OVqntYP J1xpEsY1tztY0lfZLG4vsOlkSx9O/pkAq4= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=NyKj9cVAhtVj0x6a1RFUrkhUCi17CXmMs36j12kJd3iH8MQf9Y4DmIIY45n0HGzmU k57MP91HHtyxNR+eMlGzTybhzI61yO4uryePXsYnI9F8G727zWAOFB8TwCn8SuhHWHT wsQFixPxE3jXtQ7PmJ3rrzHQ3ai4r1BSjbNqd0w= Message-Id: <6.2.5.6.2.20070612223802.02b263d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 12 Jun 2007 22:43:25 -0700 To: ima@ietf.org From: SM Subject: Re: [EAI] Name of new mesage/ subtype In-Reply-To: <6.0.0.20.2.20070612110104.0a249010@localhost> References: <6.0.0.20.2.20070608151125.09f66e30@localhost> <466D2527.9010903@isode.com> <466DEC83.2050407@icu.ac.kr> <565ADE710A8D0ACBBADC38F4@[192.168.0.3]> <6.0.0.20.2.20070612110104.0a249010@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 19:03 11-06-2007, Martin Duerst wrote: >We definitiely could also make it message/ima. How about message/intl-email ? The subtype is somewhat more descriptive about the content. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 13 06:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyQN5-0004fD-IU; Wed, 13 Jun 2007 06:46:39 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1HyQN3-0004f8-MC for ima-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 06:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyQN3-0004f0-Cd for ima@ietf.org; Wed, 13 Jun 2007 06:46:37 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyQMz-0004yL-SD for ima@ietf.org; Wed, 13 Jun 2007 06:46:37 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew$man*ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 466fcb06.ea82.152 for ima@ietf.org; Wed, 13 Jun 2007 11:46:30 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5DAkSqw007064 for ; Wed, 13 Jun 2007 11:46:29 +0100 (BST) To: IMA Subject: Re: [EAI] Re: [ietf-dkim] Jim's issues - one more try References: <46692595.1080300@cs.tcd.ie> <9EBAE550-57EC-4239-95DE-8090C5340C01@mail-abuse.org> <8AD160571F8A052FD9F8E6EB@rieux.neophilic.com> Message-ID: From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 13 Jun 2007 11:46:27 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 12 Jun 2007 13:52:04 +0100, Charles Lindsey wrote: > On Tue, 12 Jun 2007 01:28:05 +0100, Douglas Otis > wrote: Oops! Wrong list. Sorry about that. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 13 12:40:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVtb-0001Wa-V4; Wed, 13 Jun 2007 12:40:35 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1HyVta-0001WO-J5 for ima-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 12:40:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVta-0001WG-7j; Wed, 13 Jun 2007 12:40:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyVtY-0007Gp-TD; Wed, 13 Jun 2007 12:40:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CA10B2AC6F; Wed, 13 Jun 2007 16:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyVt4-0002hn-J6; Wed, 13 Jun 2007 12:40:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 13 Jun 2007 12:40:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-dsn-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : International Delivery and Disposition Notifications Author(s) : C. Newman, A. Melnikov Filename : draft-ietf-eai-dsn-01.txt Pages : 16 Date : 2007-06-13 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-dsn-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-dsn-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-dsn-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-06-13123334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-dsn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-dsn-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-06-13123334.I-D\@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 14 18:20:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyxg6-0006ZE-M0; Thu, 14 Jun 2007 18:20:30 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Hyxg5-0006YD-7E for ima-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 18:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyxg4-0006Y2-TU for ima@ietf.org; Thu, 14 Jun 2007 18:20:28 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyxfx-0000vu-De for ima@ietf.org; Thu, 14 Jun 2007 18:20:28 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56E0E259725 for ; Fri, 15 Jun 2007 00:20:20 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03624-04 for ; Fri, 15 Jun 2007 00:20:15 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F9FA25971A for ; Fri, 15 Jun 2007 00:20:15 +0200 (CEST) Date: Fri, 15 Jun 2007 00:19:28 +0200 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [EAI] Ticket status, EAI, June 15, 2007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The following tickets are open on the EAI issue tracker: 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no later discussion. 1484 SMTPEXT 2.2: More exact definition of action choices Text proposed in -06, no later discussion. 1485 UTF8HDR 4.6/DSN: Choice of body part for transport of UTF8SMTP messages MIME type message/something is proposed, no clear consensus. Poll will be sent. 1486 SMTPEXT 2.7.2: Message retry Text proposed in -06, no later discussion. 1487 UTF8HDR 4.2: Does this specification update MIME? Proposed resolution: Yes. Say so in introduction. 1488 UTF8HDR 4.2: List MIME headers that are modified? Proposed resolution: Yes. We need an intro saying how we handle the difference in grammars. Propose to merge this with 1487. 1490 UTF8HDR 4.2: Including Content-Description to picture (grammar) Propose to merge this with 1487. 1491 UTF8HDR 4.2: Extending MIME (ABNF grammar) Propose to merge this with 1487. 1492 SMTPEXT 2.7.3: syntax Text proposed in -06, no later discussion. 1493 SMTPEXT 2.4: Redefining of RCPT TO and MAIL FROM commands (ABNF grammar) Text proposed in -06, no later discussion. 1494 UTF8HDR 4.4: should include Proposed resolution: Yes; UTF-8 format needs to be an additional alternative (=/) on angle-addr. 1495 SMTPEXT 2.5/2.6: Reply code used on DATA Text proposed in -06. 1496 DOWNGRADE: Specify a simpler downgrade procedure? No discussion so far. For the "text proposed in -06" tickets, we will interpret silence as "this is good enough", and resolve the tickets in a week or so. For the issues with no proposed solution, discussion is needed. harald, for the chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 15 01:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz3ww-0004Df-I2; Fri, 15 Jun 2007 01:02:18 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Hz3wv-0004DX-A7 for ima-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 01:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz3wu-0004DP-W6 for ima@ietf.org; Fri, 15 Jun 2007 01:02:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz3wt-0002PX-EJ for ima@ietf.org; Fri, 15 Jun 2007 01:02:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hz3ws-0005Eg-Ab for ima@ietf.org; Fri, 15 Jun 2007 07:02:14 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 07:02:14 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 07:02:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 15 Jun 2007 08:02:05 +0300 Lines: 87 Message-ID: <5dfy4t95f6.fsf@Hurtta06k.keh.iki.fi> References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Kari Hurtta Subject: [EAI] Re: Ticket status, EAI, June 15, 2007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org It is still unclear what was destiny of ISSUE: UTF8HDR 4.5: and on trace field syntax Was that editoral issue? Or was it minor, non-important issue? Basically when utf-8 address is allowed on for clause, rfc 2822 syntax needs extending: received = "Received:" name-val-list ";" date-time CRLF name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] name-val-pair = item-name CFWS item-value item-name = ALPHA *(["-"] (ALPHA / DIGIT)) item-value = 1*angle-addr / addr-spec / atom / domain / msg-id does not allow utf-8 addresses. So need include . ( Another problem is that syntax is changing. So change need to be tracked :-) ) On ISSUE I suggested item-value =/ utf8-addr-spec / Kari Hurtta Harald Tveit Alvestrand writes in gmane.ietf.ima: > The following tickets are open on the EAI issue tracker: > > 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no > later discussion. > > 1484 SMTPEXT 2.2: More exact definition of action choices Text > proposed in -06, no later discussion. > > 1485 UTF8HDR 4.6/DSN: Choice of body part for transport of UTF8SMTP messages > MIME type message/something is proposed, no clear consensus. Poll will be > sent. > > 1486 SMTPEXT 2.7.2: Message retry Text proposed in -06, no later > discussion. > > 1487 UTF8HDR 4.2: Does this specification update MIME? Proposed > resolution: Yes. Say so in introduction. > > 1488 UTF8HDR 4.2: List MIME headers that are modified? Proposed > resolution: Yes. We need an intro saying how we handle the > difference in grammars. > Propose to merge this with 1487. > > 1490 UTF8HDR 4.2: Including Content-Description to picture (grammar) > Propose to merge this with 1487. > > 1491 UTF8HDR 4.2: Extending MIME (ABNF grammar) Propose to merge this > with 1487. > > 1492 SMTPEXT 2.7.3: syntax Text proposed in -06, no later > discussion. > > 1493 SMTPEXT 2.4: Redefining of RCPT TO and MAIL FROM commands (ABNF > grammar) > Text proposed in -06, no later discussion. > > 1494 UTF8HDR 4.4: should include > Proposed resolution: Yes; UTF-8 format needs to be an additional > alternative (=/) on angle-addr. > > 1495 SMTPEXT 2.5/2.6: Reply code used on DATA > Text proposed in -06. > > 1496 DOWNGRADE: Specify a simpler downgrade procedure? > No discussion so far. > > For the "text proposed in -06" tickets, we will interpret silence as "this > is good enough", and resolve the tickets in a week or so. For the issues > with no proposed solution, discussion is needed. > > harald, for the chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 15 01:58:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4pL-0004P7-2I; Fri, 15 Jun 2007 01:58:31 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Hz4pJ-0004Ox-2I for ima-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 01:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4pI-0004Op-Mf for ima@ietf.org; Fri, 15 Jun 2007 01:58:28 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4pH-0006Bb-CW for ima@ietf.org; Fri, 15 Jun 2007 01:58:28 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACF47259729; Fri, 15 Jun 2007 07:58:26 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19715-05; Fri, 15 Jun 2007 07:58:20 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6096259727; Fri, 15 Jun 2007 07:58:20 +0200 (CEST) Message-ID: <46722A7A.9020507@alvestrand.no> Date: Fri, 15 Jun 2007 07:58:18 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] Re: Ticket status, EAI, June 15, 2007 References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dfy4t95f6.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5dfy4t95f6.fsf@Hurtta06k.keh.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > It is still unclear what was destiny of > > ISSUE: UTF8HDR 4.5: and on trace field syntax > > Was that editoral issue? Or was it minor, non-important issue? > I forwarded that to the editors as an editorial issue. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jun 16 02:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzRmz-0000Am-QL; Sat, 16 Jun 2007 02:29:37 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1HzRmz-0000Ae-2c for ima-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 02:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzRmy-0000AW-KZ for ima@ietf.org; Sat, 16 Jun 2007 02:29:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzRmv-0000AC-Pi for ima@ietf.org; Sat, 16 Jun 2007 02:29:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HzRmg-0004lt-5g for ima@ietf.org; Sat, 16 Jun 2007 08:29:18 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 08:29:18 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 08:29:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 16 Jun 2007 09:29:03 +0300 Lines: 228 Message-ID: <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: Kari Hurtta Subject: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand writes in gmane.ietf.ima: > The following tickets are open on the EAI issue tracker: > > 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no > later discussion. I suggest small change to text. Change here is on diff format. Dicussion follows. --------------------------------------------------------------------------- --- draft-ietf-eai-smtpext-06.txt 2007-06-05 06:40:53.000000000 +0300 +++ draft-ietf-eai-smtpext-06.txt--1483 2007-06-16 09:16:28.000000000 +0300 @@ -600,18 +600,26 @@ MUST be transmitted in the form of ACE labels. The protocol value of the WITH clause is UTF8SMTP when this extension is used. More information is in the "IANA Considerations" section of this document. 2.7.4. UTF-8 Reply - If the client issues the "RCPT" command which contains non-ASCII + If the client issues the RCPT command which contains non-ASCII characters, the SMTP server is permitted to use UTF-8 characters within 251 and 551 response codes. Servers MUST NOT include non- ASCII characters except in the limited cases specifically permitted - in this section. + in this section. The SMTP client following this specification MUST + accept UTF-8 on replies of the RCPT command on that case. + If SMTP reply requires UTF-8, but SMTP client does not use + RCPT command which contains non-ASCII characters, the response + code 250 meaning "OK" or 550 meaning "Requested action not taken: + mailbox unavailable" is used. When response codes 250 and 550 is + used on place of 251 and 551 response codes, response do not include + new mailbox. If enhanced mail system status code [RFC3463] + is used, response codes given on below is used. Yao & Mao Expires December 8, 2007 [Page 11] Internet-Draft EAI June 2007 @@ -627,28 +635,26 @@ is included in it and therefore UTF-8 is not needed. UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP server that the client is prepared for UTF-8 on SMTP replies. VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to: - "VRFY" SP uAtom [SP "UTF8REPLY"] CRLF; - ;uAtom is defined in section 2.3 of this document + "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; + ;uLocal-part and uMailbox is defined in section 2.3 of this document - "EXPN" SP uAtom [SP "UTF8REPLY"] CRLF; - ;uAtom is defined in section 2.3 of this document + "EXPN" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; + ;uLocal-part and uMailbox is defined in section 2.3 of this document This parameter "UTF8REPLY" does not have value. If SMTP reply requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in - the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "252" + the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code 252 is used, defined in [RFC2821], meaning "Cannot VRFY user, but will - accept the message and attempt the delivery". If enhanced mail - system status code [RFC3463] is used, the response code should be - "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply - required, but the UTF8REPLY parameter not used.". [[anchor13: REMOVE - THIS: IANA please assign the proper error codes for "5.6.y" and - "2.6.y".]] "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN) + accept the message and attempt the delivery". Also response code 550 + may be used, meaning "Requested action not taken: mailbox unavailable". + If enhanced mail system status code [RFC3463] is used, response codes + given on below is used. "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN) commands enables UTF-8 for that command only. The uAtom of the VRFY and EXPN commands is a user name or a user name and a domain (see below). If a normal (i.e., 250) response is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the @@ -658,12 +664,20 @@ ; uMailbox is defined in section 2.3 of this document ; User Name allows the non-ASCII character. uMailbox ; uMailbox is defined in section 2.3 of this document + + If SMTP reply requires UTF-8, but UTF-8 is not allowed on reply, + and enhanced mail system status code [RFC3463] is used, + the response code should be "5.6.y" or "2.6.y" [SMTP-codes], + meaning that "The UTF-8 reply required, but not allowed.". + [[anchor13: REMOVE THIS: IANA please assign the proper error codes + for "5.6.y" and "2.6.y".]] + If the SMTP Client lack of the UTF8SMTP support receives the UTF-8 message on reply, it may crash. UTF-8 messages on reply are only allowed in the commands under the situations described above. Under --------------------------------------------------------------------------- Discussion: 1) SMTP client needed to be required to accept UTF-8 also on RCPT response. 2) 251 response with UTF-8 mailbox can be replaced with 250 response. 250 response does not include new address. Instead of RCPT TO: 251 2.1.5 New address is , will forward use RCPT TO: 250 2.6.y Address is changed, will forward Of course 251 can not replaced with 550 because that recipient is accepted. Therefore 250 is correct response code. 3) --- start quote -- This parameter "UTF8REPLY" does not have value. If SMTP reply requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "252" is used, defined in [RFC2821], meaning "Cannot VRFY user, but will accept the message and attempt the delivery". If enhanced mail system status code [RFC3463] is used, the response code should be "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply required, but the UTF8REPLY parameter not used.". --- end quote --- Here is problem that that talks only response code "252", but enchanced response codes talk both "5.6.y" and "2.6.y". These "5.6.y" and "2.6.y" are fine -- these should NOT removed. Problem is that these enchanced response codes now apply only to VERIFY and EXPAND. My original text these apply also to RCPT command. On that change effectively ``If enhanced mail system status code [RFC3463] is used, the response code should be "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply required, but the UTF8REPLY parameter not used."?? is moved just to new chapter so that it applies to RCPT -command also. menaing text is also of course change, because RCPT command here did not taken UTF8REPLY paramater. 4) Limiting VRFY and EXPN to uAtom is very restrictive. RFC 2821 quote: ------------------------------ "User name" is a fuzzy term and has been used deliberately. An implementation of the VRFY or EXPN commands MUST include at least recognition of local mailboxes as "user names". However, since current Internet practice often results in a single host handling mail for multiple domains, hosts, especially hosts that provide this functionality, SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY also choose to recognize other strings as "user names". ---- end RFC 2821 quote ------------------------------- uAtom do not accept "@domain" which is "SHOULD" on RFC 2821. With suggested syntax it roughly matches with RFC 2821 text. Yes, actual syntax on RFC 2821 is somewhat conflict with this: RFC 2821 quote: ------------------------------ 4.1.1.6 VERIFY (VRFY) This command asks the receiver to confirm that the argument identifies a user or mailbox. If it is a user name, information is returned as specified in section 3.5. This command has no effect on the reverse-path buffer, the forward- path buffer, or the mail data buffer. Syntax: "VRFY" SP String CRLF 4.1.1.7 EXPAND (EXPN) This command asks the receiver to confirm that the argument identifies a mailing list, and if so, to return the membership of that list. If the command is successful, a reply is returned containing information as described in section 3.5. This reply will have multiple lines except in the trivial case of a one-member list. This command has no effect on the reverse-path buffer, the forward- path buffer, or the mail data buffer and may be issued at any time. Syntax: "EXPN" SP String CRLF ---- end RFC 2821 quote ------------------------------- Where String seems to be String = Atom / Quoted-string ( And anyway uAtom do not cover Quoted-string which is allowed on String ). Seems that RFC 2821 is mess on here also :-( / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 17 12:27:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzxbE-0006U5-Af; Sun, 17 Jun 2007 12:27:36 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1HzxbD-0006Q1-Ls for ima-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 12:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzxbD-0006PU-C4 for ima@ietf.org; Sun, 17 Jun 2007 12:27:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzxbC-0008A8-QH for ima@ietf.org; Sun, 17 Jun 2007 12:27:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hzxb6-00071e-JI for ima@ietf.org; Sun, 17 Jun 2007 18:27:28 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 18:27:28 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jun 2007 18:27:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 17 Jun 2007 19:27:08 +0300 Lines: 94 Message-ID: <5dmyyywnqb.fsf@Hurtta06k.keh.iki.fi> References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Kari Hurtta Subject: [EAI] #1495 draft-ietf-eai-smtpext-06.txt 2.5. Using the ALT-ADDRESS parameter => new title X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand writes in gmane.ietf.ima: > 1495 SMTPEXT 2.5/2.6: Reply code used on DATA > Text proposed in -06. Suggestion on diff format. This is mostly editoral. Discussion follows. ----------------------------------------------------------------------------- --- draft-ietf-eai-smtpext-06.txt 2007-06-05 06:40:53.000000000 +0300 +++ draft-ietf-eai-smtpext-06.txt-1495 2007-06-17 19:23:49.000000000 +0300 @@ -450,13 +450,18 @@ address before xtext encoding. -2.5. Using the ALT-ADDRESS parameter +2.5. Using the ALT-ADDRESS parameter and message downgrading A message containing non-ASCII envelope addresses or header fields MUST NOT be sent to an SMTP server which does not support UTF8SMTP. Such a message MAY be rejected due to lack of the ALT-ADDRESS as discussed in section 2.2 of this document. + [EAI-utf8header] specifies "UTF8SMTP message" which requires + UTF8SMTP support. Such a message MUST NOT be sent to an SMTP server + which does not support UTF8SMTP. Such a message MAY be rejected due + downgrade failure or lack of the downgrade support. + When messages are rejected because they require UTF8SMTP, response code "550" is used, defined in [RFC2821], meaning "mailbox unavailable". If enhanced mail system status codes [RFC3463] is @@ -465,7 +470,7 @@ If the response code is issued after the final "." of the DATA command, the response code "554" is used, defined in [RFC2821], - meaning "Transaction failed". if enhanced mail system status codes + meaning "Transaction failed". If enhanced mail system status codes [RFC3463] is used, the response code should be "5.6.z" [SMTP-codes], meaning that "UTF8SMTP downgrade failed". ----------------------------------------------------------------------------- Discussion: ------start quote---------- 2.5. Using the ALT-ADDRESS parameter A message containing non-ASCII envelope addresses or header fields MUST NOT be sent to an SMTP server which does not support UTF8SMTP. Such a message MAY be rejected due to lack of the ALT-ADDRESS as discussed in section 2.2 of this document. When messages are rejected because they require UTF8SMTP, response code "550" is used, defined in [RFC2821], meaning "mailbox unavailable". If enhanced mail system status codes [RFC3463] is used, the response code should be "5.6.x" [SMTP-codes], meaning that "alt-address is required but not specified". If the response code is issued after the final "." of the DATA command, the response code "554" is used, defined in [RFC2821], meaning "Transaction failed". if enhanced mail system status codes [RFC3463] is used, the response code should be "5.6.z" [SMTP-codes], meaning that "UTF8SMTP downgrade failed". [[anchor8: REMOVE THIS: IANA please assign the proper error codes for "5.6.x" and "5.6.z".]] -------end quote---------------- 1) Now, when this section talks also DATA command and downgrade failure, title "Using the ALT-ADDRESS parameter" does not describe it. I suggested of alternative. Is someone better suggestion for title? 2) It is better to give pointer to draft-ietf-eai-utf8headers (section 4.6 UTF8SMTP message), where is listed conditions when message requires UTF8SMTP support. It does not make sense reproduce them on here. Another thing is that these conditions may be controversial. But it does not have effect to here. More likely is that message is not rejected, but instead NDN is sent. This text does not prevent that case. Generation of NDN is mentioned on section 2.2 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 18 05:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dxi-0004Hn-9I; Mon, 18 Jun 2007 05:55:54 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0Dxh-0004Hh-9X for ima-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dxg-0004HZ-Vh for ima@ietf.org; Mon, 18 Jun 2007 05:55:52 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Dxf-0007Ng-68 for ima@ietf.org; Mon, 18 Jun 2007 05:55:52 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew$man#ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 467656a5.15c4c.4c for ima@ietf.org; Mon, 18 Jun 2007 10:55:49 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5I9tnZ2029009 for ; Mon, 18 Jun 2007 10:55:50 +0100 (BST) Subject: Fwd: Re: [EAI] Ticket status, EAI, June 15, 2007 References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 18 Jun 2007 10:55:48 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 14 Jun 2007 23:19:28 +0100, Harald Tveit Alvestrand wrote: > The following tickets are open on the EAI issue tracker: > 1485 UTF8HDR 4.6/DSN: Choice of body part for transport of UTF8SMTP > messages > MIME type message/something is proposed, no clear consensus. Poll will be > sent. It would be premature to send a poll on this until there exist clear technical descriptions of the proposed options. As regards the proposed message/utf8smtp (by whatever nsme it is eventually called) I have repeatedly asked for answers to the following three questions: 1. Is a message/utf8smtp supposed to be transportable on the existing network? 2. If so, what is supposed to happen when it encounters a MTA that does not support 8BITMIME? 3. Which currently deployed MTAs will actually do whatever is the answer to Q2 (and which will not do it, for that matter)? Nobody has yet seen fit to answer these questions. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 19 01:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0WQJ-0000nn-Ph; Tue, 19 Jun 2007 01:38:39 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0WQI-0000m5-MB for ima-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 01:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0WQI-0000lx-A1 for ima@ietf.org; Tue, 19 Jun 2007 01:38:38 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0WQH-0004m4-MQ for ima@ietf.org; Tue, 19 Jun 2007 01:38:38 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l5J5cawG028366; Tue, 19 Jun 2007 14:38:36 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007061914383523145 ; Tue, 19 Jun 2007 14:38:35 +0900 Date: Tue, 19 Jun 2007 14:38:35 +0900 (JST) Message-Id: <20070619.143835.41648021.fujiwara@jprs.co.jp> To: klensin@jck.com Subject: Re: [EAI] ISSUE: Trivial downgrading From: fujiwara@jprs.co.jp In-Reply-To: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Is partial downgrading a solution for the trivial downgrading? No downgrading is always allowed. So, implementor can implement such implementation as: > * Converts the known header fields containing UTF-8 data > into the same fields with encoded words. * Don't touch trace headers. If trace headers contain non-ASCII characters, the downgrading fails. * Don't touch unknown headers. If unknown headers contain non-ASCII characters, the downgrading fails. * Don't touch address headers except in comments. If any address header contains non-ASCII addresses, the downgrading fails. * Don't touch the MIME body part headers. If the MIME body part headers contain non-ASCII characters, the downgrading fails. This is one of trivial downgrading, I think. Is it true? -- Kazunori Fujiwara, JPRS > From: John C Klensin > Hi. > > Kari and I have been having an offlist discussion that has > inspired a thought. > > Suppose one has a message that has UTF-8 headers, but there are > no non-ASCII addresses in the headers (either forward or > backward-pointing). This may actually turn out to be a common > case for people who stick with ASCII-addresses (either for > interoperability or because, e.g., their names don't happen to > require non-ASCII characters even if their languages are written > using extended "Latin" scripts and do). But, if they are using > UTF8SMTP-aware MUAs and Submission servers (MSAs), they are > likely to be producing non-ASCII subject lines (as is the case > today), but sending them as UTF-8 rather than as encoded words. > There are some other cases, but this is the important one. > > At present, our rules appear to sent such messages through the > entire downgrade process, generating Downgrade headers, etc. > > I wonder if, to make that class of cases efficient and maximize > its utility, we ought to have a different downgrade path that > simply: > > * Converts the known header fields containing UTF-8 data > into the same fields with encoded words. > > * Documents the conversion only in trace information (i.e., > no "Downgraded:" headers). > > * If any body parts or information require downgrading, > treat them strictly according to the 8BITMIME rules, which > would obviously apply. > > This would, of course, apply only if no non-ASCII addresses were > present and all of the header fields that contained UTF-8 data > were known (see below). The present downgrade procedure, and > the conditions associated with it, would continue to apply to > all other cases. > > The reason for a "known header" restriction is fear of > information loss if we start tampering with headers that are not > recognized, i.e., those for which explicit rules about encoding > of non-ASCII information does not exist already. But the net > effect of this approach would be to downgrade by recreating > _exactly_ the types of messages that can be sent today (without > the EAI extension), with no new headers or other material, from > messages that are just the UTF-8 rendering of their encoded > words ... almost exactly symmetric with the intent of the > 8BITMIME transformations. > > Having two downgrade styles does add complexity, but because > this one is simple enough and has no expectation about anything > UTF8-aware on the far side of the downgrade (even aware enough > to pass Downgraded header fields), maybe it would be more widely > implemented and perceived as worth the trouble. > > Thoughts? I think that, if there is interest, Kari and I could > write it up fairly quickly (for the record, he doesn't know that > I'm volunteering him). > > john > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 19 05:15:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZoG-0005JI-3q; Tue, 19 Jun 2007 05:15:36 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0ZoF-0005JA-Bj for ima-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 05:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZoF-0005J2-1o for ima@ietf.org; Tue, 19 Jun 2007 05:15:35 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ZoD-0005dD-59 for ima@ietf.org; Tue, 19 Jun 2007 05:15:35 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5J9FTbm008725 for ; Tue, 19 Jun 2007 18:15:29 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 2b4a_9fb424b4_1e45_11dc_8c51_0014221f2a2d; Tue, 19 Jun 2007 18:15:28 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:54318) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 19 Jun 2007 18:13:32 +0900 Message-Id: <6.0.0.20.2.20070619145141.05856d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jun 2007 14:52:54 +0900 To: fujiwara@jprs.co.jp, klensin@jck.com From: Martin Duerst Subject: Re: [EAI] ISSUE: Trivial downgrading In-Reply-To: <20070619.143835.41648021.fujiwara@jprs.co.jp> References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> <20070619.143835.41648021.fujiwara@jprs.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I think the difference between John's proposal and this one is that the way I understood it, John is proposing that there are two ways of downgrading, and that in many cases, mail servers would implement both. The list below suggests that a server in general would choose just one. Regards, Martin. At 14:38 07/06/19, fujiwara@jprs.co.jp wrote: >Is partial downgrading a solution for the trivial downgrading? > >No downgrading is always allowed. > >So, implementor can implement such implementation as: >> * Converts the known header fields containing UTF-8 data >> into the same fields with encoded words. > > * Don't touch trace headers. If trace headers contain > non-ASCII characters, the downgrading fails. > > * Don't touch unknown headers. If unknown headers contain > non-ASCII characters, the downgrading fails. > > * Don't touch address headers except in comments. > If any address header contains non-ASCII addresses, > the downgrading fails. > > * Don't touch the MIME body part headers. > If the MIME body part headers contain non-ASCII characters, > the downgrading fails. > >This is one of trivial downgrading, I think. > >Is it true? > >-- >Kazunori Fujiwara, JPRS > >> From: John C Klensin >> Hi. >> >> Kari and I have been having an offlist discussion that has >> inspired a thought. >> >> Suppose one has a message that has UTF-8 headers, but there are >> no non-ASCII addresses in the headers (either forward or >> backward-pointing). This may actually turn out to be a common >> case for people who stick with ASCII-addresses (either for >> interoperability or because, e.g., their names don't happen to >> require non-ASCII characters even if their languages are written >> using extended "Latin" scripts and do). But, if they are using >> UTF8SMTP-aware MUAs and Submission servers (MSAs), they are >> likely to be producing non-ASCII subject lines (as is the case >> today), but sending them as UTF-8 rather than as encoded words. >> There are some other cases, but this is the important one. >> >> At present, our rules appear to sent such messages through the >> entire downgrade process, generating Downgrade headers, etc. >> >> I wonder if, to make that class of cases efficient and maximize >> its utility, we ought to have a different downgrade path that >> simply: >> >> * Converts the known header fields containing UTF-8 data >> into the same fields with encoded words. >> >> * Documents the conversion only in trace information (i.e., >> no "Downgraded:" headers). >> >> * If any body parts or information require downgrading, >> treat them strictly according to the 8BITMIME rules, which >> would obviously apply. >> >> This would, of course, apply only if no non-ASCII addresses were >> present and all of the header fields that contained UTF-8 data >> were known (see below). The present downgrade procedure, and >> the conditions associated with it, would continue to apply to >> all other cases. >> >> The reason for a "known header" restriction is fear of >> information loss if we start tampering with headers that are not >> recognized, i.e., those for which explicit rules about encoding >> of non-ASCII information does not exist already. But the net >> effect of this approach would be to downgrade by recreating >> _exactly_ the types of messages that can be sent today (without >> the EAI extension), with no new headers or other material, from >> messages that are just the UTF-8 rendering of their encoded >> words ... almost exactly symmetric with the intent of the >> 8BITMIME transformations. >> >> Having two downgrade styles does add complexity, but because >> this one is simple enough and has no expectation about anything >> UTF8-aware on the far side of the downgrade (even aware enough >> to pass Downgraded header fields), maybe it would be more widely >> implemented and perceived as worth the trouble. >> >> Thoughts? I think that, if there is interest, Kari and I could >> write it up fairly quickly (for the record, he doesn't know that >> I'm volunteering him). >> >> john >> >> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www1.ietf.org/mailman/listinfo/ima >> > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 19 15:30:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jPh-00013L-O2; Tue, 19 Jun 2007 15:30:53 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0jPg-00013D-AN for ima-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:30:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jPg-000135-0u for ima@ietf.org; Tue, 19 Jun 2007 15:30:52 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jPe-0003Ej-LU for ima@ietf.org; Tue, 19 Jun 2007 15:30:52 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1I0jPa-0007dT-8P; Tue, 19 Jun 2007 15:30:46 -0400 Date: Tue, 19 Jun 2007 15:30:44 -0400 From: John C Klensin To: Martin Duerst , fujiwara@jprs.co.jp Subject: Re: [EAI] ISSUE: Trivial downgrading Message-ID: <1DF23DF6656E062F8D9F6925@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20070619145141.05856d80@localhost> References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> <20070619.143835.41648021.fujiwara@jprs.co.jp> <6.0.0.20.2.20070619145141.05856d80@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 19 June, 2007 14:52 +0900 Martin Duerst wrote: > I think the difference between John's proposal and this one > is that the way I understood it, John is proposing that there > are two ways of downgrading, and that in many cases, mail > servers would implement both. The list below suggests that > a server in general would choose just one. Martin, I think Fujiwara-san is correct and that "trivial" is just one special case. I apologize for any additional confusion I may have contributed. There are still questions here that I think the WG needs to consider. For example: (1) Is the explanation in the downgrading document clear enough as to what is permitted, what is permitted to go in (e.g., that downgrading is not possible if any of the header addresses are non-ASCII and do no have ASCII forms), and what comes out under various circumstances. My personal belief is that the answer is "no" with the current posted version. The editors (design) team is working on that issue, but I hope that, once the next version is posted, other participants in the WG will make suggestions about how clarity can be further improved where that is appropriate. (2) Are there sufficient options in, and paths through, the downgrading process, depending either on the input or on server choices, to cause an interoperability or "user surprise" problem and, if so, is there a way to reduce them? I think the answer is "no", but that is just my opinion of the moment. It is clear to me that making downgrading work cleanly in the maximum number of cases, without either causing long-term harm in a world after most mail systems have been upgraded or delaying upgrading, is the largest challenge facing this WG; I'm not sure we are in the right place on that path yet. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 20 03:08:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uIR-0005In-Bb; Wed, 20 Jun 2007 03:08:07 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0uIP-0005If-PR for ima-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 03:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uIP-0005IX-F2 for ima@ietf.org; Wed, 20 Jun 2007 03:08:05 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0uIN-0008Uu-Er for ima@ietf.org; Wed, 20 Jun 2007 03:08:05 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5K78206023367 for ; Wed, 20 Jun 2007 07:08:03 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJX00701AD97G00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Wed, 20 Jun 2007 01:08:02 -0600 (MDT) Received: from [10.1.110.5] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJX00DJ6AH4BF20@mail-amer.sun.com>; Wed, 20 Jun 2007 01:08:02 -0600 (MDT) Date: Mon, 18 Jun 2007 09:49:25 -0700 From: Chris Newman Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply In-reply-to: <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> To: Kari Hurtta , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.3 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org For SMTP, allowing UTF-8 in error responses opens a can of worms. SMTP error response text needs to be comprehensible by: * An arbitrary remote system administrator * The local system administrator * The end-user Probably in that priority order (although that's debatable and may be= different=20 for SUBMIT). That means SMTP response text may have to be in more th= an one=20 language and guidance needs to be provided for language selection. I would not consider a document allowing UTF-8 in response text compl= ete unless=20 dodges this issue (e.g., by only allowing UTF-8 in addresses) or conf= ronts this=20 issue. - Chris Kari Hurtta wrote on 6/16/07 9:29 +0300: > Harald Tveit Alvestrand writes in gmane.ietf= .ima: > >> The following tickets are open on the EAI issue tracker: >> >> 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06= , no >> later discussion. > > I suggest small change to text. Change here is on diff format. > Dicussion follows. > > -------------------------------------------------------------------= -------- > --- draft-ietf-eai-smtpext-06.txt=092007-06-05 06:40:53.000000000 += 0300 > +++ draft-ietf-eai-smtpext-06.txt--1483=092007-06-16 09:16:28.00000= 0000 +0300 > @@ -600,18 +600,26 @@ > MUST be transmitted in the form of ACE labels. The protocol va= lue of > the WITH clause is UTF8SMTP when this extension is used. More > information is in the "IANA Considerations" section of this doc= ument. > > 2.7.4. UTF-8 Reply > > - If the client issues the "RCPT" command which contains non-ASCI= I > + If the client issues the RCPT command which contains non-ASCII > characters, the SMTP server is permitted to use UTF-8 character= s > within 251 and 551 response codes. Servers MUST NOT include no= n- > ASCII characters except in the limited cases specifically permi= tted > - in this section. > + in this section. The SMTP client following this specification M= UST > + accept UTF-8 on replies of the RCPT command on that case. > > + If SMTP reply requires UTF-8, but SMTP client does not use > + RCPT command which contains non-ASCII characters, the response > + code 250 meaning "OK" or 550 meaning "Requested action not tak= en: > + mailbox unavailable" is used. When response codes 250 and 550 = is > + used on place of 251 and 551 response codes, response do not in= clude > + new mailbox. If enhanced mail system status code [RFC3463] > + is used, response codes given on below is used. > > > Yao & Mao Expires December 8, 2007 [Pa= ge 11] > =0C > Internet-Draft EAI Jun= e 2007 > > @@ -627,28 +635,26 @@ > is included in it and therefore UTF-8 is not needed. UTF8REPLY > parameter on the VRFY and EXPN commands tells the SMTP server t= hat > the client is prepared for UTF-8 on SMTP replies. > > VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to: > > - "VRFY" SP uAtom [SP "UTF8REPLY"] CRLF; > - ;uAtom is defined in section 2.3 of this document > + "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; > + ;uLocal-part and uMailbox is defined in section 2.3 = of this > document > - "EXPN" SP uAtom [SP "UTF8REPLY"] CRLF; > - ;uAtom is defined in section 2.3 of this document > + "EXPN" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; > + ;uLocal-part and uMailbox is defined in section 2.3 = of this > document > This parameter "UTF8REPLY" does not have value. If SMTP reply > requires UTF-8, but SMTP client does not use "UTF8REPLY" parame= ter in > - the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code= "252" > + the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code= 252 > is used, defined in [RFC2821], meaning "Cannot VRFY user, but w= ill > - accept the message and attempt the delivery". If enhanced mail > - system status code [RFC3463] is used, the response code should = be > - "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply > - required, but the UTF8REPLY parameter not used.". [[anchor13: R= EMOVE > - THIS: IANA please assign the proper error codes for "5.6.y" and > - "2.6.y".]] "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN) > + accept the message and attempt the delivery". Also response cod= e 550 > + may be used, meaning "Requested action not taken: mailbox unava= ilable". > + If enhanced mail system status code [RFC3463] is used, response= codes > + given on below is used. "UTF8REPLY" on the VERIFY (VRFY) or EXP= AND (EXPN) > commands enables UTF-8 for that command only. > > The uAtom of the VRFY and EXPN commands is a user name or a use= r name > and a domain (see below). If a normal (i.e., 250) response is > returned, the response MAY include the full name of the user an= d MUST > include the mailbox of the user. It MUST be in either of the > @@ -658,12 +664,20 @@ > ; uMailbox is defined in section 2.3 of this docum= ent > ; User Name allows the non-ASCII character. > > uMailbox > ; uMailbox is defined in section 2.3 of this docum= ent > > + > + If SMTP reply requires UTF-8, but UTF-8 is not allowed on reply= , > + and enhanced mail system status code [RFC3463] is used, > + the response code should be "5.6.y" or "2.6.y" [SMTP-codes], > + meaning that "The UTF-8 reply required, but not allowed.". > + [[anchor13: REMOVE THIS: IANA please assign the proper error co= des > + for "5.6.y" and "2.6.y".]] > + > If the SMTP Client lack of the UTF8SMTP support receives the UT= F-8 > message on reply, it may crash. UTF-8 messages on reply are on= ly > allowed in the commands under the situations described above. = Under > > > > > -------------------------------------------------------------------= -------- > > Discussion: > > 1) > > SMTP client needed to be required to accept UTF-8 also on RCPT resp= onse. > > 2) > > 251 response with UTF-8 mailbox can be replaced with 250 response. > 250 response does not include new address. > > Instead of > > RCPT TO: > 251 2.1.5 New address is ,= will forward > > use > > RCPT TO: > 250 2.6.y Address is changed, will forward > > > Of course 251 can not replaced with 550 because that recipient is a= ccepted. > Therefore 250 is correct response code. > > 3) > > --- start quote -- > This parameter "UTF8REPLY" does not have value. If SMTP reply > requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter = in > the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "25= 2" > is used, defined in [RFC2821], meaning "Cannot VRFY user, but will > accept the message and attempt the delivery". If enhanced mail > system status code [RFC3463] is used, the response code should be > "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply > required, but the UTF8REPLY parameter not used.". > --- end quote --- > > Here is problem that that talks only response code "252", but > enchanced response codes talk both "5.6.y" and "2.6.y". > > These "5.6.y" and "2.6.y" are fine -- these should NOT removed. > > Problem is that these enchanced response codes now apply only > to VERIFY and EXPAND. My original text these apply also to > RCPT command. > > On that change effectively > ``If enhanced mail > system status code [RFC3463] is used, the response code should= be > "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply > required, but the UTF8REPLY parameter not used."?? > is moved just to new chapter so that it applies to RCPT > -command also. menaing text is also of course change, because > RCPT command here did not taken UTF8REPLY paramater. > > 4) > > Limiting VRFY and EXPN to uAtom is very restrictive. > > RFC 2821 quote: ------------------------------ > > > "User name" is a fuzzy term and has been used deliberately. An > implementation of the VRFY or EXPN commands MUST include at leas= t > recognition of local mailboxes as "user names". However, since > current Internet practice often results in a single host handlin= g > mail for multiple domains, hosts, especially hosts that provide = this > functionality, SHOULD accept the "local-part@domain" form as a "= user > name"; hosts MAY also choose to recognize other strings as "user > names". > ---- end RFC 2821 quote ------------------------------- > > > uAtom do not accept "@domain" which is "SHOULD" on RFC 2821. > > With suggested syntax it roughly matches with RFC 2821 text. > > > Yes, actual syntax on RFC 2821 is somewhat conflict with > this: > > RFC 2821 quote: ------------------------------ > 4.1.1.6 VERIFY (VRFY) > > This command asks the receiver to confirm that the argument > identifies a user or mailbox. If it is a user name, information= is > returned as specified in section 3.5. > > This command has no effect on the reverse-path buffer, the forwa= rd- > path buffer, or the mail data buffer. > > Syntax: > "VRFY" SP String CRLF > > 4.1.1.7 EXPAND (EXPN) > > This command asks the receiver to confirm that the argument > identifies a mailing list, and if so, to return the membership o= f > that list. If the command is successful, a reply is returned > containing information as described in section 3.5. This reply = will > have multiple lines except in the trivial case of a one-member l= ist. > > This command has no effect on the reverse-path buffer, the forwa= rd- > path buffer, or the mail data buffer and may be issued at any ti= me. > > Syntax: > "EXPN" SP String CRLF > > ---- end RFC 2821 quote ------------------------------- > > Where String seems to be > > String =3D Atom / Quoted-string > > > > ( And anyway uAtom do not cover Quoted-string which is allowed on > String ). > > Seems that RFC 2821 is mess on here also :-( > > > / Kari Hurtta > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 20 03:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uIX-0005MV-HN; Wed, 20 Jun 2007 03:08:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0uIW-0005MJ-Ht for ima-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 03:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uIW-0005M9-7R for ima@ietf.org; Wed, 20 Jun 2007 03:08:12 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0uIT-0008Uv-R5 for ima@ietf.org; Wed, 20 Jun 2007 03:08:12 -0400 Received: (eyou send program); Wed, 20 Jun 2007 15:08:01 +0800 Message-ID: <382323281.21509@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.9) by 159.226.7.146 with SMTP; Wed, 20 Jun 2007 15:08:01 +0800 Message-ID: <00fd01c7b309$bd68ad60$096ff1da@yaojk> From: "YAO Jiankang" To: References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <382097668.26386@cnnic.cn> Subject: Re: [EAI] #1495 draft-ietf-eai-smtpext-06.txt 2.5. Using theALT-ADDRESS parameter => new title Date: Wed, 20 Jun 2007 15:08:01 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 1.0 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1946469223==" Errors-To: ima-bounces@ietf.org --===============1946469223== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkthcmkgSHVydHRhIiA8aHVy dHRhK2dtYW5lQHNpaWxvLmZtaS5maT4NClRvOiA8aW1hQGlldGYub3JnPg0KQ2M6ICJLYXJpIEh1 cnR0YSIgPGh1cnR0YStnbWFuZUBzaWlsby5mbWkuZmk+DQpTZW50OiBNb25kYXksIEp1bmUgMTgs IDIwMDcgMTI6MjcgQU0NClN1YmplY3Q6IFtFQUldICMxNDk1IGRyYWZ0LWlldGYtZWFpLXNtdHBl eHQtMDYudHh0IDIuNS4gVXNpbmcgdGhlQUxULUFERFJFU1MgcGFyYW1ldGVyID0+IG5ldyB0aXRs ZSANCg0KDQo+IEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4g d3JpdGVzIGluIGdtYW5lLmlldGYuaW1hOg0KPiANCj4+IDE0OTUgU01UUEVYVCAyLjUvMi42OiBS ZXBseSBjb2RlIHVzZWQgb24gREFUQQ0KPj4gVGV4dCBwcm9wb3NlZCBpbiAtMDYuDQo+IA0KPiBT dWdnZXN0aW9uIG9uIGRpZmYgZm9ybWF0LiAgVGhpcyBpcyBtb3N0bHkgZWRpdG9yYWwuIERpc2N1 c3Npb24gZm9sbG93cy4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLSBkcmFmdC1p ZXRmLWVhaS1zbXRwZXh0LTA2LnR4dCAyMDA3LTA2LTA1IDA2OjQwOjUzLjAwMDAwMDAwMCArMDMw MA0KPiArKysgZHJhZnQtaWV0Zi1lYWktc210cGV4dC0wNi50eHQtMTQ5NSAyMDA3LTA2LTE3IDE5 OjIzOjQ5LjAwMDAwMDAwMCArMDMwMA0KPiBAQCAtNDUwLDEzICs0NTAsMTggQEANCj4gDQo+ICAg IGFkZHJlc3MgYmVmb3JlIHh0ZXh0IGVuY29kaW5nLg0KPiANCj4gLTIuNS4gIFVzaW5nIHRoZSBB TFQtQUREUkVTUyBwYXJhbWV0ZXINCj4gKzIuNS4gIFVzaW5nIHRoZSBBTFQtQUREUkVTUyBwYXJh bWV0ZXIgYW5kIG1lc3NhZ2UgZG93bmdyYWRpbmcNCj4gDQo+ICAgIEEgbWVzc2FnZSBjb250YWlu aW5nIG5vbi1BU0NJSSBlbnZlbG9wZSBhZGRyZXNzZXMgb3IgaGVhZGVyIGZpZWxkcw0KPiAgICBN VVNUIE5PVCBiZSBzZW50IHRvIGFuIFNNVFAgc2VydmVyIHdoaWNoIGRvZXMgbm90IHN1cHBvcnQg VVRGOFNNVFAuDQo+ICAgIFN1Y2ggYSBtZXNzYWdlIE1BWSBiZSByZWplY3RlZCBkdWUgdG8gbGFj ayBvZiB0aGUgQUxULUFERFJFU1MgYXMNCj4gICAgZGlzY3Vzc2VkIGluIHNlY3Rpb24gMi4yIG9m IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiArICAgW0VBSS11dGY4aGVhZGVyXSBzcGVjaWZpZXMgIlVU RjhTTVRQIG1lc3NhZ2UiIHdoaWNoIHJlcXVpcmVzDQo+ICsgICBVVEY4U01UUCBzdXBwb3J0LiAg U3VjaCBhIG1lc3NhZ2UgTVVTVCBOT1QgYmUgc2VudCB0byBhbiBTTVRQIHNlcnZlciANCj4gKyAg IHdoaWNoIGRvZXMgbm90IHN1cHBvcnQgVVRGOFNNVFAuIFN1Y2ggYSBtZXNzYWdlIE1BWSBiZSBy ZWplY3RlZCBkdWUgDQo+ICsgICBkb3duZ3JhZGUgZmFpbHVyZSBvciBsYWNrIG9mIHRoZSBkb3du Z3JhZGUgc3VwcG9ydC4NCj4gKw0KPiAgICBXaGVuIG1lc3NhZ2VzIGFyZSByZWplY3RlZCBiZWNh dXNlIHRoZXkgcmVxdWlyZSBVVEY4U01UUCwgcmVzcG9uc2UNCj4gICAgY29kZSAiNTUwIiBpcyB1 c2VkLCBkZWZpbmVkIGluIFtSRkMyODIxXSwgbWVhbmluZyAibWFpbGJveA0KPiAgICB1bmF2YWls YWJsZSIuICBJZiBlbmhhbmNlZCBtYWlsIHN5c3RlbSBzdGF0dXMgY29kZXMgW1JGQzM0NjNdIGlz DQo+IEBAIC00NjUsNyArNDcwLDcgQEANCj4gDQo+ICAgIElmIHRoZSByZXNwb25zZSBjb2RlIGlz IGlzc3VlZCBhZnRlciB0aGUgZmluYWwgIi4iIG9mIHRoZSBEQVRBDQo+ICAgIGNvbW1hbmQsIHRo ZSByZXNwb25zZSBjb2RlICI1NTQiIGlzIHVzZWQsIGRlZmluZWQgaW4gW1JGQzI4MjFdLA0KPiAt ICAgbWVhbmluZyAiVHJhbnNhY3Rpb24gZmFpbGVkIi4gaWYgZW5oYW5jZWQgbWFpbCBzeXN0ZW0g c3RhdHVzIGNvZGVzDQo+ICsgICBtZWFuaW5nICJUcmFuc2FjdGlvbiBmYWlsZWQiLiBJZiBlbmhh bmNlZCBtYWlsIHN5c3RlbSBzdGF0dXMgY29kZXMNCj4gICAgW1JGQzM0NjNdIGlzIHVzZWQsIHRo ZSByZXNwb25zZSBjb2RlIHNob3VsZCBiZSAiNS42LnoiIFtTTVRQLWNvZGVzXSwNCj4gICAgbWVh bmluZyB0aGF0ICJVVEY4U01UUCBkb3duZ3JhZGUgZmFpbGVkIi4NCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IA0KPiBEaXNjdXNzaW9uOg0KPiANCj4gDQo+IC0tLS0tLXN0YXJ0IHF1b3Rl LS0tLS0tLS0tLQ0KPiAyLjUuICBVc2luZyB0aGUgQUxULUFERFJFU1MgcGFyYW1ldGVyDQo+IA0K PiAgIEEgbWVzc2FnZSBjb250YWluaW5nIG5vbi1BU0NJSSBlbnZlbG9wZSBhZGRyZXNzZXMgb3Ig aGVhZGVyIGZpZWxkcw0KPiAgIE1VU1QgTk9UIGJlIHNlbnQgdG8gYW4gU01UUCBzZXJ2ZXIgd2hp Y2ggZG9lcyBub3Qgc3VwcG9ydCBVVEY4U01UUC4NCj4gICBTdWNoIGEgbWVzc2FnZSBNQVkgYmUg cmVqZWN0ZWQgZHVlIHRvIGxhY2sgb2YgdGhlIEFMVC1BRERSRVNTIGFzDQo+ICAgZGlzY3Vzc2Vk IGluIHNlY3Rpb24gMi4yIG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAgIFdoZW4gbWVzc2FnZXMg YXJlIHJlamVjdGVkIGJlY2F1c2UgdGhleSByZXF1aXJlIFVURjhTTVRQLCByZXNwb25zZQ0KPiAg IGNvZGUgIjU1MCIgaXMgdXNlZCwgZGVmaW5lZCBpbiBbUkZDMjgyMV0sIG1lYW5pbmcgIm1haWxi b3gNCj4gICB1bmF2YWlsYWJsZSIuICBJZiBlbmhhbmNlZCBtYWlsIHN5c3RlbSBzdGF0dXMgY29k ZXMgW1JGQzM0NjNdIGlzDQo+ICAgdXNlZCwgdGhlIHJlc3BvbnNlIGNvZGUgc2hvdWxkIGJlICI1 LjYueCIgW1NNVFAtY29kZXNdLCBtZWFuaW5nIHRoYXQNCj4gICAiYWx0LWFkZHJlc3MgaXMgcmVx dWlyZWQgYnV0IG5vdCBzcGVjaWZpZWQiLg0KPiANCj4gICBJZiB0aGUgcmVzcG9uc2UgY29kZSBp cyBpc3N1ZWQgYWZ0ZXIgdGhlIGZpbmFsICIuIiBvZiB0aGUgREFUQQ0KPiAgIGNvbW1hbmQsIHRo ZSByZXNwb25zZSBjb2RlICI1NTQiIGlzIHVzZWQsIGRlZmluZWQgaW4gW1JGQzI4MjFdLA0KPiAg IG1lYW5pbmcgIlRyYW5zYWN0aW9uIGZhaWxlZCIuIGlmIGVuaGFuY2VkIG1haWwgc3lzdGVtIHN0 YXR1cyBjb2Rlcw0KPiAgIFtSRkMzNDYzXSBpcyB1c2VkLCB0aGUgcmVzcG9uc2UgY29kZSBzaG91 bGQgYmUgIjUuNi56IiBbU01UUC1jb2Rlc10sDQo+ICAgbWVhbmluZyB0aGF0ICJVVEY4U01UUCBk b3duZ3JhZGUgZmFpbGVkIi4NCj4gDQo+ICAgW1thbmNob3I4OiBSRU1PVkUgVEhJUzogSUFOQSBw bGVhc2UgYXNzaWduIHRoZSBwcm9wZXIgZXJyb3IgY29kZXMgZm9yDQo+ICAgIjUuNi54IiBhbmQg IjUuNi56Ii5dXQ0KPiAtLS0tLS0tZW5kIHF1b3RlLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gMSkN Cj4gDQo+IE5vdywgd2hlbiB0aGlzIHNlY3Rpb24gdGFsa3MgYWxzbyBEQVRBIGNvbW1hbmQgYW5k IGRvd25ncmFkZSBmYWlsdXJlLA0KPiB0aXRsZSAiVXNpbmcgdGhlIEFMVC1BRERSRVNTIHBhcmFt ZXRlciIgZG9lcyBub3QgZGVzY3JpYmUgaXQuDQo+IA0KPiBJIHN1Z2dlc3RlZCBvZiBhbHRlcm5h dGl2ZS4gSXMgc29tZW9uZSBiZXR0ZXIgc3VnZ2VzdGlvbiBmb3IgdGl0bGU/DQoNClRoYW5rcyBh IGxvdCBmb3Iga2luZCBjb21tZW50cy4NCmhvdyBhYm91dCAiQUxULUFERFJFU1MgcGFyYW1ldGVy IHVzYWdlIGFuZCByZXNwb25zZSBjb2RlcyI/DQoNCg0KWUFPIEppYW5rYW5nDQoNCg== --===============1946469223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1946469223==-- From ima-bounces@ietf.org Wed Jun 20 05:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wqr-0007Ez-Fg; Wed, 20 Jun 2007 05:51:49 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0wqq-0007Ax-HN for ima-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 05:51:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wqq-0007Am-79 for ima@ietf.org; Wed, 20 Jun 2007 05:51:48 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wqn-0008Mu-Jm for ima@ietf.org; Wed, 20 Jun 2007 05:51:48 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew&man#ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4678f8af.15402.35 for ima@ietf.org; Wed, 20 Jun 2007 10:51:43 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5K9peuV026966 for ; Wed, 20 Jun 2007 10:51:41 +0100 (BST) Subject: Fwd: Re: [EAI] ISSUE: Trivial downgrading References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> <20070619.143835.41648021.fujiwara@jprs.co.jp> <6.0.0.20.2.20070619145141.05856d80@localhost> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 20 Jun 2007 10:51:40 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 19 Jun 2007 06:52:54 +0100, Martin Duerst wrote: > I think the difference between John's proposal and this one > is that the way I understood it, John is proposing that there > are two ways of downgrading, and that in many cases, mail > servers would implement both. The list below suggests that > a server in general would choose just one. But since, in fact, what John is proposing seems to me to be identical to what is already in the downgrade drafts, I am at a loss to understand what difference will actually exist. Unless I have missed some feature of John's idea. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 20 07:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0y1k-0006rb-6w; Wed, 20 Jun 2007 07:07:08 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I0y1j-0006mv-MF for ima-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 07:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0y1j-0006j4-4j for ima@ietf.org; Wed, 20 Jun 2007 07:07:07 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0y1h-0001FI-LO for ima@ietf.org; Wed, 20 Jun 2007 07:07:07 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C89B2596C9; Wed, 20 Jun 2007 13:07:04 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02767-08; Wed, 20 Jun 2007 13:06:51 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E5AF2596C8; Wed, 20 Jun 2007 13:06:51 +0200 (CEST) Message-ID: <46790A4B.7050703@alvestrand.no> Date: Wed, 20 Jun 2007 13:06:51 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Chris Newman Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman wrote: > For SMTP, allowing UTF-8 in error responses opens a can of worms. > > SMTP error response text needs to be comprehensible by: > * An arbitrary remote system administrator > * The local system administrator > * The end-user > Probably in that priority order (although that's debatable and may be > different for SUBMIT). That means SMTP response text may have to be > in more than one language and guidance needs to be provided for > language selection. > > I would not consider a document allowing UTF-8 in response text > complete unless dodges this issue (e.g., by only allowing UTF-8 in > addresses) or confronts this issue. I think the text in the draft is a suitable amount of dodgery, but your mileage may vary. We're not addressing the subject of non-English language in response codes at all here; this is an existing problem (error codes in Latin, anyone?), and so is out of scope for the EAI WG. I'd be happy to add text saying "use UTF-8 in addresses only" (my opinion only). One thing I forgot to respond to on Kari's proposed text: > > - Chris > > Kari Hurtta wrote on 6/16/07 9:29 +0300: > >> Harald Tveit Alvestrand writes in gmane.ietf.ima: >> >>> The following tickets are open on the EAI issue tracker: >>> >>> 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no >>> later discussion. >> >> I suggest small change to text. Change here is on diff format. >> Dicussion follows. >> >> --------------------------------------------------------------------------- >> >> --- draft-ietf-eai-smtpext-06.txt 2007-06-05 06:40:53.000000000 +0300 >> +++ draft-ietf-eai-smtpext-06.txt--1483 2007-06-16 >> 09:16:28.000000000 +0300 >> @@ -600,18 +600,26 @@ >> MUST be transmitted in the form of ACE labels. The protocol >> value of >> the WITH clause is UTF8SMTP when this extension is used. More >> information is in the "IANA Considerations" section of this >> document. >> >> 2.7.4. UTF-8 Reply >> >> - If the client issues the "RCPT" command which contains non-ASCII >> + If the client issues the RCPT command which contains non-ASCII >> characters, the SMTP server is permitted to use UTF-8 characters >> within 251 and 551 response codes. Servers MUST NOT include non- >> ASCII characters except in the limited cases specifically permitted >> - in this section. >> + in this section. The SMTP client following this specification MUST >> + accept UTF-8 on replies of the RCPT command on that case. >> >> + If SMTP reply requires UTF-8, but SMTP client does not use >> + RCPT command which contains non-ASCII characters, the response >> + code 250 meaning "OK" or 550 meaning "Requested action not taken: >> + mailbox unavailable" is used. When response codes 250 and 550 is >> + used on place of 251 and 551 response codes, response do not include >> + new mailbox. If enhanced mail system status code [RFC3463] >> + is used, response codes given on below is used. I suggest a shorter version: If the client sends a message without UTF-8 characters in the RCPT TO command, and the server would desire to send back a response with a non-ASCII email address in it, the server will have to choose another response code, for instance replacing a 251 response code with a 250 code, or a 551 response with a 550. I don't think we need to repeat text talking about the enhanced mail system status codes. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 20 14:10:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14dX-0000E0-Av; Wed, 20 Jun 2007 14:10:35 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I14dV-0000Du-E3 for ima-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 14:10:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14dV-0000Dl-4T for ima@ietf.org; Wed, 20 Jun 2007 14:10:33 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14dT-00049e-P7 for ima@ietf.org; Wed, 20 Jun 2007 14:10:33 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1I14dS-0000HN-5h; Wed, 20 Jun 2007 14:10:30 -0400 Date: Wed, 20 Jun 2007 14:10:29 -0400 From: John C Klensin To: Chris Newman Subject: SUBMIT and error replies (was: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply) Message-ID: <5692A9C61267224450611D5C@p3.JCK.COM> In-Reply-To: References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 18 June, 2007 09:49 -0700 Chris Newman wrote: > For SMTP, allowing UTF-8 in error responses opens a can of > worms. > > SMTP error response text needs to be comprehensible by: > * An arbitrary remote system administrator > * The local system administrator > * The end-user > Probably in that priority order (although that's debatable and > may be different for SUBMIT). And, of course, SUBMIT could be tuned differently if needed. Since SUBMIT-i18n is not on the WG's agenda and I think we are obligated to see how this approach works out, I don't want to start a discussion now but it occurs to me that, if general-purpose downgrading turns out to be too constrained to be useful, another option --whether complementary or alternate-- would be to say that most of the responsibility for downgrading, if needed, lies next to the endpoints and that SUBMIT might be extended to permit passing some rather specific instructions between client and submission server. > That means SMTP response text > may have to be in more than one language and guidance needs to > be provided for language selection. I suppose partially because I'm not enamored of SMTP language extensions, I would not like to see part of that idea considered in isolation -- either we look at the whole package (if necessary, assigning it to this WG, although I'd hope not), or we don't start tip-toeing backwards down that path. > I would not consider a document allowing UTF-8 in response > text complete unless dodges this issue (e.g., by only allowing > UTF-8 in addresses) or confronts this issue. >From the above, I guess I vote "dodge". john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 20 15:26:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15oy-0006mX-N6; Wed, 20 Jun 2007 15:26:28 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I15ox-0006mS-CU for ima-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15ox-0006mK-31 for ima@ietf.org; Wed, 20 Jun 2007 15:26:27 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15ou-0002Pb-Qx for ima@ietf.org; Wed, 20 Jun 2007 15:26:27 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I15Yu-0002CG-S9 for ima@ietf.org; Wed, 20 Jun 2007 21:09:52 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jun 2007 21:09:52 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jun 2007 21:09:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 20 Jun 2007 21:52:34 +0300 Lines: 50 Message-ID: <5dvedi8nm5.fsf_-_@Hurtta06k.keh.iki.fi> References: <36142CAC28EC7DAF983693C5@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Kari Hurtta Subject: [EAI] #1485 message/utf-8-future (Re: Name of new mesage/ subtype) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > --On Thursday, 07 June, 2007 14:34 +0100 Charles Lindsey > wrote: > > > On Thu, 07 Jun 2007 10:00:15 +0100, John C Klensin > > wrote: > > > >> There is an hypothesis that we should be using a new content > >> subtype for message/ to identify body parts whose headers may > >> contain UTF-8 material, if only to provide a specific message/ > >> subtype that can be used (by extension of the MIME spec) with > >> a content-transfer-encoding. At least some of us have > >> concluded that modifying MIME to permit a C-T-E on _any_ > >> message/ subtype, or even any message/subtype defined in RFC > >> 2045/2046 is a bad idea, especially in an experimental > >> protocol. > > > > Does "some of us" includes you? It is certainly the main > > reason why I am still arguing for message/rfc822. > > Yes, it includes me. But, having changed my mind at least once > about this, I don't consider my opinion to be particularly > important. And I was trying to present, rather than persuade. And updating RFC 2045 for allowing C-T-E does not really help. On UTF8SMTP environment this is not needed. And outside of UTF8SMTP environment it can not be assumed that this change is known. Therefore that is not compatible. Saying that 8BITMIME -> 7bit downgraders can encode message/ does not work. 8BITMIME -> 7bit downgraders do not know that they are allowed to to encode message/utf-8-future. It does not help that specification of message/utf-8-future updates RFC 2045. 8BITMIME -> 7bit downgraders knows only original RFC 2045 specification where is this famous "EXPRESSLY FORBIDDEN". ( This does not prevent using message/utf-8-future inside of UTF8SMTP environment. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 21 13:04:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Q53-0002Rj-44; Thu, 21 Jun 2007 13:04:25 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I1Q51-0002Re-26 for ima-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 13:04:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Q50-0002RW-Om for ima@ietf.org; Thu, 21 Jun 2007 13:04:22 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Q4z-0007Pn-8y for ima@ietf.org; Thu, 21 Jun 2007 13:04:22 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Jun 2007 18:04:19 +0100 Message-ID: <467AAF3D.9070405@isode.com> Date: Thu, 21 Jun 2007 18:02:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Harald Alvestrand Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> <46790A4B.7050703@alvestrand.no> In-Reply-To: <46790A4B.7050703@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > Chris Newman wrote: > >> For SMTP, allowing UTF-8 in error responses opens a can of worms. >> >> SMTP error response text needs to be comprehensible by: >> * An arbitrary remote system administrator >> * The local system administrator >> * The end-user >> Probably in that priority order (although that's debatable and may be >> different for SUBMIT). That means SMTP response text may have to be >> in more than one language and guidance needs to be provided for >> language selection. >> >> I would not consider a document allowing UTF-8 in response text >> complete unless dodges this issue (e.g., by only allowing UTF-8 in >> addresses) or confronts this issue. > > I think the text in the draft is a suitable amount of dodgery, but > your mileage may vary. > We're not addressing the subject of non-English language in response > codes at all here; this is an existing problem (error codes in Latin, > anyone?), and so is out of scope for the EAI WG. > > I'd be happy to add text saying "use UTF-8 in addresses only" (my > opinion only). +1. > One thing I forgot to respond to on Kari's proposed text: > >> >> - Chris >> >> Kari Hurtta wrote on 6/16/07 9:29 +0300: >> >>> Harald Tveit Alvestrand writes in >>> gmane.ietf.ima: >>> >>>> The following tickets are open on the EAI issue tracker: >>>> >>>> 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no >>>> later discussion. >>> >>> >>> I suggest small change to text. Change here is on diff format. >>> Dicussion follows. >>> >>> --------------------------------------------------------------------------- >>> >>> --- draft-ietf-eai-smtpext-06.txt 2007-06-05 06:40:53.000000000 >>> +0300 >>> +++ draft-ietf-eai-smtpext-06.txt--1483 2007-06-16 >>> 09:16:28.000000000 +0300 >>> @@ -600,18 +600,26 @@ >>> MUST be transmitted in the form of ACE labels. The protocol >>> value of >>> the WITH clause is UTF8SMTP when this extension is used. More >>> information is in the "IANA Considerations" section of this >>> document. >>> >>> 2.7.4. UTF-8 Reply >>> >>> - If the client issues the "RCPT" command which contains non-ASCII >>> + If the client issues the RCPT command which contains non-ASCII >>> characters, the SMTP server is permitted to use UTF-8 characters >>> within 251 and 551 response codes. Servers MUST NOT include non- >>> ASCII characters except in the limited cases specifically permitted >>> - in this section. >>> + in this section. The SMTP client following this specification MUST >>> + accept UTF-8 on replies of the RCPT command on that case. >>> >>> + If SMTP reply requires UTF-8, but SMTP client does not use >>> + RCPT command which contains non-ASCII characters, the response >>> + code 250 meaning "OK" or 550 meaning "Requested action not taken: >>> + mailbox unavailable" is used. When response codes 250 and 550 is >>> + used on place of 251 and 551 response codes, response do not >>> include >>> + new mailbox. If enhanced mail system status code [RFC3463] >>> + is used, response codes given on below is used. >> > I suggest a shorter version: > > If the client sends a message without UTF-8 characters in the RCPT > TO command, > and the server would desire to send back a response with a non-ASCII > email > address in it, the server will have to choose another response code, > for instance > replacing a 251 response code with a 250 code, or a 551 response > with a 550. > > > I don't think we need to repeat text talking about the enhanced mail > system status codes. I agree and I like your text. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 22 02:20:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cVN-0004BR-5Z; Fri, 22 Jun 2007 02:20:25 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I1cVM-0004A9-0Q for ima-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 02:20:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cVL-00048S-GU for ima@ietf.org; Fri, 22 Jun 2007 02:20:23 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1cR7-0002nN-JE for ima@ietf.org; Fri, 22 Jun 2007 02:16:03 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C98022596D9 for ; Fri, 22 Jun 2007 08:16:00 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17691-09 for ; Fri, 22 Jun 2007 08:15:49 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B1032596E2 for ; Fri, 22 Jun 2007 08:15:49 +0200 (CEST) Message-ID: <467B6915.2060000@alvestrand.no> Date: Fri, 22 Jun 2007 08:15:49 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [EAI] POLL: on the "what MIME type" question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 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.... 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.... 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.... 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.... _______________________________________________ EAI-DT mailing list EAI-DT@alvestrand.no http://www.alvestrand.no/mailman/listinfo/eai-dt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 22 15:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ogJ-0006GN-8x; Fri, 22 Jun 2007 15:20:31 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I1ogH-0006Fl-Ue for ima-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 15:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ogH-0006Dg-KM for ima@ietf.org; Fri, 22 Jun 2007 15:20:29 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ogF-0003Ea-LQ for ima@ietf.org; Fri, 22 Jun 2007 15:20:29 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5MJKRkv010510 for ; Fri, 22 Jun 2007 19:20:27 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK100201XP93I00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 22 Jun 2007 13:20:27 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK100HEBXPXCL90@mail-amer.sun.com>; Fri, 22 Jun 2007 13:20:26 -0600 (MDT) Date: Fri, 22 Jun 2007 12:20:20 -0700 From: Chris Newman Subject: Re: [EAI] POLL: on the "what MIME type" question In-reply-to: <467B6915.2060000@alvestrand.no> To: Harald Alvestrand Message-id: <5F3CE6CC21E01CB6AAAA277D@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <467B6915.2060000@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote on 6/22/07 8:15 +0200: > 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.... B > 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.... A > 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.... Slight preference for A, no objection to B however. > 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.... I consider A, F, L, M, O technically flawed choices because the label is misleading. I aesthetically dislike E, H. Any other choice would be fine although I don't really like any of them. If I had to choose one, I'd choose C with G a close second. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 22 16:26:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1piV-0000BK-Ie; Fri, 22 Jun 2007 16:26:51 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I1piU-0000Ah-Bz for ima-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 16:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1piT-00008r-Tr for ima@ietf.org; Fri, 22 Jun 2007 16:26:49 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1piP-0004iR-Kw for ima@ietf.org; Fri, 22 Jun 2007 16:26:49 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43581) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1I1piM-0002Gy-22 (Exim 4.63) (return-path ); Fri, 22 Jun 2007 21:26:42 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1I1piM-0006Qt-JZ (Exim 4.54) (return-path ); Fri, 22 Jun 2007 21:26:42 +0100 Date: Fri, 22 Jun 2007 21:26:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Chris Newman Subject: Re: [EAI] POLL: on the "what MIME type" question In-Reply-To: <5F3CE6CC21E01CB6AAAA277D@[10.1.110.5]> Message-ID: References: <467B6915.2060000@alvestrand.no> <5F3CE6CC21E01CB6AAAA277D@[10.1.110.5]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 22 Jun 2007, Chris Newman wrote: > > If I had to choose one, I'd choose [message/international] with > [message/utf8] a close second. I agree with Chris's comments. How about the slightly punning message/utf822? Tony. -- f.a.n.finch http://dotat.at/ MALIN HEBRIDES: NORTHERLY 4 OR 5, OCCASIONALLY 6. SLIGHT OR MODERATE. SHOWERS, FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 22 18:22:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rWZ-00048Z-V7; Fri, 22 Jun 2007 18:22:39 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I1rWZ-000481-65 for ima-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 18:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1rWY-00047t-Sq for ima@ietf.org; Fri, 22 Jun 2007 18:22:38 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1rWX-0002o3-DW for ima@ietf.org; Fri, 22 Jun 2007 18:22:38 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1I1rWW-000DeH-Mb; Fri, 22 Jun 2007 18:22:36 -0400 Date: Fri, 22 Jun 2007 18:22:35 -0400 From: John C Klensin To: Harald Alvestrand , EAI WG Subject: Re: [EAI] POLL: on the "what MIME type" question Message-ID: <013C61671B444436A3640E04@p3.JCK.COM> In-Reply-To: <467B6915.2060000@alvestrand.no> References: <467B6915.2060000@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 22 June, 2007 08:15 +0200 Harald Alvestrand wrote: > 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.... B > 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.... A. Not completely satisfactory, but all other options proposed so far have been worse. > 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.... A. I think that having it as an application/ subtype would violate the principle of least astonishment and that, in the long term, people would wonder why we took leave of our sanity. > 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.... I agree with Chris's "technically flawed" list. I would add G to that list: I believe that is technically flawed -- this is about formats and mail handling, not about a character set, and would introduce confusion with the charset parameter on text/plain. I also believe that G invites mischief. Also like Chris, I find E and H aesthetically unattractive (in part because, while I understood the reasons -- which do not apply here-- I believe that "message/rfc822" was a mistake the first time around). That leaves me with some preference for C or I although I'm not wild about any of these. I could easily live with D or some contraction of "international" that is not on the list (e.g., message/intl). As I think more about it, the more appeal "I" has. If one performs the experiment of pretending to be some years in the future, with this work widely deployed, message/mail would seem fairly natural. It conveys the impression that the internationalized case is the normal one, with message/rfc822 being the restricted case for those poor backward types who haven't caught up yet. That, it seems to me, is exactly what we want. Message/mail also connects with some of my aesthetic objection to many of the other ideas, which stress that this is an extension rather than the [long-term] normal case. On that theory, if message/mail is problematic for some reason, message/email or message/netmail or message/imail (for Internet mail, not "international") would be alternatives in the same spirit. (For those who don't know but still care, as Mike Padlipsky regularly points out, "'netmail' is what we called this stuff when we were inventing it".) john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 22 22:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1uvl-00057Y-V0; Fri, 22 Jun 2007 22:00:53 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I1uvl-00057M-5V for ima-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 22:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1uvk-00057B-Pa for ima@ietf.org; Fri, 22 Jun 2007 22:00:52 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1uvi-0004Ui-Uv for ima@ietf.org; Fri, 22 Jun 2007 22:00:52 -0400 Received: (snipe 3110 invoked by uid 0); 23 Jun 2007 10:54:47 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.635146 secs); Received: from unknown (HELO ?192.168.10.249?) (Z@218.36.241.240) by unknown with SMTP; 23 Jun 2007 10:54:46 +0900 X-SNIPER-SENDERIP: 218.36.241.240 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: harald@alvestrand.no, ima@ietf.org, yangwooko@gmail.com Message-ID: <467C7D3A.5080401@icu.ac.kr> Date: Sat, 23 Jun 2007 10:54:02 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [EAI] POLL: on the "what MIME type" question References: <467B6915.2060000@alvestrand.no> In-Reply-To: <467B6915.2060000@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > > 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.... B > > 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.... A > > 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.... A > > 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.... C > (B or J) > (K,Q) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jun 23 03:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1zoX-0004lg-SM; Sat, 23 Jun 2007 03:13:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I1zoW-0004lT-9N for ima-confirm+ok@megatron.ietf.org; Sat, 23 Jun 2007 03:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1zoS-0004lG-Pb for ima@ietf.org; Sat, 23 Jun 2007 03:13:40 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1zoP-0005L0-VM for ima@ietf.org; Sat, 23 Jun 2007 03:13:40 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l5N7DWSM029282 for ; Sat, 23 Jun 2007 16:13:34 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1597_3fe07968_2159_11dc_8a49_0014221f2a2d; Sat, 23 Jun 2007 16:13:31 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47235) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 23 Jun 2007 16:11:33 +0900 Message-Id: <6.0.0.20.2.20070623114444.04015d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 23 Jun 2007 11:48:04 +0900 To: Harald Alvestrand , EAI WG From: Martin Duerst Subject: Re: [EAI] POLL: on the "what MIME type" question In-Reply-To: <467B6915.2060000@alvestrand.no> References: <467B6915.2060000@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 15:15 07/06/22, Harald Alvestrand wrote: >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.... I guess B, although I haven't studied this in full detail. >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.... A, with same caveat as above. >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.... A; B might also be acceptable. >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.... Okay, with most preferred first: K, Q, I, J, N, O, P, A, H, M, R Bad ideas: B, C, D, E, F, G, L Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 24 15:24:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XhU-0005QD-P6; Sun, 24 Jun 2007 15:24:44 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I2XhT-0005Q8-Mg for ima-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 15:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XhT-0005Pz-DB for ima@ietf.org; Sun, 24 Jun 2007 15:24:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2XhO-0000wq-Q6 for ima@ietf.org; Sun, 24 Jun 2007 15:24:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I2Xh7-0000oB-Gv for ima@ietf.org; Sun, 24 Jun 2007 21:24:21 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jun 2007 21:24:21 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jun 2007 21:24:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 24 Jun 2007 22:23:59 +0300 Lines: 105 Message-ID: <5d1wg16trk.fsf@Hurtta06k.keh.iki.fi> References: <467B6915.2060000@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Kari Hurtta Subject: [EAI] Re: POLL: on the "what MIME type" question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand 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@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/eai-dt / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 25 05:38:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2l1l-0004AQ-Rn; Mon, 25 Jun 2007 05:38:33 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I2l1l-0004AL-Dk for ima-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 05:38:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2l1h-0004AB-Mf for ima@ietf.org; Mon, 25 Jun 2007 05:38:29 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2l1f-0000iT-Ro for ima@ietf.org; Mon, 25 Jun 2007 05:38:29 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l5P9cLwG029290 for ; Mon, 25 Jun 2007 18:38:26 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007062518382121118 for ; Mon, 25 Jun 2007 18:38:21 +0900 Date: Mon, 25 Jun 2007 18:38:21 +0900 (JST) Message-Id: <20070625.183821.39184945.fujiwara@jprs.co.jp> To: ima@ietf.org Subject: Re: [EAI] POLL: on the "what MIME type" question From: fujiwara@jprs.co.jp In-Reply-To: <467B6915.2060000@alvestrand.no> References: <467B6915.2060000@alvestrand.no> X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: Harald Alvestrand > 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.... B > 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.... A > 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.... A > 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.... I prefer A or K. common nouns or words which have another meaning are not suitable for identifiers, I think. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 25 06:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2m1K-0003JH-3c; Mon, 25 Jun 2007 06:42:10 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I2m1I-0003JC-Sm for ima-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 06:42:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2m1I-0003J4-JL for ima@ietf.org; Mon, 25 Jun 2007 06:42:08 -0400 Received: from [159.226.7.151] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2m1B-0003lC-Pm for ima@ietf.org; Mon, 25 Jun 2007 06:42:08 -0400 Received: (eyou send program); Mon, 25 Jun 2007 18:41:53 +0800 Message-ID: <382768113.12442@cnnic.cn> Received: from 159.226.7.246 by mail.cnnic.cn with HTTP; Mon, 25 Jun 2007 18:41:53 +0800 X-WebMAIL-MUA: [159.226.7.246] From: "MAO Wei" To: harald@alvestrand.no, ima@ietf.org Date: Mon, 25 Jun 2007 18:41:53 +0800 X-Priority: 3 Subject: Re:[EAI] POLL: on the "what MIME type" question Content-Type: text/plain X-Spam-Score: 1.2 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: MAO Wei List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >From: Harald Alvestrand >Reply-To: >To: EAI WG >Subject: [EAI] POLL: on the "what MIME type" question >Date:Fri, 22 Jun 2007 08:15:49 +0200 > >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.... B > > 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.... A > > 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.... A > > 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.... C, D or R > > > _______________________________________________ > EAI-DT mailing list > EAI-DT@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/eai-dt > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 25 10:46:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ppU-0000A9-8g; Mon, 25 Jun 2007 10:46:12 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I2ppT-00008J-4Q for ima-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 10:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ppS-000087-Qc for ima@ietf.org; Mon, 25 Jun 2007 10:46:10 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2ppH-0000T5-MF for ima@ietf.org; Mon, 25 Jun 2007 10:46:10 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3#clerew#man*ac&uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 467fd526.fd60.c7 for ima@ietf.org; Mon, 25 Jun 2007 15:45:58 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5PEjuAX006260 for ; Mon, 25 Jun 2007 15:45:57 +0100 (BST) Date: Mon, 25 Jun 2007 15:45:55 +0100 To: IMA Subject: Re: [EAI] POLL: on the "what MIME type" question References: <467B6915.2060000@alvestrand.no> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <467B6915.2060000@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 22 Jun 2007 07:15:49 +0100, Harald Alvestrand wrote: > 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. I must protest most strongly that we are being asked to choose netween two alternatives of which one has currently no clearly agreed technical description, making it impossible to make an informed choice between them. > 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.... A. The only argument presented against A is that such messages might leak into the existing environment without being properly downgraded first. Leaks happen because standards have been accidentally violated, usually by unusual hand-written scripts which have not been implemented with the care expected when writing agents intended for widespread use. The question that arises is whether introducing a message/utf8smtp will reduce the number of such 'accidents', bearing in mind that current agents and the expectations of script writers are unlikely to be aware of the new message type. For sure, the number of leaks will indeed be reduced, but will the proportion of leaks reduced be significant in comparison with the number that remain? Sufficiently so to justify the introduction of the new type? > > 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. It depends on how well such messages will be propagated intact within the present network. This is no problem if the answer to Q3 is 'B', but otherwise it appears to be the case that NO current MTA will downgrade them from 8bit to Q-P or to Base64 (I have repeatedly asked for a SINGLE example of a current MTA that would do so, but none has been forthcoming, whereas several current MTAs with significant current usage that will not do so have been reported - notably sendmail). If it were already the case that many/most MTAs already handled this case, then the implied violation of that EXPRESSLY FORBIDDEN in RFC 2045 could perhaps be overlooked; but apparently that is NOT the case. Therefore, the only possible answer to this question is 'A' if the answer to Q1 is 'A', and 'B' if it is not. Alternatively we could state explicitly that this new message type was not expected to propagate through non-8BITMIME environments (as seems to be suggested in the latest DSN draft); but that is outwith the scope of the question as asked. > > 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. 'A' if the answer to Q2 is 'B', otherwise 'B'. But 'B' is ugly and counter-intuitive. And indeed the ugliness of 'B' is the best argument for not anwering 'A' to Q2. > > 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.... Presumably if Q1 is anwered with 'A', then this Q4 is redundant. Otherwise, it needs to include the word 'mail' plus either 'utf-8' or 'international' (or variations on them such as 'email' - even 'smtp' - and 'i18n'). So that restricts the choice to one of A, J, O, R, of which I prefer O (except that has been pre-empted by the new DSN draft - but that is fixable, and should have been a text type anyway). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 25 20:05:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yYn-0003Tt-0d; Mon, 25 Jun 2007 20:05:33 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I2yYl-0003To-VF for ima-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 20:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yYl-0003Tg-Lk for ima@ietf.org; Mon, 25 Jun 2007 20:05:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2yYl-0005v3-Ax for ima@ietf.org; Mon, 25 Jun 2007 20:05:31 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5Q05QCG002590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2007 17:05:26 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-53.qualcomm.com [10.50.16.53]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5Q05O5R017908; Mon, 25 Jun 2007 17:05:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <467B6915.2060000@alvestrand.no> References: <467B6915.2060000@alvestrand.no> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 25 Jun 2007 17:00:00 -0700 To: Harald Alvestrand , EAI WG From: Randall Gellens Subject: Re: [EAI] POLL: on the "what MIME type" question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 8:15 AM +0200 6/22/07, Harald Alvestrand wrote: > 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.... B > 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.... A (we can make an exception to permit encoding for this one subtype) > 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.... A (anything else will be bizarre and unfortunate) > 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.... Best of these is "I: Message/mail". Also acceptable would be versions of "mail" as proposed by John. I agree that we do not want to pick choices which contain "smtp" or "822" or "utf8". Acceptable would be "D: Message/global" or "C: Message/international" although they seem awkward. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- You may be only one person in the world, but you may also be the world to one person. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 25 20:19:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ymF-0007EE-UL; Mon, 25 Jun 2007 20:19:27 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I2ymF-0007E5-0J for ima-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 20:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ymE-0007Co-Li for ima@ietf.org; Mon, 25 Jun 2007 20:19:26 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2ymD-0001Gv-4Y for ima@ietf.org; Mon, 25 Jun 2007 20:19:26 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5Q0JNnM004360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2007 17:19:23 -0700 Received: from [[192.168.1.13]] (vpn-10-50-16-53.qualcomm.com [10.50.16.53]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5Q0JK0J022600; Mon, 25 Jun 2007 17:19:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <5dhcplog2n.fsf@Hurtta06k.keh.iki.fi> References: <1E21CB021D6CAF47A71D301B@[192.168.1.110]> <5dhcplog2n.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 25 Jun 2007 17:13:45 -0700 To: Kari Hurtta , ima@ietf.org From: Randall Gellens Subject: [EAI] Re: ISSUE: Trivial downgrading Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 7:35 AM +0300 6/6/07, Kari Hurtta wrote: > ( And it is likely that mail server is changed according on what > network you are connected. So MSA can suddenly come to UTF8SMTP aware :-) > Port 25 is closed by order of Finnish Communications Regulatory Authority > (FICORA) on consumer subscription line. (That order of course do not > prevent sending mail via home server with port 587 or 465 (non > standard)). ) This is a bit off-topic, but why would the MSA change depending on the connection network? Generally, the idea of submission as a separate service is that one always submits using one's home MSA, regardless of how one is connected to the Internet. So, if my home MSA is the one run by my usual ISP, but I happen to be travelling and using an 802.11 connection in a coffee shop, I still submit through my usual ISP's MSA. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Wealth is not only money. Wealth can be happiness in your sweetheart or your honey. --(Fortune cookie) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 26 03:39:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35e1-0001BS-Ko; Tue, 26 Jun 2007 03:39:25 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I35dz-0001BK-Ou for ima-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 03:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35dz-0001BC-BX for ima@ietf.org; Tue, 26 Jun 2007 03:39:23 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I35du-0002tl-67 for ima@ietf.org; Tue, 26 Jun 2007 03:39:23 -0400 Received: (eyou send program); Tue, 26 Jun 2007 15:39:13 +0800 Message-ID: <382843553.19715@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Tue, 26 Jun 2007 15:39:13 +0800 Message-ID: <065301c7b7c5$12e64670$236ff1da@yaojk> From: "YAO Jiankang" To: "Chris Newman" References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]><5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> <382323308.21509@cnnic.cn> Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply Date: Tue, 26 Jun 2007 15:39:05 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 1.0 (+) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: hurtta@siilo.fmi.fi, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2109245283==" Errors-To: ima-bounces@ietf.org --===============2109245283== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIE5ld21hbiIgPENo cmlzLk5ld21hbkBTdW4uQ09NPg0KVG86ICJLYXJpIEh1cnR0YSIgPGh1cnR0YStnbWFuZUBzaWls by5mbWkuZmk+OyA8aW1hQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgSnVuZSAxOSwgMjAwNyAx Mjo0OSBBTQ0KU3ViamVjdDogUmU6IFtFQUldICMxNDgzIGRyYWZ0LWlldGYtZWFpLXNtdHBleHQt MDYudHh0IDIuNy40LiBVVEYtOCBSZXBseQ0KDQoNCj5Gb3IgU01UUCwgYWxsb3dpbmcgVVRGLTgg aW4gZXJyb3IgcmVzcG9uc2VzIG9wZW5zIGEgY2FuIG9mIHdvcm1zLg0KDQo+U01UUCBlcnJvciBy ZXNwb25zZSB0ZXh0IG5lZWRzIHRvIGJlIGNvbXByZWhlbnNpYmxlIGJ5Og0KPiogQW4gYXJiaXRy YXJ5IHJlbW90ZSBzeXN0ZW0gYWRtaW5pc3RyYXRvcg0KPiogVGhlIGxvY2FsIHN5c3RlbSBhZG1p bmlzdHJhdG9yDQo+KiBUaGUgZW5kLXVzZXINCj5Qcm9iYWJseSBpbiB0aGF0IHByaW9yaXR5IG9y ZGVyIChhbHRob3VnaCB0aGF0J3MgZGViYXRhYmxlIGFuZCBtYXkgYmUgZGlmZmVyZW50IA0KPmZv ciBTVUJNSVQpLiAgVGhhdCBtZWFucyBTTVRQIHJlc3BvbnNlIHRleHQgbWF5IGhhdmUgdG8gYmUg aW4gbW9yZSB0aGFuIG9uZSANCj5sYW5ndWFnZSBhbmQgZ3VpZGFuY2UgbmVlZHMgdG8gYmUgcHJv dmlkZWQgZm9yIGxhbmd1YWdlIHNlbGVjdGlvbi4NCg0KPkkgd291bGQgbm90IGNvbnNpZGVyIGEg ZG9jdW1lbnQgYWxsb3dpbmcgVVRGLTggaW4gcmVzcG9uc2UgdGV4dCBjb21wbGV0ZSB1bmxlc3Mg DQo+ZG9kZ2VzIHRoaXMgaXNzdWUgKGUuZy4sIGJ5IG9ubHkgYWxsb3dpbmcgVVRGLTggaW4gYWRk cmVzc2VzKSBvciBjb25mcm9udHMgdGhpcyANCj5pc3N1ZS4NCg0KRGVhciBDaHJpcywNCg0KV2Ug d291bGQgbGlrZSB0byBhZGQgb25lIHNlbnRlbmNlIGluIHRoaXMgc2VjdGlvbjogDQoiVVRGLTgg aXMgbmVlZGVkIHRvIHJlcHJlc2VudCBlbWFpbCBhZGRyZXNzZXMgaW4gcmVzcG9uc2VzLiBUaGlz IGV4dGVuc2lvbiBkb2VzDQpub3QgYXV0aG9yaXplIHRoZSB1c2Ugb2YgVVRGLTggZm9yIGFueSBv dGhlciBwdXJwb3NlIi4NCg0KaXMgaXQgb2sgZm9yIHlvdT8NCg0KDQpZQU8gSmlhbmthbmcNCkNO TklDDQoNCg0KDQoNCg0KPiAgICAgICAgICAgICAgICAtIENocmlzDQoNCkthcmkgSHVydHRhIHdy b3RlIG9uIDYvMTYvMDcgOToyOSArMDMwMDoNCg0KPiBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCA8 aGFyYWxkQGFsdmVzdHJhbmQubm8+IHdyaXRlcyBpbiBnbWFuZS5pZXRmaW1hOg0KPg0KPj4gVGhl IGZvbGxvd2luZyB0aWNrZXRzIGFyZSBvcGVuIG9uIHRoZSBFQUkgaXNzdWUgdHJhY2tlcjoNCj4+ DQo+PiAxNDgzIFNNVFBFWFQgMi43OiBOb24tQVNDSUkgaW4gcmVzcG9uc2UgdGV4dHMgVGV4dCBw cm9wb3NlZCBpbiAtMDYsIG5vDQo+PiBsYXRlciBkaXNjdXNzaW9uLg0KPg0KPiBJIHN1Z2dlc3Qg c21hbGwgY2hhbmdlIHRvIHRleHQuIENoYW5nZSBoZXJlIGlzIG9uIGRpZmYgZm9ybWF0Lg0KPiBE aWN1c3Npb24gZm9sbG93cy4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLSBkcmFmdC1p ZXRmLWVhaS1zbXRwZXh0LTA2LnR4dCAyMDA3LTA2LTA1IDA2OjQwOjUzLjAwMDAwMDAwMCArMDMw MA0KPiArKysgZHJhZnQtaWV0Zi1lYWktc210cGV4dC0wNi50eHQtLTE0ODMgMjAwNy0wNi0xNiAw OToxNjoyOC4wMDAwMDAwMDAgKzAzMDANCj4gQEAgLTYwMCwxOCArNjAwLDI2IEBADQo+ICAgICBN VVNUIGJlIHRyYW5zbWl0dGVkIGluIHRoZSBmb3JtIG9mIEFDRSBsYWJlbHMuICBUaGUgcHJvdG9j b2wgdmFsdWUgb2YNCj4gICAgIHRoZSBXSVRIIGNsYXVzZSBpcyBVVEY4U01UUCB3aGVuIHRoaXMg ZXh0ZW5zaW9uIGlzIHVzZWQuICBNb3JlDQo+ICAgICBpbmZvcm1hdGlvbiBpcyBpbiB0aGUgIklB TkEgQ29uc2lkZXJhdGlvbnMiIHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudC4NCj4NCj4gIDIuNy40 LiAgVVRGLTggUmVwbHkNCj4NCj4gLSAgIElmIHRoZSBjbGllbnQgaXNzdWVzIHRoZSAiUkNQVCIg Y29tbWFuZCB3aGljaCBjb250YWlucyBub24tQVNDSUkNCj4gKyAgIElmIHRoZSBjbGllbnQgaXNz dWVzIHRoZSBSQ1BUIGNvbW1hbmQgd2hpY2ggY29udGFpbnMgbm9uLUFTQ0lJDQo+ICAgICBjaGFy YWN0ZXJzLCB0aGUgU01UUCBzZXJ2ZXIgaXMgcGVybWl0dGVkIHRvIHVzZSBVVEYtOCBjaGFyYWN0 ZXJzDQo+ICAgICB3aXRoaW4gMjUxIGFuZCA1NTEgcmVzcG9uc2UgY29kZXMuICBTZXJ2ZXJzIE1V U1QgTk9UIGluY2x1ZGUgbm9uLQ0KPiAgICAgQVNDSUkgY2hhcmFjdGVycyBleGNlcHQgaW4gdGhl IGxpbWl0ZWQgY2FzZXMgc3BlY2lmaWNhbGx5IHBlcm1pdHRlZA0KPiAtICAgaW4gdGhpcyBzZWN0 aW9uLg0KPiArICAgaW4gdGhpcyBzZWN0aW9uLiBUaGUgU01UUCBjbGllbnQgZm9sbG93aW5nIHRo aXMgc3BlY2lmaWNhdGlvbiBNVVNUDQo+ICsgICBhY2NlcHQgVVRGLTggb24gcmVwbGllcyBvZiB0 aGUgUkNQVCBjb21tYW5kIG9uIHRoYXQgY2FzZS4NCj4NCj4gKyAgIElmIFNNVFAgcmVwbHkgcmVx dWlyZXMgVVRGLTgsIGJ1dCBTTVRQIGNsaWVudCBkb2VzIG5vdCB1c2UNCj4gKyAgIFJDUFQgY29t bWFuZCB3aGljaCBjb250YWlucyBub24tQVNDSUkgY2hhcmFjdGVycywgdGhlIHJlc3BvbnNlDQo+ ICsgICBjb2RlIDI1MCBtZWFuaW5nICJPSyIgIG9yIDU1MCBtZWFuaW5nICJSZXF1ZXN0ZWQgYWN0 aW9uIG5vdCB0YWtlbjoNCj4gKyAgIG1haWxib3ggdW5hdmFpbGFibGUiIGlzIHVzZWQuICBXaGVu IHJlc3BvbnNlIGNvZGVzIDI1MCBhbmQgNTUwIGlzDQo+ICsgICB1c2VkIG9uIHBsYWNlIG9mIDI1 MSBhbmQgNTUxIHJlc3BvbnNlIGNvZGVzLCByZXNwb25zZSBkbyBub3QgaW5jbHVkZQ0KPiArICAg bmV3IG1haWxib3guIElmIGVuaGFuY2VkIG1haWwgc3lzdGVtIHN0YXR1cyBjb2RlIFtSRkMzNDYz XQ0KPiArICAgaXMgdXNlZCwgIHJlc3BvbnNlIGNvZGVzIGdpdmVuIG9uIGJlbG93IGlzIHVzZWQu DQo+DQo+DQo+ICBZYW8gJiBNYW8gICAgICAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDgsIDIw MDcgICAgICAgICAgICAgICBbUGFnZSAxMV0NCj4gIA0KPiAgSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgICBFQUkgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQo+DQo+ IEBAIC02MjcsMjggKzYzNSwyNiBAQA0KPiAgICAgaXMgaW5jbHVkZWQgaW4gaXQgYW5kIHRoZXJl Zm9yZSBVVEYtOCBpcyBub3QgbmVlZGVkLiAgVVRGOFJFUExZDQo+ICAgICBwYXJhbWV0ZXIgb24g dGhlIFZSRlkgYW5kIEVYUE4gY29tbWFuZHMgdGVsbHMgdGhlIFNNVFAgc2VydmVyIHRoYXQNCj4g ICAgIHRoZSBjbGllbnQgaXMgcHJlcGFyZWQgZm9yIFVURi04IG9uIFNNVFAgcmVwbGllcy4NCj4N Cj4gICAgIFZFUklGWSAoVlJGWSkgYW5kIEVYUEFORCAoRVhQTiljb21tYW5kIHN5bnRheGVzIGFy ZSBjaGFuZ2VkIHRvOg0KPg0KPiAtICAgICAgICJWUkZZIiBTUCB1QXRvbSBbU1AgIlVURjhSRVBM WSJdIENSTEY7DQo+IC0gICAgICAgICAgICAgIDt1QXRvbSBpcyBkZWZpbmVkIGluIHNlY3Rpb24g Mi4zIG9mIHRoaXMgZG9jdW1lbnQNCj4gKyAgICAgICAiVlJGWSIgU1AgKHVMb2NhbC1wYXJ0IC8g dU1haWxib3gpIFtTUCAiVVRGOFJFUExZIl0gQ1JMRjsNCj4gKyAgICAgICAgICAgICAgO3VMb2Nh bC1wYXJ0IGFuZCB1TWFpbGJveCBpcyBkZWZpbmVkIGluIHNlY3Rpb24gMi4zIG9mIHRoaXMNCj4g ZG9jdW1lbnQNCj4gLSAgICAgICAiRVhQTiIgU1AgdUF0b20gW1NQICJVVEY4UkVQTFkiXSBDUkxG Ow0KPiAtICAgICAgICAgICAgICA7dUF0b20gaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDIuMyBvZiB0 aGlzIGRvY3VtZW50DQo+ICsgICAgICAgIkVYUE4iIFNQICh1TG9jYWwtcGFydCAvIHVNYWlsYm94 KSBbU1AgIlVURjhSRVBMWSJdIENSTEY7DQo+ICsgICAgICAgICAgICAgIDt1TG9jYWwtcGFydCBh bmQgdU1haWxib3ggaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDIuMyBvZiB0aGlzDQo+IGRvY3VtZW50 DQo+ICAgICBUaGlzIHBhcmFtZXRlciAiVVRGOFJFUExZIiBkb2VzIG5vdCBoYXZlIHZhbHVlLiAg SWYgU01UUCByZXBseQ0KPiAgICAgcmVxdWlyZXMgVVRGLTgsIGJ1dCBTTVRQIGNsaWVudCBkb2Vz IG5vdCB1c2UgIlVURjhSRVBMWSIgcGFyYW1ldGVyIGluDQo+IC0gICB0aGUgVkVSSUZZIChWUkZZ KSBhbmQgRVhQQU5EIChFWFBOKSBjb21tYW5kcywgdGhlIHJlc3BvbnNlIGNvZGUgIjI1MiINCj4g KyAgIHRoZSBWRVJJRlkgKFZSRlkpIGFuZCBFWFBBTkQgKEVYUE4pIGNvbW1hbmRzLCB0aGUgcmVz cG9uc2UgY29kZSAyNTINCj4gICAgIGlzIHVzZWQsIGRlZmluZWQgaW4gW1JGQzI4MjFdLCBtZWFu aW5nICJDYW5ub3QgVlJGWSB1c2VyLCBidXQgd2lsbA0KPiAtICAgYWNjZXB0IHRoZSBtZXNzYWdl IGFuZCBhdHRlbXB0IHRoZSBkZWxpdmVyeSIuICBJZiBlbmhhbmNlZCBtYWlsDQo+IC0gICBzeXN0 ZW0gc3RhdHVzIGNvZGUgW1JGQzM0NjNdIGlzIHVzZWQsIHRoZSByZXNwb25zZSBjb2RlIHNob3Vs ZCBiZQ0KPiAtICAgIjUuNi55IiBvciAiMi42LnkiIFtTTVRQLWNvZGVzXSwgbWVhbmluZyB0aGF0 ICJUaGUgVVRGLTggcmVwbHkNCj4gLSAgIHJlcXVpcmVkLCBidXQgdGhlIFVURjhSRVBMWSBwYXJh bWV0ZXIgbm90IHVzZWQuIi4gW1thbmNob3IxMzogUkVNT1ZFDQo+IC0gICBUSElTOiBJQU5BIHBs ZWFzZSBhc3NpZ24gdGhlIHByb3BlciBlcnJvciBjb2RlcyBmb3IgIjUuNi55IiBhbmQNCj4gLSAg ICIyLjYueSIuXV0gICJVVEY4UkVQTFkiIG9uIHRoZSBWRVJJRlkgKFZSRlkpIG9yIEVYUEFORCAo RVhQTikNCj4gKyAgIGFjY2VwdCB0aGUgbWVzc2FnZSBhbmQgYXR0ZW1wdCB0aGUgZGVsaXZlcnki LiBBbHNvIHJlc3BvbnNlIGNvZGUgNTUwDQo+ICsgICBtYXkgYmUgdXNlZCwgbWVhbmluZyAiUmVx dWVzdGVkIGFjdGlvbiBub3QgdGFrZW46IG1haWxib3ggdW5hdmFpbGFibGUiLg0KPiArICAgSWYg ZW5oYW5jZWQgbWFpbCBzeXN0ZW0gc3RhdHVzIGNvZGUgW1JGQzM0NjNdIGlzIHVzZWQsIHJlc3Bv bnNlIGNvZGVzDQo+ICsgICBnaXZlbiBvbiBiZWxvdyBpcyB1c2VkLiAiVVRGOFJFUExZIiBvbiB0 aGUgVkVSSUZZIChWUkZZKSBvciBFWFBBTkQgKEVYUE4pDQo+ICAgICBjb21tYW5kcyBlbmFibGVz IFVURi04IGZvciB0aGF0IGNvbW1hbmQgb25seS4NCj4NCj4gICAgIFRoZSB1QXRvbSBvZiB0aGUg VlJGWSBhbmQgRVhQTiBjb21tYW5kcyBpcyBhIHVzZXIgbmFtZSBvciBhIHVzZXIgbmFtZQ0KPiAg ICAgYW5kIGEgZG9tYWluIChzZWUgYmVsb3cpLiAgSWYgYSBub3JtYWwgKGkuZS4sIDI1MCkgcmVz cG9uc2UgaXMNCj4gICAgIHJldHVybmVkLCB0aGUgcmVzcG9uc2UgTUFZIGluY2x1ZGUgdGhlIGZ1 bGwgbmFtZSBvZiB0aGUgdXNlciBhbmQgTVVTVA0KPiAgICAgaW5jbHVkZSB0aGUgbWFpbGJveCBv ZiB0aGUgdXNlci4gIEl0IE1VU1QgYmUgaW4gZWl0aGVyIG9mIHRoZQ0KPiBAQCAtNjU4LDEyICs2 NjQsMjAgQEANCj4gICAgICAgICAgICAgICAgICA7IHVNYWlsYm94IGlzIGRlZmluZWQgaW4gc2Vj dGlvbiAyLjMgb2YgdGhpcyBkb2N1bWVudA0KPiAgICAgICAgICAgICAgICAgIDsgVXNlciBOYW1l IGFsbG93cyB0aGUgbm9uLUFTQ0lJIGNoYXJhY3Rlci4NCj4NCj4gICAgICAgICAgIHVNYWlsYm94 DQo+ICAgICAgICAgICAgICAgICAgOyB1TWFpbGJveCBpcyBkZWZpbmVkIGluIHNlY3Rpb24gMi4z IG9mIHRoaXMgZG9jdW1lbnQNCj4NCj4gKw0KPiArICAgSWYgU01UUCByZXBseSByZXF1aXJlcyBV VEYtOCwgYnV0IFVURi04IGlzIG5vdCBhbGxvd2VkIG9uIHJlcGx5LA0KPiArICAgYW5kIGVuaGFu Y2VkIG1haWwgc3lzdGVtIHN0YXR1cyBjb2RlIFtSRkMzNDYzXSBpcyB1c2VkLA0KPiArICAgdGhl IHJlc3BvbnNlIGNvZGUgc2hvdWxkIGJlICAiNS42LnkiIG9yICIyLjYueSIgW1NNVFAtY29kZXNd LA0KPiArICAgbWVhbmluZyB0aGF0ICJUaGUgVVRGLTggcmVwbHkgcmVxdWlyZWQsIGJ1dCBub3Qg YWxsb3dlZC4iLg0KPiArICAgW1thbmNob3IxMzogUkVNT1ZFIFRISVM6IElBTkEgcGxlYXNlIGFz c2lnbiB0aGUgcHJvcGVyIGVycm9yIGNvZGVzDQo+ICsgICBmb3IgIjUuNi55IiBhbmQgIjIuNi55 Ii5dXQ0KPiArDQo+ICAgICBJZiB0aGUgU01UUCBDbGllbnQgbGFjayBvZiB0aGUgVVRGOFNNVFAg c3VwcG9ydCByZWNlaXZlcyB0aGUgVVRGLTgNCj4gICAgIG1lc3NhZ2Ugb24gcmVwbHksIGl0IG1h eSBjcmFzaC4gIFVURi04IG1lc3NhZ2VzIG9uIHJlcGx5IGFyZSBvbmx5DQo+ICAgICBhbGxvd2Vk IGluIHRoZSBjb21tYW5kcyB1bmRlciB0aGUgc2l0dWF0aW9ucyBkZXNjcmliZWQgYWJvdmUuICBV bmRlcg0KPg0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gRGlzY3Vzc2lvbjoN Cj4NCj4gMSkNCj4NCj4gU01UUCBjbGllbnQgbmVlZGVkIHRvIGJlIHJlcXVpcmVkIHRvIGFjY2Vw dCBVVEYtOCBhbHNvIG9uIFJDUFQgcmVzcG9uc2UuDQo+DQo+IDIpDQo+DQo+IDI1MSAgcmVzcG9u c2Ugd2l0aCBVVEYtOCBtYWlsYm94IGNhbiBiZSByZXBsYWNlZCB3aXRoIDI1MCByZXNwb25zZS4N Cj4gMjUwIHJlc3BvbnNlIGRvZXMgbm90IGluY2x1ZGUgbmV3IGFkZHJlc3MuDQo+DQo+IEluc3Rl YWQgb2YNCj4NCj4gICAgICAgICBSQ1BUIFRPOjxzdXBwb3J0QGV4YW1wbGUuY29tPg0KPiAgICAg ICAgIDI1MSAyLjEuNSBOZXcgYWRkcmVzcyBpcyA8a+R5dHTkauR0dWtpQEBleGFtcGxlLmNvbT4s IHdpbGwgZm9yd2FyZA0KPg0KPiB1c2UNCj4NCj4gICAgICAgICBSQ1BUIFRPOjxzdXBwb3J0QGV4 YW1wbGUuY29tPg0KPiAgICAgICAgIDI1MCAyLjYueSBBZGRyZXNzIGlzIGNoYW5nZWQsIHdpbGwg Zm9yd2FyZA0KPg0KPg0KPiBPZiBjb3Vyc2UgMjUxIGNhbiBub3QgcmVwbGFjZWQgd2l0aCA1NTAg YmVjYXVzZSB0aGF0IHJlY2lwaWVudCBpcyBhY2NlcHRlZC4NCj4gVGhlcmVmb3JlIDI1MCBpcyBj b3JyZWN0IHJlc3BvbnNlIGNvZGUuDQo+DQo+IDMpDQo+DQo+IC0tLSBzdGFydCBxdW90ZSAtLQ0K PiBUaGlzIHBhcmFtZXRlciAiVVRGOFJFUExZIiBkb2VzIG5vdCBoYXZlIHZhbHVlLiBJZiBTTVRQ IHJlcGx5DQo+IHJlcXVpcmVzIFVURi04LCBidXQgU01UUCBjbGllbnQgZG9lcyBub3QgdXNlICJV VEY4UkVQTFkiIHBhcmFtZXRlciBpbg0KPiB0aGUgVkVSSUZZIChWUkZZKSBhbmQgRVhQQU5EIChF WFBOKSBjb21tYW5kcywgdGhlIHJlc3BvbnNlIGNvZGUgIjI1MiINCj4gaXMgdXNlZCwgZGVmaW5l ZCBpbiBbUkZDMjgyMV0sIG1lYW5pbmcgIkNhbm5vdCBWUkZZIHVzZXIsIGJ1dCB3aWxsDQo+IGFj Y2VwdCB0aGUgbWVzc2FnZSBhbmQgYXR0ZW1wdCB0aGUgZGVsaXZlcnkiLiBJZiBlbmhhbmNlZCBt YWlsDQo+IHN5c3RlbSBzdGF0dXMgY29kZSBbUkZDMzQ2M10gaXMgdXNlZCwgdGhlIHJlc3BvbnNl IGNvZGUgc2hvdWxkIGJlDQo+ICI1LjYueSIgb3IgIjIuNi55IiBbU01UUC1jb2Rlc10sIG1lYW5p bmcgdGhhdCAiVGhlIFVURi04IHJlcGx5DQo+IHJlcXVpcmVkLCBidXQgdGhlIFVURjhSRVBMWSBw YXJhbWV0ZXIgbm90IHVzZWQuIi4NCj4gLS0tIGVuZCBxdW90ZSAtLS0NCj4NCj4gSGVyZSBpcyBw cm9ibGVtIHRoYXQgdGhhdCB0YWxrcyBvbmx5IHJlc3BvbnNlIGNvZGUgIjI1MiIsIGJ1dA0KPiBl bmNoYW5jZWQgcmVzcG9uc2UgY29kZXMgdGFsayBib3RoICI1LjYueSIgYW5kICIyLjYueSIuDQo+ DQo+IFRoZXNlICI1LjYueSIgYW5kICIyLjYueSIgYXJlIGZpbmUgLS0gdGhlc2Ugc2hvdWxkIE5P VCByZW1vdmVkLg0KPg0KPiBQcm9ibGVtIGlzIHRoYXQgdGhlc2UgZW5jaGFuY2VkIHJlc3BvbnNl IGNvZGVzIG5vdyBhcHBseSBvbmx5DQo+IHRvIFZFUklGWSBhbmQgRVhQQU5ELiBNeSBvcmlnaW5h bCB0ZXh0IHRoZXNlIGFwcGx5IGFsc28gdG8NCj4gUkNQVCBjb21tYW5kLg0KPg0KPiBPbiB0aGF0 IGNoYW5nZSBlZmZlY3RpdmVseQ0KPiAgICBgYElmIGVuaGFuY2VkIG1haWwNCj4gICAgICBzeXN0 ZW0gc3RhdHVzIGNvZGUgW1JGQzM0NjNdIGlzIHVzZWQsIHRoZSByZXNwb25zZSBjb2RlIHNob3Vs ZCBiZQ0KPiAgICAgICI1LjYueSIgb3IgIjIuNi55IiBbU01UUC1jb2Rlc10sIG1lYW5pbmcgdGhh dCAiVGhlIFVURi04IHJlcGx5DQo+ICAgICAgcmVxdWlyZWQsIGJ1dCB0aGUgVVRGOFJFUExZIHBh cmFtZXRlciBub3QgdXNlZC4iPz8NCj4gaXMgbW92ZWQganVzdCB0byBuZXcgY2hhcHRlciBzbyB0 aGF0IGl0IGFwcGxpZXMgdG8gUkNQVA0KPiAtY29tbWFuZCBhbHNvLiBtZW5haW5nIHRleHQgaXMg YWxzbyBvZiBjb3Vyc2UgY2hhbmdlLCBiZWNhdXNlDQo+IFJDUFQgY29tbWFuZCBoZXJlIGRpZCBu b3QgdGFrZW4gVVRGOFJFUExZIHBhcmFtYXRlci4NCj4NCj4gNCkNCj4NCj4gTGltaXRpbmcgVlJG WSBhbmQgRVhQTiB0byB1QXRvbSBpcyB2ZXJ5IHJlc3RyaWN0aXZlLg0KPg0KPiBSRkMgMjgyMSBx dW90ZTogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+ICAgICJVc2VyIG5h bWUiIGlzIGEgZnV6enkgdGVybSBhbmQgaGFzIGJlZW4gdXNlZCBkZWxpYmVyYXRlbHkuICBBbg0K PiAgICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgVlJGWSBvciBFWFBOIGNvbW1hbmRzIE1VU1QgaW5j bHVkZSBhdCBsZWFzdA0KPiAgICByZWNvZ25pdGlvbiBvZiBsb2NhbCBtYWlsYm94ZXMgYXMgInVz ZXIgbmFtZXMiLiAgSG93ZXZlciwgc2luY2UNCj4gICAgY3VycmVudCBJbnRlcm5ldCBwcmFjdGlj ZSBvZnRlbiByZXN1bHRzIGluIGEgc2luZ2xlIGhvc3QgaGFuZGxpbmcNCj4gICAgbWFpbCBmb3Ig bXVsdGlwbGUgZG9tYWlucywgaG9zdHMsIGVzcGVjaWFsbHkgaG9zdHMgdGhhdCBwcm92aWRlIHRo aXMNCj4gICAgZnVuY3Rpb25hbGl0eSwgU0hPVUxEIGFjY2VwdCB0aGUgImxvY2FsLXBhcnRAZG9t YWluIiBmb3JtIGFzIGEgInVzZXINCj4gICAgbmFtZSI7IGhvc3RzIE1BWSBhbHNvIGNob29zZSB0 byByZWNvZ25pemUgb3RoZXIgc3RyaW5ncyBhcyAidXNlcg0KPiAgICBuYW1lcyIuDQo+IC0tLS0g ZW5kIFJGQyAyODIxIHF1b3RlIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4N Cj4gdUF0b20gZG8gbm90IGFjY2VwdCAiQGRvbWFpbiIgd2hpY2ggaXMgIlNIT1VMRCIgb24gUkZD IDI4MjEuDQo+DQo+IFdpdGggc3VnZ2VzdGVkIHN5bnRheCBpdCByb3VnaGx5IG1hdGNoZXMgd2l0 aCBSRkMgMjgyMSB0ZXh0Lg0KPg0KPg0KPiBZZXMsIGFjdHVhbCBzeW50YXggb24gUkZDIDI4MjEg aXMgc29tZXdoYXQgY29uZmxpY3Qgd2l0aA0KPiB0aGlzOg0KPg0KPiBSRkMgMjgyMSBxdW90ZTog LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IDQuMS4xLjYgVkVSSUZZIChWUkZZKQ0K Pg0KPiAgICBUaGlzIGNvbW1hbmQgYXNrcyB0aGUgcmVjZWl2ZXIgdG8gY29uZmlybSB0aGF0IHRo ZSBhcmd1bWVudA0KPiAgICBpZGVudGlmaWVzIGEgdXNlciBvciBtYWlsYm94LiAgSWYgaXQgaXMg YSB1c2VyIG5hbWUsIGluZm9ybWF0aW9uIGlzDQo+ICAgIHJldHVybmVkIGFzIHNwZWNpZmllZCBp biBzZWN0aW9uIDMuNS4NCj4NCj4gICAgVGhpcyBjb21tYW5kIGhhcyBubyBlZmZlY3Qgb24gdGhl IHJldmVyc2UtcGF0aCBidWZmZXIsIHRoZSBmb3J3YXJkLQ0KPiAgICBwYXRoIGJ1ZmZlciwgb3Ig dGhlIG1haWwgZGF0YSBidWZmZXIuDQo+DQo+ICAgIFN5bnRheDoNCj4gICAgICAgIlZSRlkiIFNQ IFN0cmluZyBDUkxGDQo+DQo+IDQuMS4xLjcgRVhQQU5EIChFWFBOKQ0KPg0KPiAgICBUaGlzIGNv bW1hbmQgYXNrcyB0aGUgcmVjZWl2ZXIgdG8gY29uZmlybSB0aGF0IHRoZSBhcmd1bWVudA0KPiAg ICBpZGVudGlmaWVzIGEgbWFpbGluZyBsaXN0LCBhbmQgaWYgc28sIHRvIHJldHVybiB0aGUgbWVt YmVyc2hpcCBvZg0KPiAgICB0aGF0IGxpc3QuICBJZiB0aGUgY29tbWFuZCBpcyBzdWNjZXNzZnVs LCBhIHJlcGx5IGlzIHJldHVybmVkDQo+ICAgIGNvbnRhaW5pbmcgaW5mb3JtYXRpb24gYXMgZGVz Y3JpYmVkIGluIHNlY3Rpb24gMy41LiAgVGhpcyByZXBseSB3aWxsDQo+ICAgIGhhdmUgbXVsdGlw bGUgbGluZXMgZXhjZXB0IGluIHRoZSB0cml2aWFsIGNhc2Ugb2YgYSBvbmUtbWVtYmVyIGxpc3Qu DQo+DQo+ICAgIFRoaXMgY29tbWFuZCBoYXMgbm8gZWZmZWN0IG9uIHRoZSByZXZlcnNlLXBhdGgg YnVmZmVyLCB0aGUgZm9yd2FyZC0NCj4gICAgcGF0aCBidWZmZXIsIG9yIHRoZSBtYWlsIGRhdGEg YnVmZmVyIGFuZCBtYXkgYmUgaXNzdWVkIGF0IGFueSB0aW1lLg0KPg0KPiAgICBTeW50YXg6DQo+ ICAgICAgICJFWFBOIiBTUCBTdHJpbmcgQ1JMRg0KPg0KPiAtLS0tIGVuZCBSRkMgMjgyMSBxdW90 ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IFdoZXJlIFN0cmluZyBzZWVt cyB0byBiZQ0KPg0KPiAgICAgICAgICBTdHJpbmcgPSBBdG9tIC8gUXVvdGVkLXN0cmluZw0KPg0K Pg0KPg0KPiAoIEFuZCBhbnl3YXkgdUF0b20gZG8gbm90IGNvdmVyIFF1b3RlZC1zdHJpbmcgd2hp Y2ggaXMgYWxsb3dlZCBvbg0KPiAgIFN0cmluZyApLg0KPg0KPiBTZWVtcyB0aGF0ICBSRkMgMjgy MSBpcyBtZXNzIG9uIGhlcmUgYWxzbyA6LSgNCj4NCj4NCj4gLyBLYXJpIEh1cnR0YQ0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJ TUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pbWENCj4NCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJTUEgbWFpbGluZyBsaXN0DQpJTUFAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0K --===============2109245283== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============2109245283==-- From ima-bounces@ietf.org Tue Jun 26 04:11:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I369J-0000z0-DV; Tue, 26 Jun 2007 04:11:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I369J-0000yr-2C for ima-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 04:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I369I-0000yj-HQ for ima@ietf.org; Tue, 26 Jun 2007 04:11:44 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I368f-00034v-0a for ima@ietf.org; Tue, 26 Jun 2007 04:11:44 -0400 Received: (eyou send program); Tue, 26 Jun 2007 16:11:00 +0800 Message-ID: <382845460.19715@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Tue, 26 Jun 2007 16:11:00 +0800 Message-ID: <06b001c7b7c9$83eec000$236ff1da@yaojk> From: "YAO Jiankang" To: "Harald Alvestrand" , "EAI WG" References: <382493242.00411@cnnic.cn> Subject: Re: [EAI] POLL: on the "what MIME type" question Date: Tue, 26 Jun 2007 16:10:50 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 1.0 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1368322478==" Errors-To: ima-bounces@ietf.org --===============1368322478== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhhcmFsZCBBbHZlc3RyYW5k IiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+DQpUbzogIkVBSSBXRyIgPGltYUBpZXRmLm9yZz4NClNl bnQ6IEZyaWRheSwgSnVuZSAyMiwgMjAwNyAyOjE1IFBNDQpTdWJqZWN0OiBbRUFJXSBQT0xMOiBv biB0aGUgIndoYXQgTUlNRSB0eXBlIiBxdWVzdGlvbg0KDQoNCj4gVGhpcyBpcyBhIHBvbGwgdG8g ZGV0ZXJtaW5lIGlmIHRoZXJlIGlzIGEgV0cgY29uc2Vuc3VzIG9uIHRoZSB2YXJpb3VzIA0KPiBp c3N1ZXMgc3Vycm91bmRpbmcgdGhlIE1JTUUgdHlwZSBmb3IgY2FycnlpbmcgVVRGOFNNVFAgbWVz c2FnZXMuDQo+IA0KPiBUbyByZXBseSB0byB0aGUgcG9sbCwgc2VuZCBhIG1lc3NhZ2UgdG8gdGhl IGxpc3QsIG9yIHRvIGJvdGggV0cgY2hhaXJzLCANCj4gYmVmb3JlIEpVTkUgMjksIDIwMDcsIDEy OjAwIEdNVC4gVGhlIGNoYWlycyB3aWxsIHRhbGx5IHRoZSByZXNwb25zZXMgYW5kIA0KPiByZXBv cnQgdGhlIHJlc3VsdHM7IG5hbWVzIG9mIHJlc3BvbmRlbnRzIHdpbGwgYmUgaW5jbHVkZWQgaW4g dGhlIHRhbGx5Lg0KPiANCj4gVGhpcyBwb2xsIGFza3MgcXVlc3Rpb25zIGFib3V0IHRoZSBjYXJy aWFnZSBvZiBtZXNzYWdlcyB0aGF0IG1ha2UgdXNlIG9mDQo+IHRoZSBleHRlbnNpb25zIGRlc2Ny aWJlZCBpbiBkcmFmdC1pZXRmLWVhaS11dGY4aGRycywgd2hlbiB0aGV5IGFyZSBwYXJ0IA0KPiBv ZiBhbm90aGVyIG1lc3NhZ2UuIEluIHRoZSB0ZXh0IGJlbG93LCB3ZSBjYWxsIHRoZW0gVVRGOFNN VFAgbWVzc2FnZXMsIA0KPiB3aXRob3V0IHByZWp1ZGljZSB0byB3aGF0IHdlIGVuZCB1cCBuYW1p bmcgdGhlbS4NCj4gDQo+IFRoZSBxdWVzdGlvbnMgYmVsb3cgYXJlIG5vdCB1bnJlbGF0ZWQ7IHRo ZSBwb2xsIGlzIGludGVuZGVkIHRvIHNob3cgDQo+IHN0cm9uZyBwcmVmZXJlbmNlcywgaXQgaXMg bm90IGEgcmVwbGFjZW1lbnQgZm9yIGluZm9ybWVkIGRlYmF0ZS4NCj4gDQo+IFFVRVNUSU9OIDE6 IFNob3VsZCB0aGVyZSBiZSBhIG5ldyBNSU1FIHR5cGUgZm9yIFVURjhTTVRQIG1lc3NhZ2VzIHdo ZW4NCj4gY2FycmllZCBpbnNpZGUgbWVzc2FnZXMgaW4gYW4gVVRGOFNNVFAgZW52aXJvbm1lbnQ/ DQo+IA0KPiBBOiBObywgbWVzc2FnZS9yZmM4MjIgY2FuIGJlIHVzZWQuDQo+IEI6IFllcy4NCj4g QzogSSBoYXZlIGFub3RoZXIgb3Bpbmlvbiwgd2hpY2ggaXMuLi4uDQo+IA0KDQpCLg0KDQo+IFFV RVNUSU9OIDI6IFNob3VsZCB0aGUgc2FtZSBNSU1FIHR5cGUgYmUgdXNlZCB0byBjYXJyeSBVVEY4 U01UUCBtZXNzYWdlcyBpbg0KPiBhIFNNVFAgZW52aXJvbm1lbnQgKHdpdGhvdXQgdGhlIFVURjhT TVRQIGV4dGVuc2lvbiwgYW5kIHdpdGhvdXQgcmVxdWlyaW5nDQo+IHRoZSA4QklUTUlNRSBleHRl bnNpb24pPw0KPiBUaGlzIGltcGxpZXMgdGhhdCBpdCdzIHBvc3NpYmxlIHRvIGVuY29kZSB0aGUg bWVzc2FnZS4NCj4gDQo+IEE6IFllcy4NCj4gQjogTm8sIHRoYXQgc2hvdWxkIG5vdCBiZSBhbGxv d2VkLg0KPiBDOiBJIGhhdmUgYW5vdGhlciBvcGluaW9uLCB3aGljaCBpcy4uLi4NCj4gDQoNCkEu DQoNCj4gUVVFU1RJT04gMzogU2hvdWxkIHRoZSBuZXcgdHlwZSBiZSBhIHN1YnR5cGUgb2YgTWVz c2FnZS8/DQo+IA0KPiBBOiBZZXMNCj4gQjogTm8sIGl0IHNob3VsZCBiZSBhcHBsaWNhdGlvbi9z b21ldGhpbmcNCj4gQzogSSBoYXZlIGFub3RoZXIgb3Bpbmlvbiwgd2hpY2ggaXMuLi4uDQo+IA0K Qm90aGUgQSBhbmQgQiBhcmUgb2sgZm9yIG1lLg0KDQo+IFFVRVNUSU9OIDQ6IFdoYXQgc2hvdWxk IHRoZSBuZXcgTUlNRSB0eXBlIGJlIGNhbGxlZD8NCj4gDQo+IEE6IE1lc3NhZ2UvdXRmOHNtdHAN Cj4gQjogTWVzc2FnZS9pMThuDQo+IEM6IE1lc3NhZ2UvaW50ZXJuYXRpb25hbA0KPiBEOiBNZXNz YWdlL2dsb2JhbA0KPiBFOiBNZXNzYWdlL3JmY3h4eHggKHRvIGJlIGFzc2lnbmVkKQ0KPiBGOiBN ZXNzYWdlL3JmYzgyMiAoY29uc2lzdGVudCB3aXRoIGFuICJBIiBhbnN3ZXIgb24gcXVlc3Rpb24g MSkNCj4gRzogTWVzc2FnZS91dGY4DQo+IEg6IE1lc3NhZ2UvcmZjODIydQ0KPiBJOiBNZXNzYWdl L21haWwNCj4gSjogTWVzc2FnZS9pMThuLWVtYWlsDQo+IEs6IE1lc3NhZ2UvZWFpDQo+IEw6IE1l c3NhZ2Uvc210cA0KPiBNOiBNZXNzYWdlL3NtdHA4DQo+IE46IE1lc3NhZ2UvdXRmOGVhaQ0KPiBP OiBNZXNzYWdlL3V0ZjgtaGVhZGVycw0KPiBQOiBNZXNzYWdlL3V0ZjgtZW1haWwNCj4gUTogTWVz c2FnZS9pbWENCj4gUjogTWVzc2FnZS9pbnRsLWVtYWlsDQo+IFM6IEkgaGF2ZSBhbm90aGVyIG9w aW5pb24sIHdoaWNoIGlzLi4uLg0KDQpJIHByZWZlciBEIGFuZCBOLiANCkIgSiBTIGFyZSBhbHNv IG9rIC4NCg0KUzogTWVzc2FnZS9pLWFkZHJlc3MgICAoaW50ZXJuYXRpb25hbGl6ZWQgYWRkcmVz cykNCg0KDQpZQU8gSmlhbmthbmcNCg0KDQoNCg0KDQoNCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFQUktRFQgbWFpbGluZyBsaXN0 DQo+IEVBSS1EVEBhbHZlc3RyYW5kLm5vDQo+IGh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWls bWFuL2xpc3RpbmZvL2VhaS1kdA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4= --===============1368322478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1368322478==-- From ima-bounces@ietf.org Tue Jun 26 11:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3DBh-0008MN-DF; Tue, 26 Jun 2007 11:42:41 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3DBg-0008Hb-4u for ima-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 11:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3DBf-0008HT-Rg for ima@ietf.org; Tue, 26 Jun 2007 11:42:39 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3DAt-0000Zc-JA for ima@ietf.org; Tue, 26 Jun 2007 11:42:39 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1182870910!13870858!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23267 invoked from network); 26 Jun 2007 15:15:10 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-120.messagelabs.com with SMTP; 26 Jun 2007 15:15:10 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.13.8/8.13.8) with ESMTP id l5QFF9pj013799 for ; Tue, 26 Jun 2007 11:15:09 -0400 Received: from attrh3i.attrh.att.com (attrh3i.attrh.att.com [135.38.62.9]) by mlpi135.enaf.sfdc.sbc.com (8.13.8/8.13.8) with ESMTP id l5QFF6Ii013755 for ; Tue, 26 Jun 2007 11:15:06 -0400 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l5QFF563017211 for ; Tue, 26 Jun 2007 11:15:06 -0400 (EDT) Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l5QFEr18016984 for ; Tue, 26 Jun 2007 11:14:53 -0400 (EDT) Received: from [135.210.36.157] (unknown[135.210.36.157](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070626151452gw10010gv7e> (Authid: tony); Tue, 26 Jun 2007 15:14:52 +0000 Message-ID: <46812D63.8090903@att.com> Date: Tue, 26 Jun 2007 11:14:43 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: EAI WG Subject: Re: [EAI] POLL: on the "what MIME type" question References: <467B6915.2060000@alvestrand.no> In-Reply-To: <467B6915.2060000@alvestrand.no> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > 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.... B > 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.... A > 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.... A > 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.... In order of preference: D, K, C, B Whatever we choose will be a compromise. Tony Hansen tony@att.com _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 26 22:13:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3N20-0004XL-7V; Tue, 26 Jun 2007 22:13:20 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3N1z-0004XG-6g for ima-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 22:13:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3N1y-0004X4-AD for ima@ietf.org; Tue, 26 Jun 2007 22:13:18 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3N1t-0002kW-65 for ima@ietf.org; Tue, 26 Jun 2007 22:13:18 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5R2DCWB013684 for ; Wed, 27 Jun 2007 02:13:12 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK900I01V8DWU00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 26 Jun 2007 20:13:12 -0600 (MDT) Received: from [10.0.1.21] (adsl-69-232-52-25.dsl.irvnca.pacbell.net [69.232.52.25]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK900CWXVHXC3A0@mail-amer.sun.com>; Tue, 26 Jun 2007 20:13:12 -0600 (MDT) Date: Tue, 26 Jun 2007 17:48:51 -0700 From: Chris Newman Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply In-reply-to: <065301c7b7c5$12e64670$236ff1da@yaojk> To: YAO Jiankang Message-id: <2727A0ACBDF7DE77AF1B2380@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> <382323308.21509@cnnic.cn> <065301c7b7c5$12e64670$236ff1da@yaojk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: hurtta@siilo.fmi.fi, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org YAO Jiankang wrote on 6/26/07 15:39 +0800: > We would like to add one sentence in this section: > "UTF-8 is needed to represent email addresses in responses. This extension > does not authorize the use of UTF-8 for any other purpose". > > is it ok for you? It's good enough for me. However, the word "authorize" is unusual in this context so others might not like that. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 26 22:22:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3NAt-0005N9-Ju; Tue, 26 Jun 2007 22:22:31 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3NAs-0005HW-Bg for ima-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 22:22:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3NAs-0005FE-0P for ima@ietf.org; Tue, 26 Jun 2007 22:22:30 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3NAk-0004Jv-Tq for ima@ietf.org; Tue, 26 Jun 2007 22:22:29 -0400 Received: (snipe 3730 invoked by uid 0); 27 Jun 2007 11:23:05 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 1.075325 secs); Received: from unknown (HELO ?210.107.250.127?) (Z@210.107.250.127) by unknown with SMTP; 27 Jun 2007 11:23:04 +0900 X-SNIPER-SENDERIP: 210.107.250.127 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: Chris.Newman@Sun.COM, yaojk@cnnic.cn, hurtta@siilo.fmi.fi, ima@ietf.org, yangwooko@gmail.com Message-ID: <4681C9D8.2010900@icu.ac.kr> Date: Wed, 27 Jun 2007 11:22:16 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Chris Newman Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> <382323308.21509@cnnic.cn> <065301c7b7c5$12e64670$236ff1da@yaojk> <2727A0ACBDF7DE77AF1B2380@446E7922C82D299DB29D899F> In-Reply-To: <2727A0ACBDF7DE77AF1B2380@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: hurtta@siilo.fmi.fi, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org How about "allow" instead of "authorize"? Chris Newman wrote: > > YAO Jiankang wrote on 6/26/07 15:39 +0800: >> We would like to add one sentence in this section: >> "UTF-8 is needed to represent email addresses in responses. This >> extension >> does not authorize the use of UTF-8 for any other purpose". >> >> is it ok for you? > > It's good enough for me. However, the word "authorize" is unusual in > this context so others might not like that. > > - Chris > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 27 00:26:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3P7A-0008NA-Vh; Wed, 27 Jun 2007 00:26:49 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3P79-0008Ib-91 for ima-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 00:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3P78-0008Gz-3D for ima@ietf.org; Wed, 27 Jun 2007 00:26:46 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3P74-0000hB-R1 for ima@ietf.org; Wed, 27 Jun 2007 00:26:46 -0400 Received: by py-out-1112.google.com with SMTP id f31so157908pyh for ; Tue, 26 Jun 2007 21:26:42 -0700 (PDT) Received: by 10.141.68.10 with SMTP id v10mr30089rvk.1182918402105; Tue, 26 Jun 2007 21:26:42 -0700 (PDT) Received: by 10.141.33.14 with HTTP; Tue, 26 Jun 2007 21:26:42 -0700 (PDT) Message-ID: Date: Wed, 27 Jun 2007 13:26:42 +0900 From: "Jaeyoun Kim" To: "Harald Alvestrand" Subject: Re: [EAI] POLL: on the "what MIME type" question In-Reply-To: <467B6915.2060000@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <467B6915.2060000@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Please see below. On 6/22/07, Harald Alvestrand wrote: > 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.... B > > 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.... A > 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.... > > 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.... > C, D, or P Regards, Jaeyoun Kim -- ----------------------------------- Jaeyoun Kim (Peter) Manager of .kr SRS, NIDA (National Internet Development Agency of Korea) Email: peter@jaeyounkim.kr / Skype: kimjaeyoun ----------------------------------- _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 27 02:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3R7Q-0006bY-Ht; Wed, 27 Jun 2007 02:35:12 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3R7P-0006bR-9z for ima-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 02:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3R7P-0006bJ-0E for ima@ietf.org; Wed, 27 Jun 2007 02:35:11 -0400 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3R7K-0000cP-6s for ima@ietf.org; Wed, 27 Jun 2007 02:35:10 -0400 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id l5R6Ynqt006297; Wed, 27 Jun 2007 14:34:50 +0800 Message-ID: <07a401c7b885$969b74c0$c7d348d3@aabbeell> From: "abel" To: "Harald Alvestrand" , "EAI WG" References: <467B6915.2060000@alvestrand.no> Subject: Re: [EAI] POLL: on the "what MIME type" question Date: Wed, 27 Jun 2007 14:37:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org ----- Original Message ----- From: "Harald Alvestrand" To: "EAI WG" Sent: Friday, June 22, 2007 2:15 PM Subject: [EAI] POLL: on the "what MIME type" question > 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.... B > > 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.... A > > 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.... A > > 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.... A>G>K>N _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 27 03:02:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3RYG-0005LC-DT; Wed, 27 Jun 2007 03:02:56 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3RYC-0005K2-Iz for ima-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 03:02:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3RY7-0005Gj-7E for ima@ietf.org; Wed, 27 Jun 2007 03:02:47 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3RVD-0004ab-Th for ima@ietf.org; Wed, 27 Jun 2007 02:59:52 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B84A2596DD for ; Wed, 27 Jun 2007 08:59:47 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07962-01 for ; Wed, 27 Jun 2007 08:59:41 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A80B72596DB for ; Wed, 27 Jun 2007 08:59:41 +0200 (CEST) Message-ID: <46820ADD.2070800@alvestrand.no> Date: Wed, 27 Jun 2007 08:59:41 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [EAI] INTERMEDIATE POLL RESULTS on the "what MIME type" question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is an intermediate poll result report. The poll closes on Friday, 12:00 GMT. Apart from my opinion, all of the opinions listed below have been posted to the list. Not all respondents responded to all questions. This is a chance to comment on the reporting format, and to check for errors. We will draw no conclusions before Friday's deadline has passed. 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. Kari Hurtta (very slight preference) Charles Lindsey B: Yes. Harald Alvestrand Chris Newman John Klensin Yangwoo Ko Martin Duerst Kazunori Fujiwara Mao Wei Randall Gellens Yao Jiankang Tony Hansen Jaeyoun Kim Abel Yang C: I have another opinion, which is.... 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. Harald Alvestrand Chris Newman John Klensin Yangwoo Ko Martin Duerst Kazunori Fujiwara Mao Wei Randall Gellens Yao Jiankang Tony Hansen Jaeyoun Kim Abel Yang B: No, that should not be allowed. C: I have another opinion, which is.... Kari Hurtta Charles Lindsey QUESTION 3: Should the new type be a subtype of Message/? A: Yes Harald Alvestrand Chris Newman (slight preference) John Klensin Yangwoo Ko Martin Duerst Kazunori Fujiwara Mao Wei Randall Gellens Tony Hansen Abel Yang B: No, it should be application/something C: I have another opinion, which is.... Kari Hurtta Charles Lindsey QUESTION 4: What should the new MIME type be called? On this question, people tended to list "good" and "bad" names, with some left unmentioned. This is reflected in the reporting format; however, this format loses distinctions present in the original responses, such as preferences between the "good" types. A: Message/utf8smtp Good: Martin Duerst, Kazunori Fujiwara, Charles Lindsey, Abel Yang Bad: Chris Newman, John Klensin B: Message/i18n Good: Yangwoo Ko, Yao Jiankang, Tony Hansen Bad: Martin Duerst C: Message/international Good: Chris Newman, Yangwoo Ko, Mao Wei, Randall Gellens, Tony Hansen, Jaeyoun Kim Bad: Martin Duerst D: Message/global Good: Mao Wei, Randall Gellens, Yao Jiankang, Tony Hansen, Jaeyoun Kim Bad: Martin Duerst E: Message/rfcxxxx (to be assigned) Bad: Chris Newman, John Klensin, Martin Duerst F: Message/rfc822 (consistent with an "A" answer on question 1) Good: Kari Hurtta Bad: Chris Newman, John Klensin, Martin Duerst G: Message/utf8 Good: Chris Newman, Abel Yang Bad: John Klensin, Martin Duerst H: Message/rfc822u Good: Martin Duerst Bad: Chris Newman, John Klensin I: Message/mail Good: John Klensin, Martin Duerst, Randall Gellens J: Message/i18n-email Good: Yangwoo Ko, Martin Duerst, Charles Lindsey, Yao Jiankang K: Message/eai Good: Yangwoo Ko, Martin Duerst, Kazunori Fujiwara, Tony Hansen, Abel Yang L: Message/smtp Bad: Chris Newman, John Klensin, Martin Duerst M: Message/smtp8 Good: Martin Duerst Bad: Chris Newman, John Klensin N: Message/utf8eai Good: Martin Duerst, Kari Hurtta, Yao Jiankang, Abel Yang O: Message/utf8-headers Good: Martin Duerst, Charles Lindsey Bad: Chris Newman, John Klensin P: Message/utf8-email Good: Martin Duerst, Kari Hurtta, Jaeyoun Kim Q: Message/ima Good: Yangwoo Ko, Martin Duerst R: Message/intl-email Good: Martin Duerst, Mao Wei, Charles Lindsey S: I have another opinion, which is.... Kari Hurtta (application/utf8-email, message-eai-email, application/eai-email) Yao Jiankang (message/i-address) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 27 09:23:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XUO-0007KU-2y; Wed, 27 Jun 2007 09:23:20 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3XUN-0007KL-2j for ima-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 09:23:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XUM-0007KC-PP for ima@ietf.org; Wed, 27 Jun 2007 09:23:18 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3XTZ-0001fW-PZ for ima@ietf.org; Wed, 27 Jun 2007 09:23:18 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1I3XTU-000Bz2-Uy; Wed, 27 Jun 2007 09:22:25 -0400 Date: Wed, 27 Jun 2007 09:22:23 -0400 From: John C Klensin To: Chris Newman , YAO Jiankang Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply Message-ID: <875C9AA97710A37E7E73F8DF@[172.17.164.187]> In-Reply-To: <2727A0ACBDF7DE77AF1B2380@446E7922C82D299DB29D899F> References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> <382323308.21509@cnnic.cn> <065301c7b7c5$12e64670$236ff1da@yaojk> <2727A0ACBDF7DE77AF1B2380@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: hurtta@siilo.fmi.fi, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 26 June, 2007 17:48 -0700 Chris Newman wrote: > YAO Jiankang wrote on 6/26/07 15:39 +0800: >> We would like to add one sentence in this section: >> "UTF-8 is needed to represent email addresses in responses. >> This extension does not authorize the use of UTF-8 for any >> other purpose". >> >> is it ok for you? > > It's good enough for me. However, the word "authorize" is > unusual in this context so others might not like that. Yes. s/authorize/permit/ or s/authorize/enable/ I prefer the first, but not strongly john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 27 09:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XUw-0007kL-IG; Wed, 27 Jun 2007 09:23:54 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3XUv-0007jM-G4 for ima-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 09:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XUv-0007jE-6c for ima@ietf.org; Wed, 27 Jun 2007 09:23:53 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3XUB-0001uo-S1 for ima@ietf.org; Wed, 27 Jun 2007 09:23:53 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1I3XU8-000BzA-Cx; Wed, 27 Jun 2007 09:23:04 -0400 Date: Wed, 27 Jun 2007 09:23:02 -0400 From: John C Klensin To: Yangwoo Ko , Chris Newman Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply Message-ID: <4925AD8F708C811199E0C91D@[172.17.164.187]> In-Reply-To: <4681C9D8.2010900@icu.ac.kr> References: <26CDE517C11F3BDF63767D0E@[192.168.1.119]> <5dps3wo1jk.fsf@Hurtta06k.keh.iki.fi> <382323308.21509@cnnic.cn> <065301c7b7c5$12e64670$236ff1da@yaojk> <2727A0ACBDF7DE77AF1B2380@446E7922C82D299DB29D899F> <4681C9D8.2010900@icu.ac.kr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: hurtta@siilo.fmi.fi, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 27 June, 2007 11:22 +0900 Yangwoo Ko wrote: > > How about "allow" instead of "authorize"? Another good alternative. No preference between it and "permit". john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 27 16:09:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dpu-0006pY-T3; Wed, 27 Jun 2007 16:09:58 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3dpt-0006j7-3A for ima-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 16:09:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dps-0006hZ-MY for ima@ietf.org; Wed, 27 Jun 2007 16:09:56 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3dps-0002sZ-G6 for ima@ietf.org; Wed, 27 Jun 2007 16:09:56 -0400 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I3dpJ-00064A-W6 for ima@ietf.org; Wed, 27 Jun 2007 16:09:21 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id DC26813744; Wed, 27 Jun 2007 16:09:28 -0400 (EDT) Date: Wed, 27 Jun 2007 16:09:28 -0400 From: Andrew Sullivan To: ima@ietf.org Message-ID: <20070627200928.GB29333@dba3> References: <46820ADD.2070800@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46820ADD.2070800@alvestrand.no> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [EAI] Poll response on "what MIME type" question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Sullivan List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > QUESTION 1: Should there be a new MIME type for UTF8SMTP messages when > carried inside messages in an UTF8SMTP environment? "B", yes > 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)? "A", yes > QUESTION 3: Should the new type be a subtype of Message/? "A", yes > QUESTION 4: What should the new MIME type be called? Given the arguments I have seen, I now don't care. My guess is that anyone who cares is going to have to end up looking in the Fine Manual anyway. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 28 03:08:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3o74-0005Wa-Ou; Thu, 28 Jun 2007 03:08:22 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3o72-0005Vc-PM for ima-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 03:08:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3o6x-0005V2-R3 for ima@ietf.org; Thu, 28 Jun 2007 03:08:15 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3o6c-0001R0-1Y for ima@ietf.org; Thu, 28 Jun 2007 03:08:15 -0400 Received: (qmail invoked by alias); 28 Jun 2007 07:07:52 -0000 Received: from dslb-084-056-219-014.pools.arcor-ip.net (EHLO hive) [84.56.219.14] by mail.gmx.net (mp018) with SMTP; 28 Jun 2007 09:07:52 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19KFJAFx7BKBOXLDqoLUARNMkrrHsMEDco7tr227Y l4K69uGj1Dhi8P From: Bjoern Hoehrmann To: Harald Alvestrand Subject: Re: [EAI] POLL: on the "what MIME type" question Date: Thu, 28 Jun 2007 09:07:53 +0200 Message-ID: References: <467B6915.2060000@alvestrand.no> In-Reply-To: <467B6915.2060000@alvestrand.no> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org * Harald Alvestrand wrote: >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.... B. >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.... A. >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.... A. >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.... Good: I (mail), Q (ima), K (eai) (in that order) Bad: A, B, C, D, G, J, L, M, N, O, P Can live with: E (rfcxxxx), F (rfc822), H (rfc822u), R (int-email). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 28 06:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rNE-0002TO-CH; Thu, 28 Jun 2007 06:37:16 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I3rNC-0002TF-H9 for ima-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 06:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rNB-0002St-LW; Thu, 28 Jun 2007 06:37:13 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3rN2-0001FB-5a; Thu, 28 Jun 2007 06:37:13 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew#man*ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46838f4e.bf7d.4d; Thu, 28 Jun 2007 11:37:02 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5SAb1YI000797; Thu, 28 Jun 2007 11:37:02 +0100 (BST) To: Internet-Drafts@ietf.org References: Message-ID: Date: Thu, 28 Jun 2007 11:37:00 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IMA Subject: [EAI] Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 20 Jun 2007 18:00:02 +0100, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Keys Identified Mail Working > Group of the IETF. > > Title : DKIM Sender Signing Practices > Author(s) : E. Allman, et al. > Filename : draft-ietf-dkim-ssp-00.txt > Pages : 19 > Date : 2007-06-18 > DomainKeys Identified Mail (DKIM) defines a domain-level > authentication framework for email using public-key cryptography and > key server technology to permit verification of the source and > contents of messages by either Mail Transport Agents (MTAs) or Mail > User Agents (MUAs). The primary DKIM protocol is described in > [RFC4871]. > This document describes the records that senders may use to advertise > how they sign their outgoing mail, and how verifiers should access > and interpret those results. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-00.txt But that URL does not seem to work, and I cannot find it at my usual mirror (ftp.nordu.net). Please can somebody fix it? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 29 05:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4CcI-0005NM-MK; Fri, 29 Jun 2007 05:18:14 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I4CcF-0005A1-7U for ima-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 05:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4CcE-00058H-Ex for ima@ietf.org; Fri, 29 Jun 2007 05:18:10 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4CXX-0000po-F4 for ima@ietf.org; Fri, 29 Jun 2007 05:14:17 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew#man#ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4684cd2d.25a6.9 for ima@ietf.org; Fri, 29 Jun 2007 10:13:17 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l5T9DGou015156 for ; Fri, 29 Jun 2007 10:13:17 +0100 (BST) To: IMA Subject: Re: [EAI] Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt References: Message-ID: From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Fri, 29 Jun 2007 10:13:15 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 28 Jun 2007 11:37:00 +0100, Charles Lindsey wrote: >> http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-00.txt > > But that URL does not seem to work, and I cannot find it at my usual > mirror (ftp.nordu.net). Please can somebody fix it? > Oops! Wrong list again. Sorry! -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 29 07:26:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ec2-0003fj-TH; Fri, 29 Jun 2007 07:26:06 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I4Ec1-0003bd-49 for ima-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 07:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ec0-0003aY-Qa for ima@ietf.org; Fri, 29 Jun 2007 07:26:04 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Eb5-0003yH-P4 for ima@ietf.org; Fri, 29 Jun 2007 07:26:04 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l5TBP6wG022931 for ; Fri, 29 Jun 2007 20:25:06 +0900 (JST) Received: (from NOTE233 [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007062920250518150 ; Fri, 29 Jun 2007 20:25:05 +0900 Date: Fri, 29 Jun 2007 20:25:01 +0900 From: Yoshiro YONEYA To: EAI WG Message-Id: <20070629202501.eb44ba53.yone@jprs.co.jp> In-Reply-To: <467B6915.2060000@alvestrand.no> References: <467B6915.2060000@alvestrand.no> X-Mailer: Sylpheed 2.4.3 (GTK+ 2.10.13; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [EAI] Re: POLL: on the "what MIME type" question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 22 Jun 2007 08:15:49 +0200 Harald Alvestrand wrote: > 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.... B > 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.... A > 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.... A > 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.... P > R > J -- Yoshiro YONEYA _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 29 18:08:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Odn-00030X-GV; Fri, 29 Jun 2007 18:08:35 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I4Odk-0002wv-Vx for ima-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 18:08:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Odk-0002wm-JK; Fri, 29 Jun 2007 18:08:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Odk-0001v3-CT; Fri, 29 Jun 2007 18:08:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1E4B5175EC; Fri, 29 Jun 2007 22:08:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I4OdF-0005ux-NA; Fri, 29 Jun 2007 18:08:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 29 Jun 2007 18:08:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-07.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-07.txt Pages : 20 Date : 2007-6-29 This document specifies the use of SMTP extension for internationalized email address delivery. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-29171548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-29171548.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart--