From ima-bounces@ietf.org Sat Dec 01 10:10: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 1IyTzP-00043T-Kq; Sat, 01 Dec 2007 10:10:43 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IyTzO-00043G-C0 for ima-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 10:10:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyTzL-0003mk-42 for ima@ietf.org; Sat, 01 Dec 2007 10:10:39 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyTzJ-0002m1-Qq for ima@ietf.org; Sat, 01 Dec 2007 10:10:39 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IyTwq-00035z-Og for ima@ietf.org; Sat, 01 Dec 2007 15:08:04 +0000 Received: from c-180-160-112.hh.dial.de.ignite.net ([62.180.160.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Dec 2007 15:08:04 +0000 Received: from nobody by c-180-160-112.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Dec 2007 15:08:04 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Sat, 1 Dec 2007 16:07:55 +0100 Organization: Lines: 15 Message-ID: References: <474EDC05.8060400@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-112.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [EAI] Re: Disposition of comments, second Last Call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann 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: =20 > Hopefully, we'll then be done with this set. Hopefully both attempts of "updates MIME" get what they deserve in the IETF Last Call... :-| I vaguely recall that as result of the first WGLC "we" (TINW) agreed to adopt a "security consideration" in the form proposed by John, but I don't recall to see this in the diff. Was this lost somewhere, or did I miss it ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Dec 01 10:19:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyU8I-0001Qz-U7; Sat, 01 Dec 2007 10:19:54 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IyU8I-0001OS-I9 for ima-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 10:19:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyU8I-0001Km-4l for ima@ietf.org; Sat, 01 Dec 2007 10:19:54 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyU8H-00060W-QR for ima@ietf.org; Sat, 01 Dec 2007 10:19:54 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IyU5A-0006d2-Cg for ima@ietf.org; Sat, 01 Dec 2007 15:16:40 +0000 Received: from c-180-160-112.hh.dial.de.ignite.net ([62.180.160.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Dec 2007 15:16:40 +0000 Received: from nobody by c-180-160-112.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Dec 2007 15:16:40 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Sat, 1 Dec 2007 16:16:27 +0100 Organization: Lines: 18 Message-ID: References: <474FD1CB.1080606@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-112.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [EAI] Re: #1518 Normalization - a proposal for resolution X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann 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: > Does that seem appropriate? Could you somehow smuggle in a note that the set of allowed UTF-8 characters might be reduced in a future version ? E.g. RFC 3987 defines a sound subset, no C1, no non-characters, no PUA. We're just not ready to decide what we want yet, it's only an experiment. Maybe allowing PUA is perfect for folks wishing to use "apples" in their local parts, and maybe allowing Unicode new line characters or similar cases turn out to cause havoc. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 02 09:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IypMF-00077f-K2; Sun, 02 Dec 2007 08:59:43 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IypME-00077T-6y for ima-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 08:59:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IypMD-00077K-Sx for ima@ietf.org; Sun, 02 Dec 2007 08:59:41 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IypMD-0005YJ-FM for ima@ietf.org; Sun, 02 Dec 2007 08:59:41 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1FA9B2596EA; Sun, 2 Dec 2007 14:59:40 +0100 (CET) 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 13946-05; Sun, 2 Dec 2007 14:59:30 +0100 (CET) Received: from [192.168.1.119] (unknown [207.236.117.226]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB3672596F0; Sun, 2 Dec 2007 14:59:29 +0100 (CET) Date: Sun, 02 Dec 2007 14:11:08 +0100 From: Harald Tveit Alvestrand To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: #1518 Normalization - a proposal for resolution Message-ID: In-Reply-To: References: <474FD1CB.1080606@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 1. desember 2007 16:16 +0100 Frank Ellermann wrote: > Harald Alvestrand wrote: > >> Does that seem appropriate? > > Could you somehow smuggle in a note that the set > of allowed UTF-8 characters might be reduced in a > future version ? wouldn't dream of SMUGGLING it in :-) > E.g. RFC 3987 defines a sound subset, no C1, no > non-characters, no PUA. We're just not ready to > decide what we want yet, it's only an experiment. > > Maybe allowing PUA is perfect for folks wishing > to use "apples" in their local parts, and maybe > allowing Unicode new line characters or similar > cases turn out to cause havoc. hm - that subset makes some sense to me. It's hard to argue for C1, half-surrogates or PUA, or that running the experiment with this restriction will make it impossible to change our minds later. Other opinions? BTW - this ticket shows the dangers of having stayed with a document for a long time; it turns out that almost exactly the same text was in section 5 already: This document does not specify any requirement for normalization. Prudent use of UTF-8 in identifiers will involve sharply restricted forms, for instance case-folded NFKC, but this document does not require such a form anywhere in the protocol. and another forgotten "note in draft". Should this be moved to section 4? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 02 10:59:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyrEF-0000yo-OY; Sun, 02 Dec 2007 10:59:35 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IyrEE-0000sS-BK for ima-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 10:59:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyrED-0000q0-Ve for ima@ietf.org; Sun, 02 Dec 2007 10:59:34 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyrED-0001pj-58 for ima@ietf.org; Sun, 02 Dec 2007 10:59:33 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IyrEB-0002tQ-4U; Sun, 02 Dec 2007 10:59:31 -0500 Date: Sun, 02 Dec 2007 10:59:29 -0500 From: John C Klensin To: Harald Tveit Alvestrand , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: #1518 Normalization - a proposal for resolution 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: -100.0 (---------------------------------------------------) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Playing devil's advocate, every step we take toward limiting what can be placed in the local-part string takes us a step closer to authorizing senders, relays, or downgraders to start "fixing" those addresses... or having them decide it is a good thing to do. From that point of view, I'd rather that the norms stand firmly behind the "no one else tampers" principle. As you know, I've argued elsewhere that imposing NFKC is a bad idea because there may be localized controversy as to whether a few of the characters are really, properly, canonical equivalents. That said, we know how to ban controls other than SP (perhaps by property rather than simply the C1 (or C1 and C0) blocks) and arguably should have done so in 821/ 1123/ 2821 many years ago. To me, that is conceptually very different from starting to write rules about graphic characters. I'd still prefer to see this resolved by a separate "advice to mail server administrators about forms of addresses" document. It could even be standards-track if it confined itself to MAY (except, maybe, for those controls). But that document isn't on the WG's task list (something that we could ask to have fixed) and it isn't obvious to me who would have the extra cycles to act as editor. john --On Sunday, 02 December, 2007 14:11 +0100 Harald Tveit Alvestrand wrote: > > > --On 1. desember 2007 16:16 +0100 Frank Ellermann > wrote: > >> Harald Alvestrand wrote: >> >>> Does that seem appropriate? >> >> Could you somehow smuggle in a note that the set >> of allowed UTF-8 characters might be reduced in a >> future version ? > > wouldn't dream of SMUGGLING it in :-) > >> E.g. RFC 3987 defines a sound subset, no C1, no >> non-characters, no PUA. We're just not ready to >> decide what we want yet, it's only an experiment. >> >> Maybe allowing PUA is perfect for folks wishing >> to use "apples" in their local parts, and maybe >> allowing Unicode new line characters or similar >> cases turn out to cause havoc. > > hm - that subset makes some sense to me. It's hard to argue > for C1, half-surrogates or PUA, or that running the experiment > with this restriction will make it impossible to change our > minds later. Other opinions? > > BTW - this ticket shows the dangers of having stayed with a > document for a long time; it turns out that almost exactly the > same text was in section 5 already: > > This document does not specify any requirement for > normalization. > Prudent use of UTF-8 in identifiers will involve sharply > restricted > forms, for instance case-folded NFKC, but this document > does not > require such a form anywhere in the protocol. > > and another forgotten "note in draft". > Should this be moved to section 4? > > Harald > > > _______________________________________________ > 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 Dec 04 14:22: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 1IzdM3-0001dp-NY; Tue, 04 Dec 2007 14:22:51 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IzdM3-0001dI-1D for ima-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:22:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdM2-0001d3-N6 for ima@ietf.org; Tue, 04 Dec 2007 14:22:50 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdM2-0003Sb-Bf for ima@ietf.org; Tue, 04 Dec 2007 14:22:50 -0500 Received: from dev18.int.libertyrms.com ([10.1.3.126]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IzdM2-0004dB-2W for ima@ietf.org; Tue, 04 Dec 2007 14:22:50 -0500 Message-ID: <4755A909.7000407@ca.afilias.info> Date: Tue, 04 Dec 2007 14:22:49 -0500 From: Derek Williams User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: dwilliams@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -3.8 (---) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] Downgrading of UTF-8 Subject: header 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 pertains the downgrade method proposed in draft-ietf-eai-downgrade-05.txt. And specifically, to this exclusively as it applies to the "Subject:" header. The process of downgrading a message containing UTF-8 characters in the value portion of its "Subject:" header results in the generation of a non-UTF8 message that will be displayed by all current UTF8SMTP unaware MUA's without a "Subject:" header. The reason for this is because the current downgrading method requires that the "Subject:" header label be renamed to "Downgraded-Subject:" for purposes that unclear to me at the time of this writing. As a result of this, all current MUA's identify this new "Downgraded-Subject:" header as unknown and fail to display a subject to the user. Given the importance of the "Subject:" header we should make an effort to preserve this header as much as possible. An alternate method for downgrading the subject header would be to MIME encode the value portion of the "Subject:" header leaving the header label untouched. However, some may argue that this doesn't preserve the original data so [optionally] a "Downgraded:" indicator could be added labeling the message as downgraded. This indicator would be prefixed to the "Subject:" header value similarly to how the "Re:" indicator is prefixed by an MUA when a message is replied to. For example: Subject: value-containing-utf8 after downgrade would become Subject: mime-encoded-value-containing-utf8 or, with optional "Downgraded:" indicator Subject: Downgraded: mime-encoded-value-containing-utf8 -- Derek Williams Afilias Canada 204-4141 Yonge Street Toronto, ON Canada M2P 2A8 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Dec 04 14:43:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdgI-0007uC-OF; Tue, 04 Dec 2007 14:43:46 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IzdgH-0007tv-Lw for ima-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdgH-0007tb-4G for ima@ietf.org; Tue, 04 Dec 2007 14:43:45 -0500 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdgG-0005Tu-P1 for ima@ietf.org; Tue, 04 Dec 2007 14:43:45 -0500 Received: from dev18.int.libertyrms.com ([10.1.3.126]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IzdgG-0005R7-Cw for ima@ietf.org; Tue, 04 Dec 2007 14:43:44 -0500 Message-ID: <4755ADF0.8030807@ca.afilias.info> Date: Tue, 04 Dec 2007 14:43:44 -0500 From: Derek Williams User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] Downgrading of UTF-8 Subject: header References: <4755A909.7000407@ca.afilias.info> In-Reply-To: <4755A909.7000407@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: dwilliams@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -3.8 (---) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 disregard this email. I recently noticed that the "Subject:" header is not re-named. My apologies. Derek Williams wrote: > The following pertains the downgrade method proposed in > draft-ietf-eai-downgrade-05.txt. And specifically, to this exclusively > as it applies to the "Subject:" header. > > The process of downgrading a message containing UTF-8 characters in > the value portion of its "Subject:" header results in the generation > of a non-UTF8 message that will be displayed by all current UTF8SMTP > unaware MUA's without a "Subject:" header. The reason for this is > because the current downgrading method requires that the "Subject:" > header label be renamed to "Downgraded-Subject:" for purposes that > unclear to me at the time of this writing. As a result of this, all > current MUA's identify this new "Downgraded-Subject:" header as > unknown and fail to display a subject to the user. Given the > importance of the "Subject:" header we should make an effort to > preserve this header as much as possible. > > An alternate method for downgrading the subject header would be to > MIME encode the value portion of the "Subject:" header leaving the > header label untouched. However, some may argue that this doesn't > preserve the original data so [optionally] a "Downgraded:" indicator > could be added labeling the message as downgraded. This indicator > would be prefixed to the "Subject:" header value similarly to how the > "Re:" indicator is prefixed by an MUA when a message is replied to. > > For example: > Subject: value-containing-utf8 > after downgrade would become > Subject: mime-encoded-value-containing-utf8 > or, with optional "Downgraded:" indicator > Subject: Downgraded: mime-encoded-value-containing-utf8 > > -- Derek Williams 204-4141 Yonge Street Afilias Canada Toronto, ON Canada M2P 2A8 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Dec 21 01:33: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 1J5bRr-0002EM-6s; Fri, 21 Dec 2007 01:33:31 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J5bRp-0002EF-AO for ima-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 01:33:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5bRo-0002E6-1c for ima@ietf.org; Fri, 21 Dec 2007 01:33:28 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5bRm-0007zS-1h for ima@ietf.org; Fri, 21 Dec 2007 01:33:27 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D6DF2596BE for ; Fri, 21 Dec 2007 07:33:23 +0100 (CET) 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 22215-01 for ; Fri, 21 Dec 2007 07:33:15 +0100 (CET) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id B574E2596BD for ; Fri, 21 Dec 2007 07:33:14 +0100 (CET) Date: Fri, 21 Dec 2007 07:30:26 +0100 From: Harald Tveit Alvestrand To: EAI WG Message-ID: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========F4669F31B0C9314AE0EA==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 1.8 (+) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Subject: [EAI] Minutes from our Vancouver meeting 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 --==========F4669F31B0C9314AE0EA========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Attached are the preliminary minutes from the Vancouver meeting. Please send corrections to the list. Thanks a lot to Don Eastlake for recording these! I have also uploaded the minutes + the agenda slides to the meeting materials server. Please inspect and comment! Harald --==========F4669F31B0C9314AE0EA========== Content-Type: text/plain; charset=utf-8; name="EAI minutes.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="EAI minutes.txt"; size=16288 Email Address Internationalization WG Meeting : IETF 70, Wednesday, December 5, 2007, 0900-1130 Location: Westin Bayshore, Vancouver, Canada Chairs : Harald Alvestrand , Xiaodong Lee = Minutes : Donald Eastlake III Version : 1.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Where appropriate, resolutions are marked with *** in the text. Call to Order: 9:02am Appointed Scribe: Donald Eastlake. Blue Sheet, Agenda Bashing (no changes) Status of core documents -------------------------- Draft-ietf-eai-utf8headers-08.txt Draft-ietfi-eai-dsn-05.txt Smtpext-09.txt Have completed 2nd WG LC on these documents Issues have been recorded in tracker and mostly resolved except a few minor items. Chair has two issues on core documents where consensus does not seem solid: #1507 weird characters in UTF8HDR/DSN: Remove NO-WS_CTL from spec? #1518 normalization Pete Resnick: go with 2822bis which is tossing no white space controls Harald: Import text from 2822bis? Pete: No, just reference. Harald: creates a normative dependence on 2822bis... Pete: Yes but 2822bis should go to IETF LC as soon as no white space controls are resolved Harald: Going to Draft? Pete: Yes. Audience: Ooooh Tony Hansen: Does implementation report have to be done before LC if its for Draft? Harald: Yes. Harald: We can probably get away with a bit because we are aiming for Experimental. Philip Guenther: Could 2822bis go for Proposed and the upgrade to Draft later without change? Harald: Note that there is a minimum of six months at Proposed before can go to Draft. Can we reference 2822 and informatively say we'd prefer 2822bis...? Chris Newman (AD): Well, I have no problem with a down reference or stating intentions for future references. *** #1507: suggestion: normative reference to 2822 for "text", state in = text that 2822bis is preferable. #1518: There are two statements in EAI draft. In 4.1 says normalization will be discussed; in 5 says will not specify normalization. Prudent use of normalization will involve restriction. John Klensin: I'm afraid of starting down a slippery slope. There are many normalizations with different purposes and effects. We are probably better off saying that local parts of addresses are for the receiving server and no one else should dare touch them.=20 Harald: Some sections of the draft just talk about text all over, not just addresses. Possibilities are 1. delete the section 4.1 note. 2. remove the note at section 5. 3. move provisions to UTF8 header section. Klensin: We should just drop these provisions. Chris Newman: I'm concerned about interoperability. Different normalizations at different recipient domains would be a problem. We need to provide enough pointers that this is unlikely. Klensin: The problem is that pointing at Unicode without being specific can lead to choices of normalization that lose data, are inconsistent, etc. I've been pushing a document going a bit further by defining a Net UTF8 stream more generally for the IETF. But it fails due to controversy. Chris: Should we insert an informative reference to Klensin's Net UTF8? Klensin: Sure. Harald: At least two people want this. Chris: We should clarify that this is to be used by recipient domains in interpreting their local part. Harald: Then it sounds like it concerns headers, not general text. Klensin: It's more general but the provisions needs a bit of tweaking for which I volunteer to help. Poll on referencing Klensin draft: 20 in favor, 0 against. Klensin: My document has a discussion of issues on normalized versus non-normalized text. *** #1518 resolution: Refer to draft-klensin-net-utf8. Placement with the document at the editor's discretion. If removed from Section 5, section 5 can be removed. Pete Coats: Local addresses are usually case mapped. What about things like Turkish? Klensin: This sort of question is why no one but the target server manipulates this. Your example is an excellent example of why this should not be discussed in the EAI documents. Harald: We will confirm these resolutions on the mailing list, update the drafts, and send them to the IESG. Downgrade: Document: draft-ietf-eai-downgrade-05.txt ----------------------------------------------------- Issue #1496: Simple downgrade procedure? Could close this issue by saying the description in Section 8.1 is adequate? John Klensin supports this. Appendix A: IMAP and POP have some upgrading text. Do we want to move such text to this document? Call for comments: none at microphone. Harald: Is this document ready for WG LC? Chris Newman: We should have some input from someone who has implemented downgrading. Suggest Ned Freed. I'll help get comments from him if needed. Klensin: If Ned has implemented this, that makes three implementations I know about. Randy Gellens: I think the document is in good shape but discussion of reconstructing information from documents could be added. Or this could be in a separate document or an Appendix. Harald: Are you suggesting to make Appendix A a separate document? Randy: Yes. Harald: Any objections. (none) I like it. Harald: Who has read this? (a few hands raised) Harald: Should Appendix A be a separate document? 2 in favor, 0 against. Klensin: Maybe the small response is because some people may need to consider this question for a while before answering. Harald: Will punt the question to the mailing list. With luck may we may get to WG LC before Christmas. If so, it will be a long WG LC due to the holidays. *** Resolution: Punt removal of Appendix A to a separate document to the = list. *** Resolution: Otherwise, document is ready for WG Last Call. IMAP and POP ------------ Draft-ietf-eai-imap-utf8-02.txt Draft-ietf-eai-pop-02.txt Pete Resnick (imap author): We should talk about upgrading first. i.e., let Randy talk first. Randy Gellens: Up-conversion in IMAP and POP: Mail stores can be in either ASCII or UTF8. Clients can ask for either. Currently the server is specified to do the up-conversion from ASCII to UTF8. But servers will probably not do a good job either, as clients have not been doing a good job. It is unreasonable to expect a server to support all possible RFC 2047 encodings. A client is in better shape because it knows what encoding it could be interest in and it will have to do conversions for old servers anyway. My proposal is to change the documents so that if a client requests UTF8, it will get it if the message is in UTF8, but if message is in ASCII, it gets ASCII. The hope is that as EAI is deployed, RFC 2047 encoding and downgraded messages stop being used. Chris Newman: (speaking as an author of the document, will not be the sponsoring AD)=20 The counter argument is as follows: Language was put in to try for the brightest possible future. Implementations of RFC 2047 on clients have been poor. Server implementations on servers are better. Expecting your mobile client to have lots of character tables is a big burden. The goal was to support simpler UTF8 clients sooner, although there is a transition period where clients do have to support RFC 2047. We want to get to a brighter future sooner. Marc Crispin: I don't think there is any harm if the server does the conversion. We can't practically prohibit it. There are clients who want to see the RFC 2047 encoding to help the client guess what character set the other guy wants. No matter what level of services we provide in the server, there is no guarantee that clients will use it. It is discouraging to me that the most common client IMAP operations are basic raw message operations. Pete Resnick: Mostly agree with Marc. Sure, servers can always do this. We could have an extension for clients to ask for up-conversion. That's what the lemonade extension was about. Let's just leave it out of documents. John Klensin: Agree with Marc, but: we get in a trap because if you send stuff around in "funny" character sets and make a requirement for conversion than you impose a requirement to know all possible character sets, including those not standardized. We have learned that it is best to use one format in messages and leave the end points to do conversion to avoid the n x n problem. We should keep things as close to UTF8 as possible. Otherwise, MIME may just tell us why we can't interoperate. X: Only mail sender and re ... Noji Kujiway (sp?): Downgraded message in a traditional RFC 2822 message except for downgrade header. Andrew Daviel: If RFC 2047 is so complex and you want the end stations to do the conversion why not use Hex. Harald: It is no simpler to use Hex: Randy: The idea that if the document says noting then servers could do what they want is wrong because it leads to non-interoperability such as with signatures. If servers can do up-conversion then they need to indicate if they have done so, etc. Wink-wink won't cut it. Harald: Cases ... Randy: Up-converting a signed message will break the signature. If a message is EAI and you have to down convert, that will also break signatures but we have decided we have to live with that and it should go away as EAI is deployed. The recipient can see the down converted headers and complain to sysadmin/sender. Harald: Questions: Do people have enough information to decide on the server upgrade question? 10 have enough info, 3 don't Do people want to remove up convert form IMAP/POP? 15 do, 0 don't: Strong consensus. *** Resolution: Upconvert is removed. =20 Pete: IMAP, if we go forward, we can eliminate section 9. Who has read -02 draft? (few) -02 makes use of ENABLE. ... You throw the big UTF8 switch at the beginning of the session. This is much better than switching just because you receive UTF8. The document needs various minor clean ups. It should be ready for wider review with next the version. Philip Guenther: Unbaked idea: UTF8 message flags are atoms. They can have any character in them. Use case is gmail labels.=20 Harald: Seems outside of charter.=20 Alexey: In IMAP WG ... Maybe some things like UTF8 login name should be removed from Experimental EAI document and made standards track. Chris Newman (AD): Get EAI documents out. I'm not concerned about things going from Experimental to Standards track quickly. Alexey: Do you have concerns about moving to a separate document in the future? Chris: No. Some things were put into EAI just because there was no place elsewhere. It's no problem splitting the IMAP doc if we want. * Harald: What about POP document? Randy: Current version was published in July. There has not been much discussion. I will revise it to remove up-conversion. Differs from IMAP in that IMAP has a big switch you throw and after you throw it everything is in the new bright UTF8 world. The POP document, on the other hand, has UTF8 versions of most separate commands. Clients are required to always use the UTF8 version if UTF8 capable and not switch back and forth but obviously a perverse client could. That structure means that a POP server might have to do down conversion on a per command basis. We could change POP to also be on a big switch basis. The down side is that POP does not have the same state situation as IMAP. Peter Coat: Why not have variants of the PASS command instead of all commands. Randy: Well, you would want a USER8 command... Chris: All POP commands are 4 characters. Pete: USR8? Randy: 8888? Pete: Say you don't know what the server supports? Randy: You get a capabilities list before you send even your user name. Harald: Choices for POP: Big switch, separate commands, no change, take to mailing list? Klensin: I favor a mode switch for two reasons. (1) Duplicate commands are just plain ugly and client changes per command is scary. (2) There are two ways to implement such things. One is to convert the entire message or message group and other in incrementally. An advantage of a mode switch is that it leaves the strategy up to the server. Per command changes pretty much requires the server to do it incrementally. Harald: 20 in favor of a big switch, 0 against. Strong consensus. *** Resolution: POP will use a "big switch" rather than separate commands. Peter Coat: On IMAP changes, I would like to see a reference to the lemonade convert document internet-draft. Klensin: The more we send people off to documents they may not be able to find, like IDs, the more we are asking for trouble... We should encourage lemonade to publish anything important as an RFC. Other Business -------------- 1. Should the "Mailto:" URL be a work item? Draft-duetrst-mailto-bis-04.txt (expired) talks about this but not in the local part. This draft has no other home. 2. Implementation experience. Interop at next IETF? Klensin: Rant preview: some of us have observed at international meetings things that have led me to conclude that IRIs are seriously and terminally broken. Or at least IRIs are irrelevant to the problem that people expect IRIs to solve. On question is is "@" appropriate in some other character set that may by RtoL? Things are not so bad in URI form. IRI is a different matter. Other meta-issue: "Mailto:" URI is designed to take an address and some things that can be dropped into headers. Will be hard to change to take an address and an alternate address... Pete: Seems like the Martin Duerst effort is different. He is trying to internationalize current "Mailto:". We need to add info... Suggest postponing this. Randy: Brief comment on alternate address... Can also put a "body" parameter in a "Mailto:" URI. Klensin: I'm not saying it is insurmountable but it is non-trivial... Randy: Unfortunately, UTF8 in "Mailto:" is critical. Consider list headers. Harald: That's compelling. If we can't complete the mailing lists document without doing this, then we have to do it. People are invited to write text. *** Resolution: Internationalization of Mailto: is within scope, because it is a requirement for the List-headers work. Harald: Implementation experience. Rumors of three implementations. I just noticed that I had set up an eai-implementors mailing list.=20 Eai-implementors@alvestrand.no, eai-implementors-request@alvestrand.no=20 Some implementers are sensitive about revealing that they are implementing but, for those who wish to announce, it would be good if they do so. Chris? Chris (as AD): The current APPs area plan is to set aside a room Wednesday at the next IETF meeting where people can gather and do interoperability tests. APPs area is getting a bit small. Want to draw in people. We will try this. I don't have details yet but suggest people plan to bring laptops set up for informal interoperability tests. Future Plans: ------------- Harald: Action items. Core documents: new revisions addressing issues and editors fixes. Then, about a week for informal review. (Documents have been WGLCed twice already.) Then ship to IESG. Could do soon if editors are energetic. Other documents: WGLC on next version of downgrade document. Plan to send to IESG in January. By February should have total focus on remaining issues: IMAP, POP, Mailing Lists, ... We also have scenarios document. It might be a useful place to put information on various cases of clients understanding or not understanding talking to messages stores that understand or don't understand messages that are or are not EAI. John Klensin said he will work on framework document. Can maybe add the things that we didn't know should have been in it at first. Next meeting, final discussions on POP and IMAP and whatever else we can manage. Soon after that, currently chartered documents will be finished: a complete set of Experimental documents people can experiment with. Perhaps near the end of 2008, we can look at whether we want to push this onto the Standards Track. We may choose not to meet at the summer 2008 IETF meeting. Will probably meet again with a new charter in the Fall. Adjourn. 10:36 --==========F4669F31B0C9314AE0EA========== 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 --==========F4669F31B0C9314AE0EA==========-- From ima-bounces@ietf.org Sat Dec 22 12:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67rc-0002Mp-D7; Sat, 22 Dec 2007 12:10:16 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J67rb-0002Mj-FA for ima-confirm+ok@megatron.ietf.org; Sat, 22 Dec 2007 12:10:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67rb-0002Mb-5F for ima@ietf.org; Sat, 22 Dec 2007 12:10:15 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J67ra-0002oh-QD for ima@ietf.org; Sat, 22 Dec 2007 12:10:15 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J67qd-0004jE-2z for ima@ietf.org; Sat, 22 Dec 2007 17:09:15 +0000 Received: from c-180-160-126.hh.dial.de.ignite.net ([62.180.160.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 17:09:15 +0000 Received: from nobody by c-180-160-126.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 17:09:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Sat, 22 Dec 2007 18:08:46 +0100 Organization: Lines: 36 Message-ID: References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-126.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [EAI] Re: Minutes from our Vancouver meeting X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann 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 wrote: =20 > Please inspect and comment! I'm not aware of major controversies about net-utf8, only minor issues wrt HT, FF, NEL, and maybe one or two other characters. What was John talking about ? The reolution to reference his draft is good. BTW, the "unicode escapes" were approved some days ago, that RFC could (should ?) be referenced in EAI-DSN. | *** Resolution: Internationalization of Mailto: is | within scope, because it is a requirement for the | List-headers work. Interesting. I kind of hoped that mailto-bis would be limited to fix mailto (for 3986, automagically also 3987). With 2822upd entering the picture that is not more as "impossible" as it used to be. But=20 I still think that mailto-I18N should be a second (experimental) step after mailto-bis (PS) is ready. | Perhaps near the end of 2008, we can look at | whether we want to push this onto the Standards | Track. No need to push and rush. For 4408 the number of=20 real (not just me ;-) complaints that experimental isn't good enough for anything serious was limited. Creating a test suite and collecting errata needs some time, less than a year might be too short. Happy holidays, Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Dec 22 12:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J68Ph-00076f-TQ; Sat, 22 Dec 2007 12:45:29 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J68Ph-00076Z-5m for ima-confirm+ok@megatron.ietf.org; Sat, 22 Dec 2007 12:45:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J68Pg-00074v-Qv for ima@ietf.org; Sat, 22 Dec 2007 12:45:28 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J68Pg-0006St-G7 for ima@ietf.org; Sat, 22 Dec 2007 12:45:28 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1J68Pf-000E9L-Kw; Sat, 22 Dec 2007 12:45:27 -0500 Date: Sat, 22 Dec 2007 12:45:25 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: Minutes from our Vancouver meeting Message-ID: <54F1EF31C09A40F72088C5CD@p3.JCK.COM> In-Reply-To: References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> 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: -100.0 (---------------------------------------------------) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Saturday, 22 December, 2007 18:08 +0100 Frank Ellermann wrote: > I'm not aware of major controversies about net-utf8, > only minor issues wrt HT, FF, NEL, and maybe one or > two other characters. What was John talking about ? I consider the recurring controversy (if that is the right term) about NEL / CRLF to be quite a major issue, actually. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Dec 22 16:46: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 1J6CAs-0002Gy-5j; Sat, 22 Dec 2007 16:46:26 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J6CAq-0002Gr-Vh for ima-confirm+ok@megatron.ietf.org; Sat, 22 Dec 2007 16:46:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6CAq-0002Gj-M0 for ima@ietf.org; Sat, 22 Dec 2007 16:46:24 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6CAp-0000fF-22 for ima@ietf.org; Sat, 22 Dec 2007 16:46:24 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J6C7t-0007LZ-BF for ima@ietf.org; Sat, 22 Dec 2007 21:43:21 +0000 Received: from c-180-160-126.hh.dial.de.ignite.net ([62.180.160.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 21:43:21 +0000 Received: from nobody by c-180-160-126.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 21:43:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Sat, 22 Dec 2007 22:38:07 +0100 Organization: Lines: 20 Message-ID: References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <54F1EF31C09A40F72088C5CD@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-126.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] net-utf8 (was: Minutes from our Vancouver meeting) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann 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: > I consider the recurring controversy (if that is the > right term) about NEL / CRLF to be quite a major issue, > actually. Protocols based on XML or similar formats not depending on a concept for "line" aren't affected by net-utf8, it is for telnet and derived protocols, where a "line" is an essential idea, consequently CRLF is also essential. Nobody needs NEL in say whois, and if I'd want IRIS I'd know where to find it (certainly not in net-utf-8 ;-) I could quibble about HT not being as evil as net-utf8 claims, but that's really a minor issue: SMTP, netnews, EAI, etc. aren't supposed to drop the "W" in WSP only because net-utf8 recommends to avoid HT. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Dec 22 17:15: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 1J6CcZ-0000TQ-Eu; Sat, 22 Dec 2007 17:15:03 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J6CcY-0000Ni-7T for ima-confirm+ok@megatron.ietf.org; Sat, 22 Dec 2007 17:15:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6CcX-0000MQ-7K for ima@ietf.org; Sat, 22 Dec 2007 17:15:01 -0500 Received: from abenaki.wabanaki.net ([65.99.1.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6CcU-0001Bx-W7 for ima@ietf.org; Sat, 22 Dec 2007 17:15:01 -0500 Received: from eric-brunner-williamss-macbook.local (dpc67142250094.direcpc.com [67.142.250.94]) by abenaki.wabanaki.net (8.13.6/8.14.1) with ESMTP id lBMLcc6G069893; Sat, 22 Dec 2007 16:38:43 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <476D8C4A.5020708@nic-naa.net> Date: Sat, 22 Dec 2007 14:14:34 -0800 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] net-utf8 References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <54F1EF31C09A40F72088C5CD@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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 > Nobody needs NEL in say whois ... Frank, the spec for whois doesn't leave a lot to the imagination. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Dec 22 17:45: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 1J6D6U-0006DI-Rp; Sat, 22 Dec 2007 17:45:58 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J6D6T-0006Ct-N8 for ima-confirm+ok@megatron.ietf.org; Sat, 22 Dec 2007 17:45:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6D6T-0006Cl-DO for ima@ietf.org; Sat, 22 Dec 2007 17:45:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6D6T-0001n8-1D for ima@ietf.org; Sat, 22 Dec 2007 17:45:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J6D67-00070V-UX for ima@ietf.org; Sat, 22 Dec 2007 22:45:35 +0000 Received: from c-180-160-126.hh.dial.de.ignite.net ([62.180.160.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 22:45:35 +0000 Received: from nobody by c-180-160-126.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 22:45:35 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Sat, 22 Dec 2007 23:44:37 +0100 Organization: Lines: 12 Message-ID: References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <54F1EF31C09A40F72088C5CD@p3.JCK.COM> <476D8C4A.5020708@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-126.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] Re: net-utf8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Eric Brunner-Williams wrote: =20 > Frank, the spec for whois doesn't leave a lot to the imagination. At some point in time "we" need a better emulation of RFC 954 than (1032 + 3912), and net-utf8 is the missing piece of this puzzle ;-) The "we" might be RFCI (rfc-ignorant.org), or any folks interested in IDN. For now email addresses in whois databases won't be EAI addresses, same issue as for SoA, Netnews, etc. =20 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Dec 23 00:19: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 1J6JFO-0003Sx-VC; Sun, 23 Dec 2007 00:19:34 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J6JFO-0003Ss-JD for ima-confirm+ok@megatron.ietf.org; Sun, 23 Dec 2007 00:19:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6JFO-0003Sk-81 for ima@ietf.org; Sun, 23 Dec 2007 00:19:34 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6JFN-0006TU-Rz for ima@ietf.org; Sun, 23 Dec 2007 00:19:34 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 912A22580D2; Sun, 23 Dec 2007 06:19:30 +0100 (CET) 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 20546-05; Sun, 23 Dec 2007 06:19:24 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CBBA2580D1; Sun, 23 Dec 2007 06:19:24 +0100 (CET) Message-ID: <476DEFDB.5060201@alvestrand.no> Date: Sun, 23 Dec 2007 06:19:23 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Frank Ellermann Subject: Mailto: (Re: [EAI] Re: Minutes from our Vancouver meeting) References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Frank Ellermann skrev: > > | *** Resolution: Internationalization of Mailto: is > | within scope, because it is a requirement for the > | List-headers work. > > Interesting. I kind of hoped that mailto-bis would > be limited to fix mailto (for 3986, automagically > also 3987). With 2822upd entering the picture that > is not more as "impossible" as it used to be. But > I still think that mailto-I18N should be a second > (experimental) step after mailto-bis (PS) is ready. > That is also my impression; Martin hasn't indicated that he wants to take on the EAI work at the same time as the rest of what he's doing. So if mailto-bis rolls out (giving us a stable platform) without EAI extensions, we can take it from there (I think). Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 26 04:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7SZ1-0000vv-P2; Wed, 26 Dec 2007 04:28:35 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J7SZ0-0000qO-RZ for ima-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 04:28:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7SZ0-0000p7-FC for ima@ietf.org; Wed, 26 Dec 2007 04:28:34 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7SYz-0006Z2-Km for ima@ietf.org; Wed, 26 Dec 2007 04:28:34 -0500 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 lBQ9SIaA007887 for ; Wed, 26 Dec 2007 18:28:31 +0900 (JST) Received: (from localhost [172.18.4.61]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007122618281812870 for ; Wed, 26 Dec 2007 18:28:18 +0900 Date: Wed, 26 Dec 2007 18:28:18 +0900 (JST) Message-Id: <20071226.182818.59656380.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.2.53 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [EAI] need comment for downgrade document 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 Dear Implementors, please comment. I also implemented downgrading as a filter program. (about 1000 line perl program from scratch. It requires no dependency without perl-5.8.8 standard distribution.) >From my implementation, I updated the document as downgrade-05. And I'm preparing downgrade-06. Current changes are below: - removed "displaying downgraded message" related parts - Intro - Appendix - Examples - fixed examples: downgrading # entire is encoded by one RFC 2047 operation. # previous my example may have a bug, # before encoding, I separated an as s. Regards, -- # Please send emergency mail to . Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Dec 26 22:29: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 1J7jRT-00038y-Mb; Wed, 26 Dec 2007 22:29:55 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J7jRS-00038t-Td for ima-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 22:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7jRS-00038l-Hw for ima@ietf.org; Wed, 26 Dec 2007 22:29:54 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7jRQ-00070B-QE for ima@ietf.org; Wed, 26 Dec 2007 22:29:54 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1J7jRM-000MnR-OJ; Wed, 26 Dec 2007 22:29:52 -0500 Date: Wed, 26 Dec 2007 22:29:47 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: net-utf8 Message-ID: In-Reply-To: References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <54F1EF31C09A40F72088C5CD@p3.JCK.COM> <476D8C4A.5020708@nic-naa.net> 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: -100.0 (---------------------------------------------------) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Saturday, 22 December, 2007 23:44 +0100 Frank Ellermann wrote: > Eric Brunner-Williams wrote: > >> Frank, the spec for whois doesn't leave a lot to the >> imagination. > > At some point in time "we" need a better emulation of RFC 954 > than (1032 + 3912), and net-utf8 is the missing piece of this > puzzle ;-) Hmm. While I believe that, given its origins, RFC 954 was solidly tied to NVT and hence ASCII-in and ASCII-out, the author of 3912 deliberately or accidentally left that vague. I assume she did that one that sincere assumption that, given the many problems that develop when Whois is compared to today's expectations of it, it would be largely historic by now, presumably replaced by IRIS. I can't speak for Leslie, but I believe that replacement is the right outcome and that patching the Whois spec wouldn't accomplish a lot at this point, especially since at least one major registry has made it fairly clear that they would ignore any such patch if it ran counter to their current creative reading of the spec. In any event, introducing a discussion of Whois into the EAI discussion doesn't seem to help move anything --either a Whois revision, or the net-utf8 doc, or the EAI work itself-- forward. I should have a new version of the net-utf8 spec posted within the next 24 hours and assume that one will go to IETF Last Call. Once that process completes (if it does), if someone wants to try updating 3912, or convincing the author of 3912 to do so, I will wish you well. But, please, not on the EAI list. > The "we" might be RFCI (rfc-ignorant.org), or any folks > interested in IDN. For now email addresses in whois databases > won't be EAI addresses, same issue as for SoA, Netnews, etc. Yep. And, if you want a personal opinion, it would be unwise to change most of those contexts until after the EAI work is on the standards track (assuming that happens). Even then, I would hope that ICANN and/or the relevant registries would give much more careful consideration to the implications of addresses that cannot be read, and may or may not be able to be copied and pasted, than I think I have seen so far. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 27 01:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7m7M-0003UB-Ov; Thu, 27 Dec 2007 01:21:20 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J7m7K-0003NF-1t for ima-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 01:21:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7m7J-0003AS-Fo for ima@ietf.org; Thu, 27 Dec 2007 01:21:17 -0500 Received: from abenaki.wabanaki.net ([65.99.1.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7m7G-0000cs-SZ for ima@ietf.org; Thu, 27 Dec 2007 01:21:15 -0500 Received: from eric-brunner-williamss-macbook.local (dpc67142250094.direcpc.com [67.142.250.94]) by abenaki.wabanaki.net (8.13.6/8.14.1) with ESMTP id lBR5hhYL042398; Thu, 27 Dec 2007 00:43:46 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <47734442.2050401@nic-naa.net> Date: Wed, 26 Dec 2007 22:20:50 -0800 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Re: net-utf8 References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <54F1EF31C09A40F72088C5CD@p3.JCK.COM> <476D8C4A.5020708@nic-naa.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Frank Ellermann , 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 Saturday, 22 December, 2007 23:44 +0100 Frank Ellermann > wrote: > > >> Eric Brunner-Williams wrote: >> >> >>> Frank, the spec for whois doesn't leave a lot to the >>> imagination. >>> >> At some point in time "we" need a better emulation of RFC 954 >> than (1032 + 3912), and net-utf8 is the missing piece of this >> puzzle ;-) >> > > Hmm. While I believe that, given its origins, RFC 954 was > solidly tied to NVT and hence ASCII-in and ASCII-out, the author > of 3912 deliberately or accidentally left that vague. I assume > she did that one that sincere assumption that, given the many > problems that develop when Whois is compared to today's > expectations of it, it would be largely historic by now, > presumably replaced by IRIS. > > I can't speak for Leslie, but I believe that replacement is the > right outcome and that patching the Whois spec wouldn't > accomplish a lot at this point, especially since at least one > major registry has made it fairly clear that they would ignore > any such patch if it ran counter to their current creative > reading of the spec. > > In any event, introducing a discussion of Whois into the EAI > discussion doesn't seem to help move anything --either a Whois > revision, or the net-utf8 doc, or the EAI work itself-- forward. > I should have a new version of the net-utf8 spec posted within > the next 24 hours and assume that one will go to IETF Last Call. > Once that process completes (if it does), if someone wants to > try updating 3912, or convincing the author of 3912 to do so, I > will wish you well. But, please, not on the EAI list. > > >> The "we" might be RFCI (rfc-ignorant.org), or any folks >> interested in IDN. For now email addresses in whois databases >> won't be EAI addresses, same issue as for SoA, Netnews, etc. >> > > Yep. > > And, if you want a personal opinion, it would be unwise to > change most of those contexts until after the EAI work is on the > standards track (assuming that happens). Even then, I would > hope that ICANN and/or the relevant registries would give much > more careful consideration to the implications of addresses that > cannot be read, and may or may not be able to be copied and > pasted, than I think I have seen so far. > > john > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > > I've tried to kill this beast, viz http://www.imc.org/ietf-whois/mail-archive/msg00218.html, however Bob Braden opined that without whois:43 the world would ... well, authoritative things were writ from an ISC address in Marina del Rey to someone obviously lacking any clue, and the 3912 draft was so much more ... I still don't know. Then there was http://www3.ietf.org/proceedings/01aug/51-40.htm, but no consensus. The 954 spec was: C: [::printable::]\r\n S: .*\r\n Cheers, Eric _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Dec 27 18:06: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 1J81oH-0003vd-Qd; Thu, 27 Dec 2007 18:06:41 -0500 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1J81oG-0003vY-Oq for ima-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 18:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J81oG-0003vO-7H for ima@ietf.org; Thu, 27 Dec 2007 18:06:40 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J81oE-0003CP-8L for ima@ietf.org; Thu, 27 Dec 2007 18:06:40 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J81kV-00008Q-1y for ima@ietf.org; Thu, 27 Dec 2007 23:02:47 +0000 Received: from c-180-160-45.hh.dial.de.ignite.net ([62.180.160.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Dec 2007 23:02:47 +0000 Received: from nobody by c-180-160-45.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Dec 2007 23:02:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Dec 2007 23:54:42 +0100 Organization: Lines: 32 Message-ID: References: <542F3E5EA7D9D9E3EF36FAD5@[192.168.1.119]> <54F1EF31C09A40F72088C5CD@p3.JCK.COM> <476D8C4A.5020708@nic-naa.net> <47734442.2050401@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-45.hh.dial.de.ignite.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: -0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [EAI] OT: whois I18N and net-utf8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Eric Brunner-Williams wrote: > I've tried to kill this beast, viz=20 > http://www.imc.org/ietf-whois/mail-archive/msg00218.html, Blasphemous. "ENOPRIVACY" cannot shock Google users, I'm anyway not interested in phone numbers and other private data of folks (registrants) who can't fix "it" (whatever), the important data is AdminC / TechC, and the date of the registration (fresh domains are suspicious). > however Bob Braden opined that without whois:43 the world > would ...=20 Good, 0:1 in the IETF vs. Internet games. IRIS might be a good idea for registries and registrars, but not for users. > the 3912 draft was so much more ... I still don't know. Fortunately "they" missed RFC 1032 in their quest to make the Internet worse ;-) As long as whois.iana.org exists and ICANN follows the rules (their interpretation of RFC 1591) all is fine. Adding a public whois-frontend to IRIS should be simple. RFC 3912 and John's new unicode-escapes RFC can already send Unicode replies as ASCII, picking hex. NCRs is possible and probably the best solution for IRIS frontends (XML supports hex. NCRs), all that's missing is an RFC 2277 whois-upgrade based on net-utf8 for UTF-8 queries. Frank --=20 http://idn.icann.org/IDNAbis#RFCs_and_Drafts_related_to_Whois _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima