From jyee@afilias.info Wed May 4 08:21:14 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7D8E079E for ; Wed, 4 May 2011 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+HYsXt+Com1 for ; Wed, 4 May 2011 08:21:13 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0781BE06B6 for ; Wed, 4 May 2011 08:21:12 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QHdt1-0001UW-95 for ima@ietf.org; Wed, 04 May 2011 15:21:11 +0000 Received: from mail-gw0-f50.google.com ([74.125.83.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QHdt1-0002r5-8C for ima@ietf.org; Wed, 04 May 2011 15:21:11 +0000 Received: by gwj16 with SMTP id 16so437459gwj.9 for ; Wed, 04 May 2011 08:21:11 -0700 (PDT) Received: by 10.236.180.135 with SMTP id j7mr1488318yhm.309.1304522471042; Wed, 04 May 2011 08:21:11 -0700 (PDT) Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id x61sm547015yhn.48.2011.05.04.08.21.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 08:21:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joseph Yee In-Reply-To: <20110420.135247.258111822.fujiwara@jprs.co.jp> Date: Wed, 4 May 2011 11:21:08 -0400 Content-Transfer-Encoding: 7bit Message-Id: <83464E34-93EA-410C-B47D-D2BC382BFEF2@afilias.info> References: <4DA5BA17.2010003@dcrocker.net> <5D4512A4-F378-4CA8-806C-6D1DB14BE1B9@afilias.info> <20110420.135247.258111822.fujiwara@jprs.co.jp> To: fujiwara@jprs.co.jp X-Mailer: Apple Mail (2.1084) Cc: dcrocker@bbiw.net, ima@ietf.org Subject: Re: [EAI] rfc5336bis-09: Downgrade in Submission server X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:21:14 -0000 On 2011-04-20, at 12:52 AM, fujiwara@jprs.co.jp wrote: >> From: John C Klensin >>>> Specification of this process and its results is outside the >>>> scope of this document. >>>> >>> >>> Personally, I like this sentence. I think it's good to add it >>> to the end of bulletin 2. Thoughts? >> >> Concur. >> >> So, at the risk of causing more work for myself, let me suggest >> the following: >> >> (i) We remove the offending "reminder" sentence from #2 and >> substitute the above sentence (or some editor-chosen variation). >> >> (ii) An EAI-related version/revision of 4409 has always been an >> EAI task if the WG concludes it is necessary. Let's do that, >> not with the intent of adding detailed EAI-specific provisions, >> but adding a paragraph that explicitly indicates that >> conversions of character sets or encodings are within the scope >> of things that MSAs can do. If that is handled as a >> clarification --which I think it would be-- than it could be >> done as a revision in grade or even as part of a full standard >> 4409bis (whether that document were processed by EAI or YAM >> would be a matter of some indifference to me). >> >> Does that make sense? > > I agree. > > -- > Kazunori Fujiwara, JPRS Agree to both suggestions. Joseph From yaojk@cnnic.cn Wed May 11 20:59:45 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9339AE07F4 for ; Wed, 11 May 2011 20:59:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -100.043 X-Spam-Level: X-Spam-Status: No, score=-100.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faH6Y-h7zjXr for ; Wed, 11 May 2011 20:59:44 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id DD6D8E0691 for ; Wed, 11 May 2011 20:59:43 -0700 (PDT) Received: (eyou send program); Thu, 12 May 2011 11:59:35 +0800 Message-ID: <505172775.10794@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 12 May 2011 11:59:35 +0800 Message-ID: <0E1EF2A34222483A89A170233CE2DC29@LENOVO47E041CF> From: "Jiankang YAO" To: References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn><503833016.15024@cnnic.cn> <503865491.01228@cnnic.cn> Date: Thu, 12 May 2011 11:59:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: ima@ietf.org Subject: Re: [EAI] (Dave's detail suggestion )Re: The scenario favoring"uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 03:59:45 -0000 QmFzZWQgb24gRGF2ZSdzIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucywNCg0KSSBwcm9wb3NlIHRo ZSBmb2xsb3dpbmcgY2hhbmdlcyB0byByZmM1MzM2YmlzOg0KDQoNCjEgKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiog ICAgICAgICANCnRoZSBhYm5mIG9mIG1haWxib3ggaXMgcHJvcG9zZWQgYmVsb3c6DQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCiBNYWlsYm94ID0gTG9jYWwtcGFydCAiQCIgKCBEb21haW4gLyBh ZGRyZXNzLWxpdGVyYWwgKQ0KICAgICAgICAgICAgICA7IEluaGVyaXQgTWFpbGJveCBEZWZpbml0 aW9uIGZyb20gUkZDIDUzMjEsIFNlY3Rpb24gNC4xLjINCiAgICAgICAgICAgICAgDQogICAgICAg ICAgIExvY2FsLXBhcnQgPSBEb3Qtc3RyaW5nIC8gUXVvdGVkLXN0cmluZw0KICAgICAgICAgICAg ICA7IEluaGVyaXQgTG9jYWwtcGFydCBEZWZpbml0aW9uIGZyb20gUkZDIDUzMjEsIFNlY3Rpb24g NC4xLjINCg0KICAgICAgICAgICBEb3Qtc3RyaW5nICAgICA9IEF0b20gKigiLiIgIEF0b20pDQog ICAgICAgICAgICAgIDsgSW5oZXJpdCBEb3Qtc3RyaW5nIERlZmluaXRpb24gZnJvbSBSRkMgNTMy MSwgU2VjdGlvbiA0LjEuMg0KDQogICAgICAgICAgUXVvdGVkLXN0cmluZyAgPSA8RGVmaW5lZCBp biBTZWN0aW9uIDQuMS4yIG9mIFJGQyA1MzIxPg0KDQoNCiAgICAgICAgICAgQXRvbSAgICAgICAg ICAgPSAxKmF0ZXh0DQogICAgICAgICAgICAgICAgOyBJbmhlcml0IEF0b20gRGVmaW5pdGlvbiBm cm9tIFJGQyA1MzIxLCBTZWN0aW9uIDQuMS4yDQoNCiAgICAgICAgICBhdGV4dCAgID0vICBVVEY4 LW5vbi1hc2NpaQ0KICAgICAgICAgICAgIDsgZXh0ZW5kIHRoZSBkZWZpbnRpb24gb2YgYXRleHQg aW4gUkZDNTMyMSwgc2VjdGlvbiA0LjEuMiANCiAgICAgICAgICAgIA0KICAgICAgICAgICBVVEY4 LW5vbi1hc2NpaSA9IDxTZWUgIFNlY3Rpb24gNC4xIG9mIFJGQzUzMzViaXM+DQoNCiAgICAgICAg ICAgRG9tYWluICAgICAgICAgPSBzdWItZG9tYWluICooIi4iIHN1Yi1kb21haW4pDQogICAgICAg ICAgICAgICAgOyBJbmhlcml0IERvbWFpbiBEZWZpbml0aW9uIGZyb20gUkZDIDUzMjEsIFNlY3Rp b24gNC4xLjINCg0KICAgICAgICAgICAgc3ViLWRvbWFpbiAgICAgPSAvIFUtbGFiZWwNCiAgICAg ICAgICAgICAgOyBleHRlbmQgdGhlIGRlZmludGlvbiBvZiBzdWItZG9tYWluIGluIFJGQzUzMjEs IHNlY3Rpb24gNC4xLjIgDQoNCiAgICAgICAgICAgIFUtbGFiZWwgICA9IDxzZWUgU2VjdGlvbiAy LjMuMi4xIG9mIFJGQzU4OTAgPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoyICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNClRoZSBzZWN0aW9u IDMuNy4zICBpcyBzdXBwb3NlZCB0byBiZSB1cGRhdGVkIHRvIHRoZSBmb2xsb3dpbmcNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQoNCjMuNy4zIFRyYWNlIEluZm9ybWF0aW9uDQoNCg0KICAgRm9yIHRoZSB0 cmFjZSBpbmZvcm1hdGlvbiBbUkZDNTMyMV0sIHRoaXMgbWVtbyB1cGRhdGVzICB0aGUgcmV0dXJu IHBhdGggbGluZSBbUkZDNTMyMV0gYW5kIHRoZSB0aW1lIHN0YW1wIGxpbmUgZm9ybWFsbHkgZGVm aW5lZCBhcyBmb2xsb3dzOg0KDQogICBSZXR1cm4tcGF0aC1saW5lID0gIlJldHVybi1QYXRoOiIg RldTIFJldmVyc2UtcGF0aCBDUkxGDQogICAgOyBJbmhlcml0IFJldHVybi1wYXRoLWxpbmUgZGVm aW50aW9uIGZyb20gU2VjdGlvbiA0LjQgb2YgUkZDIDUzMjENCiAgICA7IFJldmVyc2UtcGF0aCBt YXkgaW5jbHVkZSB0aGUgaW50ZXJuYXRpb25hbGl6ZWQgZG9tYWluIG5hbWUgd2l0aCB0aGUgVS1s YWJlbCBmb3JtIA0KDQogIFRpbWUtc3RhbXAtbGluZSA9ICJSZWNlaXZlZDoiIEZXUyBTdGFtcCBD UkxGDQogICAgOyBSZXBsYWNlcyBUaW1lLXN0YW1wLWxpbmUgaW4gU2VjdGlvbiA0LjQgb2YgUkZD IDUzMjENCiAgICA7IFN0YW1wIG1heSBpbmNsdWRlIHRoZSAnRm9yJyBjbGF1c2Ugd2hlcmUgdGhl IGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBuYW1lIHdpdGggdGhlIFUtbGFiZWwgZm9ybSBtYXkg YmUgdXNlZC4NCg0KDQpFeGNlcHQgaW4gdGhlICdGb3InIGNsYXVzZSBhbmQgJ1JldmVyc2UtcGF0 aCcgdmFsdWUgd2hlcmUNCiAgIGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBuYW1lIHdpdGggdGhl IFUtbGFiZWwgZm9ybSBNQVkgYmUgdXNlZCwNCiAgIGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBu YW1lcyBpbiBSZWNlaXZlZCBmaWVsZHMgTVVTVCBiZSB0cmFuc21pdHRlZA0KICAgaW4gdGhlIGZv cm0gb2YgQS1sYWJlbHMuICBUaGUgcHJvdG9jb2wgdmFsdWUgb2YgdGhlIFdJVEggY2xhdXNlIHdo ZW4NCiAgIHRoaXMgZXh0ZW5zaW9uIGlzIHVzZWQgaXMgb25lIG9mIHRoZSBVVEY4U01UUGJpcyB2 YWx1ZXMgc3BlY2lmaWVkIGluDQogICB0aGUgIklBTkEgQ29uc2lkZXJhdGlvbnMiIHNlY3Rpb24g b2YgdGhpcyBkb2N1bWVudC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoN CjMgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCg0KDQp0aGUgIFZFUklGWSAoVlJGWSkgYW5kIEVYUEFORCAoRVhQTikg Y29tbWFuZCBzeW50YXhlcyBhcmUgY2hhbmdlZCB0bzoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCiAgICAgdnJmeSA9ICJWUkZZIiBTUCBTdHJpbmcNCiAgICAgWyBTUCAiVVRGOFNNVFBiaXMi IF0gQ1JMRg0KICAgICA7IFN0cmluZyBtYXkgaW5jbHVkZSBVVEYtOCBjaGFyYWN0ZXJzDQoNCiAg IGV4cG4gPSAiRVhQTiIgU1AgU3RyaW5nDQogICAgIFsgU1AgIlVURjhTTVRQYmlzIiBdIENSTEYN CiAgICAgOyBTdHJpbmcgbWF5IGluY2x1ZGUgVVRGLTggY2hhcmFjdGVycw0KDQoNCg0KDQogIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQphbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoN ClRoYW5rcyBhIGxvdC4NCg0KDQpKaWFua2FuZyBZYW8NCg0KDQoNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4NClRv OiA8ZGNyb2NrZXJAYmJpdy5uZXQ+DQpDYzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2Rh eSwgQXByaWwgMjcsIDIwMTEgODo1MSBBTQ0KU3ViamVjdDogW0VBSV0gKERhdmUncyBkZXRhaWwg c3VnZ2VzdGlvbiApUmU6IFRoZSBzY2VuYXJpbyBmYXZvcmluZyJ1TWFpbGJveCI/DQoNCg0KPiB0 aGFua3MgYSBsb3QgZm9yIERhdmUncyBkZXRhaWwgQUJORiBzdWdnZXN0aW9uLg0KPiBIb3BlIHRv IHNlZSBtb3JlIGNvbW1lbnRzIHRvIGl0IGZyb20gdGhlIFdHLg0KPiANCj4gSmlhbmthbmcgWWFv DQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAiRGF2ZSBDUk9D S0VSIiA8ZGhjMkBkY3JvY2tlci5uZXQ+DQo+IENjOiA8aW1hQGlldGYub3JnPg0KPiBTZW50OiBU dWVzZGF5LCBBcHJpbCAyNiwgMjAxMSAxMTo0OSBQTQ0KPiBTdWJqZWN0OiBSZTogW0VBSV0gVGhl IHNjZW5hcmlvIGZhdm9yaW5nICJ1TWFpbGJveCI/DQo+IA0KPiANCj4+IEZvbGtzLA0KPj4gDQo+ PiANCj4+IE9uIDQvMjUvMjAxMSAxMDozNiBQTSwgSmlhbmthbmcgWUFPIHdyb3RlOg0KPj4+IEkg dGhpbmsgdGhhdCB0aGUgY29yZSBpc3N1ZSBsZWZ0IGZvciB0aGUgY29yZSByZmNzIGlzIEFCTkYg c3ludGF4Lg0KPj4+DQo+Pj4gSSBob3BlIHRoYXQgd2UgY2FuIGhhdmUgYSBjbGVhciBjb25jbHVz aW9uIG9yIHNvbHV0aW9uIGZvciBBQk5GIHN5bnRheCBzb29uLg0KPj4gDQo+PiBJIGhhdmUgbG9v a2VkIG92ZXIgdGhlIEFCTkYgaW4gcmZjNTMzNWJpcyBhbmQgdGhpcyBtZXNzYWdlIGNvbnRhaW5z IGEgcHJvcG9zYWwgDQo+PiBmb3IgYSBtdWNoIHNpbXBsZXIgYXBwcm9hY2guDQo+PiANCj4+IFRo ZSBjdXJyZW50IHJmYzUzMzViaXMgZHJhZnQgc3BlY2lmaWVzIGV4dGVuc2l2ZSBBQk5GLCBpbmNs dWRpbmcgYWRkaXRpb25zIG9mIA0KPj4gInUiIHJ1bGVzLCBpbiBTZWN0aW9uczoNCj4+IA0KPj4g ICAgMy4zLiAgRXh0ZW5kZWQgTWFpbGJveCBBZGRyZXNzIFN5bnRheA0KPj4gDQo+PiAgICAzLjcu My4gIFRyYWNlIEluZm9ybWF0aW9uDQo+PiANCj4+ICAgIDMuNy40LjIuICBWUkZZIGFuZCBFWFBO IENvbW1hbmRzIGFuZCB0aGUgVVRGOFNNVFBiaXMgUGFyYW1ldGVyDQo+PiANCj4+IFRoZXNlIHNl Y3Rpb25zIGhhdmUgYSBsYXJnZSBudW1iZXIgb2YgQUJORiBydWxlcyB0aGF0IGFkZCBVVEYtOCBz dXBwb3J0IA0KPj4gc2VsZWN0aXZlbHkgYW5kIGluIHRoZSAiaGlnaGVyLWxldmVsIiBydWxlcywg cmF0aGVyIHRoYW4gdGhlIHVuZGVybHlpbmcsIGJhc2ljIA0KPj4gcnVsZXMuDQo+PiANCj4+IFRv IGZvbGxvdyB0aGUgZGlmZmVyZW50IGFuZCBzaW1wbGVyIGFwcHJvYWNoIHRoYXQgdGhlIEVBSSB3 b3JraW5nIGdyb3VwIGhhcyBub3cgDQo+PiBhcHByb3ZlZCBmb3IgcmZjNTMzNWJpcywgSSBwcm9w b3NlIGFkZGluZyBVVEYtOCBzdXBwb3J0IHRvIHVuZGVybHlpbmcgKGJhc2ljKSANCj4+IHJ1bGVz Lg0KPj4gDQo+PiBIZXJlIGFyZSB0aGUgb25seSBBQk5GIGNoYW5nZXMgdGhhdCBhcHBlYXIgdG8g YmUgbmVlZGVkLg0KPj4gDQo+PiBGcm9tIHJmYzUzMzViaXM6DQo+PiANCj4+ICAgIFVURjgtZW5o YW5jZW1lbnQgID0gICBVVEY4LTIgLyBVVEY4LTMgLyBVVEY4LTQNCj4+ICAgICAgICAgICAgICAg ICAgICAgICAgOyBpbmNvcnBvcmF0ZSBmcm9tIHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+PiAN Cj4+ICAgIFZDSEFSICAgPS8gIFVURjgtbm9uLWFzY2lpDQo+PiAgICAgICAgICAgICAgICAgICAg ICAgIDsgaW5jb3Jwb3JhdGUgZnJvbSByZmM1MzM1YmlzLCBTZWN0aW9uIDIuMQ0KPj4gDQo+PiAg ICBjdGV4dCAgID0vICBVVEY4LWVuaGFuY2VtZW50DQo+PiAgICAgICAgICAgICAgICAgICAgICAg IDsgaW5jb3Jwb3JhdGUgZnJvbSByZmM1MzM1YmlzLCBTZWN0aW9uIDIuMQ0KPj4gDQo+PiAgICBh dGV4dCAgID0vICBVVEY4LWVuaGFuY2VtZW50DQo+PiAgICAgICAgICAgICAgICAgICAgICAgIDsg aW5jb3Jwb3JhdGUgZnJvbSByZmM1MzM1YmlzLCBTZWN0aW9uIDIuMQ0KPj4gDQo+PiAgICBxdGV4 dCAgID0vICBVVEY4LWVuaGFuY2VtZW50DQo+PiAgICAgICAgICAgICAgICAgICAgICAgIDsgaW5j b3Jwb3JhdGUgZnJvbSByZmM1MzM1YmlzLCBTZWN0aW9uIDIuMQ0KPj4gDQo+PiAgICB0ZXh0ICAg ID0vICBVVEY4LWVuaGFuY2VtZW50DQo+PiAgICAgICAgICAgICAgICAgICA7IG5vdGUgdGhhdCB0 aGlzIHVwZ3JhZGVzIHRoZSBib2R5IHRvIFVURi04DQo+PiAgICAgICAgICAgICAgICAgICAgICAg IDsgaW5jb3Jwb3JhdGUgZnJvbSByZmM1MzM1YmlzLCBTZWN0aW9uIDIuMQ0KPj4gDQo+PiAgICB7 eyBob3cgdG8gYWRkIElETiB0byB0aGlzPyB9fQ0KPj4gICAgZG9tYWluICA9ICAgZG90LWF0b20g LyBkb21haW4tbGl0ZXJhbCAvIG9icy1kb21haW4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAg OyBpbmNvcnBvcmF0ZSBmcm9tIHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+PiANCj4+IEFkZDoN Cj4+IA0KPj4gICAgcXVvdGVkLXBhaXJTTVRQICA9LyAlZDkyIFVURjgtZW5oYW5jZW1lbnQNCj4+ IA0KPj4gICAgcXRleHRTTVRQICAgICAgICA9LyAgVVRGOC1lbmhhbmNlbWVudA0KPj4gDQo+PiAN Cj4+IA0KPj4gQWxsIG90aGVyIEFCTkYgcnVsZXMgaW4gcmZjNTMzNWJpcyB3b3VsZCBiZSByZW1v dmVkLg0KPj4gDQo+PiANCj4+IEluIHRlcm1zIG9mIHRoZSBlZmZlY3Qgb2YgZG9pbmcgdGhpcywg aW4gcmZjNTMzNWJpcywgaGVyZSBpcyBhbiBleGFtcGxlOg0KPj4gDQo+PiA+IDMuMy4gIEV4dGVu ZGVkIE1haWxib3ggQWRkcmVzcyBTeW50YXgNCj4+ID4NCj4+ID4gICAgdU1haWxib3ggPSB1TG9j YWwtcGFydCAiQCIgKCB1RG9tYWluIC8gYWRkcmVzcy1saXRlcmFsICkNCj4+ID4gICAgIDsgUmVw bGFjZSBNYWlsYm94IGluIFJGQyA1MzIxLCBTZWN0aW9uIDQuMS4yDQo+PiANCj4+IFVzZSBleGlz dGluZyA8TWFpbGJveD4gZGVmaW5pdGlvbiBmcm9tIFJGQyA1MzIxLCB3aXRoIHRoZSA8YXRleHQ+ IGVuaGFuY2VtZW50IA0KPj4gZnJvbSBhYm92ZS4gIFRoaXMgY292ZXJzIFVURi04IGluIExvY2Fs LXBhcnQuDQo+PiANCj4+IElETiBoYW5kbGVzIFVURi04IGluIHRoZSBEb21haW4uIChOb3RlIHRo YXQgdGhlIHNwZWNpZmljIGRldGFpbHMgZm9yIHNwZWNpZnlpbmcgDQo+PiB0aGlzIGluIHJmYzUz MzViaXMgaXMgbm90IGZ1bGx5IHJlc29sdmVkOyBpdCBuZWVkcyB0byBiZSByZXNvbHZlZCB0aGUg c2FtZSB3YXkgDQo+PiBmb3IgdGhhdCBzcGVjaWZpY2F0aW9uIGFuZCBmb3IgdGhpcyBvbmUuKQ0K Pj4gDQo+PiBUaGVyZWZvcmUgdUxvY2FsLXBhcnQgYW5kIHVEb21haW4gYXJlIG5vdCBuZWVkZWQ7 IG5vbmUgb2YgdGhlaXIgc3VwcG9ydGluZyBydWxlcyANCj4+IGFyZSBuZWVkZWQuDQo+PiANCj4+ IFNpbWlsYXIgc2ltcGxpZmljYXRpb25zIHRha2UgcGxhY2UgZm9yIHRoZSBvdGhlciBoaWdoZXIt bGV2ZWwgY29uc3RydWN0Lg0KPj4gDQo+PiBkLw0KPj4gLS0gDQo+PiANCj4+ICAgRGF2ZSBDcm9j a2VyDQo+PiAgIEJyYW5kZW5idXJnIEludGVybmV0V29ya2luZw0KPj4gICBiYml3Lm5ldA0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IElNQSBt YWlsaW5nIGxpc3QNCj4+IElNQUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pbWENCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= From klensin@jck.com Sun May 15 09:28:18 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A59E06CB for ; Sun, 15 May 2011 09:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GJ8KDQaphK2 for ; Sun, 15 May 2011 09:28:18 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id E1726E068C for ; Sun, 15 May 2011 09:28:17 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QLeAt-000FUA-MS; Sun, 15 May 2011 12:28:11 -0400 Date: Sun, 15 May 2011 12:28:11 -0400 From: John C Klensin To: EAI WG list , IDNABIS WG list 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 Cc: Paul Hoffman Subject: [EAI] Internationalization Terminlogy X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: apps-discuss@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 16:28:19 -0000 Hi. If you have any significant interest in internationalization, and particular terminology used about it in the IETF, please have a look at draft-ietf-appsawg-rfc3435bis-00. Paul and I have several editorial and fine-tuning comments queued up, but are looking for more comments before we submit another draft and ask the Apps Area WG Chairs to generate a Last Call within that WG. In other words, your last and best opportunity to submit effective comments is now. We are particularly interested in comments about what has been left out that is relevant and important. Comments about definitions we have gotten wrong are also important. FWIW, we are determined to keep focus on what the title suggests: internationalization terminology used in the IETF (and in IETF protocol work in particular). Unless there is strong demand in the community to change goals, we do not want to expand this document into a general discussion of either i18n/l10n issues that includes ones that the IETF has not addressed and is never likely to address, nor a discussion of character set terminology that has not been needed for IETF work, etc. Note for EAI participants: It is my hope that EAI documents will be consistent with these definitions and will, where appropriate, reference this document rather than inventing definitions of their own. Note for IDNABIS participants: Note that this document does not alter, or even repeat, any IDNA terminology. IDNA-specific terms are simply listed and cross-referenced to RFC 5890. Substantive comments to apps-discuss@ietf.org please; editorial ones to Paul and myself. thanks, john From jfc@morfin.org Sun May 15 16:27:21 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB195E0707; Sun, 15 May 2011 16:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2imWeY4R2Sg; Sun, 15 May 2011 16:27:21 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0B3E0700; Sun, 15 May 2011 16:27:21 -0700 (PDT) Received: from 77.30-227-89.dsl.completel.net ([89.227.30.77]:53225 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QLkiV-0002l9-DW; Sun, 15 May 2011 16:27:19 -0700 Message-Id: <7.0.1.0.2.20110515191953.07211fe8@morfin.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 16 May 2011 01:27:18 +0200 To: apps-discuss@ietf.org,EAI WG list , IDNABIS WG list From: "J-F C. Morfin" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sun, 15 May 2011 17:51:21 -0700 Cc: Paul Hoffman Subject: Re: [EAI] Internationalization Terminlogy X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 23:27:21 -0000 John, Good work. I have just searched the text for some words. I note that: - "globalization" is missing which is embarassing as Unicode uses to say (if I am correct) globalization = internationalization + localization + language tagging. - "langtag" term is missing, so is their IANA table (largest by far IANA file). RFC 5646 is named. RFC 4647 is quoted, but not explained, so "language filtering" is not alluded to. - "linguistic diversity" is missing. Not an IETF word but the IETF targets its support? - "majuscules" are named, but uncorrectly explained: in latin languages, at least, an upper case may be a majuscule, but a majuscule may not be printed as an upper case, or stays a majuscule even if incorrectly printed as a lower case. - "plurilingual" is not quoted which is different from multilingual? - "linguistic independance" is not alluded to - ex. using digital codes. - "orthotypograpy" is missing in IETF jfc At 18:28 15/05/2011, John C Klensin wrote: >Hi. > >If you have any significant interest in internationalization, >and particular terminology used about it in the IETF, please >have a look at draft-ietf-appsawg-rfc3435bis-00. Paul and I >have several editorial and fine-tuning comments queued up, but >are looking for more comments before we submit another draft and >ask the Apps Area WG Chairs to generate a Last Call within that >WG. In other words, your last and best opportunity to submit >effective comments is now. > >We are particularly interested in comments about what has been >left out that is relevant and important. Comments about >definitions we have gotten wrong are also important. > >FWIW, we are determined to keep focus on what the title >suggests: internationalization terminology used in the IETF (and >in IETF protocol work in particular). Unless there is strong >demand in the community to change goals, we do not want to >expand this document into a general discussion of either >i18n/l10n issues that includes ones that the IETF has not >addressed and is never likely to address, nor a discussion of >character set terminology that has not been needed for IETF >work, etc. > >Note for EAI participants: It is my hope that EAI documents will >be consistent with these definitions and will, where >appropriate, reference this document rather than inventing >definitions of their own. > >Note for IDNABIS participants: Note that this document does not >alter, or even repeat, any IDNA terminology. IDNA-specific >terms are simply listed and cross-referenced to RFC 5890. > >Substantive comments to apps-discuss@ietf.org please; editorial >ones to Paul and myself. > >thanks, > john > >_______________________________________________ >Idna-update mailing list >Idna-update@alvestrand.no >http://www.alvestrand.no/mailman/listinfo/idna-update From dhc2@dcrocker.net Mon May 23 20:04:06 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE45E07CD for ; Mon, 23 May 2011 20:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6MfuVsJabFY for ; Mon, 23 May 2011 20:04:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F4E06B2 for ; Mon, 23 May 2011 20:04:04 -0700 (PDT) Received: from [192.168.1.7] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4O33u8A022011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 20:04:02 -0700 Message-ID: <4DDB2010.7090400@dcrocker.net> Date: Mon, 23 May 2011 20:03:44 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jiankang YAO References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn><503833016.15024@cnnic.cn> <503865491.01228@cnnic.cn> <505172775.10794@cnnic.cn> In-Reply-To: <505172775.10794@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 23 May 2011 20:04:02 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] (Dave's detail suggestion )Re: The scenario favoring"uMailbox"? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 03:04:06 -0000 On 5/11/2011 8:59 PM, Jiankang YAO wrote: > I propose the following changes to rfc5336bis: It is troubling that there have been no responses to your proposal, for over one month. This should raise a question about whether there is sufficient community interest in this work. > 1 *********************************************************************** > the abnf of mailbox is proposed below: If the details from one specification are repeated in another, this creates an opportunity for error. Mixing the repeated specification in with new error also makes it more difficult to find the rules that are new. It is better to cite the older details than to repeat them. The argument that I have heard to justify the repetition is saving the reader from having to refer back to the earlier specification. This justification is based on the assumption that the reader is not going to be required to be familiar with the earlier specification for other reasons. In the case of EAI, the reader is required to be familiar with RFC 5321. So the repetition of some rules does not really save the reader any interesting amount of effort, in my opinion. So I suggest: ---------- Imported from RFC 5321, Section 4.1.2: Mailbox Local-part Dot-string Quoted-string Domain Atom Imported from RFC 5335bis, Section 4.1: UTF8-non-ascii Imported from RFC 5890, Section 2.3.2.1: U-label Extended from RFC 5321, Section 4.1.2: atext =/ UTF8-non-ascii sub-domain = / U-label ---------- However, note that none of the first set of rules (from RFC 5321, Section 4.1.2) is actually used elsewhere in this specification. Hence, it does not make much sense to import or repeat them. I believe that what is meant, when referring to them, is to help the reader understand that and are used by these other rules. I believe it will be more helpful to have text that explains this, rather than to cite rules that are not used in this document. > ----------------------------------------------------------------------------------- > > > 2 ****************************************** > > > The section 3.7.3 is supposed to be updated to the following > > > -------------------------------------------------------------------- > > > 3.7.3 Trace Information > If this section is going to re-define specific, existing components, from RFC 5321, then it should only define the parts that are different or new. Again, it should not repeat the full specification. > For the trace information [RFC5321], this memo updates the return path line [RFC5321] and the time stamp line formally defined as follows: > > Return-path-line = "Return-Path:" FWS Reverse-path CRLF > ; Inherit Return-path-line defintion from Section 4.4 of RFC 5321 > ; Reverse-path may include the internationalized domain name with the U-label form (I believe Reverse-path is defined in Section 4.1.2.) This is not additional specification, because the existing definition's use of Mailbox merely uses the new and enhanced definition of sub-domain, from above. Hence, what might be needed is merely some text that points out this fact to the reader, rather than anything that tries to look like a specification. > Time-stamp-line = "Received:" FWS Stamp CRLF > ; Replaces Time-stamp-line in Section 4.4 of RFC 5321 ) > ; Stamp may include the 'For' clause where the internationalized domain name > with the U-label form may be used. This is not additional specification, because the existing definition's use of Mailbox merely uses the new and enhanced definition of sub-domain, from above. Hence, what might be needed is merely some text that points out this fact to the reader, rather than anything that tries to look like a specification. In addition: >>> From rfc5335bis: >>> >>> UTF8-enhancement = UTF8-2 / UTF8-3 / UTF8-4 >>> ; incorporate from rfc5335bis, Section 2.1 >>> >>> VCHAR =/ UTF8-non-ascii >>> ; incorporate from rfc5335bis, Section 2.1 >>> >>> ctext =/ UTF8-enhancement >>> ; incorporate from rfc5335bis, Section 2.1 >>> >>> atext =/ UTF8-enhancement >>> ; incorporate from rfc5335bis, Section 2.1 >>> >>> qtext =/ UTF8-enhancement >>> ; incorporate from rfc5335bis, Section 2.1 >>> >>> text =/ UTF8-enhancement >>> ; note that this upgrades the body to UTF-8 >>> ; incorporate from rfc5335bis, Section 2.1 >>> >>> {{ how to add IDN to this? }} >>> domain = dot-atom / domain-literal / obs-domain >>> ; incorporate from rfc5335bis, Section 2.1 >>> >>> Add: >>> >>> quoted-pairSMTP =/ %d92 UTF8-enhancement >>> >>> qtextSMTP =/ UTF8-enhancement I see that most of the enhanced rules that I suggested are not included in your proposal. Please explain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From yaojk@cnnic.cn Tue May 24 00:30:20 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A90E06E1 for ; Tue, 24 May 2011 00:30:20 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.51 X-Spam-Level: X-Spam-Status: No, score=-99.51 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exzAkIhefHti for ; Tue, 24 May 2011 00:30:19 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 09CA3E06DF for ; Tue, 24 May 2011 00:30:17 -0700 (PDT) Received: (eyou send program); Tue, 24 May 2011 15:30:16 +0800 Message-ID: <506222216.09892@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 24 May 2011 15:30:16 +0800 Message-ID: <0F62D3A719594A7FB03F56B8FBF25C87@LENOVO47E041CF> From: "Jiankang YAO" To: References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn><503833016.15024@cnnic.cn> <503865491.01228@cnnic.cn> <505172775.10794@cnnic.cn> <506206245.14647@cnnic.cn> Date: Tue, 24 May 2011 15:30:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: ima@ietf.org Subject: Re: [EAI] (Dave's detail suggestion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 07:30:20 -0000 RGVhciBEYXZlLA0KDQogICB0aGFua3MgYSBsb3QgZm9yIHlvdXIga2luZCByZXNwb25zZS4NCiAg TW9yZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQoNCkppYW5rYW5nIFlhbw0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhdmUgQ1JPQ0tFUiIgPGRoYzJAZGNyb2NrZXIu bmV0Pg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4NCkNjOiA8aW1hQGlldGYu b3JnPg0KU2VudDogVHVlc2RheSwgTWF5IDI0LCAyMDExIDExOjAzIEFNDQpTdWJqZWN0OiBSZTog W0VBSV0gKERhdmUncyBkZXRhaWwgc3VnZ2VzdGlvbiApUmU6IFRoZSBzY2VuYXJpbyBmYXZvcmlu ZyJ1TWFpbGJveCI/DQoNCg0KPiANCj4gT24gNS8xMS8yMDExIDg6NTkgUE0sIEppYW5rYW5nIFlB TyB3cm90ZToNCj4+IEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMgdG8gcmZjNTMzNmJp czoNCj4gDQo+IEl0IGlzIHRyb3VibGluZyB0aGF0IHRoZXJlIGhhdmUgYmVlbiBubyByZXNwb25z ZXMgdG8geW91ciBwcm9wb3NhbCwgZm9yIG92ZXIgb25lIA0KPiBtb250aC4gDQo+DQoNCk15IGxh c3QgbWVzc2FnZSBzZW50IGlzIG9uIDEyIE1heS4gVGhlcmUgaGFzIGFyb3VuZCAyIHdlZWtzLg0K DQo+DQo+IFRoaXMgc2hvdWxkIHJhaXNlIGEgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0aGVyZSBp cyBzdWZmaWNpZW50IGNvbW11bml0eSANCj4gaW50ZXJlc3QgaW4gdGhpcyB3b3JrLg0KPiANCg0K SSBoYXZlIGEgZGlmZmVyZW50IHZpZXcgYWJvdXQgaXQuDQoNClRoZSBXRyBkZWNpZGVkIHRvIGFk b3B0IHRoZSBBQk5GIHN0eWxlIHNhbWUgb3Igc2ltaWxhciB0byB5b3VyIHN1Z2dlc3Rpb24uDQpT byBJIHRoaW5rIHRoYXQgbW9zdCBXRyBtZW1iZXJzIGFyZSB3YWl0aW5nIGZvciB5b3VyICJhdXRo b3JpdGF0aXZlIiByZXNwb25zZS4NCg0KT24gdGhlIG90aGVyIGhhbmQsIHRoZSBXRyBoYXZlIHJl YWNoZWQgbWFueSBjb25jbHVzaW9ucyBvciByZXN1bHRzLCBhbmQgc29sdmVkIHRoZSBrZXkgaXNz dWVzLg0KVGhlIGN1cnJlbnQgZWRpdGluZyB3b3JrIGlzIG1vcmUgb3IgbGVzcyBqdXN0ICJlZGl0 aW5nIG9yIHJlZmluaW5nIi4NCkkgcmVtZW1iZXIgdGhhdCBTaGF3biBzYWlkIHRoYXQgdGhlIGlt cGxlbWVudGF0aW9uIHdvcmsgb2YgRUFJIHdpbGwga2VlZXAgc2FtZSBvciBzaW1pbGFyIGluIHNw aXRlIG9mIHRoYXQgaG93IHdlIGNoYW5nZSB0aGUgQUJORiBzdHlsZS4NCg0KDQoNCj4gDQo+PiAx ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+PiB0aGUgYWJuZiBvZiBtYWlsYm94IGlzIHByb3Bvc2VkIGJlbG93 Og0KPiANCj4gSWYgdGhlIGRldGFpbHMgZnJvbSBvbmUgc3BlY2lmaWNhdGlvbiBhcmUgcmVwZWF0 ZWQgaW4gYW5vdGhlciwgdGhpcyBjcmVhdGVzIGFuIA0KPiBvcHBvcnR1bml0eSBmb3IgZXJyb3Iu ICBNaXhpbmcgdGhlIHJlcGVhdGVkIHNwZWNpZmljYXRpb24gaW4gd2l0aCBuZXcgZXJyb3IgYWxz byANCj4gbWFrZXMgaXQgbW9yZSBkaWZmaWN1bHQgdG8gZmluZCB0aGUgcnVsZXMgdGhhdCBhcmUg bmV3Lg0KPiANCj4gSXQgaXMgYmV0dGVyIHRvIGNpdGUgdGhlIG9sZGVyIGRldGFpbHMgdGhhbiB0 byByZXBlYXQgdGhlbS4NCj4gDQo+IFRoZSBhcmd1bWVudCB0aGF0IEkgaGF2ZSBoZWFyZCB0byBq dXN0aWZ5IHRoZSByZXBldGl0aW9uIGlzIHNhdmluZyB0aGUgcmVhZGVyIA0KPiBmcm9tIGhhdmlu ZyB0byByZWZlciBiYWNrIHRvIHRoZSBlYXJsaWVyIHNwZWNpZmljYXRpb24uICBUaGlzIGp1c3Rp ZmljYXRpb24gaXMgDQo+IGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHJlYWRlciBp cyBub3QgZ29pbmcgdG8gYmUgcmVxdWlyZWQgdG8gYmUgDQo+IGZhbWlsaWFyIHdpdGggdGhlIGVh cmxpZXIgc3BlY2lmaWNhdGlvbiBmb3Igb3RoZXIgcmVhc29ucy4NCj4gDQo+IEluIHRoZSBjYXNl IG9mIEVBSSwgdGhlIHJlYWRlciBpcyByZXF1aXJlZCB0byBiZSBmYW1pbGlhciB3aXRoIFJGQyA1 MzIxLiAgU28gdGhlIA0KPiByZXBldGl0aW9uIG9mIHNvbWUgcnVsZXMgZG9lcyBub3QgcmVhbGx5 IHNhdmUgdGhlIHJlYWRlciBhbnkgaW50ZXJlc3RpbmcgYW1vdW50IA0KPiBvZiBlZmZvcnQsIGlu IG15IG9waW5pb24uDQo+IA0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZXZlbiBpZiB0aGUg cmVhZGVycyBhcmUgZmFtaWxpYXIgd2l0aCBSRkMgNTMyMSwgdGhleSBjYW4gbm90IHJlcGVhdCB0 aGUgYWN0dWFsIEFCTkYgZGVmaW5pdGlvbiBpbiBtaW5kLg0KDQpJZiB0aGUgcXVlc3Rpb24gaXMg IndobyBjYW4gd3JpdGUgZG93biAgUkZDIDUzMjEncyBBQk5GIGRlZmluaXRpb24gb2YgTWFpbGJv eCwgUXVvdGVkLXN0cmluZyBvciBEb3Qtc3RyaW5nIHdpdGhvdXQgbG9va2luZyB1cCBpbnRvIFJG QzUzMjEiLCBJIGJlbGlldmUgdGhhdCBmZXcgd2lsbCByYWlzZSB0aGUgaGFuZC4gQXQgbGVhc3Qs IGZvciBtZSwgSSBoYXZlIHRvIGxvb2sgaXQgdXAgaW4gUkZDNTMyMS4NCg0KU28gc29tZXRpbWVz LCB3ZSBoYXZlIHRvIGRvIHNvbWUgcmVwZXRpb24gd29yayBmb3IgZWFzeSByZWFkaW5nLg0KDQpJ ZiB3ZSBhcmUgYWZyYWlkIG9mIGNyZWF0aW5nIGFuIG9wcG9ydHVuaXR5IGZvciBlcnJvciwgd2Ug Y2FuIHRha2UgbW9yZSB0aW1lIHRvIGNoZWNrIHdoZXRoZXIgb3VyIHJlcGV0aW9uIGlzIGNvcnJl Y3Qgb3Igbm90Lg0KDQppZiB3ZSByZWZ1c2UgdG8gcmVwZWF0IHNvbWUgZGVmaW5pdGlvbiwgSSBh bSBhZnJhaWQgb2YgY3JlYXRpbmcgYW4gb3Bwb3J0dW5pdHkgZm9yIGVycm9yIG9yIGNvbmZ1c2lu ZyB0b28uDQoNCkZvciBleGFtcGxlLCBpbiBSRkM1MzM2YmlzLCBtYWlsYm94IHdpbGwgYmUgbWVu dGlvbmVkICBvciByZWZlcmVuY2VkIGEgbG90IG9mIHRpbWVzLg0KSWYgd2UganVzdCB0ZWxsIHRo ZSByZWFkZXJzIHRoYXQgcGxzIGxvb2sgbWFpbGJveCBkZWZpbml0aW9uIGluIFJGQzUzMjEsIHRo ZSByZWFkZXIgbWF5IGp1c3QgcmVhZCB0aGUgbWFpbGJveCBkZWZpbml0aW9uIG9mIFJGQzUzMjEg YW5kIGl0cyBzdXBwb3J0IHJ1bGVzIGluIFJGQzUzMjEsIGFuZCByZWFjaCBhIHdyb25nIGNvbmNs dXNpb24gdGhhdCBtYWlsYm94IG9mIHJmYzUzMzZiaXMgPT09bWFpbGJveCBvZiByZmM1MzIxLCBi dXQgaW4gZmFjdCwgICAgIG1haWxib3ggb2YgcmZjNTMzNmJpcyBpbmNsdWRlcyBtb3JlIGNoYXJh Y3RlcnMgd2hpbGUgbWFpbGJveCBvZiByZmM1MzIxIGluY2x1ZGVzIGxlc3MgY2hhcmFjdGVycy4N Cg0KYW55IGNvbW1lbnRzIGFib3V0IGl0ID8NCg0KDQo+IFNvIEkgc3VnZ2VzdDoNCj4gDQo+ICAt LS0tLS0tLS0tDQo+IA0KPiAgICBJbXBvcnRlZCBmcm9tIFJGQyA1MzIxLCBTZWN0aW9uIDQuMS4y Og0KPiANCj4gICAgICBNYWlsYm94DQo+IA0KPiAgICAgIExvY2FsLXBhcnQNCj4gDQo+ICAgICAg RG90LXN0cmluZw0KPiANCj4gICAgICBRdW90ZWQtc3RyaW5nDQo+IA0KPiAgICAgIERvbWFpbg0K PiANCj4gICAgICBBdG9tDQo+IA0KPiAgICBJbXBvcnRlZCBmcm9tIFJGQyA1MzM1YmlzLCBTZWN0 aW9uIDQuMToNCj4gDQo+ICAgICAgVVRGOC1ub24tYXNjaWkNCj4gDQo+IA0KPiAgICBJbXBvcnRl ZCBmcm9tIFJGQyA1ODkwLCBTZWN0aW9uIDIuMy4yLjE6DQo+IA0KPiAgICAgIFUtbGFiZWwNCj4g DQo+IA0KPiAgICBFeHRlbmRlZCBmcm9tIFJGQyA1MzIxLCBTZWN0aW9uIDQuMS4yOg0KPiANCj4g ICAgICBhdGV4dCAgICAgICAgICA9LyAgVVRGOC1ub24tYXNjaWkNCj4gDQo+ICAgICAgc3ViLWRv bWFpbiAgICAgID0gLyBVLWxhYmVsDQo+IA0KPiAgICAtLS0tLS0tLS0tDQo+IA0KPiBIb3dldmVy LCBub3RlIHRoYXQgbm9uZSBvZiB0aGUgZmlyc3Qgc2V0IG9mIHJ1bGVzIChmcm9tIFJGQyA1MzIx LCBTZWN0aW9uIDQuMS4yKSANCj4gaXMgYWN0dWFsbHkgdXNlZCBlbHNld2hlcmUgaW4gdGhpcyBz cGVjaWZpY2F0aW9uLiAgSGVuY2UsIGl0IGRvZXMgbm90IG1ha2UgbXVjaCANCj4gc2Vuc2UgdG8g aW1wb3J0IG9yIHJlcGVhdCB0aGVtLg0KPiANCj4gSSBiZWxpZXZlIHRoYXQgd2hhdCBpcyBtZWFu dCwgd2hlbiByZWZlcnJpbmcgdG8gdGhlbSwgaXMgdG8gaGVscCB0aGUgcmVhZGVyIA0KPiB1bmRl cnN0YW5kIHRoYXQgPGF0ZXh0PiBhbmQgPHN1Yi1kb21haW4+IGFyZSB1c2VkIGJ5IHRoZXNlIG90 aGVyIHJ1bGVzLg0KPiAgSSANCj4gYmVsaWV2ZSBpdCB3aWxsIGJlIG1vcmUgaGVscGZ1bCB0byBo YXZlIHRleHQgdGhhdCBleHBsYWlucyB0aGlzLCByYXRoZXIgdGhhbiB0byANCj4gY2l0ZSBydWxl cyB0aGF0IGFyZSBub3QgdXNlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gDQo+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+DQo+PiAyICoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KPj4NCj4+DQo+PiBUaGUgc2VjdGlvbiAzLjcuMyAgaXMgc3Vw cG9zZWQgdG8gYmUgdXBkYXRlZCB0byB0aGUgZm9sbG93aW5nDQo+Pg0KPj4NCj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+Pg0KPj4NCj4+IDMuNy4zIFRyYWNlIEluZm9ybWF0aW9uDQo+Pg0KPiBJZiB0aGlzIHNl Y3Rpb24gaXMgZ29pbmcgdG8gcmUtZGVmaW5lIHNwZWNpZmljLCBleGlzdGluZyBjb21wb25lbnRz LCBmcm9tIFJGQyANCj4gNTMyMSwgdGhlbiBpdCBzaG91bGQgb25seSBkZWZpbmUgdGhlIHBhcnRz IHRoYXQgYXJlIGRpZmZlcmVudCBvciBuZXcuICBBZ2FpbiwgaXQgDQo+IHNob3VsZCBub3QgcmVw ZWF0IHRoZSBmdWxsIHNwZWNpZmljYXRpb24uDQo+IA0KPiANCj4+ICAgICBGb3IgdGhlIHRyYWNl IGluZm9ybWF0aW9uIFtSRkM1MzIxXSwgdGhpcyBtZW1vIHVwZGF0ZXMgIHRoZSByZXR1cm4gcGF0 aCBsaW5lIFtSRkM1MzIxXSBhbmQgdGhlIHRpbWUgc3RhbXAgbGluZSBmb3JtYWxseSBkZWZpbmVk IGFzIGZvbGxvd3M6DQo+Pg0KPj4gICAgIFJldHVybi1wYXRoLWxpbmUgPSAiUmV0dXJuLVBhdGg6 IiBGV1MgUmV2ZXJzZS1wYXRoIENSTEYNCj4+ICAgICAgOyBJbmhlcml0IFJldHVybi1wYXRoLWxp bmUgZGVmaW50aW9uIGZyb20gU2VjdGlvbiA0LjQgb2YgUkZDIDUzMjENCj4+ICAgICAgOyBSZXZl cnNlLXBhdGggbWF5IGluY2x1ZGUgdGhlIGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBuYW1lIHdp dGggdGhlIFUtbGFiZWwgZm9ybQ0KPiANCj4gKEkgYmVsaWV2ZSBSZXZlcnNlLXBhdGggaXMgZGVm aW5lZCBpbiBTZWN0aW9uIDQuMS4yLikNCj4gDQo+IFRoaXMgaXMgbm90IGFkZGl0aW9uYWwgc3Bl Y2lmaWNhdGlvbiwgYmVjYXVzZSB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbidzIHVzZSBvZiANCj4g TWFpbGJveCBtZXJlbHkgdXNlcyB0aGUgbmV3IGFuZCBlbmhhbmNlZCBkZWZpbml0aW9uIG9mIHN1 Yi1kb21haW4sIGZyb20gYWJvdmUuIA0KPiBIZW5jZSwgd2hhdCBtaWdodCBiZSBuZWVkZWQgaXMg bWVyZWx5IHNvbWUgdGV4dCB0aGF0IHBvaW50cyBvdXQgdGhpcyBmYWN0IHRvIHRoZSANCj4gcmVh ZGVyLCByYXRoZXIgdGhhbiBhbnl0aGluZyB0aGF0IHRyaWVzIHRvIGxvb2sgbGlrZSBhIHNwZWNp ZmljYXRpb24uDQo+IA0KPiANCj4+ICAgIFRpbWUtc3RhbXAtbGluZSA9ICJSZWNlaXZlZDoiIEZX UyBTdGFtcCBDUkxGDQo+PiAgICAgIDsgUmVwbGFjZXMgVGltZS1zdGFtcC1saW5lIGluIFNlY3Rp b24gNC40IG9mIFJGQyA1MzIxDQo+IA0KPiApDQo+IA0KPj4gOyBTdGFtcCBtYXkgaW5jbHVkZSB0 aGUgJ0ZvcicgY2xhdXNlIHdoZXJlIHRoZSBpbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbmFtZQ0K PiA+IHdpdGggdGhlIFUtbGFiZWwgZm9ybSBtYXkgYmUgdXNlZC4NCj4gDQo+IFRoaXMgaXMgbm90 IGFkZGl0aW9uYWwgc3BlY2lmaWNhdGlvbiwgYmVjYXVzZSB0aGUgZXhpc3RpbmcgZGVmaW5pdGlv bidzIHVzZSBvZiANCj4gTWFpbGJveCBtZXJlbHkgdXNlcyB0aGUgbmV3IGFuZCBlbmhhbmNlZCBk ZWZpbml0aW9uIG9mIHN1Yi1kb21haW4sIGZyb20gYWJvdmUuIA0KPiBIZW5jZSwgd2hhdCBtaWdo dCBiZSBuZWVkZWQgaXMgbWVyZWx5IHNvbWUgdGV4dCB0aGF0IHBvaW50cyBvdXQgdGhpcyBmYWN0 IHRvIHRoZSANCj4gcmVhZGVyLCByYXRoZXIgdGhhbiBhbnl0aGluZyB0aGF0IHRyaWVzIHRvIGxv b2sgbGlrZSBhIHNwZWNpZmljYXRpb24uDQo+IA0KPiANCj4gSW4gYWRkaXRpb246DQo+IA0KPj4+ PiAgRnJvbSByZmM1MzM1YmlzOg0KPj4+Pg0KPj4+PiAgICAgVVRGOC1lbmhhbmNlbWVudCAgPSAg IFVURjgtMiAvIFVURjgtMyAvIFVURjgtNA0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICA7 IGluY29ycG9yYXRlIGZyb20gcmZjNTMzNWJpcywgU2VjdGlvbiAyLjENCj4+Pj4NCj4+Pj4gICAg IFZDSEFSICAgPS8gIFVURjgtbm9uLWFzY2lpDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg IDsgaW5jb3Jwb3JhdGUgZnJvbSByZmM1MzM1YmlzLCBTZWN0aW9uIDIuMQ0KPj4+Pg0KPj4+PiAg ICAgY3RleHQgICA9LyAgVVRGOC1lbmhhbmNlbWVudA0KPj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICA7IGluY29ycG9yYXRlIGZyb20gcmZjNTMzNWJpcywgU2VjdGlvbiAyLjENCj4+Pj4NCj4+ Pj4gICAgIGF0ZXh0ICAgPS8gIFVURjgtZW5oYW5jZW1lbnQNCj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgOyBpbmNvcnBvcmF0ZSBmcm9tIHJmYzUzMzViaXMsIFNlY3Rpb24gMi4xDQo+Pj4+ DQo+Pj4+ICAgICBxdGV4dCAgID0vICBVVEY4LWVuaGFuY2VtZW50DQo+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgIDsgaW5jb3Jwb3JhdGUgZnJvbSByZmM1MzM1YmlzLCBTZWN0aW9uIDIuMQ0K Pj4+Pg0KPj4+PiAgICAgdGV4dCAgICA9LyAgVVRGOC1lbmhhbmNlbWVudA0KPj4+PiAgICAgICAg ICAgICAgICAgICAgOyBub3RlIHRoYXQgdGhpcyB1cGdyYWRlcyB0aGUgYm9keSB0byBVVEYtOA0K Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICA7IGluY29ycG9yYXRlIGZyb20gcmZjNTMzNWJp cywgU2VjdGlvbiAyLjENCj4+Pj4NCj4+Pj4gICAgIHt7IGhvdyB0byBhZGQgSUROIHRvIHRoaXM/ IH19DQo+Pj4+ICAgICBkb21haW4gID0gICBkb3QtYXRvbSAvIGRvbWFpbi1saXRlcmFsIC8gb2Jz LWRvbWFpbg0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICA7IGluY29ycG9yYXRlIGZyb20g cmZjNTMzNWJpcywgU2VjdGlvbiAyLjENCj4+Pj4NCj4+Pj4gQWRkOg0KPj4+Pg0KPj4+PiAgICAg cXVvdGVkLXBhaXJTTVRQICA9LyAlZDkyIFVURjgtZW5oYW5jZW1lbnQNCj4+Pj4NCj4+Pj4gICAg IHF0ZXh0U01UUCAgICAgICAgPS8gIFVURjgtZW5oYW5jZW1lbnQNCj4gDQo+IA0KPiBJIHNlZSB0 aGF0IG1vc3Qgb2YgdGhlIGVuaGFuY2VkIHJ1bGVzIHRoYXQgSSBzdWdnZXN0ZWQgYXJlIG5vdCBp bmNsdWRlZCBpbiB5b3VyIA0KPiBwcm9wb3NhbC4gIFBsZWFzZSBleHBsYWluLg0KPiANCg0KSW4g dGhpcyBlbWFpbCwgSSBqdXN0IGZvY3VzIG9uIFJGQzUzMzZiaXMuIE1hbnkgZW5oYW5jZWQgcnVs ZXMgc3VjaCBhcyAgVkNIQVIgb3IgY3RleHQgb3IgcXRleHQgYXJlIG5vdCB1c2VkIGluIFJGQzUz MzZiaXMsIHdoaWxlIHRoZXkgYXJlIHVzZWQgaW4gUkZDNTMzNWJpcy4NCg0KDQoNCj4gZC8NCj4g LS0gDQo+IA0KPiAgIERhdmUgQ3JvY2tlcg0KPiAgIEJyYW5kZW5idXJnIEludGVybmV0V29ya2lu Zw0KPiAgIGJiaXcubmV0 From johnl@iecc.com Tue May 24 06:32:00 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21AE06E9 for ; Tue, 24 May 2011 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.124 X-Spam-Level: X-Spam-Status: No, score=-111.124 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuBeugMlVFOr for ; Tue, 24 May 2011 06:31:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5A23AE0747 for ; Tue, 24 May 2011 06:31:59 -0700 (PDT) Received: (qmail 76695 invoked from network); 24 May 2011 13:31:58 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 24 May 2011 13:31:58 -0000 Date: 24 May 2011 13:31:36 -0000 Message-ID: <20110524133136.8902.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <506222216.09892@cnnic.cn> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] (Dave's detail suggestion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:32:00 -0000 Sorry, I thought I'd responded to this a long time ago. In this case, I have to agree with Dave. If a newer RFC uses definitions from an older one, it should always refer to the older one, not attempt to copy the definitions. There are too many ways that the copies get out of sync, and it's useful to document via the reference that the two definitions are required to be the same. The entire RFC archive easily fits on a $2 thumb drive. It is not unreasonable to expect people to have access to every RFC. R's, John From klensin@jck.com Tue May 24 11:31:01 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50514E076B for ; Tue, 24 May 2011 11:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMVFJ4oqVsXw for ; Tue, 24 May 2011 11:31:00 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1B447E0765 for ; Tue, 24 May 2011 11:30:59 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QOwNe-000OsU-Ga for ima@ietf.org; Tue, 24 May 2011 14:30:58 -0400 Date: Tue, 24 May 2011 14:30:57 -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 Subject: [EAI] Syntax and status of 5336bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:31:01 -0000 Hi. I probably should have been explicit about this earlier, but I've decided that I don't want to take any position about the details of the various ABNF controversies. Compared to the costs of delay while we debate the issues, I just do not consider the choice important as long as we are consistent about it. I do think it is worth pointing out to the WG that, when 5321 was approved, at least one member of the IESG was quite insistent that we copy all definitions (so that the document was self-contained and automated ABNF checkers could be used) and indicate where they came from so that the accuracy of the copies could be checked manually. We argued that doing that post-Last-Call was just too dangerous and ultimately agreed that 5321bis (if and when it ever happened) would contain some sort of explicit index to where productions could be found. The individual involved is no longer on the IESG, so this may be a non-issue, but I would like Pete (as AD) to either speak up now about what he is willing to defend to the IESG or to agree to defend whatever conclusion the WG reaches as to how to proceed. FWIW, I believe that the "copy and reference source in a note" model that Jiankang has advocated from time to time may have been discussed in the context of the IESG position on 5321 during the initial EAI WG period. That discussion, if it occurred (I just don't remember), may have influenced what appeared in 5336 (and 5335). It makes little difference at this stage, but let's be careful about blaming the editor for an approach that seemed sensible to the WG at one time. john From klensin@jck.com Tue May 24 11:57:04 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3EE06AC for ; Tue, 24 May 2011 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhzTcPX1qtDE for ; Tue, 24 May 2011 11:57:03 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 31A08E069D for ; Tue, 24 May 2011 11:57:03 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QOwmo-000PjD-PV; Tue, 24 May 2011 14:56:59 -0400 Date: Tue, 24 May 2011 14:56:57 -0400 From: John C Klensin To: Jiankang YAO Message-ID: In-Reply-To: <505172775.10794@cnnic.cn>, <0E1EF2A34222483A89A170233CE2DC29@LENOVO47E041CF> References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn> <503833016.15024@cnnic.cn> <503865491.01228@cnnic.cn> <505172775.10794@cnnic.cn>, <0E1EF2A34222483A89A170233CE2DC29@LENOVO47E041CF> 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 Cc: ima@ietf.org Subject: [EAI] Trace fields (was: Re: (Dave's detail suggestion )Re: The scenario favoring"uMailbox"?_ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:57:04 -0000 --On Thursday, May 12, 2011 11:59 +0800 Jiankang YAO wrote: > 2 ****************************************** > > > The section 3.7.3 is supposed to be updated to the following > > > -------------------------------------------------------------- > ------ > > > 3.7.3 Trace Information > > > For the trace information [RFC5321], this memo updates the > return path line [RFC5321] and the time stamp line formally > defined as follows: >... > > Time-stamp-line = "Received:" FWS Stamp CRLF > ; Replaces Time-stamp-line in Section 4.4 of RFC 5321 > ; Stamp may include the 'For' clause where the > internationalized domain name with the U-label form may be > used. > Except in the 'For' clause and 'Reverse-path' value where > internationalized domain name with the U-label form MAY be > used, internationalized domain names in Received fields > MUST be transmitted in the form of A-labels. The protocol > value of the WITH clause when this extension is used is one > of the UTF8SMTPbis values specified in the "IANA > Considerations" section of this document. Speaking personally, as editor of 5321, and historically, but not as co-chair, we discussed this at length during the initial round of EIA and concluded that it was a bad idea. The problem is that trace fields are of use primarily in debugging, often of bounced messages, and there is no guarantee that the path used to return such messages will be EAI-compliant even if the forward path is EAI-compliant. Return-path is not a problem because it is supplied only on final delivery where the capabilities of the delivery server are noted. But, for anything that might be bounced, putting something in any "Received:" (time-stamp) field that might cause the trace information to be trashed or the bounce message to be dropped is a very serious step. This is one of those obvious tradeoffs between "works well during the transition but is ugly and creates an unpleasant transitional situation we won't be able to get rid of" and "looks and acts much better in the long run, but may cause problems in the shorter term". I am not going to take a position on what choice the WG makes, but suggest that the WG needs to examine the question very carefully. john p.s. It seems to me that we are having a little bit of misunderstanding about "outside the scope of this specification" as a statement and design model for what can and cannot be said in a specification. There are, IMO, two flavors of "out of scope". One is our tradition one and is used extensively (as a design model) in 5321 and elsewhere. That situation arises when a specification deliberately does not cover a particular case or when it prohibits some behavior. While there are exceptions in which we actually do specify the behavior for the error cases, our normal position on what happens if the rule is violated is "out of scope for the specification". The other situation arises with extensions and requirements that the extension specification (5336bis in this case) inherits from the base specification (5321 in this case). Because every SMTP extension specification is required to follow whatever provisions of SMTP/5321 that it doesn't explicitly override, including correct handling or unextended SMTP/5321 messages and the presence or absence of UTF8SMTP doesn't explicitly change the semantics or actions associated with data elements that are 5321-conformant, we know for certain that every EAI-compliant server must be able to handle an all-ASCII (envelope, headers, content) message the way 5321 specifies handling it. It seems to me that mentioning that (or not) is an editorial matter, best not repeated unless doing so is needed for clarity. But mentioning it (or not) is not "outside the specification" because 5336bis inherits the 5321 base spec. john From Shawn.Steele@microsoft.com Tue May 24 12:49:45 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B001E06A5 for ; Tue, 24 May 2011 12:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+jL++dhDX9H for ; Tue, 24 May 2011 12:49:44 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id C493EE0708 for ; Tue, 24 May 2011 12:49:44 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 May 2011 12:49:44 -0700 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.90]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0289.008; Tue, 24 May 2011 12:49:44 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Interest Thread-Index: AcwaSiWKjc826bBtR4uzPwqBalhdMA== Date: Tue, 24 May 2011 19:49:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Interest X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 19:49:45 -0000 > The WG decided to adopt the ABNF style same or similar to your suggestion= . > So I think that most WG members are waiting for your "authoritative" resp= onse. Pretty much. I, personally, feel like the "rank and file" members (me) thi= nk that the tweaks are being requested are minor. I don't understand the s= ubtleties of ABNF to provide reasonable feedback. I depend on John and Dav= e to say reasonable things and make reasonable comments. "Whatever makes t= hem happy." > On the other hand, the WG have reached many conclusions or results, and s= olved the key issues. > The current editing work is more or less just "editing or refining". > I remember that Shawn said that the implementation work of EAI will keeep= same or similar=20 > in spite of that how we change the ABNF style. Yes. The review process is in a serious rut. IMO this should "just" make = the corrections currently requested and submit it. The nitpicking is weari= ng, and if there are minor errors that need fixed, that's what the editoria= l process is for. The core concepts have been stable for months. > It is better to cite the older details than to repeat them. I would agree that it's better to reference the earlier spec, with minor up= dates. However this is really an editorial issue and has nothing to do wit= h the functionality. From dhc2@dcrocker.net Tue May 24 13:14:00 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB3EE0670 for ; Tue, 24 May 2011 13:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtoJXeq8T21N for ; Tue, 24 May 2011 13:14:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7C7E06AE for ; Tue, 24 May 2011 13:14:00 -0700 (PDT) Received: from [10.250.20.34] (guest-224.mv.mozilla.com [63.245.220.224]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4OKDr6Y013484 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 24 May 2011 13:13:59 -0700 Message-ID: <4DDC117D.4000100@dcrocker.net> Date: Tue, 24 May 2011 13:13:49 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ima@ietf.org References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn> <503833016.15024@cnnic.cn> <503865491.01228@cnnic.cn> <505172775.10794@cnnic.cn>, <0E1EF2A34222483A89A170233CE2DC29@LENOVO47E041CF> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 24 May 2011 13:14:00 -0700 (PDT) Subject: Re: [EAI] Trace fields X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:14:01 -0000 On 5/24/2011 11:56 AM, John C Klensin wrote: >> 3.7.3 Trace Information ... >> Time-stamp-line = "Received:" FWS Stamp CRLF ... >> Except in the 'For' clause and 'Reverse-path' value where ... > > Speaking personally, as editor of 5321, and historically, but > not as co-chair, we discussed this at length during the initial > round of EIA and concluded that it was a bad idea. The problem > is that trace fields are of use primarily in debugging, often of > bounced messages, and there is no guarantee that the path used > to return such messages will be EAI-compliant even if the > forward path is EAI-compliant. There is no "guarantee" that the /forward/ path will be EAI-complaint! What there /is/ is a working group decision to support EAI in the message. This decision is damaged when it is applied to only part of the message. The working group originally tried to use a more complicated model for its specification, including support for "hybrid" environments, with some Unicode and some ASCII-only. The current working group model is for an 8-bit clean environment, leaving the concern for 7-bit environments to separate work. That model applies to the return path, as well as the forward path. As such, it is reasonable and appropriate -- in fact I think it is necessary -- to have the Trace fields support the EAI enhancements. This does not deny that that there will be barriers to 8-bit clean. Rather, it simply moves the issue outside of this specification, to simplify the specification model and effort. (It also ought to make specification quicker...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Tue May 24 16:38:23 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2CE0695 for ; Tue, 24 May 2011 16:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1BA1DOvbz8j for ; Tue, 24 May 2011 16:38:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09FE064E for ; Tue, 24 May 2011 16:38:22 -0700 (PDT) Received: from [10.250.20.34] (guest-224.mv.mozilla.com [63.245.220.224]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4ONcBJb016717 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 16:38:20 -0700 Message-ID: <4DDC415F.2050303@dcrocker.net> Date: Tue, 24 May 2011 16:38:07 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jiankang YAO References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn><503833016.15024@cnnic.cn> <503865491.01228@cnnic.cn> <505172775.10794@cnnic.cn> <506206245.14647@cnnic.cn> <506222216.09892@cnnic.cn> In-Reply-To: <506222216.09892@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 24 May 2011 16:38:20 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] (Dave's detail suggestion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 23:38:23 -0000 On 5/24/2011 12:30 AM, Jiankang YAO wrote: > From: "Dave CROCKER" >> >> It is better to cite the older details than to repeat them. > > My understanding is that even if the readers are familiar with RFC 5321, they > can not repeat the actual ABNF definition in mind. > > If the question is "who can write down RFC 5321's ABNF definition of > Mailbox, Quoted-string or Dot-string without looking up into RFC5321", I > believe that few will raise the hand. At least, for me, I have to look it up > in RFC5321. > > So sometimes, we have to do some repetition work for easy reading. There are a number of different types of people who read these documents. Some readers are very casual. They have some interest in the work, but they are not required to develop a deep understanding of the fine-grained details. I believe you are correct that the repeated text will make their reading easier. However IETF technical specifications are not written for this type of reader. (I believe our specifications tend to be more readable for such folk than are specifications from most other standards groups, but they are not our target market.) Other readers are implementers. It might seem to be intuitively correct that repetition would make the work easier for these people, too. However, it probably does /not. The reality is that they are required to consult the base document (RFC 5321, in this case) whether this text is repeated or not: Doing implementation work for an enhancement to an existing specification requires consulting the original specification. For such people, having a definition exist in two places actually can make things more confusing. As I previously noted, it also makes the new specification larger and more complicated. > If we are afraid of creating an opportunity for error, we can take more time > to check whether our repetition is correct or not. Unfortunately, simply insisting on more review does not guarantee that there will be no errors. (Over in the DKIM world, we are also doing a -bis version of the original specification. The original was very heavily reviewed, yet it turns out that its ABNF had a number of very basic and very important errors.) As for the view that the question of whether to repeat specification text really is important: It is easy to believe it does not matter very much... until one watches the confusion of implementers and the confusion of folk who discuss protocol specifications later. As for the possibility that someone on the IESG might feel that repeating the text is better: This is a good demonstration that people on the IESG can be wrong. It also highlights the problem with worrying more about IESG reaction than about doing good engineering. The requirement for working groups is to produce good engineering; this is not accomplished by worrying whether one or another IESG member /might/ be misguided. If the IESG is going to create a policy about the details of technical specifications, they can document it and seek IETF approval. Until they do that, they should not try to dictate this sort of detail. As for the concern about delays: Forgive me, but this working group has not followed a process that has shown much concern for moving quickly, up to this point. Consequently, using urgency as an argument, at this stage, as a basis for ignoring a basic matter of specification should not carry much weight. > if we refuse to repeat some definition, I am afraid of creating an > opportunity for error or confusing too. Please forgive my repeating: including redundant specification encourages confusion divergence, confusion and error. (There is a very old joke: if you have one watch, you know what time it is; if you have two, you are never quite sure. The same applies for repeated normative specifications...) > For example, in RFC5336bis, mailbox will be mentioned or referenced a lot of > times. If we just tell the readers that pls look mailbox definition in > RFC5321, the reader may just read the mailbox definition of RFC5321 and its > support rules in RFC5321, and reach a wrong conclusion that mailbox of > rfc5336bis ===mailbox of rfc5321, but in fact, mailbox of rfc5336bis > includes more characters while mailbox of rfc5321 includes less characters. rfc5336bis needs to have text that explains the relationship between its specification and the specifications in rfc5321. This does not require repeating any of the base (rfc5321) specification. I believe that if we are consistent in applying the logic you are using, then we must repeat /more/ rules from RFC 5321 than you are providing: it is not enough to include Mailbox and its constituents. In fact it would be necessary to repeat /all/ of rfc5321, with the EAI changes. An implementer might need all of them, so we would have to provide them, if the goal is to avoid having the implementer consult rfc 5321... >> In addition: >> >>>>> From rfc5335bis: >>>>> >>>>> UTF8-enhancement = UTF8-2 / UTF8-3 / UTF8-4 ; incorporate from >>>>> rfc5335bis, Section 2.1 ... >> I see that most of the enhanced rules that I suggested are not included in >> your proposal. Please explain. > > In this email, I just focus on RFC5336bis. Many enhanced rules such as VCHAR > or ctext or qtext are not used in RFC5336bis, while they are used in > RFC5335bis. I often miss or misunderstand details, even when I'm trying to be careful. So it is entirely possible that what follows has errors... RFC 5321 has the construct: > Local-part = Dot-string / Quoted-string > ; MAY be case-sensitive is a component that forms a . Your proposal kept the version of that I specified. This covers the EAI requirement for a . also needs to support EAI. From my proposed syntax, was intended to satisfy this requirement. However, RFC 5321 uses a different construct for a quoted string: . Therefore I believe that was is needed is: qtextSMTP =/ UTF8-non-ascii RFC 5321 also used a quoted-pair construct: > quoted-pairSMTP = %d92 %d32-126 If I am reading this correctly, it already supports UTF-8, but I'd appreciate hearing others confirm this. (I am a little curious about the reason it does not include %d127. Since that is obviously excluded explicitly, I assume that it is not an error.) Upon review, I believe that all 3 of these rules: > VCHAR =/ UTF8-non-ascii > ; incorporate from rfc5335bis, Section 2.1 > > ctext =/ UTF8-enhancement > ; incorporate from rfc5335bis, Section 2.1 > > text =/ UTF8-enhancement > ; note that this upgrades the body to UTF-8 > ; incorporate from rfc5335bis, Section 2.1 are used in RFC 5322, for general text in some fields and that they are not needed for RFC 5321. That is, I believe you are correct to remove them. Again, it would be helpful to have other working group participants review this and confirm that they are not needed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Wed May 25 10:11:12 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE13E0740 for ; Wed, 25 May 2011 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PPdYGuMKljj for ; Wed, 25 May 2011 10:11:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 29746E070F for ; Wed, 25 May 2011 10:11:12 -0700 (PDT) Received: from [10.250.20.34] (guest-224.mv.mozilla.com [63.245.220.224]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4PHB4JV011154 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 10:11:09 -0700 Message-ID: <4DDD3824.6070504@dcrocker.net> Date: Wed, 25 May 2011 10:11:00 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jiankang YAO References: <503791589.01356@cnnic.cn> <503796187.10439@cnnic.cn><503833016.15024@cnnic.cn> <503865491.01228@cnnic.cn> <505172775.10794@cnnic.cn> <506206245.14647@cnnic.cn> <506222216.09892@cnnic.cn> <4DDC415F.2050303@dcrocker.net> In-Reply-To: <4DDC415F.2050303@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 25 May 2011 10:11:09 -0700 (PDT) Cc: ima@ietf.org Subject: Re: [EAI] (Dave's detail suggestion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:11:13 -0000 On 5/24/2011 4:38 PM, Dave CROCKER wrote: > On 5/24/2011 12:30 AM, Jiankang YAO wrote: >> From: "Dave CROCKER" >>> >>> It is better to cite the older details than to repeat them. >> >> My understanding is that even if the readers are familiar with RFC 5321, they >> can not repeat the actual ABNF definition in mind. ... > Other readers are implementers. It might seem to be intuitively correct that > repetition would make the work easier for these people, too. However, it > probably does /not. The reality is that they are required to consult the base > document (RFC 5321, in this case) whether this text is repeated or not: Doing > implementation work for an enhancement to an existing specification requires > consulting the original specification. Please forgive my responding to my own posting, but I had an additional thought this morning: Consider the "=/" ABNF construct. Note that we are already using it in the working group specifications. Therefore we should consider what its use means and what it implies. The purpose of this construct is for adding one ore more alternatives to an ABNF rule that has previously been specified, elsewhere. This very much does include having been specified in an earlier document. The construct permits enhancing a rule... WITHOUT HAVING TO REPEAT THE ENTIRE RULE. (Please forgive my "shouting" but it is important that this point be considered carefully.) If we have an ABNF construct that is intended to permit additional specification without repating the original rule, itself, then it makes no sense to include the surrounding rules "to provide background" for the reader. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Shawn.Steele@microsoft.com Wed May 25 12:46:20 2011 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153C31300DC for ; Wed, 25 May 2011 12:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXpovDfD7htY for ; Wed, 25 May 2011 12:46:19 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9D652130097 for ; Wed, 25 May 2011 12:46:19 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 May 2011 12:46:18 -0700 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.90]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0289.008; Wed, 25 May 2011 12:46:18 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: (Dave's detail suggestion (Dave CROCKER) Thread-Index: AcwbFDM/ziRIqDegQpODY9U5yX13Lw== Date: Wed, 25 May 2011 19:46:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] (Dave's detail suggestion (Dave CROCKER) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 19:46:20 -0000 I agree with dave's points (still) that the text shouldn't be duplicated. = =20 * Readers still need to understand the older mail RFCs * In the event of errata or something to the older RFCs, it gets more confu= sing if stuff is duplicated. -Shawn